Filter
Top Products
Chapter 8. Conclusion 179
We measure the effectiveness of the behaviors or functional requirements
against the goals and larger concerns of the system, at the same time ensuring
that the constraints are met.
The goals, constraints, and desired behaviors drive the system architecture. We
postulate an architecture (or set of architectures) and then design and test
against the goals.
Next, we analyze collaborations.
MDSD suggests that a breadth-first collaboration based approach across
multiple viewpoints will be more effective than a traditional depth-first functional
decomposition in creating an architecture that will not only meet the
requirements, but will prove to be more resilient in the face of inevitable change.
We can analyze collaboration both from a black-box and a white-box perspective.
Having gained an understanding of the system's context, we postulate an
architecture, a structure or set of structures, that will realize the system's
requirements. We break open the black box, and look at the system as a white
box (yet another transformation). We decompose the system into pieces,
understand how the pieces work together to meet the black-box requirements,
thereby deriving requirements on the pieces. Through all of this, we integrate,
refine, and refactor as we go, seeking to provide resiliency and avoid brittleness.
The collaboration seeks to realize requirements, which have been formulated
from the larger set of concerns.
MDSD also seeks to provide an effective distribution of responsibilities across
resources—joint realization and abstractions such as localities provide an
effective and elegant way of accomplishing this.
Finally, the ability to attach attributes and values to modeling entities and the
parametric capabilities of SysML allow us to provide a basis for doing simulations
or other models to meet cost, risk, and other concerns. While we have only
touched upon this concept in this publication, it is clearly a future direction that
we look forward to developing.