100% found this document useful (3 votes)

652 views

Modelingwith Sys MLTutorial

Uploaded by

radup2

Available Formats

Download as PDF, TXT or read online on Scribd

100% found this document useful (3 votes)

652 views

Modelingwith Sys MLTutorial

Uploaded by

radup2

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 148

Modeling with SysML

Instructors:
Sanford Friedenthal
[email protected]
Joseph Wolfrom
[email protected]

Tutorial presented at INCOSE 2010 Symposium, Chicago, IL, July 2010.

OMG SysML™ Specification
 Specification status
 Adopted by OMG in May ’06
 Available Specification v1.0 in Sept ’07
 Available Specification v1.1 in Nov ‘08
 Available Specification for v1.2 in March ‘10
 Revision Task Force for v1.3 in process

 Multiple vendor implementations available

 This tutorial is based on:

 OMG SysML available specification (formal/2007-09-01) and
 OMG/INCOSE tutorial by Friedenthal, Moore, and Steiner
 “A Practical Guide to SysML” by Friedenthal, Moore, and Steiner
 Tutorial Material from JHU/APL Course developed by Joe Wolfrom

 This OMG tutorial, specifications, papers, and vendor info can be

found on the OMG SysML Website at http://www.omgsysml.org/

2 Copyright © 2006-2009 by Object Management Group.

Agenda
 Introduction
 SysML Diagram Overview
 Introduction to a Modeling Tool
 Language Concepts and Constructs
 Class Exercise
 Process Summary
 Tools Overview
 Wrap-up

3 © 2010 by JHU/APL. All Rights Reserved.

Objectives & Intended Audience
At the end of this tutorial, you should have an awareness of:
 Motivation of model-based systems engineering approach
 SysML diagrams and basic language concepts
 How SysML is used as part of an MBSE process

This course is not intended to make you a systems modeler!

You must use the language.

Intended Audience:
 Practicing Systems Engineers interested in system modeling
 Software Engineers who want to better understand how to
integrate software and system models
 Familiarity with UML is not required, but it helps

4 Copyright © 2006-2009 by Object Management Group.

INTRODUCTION

5 © 2010 by JHU/APL. All Rights Reserved.

SE Practices for Describing Systems

Past Future
 Specifications
ATC Pilot Airplane

 Interface requirements Request to proceed

Authorize

 System design
Initiate power-up

Power-up

Report Status

Direct taxiway

 Analysis & Trade-off Initiate Taxi

Executed cmds

 Test plans

Moving from Document centric to Model centric

6 Copyright © 2006-2009 by Object Management Group.
Model-based Systems Engineering (MBSE)
Life Cycle Support
 Formalizes the practice of
systems development
through use of models
 Broad in scope
 Integrates with multiple
modeling domains across
life cycle from system of
systems to component

Vertical Integration
 Results in
quality/productivity
improvements & lower risk
 Rigor and precision
 Communications among
system/project
stakeholders
 Management of complexity

7 © Copyright Lockheed Martin Corporation All Rights Reserved

System Development Process
Stakeholder Manage Plan
Reqts System
Development

Status
Test procedures
Technical data Define System Integrate
Reqt's & & Test System
Design System arch System
Allocated reqt's
System
Modeling Procedures Verified
Activities Data System
Hardware Component
Software
Develop
Component System
Modeling Components
Activities

Integrated Product A Recursive V process

Development (IPD) is that can be applied to
essential to improve multiple levels of the
communications system hierarchy

8 Copyright © 2006-2009 by Object Management Group.

System Modeling Activities – OOSEM
Integrating MBSE into the SE Process

Major SE Development Activities

•Causal analysis
Analyze •Mission use cases/scenarios
Needs
•Enterprise model

Define •System use cases/scenarios

System
Requirements
•Elaborated context

Define •Logical decomposition

Logical •Logical scenarios
Optimize &
Architecture •Logical subsystems
Evaluate •Parametric Diag
Alternatives •Trade study

Synthesize •Node diagram

Support Allocated •HW, SW, Data arch
Manage •Reqt’s •Test cases
Requirements Diagram
Validation & Architecture •System deployment
Verification •Test procedures
& tables

Common Subactivities
9 Copyright © 2006-2009 by Object Management Group.
4 Pillars of SysML
pkg [Model] Example Model [Model Organization]

System
Model

Requirements Behavior Structure Parametrics

req [Package] Requirements act [Activity] Behavior::A0 bdd [Package] Structure par [Block] Parametrics::Analysis J
«block»
«requirement» :System :Actor property 1
System
SR1
values
property 1 :C1
:A1
«satisfy»
«requirement» «requirement»
SR1.1 SR1.2 «block» «block»

:A2 Comp 1 Comp 2 property 1.1 property 1.2

values values
property 1.1 property 1.2

act [Activity] Behavior::A1 ibd [Block] System

:Comp1 :Comp2
:Comp 1 :Comp 2

:A1.1

:A1.2

10 © 2010 Elsevier, Inc.: A Practical Guide to SysML

SysML Diagram Types
SysML includes nine diagrams as shown in this diagram:

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.1

11 © 2010 by JHU/APL. All Rights Reserved.

4 Pillars of SysML – ABS Example
1. Structure sd ABS_ActivationSequence [Sequence Diagram] 2. Behavior
stm TireTraction [State Diagram]
m1:Brake
interaction
d1:Traction
Detector Modulator
LossOfTraction state
machine
detTrkLos()Gripping Slipping

activity/
RegainTraction
sendSignal() function
modBrkFrc(traction_signal:boolean)

modBrkFrc()
definition use
sendAck()

12 3. Requirements •4. Parametrics

13 © 2010 by JHU/APL. All Rights Reserved.

SysML Diagram Frames
 Each SysML Diagram must have a diagram frame
 Each SysML diagram frame represents a model element
 Diagram context is indicated in the header:
 Diagram kind (act, bdd, ibd, sd, etc.)
 Model element type (package, block, activity, etc.)
 Model element name
 User defined diagram name or view name
 A separate diagram description block is used to indicate if the
diagram is complete, or has elements elided

FIGURE 4.8
© 2008 Elsevier, Inc.: A Practical Guide to SysML

14 Copyright © 2006-2009 by Object Management Group.

SysML Diagrams
 Package diagram
 Requirement diagram
 Use Case diagram
 Block Definition diagram
 Internal Block diagram
 Activity diagram
 Sequence diagram
 State Machine diagram
 Parametric diagram

15 © 2010 by JHU/APL. All Rights Reserved.

Package Diagram
 Represents the organization of a model in terms of packages that
contain model elements

FIGURE 3.19
© 2008 Elsevier, Inc.: A Practical Guide to SysML

16 © 2010 by JHU/APL. All Rights Reserved.

Requirement Diagram
 Represents text-based requirements and their relationship with other
requirements, design elements, and test cases to support
requirements traceability

FIGURE 3.2
© 2008 Elsevier, Inc.: A Practical Guide to SysML

17 © 2010 by JHU/APL. All Rights Reserved.

Block Definition Diagram
 Represents structural elements called blocks, and their composition
and classification

FIGURE 3.3
© 2008 Elsevier, Inc.: A Practical Guide to SysML

18 © 2010 by JHU/APL. All Rights Reserved.

Internal Block Diagram
 Represents interconnection and interfaces between the parts of a
block

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.9
19 © 2010 by JHU/APL. All Rights Reserved.
Use Case Diagram
 Represents functionality in terms of how a system or other entity is
used by external entities (i.e., actors) to accomplish a set of goals

FIGURE 3.4
© 2008 Elsevier, Inc.: A Practical Guide to SysML

20 © 2010 by JHU/APL. All Rights Reserved.

Drive Vehicle
Sequence Diagram
 Represents behavior in
terms of a sequence of
messages exchanged
between parts

FIGURE 3.5
© 2008 Elsevier, Inc.: A Practical Guide to SysML

21 © 2010 by JHU/APL. All Rights Reserved.

Start Vehicle
Sequence Diagram

FIGURE 3.6 © 2008 Elsevier, Inc.: A Practical Guide to SysML

22 © 2010 by JHU/APL. All Rights Reserved.

Activity Diagram
 Represents behavior in terms of the ordering of actions based on the
availability of inputs, outputs, and control, and how the actions
transform the inputs to outputs

FIGURE 3.7
© 2008 Elsevier, Inc.: A Practical Guide to SysML

23 © 2010 by JHU/APL. All Rights Reserved.

Vehicle System Hierarchy
Block Definition Diagram

FIGURE 3.10 © 2008 Elsevier, Inc.: A Practical Guide to SysML

24 © 2010 by JHU/APL. All Rights Reserved.

Power Subsystem
Internal Block Diagram

FIGURE 3.12 © 2008 Elsevier, Inc.: A Practical Guide to SysML

25 © 2010 by JHU/APL. All Rights Reserved.

Provide Power
Activity Diagram

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.11

26 © 2010 by JHU/APL. All Rights Reserved.

State Machine Diagram
 Represents behavior of an entity in terms of its transitions between
states triggered by events

FIGURE 3.8
© 2008 Elsevier, Inc.: A Practical Guide to SysML

27 © 2010 by JHU/APL. All Rights Reserved.

Parametric Diagram
 Represents constraints on property values, such as F=m*a, used to
support engineering analysis

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.14
28 © 2010 by JHU/APL. All Rights Reserved.
Requirements Traceability

FIGURE 3.18 © 2008 Elsevier, Inc.: A Practical Guide to SysML

29 © 2010 by JHU/APL. All Rights Reserved.

INTRODUCTION TO A
MODELING TOOL

30 © 2010 by JHU/APL. All Rights Reserved.

Typical Work Area Components

Drawing Area

Project Toolbox
Browser

Figure Tabs

31 © 2010 by JHU/APL. All Rights Reserved.

LANGUAGE CONCEPTS AND
CONSTRUCTS

32 © 2010 by JHU/APL. All Rights Reserved.

Agenda
 Language Concepts and Constructs
 Organizing the Model with Packages
 Capturing Text-Based Requirements in the Model
 Modeling High Level Functionality with Use Cases
 Modeling Structure With Blocks
 Modeling Blocks and Their Relationships on a BDD
 Modeling Part Interconnection on an IBD
 Modeling Behavior
 Flow-based Behavior with Activities
 Message-based Behavior with Interactions
 Event-based Behavior with State Machines
 Modeling Constraints with Parametrics
 Modeling Cross Cutting Relationships with Allocations

33 © 2010 by JHU/APL. All Rights Reserved.

ORGANIZING THE MODEL
WITH PACKAGES

34 © 2010 by JHU/APL. All Rights Reserved.

Packages
 Packages are used to organize the model
 Groups model elements into a name space
 Often represented in tool browser
 Supports model configuration management (check-in/out)
 Model can be organized in multiple ways
 By System hierarchy (e.g., enterprise, system, component)
 By diagram kind (e.g., requirements, use cases, behavior)
 Use viewpoints to augment model organization
 Package Diagrams provide a graphical depiction of the model
organization and/or package content

35 Copyright © 2006-2009 by Object Management Group.

Package Diagram for Automobile Model

FIGURE 3.19
© 2008 Elsevier, Inc.: A Practical Guide to SysML

36 © 2010 by JHU/APL. All Rights Reserved.

Package Diagram Containment Relationship
 Depicts Package Hierarchy
 Three techniques (displayed below)
 Packages contained within ‘frame’ of parent package
 Packages contained within a package
 Crosshair pointing to the parent package

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 5.1

37 © 2010 by JHU/APL. All Rights Reserved.

Package Organization for Parking Garage
Gate

38 © 2010 by JHU/APL. All Rights Reserved.

Summary
 Packages are used for Model Organization
 Package Diagrams are used to depict how the model is organized
 Packages can contain:
 Other packages
 Model elements
 Models may be organized using a variety of methods

39 © 2010 by JHU/APL. All Rights Reserved.

CAPTURING TEXT-BASED
REQUIREMENTS IN THE MODEL

40 © 2010 by JHU/APL. All Rights Reserved.

Requirements
 The «requirement» stereotype represents a text based requirement
 Includes id and text properties
 Can add user defined properties such as verification method
 Can add user defined requirements categories
(e.g., functional, interface, performance)
 Requirements hierarchy describes requirements contained in a
specification
 Requirements relationships include Containment, DeriveReqt,
Satisfy, Verify, Refine, Trace, Copy
 SysML provides a graphical depiction of these relationships
 SysML also provides a means to capture rationale for a specific
requirement or relationship

41 Copyright © 2006-2009 by Object Management Group.

Automobile Specification Requirements
Diagram

FIGURE 3.2 © 2008 Elsevier, Inc.: A Practical Guide to SysML

42 © 2010 by JHU/APL. All Rights Reserved.

Requirements Traceability

FIGURE 3.18 © 2008 Elsevier, Inc.: A Practical Guide to SysML

43 © 2010 by JHU/APL. All Rights Reserved.

Representing Relationships
 Three ways to depict requirement relationships in SysML:
 Direct
 Compartment
 Callout

44 © 2010 by JHU/APL. All Rights Reserved.

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

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 12.3

45 © 2010 by JHU/APL. All Rights Reserved.

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.

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 12.4

46 © 2010 by JHU/APL. All Rights Reserved.

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

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 12.5

47 © 2010 by JHU/APL. All Rights Reserved.

Depicting Rationale
 Used to explain or justify a requirement or a requirement relationship

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 12.14
48 © 2010 by JHU/APL. All Rights Reserved.
Tabular Format
 Requirements and their relationships can be represented in a
tabular format

© 2008 Elsevier, Inc.: A Practical Guide to SysML

49
Parking Garage Requirements Model

50 © 2010 by JHU/APL. All Rights Reserved.

Summary
 Requirement modeling graphically depicts:
 Hierarchy between requirements
 Traceability between requirements and the rest of the model
elements
 There are three types of notation used to depict requirement
relationships: Direct, Compartment, and Callout
 There are seven types of requirement relationships in SysML:
 Containment
 Satisfy
 Verify
 Derive
 Refine
 Trace
 Copy

51 © 2010 by JHU/APL. All Rights Reserved.

MODELING HIGH LEVEL
FUNCTIONALITY WITH USE CASES

52 © 2010 by JHU/APL. All Rights Reserved.

Use Cases
 Provide means for describing basic functionality in terms of
usages/goals of the system by actors
 Use is methodology dependent
 Often accompanied by use case descriptions
 Common functionality can be factored out via «include» and
«extend» relationships
 Elaborated via other behavioral representations to describe detailed
scenarios
 No change to UML

53 Copyright © 2006-2009 by Object Management Group.

Operate Vehicle Use Case Diagram

FIGURE 3.4
© 2008 Elsevier, Inc.: A Practical Guide to SysML

54 © 2010 by JHU/APL. All Rights Reserved.

Use Case Diagram Components
 Use Case diagrams are comprised of the following:
 Subject
 Actors
 Use Cases
 Relationships

FIGURE 11.1 © 2008 Elsevier, Inc.: A Practical Guide to SysML

55 © 2010 by JHU/APL. All Rights Reserved.

Subject
 Provides the functionality in support of the use cases
 Represents a system being developed
 Also called the ‘system under consideration’
 Represented by a rectangle on the use case diagram

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 11.1

56 © 2010 by JHU/APL. All Rights Reserved.

Actors
 Used to represent something that uses the system
 Not ‘part’ of the system
 Depicted outside of the system ‘box’
 Actors interface with the system
 Can be a person or another system
 Usually depicted by a stick figure and/or block with <<actor>> label
 Name the Actors based on the role they perform as a user of the
system (e.g. Operator, Customer, etc)

FIGURE 11.1 © 2008 Elsevier, Inc.: A Practical Guide to SysML

57 © 2010 by JHU/APL. All Rights Reserved.

Use Cases
 Represent the goals that a system will support
 Depicted by an oval with the Use Case name inside
 Name should consist of a verb and a noun that describe the
functionality of the system (e.g. Record Grades, Monitor
Environment)

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 11.1

58 © 2010 by JHU/APL. All Rights Reserved.

Relationships on a Use Case Diagram
 Relationships between Actors and Use Cases
 Relationships between Use Cases
 Include
 Extend
 Classification

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 11.4

59 © 2010 by JHU/APL. All Rights Reserved.

Relationships Between Use Cases
 Include - depicts
shared (or re-
used) functionality
 Extend – depicts
optional
functionality,
performed when a
particular
condition is met
 Classification –
indicates that the
specialized Use
Case inherits
functionality from
the general Use
Case FIGURE 11.4 © 2008 Elsevier, Inc.: A Practical Guide to SysML

60 © 2010 by JHU/APL. All Rights Reserved.

Use Case Model for Parking Garage Gate

61 © 2010 by JHU/APL. All Rights Reserved.

Summary
 Use Cases capture the functionality a system must provide to
achieve user goals
 Use Case diagrams are made up of:
 Subject
 Actors
 Use Cases
 Relationships
 Use Case can be elaborated through:
 Activity diagrams
 Sequence diagrams
 State machine diagrams

62 © 2010 by JHU/APL. All Rights Reserved.

MODELING STRUCTURE
WITH BLOCKS

63 © 2010 by JHU/APL. All Rights Reserved.

MODELING BLOCKS AND THEIR
RELATIONSHIPS ON A BDD

64 © 2010 by JHU/APL. All Rights Reserved.

Blocks are Basic Structural Elements
 Provides a unifying concept for describing the structure of an
entity
 System
 Hardware «block» Compartment
 Software BrakeModulator Label
 Data
allocatedFrom
 Procedure «activity»Modulate
 Facility BrakingForce
 Person
values
DutyCycle: Percentage

 Multiple standard compartments can describe the block

characteristics
 Properties (parts, references, values, ports)
 Operations
 Constraints
 Allocations from/to other model elements (e.g. activities)
 Requirements the block satisfies
 User defined compartments

65 Copyright © 2006-2009 by Object Management Group.

Top Level Block Definition Diagram

FIGURE 3.3
© 2008 Elsevier, Inc.: A Practical Guide to SysML

66 © 2010 by JHU/APL. All Rights Reserved.

Vehicle System Hierarchy

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.10

67 © 2010 by JHU/APL. All Rights Reserved.

Purpose of Block Definition Diagrams
 Depicting Relationships between Blocks
 Composite Association
 Generalization
 Depicting Structural Features of Blocks
 Part Properties
 Value Properties
 Ports
 Flow Ports
 Standard Ports
 Depicting Behavioral Characteristics of Blocks
 Operations

68 © 2010 by JHU/APL. All Rights Reserved.

Composite Association
 Composite Associations depict parts that make up the Whole
 Black diamond on the Whole end
 Role names can appear on the part end

FIGURE 6.5 © 2008 Elsevier, Inc.: A Practical Guide to SysML

69 © 2010 by JHU/APL. All Rights Reserved.

Generalization
 Block Definition Diagrams can be
used to depict generalization and
Superclass
specialization relationships
 Facilitates reuse
 The specialized block (subclass)
reuses (inherits) the features of a
generalized block (superclass),
and adds its own features
 Depicts an ‘is-a’ relationship
 Depicted with a closed arrowhead
pointing toward the generalized
block Subclass Subclass

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 6.35

70 © 2010 by JHU/APL. All Rights Reserved.

Value Properties
 Used to model quantifiable block characteristics or attributes
 Based on a Value Type, which describe the values for quantities
 Listed in compartments using the following syntax:
 value property name: value type name
 Value Properties:
 can have default values
 can also define a probability distribution for their values

Probability Distribution

Default Value

© 2008 Elsevier, Inc.: A Practical Guide to SysML FIGURE 6.22

71 © 2010 by JHU/APL. All Rights Reserved.

Ports
 Specifies interaction points on blocks
 Kinds of Ports
 Flow Port
 Specifies what can flow in or out of a block
 Standard Port
 Specifies a set of required or provided operations

72
Flow Ports
 Flow Ports – used to describe an interaction point for items flowing
in or out of a block
 Two types:
 Atomic Ports
 Non-atomic Ports
 Depicted as a box on the block border

FIGURE 6.25 FIGURE 6.26

73 © 2010 by JHU/APL. All Rights Reserved.

Standard Ports and Interfaces
 Standard Ports – depict interfaces that specify the
behavioral features (services) that a block either
provides or requires
 Provided Interface – specifies operations that a
block provides
 Depicted by a ‘ball’
 Required Interface – specifies operations required
by the block
 Depicted by a ‘socket’

FIGURE 6.32
FIGURE 6.33
© 2008 Elsevier, Inc.: A Practical Guide to SysML

74 © 2010 by JHU/APL. All Rights Reserved.

Operations
 Operations describe something that a block can do
 Operations can have parameters that are passed into or out of the operation
 Operations are typically synchronous, (i.e. requestor waits for a response)
 Operations are listed in the ‘operations’ compartment of a block, as follows:
 operation name (parameter list): return type

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 6.31
75 © 2010 by JHU/APL. All Rights Reserved.
Top Level Block Definition Diagram for
Parking Garage Gate Domain

76 © 2010 by JHU/APL. All Rights Reserved.

Block Definition Diagram for Gate System

77 © 2010 by JHU/APL. All Rights Reserved.

Generalization/Specialization Relationship

78 © 2010 by JHU/APL. All Rights Reserved.

Summary
 A Block is the basic structural element used to model the system’s
structure
 Block Definition Diagrams are used to depict
 Definition of blocks
 How blocks relate to each other
 Block structural characteristics include part properties, value
properties, and ports
 Block functional characteristics include operations and receptions
 Block relationships include associations and generalizations

79 © 2010 by JHU/APL. All Rights Reserved.

MODELING PART
INTERCONNECTION ON AN IBD

80 © 2010 by JHU/APL. All Rights Reserved.

Block Definition vs. Usage
Block Definition Diagram Internal Block Diagram

Definition Usage
 Part is the usage of a
 Block is a definition/type
block in the context of a
 Captures properties, etc. composing block
 Reused in multiple contexts  Also known as a role

81 Copyright © 2006-2009 by Object Management Group.

Internal Block Diagram (ibd)
Blocks, Parts, Ports, Connectors & Flows

Enclosing
Block

Connector

Item Flow

Port Part

Internal Block Diagram Specifies Interconnection of Parts

82 Copyright © 2006-2009 by Object Management Group.

Vehicle System Context Showing External
Interfaces

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.9

83 © 2010 by JHU/APL. All Rights Reserved.

Power Subsystem
Internal Block Diagram

FIGURE 3.12
© 2008 Elsevier, Inc.: A Practical Guide to SysML

84 © 2010 by JHU/APL. All Rights Reserved.

Modeling Standard Ports and their
Connectors on an IBD
 Standard ports specify interactions as services
 Required interface specifies requests for services (socket symbol)
 Provided interface specifies provided services (ball symbol)

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 6.34

85 © 2010 by JHU/APL. All Rights Reserved.

Internal Block Diagram for Gate Assembly

86 © 2010 by JHU/APL. All Rights Reserved.

Internal Block Diagram for Control Unit

87 © 2010 by JHU/APL. All Rights Reserved.

Summary
 Internal Block Diagrams are used to depict the internal structure of a
block
 The frame of an IBD represents the enclosing block
 Internal Block Diagrams depict:
 The usage of a block in a specific context
 How parts/ports are connected
 What flows between parts/ports
 Standard ports are used on an IBD to depict interfaces that specify
the behavioral features (services) that a block either provides or
requires

88 © 2010 by JHU/APL. All Rights Reserved.

MODELING BEHAVIOR

89 © 2010 by JHU/APL. All Rights Reserved.

MODELING FLOW-BASED
BEHAVIOR WITH ACTIVITIES

90 © 2010 by JHU/APL. All Rights Reserved.

Activities
 Activity specifies transformation of inputs to outputs through a
controlled sequence of actions
 Secondary constructs show responsibilities for the activities using
activity partitions (i.e., swim lanes)
 SysML extensions to Activities
 Support for continuous flow modeling
 Alignment of activities with Enhanced Functional Flow Block
Diagram (EFFBD)

91 Copyright © 2006-2009 by Object Management Group.

Control Power Activity Diagram

FIGURE 3.7 © 2008 Elsevier, Inc.: A Practical Guide to SysML

92 © 2010 by JHU/APL. All Rights Reserved.

Provide Power Activity Diagram

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 3.11

93 © 2010 by JHU/APL. All Rights Reserved.

Actions
 Actions – describe how activities execute
 Used to model the steps of the activity
 Accept inputs and create outputs (depicted by ‘pins’)
 Call Actions – represent activities that can be further
decomposed into other actions
 Allows for hierarchical modeling of activities

© 2008 Elsevier, Inc.: A Practical Guide to SysML

FIGURE 8.3

94 © 2010 by JHU/APL. All Rights Reserved.

Decomposing an Activity Diagram with
Call Behavior Actions
 Pins match Parameters in number and type
 Rake symbol denotes details are depicted on another diagram

FIGURE 8.6

FIGURE 8.8
© 2008 Elsevier, Inc.: A Practical Guide to SysML

95 © 2010 by JHU/APL. All Rights Reserved.

Initial, Activity Final, and Flow Final Nodes
 Initial Node – denotes where execution begins
 Depicted by black circle
 Activity Final Node – denotes where execution
terminates
 Depicted by a bulls-eye
 Flow Final Node – terminates a particular
sequence of actions without terminating the entire
activity
 Depicted by circle with cross-hair

96 © 2010 by JHU/APL. All Rights Reserved.

Fork Nodes and Join Nodes
 Fork Node – one input flow, multiple output flows
 Output flows are independent and concurrent
 Join Node – multiple input flows, one output flow
 Output occurs, only when all input tokens are available (default)
 Join Specification may override default

Join Node with Join Specification

Fork Node

FIGURE 8.7
© 2008 Elsevier, Inc.: A Practical Guide to SysML
FIGURE 8.1

97 © 2010 by JHU/APL. All Rights Reserved.

Decision Nodes and Merge Nodes
 Decision Nodes – one input, multiple output paths
 Only one output path is valid, based on ‘guard’ conditions
 Guards must be mutually exclusive
 Merge Node – multiple inputs, one output flow
 Output flow is triggered upon arrival of any of the input flows

Decision Node Merge Node

FIGURE 8.13

Control Flow
 Used to show sequence of actions
 Represents a control token
 An action cannot start until it receives a control token on all input
control flows
 When an action is completed, it places control tokens on all
outgoing control flows
 Can be depicted with a dashed arrow, to distinguish it from object
flows
 Like object flow, can be used with:
 Forks and Joins
 Decision Nodes and Merges

Partitions (aka Swimlanes)
 Allocates actions to an
entity responsible for
performing the action
 Can be used to specify
functional requirements
of an actor, component,
or part
 Can be depicted
horizontally or vertically

Activity Model (w/Object Flow)

Activity Model (w/Partitions)

Decomposition of Calculate Fee
 Example below shows use of Input and Output Parameters for the
Calculate Fee Activity
 Hierarchical relationship of Activities and Actions

Summary
 Activity Diagrams are used to model behavior that specifies the
transformation of inputs to outputs through a controlled sequence
of Actions
 Activities can have multiple inputs or outputs called parameters
 Activities are made up of actions
 Actions consume input tokens and produce output tokens via pins
 Inputs/outputs can either be streaming or non-streaming
 Object Flows are used to depict the flow of object tokens from one
action to other actions
 Control Flows are used to depict the transfer of control from one
action to other actions using control tokens
 Call behavior actions can be further decomposed by calling other
activities
 Partitions are used to assign responsibility for actions to blocks or
parts that the partition represent

MODELING MESSAGE-BASED
BEHAVIOR WITH INTERACTIONS

Interactions
 Sequence diagrams provide representations of message based
behavior
 represent flow of control
 describe interactions between parts
 Sequence diagrams provide mechanisms for representing complex
scenarios
 reference sequences
 control logic

Start Vehicle Sequence Diagram

FIGURE 3.6

Drive Vehicle Sequence Diagram

Sequence Diagram Components
 Sequence diagrams can be comprised of the following:
 Lifelines
 Represents a Structural Element of a system
 Depicts ‘Time’
 Messages
 Asynchronous
 Synchronous
 Reply

FIGURE 9.4

Sequence Diagram for Opening the Gate

Summary
 Sequence Diagrams are used to depict the interactions between
structural elements of a Block
 Sequence Diagrams are comprised of:
 Lifelines
 Messages
 Lifelines represent the structural element and depicts Time
 Messages can be either:
 Asynchronous
 Synchronous
 Reply
 Messages represent a call for an operation
 Combined Fragments are used to depict complex interactions and
include: alternate paths, parallel paths, optional paths or loops
 Reference Interactions depict re-use of common interactions

MODELING EVENT-BASED
BEHAVIOR WITH STATE MACHINES

State Machines
 Typically used to represent the life cycle of a block
 Support event-based behavior (generally asynchronous)
 Transition with trigger, guard, action
 State with entry, exit, and do-activity
 Can include nested sequential or concurrent states
 Can send/receive signals to communicate between blocks
during state transitions, etc.
 Event types
 Change event
 Time event
 Signal event

Drive Vehicle States

States
 States – represents a condition in the life of a block
 Initial State – represented by a black solid dot
 Final State – represented by a bulls-eye

Behaviors
 Actions of a State
 Types:
 Entry – what happens when the state is entered
 Exit – what happens when the state is exited
 Do – what happens while in a state

Transitions
 Used to show the flow from one state to another (solid arrow)
 Can consist of triggers, guards, and effects

FIGURE 10.3
118 © 2010 by JHU/APL. All Rights Reserved.
Composite States
 Means of depicting the hierarchy of states
 Sub-states – states that are unique to another state of an entity
 Composite States are depicted by enclosing sub-states within a state

Summary
 State Machines Diagrams are used to depict how a Block changes
State
 State Machines can be comprised of:
 States
 Transitions
 Composite States
 States represent a condition in the life of a Block
 Behaviors are the actions associated with a State
 Transitions are used to show how a Block changes from one State
to another
 Transitions can consist of Triggers, Guards, and Effects
 Composite States are used to depict the hierarchy of States

MODELING CONSTRAINTS
WITH PARAMETRICS

Parametrics
 Used to express constraints (equations) between value
properties
 Provides support for engineering analysis
(e.g., performance, reliability)
 Facilitates identification of critical performance properties
 Constraint block captures equations
 Expression language can be formal (e.g., MathML, OCL) or informal
 Computational engine is provided by applicable analysis tool and not
by SysML
 Parametric diagram represents the usage of the constraints in
an analysis context
 Binding of constraint parameters to value properties of blocks (e.g.,
vehicle mass bound to parameter ‘m’ in F= m × a)

Parametrics Ena ble s Inte gra tion of Engine e ring Ana lys is
with De s ign Mode ls

Vehicle Acceleration Analysis Parametric
Diagram

Defining Constraints in Constraint Blocks
 Constraint Blocks
 Define equations so that they may be re-used and inter-connected
 Define a set of parameters
 Define an expression that constrains the parameters

125 © 2010 by JHU/APL. All Rights Reserved.
Defining Parametric Models
 Parametric models:
 Depict a network of equations
that constrain the properties
of blocks
 The properties of the system
are bound to the parameters
of the analysis equations (e.g.
vehicle mass is bound to ‘m’
in F=m x a)
 Example: in the figure,
properties of the vehicle are
bound to the parameters of the
equations used to analyze
vehicle stopping distance
 Parametric models thus help
identify the properties of the
system that are critical to
satisfying requirements © 2006-2008 by Object Management Group.

Top-Level Parametric Diagram for Gate
System

Summary
 Parametric diagrams
 Capture the analysis as a network of equations
 Help ensure consistency between the system design model and
multiple engineering analysis models
 Help to manage technical performance measures
 Constraint Blocks
 Define parameters and constraint expressions
 Represented on a Block Definition Diagram
 Constraint Property
 Usage of constraint blocks
 Represented on a Parametric Diagram

MODELING CROSS CUTTING
RELATIONSHIPS WITH
ALLOCATIONS

Allocation Relationships
 Allocation Relationships: Mapping Between Any Two Named Model
Elements
 A Named Model Element is Allocated to (allocatedTo) or Allocated
From (allocatedFrom) Other Model Elements.
 Example: System Behavioral Allocation (or Functional Allocation)
 Allocation of System Activities to Blocks
 Each Block Responsible for Executing a Particular Activity

Allocation Relationships

FIGURE 13.1

Allocation Notation
 Tabular (Table or Matrix) Notation: Multiple Allocation Relationships
 Not specifically prescribed by SysML specification (Tools Vary)
 Useful for concise, compact Allocations Representations

Functional Allocations for Parking Garage
Gate

Cross Connecting Model Elements
1. Structure 2. Behavior

satisfy

3. Requirements 4. Parametrics
134 Copyright © 2006-2009 by Object Management Group.
Summary
 Allocations are used to depict mapping of model elements to one
another
 There are many types of allocation, including: behavior, structure,
and properties
 Allocations allows:
 Allocating activities to blocks
 Allocating requirements to blocks
 Allocating logical elements to physical elements
 Allocation can be represented graphically though the following
notations: Direct, Compartment, and Callout
 Tabular representations offer a compact representation of multiple
allocation relationships

Class Exercise
Dishwasher Example - Sample Artifacts
Primary
 Requirement diagram – dishwasher spec
 Block definition diagram – top level
 Internal block diagram – dishwasher black box
 Use case diagram
 Activity diagram – black box scenario
 Block definition diagram – input/output definitions
 Block definition diagram – dishwasher hierarchy
 Internal block diagram – dishwasher white box
 Activity diagram – white box scenario
 Requirement diagram - traceability

Optional
 Parametric diagram
 State machine diagram
 Sequence diagram

136
PROCESS SUMMARY

System Modeling Activities – OOSEM
Integrating MBSE into the SE Process

Major SE Development Activities

•BDD – Top Level
Analyze
Needs
•Mission Use Case Diagrams

Define •System Use Case Diagrams

System •IBD – Black Box
Requirements
•Activity Diagram – Black Box Scenario

Define •BDD – Input/Output definitions

Logical •BDD – Hierachy
Optimize &
Evaluate
Architecture •IBD – White Box
Alternatives •Parametric Diagrams •Activity Diagrams – White Box Scenarios

Synthesize •Allocations
Support Allocated
Manage •Reqt’s •Test cases
Validation & Architecture
Requirements Diagrams
Verification •Test procedures
Spec &
Traceability

System
Analysis Models
Architecture Model Verification Models

U(s) G(s)
∫

Req’ts Allocation &

Design Integration

Hardware Models Software Models

SET
S Q

R CLR Q

139
TOOLS OVERVIEW

Tools Overview
 Tool Integration
 Suggested Tool Selection Criteria
 Partial List of SysML Tools

Tool Integration
 Classes of Tools in a Systems Development Environment
 Project Management
 Systems Modeling
 Performance Simulation
 Requirements Management
 Configuration Management and Data Management
 Verification and Validation
 Engineering Analysis
 HW and SW Modeling
 Document Generation

Tool Integration
 Data Exchange Mechanisms  Data Exchange Standards
 Manual  XML Metadata Interchange
 File-based exchange (XMI)  Application Protocol 233
 Interaction-based exchange (API)  Diagram Interchange
 Repository-based exchange Standards
 Model Transformation

Suggested Tool Selection Criteria
 Conformance to SysML specification
 Usability
 Document Generation capability
 Model execution capability
 Conformance to XMI
 Conformance to AP233
 Integration with other engineering tools
 Performance (maximum number of users, model size)
 Model checking to verify model conformance
 Training, online help, and support
 Availability of model libraries
 Life-cycle cost (acquisition, training, support)
 Vendor viability
 Previous experience with tool
 Support for selected model-based method (e.g. automated scripts,
standard reports, etc.)

Partial List of SysML Tools
 IBM - Rhapsody
 No Magic - Magic Draw
 Sparx Systems - Enterprise Architect
 Atego – Artisan Studio
 INTERCax ParaMagic (Magic Draw plug-in)
 Others
 Microsoft Visio – SysML Template (Pavel Hruby)
 ….

Note: list taken from SysML RFI 2009 Survey Responses

WRAP-UP

Deploying MBSE

Deploy MBSE into your organization as part of your improvement process

Summary
 SysML sponsored by INCOSE/OMG with broad industry and vendor
participation and adopted in 2006
 SysML provides a general purpose modeling language to support
specification, analysis, design and verification of complex systems
 Subset of UML 2 with extensions
 4 Pillars of SysML include modeling of requirements, behavior, structure,
and parametrics
 Multiple vendor implementations available
 Standards based modeling approach for SE expected to improve
communications, tool interoperability, and design quality
 Plan SysML transition as part of overall MBSE approach
 Continue to evolve SysML based on user/vendor/researcher
feedback and lessons learned