Executable UML
Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change.
Physically, an Executable UML specification comprises a set of models represented as diagrams that describe and define the conceptualization and behavior of the real or hypothetical world under study. The set of models, taken together, comprise a single specification that we can examine from several points of view. There are three fundamental projections on the specification, though we may choose to build any number of UML diagrams to examine the specification in particular ways.
The first model identifies, classifies, and abstracts the real or hypothetical world under study, and it organizes the information into a formal structure. Similar "things," or objects, in the subject matter under study are identified and abstracted as classes; characteristics of these objects are abstracted as attributes; and reliable associations between the objects are abstracted as relationships.
Concept |
Called |
Modeled As |
Expressed As |
the world |
|
|
|
is full of things |
data |
Classes |
UML class diag |
|
|
attributes |
|
|
|
associations |
|
|
|
constraintsram |
|
things have lifecycles |
control |
States |
UML statechart diagram |
|
|
events |
|
|
|
transitions |
|
|
|
procedures |
|
things do things at each stage |
algorithm |
actions |
action language |
NOTE
Operations do not appear explicitly as entries in Figure 1.1 because Executable UML derives operations from actions on state machines.
Invoked actions may be shown as operations on classes, but their existence is normally dependent on the invocation that occurs in a state machine.
Figure 1.1 Concepts in an Executable UML Model
fie express this first model using a UML class diagram. The abstraction process requires that each object be subject to and conform to the well-defined and explicitly stated rules or policies of the subject matter under study, that attributes be abstractions of characteristics of things in the subject matter under study, and that relationships similarly model associations in the subject matter.
Next, the objects (the instances of the classes) may have lifecycles (behaviors over time) that are abstracted as state machines. These state machines are defined for classes, and expressed using a UML statechart diagram. The abstraction process requires that each object be subject to and conform to the well-defined and explicitly stated rules or policies of the world under study, so each object is known to exhibit the same pattern of behavior.
The behavior of the system is driven by objects moving from one stage in their lifecycles to another in response to events. when an object changes state, something must happen to make this new state be so. Each state machine has a set of procedures, one of which is executed when the object changes state, thus establishing the new state.
NOTE
Executable UML is a single language in the UML family, designed for a single purpose: to define the semantics of subject matters precisely. Executable UML is a particular usage, or profile, the formal manner in which we specify a set of rules for how particular elements in UML fit together for a particular purpose.
This book, then, describes a profile of UML for execution.
Each procedure comprises a set of actions. Actions carry out the fundamental computation in the system, and each action is a primitive unit of computation, such as a data access, a selection, or a loop. The UML only recently defined a semantics for actions, and it currently has no standard notation or syntax, though several (near-)conforming languages are available.
These three modelsthe class model, the state machines for the classes, and the states' proceduresform a complete definition of the subject matter under study. Figure 1.1 describes the concepts in an Executable UML model.
In this book we will informally make use of other UML diagrams, such as use case and collaboration diagrams, that support the construction of executable UML models or can be derived from them. We encourage using any modeling technique, UML-based or otherwise, that helps build the system.