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

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

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

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

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

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

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

8. SysML Diagram Taxonomy
Behavior
Structure
Requirements
Parametrics

9. SysML Structural Diagrams
Requirements Diagrams

10. Requirements Diagram Elements: Nodes

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

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

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

14. Adding a Test Case Node (Visual Paradigm)

15. Adding more Requirements Nodes

16. Tabular Format of a Requirements Diagram

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

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

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

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

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

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

24. 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:

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

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

27. SysML Structural Diagrams
Package Diagrams

28. Package Diagram

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

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

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

32. SysML Structural Diagrams
Block Diagrams

33. Blocks: Basic Structural Elements

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

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

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

37. Reference Property vs Part

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

39. Port Notation

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

41. Behavioral Diagrams

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

43. Activity Diagram Notation (UML, SysML)

44. SysML Activity Diagrams also support Swim Lanes
TractionDetector
Swimlane BrakeModulator

45. SysML Activities can consists of Subactivities
Activity Diagram
Block Definition Diagram

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

47. Black Box Sequence Diagram (UML, SysML)

48. StartVehicle: Black Box Sequence Diagram

49. StartVehicle: White Box Sequence Diagram

50. SysML State Machines
The same notation as in UML

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

52. Allocations

53. Allocations

54. Different Representations for Allocations

55. Additional Information
[INCOSE 2004]
Systems Engineering Vision 2020, International Council for Systems Engineering, Technical Report INCOSE-TP , September 2004
[SysML Tutorial 2009] Sanford Friedenthal, Alan Moore, Rick Steiner
OMG Systems Modeling Language Tutorial,
pdf
This lecture is based on this tutorial
SysML Requirements Modeling with Visual Paradigm
Here you also find a movie about requirements diagrams
Visual Paradigm Standard Edition for UML and SysML
Download Link:
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)
Open source. Masterthesis offered: Feature Modeling, a modeling language replacing SysML

56. Backup Slides

57. Stereotypes and Model Libraries

58. Stereotypes

59. Applying a Profile and Importing a Model Library

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

61. SysML Parametric Diagrams

62. A SysML Model allows to include Physical Laws

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

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