Page 232 -

OO-METHOD 217
Figure 11.6 Partial State Transition Diagram for Class Invoice

editInvoiceData

newInvoice deleteInvoice
Unpaid

pay
deleteInvoice

Paid

The analyst can also define the interobject communication aspects of the system in this dynamic
model view, which in this case is supported by the graphical notation of UML communication
diagrams.
For instance, in order to support the requirement that the creation of an invoice must always
result in sending a notification to the invoiced client, the analyst decides to create a global service
name “InvoiceClient” to encompass the execution of the “newInvoice” service of class “Invoice”
with the execution of the “notify” service of class “Client” in a single execution unit. Figure 11.7
illustrates the communication diagram for the “InvoiceClient” global service, where these two
atomic services are used to specify the resultant global service.

Defining the Functional Model View

As in the case of the dynamic model view, once a service has been added or edited for a class, the
analyst can move on to define how the execution of that service will change the state of the object
(in terms of the values of its attributes) on which it is executed. The definition of the functional
model view does not have to take place after the definition of the dynamic model view, the only
real prerequisite is that the related services must have been defined or edited previously in the
objects model view.
As discussed above, services can be events or transactions, that is, atomic or molecular execu-
tion units; and the analyst can define how the occurrence of events changes the value of attributes
of a class in the functional model view. The dynamic logic axioms used for that purpose do not
have a graphical notation, but rather a textual, object constraint language–like one. Each of these
dynamic logic axioms, called valuations, relates an attribute and an event of a class in order to
state the value that this attribute will have when the event occurs.