Organisation of diagrams and elements?

[serethos]

Hello,

I am struggeling with the general organization of my diagrams. Please imagine the following situation:
I have a new Model which is the root node for all my diagrams of a given task. Now I create a "Class View"
which will host any class structures. It could look like that in the project browser:


MyProject Payment
    Payment Classes  <class view>
       pamentPackage <package>
         Payment Class Diagram <diagram>
         MyClass1    <class>
         MyClass2    <class>
         ...

Now I want to create several Object Diagrams for different cases but all using the mentioned classes.
First I thought it was a good idea to put the objects into the same package/view as the classes to have
a class-oriented view in one place:

MyProject Payment
    Payment Classes  <class view>
       pamentPackage <package>
         Payment Class Diagram <diagram>
         Payment Object Diagram <diagram>
         MyClass1    <class>
         MyClass2    <class>
         :MyClass1   <object>
         :MyClass1   <object>
        
But this has disadvantages:

- If I create several object diagrams cases using a similar set of objects, they are not structured but
all mixed on the same level

- In general, anonymus objects (having no name, but only the type like :MyClass) can not be distincted.
In some cases I do not want to give them names, but anyway need a way to differ them within the project browser

The only ways I see is either to use packages or one view per diagram case. To put all elements of a case
into a package does not work, because nonetheless there can be multiple cases to picture belonging to the same
package. So sometimes I tend to abuse packages (in sense of programming units) as folders (in sense of structuring
the project tree).
The second way would be to use one view per diagram/case..

Can anyone explain to me a good organisation of such projects?

[Geert Bellekens]

Serethos,

You are not abusing packages, but merely using them for what they are designed: to structure your model.
From UML superstructure 2.3

A package is used to group elements, and provides a namespace for the grouped elements.

So nothing wrong with using packages to group the objects needed to express certain situations.

Geert

[Paolo F Cantoni]

[size=18]...[/size]
From UML superstructure 2.3

A package is used to group elements, and provides a namespace for the grouped elements.

[size=18]...[/size]

The problem for us modelers is that there are many ways to group the same set of elements, but there is only one way to create a namespace for an element.

Unfortunately UML used/uses the concept of a container (package) to describe a classification (namespace).

While a classification IS a grouping (of all the elements with the parent classification) it is only one of many.

Oh well...

Paolo

[mperry247]

Help

Can anyone tell me why I can't use the advanced properites option 'show composite diagram' in a BPMN 1.1 diagram.

[paulourada]

Still flogging this horse, Paolo? Good! Keep it up!  

I'm a little late to this particular party, but I have been complaining about this type of issue for many years. Sparx's competitors allow many options for organizing projects, including allowing package specifications which are not part of the namespace structure. For some reason Sparx has decided to more closely toe the UML party line.

In my work, we have just two namespaces: One for a framework, and one for the application which uses the framework (OK mulitple applications, but only one app namespace per project). But there are many domain packages and each have multiple component packages. And under the component packages we like to split out test code into a separate test package. If we were to put all these domains and packages into the namespace specification under the root, things would get ugly but fast. Using statements help, but can be confusing. (C++ is the language of choice for us.)

So, for us it's enough separation to have Framework::MyClass and App::MyClassDerivative types of structures. And we have about 2200 classes in the framework alone. Without some sort of organizing feature such as a "folder" or other non-package, or a tag that specifies a package not be in the namespace, how can you get multiple developers to work on the same model? You have to lock things somehow. We can't have 2500 classes all under one package.

I have tried modifying the code generator, and I can get it to spit out code which ignores all the sub-packages in the namespace specification. However, when I try to sync the same code, the diagram editor thinks that I am syncing a different class, causing IsA or sub-classing type of relationships disappear from the diagram. This is directly due to the fact that the namespace specification of the synchronized class or element is not what EA expects from the package structure in the EA project.

It's bad enough trying to get colleagues to adopt good design practices, but when I can't get the tool to do something simple as not include a package in the namespace, and then they try to sync and the diagrams don't follow suit, they just give up and our process goes to hell.

The point is that it is one thing to attempt to adhere to a standard. It's quite another to hamstring your users with it.

GAH!  

I really like EA in most respects, but we're having to seriously consider moving to a more expensive product @ IBM.

Paul Ourada