SysML: A Modeling Language for Systems of Systems Note to Instructor: The material in this slide set is not contained in the 3rd edition of the text book It is planned for the 4th edition.

What is SysML? A graphical modeling language developed by the OMG A UML profile that presents a subset of UML 2 with extensions A modeling language for modeling “systems of systems” Supports the development of complex systems consisting of several systems Model exchange via XMI Designed for model-based systems engineering (MBSE)

Relationship between SysML and UML SysML is defined as an extension of a subset of the Unified Modeling Language (UML) using UML's profile mechanism SysML is MOF compliant All models (MOF) UML models CORBA models (profile) SysML models .NET models U2TP UML 2 SysML Association Classes Class Diagrams Use Case Diagrams Requirements Diagrams Parametric Diagrams

Model Based Systems Engineering (MBSE) The formalized application of modeling to support system requirements, design, analysis, verification, validation activities[INCOSE 2004] Advantages Improved communications and knowledge management Impact analysis of requirements and design changes More complete representation A system engineering model contains several models addressing all aspects of the participating systems, hardware as well as software: Functional model Behavoral model (Dynamic model) Structure model (Object model) Cost model Organizational model Development environment, target environment

A SysML Model contains several Models Requirements Functional Model Dynamic (Behavior) Model Object (Structure) Model Other Models

A SysML System Model containing many Models (ABS Example) Also called the 4 pillars of SysML ABS Example

SysML Diagram Frames Activity diagram, block diagram, internal block diagram, sequence diagram

SysML Diagram Taxonomy Behavior Structure Requirements Parametrics

SysML Structural Diagrams Requirements Diagrams

Requirements Diagram Elements: Nodes

SysML Requirements Diagrams A SysML requirements diagram depicts the requirements in graphical, tabular or tree structure format Example: A Requirements Diagram in Visual Paradigm

Requirement Node (CASE tool:Visual Paradigm) A requirement node is a stereotype of a UML Class It has several attributes Text: the description of the requirement in natural language Id: Allows to number the requirement Source: Location, Stakeholder Kind: to categorize the requirement into Functional, Performance, Interface VerifyMethod: Analysis, Demonstration, Inspection, Test Risk: High, medium, low Status: Proposed, Approved, Rejected, Deferred, Implemented, Mandatory, Obsolete.

Visual Paradigm University License for Visual Paradigm Standard Edition Visual Paradigm Tutorials http://www.visual-paradigm.com/product/vpuml/tutorials.jsp Requirements Modeling with Visual Paradigm http://www.visual- paradigm.com/product/vpuml/provides/reqmodeling.jsp On this URL you also find a tutorial movie about managing SysML requirement diagrams.

Adding a Test Case Node (Visual Paradigm)

Adding more Requirements Nodes

Tabular Format of a Requirements Diagram

Dependency Relationships: Linking of Requirements Requirements can be linked to other requirements Containment: The requirement contains several sub-requirements Copy: One requirement is a read-only version of another requirement Derive: A requirement is derived from another requirement Requirement elements can also be linked to other model elements (in analysis and design models) Refine: A model element refines a requirement Verify: Another model element validates a requirement Satisfy: Another model element satisfies a requirement Linking to Use Cases Linking to Class diagrams Trace: Any model element that realizes a nonfunctional (performance) requirement.

Requirements Diagram Elements: Associations between Nodes Requirement Containment Relationship The containment relationship describes how each object instance is related to other object instances within a particular environment. This relationship pertains to object instances, not object classes. (in class relationships it is called aggregation) Aggregation (Containment) differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.

Requirements Diagram Elements: Associations between Nodes Requirement Composition Relationship The containment relationship describes how each object instance is related to other object instances within a particular environment. This relationship pertains to object instances, not object classes. (in class relationships it is called aggregation) Aggregation (Containment) differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.

Requirements Diagram Elements: Associations between Nodes Requirement Composition Relationship The containment relationship describes how each object instance is related to other object instances within a particular environment. This relationship pertains to object instances, not object classes. (in class relationships it is called aggregation) Aggregation (Containment) differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.

Requirements Diagram Elements: Associations between Nodes The text of the Slave requirement is a read-only copy of the text of the Master requirement Copy Dependency A functional requirement derived from a business need or a test requirement is derived from a functional requirement A Copy relationship is a dependency between a supplier requirement and a client requirement that specifies that the text of the client requirement is a read-only copy of the text of the supplier requirement. A DeriveReqt relationship is a dependency between two requirements in which a client requirement can be derived from the supplier requirement. For example, a system requirement may be derived from a business need, or lower-level requirements may be derived from a system requirement. As with other dependencies, the arrow direction points from the derived (client) requirement to the (supplier) requirement from which it is derived. Derive Dependency Functional Requirement Business Need Example: A use case satisfies a functional requirement. Satisfy Dependency

Example of a Copy Dependency (Reuse of Requirements) This slide illustrates the use of the Copy dependency to allow a single requirement to be reused in several requirements hierarchies. The master tag provides a textual reference to the reused requirement.

Example of a Derive Dependency Based on the requirement specifications from the National Highway Traffic Safety Administration (NHTSA.) Excerpt of the original requirement text used to create the model:

Requirements Diagram Elements: Associations between Nodes Example: A test case validates a functional requirement Verify Dependency Example: A use case refines a requirement Refine Dependency Trace Dependency Example: A use case can be traced to a requirement.

Callouts Or: How to avoid “Spaghetti” in Requirements Diagrams Trace Dependency Is equivalent to: TraceCallout

SysML Structural Diagrams Package Diagrams

Package Diagram

Organizing a Model by Use Cases Tim Weilkiens, Systems engineering with SysML/UML: modeling, analysis, design‬

Organizing a Model by Stakeholders SysML allows provide viewpoints for the stakeholders of a system

Package Diagram: Views and ViewPoints A model usually focuses on one abstraction of the system (analysis, design, cost) A view provides a perspective that spans multiple abstractions. It includes (subgraphs) of other models The EngrAnalysis view, for example, includes the organization of the enterprise, the system model, logical design and allocated design The viewpoint lists the stakeholders and purpose of the view.

SysML Structural Diagrams Block Diagrams

Blocks: Basic Structural Elements

SysML Blocks vs UML Classes SysML Blocks are based on UML classes However the do not allow association classes They distinguish between value properties from part properties They allow nested connector ends There are two types of SysML block diagrams Block definition diagrams (bdd) describing the relationship between blocks (composition, association,…) Internal block diagrams (ibd) describing the internal structure of a single block in terms of its properties and connectors Behavior (activity diagrams, use cases) can be allocated to both types of block diagrams.

SysML Block Diagrams Anti-Lock Controller Internal Block Block Definition Diagram Anti-Lock Controller

Internal Block Diagram: Blocks, Parts, Ports, Connectors and Flows

Reference Property vs Part

SysML Ports 2 Port Types Standard Port (also available in UML) Specifies a set of operations and/or signals Typed by a UML interface Flow Port Specifies what can flow in or out of a block/part Typed by a flow specification.

Port Notation

Links between Requirements and Design This slides shows an example of a compound requirement decomposed into multiple subrequirements.

Behavioral Diagrams

SysML Activities SysML activity diagram notation is the same as in UML SysML extensions to support Continous flow modeling Alignment of activities with Enhanced Functional Flow Block Diagrams (EFFBD)

Activity Diagram Notation (UML, SysML)

SysML Activity Diagrams also support Swim Lanes TractionDetector Swimlane BrakeModulator

SysML Activities can consists of Subactivities Activity Diagram Block Definition Diagram

SysML Interactions SysML sequence diagram notation is also the same as in UML but SysML does not include timing diagrams and communications diagrams SysML focuses on black and white box views of interactions with sequence diagrams.

Black Box Sequence Diagram (UML, SysML)

StartVehicle: Black Box Sequence Diagram

StartVehicle: White Box Sequence Diagram

SysML State Machines The same notation as in UML

SysML Use Cases SysML use cases: Also no change from UML

Allocations

Allocations

Different Representations for Allocations

Additional Information [INCOSE 2004] Systems Engineering Vision 2020, International Council for Systems Engineering, Technical Report INCOSE-TP-2004-004-02, September 2004 http://www.incose.org/ProductsPubs/pdf/SEVision2020_20071003_v2_03.pdf [SysML Tutorial 2009] Sanford Friedenthal, Alan Moore, Rick Steiner OMG Systems Modeling Language Tutorial, www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE-060524-low_res. pdf This lecture is based on this tutorial SysML Requirements Modeling with Visual Paradigm http://www.visual-paradigm.com/product/vpuml/provides/reqmodeling.jsp Here you also find a movie about requirements diagrams Visual Paradigm Standard Edition for UML and SysML Download Link: http://wwwbruegge.in.tum.de/static/vpapp/ Unlimited Educational License, Key will be provided in the SE 1 forum Installed on all the computers at the chair for applied software engineering Unicase (Research Tool) http://unicase.org Open source. Masterthesis offered: Feature Modeling, a modeling language replacing SysML

Backup Slides

Stereotypes and Model Libraries

Stereotypes

Applying a Profile and Importing a Model Library

SysML Block Property Types Part Property A Part is owned by a block (composition) Example: Right-Front Wheel is part of the Vehicle block The part stops existing, when the block stops existing Reference Property A part is not owned by the enclosing block Example: An interface between two parts Value Property Allows to define a value with units, dimensions and even probability distribution Examples: Non-distributed value: tirePressure:psi=30 Distributed value: <<uniform>> {min=28, max = 32} tirePressure:psi

SysML Parametric Diagrams

A SysML Model allows to include Physical Laws

The Physical Laws can be used to constrain Value Properties in the SysML Model

Allocation of Hardware to Software (-> Lecture on System Design, Topic Hardware-Software Mapping)