A UML/MOF METAMODEL FOR HATLEY-PIRBHAI SYSTEM SPECIFICATION
An UnCOOL situation
Figure 1: Uncool
TeamWork, was a structured engineering tool for requirements documentation and systems design of real-time and embedded software. Sterling Software acquired TeamWork from Cayenne Software way back in October 1998, and subsequently re-named it to COOL:Teamwork. The tool provided (partial) support for building software models as described in the book Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, ISBN 0-932633-11-0.
COOL:Teamwork was used at a number of (public limited) companies, to model products targeted for the aeronautical and military (and maybe other) domains. These products have very long life-cycles (typically 10 years of development, and then three decades of product service). New variants of these products may extend the lifecycle even further. The comparatively fast-moving world of software tools presents a challenge to those seeking adequate long-term support for their tooling. Unfortunately COOL:Teamwork has been unsupported software for many years, and a solution needs to be found for migrating the valuable design and specification models that it contains into modern software tooling.
Constructing a UML/MOF metamodel of Hatley-Pirbhai System Specification, as partially implemented in the COOL:Teamwork CASE tool, was the first step in our development of a robust solution to the model migration problem. If you would like to learn more then please get in contact with us via This email address is being protected from spambots. You need JavaScript enabled to view it.!
| Element | Description |
|---|---|
| EDIF serialization of model | The EDIF serialization of a COOL:Teamwork model. |
| COOL:Teamwork | The COOL:Teamwork application. |
| Sparx Enterprise Architect | Sparx Systems Enterprise Architect application. |
| UnCOOL | The UnCOOL application validates the COOL:Teamwork model, then transforms and rebuilds it inside of Sparx Enterprise Architect via the automation API. |
A UML/MOF metamodel of Hatley-Pirbhai System Specification
Figure 2: A UML/MOF metamodel of Hatley-Pirbhai System Specification
| Element | Description |
|---|---|
| System Architecture Model | The system architecture model consists of a layered set of AFDs and AIDs and their associated AMSs and AISs. Each successive layer refines the configuration defined by the higher-level diagrams.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24 |
| System Requirements Model | The System Requirements Model consists of:
No mention is made of how the process is activated. This is an important part of the information hiding and non-redundancy principles. The PSPEC does not know how or why it is activated, only what to do when it is. Likewise, the CSPEC does not know what the PSPEC does, only how to activate it. The user (who is familiar with the method) know exactly where to look for this information.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 288 |
| System Specification Model | The complete system specification model, consisting of the requirements and architecture models, specifies both what the system is to do, and how its design will be structured... The requirements and the architecture models together forming the total system specification model... The system requirements and architecture are interrelated and must be developed in parallel.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 22 and 24 |
The Requirements metamodel
Figure 3: The Requirements metamodel
| Element | Description |
|---|---|
| Control Context Diagram | The control context diagram establishes the control boundary between the system under study and the environment. It is used to show communication between the system and the environment and the entities in the environment with which the system communications. The control context diagram is the highest-level control flow diagram for the system.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 345 |
| Control Flow Diagram | A control flow diagram mirrors the processes and stores form the DFD, but shows control flows instead of data flows. The CFD is constructed simply to constrain the control signals to flow along the same paths as the data signals may flow.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 347 |
| Control Specification (CSPEC) | Control specifications convert input signals into output control signals or into process controls. Control specifications have two roles, one to show control processing and the other to show process control.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 350 |
| Data Context Diagram | The data context diagram establishes the data boundary between the system under study and the environment. It is used to show the communications between the system and the environment and the entities in the environment with which the system communicates. The data context diagram is the highest-level data flow diagram for that system-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 344 |
| Data Flow Diagram | A data flow diagram is a network representation of a system's functional requirements. The system could be automated, manual, or mixed. The DFD portrays the requirements in terms of their functional component parts, with all interfaces among the parts indicated."-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 346 |
| Process Specification (PSPEC) | A process specification must be written for every functional primitive process on a data flow diagram. A functional primitive process is defined as a process that is not further decomposed into a child DFD, but is described in a PSPEC.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 349 |
| Requirements Dictionary | The requirements dictionary is a ordered list of data and control flow names and data and control store names, each with a definition in terms of its components and structure. Every data flow, control flow, and store on the flow diagrams must be defined in the dictionary down to its primitive elements.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 354 |
| System Requirements Model | The System Requirements Model consists of:
No mention is made of how the process is activated. This is an important part of the information hiding and non-redundancy principles. The PSPEC does not know how or why it is activated, only what to do when it is. Likewise, the CSPEC does not know what the PSPEC does, only how to activate it. The user (who is familiar with the method) know exactly where to look for this information.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 288 |
| Timing Specfication | The timing specification is a list of system input events and their resulting system output events, both expressed in terms of the system input and output signals that represent them. The timing relationships are listed for each input-to-output event pair.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 353 |
Control Flow Diagram metamodel
Figure 4: Control Flow Diagram metamodel
| Element | Description |
|---|---|
| Control flow | A control flow is a pipeline through which control information of know composition flows. It may consist of a single element or a group of elements.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 340 Notation: A dashed arc (terminating in a filled arrow head) with a name. |
| Control Flow Diagram | A control flow diagram mirrors the processes and stores form the DFD, but shows control flows instead of data flows. The CFD is constructed simply to constrain the control signals to flow along the same paths as the data signals may flow.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 347 |
| CSPEC bar | A CSPEC Bar is a symbol used on a CFD to indicate the interface between the CFD and its CSPEC.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 340 Notation: A short unlabeled bar. |
| Process | "A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing." -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341
Notation: A circle with a name and a number. |
| Store | A data or control store is simply a data or control flow frozen in time. The data or control information it contains may be used any time after that information is stored and in any order.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A pair of parallel lines containing a name. |
Control Specification metamodel
Figure 5: Control Specification metamodel
| Element | Description |
|---|---|
| Control Specification (CSPEC) | Control specifications convert input signals into output control signals or into process controls. Control specifications have two roles, one to show control processing and the other to show process control.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 350 |
| Process Activation Table (PAT) | Process activation tables show the circumstances under which the processes on a DFD are enabled and disabled. The actions from an STD enter a PAT, which enables and disables the appropriate processes.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 17 |
| State Transition Diagram |
A diagrammatic representation of a finite state machine. State transition diagrams show the states of the system and how they are influenced by control signals. They respond to events represented by control flows and show the corresponding action that they system must take. Events and actions are represented on STDs as Event/Action labels on each of the transitions between the states.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 17 |
| State Transition Matrix (STM) | Here, the states are listed on the left side of the matrix, and the events along the top. Each element in the matrix shows the action (if any), and the next state (if any), caused by the event above that element when the machine is in the state on the left of that element.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 83 |
| State Transition Table (STT) |
A state transition table consists of four columns. The first column contains a list of each of the states. The second column shows, for each current state, all the events that cause transitions from it. The third shows the action (if any) associated with each transition. The fourth shows the state to which the transition goes.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 83 |
Data Context Diagram metamodel
Figure 6: Data Context Diagram metamodel
| Element | Description |
|---|---|
| Data Context Diagram | The data context diagram establishes the data boundary between the system under study and the environment. It is used to show the communications between the system and the environment and the entities in the environment with which the system communicates. The data context diagram is the highest-level data flow diagram for that system-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 344 |
| Process | A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A circle with a name and a number. |
| Terminator | A terminator represents an entity outside the context of the system that is a net transmitter or receiver of system data.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A rectangle containing a name. |
Data Flow Diagram metamodel
Figure 7: Data Flow Diagram metamodel
| Element | Description |
|---|---|
| Data Flow | A data flow is a pipeline through which data of know composition flows. It may consist of a single element or a group of elements.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 339 Notation: A solid arc (terminating in a filled arrow head) with a name. |
| Data Flow Diagram | A data flow diagram is a network representation of a system's functional requirements. The system could be automated, manual, or mixed. The DFD portrays the requirements in terms of their functional component parts, with all interfaces among the parts indicated.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 346 |
| Process | A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A circle with a name and a number. |
| Store | A data or control store is simply a data or control flow frozen in time. The data or control information it contains may be used any time after that information is stored and in any order.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A pair of parallel lines containing a name. |
Relationships metamodel
Figure 8: Relationships metamodel
| Element | Description |
|---|---|
| Control flow | A control flow is a pipeline through which control information of know composition flows. It may consist of a single element or a group of elements.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 340 Notation: A dashed arc (terminating in a filled arrow head) with a name. |
| Data Flow | A data flow is a pipeline through which data of know composition flows. It may consist of a single element or a group of elements.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 339 Notation: A solid arc (terminating in a filled arrow head) with a name. |
| Information Flow Channel | An information flow channel represents the physical means by which an information flow travels from architecture module to another. This channel may be constructed of any material or energy carrier, for example it may be electrical, mechanical, optical, or radio waves. There can be different symbols for different mediums of transmission.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 343 |
| Information Flow Vector | An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name. |
| Relationship | A relationship between two elements. |
State Transition Diagram metamodel
Figure 9: State Transition Diagram metamodel
| Element | Description |
|---|---|
| Action | Notation: Shown by name, adjacent to the events that cause them; the event and action are separated by either a forward slash (like event/action) or a horizontal line (like the mathematical notation for a fraction). |
| Event | Notation: Show by name as a label on the arc of the triggered transition. |
| State | Notation: A rectangular box containing the name of the state. |
| State Transition Diagram |
A diagrammatic representation of a finite state machine. State transition diagrams show the states of the system and how they are influenced by control signals. They respond to events represented by control flows and show the corresponding action that they system must take. Events and actions are represented on STDs as Event/Action labels on each of the transitions between the states.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 17 |
| Transition Arc | Notation: A solid line terminating in a filled arrow head (showing the direction of the transition). |
System Architecture Model metamodel
Figure 10: System Architecture Model metamodel
| Element | Description |
|---|---|
| Architecture Dictionary | The architecture dictionary is an enhancement of the requirements dictionary. It captures the allocation of all the data and control flows to architecture modules and the channels on which they flow.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24 |
| Architecture Flow Diagram | An architecture flow diagram is a network representation of a system configuration. The AFD represents a set of DFD and CFD flows and processes grouped into one architecture module. The architecture modules are represented by the architecture module symbol, and the communications between the architecture modules are represented by information flow vectors.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 360 |
| Architecture Interconnect Diagram | An architecture interconnect diagram is a representation of the channels by which the architecture modules communicate. The channels represent the physical means by which the information travels from one architecture module to another. The physical means might be any material or energy medium such as electrical buses, mechanical linkages, or an optical link.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 361 |
| Architecture Interconnect Specification | The architecture interconnect specification establishes the characteristics of the physical media connecting the architecture modules.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 364 |
| Architecture Module Specification | An architecture module specification must be written for every architecture module in the architecture model. The purpose of the AMS is to state the information and processing allocation for that architecture module in narrative or graphical form-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 363 |
| System Architecture Model | The system architecture model consists of a layered set of AFDs and AIDs and their associated AMSs and AISs. Each successive layer refines the configuration defined by the higher-level diagrams.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24 |
Architecture Context Diagram
Figure 11: Architecture Context Diagram
| Element | Description |
|---|---|
| Architecture Context Diagram | The architecture context diagram establishes the information boundary between the system and the environment. It is used to show communication between the system and entities in the environment outside the system. The architecture context diagram is the highest-level architecture diagram for that system-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 358 |
| Architecture Module | An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules...-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342 Notation: A rounded rectangle containing a name and number. |
| Information Flow Vector | An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name. |
| Terminator | A terminator represents an entity outside the context of the system that is a net transmitter or receiver of system data.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A rectangle containing a name. |
Architecture Flow Diagram
Figure 12: Architecture Flow Diagram
| Element | Description |
|---|---|
| Architecture Flow Diagram | An architecture flow diagram is a network representation of a system configuration. The AFD represents a set of DFD and CFD flows and processes grouped into one architecture module. The architecture modules are represented by the architecture module symbol, and the communications between the architecture modules are represented by information flow vectors.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 360 |
| Architecture Module | An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules...-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342 Notation: A rounded rectangle containing a name and number. |
| Information Flow Vector | An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name. |
Architecture Interconnect Diagram
Figure 13: Architecture Interconnect Diagram
| Element | Description |
|---|---|
| Architecture Interconnect Diagram | An architecture interconnect diagram is a representation of the channels by which the architecture modules communicate. The channels represent the physical means by which the information travels from one architecture module to another. The physical means might be any material or energy medium such as electrical buses, mechanical linkages, or an optical link.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 361 |
| Architecture Module | An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules...-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342 Notation: A rounded rectangle containing a name and number. |
| Information Flow Channel | An information flow channel represents the physical means by which an information flow travels from architecture module to another. This channel may be constructed of any material or energy carrier, for example it may be electrical, mechanical, optical, or radio waves. There can be different symbols for different mediums of transmission.-- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 343 |
