OMG Systems Modeling Language Tutorial May, 2012 Giuseppe Scanniello Giuseppina Casalaro
System Engineering Overview System Engineering (SE) is a discipline to deal with complex system realised through software and hardware solutions. System Engineering applies to the following areas and industries: embedded systems, automotive, rail, aerospace, military, telecommunication, healthcare, energy, etc. System Engineering relies on modelling and simulation methods to validate requirements or to evaluate the system.
SysML vs UML SysML reuses a subset of the UML2 (UML4SysML), and defines its own extensions. Therefore SysML includes nine diagrams instead of the thirteen diagrams from the UML 2.0, making it a smaller language that is easier to learn and apply.
Structure of SysML Language SysML is defined on a modular basis. We can distinguish between elements of the Structural Model (Structure) used to describe the structure of the system, elements of the Behavioral Model (Behavior) used to describe the functions of the system, and other model elements that relate to both (structural and behavioral).
Structure of SysML Language Specifically: The classes are called blocks (the UML Class Diagram becomes Block Definition Diagram in SysML); The Composite Structure Diagram of the UML is called Internal Block Diagram in SysML. With this diagram you can model the flows between the various blocks (item flows); Two new types of diagrams: Requirement Diagram and Parametric Diagram;
Behavior Diagram Activity Diagram The Activity Diagram is used to describe the flows in a sequence of actions. The flows involving input data and output (required or created within the stream itself). The stream scan run in parallel, to be synchronized, or divided according to specific conditions. The basic elements of this diagram are the activities.
Structure Diagram Block Definition Diagram The Block Definition Diagram defines the properties, operations and relations between the blocks, giving a hierarchical system. It s based on the UML Class Diagram with restrictions and extensions. The elements of the model underlying this graph are the blocks and the elements attached to it: attributes, data types, units, dimensions, and relations between the blocks (association: aggregation and composition, dependency and generalization).
Structure Diagram Internal Block Diagram The Internal Block Diagram describes the internal structure of a block in terms of properties and connections between them. It can be used to represent the interfaces of the system. It is based on the Composite Structure Diagram of the UML, with restrictions and extensions. The elements of the model at the base of this diagram are always the blocks. In particular, the common elements with the Block Definition Diagram (attributes, data types, units, dimensions, aggregation and composition relationships, dependency, generalization). In the more they considered the elements role, connectors, ports, interfaces, item flows, block association, and signals.
Structure Diagram Parametric Diagram The Parametric Diagram is a special form of Internal Block Diagram, in which the blocks used are of Constraint Blocks through which it is possible to specify constraints that are present in the properties of a block, i.e. in a part of the system. The elements of the model at the base of this diagram are the constraint blocks, and blocks.
But our focus is on
REQUIREMENT DIAGRAMS While the functional requirements can be modeled with the use cases, present both in the UML that in the SysML: Special stereotypes could be defined for use cases to represent nonfunctional requirements. SysML, has introduced a new type of diagram: the Requirement Diagram, which allows you to define and describe the requirements and model the relationships with other requirements or elements of the model. The graphical elements are the requirements with model elements related to it, and relations with other requirements and/or other elements: Containment, Satisfy, Verify, Derive, Refine, Trace, Copy.
Example of Requirement Diagram 1/2
Example of Requirement Diagram 2/2
Individual Requirement Attributes Unambiguous every requirement has only one interpretation Understandable the interpretation of each requirement is clear Correct the requirement states something required of the system, as judged by the stakeholders Concise no unnecessary information is included in the requirement Traced each stakeholder s requirement is traced to some document or statement of the stakeholders Traceable each derived requirement must be traceable to a higher level requirement via some unique name or number Design independent each requirement does not specify a particular solution or a portion of a particular solution Verifiable a finite, cost-effective process can be defined to check that the requirement has been attained
Attributes of a Set of Requirements Unique there is no overlapping or redundancy among requirements Complete (a) everything the system is required to do throughout the system s life cycle is included, (b) responses to all possible inputs throughout the system s life cycle are defined, (c) the document is defined clearly and self-contained, and (d) there are no to be defined or to be reviewed statements Consistent (a) internal -no two subsets of requirements conflict, and (b) external no subset of requirements conflicts with external documents from which the requirements are traced Comparable the relative necessity of the requirements is included Attainable solutions exist within performance, cost, and schedule constraints Organized grouped according to a hierarchical set of concepts
Definition of Requirement A requirement specifies a capability, a function, a service or a condition that the system must satisfy. This is a stereotype of <<requirement>> element of the UML class. The two basic properties of requirement are an ID (unique identifier) and a descriptive text (text). Both are strings. The text contains a description of the requirement itself or references to external sources. Note: ID and text are attributes of the stereotype <<requirement>> can then be defined for any requirement.
Representing Relationships There are three ways to depict requirement relationships in SysML: Direct Compartment Callout
Direct Notation Used when the requirement and the related model element appear on the same diagram. Establishes dependency of model element to requirement in model. Read figure below as: The camera satisfies the Sensor Decision requirement.
Compartment Notation Used when the requirement and model element do not appear on the same diagram. Used for model elements such as blocks or requirements that support compartments.
Callout Notation Used when the requirement and model element do not appear on the same diagram Uses Note box, rather than model element. Can be used when the model element or tool does not support compartments.
Requirement Relationships in SysML There are seven types of relationships in SysML: 1. Containment 2. Satisfy 3. Verify 4. Derive 5. Refine 6. Trace 7. Copy
Containment Relationship Depicts Requirement Hierarchy. Crosshair points to the parent requirement. Parent requirement and Child requirements may not have the same name. The relationship containment precludes the reuse of requirements, then SysML provides the relationship copy (>>).
Satisfy Relationship Depicts when a model element satisfies a requirement. It says if a requirement is satisfied in full or in part. We can add this information using a comment or a stereotype.
Verify Relationship Used to depict a test case (>>) that is used to verify a requirement. The relationship can be represented either by Direct Notation that with the Compartment Notation. "Test Case" is an element that controls whether a certain element of the system satisfies a requirement or not. In SysML, the "test case" can be used as a general mechanism for representing methods of verification. So, a "test case" is often referenced by a requirement to report "verify".
Derive Relationship Used when a requirement is derived from another requirement based on analysis. This report may be used only between requirements. Arrowhead points to the source requirement.
Refine Relationship Used to depict a model element that clarifies a requirement. Typically, a use case or behavioral diagram. Arrowhead points to the requirement. The relationship can be represented either by Direct Notation that with the Compartment Notation.
Trace Relationship Used to relate requirements to a model element that represents a source for the requirement. It is used only for reasons of traceability. Arrowhead points to the model element.
Copy Relationship The relationship Copy describes a condition that a requirement is copy of another requirement. It was introduced by SysML because sometimes you need to reuse a requirement in another context; and use a Containment Requirement may lead to formal problems. This relationship allows you to create a copy of the original requirement. Name and ID can be different, instead of text must be equal to the original.
Finally Depicting Rationale Used to explain or justify a requirement or a requirement relationship
Bibliography: A pratica guide to SysML Friedenthal, Moore, Steiner, Morgan Kaufmann Couse Material by Joe Wolfrom, APL OMG System Modeling Language Tutorial