Filter
Top Products
Chapter 1. Introduction 13
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.
16
Correspondence with Michael Mott, IBM Distinguished Engineer