SysML defines neither an architecture framework nor a method. This opens discussions of how to structure the model, what views to build, which artifacts to deliver and in what sequence. Every customer I see deals with the same issue a bit differently. Some use defense architecture frameworks like DoDAF, NAF, MODAF, others use FAS; however, saying there is no need for an architectural framework just doesn’t work. You always end-up using an architecture framework whether you want one or not, or whether you intend to or not.
When analyzing available alternatives, the defense frameworks are considered to be heavyweight, although they do not require using a full set of views, and FAS is not as well-known and or used yet. Option number three is to define your own custom architectural framework (AF). This is what usually happens in reality. There are so many domains in system engineering; it is no wonder the approach for designing different types of systems differs.
In this post, I, being a part of such framework developments in various organizations, defined a pattern (Magic Pattern) for a custom AF based on SysML (see figure 1).
Figure 1. Magic Pattern
One client argued that instead of derivation he would use refinement. So go ahead, I said, it is not against SysML. SysML provides a set of elements; however, it is up to you to interpret their usage in most of cases.
An example of the pattern shown in figure 1 could be a framework consisting of three levels of abstraction (see figure 2):
1. Conceptual – defines the core concepts of the system context and their interactions. The undoubted benefit of views created in the conceptual model is sharing core concepts of the system context between stakeholders.
2. Functional – defines functional analysis from the behavioral perspective, where functions instead of structural units are emphasized. Do not mix this up with the Logical architecture. They are different; however, explaining the difference requires another post.
3. Physical – defines equipment, their physical interfaces and parameters. The physical model is usually a subject for simulation and model-based testing.
Figure 2. Example of Magic Pattern
Figure 2 shows a single possible instance of Magic Pattern shown in figure 1. Each of the architecture models and relationships among them can be represented in SysML using a different set of elements and views (diagrams, matrices, tables, etc.). E.g. functional requirements can be depicted in SysML Requirements Diagram or SysML Requirements Table; conceptual architecture can be depicted in IBD (see my blog post on Conceptual Models in SysML), Use Case diagram, Sequence Diagram etc. See figure 3 for my recommendations.
Figure 3. Architectural Models to SysML Diagrams Mapping
As you can see in the figure 3, the SysML Package Diagram is marked in Grey. This is because it can be created in any architecture model or can be skipped. The purpose of this diagram is to organize the model, thus generally it is created at the beginning and updated afterwards.
The SysML Use Case Diagram is sometimes used to define User Needs. There is a concept of Business Use Case used for such purpose.
Relationships between architecture models are derived from the relationships between model elements, e.g. functional requirement derivation from some user need implies the dependency of the functional requirements model from the user needs model.
Summarizing, it can be clearly seen that there are so many variations of architectures, models, diagrams and combinations of them (note that we have not touched the process yet), that crafting a custom architectural framework is not an easy task. For this reason I will look into use of defense architecture frameworks with SysML in my upcoming post. In my future posts I will also provide some best practice tips and examples for each of the architecture models.
