A
system is composed of multiple subject matters, known as
domains in Executable UML terms. Executable UML is used to model a domain at the level of
abstraction of its subject matter independent of implementation concerns. The resulting domain model is represented by the following elements: • The
domain chart provides a view of the
domain being modeled, and the dependencies it has on other domains. • The
class diagram defines the
classes and class
associations for the domain. • The
statechart diagram defines the
states, events, and state transitions for a class or class instance. • The
action language defines the actions or operations that perform processing on model elements.
Domain chart Executable UML requires identification of the domains (also known as:
aspects or
concerns) of the system. "Each domain is an autonomous world inhabited by conceptual entities" Each domain can be modeled independent of the other domains in the system, enabling a
separation of concerns. As an example, domains for an automated teller system may include the following: • The application domain model of the automated teller's
business logic. • The
security domain model of various issues regarding system security (such as
authentication and
encryption). • The data access domain model of methods for external
data usage. • The
logging domain model of the various methods through which the system can or must log information. • The
user interface domain model of the user interactions with the system. • The
architecture domain model of the
implemented of the Executable UML model on the system's
hardware and
software platforms. The
separation of concerns enables each domain to be developed and verified independently of the other domains in the system by the respective domain experts. The connections between domains are called
bridges. "A bridge is a layering dependency between domains". This means that the domains can place requirements upon other domains. It is recommended that bridges are agreed upon by the different domain experts. A domain can be marked as
realized to indicate that the domain exists and does not need to be modeled. For example, a data access domain that uses a
MySQL database would be marked as realized.
Class diagram Conceptual entities, such as tangible things, roles, incidents, interactions, and specifications, specific to the domain being modeled are abstracted into
classes. Classes can have
attributes and
operations. The relationships between these classes will be indicated with
associations and
generalizations. An association may require further abstraction as an
Association Class. Constraints on the class diagram can be written in both Action Language and
Object Constraint Language (OCL). The Executable UML method limits the UML elements that can be used in an Executable UML class diagram. An Executable UML class diagram is meant to expose information about the domain. Too much complexity in the statechart diagrams is a good indicator that the class diagram should be reworked.
Statechart diagram Classes have lifecycles which are modeled in Executable UML with a
statechart diagram. The statechart diagram defines the
states,
transitions,
events, and
procedures that define a class' behaviour. Each state has only one procedure that is executed upon
entry into that state. A procedure is composed of actions, which are specified in an action language.
Action language The class and state models by themselves can only provide a static view of the domain. In order to have an executable model, there must be a way to create class instances, establish associations, perform operations on attributes, call state events, etc. In Executable UML, this is done using an action language that conforms to the UML Action Semantics. Action Semantics was added to the UML specification in 2001. The Action Semantics RFP was based on previous work in action languages supporting the
Shlaer–Mellor method. Existing action languages are Object Action Language (OAL), Shlaer–Mellor Action Language (SMALL), Action Specification Language (ASL), Model Action Specification Language (MASL), That Action Language (TALL), Starr's Concise Relational Action Language (SCRALL), Platform-independent Action Language (PAL) and PathMATE Action Language (PAL). SCRALL is the only one that is a graphical action language.
Model testing and execution Once a domain is modeled, it can be
tested independent of the target
implementation by executing the model. Each domain can be
verified and validated independent of any other domain. This allows
errors detected to be associated with the domain and independent of other system concerns.
Verification will involve such things as human
review of the models, performed by experts in the relevant domain, and automated checking of the Executable UML semantics. i.e., checking that the Executable UML model complies with the Executable UML
metamodel.
Validation will typically involve use of an Executable UML tool to execute the model. The execution can occur either before or after model compilation.
Model compilation In order to support execution on the target
implementation, the domain model must be translated into a less
abstract form. This translation process is called
model compilation. Most model
compilers target a known
programming language, because this allows reuse of existing
compiler technologies.
Optimizing the domain models for target
implementation reasons will reduce the level of
abstraction, adversely affect domain independence, and increase the cost of
reuse. In executable UML,
optimizations are done by the model
compiler either automatically or through
marking. Marking allows specific model elements to be targeted for specific lower-level
implementations, and allows for broader architectural decisions, such as specifying that
collections of objects should be
implemented as a
doubly linked list. In
MDA terms, the model
compiler creates the
PSM. The separation between the PIM and
PSM in Executable UML disables the ability to
round-trip engineer the model, and deters modifications to the
PSM. ==Executable UML key aspects==