Last Updated: 26 January 2008
A Shlaer-Mellor Method metamodel has traditionally been called an OOA of OOA. Here we use the term metamodel for the OOA of OOA project as a whole and the term OOA of OOA for the application domain responsible for defining Object-Oriented Analysis (OOA) models and Recursive Design (RD) projects. The initial boundary for the OOA10 metamodel is determined by what is required to enable the interchange of work products between tools. However, the final boundary will be determined by what is required to facilitate an open marketplace for Shlaer-Mellor and Executable UML work products.
A work in progress metamodel for OOA Tool is currently distributed in OOA Tool releases (see OOATool.ooa). However, this metamodel is used to capture what has been implemented so far and what may be implemented in the future. Some parts of it are still undergoing considerable change. The official metamodel given below will always be a subset of the OOA Tool metamodel. Only stable features of what has actually been implemented in OOA Tool will be included in the official metamodel. The official metamodel is crucially important since it defines the metamodel data that can be extracted from Shlaer-Mellor or Executable UML models in Archetype Language templates. Since archetype templates are used for all reporting and code generation, any users who want to create new or change existing reports or implementation work products will need to understand the specific version of the metamodel assumed in the templates.
There is no direct relationship between the OOA10 metamodel and any version of the UML metamodel. However, there is a mapping (implemented in OOA Tool) between Shlaer-Mellor notation and Executable UML notation which will not be discussed here. Even though OOA Tool allows users to switch between Shlaer-Mellor and Executable UML notation, anyone who needs to develop or maintain archetype templates in OOA Tool will currently need to understand the Shlaer-Mellor based metamodel defined below. An Executable UML version of the official metamodel may be produced in the future depending on demand.
The Metamodel project currently only defines the OOA of OOA domain.
However, other domains are required to complete the metamodel,
e.g. a Diagramming domain is required to capture all the diagrams associated with a project.
The OOA of OOA domain is partitioned into the following subsystems:
Recursive Design,Information Model,Data Dictionary,State Model.Process Model and Action Language)
that have not been merged into the official metamodel yet.
The Object Information Model displayed above is taken from the Information Model Report for Recursive Design.
Shlaer-Mellor users apply Recursive Design when they separate their systems (captured as projects)
into different subject matter domains starting with their application domain,
recursively identifying service domains, working down to an architectural domain
and the implementation domains that will be used to realize the final system.
Creating an information model is not part of the Recursive Design process.
Translation of the project into implementation work products is part of the Recursive Design process.
However, translation concepts are not included in this subsystem.
Instead, they are defined in a separate Translation subsystem
which is not included in the official metamodel yet.
Although this subsystem looks small, once bridge mappings are defined,
this subsystem is similar in scale to the Information Model subsystem defined below.
What's included and implemented is:
Project, Domain and Bridge.Task and Activity
required to populate the Project Matrix work product.Imported Domain and Imported Bridge to facilitate reuse,Bridge Mapping and Wormhole
allowing domains to be integrated.Recursive Design subsystem.
However, none of the additional concepts have been implemented in OOA Tool yet.
The Object Information Model displayed above is taken from the Information Model Report for Information Model.
This subsystem defines all of the information modelling concepts originally presented in OOA88, OOA91 and OOA96. It also includes a few concepts from Executable UML [xtUML02] such as initial values for attributes and subset constrained relationships. Some completely new concepts have also been defined such as polymorphic attributes. Careful thought has gone into all new OOA10 concepts. This subsystem has remaining stable for a considerable time now.
What's included and implemented is:
Information Model and Subsystem,Object, Attribute and Identifier,Entity providing a single namespace and key letters space
for objects and terminators,Arbitrary ID Attribute
,Polymorphic Attribute
(see
Technical Note - Polymorphic Attributes),Relationship, Participant and Participant Mapping.Mathematically Dependent Relationship
(see
Technical Note - Mathematical Dependence),Loop Dependent Relationship
(see
Technical Note - Loop Dependent Relationships),
The Object Information Model displayed above is taken from the Information Model Report for Data Dictionary.
The Data Dictionary subsystem complements the Information Model subsystem
by allowing value domains to be formalized as data types.
Data types were introduced after OOA96 in the white paper DataType97.
This paper defined the following base data types:
Enumerated Type concept,Boolean Type concept,Symbolic Type concept,Numeric Type conceptValue Format != TIME and Time Unit == UNDEFINED),Arbitrary ID Type concept
(with Ordinal == TRUE),Numeric Type conceptValue Format == TIME and Time Unit != UNDEFINED),Numeric Type conceptValue Format != TIME and Time Unit != UNDEFINED),Arbitrary ID Type concept
(with Ordinal == FALSE).
This subsystem also introduces the concept of a predefined data type.
The obvious example being Boolean which can be either true or false.
This is complemented by the Boolean Type concept
which allows a true and false alias to be defined and used in addition to the normal true and false literals.
Predefined data types can't be created or changed within OOA Tool.
They must be explicitly added to each domain before they can be used.
Furthermore, if they are changed externally in an OOA file which is then loaded into OOA Tool,
they are reset to their factory presets.
Any predefined data types defined in a project which are not recognized by OOA Tool
are downgraded to ordinary data types when an OOA file is loaded.
OOA10 based tools which have defined their own predefined data types
should check whether an ordinary data type exactly matches one of their predefined data types
and upgrade any exact matches (including description) to predefined data types during loading.
This convention should allow different tools to define different predefined data types if necessary
while still allowing 100% compatible OOA interchange between tools.
Executable UML defines the following set of core types:
Boolean TypeFalse Alias = "FALSE", True Alias = "TRUE"
and Default Value = FALSE,Symbolic Type
with Default Value = "",Numeric TypeMaximum Decimal Places = 0 and Default Value = 0,Numeric TypePreferred Decimal Places = 1 and Default Value = 0.0,Numeric TypeValue Format = TIME and Time Unit = MILLISECOND,Numeric TypeValue Format = TIME and Time Unit = NANOSECOND,Domain Allocated ID Type.Integer core type would require a Java BigInteger as an
implementation type since there is no minimum or maximum value defined for the Integer core type.
However, if the user defined a domain specific integer between 0 and 1000
then a Java int could be used as the implementation type which is much more efficient.
What's included and implemented is:
Data Type and Data Value,Symbolic TypePattern Language domain
which will be merged into the official metamodel in the future),Arbitrary ID Type
which may be arbitrary or ordinal in nature and domain, object or parent allocated.
Data Holder which underlies supplemental data items, parameters and variables,Object Reference Type and Event Reference Type
for transferring references between supplemental data items, parameters and variables,Return Coordinate Type and Transfer Vector Type
required to formalize bridge mappings,Abstract Type
(called a deferred type in OOA97)
allowing a value to be passed from one domain to another without the target domain needing to know
how to create or operate on the value (beyond polymorphic operations such as equality).Data Dictionary subsystem.
The Object Information Model displayed above is taken from the Information Model Report for State Model.
This subsystem is only included here at the present time since the Terminator object
is imported into the Information Model subsystem.
The OOA Tool metamodel includes a complete State Model subsystem
which has also been fully implemented in OOA Tool.
However, there are a few dependency issues to be resolved before it is merged into the official metamodel.
OOA Tool is being developed in parallel with the OOA Tool metamodel. However, that metamodel is not stable enough for use with archetype templates. Furthermore, the work required (i.e. the Java coding in OOA Tool) to transform a users project into metamodel data is considerable. The metamodel has to be hard coded and each and every object, attribute and relationship of the metamodel has to be manually populated. That is why the official metamodel defined here only includes stable features.
The populated metamodel data is called a Metamodel Population in OOA10
and is identified solely by the metamodel version given in the change log below.
Another type of Project Population is a Model Population
which is used to capture the initial state for a simulation.
All of these concepts are defined within the Simulation subsystem
which is not yet stable enough to be merged into the official metamodel yet.
OOA Tool allows version specific metamodel populations to be added to a project.
These must be manually populated by selecting Populate Metamodel...
from the metamodel population's menu.
This is because metamodel data is big and as the official metamodel grows,
metamodel data will become even bigger.
OOA Tool loads all of the currently distributed projects in 10M.
However, it currently requires 21M to populate the metamodel data for just the OOA Tool project.
Metamodel populations are shared across all simulations and translations within a project.
However, if different archetype templates (in different translations) require different metamodel versions
then a metamodel population for each of the versions will need to be populated within the project.
Metamodel data is never saved in OOA files since it is entirely derived and temporal in nature.
Creating archetype templates requires a considerable investment of effort. However, by strictly controlling the versions of metamodel data, we can balance the need for stability against the need for innovation. OOA Tool will continue to support old versions of the metamodel even after new versions have become the norm, i.e. users are not expected to keep updating their archetype templates. Users should only update their templates if they need to access new information that is now available.
| Version 0.01 |
Domain Chart Recursive Design Information Model Data Dictionary State Model |
Initial tracked version. Includes 68 objects, 325 attributes and 74 relationships. Requires OOA Tool 1.0 BETA Build 013 (or later). |
| Version 1.0 | Requires OOA Tool 1.0 Standard (not released yet). |