IBM SG24-7368-00 manual 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-pipedpattern, 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-11shows 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.

66Model Driven Systems Development with Rational Products