Newy,
What I'm trying to say is that you create the structure to suit yourself, or preferably to suit the goals of producing your models.
Consider there three interconnected aspects of "tool assisted" systems alaysis and design:
- the tool, which supports
- the model notation, which is driven by
- the methodology
EA is the tool that supports the notation. In this case, UML 2.0! EA is very flexible and can be used with essentially any UML based methodology. Your chosen methodology will specify a set of artifacts that together, and over the life of the project, describe the system to the audiences of those artifacts.
You have already noticed that EA lets you put any UML element into any diagram. This is consistent with UML. Even though the diagram "types" have names that indicate that they should be constrained to a specific subset of UML elements there is no constraint that says you cannot put a class element (for example) into a use case diagram (for example). The only question is whether it makes sense to do so. Certainly the primary elements that make up a use case diagram are actors and use cases, but if adding a "non-usecase" element
adds to the value of the diagram then the tool should not constrain nor prevent you from adding that element. By way of example, consider a plumbing diagram for a high rise building. If there are non-plumbing elements of interest to the plumber (or his safety) such as high voltage feeders concealed in various parts of the plumbing core, doesn't the building drawings include some indication of those things on the plumbing diagrams?
Similarly, when we consider how to structure the elements in the project tree, i.e. in views, packages, sub packages etc this is again a matter of doing in a way that supports the way you are working. The instructions for how to use an electric hammer drill will tell the carpenter how to use the drill but wont tell him where to put the holes in the walls, nor do they tell him how to arrange the anchor bolts in his tool chest.
So, again what I am saying is that the structuring of UML (notation) models inside EA (tool) repositories is a matter of personal choice guided by what you are trying to achieve and how you are going about it.
As I work for a "large" organization, which uses various UML based tools, we have the following goals that affect how we arrange our model structures:
1) all UML system designs should be interchangeable between tools;
2) as project team members
often move between teams it is important to us that all models have a very similar structure;
3) as, usually, the number of stakeholders in a project tends to the "large" end and therefore stakeholders are likely to be exposed to more than one project at a time it is important that system models have similar look and feel and that they are all syntactically similar.
For these reasons, we spent a significant time getting that structure "correct" for the orgainsation. It is very rigid and formally specified.
Other people on this forum work in very different environments. Some, where for example the team size is small,or where the useful lifetime of a model is short, get much more benefit through (I expect) a much less formal arrangement of model structure - possibly down to and including a completely flat structure consisting of one package or view containing all elements.
In the final analysis, IIWY I wouldn't worry too much about how you should be formally structuring the models until you have a few iterations of a few systems under your belt. Concentrate on getting value out of the models that you make not on doing them "by the letter of the law" ( and by now you should realise there is no real L-A-W law anyway).
Look more at using a method and see if you can "get through" a simulated project. Try several if you have time and decide which method is best for you in which situation. Understand the critical artifacts of the method, what they are used for and whether the models you are producing are structured to support the delivery of those artifacts.
Last century, when I started in working in this here komputer game, the only tool we had was a plastic flowchart template - and by jimminy, the help file for them was pretty useless
- but we survived, learnt and went on to bigger and better things.
hth
Bruce
