Filter
Top Products
66 Model Driven Systems Development with Rational Products
They are unlike use cases in that they are not complete system usages, but are
more atomic. Operations also
run to completion, meaning that once invoked,
they continue until they are finished (or fail) without requiring the actors to invoke
any further operations. If there were a need for an additional operation invoked by
the actor, that would be the end of this operation and the start of another.
Operations can have interactions with other elements and actors as they run, but
have only a single invocation by the element or actor who invokes them.
For example, when I request my car to start by turning the key in the ignition, the
car starts, or does not, with no further interaction with me. The car can have
additional interactions with other actors, say a GPS satellite, in the course of
starting, but it runs to completion without needing me for anything. Based on how
we derive operations using sequence diagrams, this run to completion feature
takes care of itself—no special attention to it is necessary.
In an optimal system architecture, we would expect operations to be used in
more than one use case. We would also expect most use cases to need more
than one operation for their fulfillment. There are exceptions. A use case in which
the system interacts only with its initiating actor, and only once at initiation of the
use case, would be accomplished by a single operation.
If no operations participate in collaborations for multiple use cases, then the
architecture might be taking a
stove-piped pattern, which is usually non-optimal.
For example, if I ended up with a separately implemented customer information
subsystem in each of my enterprise applications, I have probably failed to
achieve good optimization. At the same time, if accomplishing a use case
involves many rapid interactions between system elements, performance might
suffer. MDSD does not solve this automatically. If it did, human architects would
be unnecessary! MDSD does provide a way to reason about these kinds of
trade-offs. The objective is to create an optimal set of operations for an entity,
and, as we will soon see, other elements within it.
With operations in hand, we can proceed to the next decomposition level of the
system.
Figure 3-11 shows a completed context diagram with the entity under
consideration, its actors and I/O entities, and entity operations. Note that there is
a significant amount of information in this diagram: we have a better sense of the
boundaries of the entity, we have a better understanding of what functionality it
must provide, and we have a high level view of what information gets passed
between the entity and its actors. In other words, we have a better understanding
of its context.