Filter
Top Products
40 Model Driven Systems Development with Rational Products
MDSD Step 1: Define the system context
Defining the system context is the first step in the MDSD process.
2
First of all, we
define the context of any system to be an enterprise. If we consider the system to
be level 1 in system decomposition levels, then the enterprise is level 0. As noted
before, this also applies more generically—the entity under consideration, our
system is level n in some hierarchy of system decomposition, and our enterprise
is level n-1.
By examining the enterprise, its goals, and its components, we will understand
the system in its context. The goals of an enterprise will be realized by its
collaborations with external entities and supported by the collaboration of internal
components. These internal components (or entities, to use a slightly less
overloaded term) will collaborate through a set of enterprise operations to
support the enterprise’s collaboration with its enclosing context. Any enterprise
operation that our system under consideration participates in will in fact be a
candidate, if not an actual, system use case. To determine what the enterprise
operations are, we must analyze the enterprise’s use cases and actors. In other
words, we must understand the collaboration of the enterprise with its actors to
discover its operations. These operations lead to system use cases. Additionally,
the other internal entities of the enterprise are usually our system’s actors.
Actors and boundaries
In the following sections we discuss discovering actors and use cases as part of
understanding the context of the system under consideration.
MDSD Step 2: Finding actors
After choosing an entity in your MDSD model, the next step is to find actors for
this entity.
3
Actors represent the roles played by entities (either a person or
another system) in relation to the entity under consideration. By definition, they
are outside the entity and interact with it.
For example, if we are building a guidance system within a commercial aircraft,
and the aircraft is our entity, then it is likely the passengers would be its actors,
while the captain and crew can be represented as part of the aircraft, and thus
are not actors. To be a little more exact, we are not representing the passenger
as an actor, we are actually representing the passenger role. Actors represent
the roles played by people and outside systems in relation to our entity. Other
actors for the commercial aircraft might include the control tower, regional air
traffic control center, and the ground crew.
2
See also Task: Define the system context in the Rational Unified Process (RUP) v7
3
Ibid, Task: Find Actors and Use Cases