This chapter tells you how to achieve separation of concern while retaining control with the overall system.
Divide and conquer is an important concept in all computing practices. If the
problem is too large and complex to be handled as a whole, divide it into a number of manageable subproblems and model each of them as a role model. A role model is complete in the sense that it represents its whole area of concern. We may use it to analyze the described phenomenon to any desired detail.
Several base models may be combined into a composite, or derived, model by the synthesis operation. The phenomenon covered by the derived model is some combination of the phenomena described by the base models, and the derived model is complete in the sense that it represents a whole phenomenon. Synthesis is called
safe when the static and dynamic correctness of the base models is retained in the
derived model, and unsafe if we only retain the static correctness and have to study the derived model to determine its dynamic correctness.
Introduction to synthesis: DerivedTravelExpense (p.104)
The AirlineBooking (AB) model
Creating the DerivedTravelExpense (DTE) model
The synthesis operation (p. 112)
Aggregation: Linking models on different levels of abstraction Safe and unsafe synthesis of the travel example models
Basic OOram concepts and notation for role model synthesis (p. 128)
The Inheritance and Role List views Synthesis in Area of Concern view
Synthesis seen in the Environment and Stimulus-Response views Synthesis seen in the Collaboration view
Synthesis seen in the Scenario view Synthesis seen in the Interface view Synthesis of method Specification view 29 March 1995 23:05
Some useful base models are illustrated in figure 3.1.
Some useful base models Figure 3.1 Models on all levels may be synthesized from simpler base models
User base models Derived classes System design model System requirements models System user model Base classes Design base models System requirements base models
1. The System user model may be composed from more general base models, which we may create as part of our current project or which we may find in a library of reusable components. 2. The System requirements model may be composed from more
general base models, which we create as part of our current project or which we find in a library of reusable components. The System design model describes the system components and their interaction. We would expect that a number of critical design details may be found in a library of reusable design base models (frameworks).
3.
4. The System implementation is a specialization of reusable base classes expressed in library frameworks.
29 March 1995 23:05
3.1 Introduction to synthesis: DerivedTravelExpense
In a nutshell
We illustrate the concept of synthesis through a concrete case. You will see that you can master a complex phenomenon by dividing it into manageable subproblems, and that you can retain control of the whole with synthesis. We would like to challenge you to imagine how you could employ this technology to model your own complex of computer-based systems.
The example we have chosen to illustrate the idea of synthesis is to extend the TravelExpense enterprise (ENT) model with a model of airline ticket booking. We laid a good foundation in section 2.3 when we created a TravelExpense model. In this model, the purchasing of airline tickets appeared as a small comment in the Method definition of figure 2.16 on page 76??. We have several options when we now want to expand the operation: <Traveler purchases the necessary tickets>.
TravelExpense case extension
Extend the TravelExpense model. We can extend the
TravelExpense model as shown in figure 3.2 (a) by adding messages and methods that describe the airline booking operations.
(a)
Synthesize a new AirlineBooking model into the TravelExpense
model. We can create a separate AirlineBooking model and synthesize it into the TravelExpense model as shown in figure 3.2 (b). The TravelExpense model is then extended as in alternative (a), but the AirlineBooking issues are also described in a separate base model.
(b)
Create a new Derived TravelExpense model synthesized from a new AirlineBooking and the old TravelExpense models. We can
create a new AirlineBooking model and then successively synthesize it and the TravelExpense models into the derived model as shown in figure 3.2 (c). We then retain both base models, which can be studied and modified independently; but also get the derived model, where we can study the
interdependencies between the base models. (c)
29 March 1995 23:05 3.1 Introduction to synthesis: DerivedTravelExpense
Figure 3.2 Alternative synthesis
strategies (a) Extend TravelExpense model.
(b) Synthesize AirlineBooking into TravelExpense.
(c) Create a derived model from AirlineBooking and TravelExpense. Derived TravelExpense Derived TravelExpense Extended TravelExpense TravelExpense AirlineBooking AirlineBooking
The first alternative is perfectly viable in this case since even the extended model will be quite simple and manageable. We reject this alternative here because it does not illustrate the issues we want to discuss.
We choose alternative 3
The second alternative is often selected when we want to base our model on a general mechanism. This is not the case here, and we will postpone the discussion of alternative 2 to chapter 5: Creating
reusable components.
The third alternative seems best suited to our purpose. We create two base models, TravelExpense and AirlineBooking, and then combine them into a DerivedTravelExpense model that gives an overview of the total solution. We will develop an AirlineBooking model in section 3.1.1, and then combine it with the existing TravelExpense model in section 3.1.2.
This is often the best alternative. Consider that you have created a model that gives a nice and clean solution to a certain problem. If you then clutter your solution with all the details of error handling, you have lost your nice and clean solution. It is much better to create a separate model of your error handling mechanism, and use synthesis to create a third model that combines the two while retaining the original, clean models if needed.
29 March 1995 23:05 3.1 Introduction to synthesis: DerivedTravelExpense
3.1.1 The AirlineBooking (AB) model
Figure 3.3 AB Area of concern
Airline tickets are ordered by a booking clerk and paid directly to the travel agent. The traveler is to show the cost of the tickets on the expense report as an expense, and as an advance since the tickets were not paid by the traveler.
There is one activity and thus one stimulus message: the ABTraveler begins the activity by sending an orderTicket message. The normal response, i.e., the final result of the activity, is that the traveler receives the tickets and records the ticket costs for later use.
Stimulus Response Comments
ABTraveler >> orderTicket ticketWithCost >> ABTraveler Ticket cost retained in attribute of ABTraveler role
Figure 3.4 AB Stimulus-response view
The essence of this model is the office procedure for handling tickets. We describe it in the scenario of figure 3.5.
Figure 3.5 AB AirlineBooking Scenario AB Traveler AB Booking Clerk AB Travel Agent AB Book Keeper AB Paymaster orderTicket: orderTicket: ticket: invoice ticketWithCost: authorizedInvoice: paymentRequest: payment:
The collaboration view may be deduced from the above scenario view and is shown in figure 3.6.
Figure 3.6 AB Collaboration view ta cust sec tr pm bk ven AB Traveler AB Booking Clerk AB Travel Agent AB Book Keeper AB Paymaster
29 March 1995 23:05 3.1 Introduction to synthesis: DerivedTravelExpense
The precise definitions of interfaces and roles are important, but boring. We hide them within our computer-based OOram tools where the analyst can browse them as needed. The interfaces are shown textually in figure 3.7.
Figure 3.7 AB message interfaces
interface 'ABBookingClerk<ABTraveler'
message 'orderTicket:' explanation "Purchase ticket(s)." param 'ticketSpecification' type 'String'
interface 'ABTraveler<ABBookingClerk'
message 'ticketWithCost:' explanation "Transmitting the ticket(s) together with
cost information."
param 'package' type 'String'
interface 'ABTravelAgent<ABBookingClerk'
message 'orderTicket:' explanation "Reserve specified passages and issue
ticket(s)."
param 'ticketSpecification' type 'String' interface 'ABBookingClerk<ABTravelAgent'
message 'ticket:' explanation "Transmittal of ticket(s)." param 'aTicket' type 'String'
message 'invoice:' explanation "Transmittal of invoice." param 'anInvoice' type 'String'
interface 'ABBookKeeper<ABBookingClerk'
message 'authorizedInvoice:' explanation "Pay this authorized ticket invoice." param 'anInvoice' type 'String'
interface 'ABPaymaster<ABBookKeeper'
message 'paymentRequest:' explanation "Pay this invoice." param 'anInvoice' type 'String'
interface 'ABTravelAgent<ABPaymaster'
message 'payment:' explanation "Transmittal of payment." param 'aCheque' type 'String'