Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Uffe

Pages: 1 ... 54 55 [56] 57 58 ... 85
Suggestions and Requests / Re: Code Generation from Activity Diagram
« on: April 25, 2008, 08:17:59 pm »

Yes, no. More's the pity since it'd be a hugely valuable feature.

The (kinda) reverse is possible, though: you can generate sequence diagrams from executed code. You'll find that described in the Help, "Debug and Profile" - "Profiling and Debugging".

However, since the process is one-way it's mainly of use for documenting existing software, not designing / implementing new stuff.


Suggestions and Requests / Re: Tool: Create Logical Diagrams
« on: April 01, 2008, 08:06:24 pm »
Yes, that's right. What I'm after is the ability to auto-generate class diagrams from an existing package structure in a model.

The background is the poor performance of the reverse-engineering process, but I meant for this tool to be completely separate from that.


Suggestions and Requests / Tool: Create Logical Diagrams
« on: March 31, 2008, 10:55:00 pm »
Hi all!

When reverse-engineering code you have the option of creating logical diagrams per package. However, for a large project this takes a lot of extra time and might cause problems with too many open windows.

Since the functionality is clearly already in EA to generate a diagram from a package, I'd like it as a Tool (with recursion as an option).

Anyone else?


I fully agree with this as a (very!) useful feature.

I can also add that if you look at the inheriting class, the method which you have overridden has a couple of tagged values "Implements" and "ImplementsGuid", which contain the name and GUID of the inherited method. So the reference is still there, it's not a once-off copy. In other words EA does know that the method is an override.

If you're doing substantial changes to an interface and if you're working in anything larger than a toy model, you don't want a pop-up asking you if you want to propagate changes for each change you make (as indeed you did not suggest).
But it'd be a huge time (=money) saver to be able to do it on request. After all, initial design is a small percentage of the work. The bulk of the time is spent on refinement and maintenance.

Also, why not include this as a model validation option? Any method which is actually an override / implementation of a method in another interface / class, and whose signature does not match that of the inherited method, gets flagged.

Suggestions and Requests / Default language in Profile
« on: December 05, 2007, 07:29:21 pm »

Profiles are often intended for a single language. It would be useful to be able to set the default language of the Profile, perhaps by using the Language box of the <<profile>> package itself, or maybe on an individual Class <<stereotype>> level.


Suggestions and Requests / Re: Poll: Open up reverse engineering
« on: December 02, 2007, 05:31:53 pm »
Gets my vote.


Suggestions and Requests / Extension management
« on: December 03, 2007, 03:47:59 pm »
Hey people,

One of the strongest features in EA is its extensibility. However, it leaves a little something to be desired in the management of these extensions. (Code datatypes, code generation templates, transformation templates, profiles, patterns and whatever else I've missed.)

The way I understand it, these all get stored in the actual project (.EAP) file, as opposed to MDG technologies and Add-Ins which are referenced from external files.

The problem is that in a medium-to-large organisation where you do a lot of toolsmithing, you need to be able to keep better track of what's in whose project file than EA currently supports.

I suggest adding the following information to any extension stored in the project file:
- Source (File, Manually entered, EA Preset)
- Time of last import from file (where applicable)
- Time of last manual change (so next time someone tells me "hey, your stupid code generation doesn't work," I can look at that and go "no actually, your stupid code generation doesn't work").

Ideally, I'd like to see this information in one single place for all extension types, but just getting it into where the respective types are managed would be good too.

Down the track, it would be great if extensions could be CM:ed like the model itself (they're XML files in the end, after all). There should then be a separate repository setup for extensions, since they tend to be used in several projects.

As I said, this is more of a medium-to-large business requirement, but hey - it is Enterprise Architect, right?


Suggestions and Requests / Re: Code generation - documentation
« on: August 29, 2007, 09:28:35 pm »
Hey guys,

Regarding the MDA Transform and Code Template Framework documentation, what's in the help covers the functionality pretty well (although there are one or two omissions such as the ability to pass parameters to a code template). The help files, along with some study of the templates for a language you're familiar with, should have you up and running pretty quickly.

However, in the Code Template Framework, there is currently (7.0.815) no way of accessing the properties from the Constraints tab of the Attributes dialog. Most everything from the General and Detail tabs is available, but the Constraints aren't. So custom code generation templates won't help.

Also, since there are an unspecified number of constraints rather than a simple tickbox or similar, and you'd want to be able to @list over all your constraints, presumably this would require a new template type and not just a new field substitution macro. This might make it harder to implement, I don't know.

One possible workaround would be to use tagged values instead. Tagged value macros are available so you can pull the information out, and you can create your own UML profiles wherein you specify the tagged values your classes require. Not a perfect solution, but it's something.



Suggestions and Requests / Class Diagram: Split
« on: October 29, 2007, 08:06:18 pm »

When you reverse-engineer a large and poorly structured package you end up with a humongous diagram with a trillion classes and a brazillion connectors.

A really useful feature for this situation would be an auto-splitter, which would split one diagram into several, where each new diagram contains only classes which have no relationships to other classes in the original diagram, only to each other.

For example, consider a package with the following contents:
Code: [Select]
class A;
class B : A;
class C : A;
class I;
class II : I;
class III : II;

The auto-splitter would, based on a diagram with all these classes, produce two diagrams, one with A, B and C, the other with I, II and III.

In addition to making the model more readable, this information would be used in refactoring to isolate mutually independent parts of a package into new packages.



All of the above, please.

And: CM integration.

Rationale: Transform / Code templates are themselves code, ergo should be source controlled. (It would then be the task of the CM tool of your choice to deal with issue 5b, comparing a template with its default [= earlier version].)
In a typical medium-to-large scale deployment, the toolsmiths are working away on their tool customisations while, in parallel, the various modelling tasks are chugging along.
Keeping track of the tool customisations without CM support quickly becomes a nightmare.

I would also like the Transform / Code templates to be integrated in the Resources tree, along with Profiles, Patterns, etc. This would give you an instant overview of which (non-standard) Transform / Code templates are present in your project.

Suggestions and Requests / Stereotypes in type selection dialogs
« on: October 04, 2007, 03:23:53 pm »
Hey people,

I'd like a Stereotype column added to the type selection dialogs, which currently contain Classifier, Type, Package and Parent Element (plus ID and GUID if you fiddle a bit).

The dialogs affected would be
  • "Select Attribute type" (class attribute)
  • "Set Element Classifier" (operation parameter, operation return type)

Good? Stupid?


Suggestions and Requests / Code reverse engineering
« on: August 09, 2007, 09:56:15 pm »

Are there any plans to open up the code reverse engineering process?
In other words, allow some form of user-creatable definitions (along the lines of the Code Templates) which specify what UML artefacts to produce from a set of directories and files in some arbitrary, user-specified language?
I'm thinking that you guys must already have some tool to do this since you can reverse engineer so many languages, so is a release of this tool to the general (paying) public within the realm of possibility?



Suggestions and Requests / Code generation: Auto Generate Files
« on: August 05, 2007, 04:05:08 pm »
Hey all,

The "Auto Generate Files" feature in the "Generate Source Code" dialog is a bit blunt for my taste.
I'd like to see something more like a reverse of the "Package Structure" section of the "Import Source Directory" dialog.

In other words, I'd like to be able to specify whether namespaces, packages and individual classes should generate files or directories.

The Java case would be directory per package, file per class. C++ could be directory per namespace, file per (non-namespace root) package. Etc. Am I making sense?


General Board / Re: Component Diagram -> Socket Ball Notation
« on: November 27, 2015, 02:56:20 am »
Hi Christian,

You don't connect the exposed interfaces directly. The assembly is itself a connector which you draw from the required to the provided interface.

The assembly connector is available in the Component Relationships toolbox in component diagrams; you can also draw the connector using the quick-linker.



General Board / Re: Guarding a namespace?
« on: December 04, 2015, 04:02:20 am »
Hi Anna,

In brief, yes. You're the only ones. ;)

It is true that reusing elements between diagrams is a key point, but it does not follow that there should only ever be one element with each name.

EA does not equate name with identity. Doing so would be severely restrictive and make it more or less impossible to model different aspects of a single system or architecture.

You can write an Add-In to implement either of your suggestions within your organisation, but I don't think you'll have much success convincing others on this forum that it would be a good idea for EA generally.

As to merging two elements, an element is very complex and it wouldn't be an easy function to implement. But if the two elements only differ in what attributes and operations they have, you can move those between the two elements in the project browser by drag-and-drop.



Pages: 1 ... 54 55 [56] 57 58 ... 85