Core processes of model-driven systems development
Model-driven systems development is essentially a simple process, but no less powerful because of its simplicity; in fact, we believe its elegance and simplicity contributes to its power. Furthermore, it is correct in that it is constructed from first principles. It starts with the definition of a system and then provides constructs for defining each of the parts of the system. It also provides an underlying meta model to maintain coherence of the model design as a team reasons about the various parts of the system.16
Model-driven systems development is an extension to the Rational Unified Process (RUP). As such, it has a well defined set of roles, activities, and artifacts that it produces. Furthermore it exists as a plug-in for the Rational Method Composer (RMC). Within the context of the Rational Unified Process, however, its essential simplicity is not necessarily immediately apparent within the phases, work flows, and activities. One of the goals of this document is to demonstrate its essential simplicity and power.
The various activities of MDSD are centered around three goals:
Defining context
Defining collaborations
Distributing responsibilities
These activities are carried out at each model level, and at each level of system decomposition. As noted previously, MDSD is a recursive or fractal process—this is part of what makes it simple and powerful.
Defining context
Confusion about context is one of the prime causes of difficulty in system development and requirements analysis. If you are not sure what the boundaries of your system are, you are likely to make mistakes about what its requirements are. Lack of clarity at this point in the development process, if carried through to deployment of the system, can be extraordinarily expensive—systems get delivered that do not meet the expectations of their stakeholders, or faults occur in expensive hardware systems after they have been deployed, and have to be recalled, redesigned, and redeployed. Or the system never gets deployed at all, after millions of dollars have been spent in its development.
Defining context means understanding where the system fits in its enterprise, domain, or ecosystem. Understanding context in a system of systems also means understanding where the various pieces of the system fit and how they relate to each other.
16Correspondence with Michael Mott, IBM Distinguished Engineer
