Shlaer-Mellor and Executable UML Portal

(Top Tabs)

OOA of OOA

Last Updated: 26 January 2008

Introduction

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.

Domain Chart

Domain Chart for Metamodel

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:

These subsystems are outlined in the sections which follow. The OOA Tool metamodel defines many more subsystems (e.g. Process Model and Action Language) that have not been merged into the official metamodel yet.

Recursive Design Subsystem

Object Information Model for Recursive Design

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:

What's not included and not implemented yet is: The OOA Tool metamodel includes a much more detailed Recursive Design subsystem. However, none of the additional concepts have been implemented in OOA Tool yet.

Information Model Subsystem

Object Information Model for Information Model

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:

What's not included and not implemented yet is: The official metamodel defines all information modelling concepts currently envisaged for OOA10.

Data Dictionary Subsystem

Object Information Model for Data Dictionary

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:

The extended boolean data type was introduced to allow partially ordered ordinal values to be compared. This data type has no representation here since OOA10 always converts a partial ordering into a complete ordering either by composing an ordering using multiple criteria or by relying on a parent (or grandparent) of an object to be completely ordered where the child-parent relationship is defined on the ordinal type.

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:

All of these core types are available as predefined data types in OOA Tool even when Shlaer-Mellor notation is specified. However, users should only use core types for the initial development of a model. Their use should be eliminated as the domain being modelled becomes better understood, allowing domain specific value constraints to be defined. This allows the most efficient implementation data types to be used in the final system. For example, using the 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:

What's not included and not implemented yet is: The OOA Tool metamodel includes a slightly more detailed Data Dictionary subsystem.

State Model Subsystem

Object Information Model for State Model

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

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.

Change Log

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).

(Bottom Tabs)

Copyright © 2008-2010 by Kavanagh Consultancy Limited. All rights reserved.