Introduction to SysML Introduction to SysML

(1)

Slide 1

Introduction to SysML Introduction to SysML

An Introduction to the An Introduction to the

OMG Systems Modeling Language OMG Systems Modeling Language

(OMG SysML (OMG SysML ™) ™ )

Published and used by INCOSE and affiliated societies with permission.

Clarence C. Moreland Clarence C. Moreland Principal Consultant,

Principal Consultant,ARTiSAN Software ToolsARTiSAN Software Tools

(2)

Slide 2

Caveat

• This material is based on the Final Adopted SysML specification (ad-06-05-04)

– Adopted by OMG in May ’06

• Some of the slides are based on the OMG SysML tutorial and are used with permission.

• OMG SysML Website

– http://www.omgsysml.org/

(3)

Slide 3

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

(4)

Slide 4

Agenda

Introduction

Systems Engineering with SysML

Requirements and Requirements Diagrams Structural Diagrams

Blocks and Block Diagrams Behavioral Diagrams

Use Case modelling

Activities and Activity Diagrams Sequence Diagrams

State Machines Cross-cutting Concepts

Requirements traceability Allocations

Package Diagram Parametric Diagrams Process Issues

Q&A

(5)

Slide 5

SE Practices for Describing Systems

• Specifications

• Interface requirements

• System design

• Analysis & Trade-off

• Test plans

Moving from Document centric to Model centric Moving from Document centric to Model centric Past

Past FutureFuture

(6)

Slide 6

System Modeling

Requirements

Integrated System Model Must Address Multiple Aspects of a Syste Integrated System Model Must Address Multiple Aspects of a Systemm

(7)

Slide 7

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)

Slide 8

What is SysML?

• A graphical modelling language in response to the UML for Systems Engineering RFP developed by the OMG,

INCOSE, and AP233

– a UML Profile that represents a subset of UML 2 with extensions

• 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 the evolving AP233 standard (in-process)

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

(9)

Slide 9

What is SysML (cont.)

• Is a visual modeling language that provides

– Semantics = meaning

– Notation = representation of meaning

• Is not a methodology or a tool

– SysML is methodology and tool independent

(10)

Slide 10

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 finalization – Being implemented by multiple tool vendors

(11)

Slide 11

SysML Team Members

• Industry & Government

– American Systems, BAE SYSTEMS, Boeing, Deere & Company, EADS-Astrium, Eurostep, Lockheed Martin, NIST, Northrop Grumman, 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

(12)

Slide 12

Introduction to SysML Introduction to SysML

Diagram Overview

(13)

Slide 13

Reuse of UML 2.0 for SysML

UML 2.0

SysML

UML not required by

SysML

SysML Extensions UML reused

by SysML

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

(14)

Slide 14

Stereotypes & Model Libraries

• Mechanisms for further customizing SysML

• Profiles represent extensions to the language

– Stereotypes extend meta-classes with properties and constraints

• Stereotype properties capture metadata about the model element – Profile is applied to user model

– Profile can also restrict the subset of the meta-model used when the profile is applied

• Model Libraries represent reusable libraries of model elements

(15)

Slide 15

Stereotypes

Defining the Stereotype Applying the Stereotype

(16)

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 tag

definition (named, for example, ‘cost’) to the stereotype through which a tag value (for example, “24.50”) can be specified for that board.

(17)

Slide 17

Applying a Profile and

Importing a Model Library

(18)

Slide 18

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 are

consistent 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 SysML behavior 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]

(19)

Modelling and Your Project

• Not all diagram types are essential

– most projects will only use a subset

• You may have additional ‘specialized’

modelling 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 modeling capability 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.

(20)

Slide 20

ibd[Block] Anti-Lock Controller1

«Block»

Anti-Lock Controller

«BlockProperty»

d1 : Traction Detector

«BlockProperty»

m1 : Brake Modulator

«BlockProperty»

d1 : Traction Detector

«BlockProperty»

m1 : Brake Modulator c1:modulator interface

use

interaction

par[constraint] StraightLineVehicleDynamics [Parametric Diagram]

: AccelerationEquation

F c

a : BrakingForceEquation

tf tl bf

f

: DistanceEquation v x

: 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 System Specification

Braking Subsystem Specification

«requirement»

id#

102 txt The vehicle shall stop from 60 mph within 150ft on a clean dry surface.

Stopping Distance

«requirement»

id#

337 txt The Braking subsystem shall prevent wheel lockup under all braking conditions.

Anti-Lock Performance req[Package] Vehicle Specifications [Braking]

«deriveReqt»

3. Requirements

bdd[Package] Vehicle [ABS]

«Block»

Library::

Electronic Processor

«Block»

Anti-Lock Controller

«Block»

Library::

Electro-Hydraulic Valve

«Block»

Traction Detector

«Block»

Brake Modulator

d1 m1

definition

Gripping Slipping

Los s O fTrac tion/

RegainTrac tion/

stmTire [Traction] state machine

Detec t Loss Of

Trac tion TractionLoss Modulate

B raking Forc e actPreventLockup

activity/

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

(21)

Slide 21

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 the diagram is complete, or has elements hidden

Header

Contents

Diagram Description Version:

Description:

Completion status:

Reference:

(User-defined fields)

«diagram usage»

diagramKind[modelElementType] modelElementName [diagramName]

(22)

Slide 22

Introduction to SysML Introduction to SysML

Requirements

(23)

Slide 23

The Requirements Diagram

Diagram

Block Definition

Internal

Block Package Activity

Requirements

as UML

The Requirements diagram sits out side the Structure/behavior organization of the remaining SysML diagram types.

(24)

Slide 24

What are Requirements?

• Statement of a customer’s needs and expectations

• Describes the essential characteristics of the customers goals

• Requirements should be problem based and not describe the solution. However, if there are solution based elements in the requirements, these must be modelled and included in the solution.

(25)

Slide 25

The SysML Requirements Diagram

What is it used for?

• The Requirements diagram can be used for a variety of 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. It’s main strength is in its ability to graphically represent requirements and how they pertain to the rest of the UML model.

(26)

Slide 26

Requirements

• A requirement “specifies a capability or condition that must (or should) be satisfied” [SysML]

• Can specify function to be performed or performance criteria to 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 specific properties, e.g.

– Requirement type (Performance,Safety, Functional, etc.) – Criticality

– Test method – Status – Etc.

«requirement»

txt The System shall do...

reqtType function

REQ_A1

(27)

Slide 27

SysML Requirements Diagram Elements

Design Elements Model Element C Model Element C

Model Element T

Model Element A

«testCase»

Model Element B

«requirement»

txt The System shall do...

reqtType function

REQ_A1

«requirement»

REQ_A1.1

«requirement»

REQ_A1.2

«requirement»

REQ_B1

«requirement»

REQ_C

«rationale»

explanation

«problem»

description of problem

«requirement»

derivedFrom REQ_A1.1 reqRequirement Diagram 1

«deriveReqt»

«refine»

«trace»

«satisfy»

«verify»

Requirement

Callout

Containment

«requirement»

txt same 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 if required.

Containment (sometimes referred to as ‘flowdown’) is used to show where requirements are decomposed into sub-requirements.

The«deriveReqt»and«copy»relationships can only exist between

requirements. «trace», «refine», «satisfy» and «verify»can exist between a requirement and any other model element.

The«verify»relationship 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 – only one example of thecallout notationis shown here.

«problem»and«rationale»comments can be added as required to any model element to capture issues and decisions.

(28)

Slide 28

SysML Requirements Diagram Example

«activity»

Distill Water

«UseCase»

Distill Water

«requirement»

txt The system must be able to connect directly to mains water

Water Input

«requirement»

txt

Distill dirty water into pure water Produce Distilled Water

«requirement»

txt The pure water output must be at a safe temperature

Water Output

«requirement»

txt The system shall handle 1 litre of water per minute

Water Throughput Customer Brochure

«requirement»

txt The system shall have an input valve that is closed when the system is off Provide Input Protection

«requirement»

txt The system must have an overflow valve in the main heating vessel

Handle Overflow

«requirement»

txt The condenser needs to cool the pure water to 30

°C

Condenser Efficiency

«refine»

«satisfy»

«trace»

«deriveReqt»

«^rationale»

Analysis of this activity show s that the throughput is possible

«^rationale»

Direct connection to high pressure mains w hen the system is off might cause damage

«^rationale»

High pressure w ater may overpow er the boiler so an overflow valve is needed

«^rationale»

30 ° is deemed a safe output temperature req[package] UserRequirements

(29)

Slide 29

Problem and Rationale

Problem and Rationale can be attached to any Problem and Rationale can be attached to any Model Element to Capture Issues and Decisions Model Element to Capture Issues and Decisions

(30)

Slide 30

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 a proposed launch date of Spring 2003. Finance have made £300K available for Conception and Development (including any re-tooling and training on the production line). The estimated profit margin is 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 wil l be held in 4- months to determine ‘go- ahead’ of Development (and subsequent) phases. Target market: Executive Fleet and Family.

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 C ontrol and Diagnostics);

Advanced Breaking System (ABS); Electric Windows & Seat Adjustme nt and Heating (Front seats only, Front windscreen only); …

Optional:

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

The Business Case

Willspecify the Requirement for a System (e.g. a Car)

Mayinclude (solution-based) capabilities of the System (e.g. Cruise Control, EMS, ABS)

Mayinclude 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. The Business Case will also identify business-level Constraints e.g. Development and Production time and cost limits.

(31)

Slide 31

Introduction to SysML Introduction to SysML

SysML Structure

(32)

Slide 32

Block Diagrams

Diagram

Internal

Requirements

as UML

(33)

Slide 33

Blocks are Basic Structural Elements

• Provides a unifying concept to describe the structure of an element or system

– Hardware – Software – Data – Procedure – Facility – Person

• Multiple compartments can describe the block characteristics

– Properties (parts, references, values) – Operations

– Constraints

– Allocations to the block (e.g. activities) – Requirements the block satisfies

(34)

Slide 34

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 (not composition)

• 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

(35)

Slide 35

Using Blocks

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

– Differentiates value properties from part properties, add nested connector ends, etc.

• Block definition diagram describes the relationship among blocks (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 Interconnection Blocks Used to Specify Hierarchies and Interconnection

(36)

Slide 36

bdd[Package] Block Defintion Diagram [bdd- Notation]

«Block»

::Block1

«Block»

parts myPart : Block4 refParts : Block6 [*]

sharedPart : Block5 [0..1]

references refParts : Block6 [*]

values aValue : ValueType1

Block2

«Block»

::Block1::Block3

«Block»

Block4

«Block»

Block5

«Block»

Block6

«ValueType»

dimension Dimension1

unit Unit1

ValueType1

Actor1 1

1

myPart 0..1

1 sharedPart

* 1

refParts

1 1

Block Definition Diagram (bdd) Notation

Generalization

Namespace containment

Reference association

Shared association Part

association

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 part

association shows exclusively owned parts, a shared association indicates parts shared with other blocks. Multiplicity values indicate the number of parts.

(37)

Slide 37

ibd[Block] Block2 [ibd Notation]

«Block»

Block2

«BlockProperty»

myPart : Block4

fPort1

fPort3

«BlockProperty»

0..1 sharedPart : Block5 fPort2

sPort

«BlockProperty»

* refParts : Block6

fPort4

Actor1

pI/F

rI/F ItemFlow1 : ItemType

«ItemFlow»

ItemFlow3 : DataType2

«ItemFlow»

ItemFlow2 : ValueType1

«ItemFlow»

Internal Block Diagram (ibd) Notation

Enclosing Enclosing

Block Block

Connector Connector Port

Port Item Flow

Item Flow

Internal Block Diagram Specifies Internal Block Diagram Specifies

Interconnection of Parts Interconnection of Parts

Reference Reference Property Property

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

Part Part

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

(38)

Slide 38

Parts

• A Part is a property of a block that the block requires in order to exist

• Used to illustrate the hierarchical composition of a system and its components

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

• A referenced property is a part not owned by its enclosing block, but referenced by some other part of that enclosing block

(39)

Slide 39

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 whatcanflow 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

(40)

Slide 40

Port Notation

«BlockProperty»

part1 sp1sp1

«BlockProperty»

part2 sp2

sp2

«BlockProperty»

part1

fp1 : ItemType1 fp1 : ItemType1

«BlockProperty»

part2 fp2 : ItemType1

fp2 : ItemType1

«BlockProperty»

part1

fp3 : FlowSpec1 fp3 : FlowSpec1

«BlockProperty»

part2 fp4 : FlowSpec1

fp4 : FlowSpec1

Interface1 Interface1

Standard Port Standard Port

Atomic Flow Port Atomic Flow Port

Non

Non--atomic Flow Portatomic Flow Port

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.

(41)

Slide 41

Unit and Item Types

• Unit types normally based on Real

• SI Units and Dimensions defined in SysML appendix

«block»

values lh : J/kg = 520 m : kg = 0 press : Pa sh : J/kg/°C = 1 t : °C

H2O

«block»

values Q : J

Heat

«block»

values lh : J/kg = 520 press : Pa sh : J/kg/°C = 1 t : °C

Residue

«block»

values lh : J/kg = 520 press : Pa sh : J/kg/°C = 1 t : °C

Fluid

«block»

values p : W

Electricity bdd[package] Items

«valueType»

dimension = mass unit = kilogram

kg

«valueType»

dimension = temperature unit = degrees Centigrade

ºC

«valueType»

unit = Joules J

«valueType»

unit = kilograms/second kg/s

«valueType»

dimension = pressure unit = kilograms/square meter

kg/m² bddUnits

(42)

Slide 42

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 : Fuel out FuelReturn : Fuel

FPump-ICE

flowPropertyList in TorqueIn : Torque out TorqueOut : Torque

TorqueSpec

«valueType»

Analogue

flowPropertyList in Value : V

Digital

«Interface»

EMU Msg Send ()

«Interface»

Set Throttle Set Throttle ()

«block»

values MassFlowRate : gm/sec Press : kg/m² Temp : °C

Liquid

«block»

values MassFlowRate : gm/sec Press : kg/m² Temp : °C

Fuel

«valueType»

°C

«valueType»

kg/m²

«valueType»

gm/sec

«valueType»

SysML Extras::SI Unit Types::A

«Interface»

TransmIF Gear ()

Temp

Press

MassFlowRate bdd[package] Flow Specifications

Flow Flow Specification Specification

Interface Interface

Block

Block Value TypeValue Type

(43)

Slide 43

Delegation Through Ports

• Delegation can be used to preserve encapsulation of block

• Interactions at outer ports of Block1 are delegated to ports of child parts

• Ports must match (same kind, types, direction etc.)

• (Deep-nested)

Connectors can break encapsulation if required (e.g. in physical system modelling)

Child2:

Child1:

ibd[block]Block1[delegation]

(44)

Slide 44

Connectors and Flows

«BlockProperty»

Part 1 : Block B

fp1 : FlowSpec1

fp1 : FlowSpec1 «BlockProperty»

Part 2 : Block C fp2 : FlowSpec1

fp2 : FlowSpec1

«ItemFlow»

Flow Ports – type specifies what canflow

in/out

Item Flow - Specifies what

doesflow (in context)

Connector

«FlowSpecification»

flowPropertyList in FlowProperty1 : Block3 out FlowProperty2 : DataType1 inout 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, or continuous 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.

(45)

Slide 45

Structure vs. Usage

Definition

– Block is a definition/type – Captures properties, etc.

– Reused in multiple contexts

Usage

– Part is the usage in a particular context – Typed by a block – Also known as a role Block Definition Diagram Internal Block Diagram

(46)

Slide 46

Block Definition Diagram Example

• Parts compartment shows structural children

• Values compartment shows properties of the block

• Flowports compartment describes the interface to the block

• Operations compartment shows functional

capabilities (a means of invoking block activities – dealt with later)

bdd[Package] Distiller [Structure - with compartments]

«Block»

operations TurnOn () TurnOff ()

parts bx1 : Boiler cx1 : Controller drain : Valve feed : Valve hx1 : Heat Exchanger ui1 : Control Panel

flowPortList out DSClean_Out : H2O in DSDirty_Out : H2O out DSExcess : H2O in DSPower_In : Power out DSResidue_Out : Residue

Distiller

«Block»

values Max : temp Min : temp

flowPortList out BLExcess : H2O in BLHotDirty_In : H2O in BLPower_In : Power inout blrSig : blrSig out BLSteam_Out : H2O out BLSteam_Out2 : Residue

Boiler

«Block»

flowPortList in Feed_HotDirty_In : H2O out Feed_HotDirty_Out : H2O in Fluid_In : Fluid out Fluid_Out : Fluid

Valve

«Block»

values tempGradient : Real

flowPortList out HEClean_Out : H2O in HEDirtyIn : H2O out HEHotDirty_Out : H2O in HESteam_In : H2O

Heat Exchanger

«Block»

Control Panel

«Block»

operations pwrOn () ResidueTimer () DrainTimer () shutDown ()

Controller

User bx1

drain hx1

1 1

feed

1 1

ui1 1

1

cx1

1 1

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 block diagram (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.

(47)

Slide 47

ibd[block] Distiller

IBD for Distiller

• Non-Atomic Flow Ports (BC and HEC) – I/O is specified using FlowSpecification – FlowSpecification consists of properties

stereotyped «FlowProperty»

– isConjugate promotes reuse of flowSpecifications

• Atomic FlowPorts (dirtyWater, extPower …)

– In this case the port is directly typed by the item type (Block or ValueType) – Direction property specifies the

direction of flow

blockDis tiller

PureWater

loPressResidue dirtyWater

hx : HeatExchanger fIn : Fluid

pFOut

HEC

tempWrn

bl : Boiler SOut BC

excess blWrn

PwrIn Rcnt Ocnt controller : Controller

ui

vO

vD wrn

pwrIn blrPwr vI

UI : FrontPanel cnt

User

overFlow

extPower inValve :

FlowValve ip

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

«^problem»

Overflow water is very hot!

(48)

Slide 48

Internal Block Diagram Example 2 : Drill-down to show Boiler internals

ibd[Block] Boiler [drill down]

«Block»

Boiler

«BlockProperty»

heater : Element

ELPower_In : Power ELHeat_Out : Heat

«BlockProperty»

tank : Heating Vessel

HVHeat_In : Heat HVHotDirty_In : H2O

HVSteam_Out : H2O

HVSludge : Residue

HVExcess : H2O

BLHotDirty_In : H2O BLSteam_Out : H2O

BLSteam_Out2 : Residue

«BlockProperty»

vOverFlow : Valve Fluid_In : Fluid

Fluid_Out : Fluid

«BlockProperty»

vResidue : Valve Fluid_In : Fluid

Fluid_Out : Fluid

BLPower_In : Power

BLExcess : H2O

«BlockProperty»

heater : Element

ELPower_In : Power ELHeat_Out : Heat

«BlockProperty»

tank : 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

«BlockProperty»

vOverFlow : Valve Fluid_In : Fluid

Fluid_Out : Fluid Fluid_In : Fluid

Fluid_Out : Fluid

«BlockProperty»

vResidue : 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 on block 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.

(49)

Slide 49

Introduction to SysML Introduction to SysML

Use Cases

(50)

Slide 50

SysML Use Case Diagram

Diagram

Internal

Requirements

as UML

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

(51)

Slide 51

Use Cases

• Provide means for describing basic functionality in terms of usages/goals of the system by actors

• Common functionality can be factored out via include and extend relationships

• Generally elaborated via other behavioral representations to describe detailed scenarios

• No change to UML

(52)

Slide 52

Use Case Diagram

Flight Crew

Navigator

Pilot

Air-To-Air Tracking Air-To-Ground

Strike Weather Monitoring

Actor Generalisation

Actor Subject

Boundary

Use Case

Subject Name ucDiagram 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.

(53)

What is a Use Case?

*

• Use Cases describe the goals that actors have in relation to the system.

• A Use Case meets a need or solves a problem for an actor.

• So, what is an Actor ?

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

• Actors should reflect the entire system lifecycle including:

manufacture, test, installation, maintenance, etc.

(54)

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 External System

Abstract such as Time

*

Expected Actors

Unexpected Actors

Unauthorized Users

Adverse

Environmental Conditions

Threats

(55)

Slide 55

What is a Use Case?

• Defines how the actors interact with the system

– Functionality triggered by an actor

(Primary Actors)

– Functionality used by an actor

– Functionality in which an actor participates (Secondary Actors)

Local operator

Monitor System Remote

Operator

Shutdown Plant

Customer Kiosk

Operator Fuel

Transaction