Looking through tutorials and support and cannot find anything regarding best practise to ensure best use of the tool and the models/projects we create, particularly around structure/folders and components/instantiation/inheritance. Can anyone point me in the right direction. Questions I am hoping to have answered:
1. Should I create 'master' component building blocks once only in a library somewhere
2. Should I just have these master components used in diagrams using a link or instantiation?
3. How does instantiation work, what does it really mean in terms of inheritance? I want to make sure I don't have five different versions of the same thing and have my users get in a pickle.
4. When instantiating a component, tags come through, requirements do not. What is going on?
5. If I don't use instantiation and only linking, my gap analysis matrix don't work, as the components are not technically present on my TO BEs
6. If I use instantiations for a TOBE state, how do I then promote these when they become ASIS?
There are all sorts of complications here and none appear to be described (that I can find). Really appreciate any pointers.
Hi There,
This is a common question I get a lot in our teaching. There are some general tips to deal with the situation you describe but as the other replies indicate, the diversity of Sparx EA means that the structure/use of the tool needs to be informed by your goals/purpose (ie., there is no universal approach for all situations).
Here are some tips opposite your questions:
Q. Should I create 'master' component building blocks once only in a library somewhere.
A. If you are wanting to use component models to describe a centrally maintained single source of truth then yes. A typical approach is to create a root node/model in your repository that becomes a central filing system for your model and typically holds the as-is state of an architecture.
Q. Should I just have these master components used in diagrams using a link or instantiation?
A. This depends on what you are trying to do. I use instantiation only when I am depicting a run-time simulation (i.e., a scenario or example of a pattern). If I am describing structural relationships or other associations, I use a link (i.e., I want to add more complete information to the original component). Remember that information you add to an instance does not get transfered back to the original classifier (instances remain stand-along objects albeit with traceability back to the classifier).
3. How does instantiation work, what does it really mean in terms of inheritance? I want to make sure I don't have five different versions of the same thing and have my users get in a pickle.
- Instantiation and inheritance are fundamentally different concepts in UML. Instances of model elements are just that, instances or "examples of" the original component. Working with instances in Sparx requires that the modeler explicity set the run states/run-time information on the component (e.g., a class is not instantiated with all of its attributes automatically visible with values). Only use instances when the item you are working with represents a "template" that you want to exemplify.
4. When instantiating a component, tags come through, requirements do not. What is going on?
Instances is a UML-based construct in sparx. Thinks like requirements and linked docuements are tool extensions (non-UML) and do not become instantiated. This is intentional as it would become complex/confusing if every instance of a component were to carry a copy or relationship to the underlying requirements.
5. If I don't use instantiation and only linking, my gap analysis matrix don't work, as the components are not technically present on my TO BEs
- I haven't used the gap analysis matrix to generate gaps, however, there shouldn't be a restriction on element type you describe. (i.e., you are not required to use instances to use the gap analysis matrix, you can do it with components/classes..etc.).
6. If I use instantiations for a TOBE state, how do I then promote these when they become ASIS?
- Don't use instances to represent the same component in different states of your architecture. If you want to model multiple "branches" of the same model element at different states (without disturbing the As-Is element at all), you need to manage redundancy in your model and refactor the changes back to the as-is state. Most modellers manage this manually, however, you could use model baseline/merge/compare facilities to accomplish this as well.
