My take away from EA literature is a Root/Model(s)/View(s) is a recommended practice to start with:
- Root
+ Model X
+ View A
+ View B
+ Model Y
This is supported by the following:
http://www.sparxsystems.com/enterprise_architect_user_guide/12.0/modeling_basics/uml.htmlModels - a model is the highest conceptual level, representing a distinct and complete representation of all or some part of a modeled system.
A Project can contain multiple models.
Views are the second level within a model and define a specific viewpoint of the system being modeled - for example a Use Case view, a Requirements View or a Dynamic (behavioral) View.
Views are simply Packages that have an additional conceptual meaning.
I assume the usage of 'View' is intentionally consistent with ISO 42010
https://en.wikipedia.org/wiki/ISO/IEC_42010, but as I understand it Views do not define a specific Viewpoint. Instead Views conform to a Viewpoint (i.e. perspective) and a View does not define a Viewpoint in and of itself. (Is this a doc bug Sparx?)
If you apply something like 4+1
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model you (theoretically) have 5 Views (as packages) per model.
This sounds like a decent way to start. Rationale: Minimal package hierarchy is easier to navigate and intuitive to use. The views are based on industry standards.
I stumbled on this presentation on a projects use of EA which shares another approach:
https://www.fbcinc.com/e/nlit/presentations/Monday/How_One_Project_at_Sandia_Labs_is_Using_Sparx_Enterprise_Architect_to_Create_Model-Driven_Requirements_and_Documents_(SF)_-_Meeks_20150420_x.pdfI liked the idea of having diagrams nested under each use case, but not all diagrams nest so well (in my experience thus far) and this doesn't follow the 'view' convention.
I recently tried using the Systems Engineering Model
http://sparxsystems.com/enterprise_architect_user_guide/12.1/systems_engineering/systems_engineering_modeling.htmlwhich is outlined like so:
This ended up being a bit cumbersome to navigate. Note: Cumbersome to navigate does not mean don't do it. I expect users utilize EA's 'Model View' feature to effectively navigate complex models.
http://sparxsystems.com/enterprise_architect_user_guide/12.1/building_models/model_views.htmlI also observed the built in html export is per root node, so if this is important to you it should be taken into account. In my case, I included all items we may want to export together under one root node.
In summary, three approaches are discussed in this comment:
1 Systems Engineering Model Structure
2 Sandia Labs Model Structure
3 Basic Model, View Structure
Today I am opting for #3 to try next. The approach I am taking is each Model package represents a Viewpoint (see 42010 reference above) of the system and not a Project as in your example. In general Views can be applicable to more than one Viewpoint, so this is not foolproof, but I am thinking this is good enough and a good place to start.
