MIGRATING COOL:TEAMWORK MODELS INTO MODERN CASE TOOLS

Transcription

1 MIGRATING COOL:TEAMWORK MODELS INTO MODERN CASE TOOLS A UML/MOF METAMODEL FOR HATLEY-PIRBHAI SYSTEM SPECIFICATION By Colin Coates (Senior Consultant) Version 1.0 Tuesday, 13 October 2015

2 Table of Contents An UnCOOL situation 3 A UML/MOF metamodel of Hatley-Pirbhai System Specification 4 The Requirements metamodel 6 Control Flow metamodel 9 Control Specification metamodel 11 Data Context metamodel 13 Data Flow metamodel 14 Relationships metamodel 16 State Transition metamodel 18 System Architecture Model metamodel 19 Architecture Context 21 Architecture Flow 23 Architecture Interconnect 25

3 An UnCOOL situation COOL:Teamwork UnCOOL AutomationAPI Sparx Enterprise Architect AutomationAPI exported from «artifact» EDIF serialization of model used by 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 Pirbhai, ISBN 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 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 info@dthomas.co.uk! EDIF serialization of model COOL:Teamwork Sparx Enterprise Architect UnCOOL The EDIF serialization of a COOL:Teamwork model. The COOL:Teamwork application. Sparx Systems Enterprise Architect application. The UnCOOL application validates the COOL:Teamwork model, then transforms and rebuilds it inside of Sparx Enterprise Architect via the automation API.

4 A UML/MOF metamodel of Hatley-Pirbhai System Specification System Specification Model System Requirements Model System Architecture Model Figure 2: A UML/MOF metamodel of Hatley-Pirbhai System Specification 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 Hatley and Imtiaz A. Pirbhai, p. 24

5 System Requirements Model The System Requirements Model consists of: A control context diagram Control specifications Control flow diagram(s) A data context diagram Data flow diagram(s) Process specifications A timing specification A requirements dictionary "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

6 The Requirements metamodel System Requirements Model 1..* 1..* 1..* 1..* Control Context Control Specification (CSPEC) Control Flow Data Context Data Flow Process Specification (PSPEC) Timing Specfication Requirements Dictionary "No mention is made of how the process is activated. This is an important part of the information hiding and nonredundancy 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 Hatley and Imtiaz A. Pirbhai, p288 Figure 3: The Requirements metamodel Control Context Control Flow Control Specification (CSPEC) Data Context "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 Hatley and Imtiaz A. Pirbhai, p. 345 "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 Pirbhai, p. 347 "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 Pirbhai, p. 350 "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

7 Data Flow Process Specification (PSPEC) Requirements Dictionary System Requirements Model 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 Hatley and Imtiaz A. Pirbhai, p. 344 "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 Hatley and Imtiaz A. Pirbhai, p. 346 "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 "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 Pirbhai, p. 354 The System Requirements Model consists of: A control context diagram Control specifications Control flow diagram(s) A data context diagram Data flow diagram(s) Process specifications A timing specification A requirements dictionary "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

8 Timing Specfication by Derek J. Hatley and Imtiaz A. Pirbhai, p. 288 "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 Pirbhai, p. 353

9 Control Flow metamodel Control Flow 0..* 0..* 0..* 0..* Process Store Relationship Control flow CSPEC bar Figure 4: Control Flow metamodel 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 Pirbhai, p. 340 Notation: A dashed arc (terminating in a filled arrow head) with a name. Control Flow CSPEC bar "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 Pirbhai, p. 347 "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 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 Pirbhai, p. 341

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

11 Control Specification metamodel Control Specification (CSPEC) 0..* 0..* 0..* 0..* State Transition State Transition Matrix (STM) State Transition Table (STT) Process Activation Table (PAT) Figure 5: Control Specification metamodel Control Specification (CSPEC) Process Activation Table (PAT) State Transition "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 Pirbhai, p. 350 "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 Hatley and Imtiaz A. Pirbhai, p. 17 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

12 State Transition Table (STT) state on the left of that element." -- Strategies for Hatley and Imtiaz A. Pirbhai, p. 83 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

13 Data Context metamodel Data Context theprocess 1..* Process Terminator Figure 6: Data Context metamodel Data Context Process "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 Hatley and Imtiaz A. Pirbhai, p. 344 "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 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 Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A rectangle containing a name.

14 Data Flow metamodel Data Flow 0..* 0..* 0..* Relationship Data Flow Process Store Figure 7: Data Flow metamodel 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 Hatley and Imtiaz A. Pirbhai, p. 339 Notation: A solid arc (terminating in a filled arrow head) with a name. Data Flow Process "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 Hatley and Imtiaz A. Pirbhai, p. 346 "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 Pirbhai, p. 341 Notation: A circle with a name and a number.

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

16 Relationships metamodel Relationship Data Flow Information Flow Vector Control flow Information Flow Channel Figure 8: Relationships metamodel 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 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 Hatley and Imtiaz A. Pirbhai, p. 339 Notation: A solid arc (terminating in a filled arrow head) with a name. Information Flow Channel Information Flow Vector "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 Pirbhai, p. 343 "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

17 modules." -- Strategies for Real-Time System Pirbhai, p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name. Relationship A relationship between two elements.

18 State Transition metamodel State Transition 0..* 0..* 0..* 0..* State Transition Arc Event Action Figure 9: State Transition metamodel Action Event State State Transition 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). Notation: Show by name as a label on the arc of the triggered transition. Notation: A rectangular box containing the name of the state. 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).

19 System Architecture Model metamodel System Architecture Model 0..* 0..* Architecture Dictionary Architecture Flow Architecture Module Specification Architecture Interconnect Architecture Interconnect Specification Figure 10: System Architecture Model metamodel Architecture Dictionary Architecture Flow Architecture Interconnect Architecture Interconnect Specification "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 Pirbhai, p. 24 "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 Pirbhai, p. 360 "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 "The architecture interconnect specification

20 Architecture Module Specification System Architecture Model 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 "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 Pirbhai, p. 363 "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 Hatley and Imtiaz A. Pirbhai, p. 24

21 Architecture Context Architecture Context 0..* Terminator Architecture Module 0..* Relationship Information Flow Vector Figure 11: Architecture Context Architecture Context Architecture Module "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 Hatley and Imtiaz A. Pirbhai, p. 358 "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 Pirbhai, p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name.

22 Terminator "A terminator represents an entity outside the context of the system that is a net transmitter or receiver of system data." -- Strategies for Hatley and Imtiaz A. Pirbhai, p. 341 Notation: A rectangle containing a name.

23 Architecture Flow Architecture Flow 0..* 0..* Architecture Module Relationship Information Flow Vector Figure 12: Architecture Flow Architecture Flow Architecture Module "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 Pirbhai, p. 360 "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.

24 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 Pirbhai, p. 342 Notation: A solid or dashed line (terminating in a filled arrow head) with a name.

25 Architecture Interconnect Architecture Interconnect 0..* Architecture Module 0..* Relationship Information Flow Channel Figure 13: Architecture Interconnect Architecture Interconnect Architecture Module "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 "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 Pirbhai, p. 343