My understanding of Capella is that its goal is to enable the user to create and design a System Architecture following the Arcadia method using graphical modelling. Thus, creating, editing and transitioning models using the “Activity Explorer” is essential.
However, a lot of functionality is hidden in context menus or even in non-graphical model editing tools.
For example, scenarios cannot be transitioned between Arcadia steps (OA, SA etc.) using the “Activity Explorer” which would lead to an invalid model as the scenario is not realized or represented in later steps. The transition can only be triggered by right-clicking on the Arcadia step in the project explorer and then choosing the appropriate option under “Transitions” (where all “missing” transitions are hidden).
Furthermore, not all elements of the Arcadia language can be created using the diagrams, but need to be created using Ecore model editors or context menus in the project explorer. An example for this are Operational Entity Packages (or System Component Packages and so on). Is Capella meant to be used purely graphically or is it to be used similar to vanilla EMF models using Ecore editors or programmatically?
I would greatly appreciate your opinions on this topic!
With best regards,
Not answering all your question but:
“My understanding of Capella is that its goal is to enable the user to create and design a System Architecture following the Arcadia method using graphical modeling.” -> Generally yes, but graphical is not considered the only way of system architecture models. For example, you may also use matrixes, or in Labs for Capella, there is an add-on that provides some textual editing features.
“Thus, creating, editing, and transitioning models using the “Activity Explorer” is essential.” -> I would say that the Activity Explorer is central. It is a way to navigate in the Arcadia method and in your model. More generally, the fact that Capella implements the Arcadia methods enables the provision of extended tooling that eases modeling activities. This makes Capella a very rich environment. Capella is certainly not limited to what you see in the Activity explorer. As you are saying, some features are only available in contextual menus. Because these features are actually contextual. I understand this may look like they are hidden. But in the end, they are documented, that’s what makes the beauty of Capella, it has a nice learning curve where you can start using it as a basic user, and as you learn more about Arcadia and Capella, you realize that there are more features that becomes useful.
I would make a third point, which is probably the most important: there are a lot of different ways of using Capella. When you start with Capella, you may get the feeling that the Activity explorer guides you in a way of using Capella, from the OA to the PA, which each step and sub-steps. But this is not how Capella is used most of the time. Capella gives you a modeling framework for System Architecting, but the end game is not making a system architecture, the end game is better systems engineering. So depending on the context of your project, the engineering pain you want to tackle using Capella, you’re going to use a subset of Arcadia and Capella. For example, let’s say your project is about modernizing an existing system. You’re probably not going to start by the OA, but rather by using the PA to reverse-engineer your existing system. There is some tooling in Capella that supports these types of activities. You may consider these features as hidden. The bottom line is that it requires some experience to know what’s the best way to use Capella and Arcacia for a given context and what tooling is available to help you in this process.
I hope this helps.
Related to your third point, it seems that you do not need to go all the way from OA to PA for every project. If I start out at either SA or LA, will there be any issues with model validation if the upstream phases have not been completed?
I ask because OA has been viewed as an academic/abstract exercise by some people I’ve tried it with, especially if we already have an idea of what capabilities and functions the system needs to do. So, an option to skip ahead for some projects would be ideal.
Well, you will for sure get errors from model validation if things are missing in the OA perspective, but validation rules are not here to run all of them, one should think about selecting the right ones that apply to a given project and share this rule selection with other team members. In other words, in your case, just deactivate all validation rules that are linked to using the OA (including OA-SA traceability). This can be done in the preference window if I am not mistaken.
Several comments about this topic:
I completely agree with Stephane’s third point. From my personal experience, most projects use 2 or 3 Arcadia perspectives, very rarely all 4.
For me the activity explorer is just a helper; it suggests building different types of diagrams depending on what you want to do (what activity) and suggests an order of activity. But personally, I don’t follow the suggested order but it was very helpful the first time I used Capella.
Indeed, you can activate/deactivate certain validation rules from the Preferences Model Validation/Constraints window (by default, some validation rules are deactivated). You can also create validation profiles in which you define the validation rules you want to apply (search for Validation Profile in the online help).
Be careful to use the automatic transition from one Arcadia perspective to another Arcadia perspective wisely. For example, it doesn’t make sense to automatically transit from the operational activities to the system functions: the former are seen from the perspective of the operational actor/entity, the latter are seen from the perspective of the system and should not have the same names. Moreover, it is likely that some operational activities will not be performed by any system function. But the automatic transition can be useful to:
- avoid the white sheet
- help to take account what was defined in the previous Arcadia perspective
- in some cases, to have a low cost traceability