One of the most difficult areas of defining or understanding context is being aware of context shifts, especially in systems of systems. A context shift occurs when you go from talking about a system within an enterprise to talking about one of its subsystems. At that point, you are considering the subsystem to be a system in its own right. It will have its own set of actors, likely to be other subsystems of the original system under consideration. It is important to manage these context shifts carefully, and to keep straight where in the system you are at a particular point. Technically, we call this set of levels within the system its decomposition levels.17 An explicit transformation between black box and white box views are one of the ways MDSD manages this context shift.18
Understanding the intended usage of a system is one of the most powerful means of analyzing it and its requirements effectively. Usage drives the functional requirements for the system. What we want the system to do determines its functionality. In MDSD, use cases represent the most important usages of the system. Use cases help define the context of the system; use cases also help put other related requirements into a context.
An essential set of artifacts is produced as we reason about context at any level:
Context diagram
Use case model
Requirements diagram (optional using SysML)
Analysis model
Defining collaborations
Brittle,
Scalability is achieved through system decomposition and operational analysis.19 The interaction of a set of systems at any given level of abstraction or decomposition determines the interactions of subsequent levels.
Essential list of artifacts:
Sequence diagrams
Analysis model
Package diagram/overview of logical architecture
17See the aforementioned citation (footnote 15).
18See Chapter 2, “Transformation methods” on page 28, and discussion in Chapters 3 and 4.
19Ibid.
14Model Driven Systems Development with Rational Products
