Page 220 -

OO-METHOD 205
In the following, we present the specific aspects of this approach in more detail.

OO-METHOD

OO-Method is a software development methodology that is based on a clear separation between
the problem space (what we want to build) and the solution space (how are we going to build it).
The definition of a problem (the abstract description of a system, represented in the corresponding
conceptual schema) can be enacted regardless of any particular reification (concrete implementa-
tion of a software solution). This positions OO-Method as a sound methodological foundation on
which to build tools that embrace the MDA directive of separating the logic of software applica-
tions from their (multiple) possible implementations.
The formalism underlying OO-Method is OASIS, which is a formal and object-oriented speci-
fication language for the specification of information systems (Pastor, Hayes, and Bear, 1992).
This formal framework provides a characterization of the conceptual elements that are needed to
accurately specify an information system. It encompasses two main components: the conceptual
model and the execution model.

Conceptual Model

The conceptual model comprises four complementary views: the objects model, the dynamic model,
the functional model, and the presentation model. All of them together constitute the whole conceptual
schema specification. These four views allow the definition of all the functional aspects of a system
in an abstract (implementation-independent) yet accurate fashion by means of a set of conceptual
elements (which we refer to as conceptual primitives or conceptual patterns) with a precise semantics.
Most of these conceptual patterns have a UML-based graphical notation, which hides the complexity
and formalism of the underlying OASIS formal specification from the developer.

Objects Model
The objects model comprises a class diagram that graphically describes the structure of the system
in terms of its classes with their properties and structural relationships (generalization, association/
aggregation), thus providing a static view of the architecture of the system.
Classes have attributes of three kinds: constant attributes (those that get a value when the class
is instantiated and do not change), variable attributes (those whose value can change during the
lifetime of objects), and derived attributes (those whose value is calculated from the values of
other attributes). In order to specify how the value of a derived attribute is calculated, a set of
well-formed formulas called derivations can be defined.
Classes also have services, which define the signature of operations that can be invoked upon
objects. Services, like “operations” in UML, have arguments or parameters but also fall into two
categories: events, which are atomic execution units; and transactions, which are molecular execu-
tion units that encompass other services (either events or transactions).
Events, in turn, can be stereotyped as “new” (those whose semantics is that of creating a new
instance of the class, assigning a value to each of its properties and relationships) and as “destroy”
(those whose semantics is that of destroying an instance of the class and breaking relationships
with related instances or cascade-destroy related instances, depending on the features of each
relationship). Figure 11.1 shows an example of the graphical notation in the class diagram for a
class with attributes and services. The semantics of events that are not stereotyped as “new” or
“destroy” are defined in the functional model.