Page 231 -

216 PASTOR, MOLINA, AND IBORRA
In MDA terms, we could say that OLIVANOVA Modeler is a tool for the edition and validation
of PIMs. The tool implements a model repository that can be exported to an XML (XML, 2006)
format for interchange with other tools.
As discussed above, an OO-Method conceptual model comprises four model views: objects,
dynamic, functional, and presentation. Thus, the tasks of the analyst typically involve the defini-
tion of the system from these four complementary viewpoints.

Defining the Objects Model View

The first task an analyst takes care of when creating an OO-Method conceptual model is the
definition of the objects model view. This view captures the static aspects of the system in terms
of which entities (classes) comprise the system (e.g., Vehicle, Client, Invoice, etc.), which are the
relevant properties of each entity (e.g., InvoiceNumber, InvoiceDate, InvoiceAmount, InvoicePay-
mentDate, IsPaid, etc.) and the relevant relations between entities (e.g., each Invoice corresponds
to one and only one Client, which can have zero or many invoices).
Integrity constraints can be defined for classes to state the conditions that must be fulfilled
by instances of a class at any time in order to enforce the consistency of the data managed by
the system (e.g., “InvoiceAmount > 0” states that the amount of an invoice must always be
greater than zero and thus prevents the existence of an invoice whose amount is, for instance,
negative).
Once the structure of the data to be managed by the system has been defined, the analyst
typically moves on to define the services (the equivalent to UML operations) that will oper-
ate on that data. For example, in the Invoice class, the analyst will define services such as
“newInvoice” to create an invoice, with arguments “invoiceNo” (invoice number), “client”
(client to be invoiced), “invoiceDate” and “invoiceAmount”; or a service such as “pay” to
mark an invoice as paid, with arguments “invoice” (the current invoice to be marked as paid)
and “paymentDate.”
If the execution of a service requires some conditions to be verified, these preconditions can be
associated to the given service in this objects model view. For instance, if the payment date of an
invoice must be later than its creation date, the analyst would associate the following precondition
to the “pay” service: “invoice.InvoiceDate < paymentDate.”
The complete specification of the objects model view is usually achieved through a series of
iterations before moving on to the definition of the other three views or after a series of iterations
covering the definition of this and the other three views.

Defining the Dynamic Model View

Once the analyst has defined (or after editing or deleting the definition of ) services in the objects
model view, s/he can proceed to define when the occurrence of these services can take place in
the dynamic model view. This is done through the use of State Transition Diagrams that represent
what states are reached by an object upon the execution of a service on it, depending on which
state that object is in.
For instance, when an invoice is created upon the execution of its “newInvoice” service, that
invoice reaches the “Unpaid” state. The execution of its “pay” service will change the state of that
invoice from the “Unpaid” to the “Paid” state. An invoice can be destroyed either when it is in
the “Unpaid” or in the “Paid” state, but it cannot be paid again if it is already in the “Paid” state.
This example is illustrated in the (partial) state transition diagram in Figure 11.6.