Conceptual and implementation class models

[andyd]

Hi All,
During the analysis phase I like to build a class model along with use case diagrams to describe the real world situation in UML.  Does it make sense that when designing the solution there may be relationships between classes in the design that are not present in the analysis, and visa versa?

If so, is it possible to do this in EA within the same model, as adding the existing classes to a new diagram will so the existing relationship.

My guess would be that you would elaborate the same diagram and so loose the original analysis object model, unless you make a backup before hand of course.

Thanks,
Andy.

[Tjerk]

Hi Andy,

About EA, when you use linked elements (e.g. classes) in another diagram, its relations are visible at first. But EA has the possibility to hide relationships on a diagram.

This means that new relations could be added to and existing relations can be hidden for when using them in different diagrams.

Does this answer your EA question? For your UML question, it seems logical that more relationships can come up during design, but I'm not use what UML forces you to do.

Tjerk

[jaimeglz]

Hi, Andy.

When going from analysis to design, it is inevitable that some of your analysis classes will evolve or collapse into new implementation classes or tables. The way this is generally handled is to create separate class models for analysis and design.

During analysis, you create an analysis model with the real-world objects you discover: this is also known as the domain model, but you can call it logical model and use the default packages provided in EA. It is very convenient to keep this model in a diagram of its own.

When going into design, the actual data and user interface models should begin to emerge into their own diagrams. If your are using an RDBMS, it is quite convenient to have all your tables in a data model package (you can copy your analysis classes into the data model with "copy as new"), and name them t_user, t_customer_heading, t_product_detail, etc (so as not to mix their names with analysis objects). Same for w_login, w_main_menu, w_cutomer_header, w_customer_detail....

To give you an example: I have a domain model with  country, state, municipality, community, family, person classes, discovered during analysis. In the data model all of these collapsed into t_entity.

Of course, if you are experiencing a very tight schedule, it should be totally valid to use and evolve a single class diagram from start to end, and just convert your analysis classes into tables, and delete collapsed or unused classes from your diagram: just keep the analysis and implementation versions of your EA project under different names.

On how to relate your analysis classes to implementation classes, see:

http://www.sparxsystems.com.au/cgi-bin/yabb/YaBB.cgi?board=general&action=display&num=1034609727

I hope this helps.

Jaime Gonzalez

[andyd]

Thanks to both of you for your comments.
Tjerk, I've not tried hiding relationships with AE.  
Say you were to have 2 class diagrams in a single model, one as an analysis and the other as a design.  

If you were to only display the relationships that you need in the design diagram and generate source from that diagram would AE generate any instance variables to implement the hidden relationships?

A second point is that, I guess you may need to keep going back to the analysis diagram to hide any relationships created during design were not automatically displayed.

It would be nice to be able to keep everything together, but it seems to me that Jaimes idea of keeping 2 different models for the two purposes would be the easiest way.

Thanks guys,

Andy.

[jaimeglz]

Hi Andy,

This is just to tell you how to hide relationships efficiently in an EA diagram: right-click on an empty part of the diagram, click on "Set visible relations", and then uncheck the realtionships you do not want to appear on your diagram. You can use that dialog the other way around: to show hidden relationships.

Works great when copying elements from one diagram to another, or when draggin an existing element into a new diagram, and getting a valid but unwanted relationship for that particular diagram: don't delete it, because this actually deletes the relationship from the whole model; just hide it.

Jaime