00 T2 Moreland

8/13/2019 00 T2 Moreland

1/2022008, ARTiSAN Software Tools 1

Introduction to SysML

Slide 1

I n t r o d u c t i o n t o S y s M LI n t r o d u c t i o n t o S y s M L

Copyright 2006 ARTISAN Software Tools All Rights Reserved

A n I n t ro d u c t i o n t o t h e A n I n t ro d u c t i o n t o t h e

O M G S y s t e m s M o d e l i n g L a n g u a g e O M G S y s t e m s M o d e l i n g L a n g u a g e

(OMG SysML(OMG SysML))

Some slides Copyright 2006 by Object Management Group.Published and used by INCOSE and affiliated societies with permission.

Clarence C. MorelandClarence C. Moreland

Principal Consultant,Principal Consultant,ARTiSAN Software ToolsARTiSAN Software Tools

8/13/2019 00 T2 Moreland



Copyright 2006ARTISAN Software Tools All Rights ReservedSlide 2

Caveat

This material is based on the Final AdoptedSysML specification (ad-06-05-04)

Adopted by OMG in May 06

Some of the slides are based on theOMG SysML tutorial and are used withpermission.

OMG SysML Website

http://www.omgsysml.org/

8/13/2019 00 T2 Moreland




Objectives & Intended Audience

At the end of this tutorial, you should understand the: Benefits of model driven approaches to systems engineering Types of SysML diagrams and their basic constructs Cross-cutting principles for relating elements across diagrams Relationship between SysML and other Standards High-level process for transitioning to SysML

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 Already familiar with system modeling & tools, or

Want to learn about systems modeling

Software Engineers who want to express systems concepts Familiarity with UML is not required, but it will help

8/13/2019 00 T2 Moreland




Agenda

Introduction

Systems Engineering with SysMLRequirements and Requirements Diagrams

Structural DiagramsBlocks and Block Diagrams

Behavioral DiagramsUse Case modelling

Activities and Activity Diagrams

Sequence Diagrams

State Machines

Cross-cutting ConceptsRequirements traceability

Allocations

Package Diagram

Parametric Diagrams

Process IssuesQ&A

8/13/2019 00 T2 Moreland




SE Practices for DescribingSystems

Specifications

Interface requirements

System design

Analysis & Trade-off

Test plans

Moving from Document centric to Model centricMoving from Document centric to Model centric

P a s t Past F u t u r e F u t u r e

8/13/2019 00 T2 Moreland




System Modeling

Requirements

Integrated System Model Must Address Multiple Aspects of a SysteIntegrated System Model Must Address Multiple Aspects of a Syste mm

8/13/2019 00 T2 Moreland




Model Based Systems

Engineering Benefits

Improved communications

Assists in managing complex system development

Separation of concerns

Hierarchical modeling

Incremental development & evolutionary acquisition

Improved design quality

Reduced errors and ambiguity

More complete representation

Early and on-going verification & validation to reduce risk

Other life cycle support (e.g., training) Enhanced knowledge capture

8/13/2019 00 T2 Moreland



C opyright 2006ARTISAN Software Tools All Rights ReservedSlide 8

What is SysML?

A graphical modelling language in response to the UML forSystems Engineering RFP developed by the OMG,

INCOSE, and AP233

a UML Profile that represents a subset of UML 2 withextensions

Supports the specification, analysis, design, verification,and validation of systems that include hardware, software,

data, personnel, procedures, and facilities

Supports model and data interchange via XMI and theevolving AP233 standard (in-process)

SysML is Key Enabler for Model Based Systems Engineering (MBSE)SysML is Key Enabler for Model Based Systems Engineering (MBSE)

8/13/2019 00 T2 Moreland




What is SysML (cont.)

Isa visual modeling language that provides Semantics = meaning

Notation = representation of meaning

Is n o t a methodology or a tool SysML is methodology and tool independent

8/13/2019 00 T2 Moreland




UML/SysML Status

UML V2.0 Updated version of UML that offers significant capability

for systems engineering over previous versions Finalized in 2005 (formal/05-07-04)

UML for Systems Engineering (SE) RFP Established the requirements for a system modeling

language Issued by the OMG in March 2003

SysML Industry Response to the UML for SE RFP Addresses most of the requirements in the RFP

Version 1.0 adopted by OMG in May 06 / In f inalization Being implemented by multiple tool vendors

8/13/2019 00 T2 Moreland



Copyright 2006 ARTISAN Software Tools All Rights ReservedSlide 11

SysML Team Members

Industry & Government American Systems, BAE SYSTEMS, Boeing, Deere & Company,

EADS-Astrium, Eurostep, Lockheed Martin, NIST, NorthropGrumman, oose.de, Raytheon, THALES

Vendors

Artisan, EmbeddedPlus, Gentleware, IBM, Gentleware,I-Logix, Mentor Graphics, Motorola, PivotPoint Technology,Sparx Systems, Telelogic, Vitech Corp

Academia

Georgia Institute of Technology Liaison Organizations

INCOSE, AP233 WG

8/13/2019 00 T2 Moreland



Slide 12


C opyright 2006 ARTISAN Software Tools All Rights Reserved

Di ag ra m O v e rv ie wDi ag ra m O v e rv i e w

8/13/2019 00 T2 Moreland




Reuse of UML 2.0 for SysML

UML 2.0SysML

UML not

required by

SysML

SysML

ExtensionsUML reused

by SysML

This workshop deals with the full set of SysML diagrams, boththe inherited UML diagrams and the additional ones.

8/13/2019 00 T2 Moreland




Stereotypes & Model Libraries

Mechanisms for further customizing SysML

Profiles represent extensions to the language

Stereotypes extend meta-classes with properties andconstraints

Stereotype properties capture metadata about the model element

Profile is applied to user model

Profile can also restrict the subset of the meta-model usedwhen the profile is applied

Model Libraries represent reusable libraries of model

elements

8/13/2019 00 T2 Moreland




Stereotypes

Defining the Stereotype Applying the Stereotype

8/13/2019 00 T2 Moreland



Copyright 2006 ARTISAN Software Tools All Rights ReservedS l i d e 1 6

Tag Definition and Tag Value

Tag Definition the definition (name, type) of an additional model item property

applied to a model item via linked stereotype(s)

Tag Value

data value(s) for a specific tag definition for a specific model item

*

When you apply a stereotype to a model item, you often want to attach additional

information to that element. In the example of a COTS stereotyped board you

might want to specify the cost of that board. This is done by linking a tagdefinition (named, for example, cost) to the stereotype through which a tag

value (for example, 24.50) can be specified for that board.

8/13/2019 00 T2 Moreland




Applying a Profile andImporting a Model Library

8/13/2019 00 T2 Moreland




SysML Taxonomy of Diagrams

Diagram

Structure Behavior

Block

Definition [1]

Internal

Block [2] Package Activity

Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

[1] Modified UML Class Diagram

[2] Enhanced UML Composite Structure Diagram

SysML reuses many of the major diagram types of UML. In some cases, the UML

diagrams are strictly re-used such as use case, sequence, state machine, and

package diagram, whereas in other cases they are modified so that they areconsistent with SysML extensions. For example, the block definition diagram and

internal block diagram are similar to the UML class diagram and composite

structure diagram respectively, but have extensions or omissions. Activity

diagrams have also been modified.

SysML does not use all of the UML diagram types such as the object diagram,

communication diagram, interaction overview diagram, timing diagram, and

deployment diagram. This is consistent with the approach that SysML represents a

subset of UML. In the case of deployment diagrams, the deployment of software to

hardware can be represented in the SysML internal block diagram. In the case of

interaction overview and communication diagrams, it is felt that the SysMLbehavior diagrams provided adequate coverage for representing behavior without

the need to include these diagram types. Two new diagram types have been added

to SysML : the requirement diagram and the parametric diagram.

[SysML v1.0]

8/13/2019 00 T2 Moreland




Modelling and Your Project

Not all diagram types are essential most projects will only use a subset

You may have additional specializedmodelling requirements: process related

domain related

customer defined

etc.

*

For many organizations, any approach to modeling needs to be customized, to

include standards, notation and information relevant to the organization, its

customers, and the projects it undertakes. This need to extend the modelingcapability of the language is recognized within the UML by the specification of

extension mechanisms. The UML provides a mechanism for extending or

customizing modeling information. This mechanism uses the above concepts to

label model elements and to define additional properties for them.

8/13/2019 00 T2 Moreland



C opyright 2006 ARTISAN Software Tools All Rights ReservedSlide 20

ibd [Block] Anti-Lock Controller1

Block

Anti-Lock Controller

BlockPropertyd1 : Traction Detector

BlockProperty

m1 : Brake Modulator

BlockPropertyd1 : Traction Detector

BlockProperty

m1 : Brake Modulator

c1:modulator interface

use

interaction

par[constraint] StraightLineVehicleDynamics [Parametric Diagram]

: AccelerationEquation

F c

a

: BrakingForceEquationtf

tl

bf

f

: DistanceEquation

vx

: VelocityEquation

a

v

{f = (tf*bf)*(1-tl)} {F = ma}

{v = dx/dt} {a = dv/dt}

The Four Pillars of SysML

(ABS Example)

1. Structure

4. Parametrics

2. Behavior

Vehicle SystemSpecification

Braking SubsystemSpecification

requirement

id#102

txtThe vehicle shall stop from

60 mph within 150ft on aclean dry surface.

Stopping Distance

requirement

id#337

txtThe Braking subsystem shallprevent wheel lockup under

all braking conditions.

Anti-Lock Performance

req[Package] Vehicle Specifications [Braking]

deriveReqt

3. Requirements

bdd [Package] Vehicle [ABS]

BlockLibrary::

Electronic

Processor

BlockAnti-Lock

Controller

BlockLibrary::

Electro-HydraulicValve

BlockTraction

Detector

BlockBrake

Modulator

d1 m1

definition

Gripping Slipping

LossOfTraction/

RegainTraction/

stmTire [Traction] state machine

Detect Loss OfTraction

TractionLoss ModulateBraking Force

act PreventLockupactivity/function

Structure

e.g., system hierarchies, interconnections

behavior

e.g., function-based behaviors, state-based behaviors

Properties

e.g., parametric models, time variable attributes

Requirements

e.g., requirements hierarchies, traceability

8/13/2019 00 T2 Moreland




SysML Diagram Frames

Each SysML diagram represents a model element

Each SysML Diagram must have a Diagram Frame Diagram context is indicated in the header:

Diagram kind (act, bdd, ibd, seq, etc.)

Model element type (activity, block, interaction, etc.)

Model element name

Descriptive diagram name or view name

A separate diagram description block is used to indicate if thediagram is complete, or has elements hidden

Header

Contents

Diagram Description

Version:Description:Completion status:Reference:(User-defined fields)

diagram usage

diagramKind [modelElementType] modelElementName [diagramName]

8/13/2019 00 T2 Moreland



Slide 22



Re q u ire m e n t s Re q u ire m e n t s

8/13/2019 00 T2 Moreland




The Requirements Diagram

Diagram

Structure Behavior

Block

Definition

Internal

Block Package Activity

Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

The Requirements diagram sits out side the Structure/behavior organization of the

remaining SysML diagram types.

8/13/2019 00 T2 Moreland




What are Requirements?

Statement of a customers needs andexpectations

Describes the essential characteristics of thecustomers goals

Requirements should be problem based and notdescribe the solution. However, if there aresolution based elements in the requirements,these must be modelled and included in thesolution.

8/13/2019 00 T2 Moreland




The SysML Requirements DiagramWh a t is i t u se d fo r ?

The Requirements diagram can be used for a varietyof purposes throughout the system lifecycle: Traditional text requirements and their properties (e.g., id,

statement, criticality, etc)

Grouping a set of requirements in a package

Breaking down requirements into constituent elements

Demonstrating traceability between derived and source

requirements

Showing which design elements satisfy which requirements

Verification of a requirement, or design element by a test case Rationale for all of the above

How the requirements diagram is used will vary depending on the industry,

company, project, and process. Its main strength is in its ability to graphically

represent requirements and how they pertain to the rest of the UML model.

8/13/2019 00 T2 Moreland




Requirements

A requirement specifies a capability or condition that must (orshould) be satisfied [SysML]

Can specify function to be performed or performance criteriato be met

Basic attributes of a Requirement ID: A unique identifier for the Requirement

Text: A Description of what is Required.

Users can create stereotypes and tags to add specificproperties, e.g. Requirement type (Performance, Safety, Functional, etc. )

Criticality

Test method

Status

Etc.

requirement

txtThe System shall do...

reqtType

function

REQ_A1

8/13/2019 00 T2 Moreland




SysML Requirements Diagram

Elements

Design Elements

Model Element CModel Element C

Model Element T

Model Element A

testCaseModel Element B

requirement

txtThe System shall do...

reqtTypefunction

REQ_A1

requirement

REQ_A1.1requirement

REQ_A1.2

requirement

REQ_B1

requirement

REQ_C

rationale

explanationproblem

description of problem

requirement

derivedFromREQ_A1.1

req Requirement Diagram 1

deriveReqt

refine

trace

satisfy

verify

Requirement

Callout

Containment

requirement

txtsame text

REQ_D

copy

The requirement diagram shows both requirements and the different types of

relationship that can be specified between them.

Requirement properties (such as the textual description) can be shown ifrequired.

Containment(sometimes referred to as flowdown) is used to show where

requirements are decomposed into sub-requirements.

ThederiveReqtandcopyrelationships can only exist between

requirements. trace, refine, satisfy and verifycan exist between a

requirement and any other model element.

Theverifyrelationship can only exist between a requirement and a behavioral

model element stereotyped as a testCase.

An alternative to these direct relationships is to use the callout notation onlyone example of the callout notation is shown here.

problem andrationalecomments can be added as required to any model

element to capture issues and decisions.

8/13/2019 00 T2 Moreland




SysML Requirements Diagram

Example

activityDistill Water

UseCaseDistill Water

requirement

txtThe system must be ableto connect directly tomains water

Water Input

requirement

txtDistill dirty water into pure water

Produce Distilled Water

requirement

txtThe pure water outputmust be at a safetemperature

Water Output

requirement

txtThe system shall handle1 litre of water per minute

Water Throughput

Customer Brochure

requirement

txtThe system shall have aninput valve that is closedwhen the system is off

Provide Input Protection

requirement

txtThe system must have anoverflow valve in the mainheating vessel

Handle Overflow

requirement

txtThe condenser needs tocool the pure water to 30C

Condenser Efficiency

refine

satisfy

trace

deriveReqt

deriveReqt

deriveReqt

rationaleAnalysis of this activity

hows that the throughputis possible

rationaleDirect connection to high

pressure mains when thesystemis off might cause

damage

rationaleHigh pressure w ater may

overpower the boiler soan overflow valve is

needed

rationale0 is deemed a safe

output temperature

req [package] UserRequirements

8/13/2019 00 T2 Moreland




Problem and Rationale

Problem and Rationale can be attached to anyProblem and Rationale can be attached to anyModel Element to Capture Issues and DecisionsModel Element to Capture Issues and Decisions

8/13/2019 00 T2 Moreland




An Automotive Example

The Business Process

The Business Case

Marketing have identified a niche in the market for a mid-range engine, high-specification vehicle(Named: XSV-2001). The eventual cost of the vehicle will be in the range of 16K-20K, with aproposed launch date of Spring 2003. Finance have made 300K available for Conception andDevelopment (including any re-tooling and training on the production line). The estimated profit marginis 10%-15% per production unit. Minimal changes will be made to existing production lines and tooling,and maximum use of existing components is mandated. A review will be held in 4-months todetermine go-ahead of Development (and subsequent) phases. Target market: Executive Fleet andFamily.

Feature-Set

Standard

Front-Wheel Drive, Front-engine, 5-Door (hatch-back), 5 -Seat three-point inertial seat -belts (standard

options of colour & cover); 1999ccm Variable Valve Control Petrol Engine; Integrated Traction &Cruise Control; Engine Management System (EMS) (including both Control and Diagnostics);Advanced Breaking System (ABS); Electric Windows & Seat Adjustment and Heating (Front seatsonly, Front windscreen only); Optional:

Front and Rear proximity sensors (including distance read-out and audio warning); GPS NavigationSystem (including audio instructions); (Sports Option) Engine Management System;

The Business Case

Will specify the Requirement for a System (e.g. a Car)

Ma yinclude (solution-based) capabilities of the System (e.g. Cruise

Control, EMS, ABS)

Ma yinclude Constraints (e.g. Cost, Time, Component Reuse, Tooling)

The Business Case defines that a System is required and defines the

requirements of the System from the Business perspective. This will include

some high-level decisions regarding the Systems Capabilities and Usage. TheBusiness Case will also identify business-level Constraints e.g. Development and

Production time and cost limits.

8/13/2019 00 T2 Moreland



Slide 31


Copyright 2006 ARTISAN Software Tools All Rights Reserved

S y s M L S t r u c t u r e S y s M L S t r u c t u r e

8/13/2019 00 T2 Moreland




Block Diagrams

Diagram

Structure Behavior

Block

Definition

Internal


Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

8/13/2019 00 T2 Moreland




Blocks are BasicStructural Elements

Provides a unifying concept to describe the structure of anelement or system

Hardware

Software

Data

Procedure

Facility

Person

Multiple compartments can describe the blockcharacteristics

Properties (parts, references, values) Operations Constraints Allocations to the block (e.g. activities)

Requirements the block satisfies

8/13/2019 00 T2 Moreland




Block Property Types

Property is a structural feature of a block Part propertyaka. part (typed by a block)

Usage of a block in the context of the enclosing block

Example - right-front:wheel

Reference property(typed by a block)

A part that is not owned by the enclosing block (notcomposition)

Example - logical interface between 2 parts

Value property(typed by value type)

Defines a value with units, dimensions, and probability

distribution

Example

Non-distributed value: tirePressure:psi=30

Distributed value: uniform {min=28,max=32}tirePressure:psi

8/13/2019 00 T2 Moreland




Using Blocks

Based on UML Class from UML Composite Structure Eliminates association classes, etc.

Differentiates value properties from part properties, add nestedconnector ends, etc.

Block definition diagram describes the relationship amongblocks (e.g., composition, association, classification)

Internal block diagram describes the internal structure of a

block in terms of its properties and connectors

Behavior can be allocated to blocks

Blocks Used to Specify Hierarchies and InterconnectionBlocks Used to Specify Hierarchies and Interconnection

8/13/2019 00 T2 Moreland




bdd[Package] Block Def intion Diagram [bdd- Notation]

Block::Block1

Block

partsmyPart : Block4refParts : Block6 [*]

sharedPart : Block5 [0..1]

referencesrefParts : Block6 [*]

valuesaValue : ValueType1

Block2

Block::Block1::Block3

BlockBlock4

BlockBlock5

BlockBlock6

ValueType

dimension

Dimension1

unitUnit1

ValueType1

Actor1

1

1

myPart 0..1

1

sharedPart

*1

refParts

11

Block Definition Diagram (bdd)

Notation

Generalization

Namespacecontainment

Referenceassociation

Shared

associationPartassociation

Multiplicity

Compartments

Part (role)names

Examples of blocks, and part, reference and value properties are shown here. The

generalization relationship indicates that Block 2 inherits properties of Block 1. The

reference association is used to indicate which parts are reference parts. A partassociation shows exclusively owned parts, a shared association indicates parts shared

with other blocks. Multiplicity values indicate the number of parts.

8/13/2019 00 T2 Moreland




ibd [Block] Block2 [ibd Notation]

BlockBlock2

BlockPropertymyPart : Block4

fPort1

fPort3

BlockProperty

0..1

sharedPart : Block5

fPort2

sPort

BlockProperty

*

refParts : Block6

fPort4

Actor1

pI/F

rI/F

ItemFlow1 : ItemTypeItemFlow

ItemFlow3 : DataType2ItemFlow

ItemFlow2 : ValueType1ItemFlow

Internal Block Diagram (ibd) Notation

E n c l o s i n g E n c l o s i n g

B l o c k B l o c k

C o n n e c t o r C o n n e c t o r

Po r t Po r t

Item FlowItem Flow

Internal Block Diagram SpecifiesInternal Block Diagram SpecifiesInterconnection of PartsInterconnection of Parts

ReferenceReference

Pr o p e r tyPr o p e r ty

(in, but not of)(in, but not of)

PartPart

Note the consistency between this ibd and the previous bdd (part names, types

and multiplicities).

8/13/2019 00 T2 Moreland




Parts

A Part is a property of a block that the block requiresin order to exist

Used to illustrate the hierarchical composition of asystem and its components

A part is normally typed by a block and representsan instance of that type within its enclosing block

A referenced property is a part not owned by itsenclosing block, but referenced by some other partof that enclosing block

8/13/2019 00 T2 Moreland




SysML Port

Specifies an interaction point on a block or a part

Supports integration of behavior and structure

Linked by a connector to one or more other ports

Port types

Standard (UML) Port

Specifies a set of operations and/or signals

Typed by a (UML) interface

Flow Port

Specifies whatcan flow in or out of block/part

Atomic ports are:

Uni-directional Typed by the single item that flows in or out

Non-atomic ports are:

Bi-directional

Typed by a flow specification

8/13/2019 00 T2 Moreland




Port Notation

BlockPropertypart1 sp1sp1

BlockPropertypart2sp2sp2

BlockPropertypart1

fp1 : ItemType1fp1 : ItemType1BlockProperty

part2

fp2 : ItemType1fp2 : ItemType1

BlockPropertypart1

fp3 : FlowSpec1fp3 : FlowSpec1BlockProperty

part2

fp4 : FlowSpec1fp4 : FlowSpec1

Interface1 Interface1

Sta n d a r d Po r t Sta n d a r d Po r t

A t o m i c F l o w P o r t A t o m i c F l o w P o r t

No nNo n--a t o m i c F l o w P o r t a t o m i c F l o w P o r t

Standard ports are typed by one or more interfaces. A provided interface (lollipop)

specifies the services provided through the port; a required interface (cup) specifies

required services.

Note the consistency of direction of the atomic flow ports.

Flow port syntax is name : type, but what is actually shown may be either or both.

8/13/2019 00 T2 Moreland




Unit and Item Types

Unit typesnormally basedon Real

SI Units and

Dimensionsdefined in SysML

appendix

block

valueslh : J/kg = 520m : kg = 0press : Pash : J/kg/C = 1t : C

H2O

block

valuesQ : J

Heat

block

valueslh : J/kg = 520press : Pash : J/kg/C = 1t : C

Residue

block

valueslh : J/kg = 520press : Pash : J/kg/C = 1t : C

Fluid

block

valuesp : W

Electricity

bdd[package] Items

valueType

dimension = mass

unit = kilogram

kg

valueType

dimension = temperatureunit = degrees Centigrade

C

valueType

unit = Joules

J

valueType

unit = kilograms/second

kg/s

valueType

dimension = pressureunit = kilograms/square meter

kg/m

bdd Units

8/13/2019 00 T2 Moreland




Port Typing

An atomic flow specifies a single item that flows in our out. A flow specification lists multiple items that flow.

flowSpecification

flowPropertyList

in FuelSupply : Fuelout FuelReturn : Fuel

FPump-ICE

flowSpecification

flowPropertyList

in TorqueIn : Torqueout TorqueOut : Torque

TorqueSpec

valueTypeAnalogue

flowSpecification

flowPropertyList

in Value : V

Digital

InterfaceEMU Msg

Send ()

Interface

Set Throttle

Set Throttle ()

block

values

MassFlowRate : gm/secPress : kg/m

Temp : C

Liquid

block

values

MassFlowRate : gm/secPress : kg/m

Temp : C

Fuel

valueTypeC

valueTypekg/m

valueTypegm/sec

valueTypeSysML Extras::SI Unit Types::AInterface

TransmIF

Gear ()

Temp

Press

MassFlowRate

bdd [package] Flow Specifications

F lo w F lo w

Sp e c if ic a t io n Sp e c if ic a t io n

InterfaceInterface

B l o c k B l o c k Va lu e T y p e Va lu e T y p e

8/13/2019 00 T2 Moreland




Delegation Through Ports

Delegation can be usedto preserve encapsulationof block

Interactions at outer portsof Block1 are delegatedto ports of child parts

Ports must match (samekind, types, direction etc.)

(Deep-nested)Connectors can breakencapsulation if required(e.g. in physical systemmodelling)

Child2:

Child1:

ibd [block]Block1[delegation]

8/13/2019 00 T2 Moreland




Connectors and Flows

BlockPropertyPart 1 : Block B

fp1 : FlowSpec1fp1 : FlowSpec1 BlockPropertyPart 2 : Block C

fp2 : FlowSpec1fp2 : FlowSpec1

ItemFlow1 : DataType1ItemFlowItemFlow1 : DataType1ItemFlow

Flow Ports type specifies

what c an flowin/out

Item Flow -Specifies what

d o e sflow

(in context)

Connector

FlowSpecification

flowPropertyListin FlowProperty1 : Block3out FlowProperty2 : DataType1inout FlowProperty3 : ValueType2

FlowSpec1

A connector is a link between parts that enables communication between them.

The flow ports, through their type, define what sort of things can flow across the

connector. This can be discrete items such as a data packet or an interrupt, orcontinuous flows like heat or fluids. What does actually flow in the specific

context of a specific diagram is specified by one or more item flows, whose type

must be consistent with that of the flow ports.

8/13/2019 00 T2 Moreland




Structure vs. Usage

Definition Block is a definition/type

Captures properties, etc.

Reused in multiple contexts

Usage

Part is the usage in aparticular context

Typed by a block

Also known as a role

Block Definition Diagram Internal Block Diagram

8/13/2019 00 T2 Moreland




Block Definition DiagramExample

Parts compartmentshows structural children

Values compartmentshows properties of theblock

Flowports compartmentdescribes the interfaceto the block

Operations compartmentshows functionalcapabilities (a means of

invoking block activities dealt with later)

bdd[Package] Distiller [Structure - with compartments]

Block

operations

TurnOn ()TurnOff ()

partsbx1 : Boilercx1 : Controller

drain : Valvefeed : Valvehx1 : Heat Exchangerui1 : Control Panel

flowPortListout DSClean_Out : H2O

in DSDirty_Out : H2Oout DSExcess : H2Oin DSPower_In : Powerout DSResidue_Out : Residue

Distiller

Block

valuesMax : tempMin : temp

flowPortListout BLExcess : H2Oin BLHotDirty_In : H2Oin BLPower_In : Powerinout blrSig : blrSigout BLSteam_Out : H2Oout BLSteam_Out2 : Residue

Boiler

Block

flowPortListin Feed_HotDirty_In : H2Oout Feed_HotDirty_Out : H2Oin Fluid_In : Fluidout Fluid_Out : Fluid

Valve

Block

valuestempGradient : Real

flowPortListout HEClean_Out : H2Oin HEDirtyIn : H2Oout HEHotDirty_Out : H2Oin HESteam_In : H2O

Heat Exchanger

BlockControl Panel

Block

operationspwrOn ()ResidueTimer ()DrainTimer ()shutDown ()

Controller

User

bx1

drain

hx1

1

1

feed

1

1

ui1

1

1

cx1

11

user

The block definition diagram (bdd) shows block properties. Which specific block

properties are shown is down to the choice of the modeler.

Parts (part properties) are normally shown using the UML composition relationship (the

filled in diamond), where the role names at the other end of the relationship specify the

part name (the block name at that end specifying the type). Part properties can also be

shown in the Parts compartment of the containing block.

The Values compartment can be used to show any values (and their type) relevant to the

block.

The Flowports compartment (if shown) will list all flowports created on an internal blockdiagram (ibd) for the block or parts typed by the block.

The Operations compartment (if shown) will list all block operations. An operation

specifies a functional capability of the block, and acts as a means through which block

activity can be invoked. This topic is dealt with in greater detail later in the course.

8/13/2019 00 T2 Moreland




ibd[block] Distiller

IBD for Distiller

Non-Atomic Flow Ports (BC and HEC) I/O is specified using FlowSpecification

FlowSpecification consists of propertiesstereotyped FlowProperty

isConjugate promotes reuse offlowSpecifications

Atomic FlowPorts (dirtyWater,extPower )

In this case the port is directly typed bythe item type (Block or ValueType)

Direction property specifies thedirection of flow

block Di stiller

PureWater

loPressResidue

dirtyWater

hx :HeatExchangerfIn : Fluid

pFOut

HEC

tempWrn

bl : Boiler

SOut

BC

excess

blWrn

PwrIn

Rcnt

Ocnt

controller : Controllerui

vO

vD

wrn

pwrIn

blrPwr

vI

UI : FrontPanel

cnt

User

overFlow

extPower

inValve :

FlowValveip

op

cnt

UserIO

ILamp

IPower

IValve

IValve

ILamp

IPower

IValve

IValve

IValve

IValve

waterOut : H2O

blSteamOut : H2O

hxWaterOut : H2O

PowerIn : Electricity

RegPower : Electricity

waterIn : H2O

Excess : H2O

blSludgeOut : Residue

problemOverflow water is

very hot!

8/13/2019 00 T2 Moreland




Internal Block Diagram Example 2 :

Drill-down to show Boiler internals

ibd [Block] Boiler [drill down]

BlockBoiler

BlockPropertyheater : Element

ELPower_In : Power

ELHeat_Out : Heat

BlockPropertytank : Heating Vessel

HVHeat_In : HeatHVHotDirty_In : H2O

HVSteam_Out : H2O

HVSludge : Residue

HVExcess : H2O

BLHotDirty_In : H2O

BLSteam_Out : H2O

BLSteam_Out2 : Residue

BlockPropertyvOverFlow : Valve

Fluid_In : FluidFluid_Out : Fluid

BlockPropertyvResidue : Valve

Fluid_In : Fluid

Fluid_Out : Fluid

BLPower_In : Power

BLExcess : H2O

BlockPropertyheater : Element

ELPower_In : Power

ELHeat_Out : Heat

ELPower_In : Power

ELHeat_Out : Heat

BlockPropertytank : Heating Vessel


HVSteam_Out : H2O

HVSludge : Residue

HVExcess : H2O


HVSteam_Out : H2O

HVSludge : Residue

HVExcess : H2O

BLHotDirty_In : H2O

BLSteam_Out : H2O

BLSteam_Out2 : Residue

BlockPropertyvOverFlow : Valve



BlockPropertyvResidue : Valve

Fluid_In : Fluid

Fluid_Out : Fluid

Fluid_In : Fluid

Fluid_Out : Fluid

BLPower_In : Power

BLExcess : H2O

Shows parts (structural children)

and ports (interaction points onblock and parts)

Supports consistency of layers

The ports on the (enclosing) Boiler block can be automatically populated on this

diagram from the information on the previous diagram.

8/13/2019 00 T2 Moreland



Slide 49



Use CasesUse Cases

8/13/2019 00 T2 Moreland




SysML Use Case Diagram

Diagram

Structure Behavior

Block

Definition

Internal


Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

The Use Case diagram in SysML is used to capture aspects of behavior.

8/13/2019 00 T2 Moreland




Use Cases

Provide means for describing basic functionalityin terms of usages/goals of the system by actors

Common functionality can be factored out viainclude and extend relationships

Generally elaborated via other behavioralrepresentations to describe detailed scenarios

No change to UML

8/13/2019 00 T2 Moreland




Use Case Diagram

Flight Crew

Navigator

Pilot

Air-To-AirTracking

Air-To-GroundStrike

WeatherMonitoring

ActorGeneralisation

Actor SubjectBoundary

Use Case

Subject NameucDiagram Name

The subject may be the entire system or a component of that system.

SysML syntax use the prefix uc followed by the name of the diagram in the

outer frame.

8/13/2019 00 T2 Moreland




What is a Use Case?

*

Use Cases describe the goals that actors have in relationto the system.

A Use Case meets a need or solves a problem for anactor.

So, what is an Actor ?

An Actor is an entity which is eternal to the system, whichinteracts with the system, but is not a part of the system.

Actors should reflect the entire system lifecycle including:

manufacture, test, installation, maintenance, etc.

8/13/2019 00 T2 Moreland



An actor is anything outside the system to which the system interfaces. This

may be a person, an external system or item of equipment, or some more abstract

concept such as time.

Examples:

Person - Pilot, Operator, Maintainer, etc

External System - EPOS, Mainframe, etc

Time - Timeouts, Scheduled events


What is an Actor?

A Person

An ExternalSystem

Abstractsuch as Time

*

Expected Actors Unexpected Actors

UnauthorizedUsers

AdverseEnvironmentalConditions

Threats

8/13/2019 00 T2 Moreland




What is a Use Case?

Defines how the actors interact with the system

Functionality triggeredby an actor(Primary Actors)

Functionality usedby an actor

Functionality in whichan actor participates(Secondary Actors)

Local operator

MonitorSystem

Remote

Operator

Shutdown

Plant

Customer KioskOperator

Fuel

Transaction

8/13/2019 00 T2 Moreland



A primary actor uses the system to achieve one or more specific goals. A use case

specifies what the system must do to satisfy a goal. Primary actors often initiate

the use case that delivers the goal.

It may be necessary for other actors to interact with the system in some well-

defined manner in order for the primary actors goal to be realized by the system.

These are referred to as secondary actors.

Stereotypes can be used to indicate primary or secondary actors.

An actor represents a role played by a user of the system. This is particularly

relevant where the actor is human; the same person may be capable of playingmore than one role with respect to the system. This situation may also imply a

requirement for access controls to use case functionality.

The UML Generalization relationship (shown using the triangle notation) can be

used to indicate a situation where one actor inherits the same set of use case

interactions shown for another actor. The specialized actor normally also has

additional use case interactions.


Actor Characteristics

Primary actor

Main beneficiary of use case

Normally initiates use case

Secondary actor

Has interaction responsibilities, but does not initiate

*

Actors represent roles

operator, supervisor,

Generalization of actors indicates inheritance of

use case interactions

Operator

Primary

Event Log

System

Secondary

Supervisor

Start LocalSystem

RunDiagnostics

8/13/2019 00 T2 Moreland



It is very important to describe each use case thoroughly and in simple English.

This description should be signed off by the user. This description also acts as a

starting point for a more structured breakdown of the use case in later stages ofdevelopment. For this it can be useful if the description employs a subject - verb

- object format, e.g. customer inserts card.


Use Case descriptions specifydetails

Automated Teller Machine

Withdraw Cash

Transfer FundsDeposit FundsCustomer

Use Case: Withdraw Cash

When a customer inserts a card, the machine reads

the code from the card and checks if it is an

acceptable card. If so it asks the customer for a PINcode (4 digits). If not, the card is ejected.

When the PIN code is received the machine checkswhether the PIN code is correct for the specific

card. If so, the machine asks for what transactionthe customer wishes to perform.

When the customer selects cash withdrawal themachine asks for the amount. Only multiples of $20

are allowed. ...

Use Case: Withdraw Cash

When a customer inserts a card, the machine reads

the code from the card and checks if it is anacceptable card. If so it asks the customer for a PIN

code (4 digits). If not, the card is ejected.

When the PIN code is received the machine checkswhether the PIN code is correct for the specific

card. If so, the machine asks for what transactionthe customer wishes to perform.

When the customer selects cash withdrawal the

machine asks for the amount. Only multiples of $20

are allowed. ...

*

Other Attributes Pre-conditions

Post-conditions(Guarantees)

Constraints

Intent Alternate courses

Stakeholders

Priority

Complexity

8/13/2019 00 T2 Moreland



Basic use cases specify the main services the system provides for its actors,

ignoring exception situations. Subordinate (to their base use cases) use cases can

be specified for specifying exception handling or for specifying functionalactivity duplicated within more than one use case.

We can show the relationships between any subordinate use cases and their base

use cases on the use case diagram.


A single goal may requiremore than one Use Case

Focus initially on the basic Use Cases

The goals for each actor

Fundamental services, ignoring exceptions

Withdraw Cash

Consider optional Use Cases separately

Subordinate, alternate services

Often error or exception handling

Wrong PIN code

Look for repeated functionality

Subordinate, duplicated functional activity

Occur in more than one use case

Validate PIN code

Use Case organization defined by three types of relationship: extend relationship

include relationship

Generalization relationship

*

8/13/2019 00 T2 Moreland




include relationship extractscommon courses of action

Common behavior may be extracted from otheruse cases

Defines a must be done relationship

Simplifies change

*

Card Validation

TransferFunds

WithdrawFunds

Deposit Funds

include

includeinclude

An include relationship can be thought of as a subroutine type of relationship.

In order to Withdraw Funds, Transfer Funds or Deposit Funds, it is essential to

carry out a Card Insertion.

8/13/2019 00 T2 Moreland




extend relationship modelsoptional courses of action

Model an optional part of a usecase

Allows introduction of separatesub-courses without affectingcourse of activity in base usecase

Defines a may get donerelationship

Bank CardTransaction

Reject InvalidCard

extend

In the example we have shown a base use case (Bank Card Transaction) and a

subordinate extended use case (Reject Invalid Card). Reject Invalid Card will

only be invoked from Bank Card Transaction in exceptional circumstances.

8/13/2019 00 T2 Moreland




Generalisation relationshipmodels specialized Behavior

Child use cases inherit from parent use case

Child use cases can extend behavior of parent

Operator

PowerSupply

InitializeSystem

Power UpInitialization

OperatorReset

A generalization relationship between use cases implies that the child use case

contains all the attributes, sequences of behavior, and extension points defined in

the parent use case, and participates in all relationships of the parent use case.The child use case may also define new behavior sequences, as well as add

additional behavior into, and specialize existing behavior of, the inherited ones.

One use case may have several parent use cases and one use case may be a parent

to several other use cases.

It is often possible to use include or extend relationships in place of

generalization.

8/13/2019 00 T2 Moreland



A Use Case defines a service provided by a computer system for an actor. For

instance, in using a word processor, some use cases would be :

Make the text bold;

Create an index;

Spellcheck the document;

The properties of a Use Case are that they :

describe some coherent system function;

may be large or small;

achieve a discrete goal for the actor;

Other possible properties include :

specifying actor intention in using the system;

capturing pre- and post-conditions;

defining alternate courses to the main flow of actions;


Use Cases

Use Cases Use Cases specify, satisfy, realise,

and/or encapsulate functionalrequirements

Provide efficient communicationmechanism between end users

and developers.

Provide a basis for design activity.

Use Cases define system requirements, and therefore systemtest requirements

Define how a goal succeeds or fails.

Provide a framework for constraints and modes models.

Use Cases define testable system requirements from

an external perspective

Use Cases define testable system requirements from

an external perspective

Use Case Name

8/13/2019 00 T2 Moreland




Typical Use Cases

Local operator

RemoteOperator

AmmoniaSystem

Handle Alarm

Stop

Compressor

Start Up Plant

Shutdown

Plant

MaintainGasPressure

StartCompressor

includeinclude

include

include

include

extend

extend

extend

8/13/2019 00 T2 Moreland




Systems Engineering Use Cases

Local operator

RemoteOperator

Ammo niaSystem

Power

Maintainer

SystemInstaller

SafetyEngineer

Start Up Plant

Shutdown

Plant

Maintain GasPressure

Power On Power Fail

Calibrate

Sensors

Replace SystemComponents

Install System

Run SiteAccep tance Tests

Power Off

Alarm

Verification Tests

MonitorSystem

SafetyInspection

include

include

8/13/2019 00 T2 Moreland




Use Case Organisation

Multiple-Levels of Use Cases

Use Case Diagrams can be organisedaround different levels of abstraction

from the System of Systems perspectiveall the way to Use Cases supported by aspecific Sub-System.

Organisation by Domain

The lowest level of abstraction (i.e. theSub-System level) encapsulates all theservices (Use Cases) provided by a

specific domain.

PilotPrimary Actor

Mission Plan

Secondary Actor

CommanderSecondary Actor

NavigatorPrimary Actor

Bombadier

Primary ActorEquivalent

Time

Primary Actor

Power

Primary Actor

Power UpCold

Store

Information

Load Mission

ContinuousBuilt-InTest

Communicate

ExecuteMission

Power UpBuilt-InTest

Power UpWarm

PowerUp

Shutdown

include

include

include

include

include

include

include

SeeExecute Mission Use Case Diagram

SeeStore InformationUse Case Diagram

PilotPrimaryActor

Navigator

PrimaryActorBombadier

PrimaryActorEquivalent

Store Present

Position

Store NavigationInformation

StoreInformation

StoreTargetDestination

StoreSelectedWeaponType

StoreMarkpoint

Store FixError

O n -T o p Fi x H UD F i x

RADARFix

On-Top Mark

HUDMark

RADARMark

StoreWeapons

Information

ombadier Use Cases

avigatorUse Cases

nynumber ofUseCaseDiagramscanbe createdtokeepthediagramstidy. Thisdiagramshows howdifferent

types ofinformationcanbe storedithinthe systemand bywhom.

System

ofSystems

System

Sub-

System

Pilot

Deploy

Weapon

Store Target

Destination

Store Selected

Weapon Type

Store GeodeticPoint

include

include

include

8/13/2019 00 T2 Moreland



Slide 66



A c t i v i t y D iag r a m s A c t i v i t y D i ag r a m s

8/13/2019 00 T2 Moreland




SysML Taxonomy of Diagrams

Diagram

Structure Behavior

Block

Definition

Internal


Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

8/13/2019 00 T2 Moreland




Activity Modelling - Overview

Activity modelling emphasizes the inputs, outputs, sequences,and conditions for coordinating other behaviors. (SysML)

behavior as in something the system does

describes flow of activity and data

can link activity elements to owning block

An activity diagram is owned by an activity and describes the detailof that activity

Useful for many purposes, including:

Exploring system functionality

Human/subsystem communication modelling

Data/item flow modelling

General flow of control modelling

etc.

Activity modeling is one of the principal means for describing behavior in

SysML. This behavior can be linked with structural modeling (blocks)

through allocations which will be covered later in the course.In practice, activity diagrams can be used for a surprisingly wide variety of

modeling purposes. For systems engineering, exploring system functionality

is one of the principal uses of these diagrams.

8/13/2019 00 T2 Moreland




SysML Activity Modelling

SysML activity modelling is based on, and inherits muchfrom, UML 2.0 activity modelling

Key SysML extensions are :

Stronger semantics for activity decomposition

Control as data

Continuous systems

Probability

Although SysML adopts much of the UML activity model, in this section

well consider SysML activity modeling as a whole, not distinguishing

between which aspects are inherited and which are extensions.

8/13/2019 00 T2 Moreland




Activities

Represent a unit of behavior Specifies sequencing of subordinate actions

Can be parameterized

activityparameter

act name

initial node

activity final

action

decision

An activity is the specification of parameterized behavior as the coordinated

sequencing of subordinate units whose individual elements are actions.

[UML]

8/13/2019 00 T2 Moreland




a2 : Activity 2 a3 : Activity 3

act [activity] Activity 1

Activity Decomposition

activityActivity 1

activityActivity 2

activityActivity 3

1

1

a21

1

a3

bddActivity Breakdown

Definition Use

Activity decomposition can be modeled on block definition diagrams Allows initial functional decomposition independent of physical structure Allocation of activities to blocks and parts can be done later

action name

An important aspect of SysML activity modeling is the principle that

activities can be treated like classes or blocks with decomposition and

association relationships modeled on a block definition diagram. The activitydiagram for that activity can then show instances of the sub-activities, where

role names on the bdd become the instance names on the activity diagram.

The meaning of activity decomposition is better defined in SysML (than in

UML). For example, SysML specifies that if a composite activity is

terminated then any currently executing part activities are also terminated.

8/13/2019 00 T2 Moreland




Action Node

Represents a single step within anactivity

not further decomposed

execution starts on entry to the actionnode

and exit occurs when the execution is

completed

Callbehavior is a variant an action node showing a behavior

invocation typically a part activity (activity

name may be hidden)

can be linked to a Block operation

action name : behavior name

action name

These are one of the principle components of activity diagrams. Each action

node defines a single step within the owning activity.

Because activity diagrams can be used in a variety of situations, the wording

of the text can be whatever is best suited to the specific situation.

In general, actions are atomic (i.e. not further decomposed). Where the

action represents a complete sub-activity, typically a part activity on a bdd,

a Callbehavior action is used. This normally has both the bdd role name and

the part activity name displayed, although the latter can be hidden. Activities

can be linked with Block operations these operations are then the

mechanism through which the activity is invoked.

8/13/2019 00 T2 Moreland




Object Node

Represents an instance of a block or data type

helps to define flow in an activity (i.e. what flows)

provides input to and/or is output from an action node

if composite part of activity, then destroyed when activity completed

multiplicity must include 0 instance may not exist throughout activity

a2 :Activity 2 a3: Activity 3

b1 :Block1

Block

dt1 :DataType1DataType

act [activity] Activity 1activityActivity 1

Block::Block1

DataTypeDataType1

activity

Activity 2

activity

Activity 3

0..1

1

b1 0..1

1

dt1

1

1

a2 1

1

a3

bddActivity Breakdown - with objects

object node name

Object nodes allow the modelling of flow of elements through an activity.

Activities can be associated with both blocks and data types as well as other

activities to indicate what type of flow elements relate to the activity. Thiscan be by composition, where the flow element gets destroyed on completion

of the activity.

8/13/2019 00 T2 Moreland




Control and Object Flows

(Activity Edge)

Control Flow Solid or dashed arrow line showing flow of control

Not in to or out from object nodes

Can be named

Object Flow

Solid arrow line linking objects to other elements

Can be named

ction 1 Object

ction 2

ction 1 Object

ction 2

Control flow Object flow

Object flow

Control flow

Control Flows are another key component of activity diagrams, providing

sequencing information. Object flows are only ever used with object nodes.

Both type of flows can be named if required.

Activity Edge is the formal name for both type of flow.

For those familiar with UML activity diagram modeling, note that the

solid/dashed convention is reversed in SysML.

8/13/2019 00 T2 Moreland




Pin vs. Object Node Notation

Pins are kinds of Object Nodes Used to specify inputs and outputs of actions

Typed by a block or data type

Object flows between pins have two diagrammatic forms

Pins shown with object flow between

Pins hidden and object node shown with flow arrows in and out

ObjectNodePins (must be samename & type)

AJM4

8/13/2019 00 T2 Moreland

76/202

lide 75

AJM4 ri ht-hand dia ram should have action:activit like the left-hand one.Alan Moore, 5/17/2006

8/13/2019 00 T2 Moreland




Accept Event shows a signal that initiates activity in action node

may also link to action object (sender)

Examples:

Send Signal and Accept Event

Send Signal

shows a signal sent at completion of action node activity

may also link to action object (receiver)

Send Signal

Accept Event

re-open door

door interruptDoor

Signal send and accept event boxes correspond to the concept of a signal event

on a state diagram. The send represents a signal sent at completion of the

activity in the preceding action node; an accept represents a signal that triggersthe activity of the subsequent action node.

A send may also have an object flow going to the object that receives the signal;

an accept may have an object flow coming from the object that sends the signal.

Dragging an RtS event onto an activity diagram creates a send signal; its

properties can then be used to change it to an accept event if required.

8/13/2019 00 T2 Moreland




Interruptible Activity Region

A bounded region of activity thatcan be terminated prior tocompletion

regionboundary

interrupting event

interrupting

edge

This feature, new to UML 2.0, allows you to explicitly identify areas of activity

where interrupts are allowed to terminate the activity in the region before

completion.In RtS the boundary is a frame box with View Options set to show dashed lines

(strictly, it should have rounded corners). The interrupting edge is a control flow

with waypoints added.

8/13/2019 00 T2 Moreland




Activity Diagram Model Elements

Control Nodes

Coordinate flow in an Activity

Initial Node denotes start of flow in an Activity

Activity Final Node denotes end of flow in an Activity

Flow Final Node denotes termination of a flow

No effect on other flows in the Activity

Decision Node provides choice of outgoing flows

One incoming and multiple outgoing flows

Merge Node brings together multiple alternate flows

Multiple incoming and one outgoing flows

Fork Node splits a flow into multiple concurrent flows

One incoming and multiple outgoing flows Join Node synchronizes multiple flows

Multiple incoming and one outgoing flows

Control Nodes are activity nodes used to provide coordination between other

nodes.

Note that an Activity Final Node denotes end of flow in the entire Activity,

whereas a Flow Final Node only terminates one flow, and has no effect on other

flows (which might still be in effect) in the Activity.

The difference between a Decision Node and a Fork Node lies in the fact that in a

Decision Node, a token arriving at the node will traverse only one of the multiple

outgoing flows, whereas in a Fork Node, the arriving token is duplicated across

the outgoing edges, each of which is traversed concurrently.

Similarly, a Merge Node is not used to synchronize multiple incoming flows, but

to accept one among several alternate flows, whereas a Join Node synchronizes

multiple incoming flows.

8/13/2019 00 T2 Moreland




Activity Partition (Swimlanes)

Named regions separated by horizontal or vertical lines

Define a location for diagram items within their region

Can be nested

Can be used to represent: individuals or groups

geographical locations

systems or subsystems blocks or parts

etc.

8/13/2019 00 T2 Moreland




Nested Swimlanes

Can be nested to any depth Can link to model item

uses model item name

Final Flow terminates

flow of activity in that

swimlane

8/13/2019 00 T2 Moreland




Activity Diagram

Tips: Use swim lanes as placeholders for a role or responsibility.

Allocate activities to each swim lane.

Determine data and control f low between activities within andacross swim lanes.

Determine any synchronisation required across swim lanes.

Determine communication infrastructure to facilitate data andcontrol flow across swim lanes.

8/13/2019 00 T2 Moreland




Explicit Allocation of Behavior

to Structure Using Swimlanes

Activity Diagram

(without Swimlanes)

Activity Diagram(with Swimlanes)

8/13/2019 00 T2 Moreland




Other Activity Related Stereotypes

nobuffer applied to object nodes or parameters

indicates that items arriving at action may be lost

overwrite applied to object nodes or parameters

indicates that arriving item replaces previous item

valid also for FIFO/LIFO queues

optional applied to parameters

indicates that action may begin even without parameter arriving

rate applied to object flow or parameter specifies rate at which items sent/received over object flow

or rate at which items arrive at parameter while action is executing requires {streaming} type parameter

These additional stereotypes are provided to bring greater detail into the

SysML model. Full details are provided in the SysML spec..

8/13/2019 00 T2 Moreland




Probability

probability stereotype applied to

outgoing edges (flows) from decision orobject nodes

Defines value (range: 0 1) for

probability of any flow being taken

Total of values from one node must

equal 1

Can also be applied to output parameter

set from node With same value constraints

action 1

action 2a action 2b

action 1

action 2a action 2b

probabilityprobabilityp (x )

probabilityprobability1-p(x)

When the probability stereotype is applied to edges coming out of decision

nodes and object nodes, it provides an expression for the probability that the

edge will be traversed. These must be between zero and one inclusive, andadd up to one for edges with same source at the time the probabilities are

used. When the probability stereotype is applied to output parameter sets,

it gives the probability the parameter set will be given values at runtime.

These must be between zero and one inclusive, and add up to one for output

parameter sets of the same behavior at the time the probabilities are used.

[SysML]

8/13/2019 00 T2 Moreland




Activity Diagram Distiller Example:

Activity Structure

Block

values

cal/sec : dQ/dt

Item Types::HeatBlock

valuesdegrees C : tempgm/sec : massFlowRatekg/gm^2 : press

Item Types::Residue

ActivityHeat Water

ActivityDistill Water

ActivityBoil Water

ActivityCondense Steam

ActivityDrain Residue Block

Item Types::H2O

BlockProperty cal/gm : specificHeat

BlockProperty cal/(gm*deg C) : latentHeat

Remove Latent Heat of Vaporisation ()

Add Latent Heat of Vaporisation ()

1

1

hotDirty : H20

1

1

pure : H2O

1

1

recovered : Heat 1

1

hiPress : Residue

1

1

loPress : Residue1

1

external : Heat1

1

steam : H2O

1 a1 : Heat Water

1 a2 : Boil Water

1 a3 : Condense Steam 1a4 : Drain Residue

1

1

coldDirty : H2O

bdd [package]DistillerBehavior [Distiller Behaviour Breakdown]

8/13/2019 00 T2 Moreland

87/202

8/13/2019 00 T2 Moreland





I/O Driven: Continuous Parallel Behavior

act [activity]Distill Water [Continuous Parallel Behavior]

pure : H2O

[Liquid]

external : Heat

coldDirty : H2O

[Liquid]loPress : Residue

a1 : Heat Water a3 : Condense Steam

a2 : Boil Water

a4 : Drain Residue

recovered : Heat

hotDirty : H20[ Liquid]

steam : H2O[G as ]

hiPress : Residue

pure : H2O

[Liquid]

external : Heat

coldDirty : H2O

[Liquid]loPress : Residue

a1 : Heat Water a3 : Condense Steam

a2 : Boil Water

a4 : Drain Residue

recovered : Heat

hotDirty : H20[ Liquid]

steam : H2O[G as ]

hiPress : Residue

8/13/2019 00 T2 Moreland




act [activity] Distill Water [Simultaneous Behavior w ith Allocations]

hx1

ShutDown

steam : H2O[G as ]

continuous

hotDirty : H20

[ Liquid]

continuous

recovered : Heat

a3 : Condense Steam

streaming

a1 : Heat Water

streaming

coldDirty : H2O[ Liquid]

continuous

external : Heat

continuous

: Heat Exchanger

allocate

drain

a4 : Drain Residue

pure : H2O

[Liquid]

continuous

loPress : Residue

continuous

:Valve

allocate

bx1

a2 : Boil Waterstreaming

hiPress : Residue

continuous

: Boi ler

allocate


(Allocation with Swimlanes): DistillWater

Parts

8/13/2019 00 T2 Moreland



Slide 89



I n t e ra c t io n s I n t e ra c t io n s

8/13/2019 00 T2 Moreland




SysML Sequence Diagram

Diagram

Structure Behavior

Block

Definition

Internal


Use Case

State

Machine

Sequence

New for

SysML

Requirements

Parametric

Modified

from UML

Same

as UML

The Sequence Diagram is re-used from UML and captures certain aspects of

behavior.

8/13/2019 00 T2 Moreland




Usage Scenarios Overview

Usage Scenarios are created for two reasons:

Understanding the requirements in more detail bycreating a model of the end-users problems (Modellingthe Problem)

Typically however, after defining an initial SystemArchitecture and exploring the capabilities of the

system (captured as Use Cases) youll want to see howthe capabilities are delivered by the components withinthe System Architecture (Modelling the Solution).

8/13/2019 00 T2 Moreland




What is a scenario?

Success scenarios Everything goes well and the actor achieves the Use Case goal

Also called sunny day scenarios.

Defines what is supposed to happen, so that the stakeholders can

agree prior to investigating everything that can go wrong.

Failure scenarios

Models failure conditions and their consequences.

May map to full blown Use Cases that will extend the main UseCase, or

may involve a simple variation on the normal sequence. Scenarios are expressed as interaction diagrams

8/13/2019 00 T2 Moreland




Description

part a:Block A

Blockpart b

:Block B

Blockpart c

:Block C

BlockActor1

seq signal1 {10ms}

par

seq message 1 {250ms}

loop

seq message 2break

seq

max.: {100ms}

message 2end loop

also par

alt

seq message 3

seq message 4( param )end alt

seq signal2

end par

sdSD Concept

Sequence Diagrams

Describe usecase or scenariosequence

Specify timingbudgets andconstraints

Define loops andconditional pathsfor systemfunctionality

Demonstrateparallel andsynchronousfunctionality

8/13/2019 00 T2 Moreland




Interaction Fragment

a piece of interaction [UML] e.g. part of asequence diagram

no defined notation in UML/SysML

represented by an interaction frame in Studio

Loosely defined in the UML as a piece of interaction, it has no specified

notation. In Studio we have made use of the interaction frame element to allow

the scoping of the required piece of interaction.By default, the name given to the fragment is taken from the first description step

covered by the frame, but it can be renamed.

8/13/2019 00 T2 Moreland




Sequence Diagram - Fragments

A Fragment can be drawn around a set of interaction messages.

Fragments are given default names (initalics) depending on

their action:

Weak Sequencing (seq) denoting the order in which interactionsoccur (most Sequence Diagrams are by default weakly sequenced).

Loop (loop) denoting a repeated order of interactions.

Alternative (alt) denoting a choice of behavior.

Strict Sequencing (strict) denoting a specific order of interactions.

Parallel (par) denoting that the fragment contains parallel execution(used for concurrent systems).

Critical Region (critical) denoting an un-interruptible order of

interactions. Option (opt) denoting execution of the fragment or not.

Break (break) denoting the contents of this fragment is executedinstead of the rest of the fragment.

Negative (neg) denoting an invalid order of interactions.

Reference (ref) another interaction diagram.*

These default names can be replaced by something more meaningful if required

in Studio.

8/13/2019 00 T2 Moreland




Sequence Diagram ExampleFragments

Description

part a:Block A

Block

part b:Block B

Block

part c:Block C

BlockActor1

seq signal1 {10ms}

par par

seq message 1 {250ms}

loop loop

seq message 2break

seq

max.: {100ms}

message 2

end loop

also par

alt altseq message 3

seq message 4

end alt

seq signal2

end par

sdSD Fragments

8/13/2019 00 T2 Moreland




Interaction Use

a reference from a step on one sequence diagram to aninteraction (represented by another sequence diagram in Studio)

allows partitioning of the interaction model e.g. a single use case

can be split over several diagrams

This is a powerful facility within UML 2.0 that provides behavioural

decomposition. With Studio an interaction use can be represented as a reference

frame linked to another diagram. The referenced diagram can be anothersequence diagram, or it can be an activity diagram, and it can be opened through

the context menu of the frame.

8/13/2019 00 T2 Moreland




Part Decomposition

a reference from an interaction entity (not necessarily a part) on onediagram to another diagram

allows decomposition of the interaction model e.g. the internalinteractions taking place within the entity, as a result of a message,can be shown separately

Similar in principle to an interaction occurrence, this form of decomposition

reflects the structural decomposition represented on internal block diagrams.

In the above example the referenced Start Boiler [detail] diagram would showthe interactions taking place between the component parts within the Boiler part

of the Distiller in order for the Boiler part to implement the powerOn operation.

Typically then, there would be a internal block diagram (ibd) that would show the

interaction entities shown above with connectors consistent with the above

messaging, and there would be another internal block diagram showing the

internal component parts of the Boiler and their connectors. It is these internal

parts and their messaging that would be shown in the Start Boiler [detail]

diagram.

8/13/2019 00 T2 Moreland




Part Decomposition - Example

Description:DistillerBlock

Distiller.ui1:Control PanelBlockProperty

Distiller.bx1:Boilerref Start Boiler

BlockPropertyUser

start up StartUpstart Distiller TurnOn

start Boiler powerO n

Description

:Boiler

BlockBoiler.heater:Element

BlockPropertyBoiler.vOverFlow:Valve

BlockPropertyBoiler.vResidue:Valve

BlockProperty

power on boiler powerOn

witch on heater onopen overflow open

open residue open

sd Start Boiler

This example illustrates interaction modelling at 2 different levels of abstraction:

black box (top diagram) and white box levels. The lower diagram is modelling

what happens inside the boiler on receipt of the powerOn message.

Note the names of the various BlockProperty parts, indicating their parent block,

as well as their block type.

8/13/2019 00 T2 Moreland



Copyright 2006 ARTISAN Software Tools All Rights ReservedS l i d e 1 0 0

Description:C ontr o l Pa ne l

Block:C ontr o l l e r

Bl oc k Us er

press start StartUp

turn on Distiller p w r O nshow powe

00 T2 Moreland

Documents

Transcript of 00 T2 Moreland