Messages

31

General Board / Re: Classes go in Class model or Component model?

« on: October 29, 2010, 01:22:13 am »

I use component diagram to depict the names of external interfaces and composite diagrams to show control and data flow interconnection between the subcomponent instances. I find these two representations, along with state charts, to be the most useful diagrams for design specification to be used for coding and maintenance.

I use class diagrams while figuring out the decomposition but a class diagram tends to be a temporary document for me. The complete details of a class are more easily expressed in my target language (C++) than in UML. It is easier to express the details, compile and then import the detailed class descriptions when I what to see class structure. I miss out on using class diagrams to express constraints so I'm studying that usage.

You should Google Leon Starr, though. He has a good blog article (and a book I have not read) about clearly expressing constraints in class diagrams. This seems like the very best purpose of a class diagram yet I seldom see them used to this full advantage.

TIFWIIW,
Dan

32

General Board / Re: Cross-package dependencies

« on: October 27, 2010, 05:47:10 pm »

We use version controlled packages. We have to be really careful to make sure that packages are added to a private project in bottom-to-top order. Above all, before checking in a changed package, make sure that all of its referenced packages have also been loaded.

Let's say you have package A and it depends on B. You might need to make a change to A that doesn't involve and of the relationships to B. You make a quick private project and check out A, make the change and check it in. You just LOST all A's references to B!

I don't have a clever way around this and have been getting by okay by just being careful. It is probably possible to write an script that you can use to check for unresolved references before checking in. I bet Geert could whip that out in minutes!

I thought I was clever and created a package dependency diagram for each of my packages. Not a bad idea regardless of the VC issue. Unfortunately, that diagram is not a guide. If a package is not loaded then the diagram just doesn't show the package. Pretty useless if you don't already know what packages should be there.

Despite this risk of losing references, the solution has been workable.

As Geert said, avoid cycles. You'll really want to do that anyway so whatever trouble EA gives you with resolving cycles is just one more concrete reason to not have cycles. We package each component in its own package and interfaces are not allowed in component packages. They are packaged separately so that it is easier to avoid cycles. Two components packages that might otherwise depend on each other only depend on an interface package instead.

We have components that are nothing more than assemblies of other components. These packages don't have any actual classes in them but hold the component definition and composite diagram for the assembly component as well as interaction diagrams. This keeps the dependencies formally going in one direction.

HTH,
Dan

33

General Board / Re: Numbering requirements with REQ001

« on: October 24, 2010, 01:13:21 pm »

See:
http://www.sparxsystems.com/enterprise_architect_user_guide/8.0/modeling_fundamentals/autocounternames.html

Dan

34

General Board / Re: Including a table in requirements

« on: October 20, 2010, 02:42:20 pm »

I've tried pasting rtf tables into the notes of a requirement element but it didn't work. I almost posted a request for it the other day but decided I didn't really want it after all. Usually a table is used to group requirements for reading. Each row in the table is usually a single requirement so I decided it is better to use document generation to create the table. You might still want the feature but I figured I'd share my conclusion just in case it might help.

Dan

35

General Board / Re: how to manage a model over multiple phases

« on: October 19, 2010, 01:41:32 am »

Oops. Fred, I should have addressed my last post to Ali. I didn't make my point clear. If the project is to overlap phases then a component that is new in one phase might need to be identified as existing in the next all at the same time. Fred's solution would address that by labeling the components with project information.

I'd recommend against labeling components with project information. Another way is to organize folders in the project browser to hold components by phase. Place the component in the phase that it will be developed (phase 0 holds preexisting components, perhaps). That would allow you to use the Phase field to indicate the status of the component and the folders to generate reports indicating component state according to plan.

I get picky about mixing project information into the component models because I reuse the models in more than one project. If the components will only be used in the one project then it probably doesn't hurt to mingle project attributes with component attributes. In that case, Fred's suggestion is less complicated and should work fine.

Dan

36

General Board / Re: how to manage a model over multiple phases

« on: October 17, 2010, 03:42:14 pm »

If a component isn't existing yet then it is still new. When it exists then is exists in every configuration it is used. It seems odd that a component would be new and existing at the same time. If your goal is to indicate which phase a component is expected to reach the "existing" state, then phase would seem like a good attribute. However, you might just do better keeping a separate plan listing the which components you expect to complete in which phase and not try to attach the project plan attributes directly to components.

I have a model for each component and include those in models that use them. Each component is independently version controlled as are the assembly models. The trick to this approach is that you need to make sure your subcomponents are encapsulated. If you start defining a component by the other components it interacts this approach won't work. You can avoid doing that. Assemblies are made up of instances of components and those instances go in the assembly model so there is no need to have the classifier definitions referencing each other. I don't use the version, state and phase attributes but if I did I'd make sure they apply to the artifacts themselves and not the system or project within which they are utilized.

I probably didn't directly help but maybe gave you some ideas to consider.

Dan

37

General Board / Re: Using EA with Agile

« on: October 12, 2010, 02:51:33 am »

Traditionally, documentation is not needed for the feature but is nice to have later when more features are to be added. If the sprint is focused on doing only what is necessary to get the features delivered, I can see modeling tasks building up in the back-log.

An effective modeler will use modeling activity to produce more features sooner. In that sense, modeling doesn't have to be a required part of the package; it is just a side effect of effective and efficient development practice. This depends on good modeling skills which for most developers are not instinctive.

Does it work to "lay down the law" and force all features to be modeled, even if the developer is not yet skilled? Is there another way to incorporate modeling?

I'm hoping to resolve apparent conflict between modeling and the following Agile values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation

When schedules are tight (always) the left side is all that is done and the right side is a nice-to-have thing that "in a perfect world" would be also done. I don't want to be cynical I believe I'm only being a realist. Geert seems to have a good measure of control over defining his process. What about others who have less control? I would be very good to find a clear and logical resolution to the apparent conflict.

Dan

38

General Board / Re: Using EA with Agile

« on: October 09, 2010, 02:20:27 am »

I hope there are some constructive suggestions to this thread. My organization is going to use Scrum because, well, "everyone's doin' it." Since I have not achieved 100% code gen from models I fear modeling will be viewed as non-agile. It would be great to hear how I can continue modeling even when "working code" is the only measure.

39

General Board / Re: Willful Transition Lines

« on: October 08, 2010, 03:32:16 am »

Thanks, Roy. I had been using custom line time but the trick is to put a control point in the line. You move the control point and the line goes with. All this time I've been messing with the ends only.

Bezier doesn't move the start end.

40

General Board / Willful Transition Lines

« on: October 07, 2010, 04:31:17 am »

I have a pattern that involves a super state transition to sub state. I drag the transition from the super state and EA happily draws the arrow. Unfortunately, this arrow has a mind of its own and is not easily made to conform to my aesthetic desires. There is some amount of predictable behavior but not much. The only way I've been able to get the look I desire is to "walk" the arrow into position by alternately pinning and unpinning the ends until it is position. Does anyone have a usable technique?

Thanks,
Dan

41

General Board / Re: What exactly is:  Executable UML

« on: October 08, 2010, 12:59:15 am »

I don't mean to be glib but if you use google you'll get plenty of hits. It is the latest trade name for the Shlaer-Mellor approach to software development.

I think the lack of serious response from this forum is because EA can be used to create models that could be compiled by a Executable UML model compiler but EA doesn't include such a compiler.

IMAO, if you don't know what it is then you are years and many $$ away from making effective use of it. This is no judgement on you but a reflection of my own experience. YMMV.

HTH,
Dan

42

General Board / Making Hidden Transitions Reappear

« on: October 07, 2010, 04:40:16 am »

I have lots of transitions that happen to go between the same two states in a state chart. I would rather not see every one of the lines but do want to see the transition specification (event, guard, action) for each. Is there an easy way to achieve this goal? Carefully placing the lines on top of each other is NOT it.

One misguided attempt was to hide all but one transition. Of course, that hides the specification as well and doesn't work. Is there a way to recover from that mistake and make the transition visible again?

Thanks,
Dan

43

General Board / Re: Rtf tables header repeated

« on: October 01, 2010, 12:32:35 am »

http://www.sparxsystems.com/downloads/whitepapers/Working_with_the_RTF_generator.pdf, pg 11

[highlight]Remove any lines between the end of the table and the end of the <risk section to ensure the table does not create extra lines when generated[/highlight].

44

General Board / Re: Business requirements vs Functional Requiremen

« on: September 30, 2010, 03:11:06 pm »

It is generally easier to generate documentation if you structure the elements in the project browser to match the document layout. It seems likely that the all business and all functional sets are the two sets you'd actually print. Query reports might be adequate for the mixed output. You can use the Satisfies relationship to link functional to business requirements.

It might turn out that the structure for one set is not so intuitive for the other. Separate trees gives you the freedom to structure the documents according to domain. The business requirements are probably the goals of your uses cases. The functional requirements will fall out of the use case scenarios so there is a good chance that trying to use a single structure will be a compromise for one or both sets. If your team is having any trouble understanding your definitions of business and functional requirement then separate structures will help with that, too.

HTH, Dan

45

General Board / Re: State internal transitions

« on: September 29, 2010, 03:53:46 pm »

See http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1278941099/0#3 for another idea.