This is a benefit of an MDSD
Having now determined our set of candidate operations, by producing sequence diagrams for all use cases (including alternate flows), we now move to the next major step, during which we will produce a consistent, optimal set of operations.
Refactoring operations
Here we consider refactoring and consolidating operations.
MDSD Step 8: Refactoring and consolidating enterprise operations
It might seem that we have determined all of the operations necessary for an entity to fulfill all of its use cases, but there is one final step. In most situations, we find that due to the elapsed time it takes to create a complete use case model, and the fact that usually multiple modelers are involved, we must ensure that the operations determined from the analysis of the entire collection of use cases do not include redundant or overlapping operations.
To do this, review the list of operations that you have identified from analysis of all the entity’s use cases. Look for any operations that might be similar but named slightly differently. For example, if in one use case an operation was identified called
In the early stages of an MDSD model, you can expect lots of this kind of refactoring and rethinking of the model.
More about operations
Now that we have identified the set of operations necessary to fulfill (or accomplish) the use cases, let us look more closely at what an operation is and what it represents in an MDSD model. Operations are like use cases, in that they are flows of events that accomplish something. In addition, they do show primarily interactions between system elements and actors, while hiding functionality internal to those elements.
Chapter 3. | 65 |
