An Introduction to OMG Systems Modeling Lang · • Is a visual modeling language that provides ... Grumman, oose.de, Raytheon, THALES • Vendors – Artisan, EmbeddedPlus, Gentleware,

©2008, ARTiSAN Software Tools 1

Introduction to SysML

Slide 1

Introduction to SysMLIntroduction to SysML

Copyright © 2006 ARTISAN Software Tools All Rights Reserved

An Introduction to theAn Introduction to theOMG Systems Modeling LanguageOMG Systems Modeling Language

(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. MorelandPrincipal Consultant,Principal Consultant, ARTiSAN Software ToolsARTiSAN Software Tools



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/




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




Agenda

IntroductionSystems Engineering with SysMLRequirements and Requirements DiagramsStructural Diagrams

Blocks and Block DiagramsBehavioral Diagrams

Use Case modellingActivities and Activity DiagramsSequence DiagramsState Machines

Cross-cutting ConceptsRequirements traceabilityAllocationsPackage DiagramParametric Diagrams

Process IssuesQ&A




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

PastPast FutureFuture




System Modeling

Requirements

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




Model Based SystemsEngineering 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



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




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




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



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



Slide 12


C opyright© 2006 ARTISAN Software Tools All Rights Reserved

Diagram OverviewDiagram Overview




Reuse of UML 2.0 for SysML

UML 2.0SysML

UML notrequired by

SysML

SysMLExtensions

UML reusedby SysML

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




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 used

when the profile is applied

• Model Libraries represent reusable libraries of modelelements




Stereotypes

Defining the Stereotype Applying the Stereotype



Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 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 additionalinformation to that element. In the example of a «COTS» stereotyped board youmight 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 tagvalue (for example, “24.50”) can be specified for that board.




Applying a Profile andImporting a Model Library




SysML Taxonomy of Diagrams

Diagram

Structure Behavior

BlockDefinition [1]

InternalBlock [2]

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas 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 UMLdiagrams are strictly re-used such as use case, sequence, state machine, andpackage diagram, whereas in other cases they are modified so that they areconsistent with SysML extensions. For example, the block definition diagram andinternal block diagram are similar to the UML class diagram and compositestructure diagram respectively, but have extensions or omissions. Activitydiagrams 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, anddeployment diagram. This is consistent with the approach that SysML represents asubset of UML. In the case of deployment diagrams, the deployment of software tohardware can be represented in the SysML internal block diagram. In the case ofinteraction overview and communication diagrams, it is felt that the SysMLbehavior diagrams provided adequate coverage for representing behavior withoutthe need to include these diagram types. Two new diagram types have been addedto SysML : the requirement diagram and the parametric diagram.

[SysML v1.0]



Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide19

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, toinclude standards, notation and information relevant to the organization, itscustomers, and the projects it undertakes. This need to extend the modelingcapability of the language is recognized within the UML by the specification ofextension mechanisms. The UML provides a mechanism for extending orcustomizing modeling information. This mechanism uses the above concepts to‘label’ model elements and to define additional properties for them.



C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 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]

: AccelerationEquationF 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 from60 mph within 150ft on aclean dry surface.

Stopping Distance

«requirement»

id#337

txtThe Braking subsystem shallprevent wheel lockup underall braking conditions.

Anti-Lock Performance

req [Package] Vehicle Specifications [Braking]

«deriveReqt»

3. Requirements

bdd [Package] Vehicle [ABS]

«Block»Library::

ElectronicProcessor

«Block»Anti-LockController

«Block»Library::

Electro-HydraulicValve

«Block»TractionDetector

«Block»Brake

Modulator

d1 m1

definition

Gripping Slipping

Los sOfTrac tion/

RegainTrac tion/

stm Tire [Traction] state machine

Detect Loss OfTraction

TractionLoss ModulateBraking Force

act PreventLockup activity/function

Structuree.g., system hierarchies, interconnections

behavior

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

Propertiese.g., parametric models, time variable attributes

Requirements

e.g., requirements hierarchies, traceability




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]



Slide 22



RequirementsRequirements




The Requirements Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML

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




What are Requirements?

• Statement of a customer’s 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.




The SysML Requirements DiagramWhat is it used for?

• 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. It’s main strength is in its ability to graphicallyrepresent requirements and how they pertain to the rest of the UML model.




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

reqtTypefunction

REQ_A1




SysML Requirements DiagramElements

Design Elements

Model Element CModel Element C

Model Element T

Model Element A

«testCase»Model Element B

«requirement»

txtThe System shall do...

reqtTypefunction

REQ_A1

«requirement»REQ_A1.1


«requirement»REQ_B1

«requirement»REQ_C

«rationale»explanation

«problem»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 ofrelationship 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 whererequirements are decomposed into sub-requirements.

The «deriveReqt» and «copy» relationships can only exist betweenrequirements. «trace», «refine», «satisfy» and «verify» can exist between arequirement and any other model element.

The «verify» relationship can only exist between a requirement and a behavioralmodel 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» and «rationale» comments can be added as required to any modelelement to capture issues and decisions.




SysML Requirements DiagramExample

«activity»Distill Water

«UseCase»Distill 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 30°C

Condenser Efficiency

«refine»

«satisfy»

«trace»

«deriveReqt»

«deriveReqt»

«deriveReqt»

«rationale»Analysis of this activityshow s that the throughputis possible

«rationale»Direct connection to highpressure mains w hen thesystem is off might causedamage

«rationale»High pressure w ater mayoverpow er the boiler soan overflow valve isneeded

«rationale»30 ° is deemed a safeoutput temperature

req [package] UserRequirements




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




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 wil l be held in 4-months todetermine ‘go-ahead’ of Development (and subsequent) phases. Target market: Executive Fleet andFamily.

Feature-Set

StandardFront-Wheel Drive, Front-engine, 5-Door (hatch-back), 5-Seat three-point inertial seat -belts (standardoptions 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)

May include (solution-based) capabilities of the System (e.g. CruiseControl, EMS, ABS)

May include Constraints (e.g. Cost, Time, Component Reuse, Tooling)

The Business Case defines that a ‘System’ is required and defines therequirements of the ‘System’ from the Business perspective. This will includesome high-level decisions regarding the ‘Systems’ Capabilities and Usage. TheBusiness Case will also identify business-level Constraints e.g. Development andProduction time and cost limits.



Slide 31



SysML StructureSysML Structure




Block Diagrams

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML




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




Block Property Types

• Property is a structural feature of a block– Part property aka. 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




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 amongblocks (e.g., composition, association, classification)

• Internal block diagram describes the internal structure of ablock 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




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

«Block»::Block1

«Block»

partsmyPart : Block4refParts : Block6 [*]sharedPart : Block5 [0..1]

referencesrefParts : Block6 [*]

valuesaValue : ValueType1

Block2

«Block»::Block1::Block3

«Block»Block4

«Block»Block5

«Block»Block6

«ValueType»

dimensionDimension1

unitUnit1

ValueType1

Actor1

1

1

myPart 0..1

1

sharedPart

*1refParts

11

Block Definition Diagram (bdd)Notation

Generalization

Namespacecontainment

Referenceassociation

SharedassociationPart

association

Multiplicity

Compartments

Part (role)names

Examples of blocks, and part, reference and value properties are shown here. Thegeneralization relationship indicates that Block 2 inherits properties of Block 1. Thereference association is used to indicate which parts are reference parts. A partassociation shows exclusively owned parts, a shared association indicates parts sharedwith other blocks. Multiplicity values indicate the number of parts.




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

EnclosingEnclosingBlockBlock

ConnectorConnector

PortPort

Item FlowItem Flow

Internal Block Diagram SpecifiesInternal Block Diagram SpecifiesInterconnection of PartsInterconnection of Parts

ReferenceReferencePropertyProperty

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

PartPart

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




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




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 what can 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




Port Notation

«BlockProperty»part1 sp1sp1

«BlockProperty»part2sp2sp2

«BlockProperty»part1

fp1 : ItemType1fp1 : ItemType1«BlockProperty»

part2

fp2 : ItemType1fp2 : ItemType1

«BlockProperty»part1

fp3 : FlowSpec1fp3 : FlowSpec1«BlockProperty»

part2

fp4 : FlowSpec1fp4 : FlowSpec1

Interface1 Interface1

Standard PortStandard Port

Atomic Flow PortAtomic Flow Port

NonNon--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) specifiesrequired 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.




Unit and Item Types

• Unit typesnormally basedon Real

• SI Units andDimensionsdefined in SysMLappendix

«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 = massunit = 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




Port Typing

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

«flowSpecification»

flowPropertyListin FuelSupply : Fuelout FuelReturn : Fuel

FPump-ICE


flowPropertyListin TorqueIn : Torqueout TorqueOut : Torque

TorqueSpec

«valueType»Analogue


flowPropertyListin Value : V

Digital

«Interface»EMU Msg

Send ()

«Interface»Set Throttle

Set Throttle ()

«block»

valuesMassFlowRate : gm/secPress : kg/m²Temp : °C

Liquid

«block»

valuesMassFlowRate : gm/secPress : 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

FlowFlowSpecificationSpecification

InterfaceInterface

BlockBlock Value TypeValue Type




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]




Connectors and Flows

«BlockProperty»Part 1 : Block B

fp1 : FlowSpec1fp1 : FlowSpec1 «BlockProperty»Part 2 : Block C

fp2 : FlowSpec1fp2 : FlowSpec1

ItemFlow1 : DataType1«ItemFlow»ItemFlow1 : DataType1«ItemFlow»

Flow Ports –type specifieswhat can flow

in/out

Item Flow -Specifies what

does flow(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 theconnector. 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 specificcontext of a specific diagram is specified by one or more item flows, whose typemust be consistent with that of the flow ports.




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




Block Definition DiagramExample

• Parts compartmentshows structural children

• Values compartmentshows properties of theblock

• Flowports compartmentdescribes the interfaceto the block

• Operations compartmentshows functionalcapabilities (a means ofinvoking block activities– dealt with later)

bdd [Package] Distiller [Structure - with compartments]

«Block»

operationsTurnOn ()TurnOff ()

partsbx1 : Boilercx1 : Controllerdrain : Valvefeed : Valvehx1 : Heat Exchangerui1 : Control Panel

flowPortListout DSClean_Out : H2Oin 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

«Block»Control Panel

«Block»

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

Controller

User

bx1

drain

hx1

1

1

feed

1

1

ui1

1

1

cx1

11user

The block definition diagram (bdd) shows block properties. Which specific blockproperties are shown is down to the choice of the modeler.

Parts (part properties) are normally shown using the UML composition relationship (thefilled in diamond), where the role names at the other end of the relationship specify thepart name (the block name at that end specifying the type). Part properties can also beshown in the Parts compartment of the containing block.

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

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 operationspecifies a functional capability of the block, and acts as a means through which blockactivity can be invoked. This topic is dealt with in greater detail later in the course.




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 bythe item type (Block or ValueType)

– Direction property specifies thedirection of flow

block Distiller

PureWater

loPressResidue

dirtyWater

hx :HeatExchangerfIn : Fluid

pFOut

HEC

tempWrn

bl : Boiler

SOut

BC

excess

blWrn

PwrIn

Rcnt

Ocntcontroller : Controller

ui

vO

vD

wrn

pwrIn

blrPwr

vI

UI : FrontPanelcnt

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

« problem»Overflow water isvery hot!




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 : HeatHVHotDirty_In : H2O

HVSteam_Out : H2O

HVSludge : Residue

HVExcess : H2O

BLHotDirty_In : H2O

BLSteam_Out : H2O

BLSteam_Out2 : Residue

«BlockProperty»vOverFlow : Valve

Fluid_In : FluidFluid_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

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


«BlockProperty»vOverFlow : Valve



«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 thisdiagram from the information on the previous diagram.



Slide 49



Use CasesUse Cases




SysML Use Case Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML

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




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




Use Case Diagram

Flight Crew

Navigator

Pilot

Air-To-AirTracking

Air-To-GroundStrike

WeatherMonitoring

ActorGeneralisation

Actor SubjectBoundary

Use Case

Subject Nameuc Diagram 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 theouter frame.



Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 53

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.



An actor is “anything outside the system to which the system interfaces”. Thismay be a person, an external system or item of equipment, or some more abstractconcept such as time.

Examples:

Person - Pilot, Operator, Maintainer, etcExternal 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




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

RemoteOperator

ShutdownPlant

Customer KioskOperator

FuelTransaction



A primary actor uses the system to achieve one or more specific goals. A use casespecifies what the system must do to satisfy a goal. Primary actors often initiatethe 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 actor’s 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 particularlyrelevant 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 arequirement for access controls to use case functionality.

The UML Generalization relationship (shown using the triangle notation) can beused to indicate a situation where one actor inherits the same set of use caseinteractions shown for another actor. The specialized actor normally also hasadditional 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 LogSystem

«Secondary»

Supervisor

Start LocalSystem

RunDiagnostics



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 astarting 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 CashWhen a customer inserts a card, the machine readsthe code from the card and checks if it is anacceptable 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 specificcard. 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 $20are allowed. ...

Use Case: Withdraw CashWhen a customer inserts a card, the machine readsthe code from the card and checks if it is anacceptable 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 specificcard. 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 $20are allowed. ...

*

• Other Attributes– Pre-conditions– Post-conditions

(Guarantees)– Constraints– Intent– Alternate courses– Stakeholders– Priority– Complexity



Basic use cases specify the main services the system provides for its actors,ignoring exception situations. Subordinate (to their base use cases) use cases canbe 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 baseuse 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

*




«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»«include»

«include»

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 tocarry out a Card Insertion.




«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 done’relationship

Bank CardTransaction

Reject InvalidCard

«extend»

In the example we have shown a base use case (Bank Card Transaction) and asubordinate ‘extended’ use case (Reject Invalid Card). Reject Invalid Card willonly be invoked from Bank Card Transaction in exceptional circumstances.




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 casecontains all the attributes, sequences of behavior, and extension points defined inthe 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 addadditional 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 parentto several other use cases.

It is often possible to use «include» or «extend» relationships in place ofgeneralization.



A Use Case defines a service provided by a computer system for an actor. Forinstance, 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 system

test requirements• Define how a goal succeeds or fails.• Provide a framework for constraints and modes models.

Use Cases define testable system requirements froman external perspective

Use Cases define testable system requirements froman external perspective

Use Case Name




Typical Use Cases

Local operator

RemoteOperator

AmmoniaSystem

Handle Alarm

StopCompressor

Start Up Plant

ShutdownPlant

Maintain GasPressure

StartCompressor

«include»«include»

«include»

«include»

«include»

«extend»

«extend»

«extend»




Systems Engineering Use Cases

Local operator

RemoteOperator

AmmoniaSystem

Power

Maintainer

SystemInstaller

SafetyEngineer

Start Up Plant

ShutdownPlant

Maintain GasPressure

Power On Power Fail

CalibrateSensors

Replace SystemComponents

Install System

Run SiteAcceptance Tests

Power Off

AlarmVerification Tests

MonitorSystem

SafetyInspection

«include»

«include»




Use Case Organisation

Multiple-Levels of Use Cases

Use Case Diagrams can be organisedaround different levels of abstractionfrom 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 aspecific domain.

Pilot«Primary Actor»

Mission Plan

«Secondary Actor»

Commander«Secondary Actor»

Navigator«Primary Actor»

Bombadier

«Primary Actor»«Equivalent»

Time

«Primary Actor»

Power

«Primary Actor»

Power UpCold

Store

Information

Load Mission

ContinuousBuilt-In Test

Communicate

ExecuteMission

Power UpBuilt-In Test

Power UpWarm

Power Up

Shutdown

«include»

«include»

«include»

«include»

«include»

«include»

«include»

See Execute Mission Use Case Diagram

SeeStore Information Use Case Diagram

Pilot«Primary Actor»

Navigator

«Primary Actor»Bombadier

«Primary Actor»«Equivalent»

Store Present

Position

Store NavigationInformation

StoreInformation

StoreTargetDestination

StoreSelectedWeaponType

StoreMarkpoint

Store Fix Error

On-TopFix HUD Fix

RADAR Fix

On-Top Mark

HUD Mark

RADAR Mark

StoreWeapons

Information

Bombadier Use Cases

NavigatorUse Cases

Any number of UseCaseDiagramscanbe created tokeep thediagramstidy. This diagram shows how different

types of informationcanbe storedwithin the system and by whom.

Systemof

Systems

System

Sub-System

Pilot

Deploy

Weapon

Store Target

Destination

Store Selected

Weapon Type

Store GeodeticPoint

«include»

«include»

«include»



Slide 66



Activity DiagramsActivity Diagrams




SysML Taxonomy of Diagrams

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML



Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide68

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 inSysML. 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 ofmodeling purposes. For systems engineering, exploring system functionalityis one of the principal uses of these diagrams.




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 sectionwe’ll consider SysML activity modeling as a ‘whole’, not distinguishingbetween which aspects are inherited and which are extensions.




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 coordinatedsequencing of subordinate units whose individual elements are actions.[UML]




a2 : Activity 2 a3 : Activity 3

act [activity] Activity 1

Activity Decomposition

«activity»Activity 1



1

1

a21

1

a3

bdd Activity 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 thatactivities can be treated like classes or blocks with decomposition andassociation relationships modeled on a block definition diagram. The activitydiagram for that activity can then show instances of the sub-activities, whererole names on the bdd become the instance names on the activity diagram.

The meaning of activity decomposition is better defined in SysML (than inUML). For example, SysML specifies that if a composite activity isterminated then any currently executing ‘part’ activities are also terminated.




Action Node

• Represents a single step within anactivity– not further decomposed– execution starts on entry to the action

node– 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 actionnode defines a single step within the owning activity.

Because activity diagrams can be used in a variety of situations, the wordingof the text can be whatever is best suited to the specific situation.

In general, actions are atomic (i.e. not further decomposed). Where theaction 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 andthe part activity name displayed, although the latter can be hidden. Activitiescan be linked with Block operations – these operations are then themechanism through which the activity is invoked.




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 : B lock1«Block»

dt1 : DataType1«DataType»

act [activity] Activity 1«activity»Activity 1

«Block»::Block1

«DataType»DataType1



0..1

1

b1 0..1

1

dt1

1

1

a2 1

1

a3

bdd Activity 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 otheractivities to indicate what type of flow elements relate to the activity. Thiscan be by composition, where the flow element gets destroyed on completionof the activity.




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

Ac tion 1Object

Ac tion 2

Ac tion 1Object

Ac tion 2

Control flow Object flow

Object flow

Control flow

Control Flows are another key component of activity diagrams, providingsequencing 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 thesolid/dashed convention is reversed in SysML.




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

Slide 75

AJM4 right-hand diagram should have action:activity like the left-hand one.Alan Moore, 5/17/2006




• 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’ eventon a state diagram. The ‘send’ represents a signal sent at completion of theactivity 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; itsproperties can then be used to change it to an accept event if required.




Interruptible Activity Region

• A bounded region of activity thatcan be terminated prior tocompletion

regionboundary

interrupting event

interruptingedge

This feature, new to UML 2.0, allows you to explicitly identify areas of activitywhere interrupts are allowed to terminate the activity in the region beforecompletion.

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 flowwith waypoints added.




Activity Diagram – Model ElementsControl 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 othernodes.

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 otherflows (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 aDecision Node, a token arriving at the node will traverse only one of the multipleoutgoing flows, whereas in a Fork Node, the arriving token is duplicated acrossthe outgoing edges, each of which is traversed concurrently.

Similarly, a Merge Node is not used to synchronize multiple incoming flows, butto accept one among several alternate flows, whereas a Join Node synchronizesmultiple incoming flows.




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.




Nested Swimlanes

• Can be nested to any depth• Can link to model item

– uses model item name

Final Flow terminatesflow of activity in that

swimlane




Activity Diagram

• Tips:– Use swim lanes as placeholders for a role or responsibility.– Allocate activities to each swim lane.– Determine data and control flow between activities within and

across swim lanes.– Determine any synchronisation required across swim lanes.– Determine communication infrastructure to facilitate data and

control flow across swim lanes.




Explicit Allocation of Behaviorto Structure Using Swimlanes

Activity Diagram(without Swimlanes)

Activity Diagram(with Swimlanes)




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 theSysML model. Full details are provided in the SysML spec..




Probability

• «probability» stereotype applied tooutgoing edges (flows) from decision orobject nodes

• Defines value (range: 0 – 1) forprobability of any flow being taken– Total of values from one node must

equal 1

• Can also be applied to output parameterset from node– With same value constraints

action 1

action 2a action 2b

action 1

action 2a action 2b

«probability»«probability»p (x )

«probability»«probability»1-p(x )

When the «probability» stereotype is applied to edges coming out of decisionnodes and object nodes, it provides an expression for the probability that theedge 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 areused. 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 outputparameter sets of the same behavior at the time the probabilities are used.[SysML]




Activity Diagram – Distiller Example:Activity Structure

«Block»

valuescal/sec : dQ/dt

Item Types::Heat«Block»

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

Item Types::Residue

«Activity»Heat Water

«Activity»Distill Water

«Activity»Boil Water

«Activity»Condense Steam

«Activity»Drain Residue «Block»

Item Types::H2O

«BlockProperty» cal/gm : specificHeat

«BlockProperty» cal/(gm*deg C) : latentHeatRemove 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

1a1 : Heat Water

1 a2 : Boil Water

1 a3 : Condense Steam 1a4 : Drain Residue1

1

coldDirty : H2O

bdd [package]DistillerBehavior [Distiller Behaviour Breakdown]




Activity Diagram – Distiller Example:Control-Driven: Serial Behavior

«effbd»act [activity] Distill Water [Serial Behavior]

coldDirty : H2O[Liquid]

recovered : Heata1 : Heat Water

a2 : Boil Water

a3 : Condense Steama4 : Drain Residue

external : Heat

pure : H2O[Liquid ]

loPress : Residue

steam : H2O[G as]

hotDirty : H20[Liquid ]

hiPress : Residue



a2 : Boil Water


external : Heat

pure : H2O[Liquid ]

loPress : Residue

steam : H2O[G as]


hiPress : Residue

fork

join

The «ephod» stereotype implies this activity conforms to the constraintsspecified for Enhanced Functional Flow Block Diagrams (a non-normativeSysML extension).




Activity Diagram – Distiller Example: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


steam : H2O[G as]

hiPress : Residue

pure : H2O[Liquid]

external : Heat

coldDirty : H2O[Liquid ] loPress : Residue


a2 : Boil Water

a4 : Drain Residue

recovered : Heat


steam : H2O[G as]

hiPress : Residue




act [activity] Distill Water [Simultaneous Behavior with Allocations]

hx1

ShutDown

steam : H2O[G a s ]

«continuous»

hotDirty : H20[ L iquid]

«continuous»

recovered : Heat

a3 : Condense Steam«streaming»

a1 : Heat Water«streaming»

coldDirty : H2O[ L iquid]

«continuous»

external : Heat«continuous»

: Heat Exchanger

«allocate»drain

a4 : Drain Residue

pure : H2O[Liquid ]

«continuous»

loPress : Residue«continuous»

:V alve

«allocate»bx1

a2 : Boil Water«streaming»

hiPress : Residue«continuous»

: B o iler

«allocate»

Activity Diagram – Distiller Example:(Allocation with Swimlanes): DistillWater

Parts



Slide 89



InteractionsInteractions




SysML Sequence Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML

The Sequence Diagram is ‘re-used’ from UML and captures certain aspects ofbehavior.




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 thesystem (captured as Use Cases) you’ll want to see howthe capabilities are delivered by the components withinthe System Architecture (Modelling the Solution).




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 Use

Case, or– may involve a simple variation on the normal sequence.

• Scenarios are expressed as interaction diagrams




Descriptionpart a

:Block A

«Block»part b

:Block B

«Block»part c

:Block C

«Block»Actor1

seq signal1 {10ms}par

seq message 1 {250ms}loop

seq message 2break

seq

max.: {100ms}

message 2end loop

also par

alt

seq message 3seq message 4( param )

end alt

seq signal2end par

sd SD Concept

Sequence Diagrams

Describe usecase or scenariosequence

Specify timingbudgets andconstraints

Define loops andconditional pathsfor systemfunctionality

Demonstrateparallel andsynchronousfunctionality




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 specifiednotation. In Studio we have made use of the ‘ interaction frame’ element to allowthe scoping of the required ‘piece of interaction’.

By default, the name given to the fragment is taken from the first description stepcovered by the frame, but it can be renamed.




Sequence Diagram - Fragments

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

• Fragments are given default names (in italics) depending ontheir action:• Weak Sequencing (seq) denoting the order in which interactions

occur (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 executed

instead 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 requiredin Studio.




Sequence Diagram – ExampleFragments

Descriptionpart a

:Block A

«Block»part b

:Block B

«Block»part c

:Block C

«Block»Actor1

seq signal1 {10ms}par par

seq message 1 {250ms}loop loop

seq message 2break

seq

max.: {100ms}

message 2end loop

also par

alt altseq message 3seq message 4

end alt

seq signal2end par

sd SD Fragments




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 casecan be split over several diagrams

This is a powerful facility within UML 2.0 that provides behaviouraldecomposition. With Studio an interaction use can be represented as a referenceframe linked to another diagram. The referenced diagram can be anothersequence diagram, or it can be an activity diagram, and it can be opened throughthe context menu of the frame.




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 decompositionreflects 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 partof 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 theinteraction entities shown above with connectors consistent with the abovemessaging, and there would be another internal block diagram showing theinternal component parts of the Boiler and their connectors. It is these internalparts and their messaging that would be shown in the ‘Start Boiler [detail]’diagram.




Part Decomposition - Example

Description:D istiller«B lock»

Distiller.ui1:Control Panel«B lockProperty»

Distiller.bx1:Boilerref Start Boiler

«BlockProperty»User

s tart up StartUps tart Dis tiller TurnOns tart Boiler powerOn

Description:Boiler«Block»

Boiler.heater:Element«BlockProperty»

Boiler.vOverFlow:Valve«BlockProperty»

Boiler.vResidue:Valve«BlockProperty»

power on boiler powerOnswitch on heater onopen overflow openopen 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 modellingwhat 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.




D escription:C ontrol P anel

«B lock»:C ontroller

«B lock»U ser

press s tart StartU pturn on Dis t iller pw rO n

show power onpwrLightON

wait for water to boil

show operating opLightONrepeat loop

alt altwater high hghLightON

els e altdraining drnLightON

els e alt

water low lowLightONend alt

unt il. . .

.. .pres s s top S hutD ow nturn off Dis t iller shutD ow nshow not operat ing

opLightOFFshow power off pwrLightOFF

seq O perate D istiller [U I Operations]

Identifying Block FunctionalRequirements with Use Case Scenarios

«Block»

operationspwrLightON ()opLightON ()hghLightON ()drnLightON ()lowLightON ()opLightOFF ()pwrLightOFF ()

Control Panel

• Messages implyneed for Blockoperations

• Block operationsdefine functionalrequirements forblock

• Operations canmap to actions

Operation callmessages

Operation call messages require corresponding operations to be supported by theblock typing the element owning the lifeline. Block operations can be linked withactions allocated to that block (e.g. via activity diagram swimlanes), whereby thearrival of the message triggers the action.




Refinement through Iteration

*

Iterate

CandidateEntities

Use CaseDescription

SequenceDiagram

:Barrier Motor Red:Light

Green:Light

:Beam Sensor :Car Count:Controller:Pressure Sensor

entry beam detects car break {5ms}beam sensor signals controller car_arrived

controller checks for space isFull {5ms}If full

suspend entry Car WaitsEndIfopen barrier openturn off red light offturn on green light on

controller checks for space isFull {5ms}If full

suspend entry Car WaitsEndIf

suspend entry Car Waits

open barrier openturn off red light offturn on green light on

car passes through beam connectbeam sensor signals controller car_entered

increment car count incrementclose barrier closeturn off green light offturn on red light on


car triggers pressure sensor detectpressure sensor signals controller car_exited

decrement car count decrementdecrement car count decrement

The principle of iteration is important not just in refining use cases and blocks,but also the ibds for blocks. For example, the messaging between the Controllerand the Control Panel shown in the previous slide, implies that the Controllerknows when the water level is high or low. This implies there must be someconnector between the Controller and the Boiler with appropriate ports and flowspec. – these would now be added to this ibd.




Sequence Diagramversus Activity Diagram

• Both describe behavioural sequences– that can include control constructs and data flow– Sequence diagrams are message based

• Use when focus is on sequence of messages between system components• Or when timing information needs to be modelled• Messages can provide ‘events’ for state modelling (later)

– Activity diagrams are action based• Use when focus is on decomposition of activity

– not sensible to model the same behavior (e.g. a use case) with both

• Can link the two models– block operation can be defined for an activity action owned by that block– operations can be parameterized

• to show incoming/outgoing information• parameters show as action node pins on activity diagram, if action node

linked with operation in Studio

The choice whether to use activity diagrams or sequence diagrams to modelbehavior is not an easy one. It will largely depend whether you see it better tomodel action sequences or message sequences. It is unlikely that you will modelboth for a single aspect of behavior, such as a use case.




Sequence Diagram andInternal Block Diagram

• Both can illustrate interaction between parts

• IBD provides ‘static’ view– Shows what can be sent, through port types– Shows what is actually sent, through item flows– Does not show why or when interaction occurs

• Sequence Diagram provides ‘dynamic’ view– Shows the ordering of the interactions– SysML does not allow item flows as messages– Studio does, as long as previously specified

It can be useful to see both a ‘static’ view of interaction (as shown on IBDs) and a‘dynamic’ view (as shown on sequence diagrams). A useful additional feature ofStudio is to allow item flows to be used as messages on sequence diagrams, aslong as their use has already been specified on the same parts on an IBD.



Slide 104



State MachinesState Machines




SysML State Machine Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML

The State Machine Diagram is re-used from UML and captures state-basedbehavior.




State Machines - Overview

• Most embedded systems are state-based in behavior:– Even the simplest system will exhibit states of:

• Initialisation• ‘Doing Something’• Shutting Down

– More complex embedded systems may have:• Multiple sequential states (the system does multiple things in a specific

order).• Multiple concurrent states (the system does multiple things all at the

same time).• A mixture of the above…

• How do you document the required states of a system orone of its components?– Use a State Machine Diagram.– Almost identical to UML state machine semantics and notation.– State machine is child diagram of parent block.

State machine are used to specify the state-based behavior of a block. The blockmay correspond to a complete system or subsystem, or it may type a componentwithin a system/subsystem.




System State Machine

Defines:• High level operational states of the system• How the system as a whole reacts to the various

external events that it can receive• Failure conditions and circumstances under which

the system can recover• Cross references system capabilities in terms of

Use Case availability for a system state• Defines pre- and post-conditions for high-level use

cases• System functions which should be mutually

exclusive




Component State Machines

Defines:• State behavior of a «block» component• How the block and any elements typed by that

block react to the various events they can receive• Cross references block functional capabilities to

states and events• Defines pre- and post-conditions for these

capabilities• Defines mutually exclusive capabilities



The UML state diagram provides a rich syntax for describing behavior. Thesubset illustrated on this slide is normally sufficient to describe the system-levelstate modelling. The following slides cover these modelling elements in moredetail. We’ll add a little detail later.

The ‘event [guard] / effect’ group is often referred to in Studio as an event-actionblock (EAB); an action being one type of effect (element of system behavior).


Main State DiagramModelling Elements

State 1 State 2

States

Transitions

event

Events

Effects

/ effect

*

Initial/Final States Guards

[guard]




Events

• An ‘occurrence’ that may trigger potentialeffects

• Event types :– Signal - event name/

– Call – operation name/

– Time - after(time period)/

– Change - when(Boolean expression)/

– Entry - Entry/

– Exit - Exit/

– None - empty

Signal events represent the receipt of an asynchronous signal (e.g. the receipt of asignal message on a sequence diagram).

Call events represent the receipt of an operation call (a message arriving). Theoperation must belong to the block owning the state machine.

Time events model the expiry of a specified period of time. Timing starts onentry to the source state. Time events are identified by the use of the ‘after’keyword followed by the time period in brackets, e.g. after(200ms).A change event models the occurrence of a specified Boolean expressionbecoming true. Change events use the keyword ‘when’ preceding the Booleanexpression in brackets, e.g. when(a=0). Conceptually, change events arecontinuously evaluated.

An entry event is the event that completes an external transition and models theentry into the destination state. Entry events normally specify an effect (often as aset of actions) to be carried out when the event occurs, e.g.Entry/currentState=idle.

Similarly an exit event occurs at the start of a external transition and models theexit from the source state. It also normally specifies an effect, e.g. Exit/cleardisplay.

If no event is shown on a transition, the transition is deemed to be taken oncompletion of any activity within the source state.




Transitions

external transitions

internal transition

• External transition– denotes exit from source state and entry to destination state– invokes Exit, transition and Entry effects

• Internal transition– no state transition– invokes transition effect(s) but not Exit/Entry effects

Transitions define the rules for responding to events.

External transitions are shown as an arrowed line running from the current(source) state to the new (destination) state. The source and destination statesmay be the same.

Internal transitions are represented by an event-action block within a state.Internal transitions will normally specify a set of actions to be carried out whenthe event (which may be guarded) occurs.




Guard Conditions

• A Boolean expression associated with a transition

• Transition only occurs if expression evaluates to true

• Guards conditions are enclosed by square brackets [ ]and may or may not be preceded by an event

Guard conditions allow transitions to be executed conditionally.

If preceded by an event, the guard condition is evaluated when the event occursand the transition only takes place if true. Where a guard is shown without apreceding event, the condition is evaluated, while in the source state, wheneverany event occurs, and a transition takes place if true.




Initial and Final States

State 1

/ init ial ac t ion

• Initial (pseudo)state• points to the entry state for a region of

a state machine• can have an initial action (effect)• only one permitted within any region of

a state machine

• Final State• Indicates completion of all state activity

for the region containing the final state• can be more than one in a region• can be named and show completion

action Final 1

/com pletion action

The term ‘region’ is used in the context of composite states (see later).




stm [Block] H2O1Gas

Liquid

Solid

Remove Latent Heat of Vaporisation/

Add Latent Heat of Vaporisation/

Remove Latent Heat of Vaporisation/

Add Latent Heat of Vaporisation/

A Simple Example

Transitions

States

Events

A state machine for water.




Junctions

• Allow merging of multiple incoming transitions to asingle outgoing transition

• Allow branching of single incoming transition intomultiple outgoing (guarded) transitions• can use [else]

junction

Although the above illustration is quite valid, it is also common to see a junctionused with several incoming transitions and only one outgoing one, or with onlyone incoming transition and several outgoing ones.




stm [Block] Boiler

Heater On

Heater Off

OperatinghighResidue/open residue valvelowResidue/close residue valve

Heater On

Heater Off

when( temp=Max )/switch off heater

when( temp=Min )/switch on heater

powerOn/switch on heater

powerOff/switch off heater

Composite State - Sequential

Sequential State

Substates

Applies to all sub-states

UML defines a composite state as ‘a state that, in contrast to a simple state, has agraphical decomposition’.

Composite states can be considered to be of two types, Sequential andConcurrent.

Entry into a sequential state can be be specified either at the sequential state level(as illustrated), in which case one of its substates must be defined as the initialstate, or directly to a substate, where for example, you want to show differenttransitions going to different substates.

One of the benefits if using a sequential state here is that we can show the‘after(1min)’ once only, as an event-action block (EAB) of the sequential state.This now means that we can handle this event irrespective of which substate thesystem is in.



C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide117

Registering

Processing

Routing

Moving Idle

Scanning

Capturing data

Processing data

Routing

Moving IdleMoving Idle

Scanning

Capturing data

Processing data

Capturing data

Processing data

Concurrent States

join

concurrent state

region

forksynchstate

stm [block] Container

A concurrent state consists of two or more regions where each region describesconcurrent behavior. A concurrent state can be used to model a situation when anobject can be in two or more states simultaneously. In the above example acontainer can be scanned while it it being routed. Exit from the concurrentProcessing state occurs only when both regions are in their final states.

A synch state can be used to synchronize activity between regions. Here, forexample, we can only capture data after a movement step has completed andprevious data has been processed. It is possible to limit the number of outgoingtransitions from a synch state by setting a bound on the difference between thenumber of times incoming and outgoing transitions fire. The synch state has beendeprecated from UML 2.0 but will remain a part of Studio as it is an essentialconcept for capturing the synchronization mechanism (e.g. priority-ceilingprotocol) used in the synchronization of data between two concurrent stateregions.

Synchronization bars are used with synch states. There are 2 types of these, forkand join as illustrated above.




doActivity

• An activity executed within a state

• May be continuous– until transition from containing state

• in which case activity is aborted

• May be of finite duration– completion triggers transition with no event

defined (if one exists)– or waits in state until transition event occurs

• Notation is ‘do : activityname’Operating

do : Boil Water

Activities have ‘significant’ duration whereas actions have ’insignificant’duration.




More Complex Example

stm [block] Distiller Controller [Distiller States]

Off

Entry/pwrLightOFF

FillingEntry/Open Feed : IValve

Warming Up

Entry/bxHtrON

Distilling

Entry/bxHtrONControlling Boiler Level

Level OKEntry/Close Drain : IValve ;Close Fill : IValve

Level HighEntry/Open Drain : IValve

Level Low

Entry/Open Feed : IValve

Controlling Boiler Residue

Building Up ResidueEntry/Close Drain : IValve

Purging Residue

Entry/Open Drain : IValve

Controlling Boiler Level



Level Low




Level Low




Purging Residue

Entry/Open Drain : IValveBuilding Up Residue

Entry/Close Drain : IValve

Purging Residue

Entry/Open Drain : IValve

DrainingEntry/Open Drain : IValve

Cooling OffEntry/bxHtrOFF;Open Drain : IValve;Open Fill : IValve

pw rO n/

[NOT bxLevelLow]/

[bxTemp = 100degrees]/

[NOT bxLevelLow]/

[bxLevelLow]/

[bxLevelHigh]/

[NOT bxLevelHigh]/

/

DrainTim er/

Res idueTimer/

[bx LevelBelow]/[bxTemp < 100degrees]/

shutDown/



Slide 120



Cross Cutting ConceptsCross Cutting Concepts

Requirements TraceabilityRequirements Traceability




Requirements:Structure or Behavior?

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML

The Requirements Diagram is neither a type of Structure Diagram nor is it atype of behavior Diagram. However it is highly likely that we would want torelate requirements to model elements that might appear on other diagramtypes, and to clearly see these relationships in the model.




Design Elements

Model Element CModel Element C

Model Element T

Model Element A

«testCase»Model Element B

«requirement»REQ_A1



«requirement»REQ_B1

«requirement»REQ_C

«deriveReqt»

«refine»

«trace»

«satisfy»

«verify»

SysML Requirements Traceability

Traceabilityrelationshipsbetweenrequirementsand modelelements

«trace», «refine», «satisfy» and «verify» can exist between a requirementand any other model element (as we have already seen).These relationships are clearly visible from the Requirements Diagrams, butcan we see them from the diagrams that contain the relevant modelelements?




Requirements Traceability fromOther Diagrams

Traceability callouts can be added from model elementswherever they appear in other diagrams in the model

Actor1

Actor2

Use Case A

Use Case B

refinesREQ_A1.2

satisfiesREQ_A1.1

Once the traceability relationship has been established in the model, calloutscan be added to show the relationship from the model element wherever thatelement appears.

Note that we have created a new use case and a «satisfy» relationshipbetween it and REQ_A1.1 to show in this illustration that all types oftraceability relationship can be added.




SysML RequirementsTraceability Table

The table can be customized by adding or removing specific columns.



Slide 125




AllocationsAllocations




Allocations

• Represent general relationships that map onemodel element to another

• Different types of allocation are:– Behavioral (i.e., function to component)– Structural (i.e., logical to physical)– Software to Hardware– ….

• Explicit allocation of actions to structure via swimlanes (i.e., activity partitions)

• Both graphical and tabular representations arespecified




Different Allocation Representations(Tabular Representation Not Shown)

Explicit Allocation ofAction to Swim Lane

Allocate Relationship

Callout NotationCompartment Notation

«block»BlockName

allocatedFrom«elementType»ElementName

PartName

«allocate»:ElementName

ActionName

«block»BlockName

PartName

allocatedFrom«elementType»ElementName

ElementName1 Element

Name3

ElementName2

«allocate»

«allocate»




act [activity] Distill Water [Simultaneous Behavior with Allocations]

hx1

ShutDown

steam : H2O[G as ]

«continuous»

hotDirty : H20[ Liquid ]

«continuous»

recovered : Heat




«continuous»


:Heat Exchanger

«allocate»drain

a4 : Drain Residue

pure : H2O[ L iquid]

«continuous»


:V a lve

«allocate»bx1

a2 : Boil Water

«streaming»


:B oiler

«allocate»

Parts

Behavioral Allocation – Actions to Partsusing Activity Diagram Swimlanes

Actions

Note the use of the «allocate» stereotype in the swimlanes, to indicate thatany actions in that swimlane are being allocated to the relevant part.




Structural AllocationAbstract to Concrete

ibd [Block] Block1 [Abstract to Concrete Structural Allocation]

«Block»Block1

«BlockProperty»: AbstractExample

«BlockProperty»Part2


«BlockProperty»: ConcreteExample




«BlockProperty»: AbstractExample





«BlockProperty»: ConcreteExample







«Allocate»

«Allocate»

«A lloca te»

«Allocate»

«Allocate»

Systems engineers have a frequent need to allocate structural modelelements (e.g., blocks, parts, or connectors) to other structural elements. Forexample, if a particular user model includes an abstract logical structure, itmay be important to show how these model elements are allocated to a moreconcrete physical structure. The need also arises, when adding detail to astructural model, to allocate a connector (at a more abstract level) to a part(at a more concrete level). [SysML]




Abstract to Concrete Allocation:Example

«BlockProperty»CC Sys : Cruise Control

System

«BlockProperty»PowSys : Power

Subsystem

Power-CC System

«BlockProperty»PowSys : Power Subsystem

CCIF : RS232

CCIF : Analogue

GearShiftIF : Force AccelIF : Force

CCIF : RS232

CCIF : Analogue

GearShiftIF : Force

«BlockProperty»CC Sys : Cruise Control

System

EMUIF : RS232

TransmIF : Analogue

BrakeIF : Digital

Power : Electric PowerEMUIF : RS232

TransmIF : Analogue

EMU : EMU Message

Set Throttle : AnalogueMessage

EMU : EMU Message

Set Throttle : AnalogueMessage

Gear : Analogue«ItemFlow»Gear : Analogue«ItemFlow»

allocatedFrom«Connector» Power-CC System

concreteimplementation

abstractconcept

Two fragments from IBDs have been used to illustrate this using the CruiseControl application. The lower fragment is from the initial ‘Vehicle MainSubsystems’ IBD; the upper fragment is from the later ‘Driver InterfaceConnections’ IBD, and shows implementation detail for the Power-CCSystem connector.




SysML Allocation of SW to HW

• In UML thedeploymentdiagram isused to deployartifacts tonodes

• In SysMLallocation onibd and bdd isused to deploysoftware/datato hardware

ibd [node] SF Residence

«node»

SF R esid ence Installat i on

«hardware»: Site Processor

allocatedFrom« software» Device Mgr« software» Event Mgr« software» Site Config Mgr« software» Site RDBMS« software» Site Status Mgr« software» User I/F« software» User Valid Mgr

«hardware»*

: Optical Sensor

«hardware»: DSL Modem

«hardware»2

: DVD-ROM Drive

allocatedFrom«data» Video File

«hardware»: User Console

« hardware»

2

: Video Camera«hardware»

: Alarm

«hardware»: NW Hub

allocatedFrom«software» SF Comm I/F

« hardware»: Site Hard Disk

allocatedFrom«data» Site Database




SysML AllocationsTraceability Table



Slide 133




SysML Package DiagramSysML Package Diagram




The Package Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML




Package Diagram

• Package diagram is used to organize the model– Groups model elements into a name space– Often represented in tool browser

• Model can be organized in multiple ways– By System hierarchy (e.g., enterprise, system,

component)– By domain (e.g., requirements, use cases, behavior)– Use viewpoints to augment model organization

• Import relationship reduces need for fullyqualified name (package1::class1)




Package DiagramOrganizing the Model

By Diagram Type By Hierarchy By IPT




Package Diagram - Views

• Model is organized inone hierarchy

• Viewpoints can provideinsight into the modelusing another principle

– E.g., analysis viewthat spans multiplelevels of hierarchy

– Can specify diagramusages, constraints,and filtering rules

– Consistent with IEEE1471 definitions




The Parametric Diagram

Diagram

Structure Behavior

BlockDefinition

InternalBlock

Package Activity

Use Case

StateMachine

Sequence

New forSysML

Requirements

Parametric

Modifiedfrom UML

Sameas UML




Parametrics

• Used to express constraints (equations) between value properties– Provides support for engineering analysis

(e.g., performance, reliability)• Constraint block captures equations

– Expression language can be formal (e.g., MathML, OCL) or informal– Computational engine is defined by applicable analysis tool and not

by SysML• Parametric diagram represents the usage of the constraints in an

analysis context– Binding of constraint usage to value properties of blocks (e.g.,

vehicle mass bound to F= m a)

Parametrics Enable Integration of EngineeringParametrics Enable Integration of EngineeringAnalysis with Design ModelsAnalysis with Design Models




Constraint Blocks

Defining reusable equations for Parametrics usingconstraint blocks on a block definition diagram

A constraint block is a block that packages the statement of a constraint so itmay be applied in a reusable way to constrain properties of other blocks. Aconstraint block includes the definition of one or more parameters which canbe bound to properties in a specific context where the constraint is used. In acontaining block where the constraint is used, the constraint block is used totype a property that holds the usage. A constraint parameter is a property ofa constraint block which may be bound to a property in a surrounding usagecontext. All properties of a constraint block define parameters of theconstraint block, with the exception of constraint properties that holdinternally nested usages of other constraint blocks. [SysML]




Parametric Diagram – Example 1Vehicle Dynamics Analysis

Using theEquations ina ParametricDiagram toConstrain

ValueProperties

A parametric diagram is defined as a restricted form of internal block diagram. Aparametric diagram may contain constraint properties and their parameters, alongwith other properties from within the internal block context. All properties thatappear, other than the constraints themselves, must either be bound directly to aconstraint parameter, or contain a property that is bound to one (through anynumber of levels of containment). [SysML]




Parametric Diagram – Example 2Direction Cosine Matrix

This diagram represents the conversion of Aircraft Heading (in Inertial Axes) into AircraftHeading (in Body Axes) using a Direction Cosine Matrix. The stereotype «constraint»contains the Direction Cosine Matrix (DCM).

The underlying data-types of each«constraintProperty»are captured. In thisexample,Aircraft.Inertial Headingis a Vector [x, y, z].

The type Vector isdefined elsewhere inthe design (as part ofthe Data-Model).

«constraint»Direction Cosine Matrix

«property»Aircraft.Yaw : Real

«property»Aircraft.Roll : Real

«property»Aircraft.Pitch : Real

«property»Aircraft.Inertial Heading : Vector

«property»Aircraft.Body Heading : Vector



C opyright © 2006ARTISAN Software Tools All Rights ReservedSlide 143

ibd [block] Anti-LockController[Internal Block Diagram]

d 1:TractionDetector

m1 :BrakeModulator

c1:modulatorinterface

ibd [block] Anti-LockController[Internal Block Diagram]

allocatedFrom«activity»DetectLosOfTraction

d1 :TractionDetector

allocatedFrom«activity»ModulateBrakingForce

m1: BrakeModulator

allocatedFrom«ObjectNode»TractionLoss:

c1:modulatorInterface

act PreventLockup [Activity Diagram]

DetectLossOfTraction

ModulateBrakingForceTractionLoss:

par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]

:AccellerationEquation[F = ma]

: VelocityEquation[a = dv/dt ]

:DistanceEquation[v = dx /dt]

:BrakingForceEquation

[f = (tf*bf )*(1-tl)]

tf : bf:tl:

f:

F:

c

a:a:

v:

v:

x:

Cross Connecting ModelElements - Summary

1. Structure 2. Behavior

3. Requirements 4. Parametrics

actPreventLockup [Swimlane Diagram]

«allocate»:TractionDetector

«allocate»:BrakeModulator

allocatedTo«connector»c1 :modulatorInterface

DetectLossOfTraction

ModulateBrakingForceTractionLoss:

req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]



id= “102”text =”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”

«requirement»StoppingDistance

id= ”337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”

«requirement»Anti-LockPerformance

«deriveReqt»

ibd [ block] Anti-LockController[Internal Block Diagram ]

allocatedFrom«activity»DetectLosOfTraction

d1 :TractionDetector


m1:BrakeModulator



satisfies«requirement»Anti- LockPerformance




id=“ 102”text= ”The vehicle shall stopfrom 60 mph within 150fton a clean dry surface.”


SatisfiedBy«block»Anti -LockController

id=” 337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”

«requirement»Anti- LockPerformance

«deriveReqt»

ibd [block] Anti- LockController[Internal Block Diagram]

allocatedFrom«activity»DetectLosOf Traction

d1:TractionDetector

valuesDutyCycle : Percentage


m1: BrakeModulator



satisfies«requirement»Anti-LockPerformance

par [ constraintBlock] StraightLineVehicleDynamics [Parametric Diagram ]

:AccellerationEquation[F = ma]

: VelocityEquation[a = dv/dt ]

: DistanceEquation[v = dx/dt]


[f = (tf*bf)*(1- tl)]

tf: bf:tl:

f:

F:

m:

a:a:

v:

v:

x:

v.Position:

v .Weight:v.chassis .tire.

Friction:v.brake.abs.m1.

DutyCycle:v. brake.rotor .BrakingForce:

par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]

:AccellerationEquation[ F = ma]

:VelocityEquation[a = dv/dt]

:DistanceEquation[v = dx /dt]


[f = (tf*bf )*(1-tl)]

tf : bf:tl:

f:

F:

m :

a :a:

v:

v:

x:

v .Position:

v.Weight:v.chassis .tire.

Friction:v.brake.abs.m1.

DutyCycle :v.brake.rotor.BrakingForce :




VerifiedBy«interaction»MinimumStoppingDistance

id=“ 102”text=”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”


SatisfiedBy«block»Anti -LockController

id= ”337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”

«requirement»Anti-LockPerformance

«deriveReqt»

satisfy

verify

valuebinding

allocate

Four types of cross-connecting principles:1. Allocation

2. Requirement satisfaction/derivation

3. Value Binding/Parametrics

4. Requirement Verification



Slide 144




Software Engineering HandoverSoftware Engineering Handover




From Systems to SoftwareEngineering

• Why do systems engineers needs to understand some aspects ofsoftware engineering?

– Help specify software requirements– Ensuring software requirements are captured completely and that they are

traceable to system requirements– Take part in software design reviews– Involvement in integration/system testing– Manage change in system requirements and define impact on software

• What do they need to know?– Some basic concepts of object–orientation (OO)– Some essential UML terminology and notation– Some appreciation of how UML designs evolve from requirements to code

• Separate systems engineering model from software engineering model– Either: separate model for each (with package import/export)– Or: separate packages for each (within one Studio model)



Slide 146




Fundamentals of OOFundamentals of OO



Objects represent some entity relevant to the real world problem we are dealingwith. They may represent physical entities (e.g. devices), or non-physical entities.

Each object must have a clearly defined and coherent set of responsibilities thatdistinguishes it from other objects. It must also have a unique identity.

Objects are responsible for maintaining information they need in order to provideservices consistent with their responsibilities.


What is an Object ?

• An Object…

– Is a software abstraction of a real-world concept or thing foundin the problem domain

– Has a coherent set of responsibilities

– Provides a set of services (operations) consistent with itsresponsibilities

– Has a unique identity

– Maintains information (attributes) about itself

– Interacts with other objects

*




The Object Oriented Paradigm (1)

• Objects work together in a ‘network’.– Networks are far more flexible to extend and modify than

hierarchies.

• Object Oriented techniques use hierarchy wherenecessary, not as a fundamental principle of design.– Composition and Aggregation Hierarchies– Inheritance Hierarchies

• Objects can represent the ‘roles’ they play within thenetwork, and not a position in an artificial hierarchy.

The origin of the word ‘hierarchy’ has its roots firmly planted in religious institutions. Originallyused to describe the ‘angelic host’ in the 4th century AD; three divisions of angels eachcomprising of three orders in a nine-fold celestial system. Later it became used to describe thesystem of ecclesiastical rule and only in its most recent application does it seem to have lost itsreligious meaning. When Darwin drew-up the hierarchy of living animals he put mankind at thetop because the hierarchy was ordered according to the ability to ‘control’, if the hierarchy wereordered by ‘ability to cooperate’ with other living animals, humans would be somewhere near thebottom. Hierarchies are an artificial mechanism to ascribe some subjective form of ‘order’ orclassification on something which is perceived to be chaotic – perhaps it would not be chaotic if itwere looked upon as a role-based network. Most organizations are hierarchically structured yetoperate, at an individual level, as a network. Individuals create a network of co-workers withwhom they work, so the hierarchy – far from providing direction and control – has no impact onan individual worker’s ability to perform their tasks.

One could define a hierarchy as ‘A partially-ordered structure of entities in which every entity butone is successor to at least one other entity; and every entity except the basic entities is apredecessor to at least one other entity’. This definition elaborates the basic problem withhierarchies, each entity within the hierarchy must be connected to at least one other (either assuccessor or predecessor) therefore to modify or remove one node in a hierarchy you also have totake into account its predecessors and successors as these may be affected. Object orientedtechniques do not impose a hierarchy (i.e. no artificial imposition of a predecessor or successor)on the evolving system; entities (or objects) can be modified, added and removed and the impactof these changes are apparent in the links (or associations) the object has with others in thenetwork.




The Object Oriented Paradigm (2)

• Objects have ‘behavior’– Objects can have ‘state behavior’ which changes with time.– An Object can perform specific functions on the data it

owns or request other Object within the ‘network’ toperform functions on their data.

• Objects own ‘information’– It manages and maintains its own information.– OO focuses on the propagation of information to and from

other Objects.




Types of things…

• You are all types of people… (assumption)• Car parks fill up with types of vehicle…• Libraries are full of types of publication…• A SysML Block is a type of system component…

However:

• It is particularly useful to classify something (i.e.identify its type) when there is more than one of them- why?

• Because the type becomes a convenient way ofdescribing the common characteristics of similarthings.




Components, Objects andClasses

• A System is an artefact within which a collection of (reusable)‘objects’ collaborate in a network to deliver the desired behaviouraloutputs.

• Data and functionality are co-located within the ‘object’ (referred toas ‘encapsulation’, ‘modularization’ or ‘information hiding’)

• ‘Objects’ are classified (or typed) into groups of things exhibitingsimilar data and functionality.

• An ‘Object’ is defined by its class.• Relationships are created between classes to define the

permissible network of interactions allowed by the ‘object’.• ‘Objects’ can be organized into larger, more abstract units referred

to as ‘Components’.• ‘Components’ can also be typed by a ‘class’ that defines the data

storage and functionality of the ‘component’.




Terminology:Object, Class and Instance

• An Object is an Instance of a Class.

– Bob (instance) is a Person (type)

– “The Meaning of Life” (instance) is a Film (type)

– DEF STAN 00-55 (instance) is a Standard (type)

• Object and Instance are synonyms.

• Type and Class(ifier) are synonyms.




Which came first?

In OO an Object is typed by a Class, but which comesfirst, the Class or the Object?

In software engineering, they are both required at thesame time.

We design a system using Objects…

… but we select the right Objects from their Classproperties.



Slide 154




Software Development with UMLSoftware Development with UML




Lot 1 SpacesLot 2 FullLot 3 Spaces

A Simple Application

Exit

Entry

Pressure sensor

Parking Lot

System controller& barrier motor

Safety barrier

IR beamsensor

Traffic lightsLot 1 SpacesLot 2 FullLot 3 Spaces

Display Boards

Serial Link

The parking lot controller controls car access to the parking lot by keeping a dynamic count of thenumber of cars currently in the parking lot. It compares this value with an operator specified valuefor the total capacity of the parking lot to determine whether to admit cars.The system makes use of two sensors, an IR beam sensor at the entry point and a pressure sensor atthe exit point. When a new car enters the parking lot the current car count is incremented. When acar leaves the parking lot the count is decremented.

Access into the parking lot is controlled by a motorized safety barrier and pair of traffic lights, onered and one green (there is no amber light). The red light is illuminated until the entry beam sensordetects a car entering. The control system then checks for space. If there is space for the car, thered light is extinguished, the green light illuminated and the barrier motor opens the safety barrier.If the parking lot is full the red light stays illuminated until the pressure sensor detects a carleaving. When the car entering has passed through the entry beam sensor the red light isilluminated again, the green light extinguished and the barrier motor closes the safety barrier.

An operator I/O unit is provided to enable initial setting of, and any subsequent changes to, theparking lot capacity value. This unit consists of a 4 digit display, two function buttons (one todisplay current capacity value, the other to reset this value), and a numeric keypad. To set up orchange the capacity the operator presses the display button, this activates the display and shows thecurrent value (zero for initial setting). The operator then uses the keypad to enter the new value,which is displayed as each key is pressed. When the display is showing the required value theoperator presses the reset button to reset the value and de-activate the display.The system also needs to provide free space information, across a serial (RS422) data connection,for an external system that updates a number of remote display boards.




«requirement»

txtThe System shall prevent a car fromentering if the parking lot is full.

REQ_1«requirement»

txtThe software shall input and store themaximum capacity value for the parking lot.

REQ_1_SW1

«requirement»

txtThe software shall maintain a count of carscurrently in the parking lot.

REQ_1_SW2

«requirement»

txtOn detecting a car arriving, the softwareshall compare current count value againstmaximum capacity to determine whetherthe car should be allowed to enter.

REQ_1_ SW3

req [Package] Reqts

«deriveReqt»

«deriveReqt»

«deriveReqt»

Software Requirements fromSystem Requirements

SystemRequirement

DerivedSoftware

Requirements

The SysML requirements diagram can show both system and (derived) softwarerequirements. In Studio, requirements diagrams can also be held in a UMLmodel.



A Context Diagram allows the software engineers to identify all inputs andoutputs that the software (to reside in a ‘black-box’ Control System) will need tohandle. Essential details for each item of input or output can be captured throughproperties.

SysML internal block diagrams and activity diagrams are the chief source ofinformation for the construction of the Context Diagram.


Capturing the Software IO Context

*

Parking Lot System

«interface device»Green Light

«interface device»Entry Beam Sensor

«interface device»Pressure Sensor

«interface device»Barrier Motor

«interface device»Red Light«subsystem»

Control System

«subsystem»Operator I/O Unit

«interface device»Keypad

«interface device»Display Button

«interface device»Reset Button

«interface device»Display

«interface device»Full Light :

«interface device»Green Light

«interface device»Entry Beam Sensor

«interface device»Pressure Sensor

«interface device»Barrier Motor

«interface device»Red Light«subsystem»

Control System

«subsystem»Operator I/O Unit









«interface device»Full Light :

Car

Operator

: car passes through: car breaks beam : car passes through: car breaks beam

: car triggers sensor: car triggers sensor

: reset press: reset press

: connect

: break

: connect

: break: detect: detect

: display press: display press

: raise

: lower

: raise

: lower

: set red: set red

: set green: set green

: clear display

: display

: clear display

: display

: key press: key press

: set full: set full




Operator

Car

Use ParkingLot

Set Capacity

Car Waits

«extend»

Software Use Cases

• Software use cases aredefined from, and traceto, systems use cases

• They specify theservices provided bysoftware in the system

This shows a simple use case diagram for the parking lot application, with theDescription property for the Use Parking Lot use case visible.

Other properties can be specified for each use case as required.

These software use cases will be derived from wider system use cases, typicallydefined in a SysML model.




System Interaction Diagrams SpecifyRequired Use Case Behavior

Use Parking LotDescription Barrier Motor Entry Beam SensorGreen Light Pressure SensorRed Light Control SystemCar

entry beam detects car car breaks beambeam sensor signals controller break

check for spaceIf full

suspend entry Car WaitsEndIf

open barrier raise{3ms}turn off red light set red( off )turn on green light set green( on )

car passes through beam car passes throughbeam sensor signals controller connect

increment car countclose barrier lowerturn off green light set green( off )turn on red light

max. {50ms}

set red( on )car triggers pressure sensor car triggers sensorpressure sensor signals controller detect

decrement car count

systemboundary

architecturalboundary

timingconstraint

Context Diagram ‘devices’

This diagram specifies the required ‘black-box’ behavior of the Control Systemfor the Use Parking Lot use case. One system interaction diagram is produced foreach software use case. The diagram defines the sequence of IO for the‘hardware’ elements defined on the Context diagram.



We now move into software design. A sequence diagram is produced for eachuse case, using candidate software objects. The purpose of these diagrams is toidentify software objects and the operations they will need to support to deliveruse case functionality. Detailed information (synchronicity, message parameters,data types, etc.) can be added as these diagrams are developed iteratively.

The note on the diagram is referring to a previous system interaction diagramwhich captured implicit hardware interactions specified for this same use case.


Initial Object Interaction for aUse Case

*

Description :Barrier Motor Red:Light

Green:Light

:Beam Sensor :Car Count:Controller:Pressure Sensor

entry beam detects car breakbeam sensor signals controller car_arrived

controller checks for space isFullIf full

suspend entry Car WaitsEndIfopen barrier openturn off red light offturn on green light on

car passes through beam connectbeam sensor signals controller car_entered


car triggers pressure sensor detectpressure sensor signals controller car_exited

decrement car count decrement

This diagram is a further development of the previously created 'Use Parking Lot - analysis ' sequence diagram. This diagram illustratesthe same use case, but this time as a sequence of software object interactions. The diagram could be used in the early stages ofobject definition and would contribute to the specification of the object model.



C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide161

Example Class Diagram

Operator I/O Unit

I/O Unit

capacity : long-num : short-newValue : long-reset ()+activate ()+key (in number)+

Display

display (in data)+

Keypad Button

read () : short+

I/O Unit

capacity : long-num : short-newValue : long-reset ()+activate ()+key (in number)+

Display

display (in data)+

Keypad Button

read () : short+

Controller

car_entered ()+car_exited ()+car_arrived ()+

Pressure Sensor

threshold : float-initialize ()+read () : short+

Light

on ()+off ()+

Beam Sensor

initialize ()+read () : short+

Sensor{Abstract}

status : short-initialize ()+read () : short+

Barrier Motor

open ()+close ()+

Car Count

capacity : long-count : long = 0-increment ()+decrement ()+isFull () : boolean+set_capacity (in value : long)+get_capacity () : long+Car_Count ()+~Car_Count ()-

1

1 theIOUnit

myKeypad1

1

myDisplay1

1

resetButton

11

Notifies

theEntrySensor

theController

11

NotifiestheExitSensor theController

1

1

theGreenLight

1

1

displayButton

1

1

theMotor

1

1theCarCount

11 resets capacity

theCarCount

1

1

theRedLight

As software interaction models are developed, a class model is also evolving tocapture class properties and relationships.



State diagrams can be produced to model the behavior of classes over theirlifetime. This diagram specifies the dynamic behavior for the Controller class.Most of the events within the ‘Able to Admit Cars' composite state representoperations defined against the Controller class. The 'after(2000)' event specifies atime period of 2 seconds from entry into the Lowering Barrier state. (note thatthis solution implies that another car will not arrive within this time frame).


State Diagram Example

*

Raising Barrier

Entry/theMotor.open;theRedLight.off;theGreenLight. on;

Lowering Barrier

Idle

Able to Admit Cars

car_exited/theCarCount.decrement

Entry Suspended

Controller

«Des troy»/after( 2000 )/

«Create»/

c ar_arrived/ [theCarCount.isFull ]/

[e ls e ] /

car_entered/theCarCount.increment;theMotor.close;theGreenLight.off;theRedLight.on;

car_exited/theCarCount.decrement

«Des troy»/




Model Concurrency

Sensor Flags

Display Press Flag

Car CountSemaphore

EventDetectionTask

Admit CarTask

ResetCapacity Task

Display

DisplayButton

Reset Button Keypad

Entry BeamSensor

PressureSensor

Red Light

Green Light

Barrier Motor

wait()

wait()

set()

set()

display press()break()

connect()detect()

key press()reset press()

get()

release()

increment()

isFull()

decrement()

reset_capacity()get_capacity()

This diagram represent an initial specification of the taskingmodel. It shows that three tasks have been identified and itdefines how task intercommunication is to take place. It alsoshows which system devices are handled by which task.

Event direction is conceptual only; in fact all input devices are polled

For multi-tasking processors a concurrency model can be developed that specifiesthe required tasks, their interaction and any mutual exclusion requirements.

The production of the concurrency model may extend the object architecturemodel, especially the class model.

Note that this example is not a standard UML diagram, but an ARTiSANextension.




Updated Class Model

Operator I/O Unit

«CRconcurrent»

...

I/O Unit

capacity : long-num : short-newValue : long-main ()+activate ()+key (in number : short)+reset ()+

Display

display (in data)+

Keypad Button

read () : short+

«CRconcurrent»

...

I/O Unit

capacity : long-num : short-newValue : long-main ()+activate ()+key (in number : short)+reset ()+

Display

display (in data)+

Keypad Button

read () : short+

pRTOS

cEvent _Flag

flag : boolean-Set ()+Clear ()+Check () : boolean+Wait ()+

cEvent _Flag

flag : boolean-Set ()+Clear ()+Check () : boolean+Wait ()+

«CRconcurrent»Controller

main ()+car_exited ()+car_arrived ()+car_entered ()+

Pressure Sensor

threshold : float-initialize ()+read () : short+

Light

on ()+off ()+

Beam Sensor

initialize ()+read () : short+

Sensor{Abstract}

status : short-initialize ()+read () : short+

Barrier Motor

open ()+close ()+

Car Count

capacity : long-count : long = 0-increment ()+decrement ()+isFull () : boolean+set_capacity(invalue:...+get_capacity () : long+

«CRconcurrent»

...

Event Detection

main ()+

1

1theIOUnit

myKeypad1

1

myDisplay1

1

resetButton

11

Notifies

theEntrySensor

theController

11

NotifiestheExitSensor theController

1

1

theGreenLight1

1

theMotor

1

1 theCarCount

11 resets capacity

theCarCount

1

1

theRedLight

11DisplayPressFlag

21

Sensor Flags

1

1

Display

1

1

theIO

1

1

ExitDetector1

1

EntryDetector

As the software design becomes more detailed, implementation concerns start toappear in the class model. However these additions should not alter thefundamental (and traceable back to use cases) properties and relationships of theapplications classes.Composition has been used to reflect the active objects ‘owning’ their parts.

Otherwise little has changed other than the addition of the RTOS wrapper classesand their restricted access via the active object classes that use them.



The creation of the class model is often seen as key. Code can be generated orproduced from information in the class model. Language profiles allow morecode related information to be held within the model.


::Class1

Attribute1 : Typedef1Operation a ()Operation b (in param : Typedef1) : long

::Class2

Operation c ()

1

1

theC2

Evolve Class Modelfor Code Production

*

class Class1{

public:enum Typedef1{

Typedef1_enum1,Typedef1_enum2

};

// public operations

void Operation_a();

long Operation_b(const Typedef1 param);

private:

// private attributes

Typedef1 Attribute1;

// private roles

Class2* rtheC2;};




Traceability/Impact Analysis

Requirements RequirementsModels

DesignModels

Systemtests

Integrationand Unit tests

Satisfies Satisfies

Acceptancetests

Tests

Tests

Tests

SourceFiles

Satisfies

What if …?

Why is … ?




::Person

Name

Age

AssignUn-Assign

::Company

Name

::Contract

StartDateSalary

Grade

ChangeGrade

::WorkInstruction

Description

StartDate

DurationPerformanceRating

AgreePerformanceRating

::RevenueItem

Cost

::Product ::Service

::DevelopmentPlan

MeanPerformanceTrainingNeeds

CurrentSkills

::ContractualConstraint

DescriptionUpdate

::Term ::Condition

11..* WorksFor

Employee Employer

1..*

1

Manages

Manager

Worker

1..*

1

Markets

Manufacturer

1..*1 DescribesWorkOn

*

0..1

1

1

*

1

Updates

Supervisor

*1

1..*

1

Updates

1..*

1

Purchases

Customer

ItemType{Exclusive}ItemType{Exclusive}

ConstraintType{Inclusive}ConstraintType{Inclusive}

Class Model

Requirements

Pilot

StoresNavigationData

DeploysWeapon

PerformsSorte

Use Case Model

TheSoftware:TheSoftwarePilot DataEntryPanel

Pilot PressesKeyKeyPress

SoftwareDeterminesnewModeKeyPress(KEYID)

ifNAVKeythen

EnterNavigationModeSetMode(NAV)

elsifWeaponsKey then

case SelectedStore iswhenLoft Bombs=>

SetMode(LOFT)whenRetardBombs => SetMode(RETARD)

whenGuns=> SetMode(GUN)whenRockets =>

SetMode(ROCKET)endcase

endif

EnterNavigationModeSetMode(NAV)

elsifWeaponsKey then









whenLoft Bombs=>SetMode(LOFT)

whenRetardBombs => SetMode(RETARD)


SetMode(ROCKET)


Pilot PressesKey KeyPressSoftwareDeterminesnewMode KeyPress(KEYID)ifNAVKeythen

EnterNavigationMode SetMode(NAV)elsif WeaponsKeythen

caseSelectedStore iswhen Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)

when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)

endcaseendif

EnterNavigationMode SetMode(NAV)elsif WeaponsKeythen



endcase



endcase

when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)



Pilot PressesKey KeyPressSoftwareDeterminesnewMode KeyPress(KEYID)ifNAVKey then

EnterNavigationModeSet Mode(NAV)

elsif WeaponsKeythencase SelectedStoreis

when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)

endcaseendif

EnterNavigationModeSet Mode(NAV)

elsif WeaponsKeythencase SelectedStoreis


endcase

case SelectedStoreis


endcase


Scenario Model

Take-of f Valve

RemoteOperator

Local operator

Nitrogen Compression Plant

NCP System

HP Tank

HPT Switch HP Switch LPT SwitchLP Switch

Remote Monitoring Unit

Local Indication Panel

Compressor Unit

CompressorMotor

CompressorSensors

Valves

By-pass ValveVent ValveInlet Valve

Outle t Valve

NCP System

HP Tank

HPT Switch HP Switch LPT SwitchLP SwitchHPT Switch HP Switch LPT SwitchLP Switch



Compressor Unit

CompressorMotor

CompressorSensors

CompressorMotor

CompressorSensors

Valves

By-pass ValveVent ValveInlet Valve

Outle t Valve By-pass ValveVent ValveInlet Valve

Outle t Valve

open()open() close()close()

250 bar()250 bar()

reset()

alarm()

reset()

alarm()

reset()

alarm()

reset()

alarm()

system stop()system stop()

alarm()

reset()

alarm()

reset()

150 bar()150 bar()

system start()

system stop()

system start()

system stop()

stop()

start()

stop()

start()

Context Diagram


RMU Display Stop ButtonRMU Display Stop Button


stop/startbuttons

LIP Display stop/startbuttons

LIP Display

Plant Controller

system bus

display boardseria l i/f

I/O board

motherboard

remote comms.

seria l i/f

system bus

display boardseria l i/fseria l i/f

I/O board

motherboard

remote comms.

seria l i/fseria l i/f

Compressor Unit

CompressorMotor Low OilPressure switch

Inlet GasPressureTrip Switch

Outlet GasPressure Tr ip

Switch

Coolant FlowMeter

CompressorMotor Low OilPressure switch

Inlet GasPressureTrip Switch

Outlet GasPressure Tr ip

Switch

Coolant FlowMeter

HP Tank

HPT Switch

HP Switch

LPT Switch

LP Switch

HPT Switch

HP Switch

LPT Switch

LP Switch

Outlet Valve Vent ValveBy-pass ValveInlet Valve

3 wire RS2323 wire RS232

RS422RS422 All I/O board connections are 24V DC single phase. Valveconnectionsare in fact 2 single 1-way connections rather one 2-way

...

Hardware Architecture(Deployment) Diagram

Start/Stop Requests

Alarms Status

Timeout Events

Alarm Inhibits /Enables

Alarm MonitoringTask (AMT)

Display andCommunication

Task (DCT)

Timer Task

(TT)

CompressorController Task

(CCT)

Timer Requests

alarm status data

Plant Status

Real WorldTrips

Real WorldDevices

Networks ( for

LIP and RMU)

Set() Clear()Set() Clear()

Read()Read()

Set()Set()

Check()Check()

Post()Post()

Write()Write()

Read()Read()

Set()Set()

Read()

Clear()

Read()

Clear()

Write()Write()

Read()Read()

Write()Write()

Read()Read()Read()

Clear()

Read()

Clear()

Concurrency (Communication)Diagram

SourceFiles

How it all fits together

Starting Up SystemFail Safe

Shutting Down System

Compressor Off

Compressor On

State4

Compressor Off

Compressor On

after( 40s )/

system start/Start Up Plant

power down/

system stop/Shutdown Plant

alarm/ Handle Alarm

after( 180s )/Maintain Gas Pressurealarm/ Handle Alarm

power up/

[LPT and LOP alarms ringing] /

[ els e ]/

[els e] /

250 bar/S top Compressor

150 bar/Start Compress or

[LOP alarmringing] /

Interaction Overview(Modes) Diagram

TestScripts

OperationalParameters Performance

Loader Speed

Belt Speed

Containers ScanSuccess

DefectiveContainers Accuracy

Constraints Diagram

runningdown

Entry/monitor .inhibit(LOP);timer .set(40);motor. stop;

valve [inlet].close;valve [outlet]. close;valve [by-pass].open; ...

stopped

waitingforoilpressuretobuildEntry/monitor.inhibit(LOP);

valve[vent].close;timer.set (30);timer.set (40);

motor. start; ...

waitingforgaspressuretobuildoperating

timeup/

monitor .enable(LOP)

start compressor/

after(40s)/valve[vent]. open;...

after(10s )/

valve[by-pass].close;valve[inlet].open ;valve[outlet]. open; ...

stopcompressor/

«Destroy»/

stopcompressor/timer.cancel (30);timer.cancel (40);

stopcompressor/

timer.cancel(40);

«Create»/

[ !monitor. check(LOP)]/monitor .activate (LOP)

[monitor .check(LOP)]/

Dynamic Model

Bombadier

Select Target Destination

Authority

Bombadier

Select Weapon Type

Navigator

«Equivalent»

Select Target Destination

Authority

Bombadier

Select Weapon Type

Navigator

Pilot

Communicator

Strike Authorised

Navigate to Target

Communicator

Strike Authorised

Navigate to Target

Commander

Strike Authority

«Secondary Actor»

Strike Authority

Activity Diagram

«pConstraint»Direction Cosine Matrix

«property»Aircraft.Yaw : Real

«property»Aircraft.Roll : Real

«property»Aircraft.Pitch : Real

«property»Aircraft.Inertial Heading : Vector

«property»Aircraft.Body Heading : Vector

Parametric Diagram

ACME RADAR

: Signal Processing : RADAR Controller

: Array Antenna

: Receiver

: Transmitter

: Antenna Controller

: Power Supply

: Tx Rx Duplex

: Array Orientation

: Mechanical Orientation

: Elevation Actuator

: Azimuthal Actuator

: Electronic Orientation

: User Displays

: Display : Keypad

: Signal Processing : RADAR Controller

: Array Antenna

: Receiver

: Transmitter


: Power Supply

: Tx Rx Duplex

: Array Orientation




: Electronic Orientation: Receiver

: Transmitter


: Power Supply

: Tx Rx Duplex

: Power Supply

: Tx Rx Duplex

: Array Orientation









: Electronic Orientation

: User Displays

: Display : Keypad: Display : Keypad

Operator

Composite StructureDiagram

Specification

«generalRequirement»

RequirementCid = "Name"

text = "The system shall..."priority = High

status = "Assigned"

«performanceRequirement»

Requirement B

«functionalRequirement»

Requirement A

«generalRequirement»

RequirementCid = "Name"

text = "The system shall..."priority = High

status = "Assigned"

«performanceRequirement»

Requirement B

«functionalRequirement»

Requirement A

Derived Requirements

«functionalRequirement»RequirementX

«performanceRequirement»RequirementY

«functionalRequirement»RequirementX

«performanceRequirement»RequirementY

Design

SystemElementA

SystemElementB

SystemElementA

SystemElementB

Test Cases

«test Case»Test CaseA«test Case»Test CaseA

*

1

«trace»«trace»

«satisfy»

«satisfy»

«verify»

<<rationale>>

Reason

Requirements Diagram

The UML provides many ‘diagram types’. Each type of diagram focuses on unique perspective ofthe evolving system. Each perspective provides a unique ‘view’ of all the linked information withthe complete model. The green lines represent the same model element on different diagrams. Thered lines represent links between different model elements. Systems today require a detailedanalysis from many perspectives in order to describe the complete system. Within RtS we providethe following views of the system:

•Use Case view – providing details of services provided by the system and which actors areinvolved with the service.

•Interaction view – supported by both Scenario and Collaboration Diagrams which detail whatentities are involved in delivering the service.•Class view – providing details of the static architecture of the software.

•State view – provided at both system and software levels to detail the dynamic behavior of boththe system and the software.•Concurrency view – providing detailed analysis of both system and software concurrency

•Constraints view – providing a mechanism to capture and maintain non-functional requirementsof the system and software.

•Contextual view – providing details of user-system and system-software interfaces as well as anoverall system context.•Hardware view – providing details of processing nodes, especially the details traditionally sharedbetween hardware and software engineers e.g. hardware addresses.



Slide 168



Summary and WrapSummary and Wrap--upup




Summary

• SysML sponsored by INCOSE/OMG with broad industry andvendor participation

• SysML provides a general purpose modeling language to supportspecification, analysis, design and verification of complexsystems– Subset of UML 2 with extensions– 4 Pillars of SysML include modeling of requirements, behavior,

structure, and parametrics

• OMG SysML Adopted in May 2006• Multiple vendor implementations announced• Standards based modeling approach for SE expected to improve

communications, tool interoperability, and design quality




References

• OMG SysML website– http://www.omgsysml.org

• UML for Systems Engineering RFP– OMG doc# ad/03-03-41

• UML 2 Superstructure– OMG doc# formal/05-07-04

• UML 2 Infrastructure– OMG doc# ptc/04-10-14




Additional Reading…

o The Unified Modeling Language Reference Manual (Addison-WesleyObject Technology Series) by James Rumbaugh, IvarJacobson, Grady Booch

o Applying UML and Patterns: An Introduction to Object-OrientedAnalysis and Design and the Unified Process (2nd Edition) by CraigLarman

o Writing Effective Use Cases by Alistair Cockburno Applying Use Cases: A Practical Guide by Geri Schneider, Jason

P. Winters, Ivar Jacobsono The Object-Oriented Thought Process by Matt Weisfeld, Bill

McCartyo Pattern-Oriented Software Architecture, Volume 2, Patterns for

Concurrent and Networked Objects by Douglas Schmidt

QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.

QuickTime™and a TIFF (Uncompressed) decompressor are needed to see this picture.QuickTime™and a TIFF (Uncompressed) decompressor are needed to see this picture.




Questions and Answers




How To Contact Us

If you would like to arrange a customized Webex ordemonstration on how ARTiSAN products & services canenhance your organizational processes’ capability andmaturation contact us at (703) 771-8008.

Speak with Mr. Phil Perri, Business DevelopmentManager, North America



Slide 174



Distiller Sample ProblemDistiller Sample Problem




System DevelopmentProcess

SystemmodelingActivities

Integrated ProductDevelopment (IPD) isessential to improve

communications

A recursive V processthat can be applied tomultiple levels of the

system hierarchy

ComponentmodelingActivities

Procedures

ManageSystem

Development

Define SystemReqt's &Design

Integrate& TestSystem

System

StakeholderReqts

System archAllocated reqt's

DataHardware

SoftwareDevelopSystem

Components

VerifiedSystem

Component

Plan

StatusTechnical data Test procedures

There are many different process models in use by many organizations. The aboveoutlines just one (reasonably common) approach.

The main purpose of this section is not to define a process but to emphasize that,whatever the process, there will be important inter-relationships between various SysMLdiagrams that are evolved iteratively.




Distiller Problem – Process Used

• Organize the model, identify libraries needed• List requirements and assumptions• Model behavior

– In similar form to problem statement– Elaborate as necessary

• Model structure– Capture implied inputs and outputs

• segregate I/O from behavioral flows– Allocate behavior onto structure, flow onto I/O

• Capture and evaluate parametric constraints– Heat balance equation

• Modify design as required to meet constraints

The process used to evolve the Distiller diagrams is outlined above. Note that this doesthings in a quite different order from the order we have introduced topics on this course.This reinforces the point that SysML is process independent. The following slides will(hopefully) also reiterate the need for, and benefits of, creating links between variousmodel elements, irrespective of the order in which they are created. It will also reiteratethe iterative nature of SysML Model development.




Distiller Problem Statement

• The following problem was posed to the SysMLteam in Dec ’05 by D. Oliver:• Describe a system for purifying dirty water.

– Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger– Boil dirty water is performed by a Boiler– Drain residue is performed by a Drain– The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C, specific heat

1cal/gm deg C, heat of vaporization 540 cal/gm.• A crude behavior diagram is shown.

Dirty water@ 20 deg C

Heat Dirty waterTo 100 deg C

Heat to Dirtywater

Boil Dirty water

Dirty water@ 100 deg C

Steam

Residue

and

Condensesteam

DrainResidue

Purewater

Disposedresidue

andand

Heat to Boilwater

Energy tocondense

What are the real requirements?How do we design the system?

Problem statements come in many different forms. The systems engineer is oftenpresented with informal diagrams and text for the initial concept requirements,and is asked to formalize them into a specification.




Distiller Types

BatchDistiller

ContinuousDistiller




Distiller Problem – Package Diagram:Model Structure and Libraries

p kg [M ode l] D istille r M ode l 6 .1h1 [M ode l O ve rview ]

D istille r R equirem ents D istille r U se C ases

D istille r B ehaviour D istille r S truc ture

V alue T ypes Item T ypes

bdd [Package] Value Types1

«ValueType»Power

«Dimension»Heat Flow Rate

«Unit»cal/sec

«Dimension»Specific Heat

«Unit»cal/(gm*DegreeCelcius)

«Dimension»Latent Heat

«Unit»cal/gram

«ValueType»Real

«ValueType»

dimensionThermodynamicTemperature

unitDegreeCelsius

temp«ValueType»

dimensionPressure

unitN/M^2

press«ValueType»

dimensionMass Flow Rate

unitgm/sec

massFlowRate«ValueType»

dimensionHeat Flow Rate

unitcal/sec

dQ/dt

«ValueType»efficiency

«ValueType»

dimensionSpecific Heat

unitcal/(gm*DegreeCelcius)

specificHeat«ValueType»

dimensionLatent Heat

unitcal/gram

latentHeat

«Unit»N/M^2

«Dimension»Mass Flow Rate

«Unit»gm/sec

This diagram shows the structure used to build the distiller model, andemphasizes the units used.




Distiller ExampleRequirements Diagram

Source

«requirement»

id#S0.0

txtDescribe a system for purifying dirty water.- Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger.- Boil dirty water is performed by a Boiler. Drain Residue is performed by a Drain.The water has properties: vol = 1 litre, density 1 gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporisation 540 cal/gm.

Original Statement

«requirement»

id#S1.0

txtThe System shall purify dirty water.

PurifyWater

«requirement»

id#S2.0

txtHeat dirty water and condensesteam are performed by a CounterFlow Heat Exchanger.

HeatExchanger «requirement»

id#S5.0

txtThe water has properties: vol = 1 litre, density 1gm/cm3, temp 20 deg C, specific heat 1cal/gm degC, heat of vaporisation 540 cal/gm.

Water Properties

«requirement»

id#S3.0

txtBoil dirty water is performed by a Boiler.

Boiler

«requirement»

id#S4.0

txtDrain residue is performed by a Drain.

Drain

«requirement»

id#S5.1

txtWater has an initial temp of 20degrees C.

WaterInitialTemp

«requirement»

id#D1.0

txtThe System shall purify water by boiling water.

Distill Water

The requirementfor a boilingfunction and aboiler impliesthat the watermust be purifiedby distillation.

req [Package] Distiller Requirements 1

«deriveReqt»

This diagram shows the Distiller Specification (including some rationale for whya distiller is an appropriate way to purify water), and a formal documentation forrelated assumptions, which are treated as requirements in this example.




Distiller Example:Requirements Tables

id name textS0.0 OriginalStatement Describe a system for purifying dirty water. …S1.0 PurifyWater The system shall purify dirty water.S2.0 HeatExchanger Heat dirty water and condense steam are performed by a …S3.0 Boiler Boil dirty water is performed by a Boiler.S4.0 Drain Drain residue is performed by a Drain.S5.0 WaterProperties water has properties: density 1 gm/cm3, temp 20 deg C, …S5.1 WaterInitialTemp water has an initial temp 20 deg C

Tables will be used more often than requirements diagrams, because they aremore compact and more scaleable.




Distiller Example – Activity Diagram:Start Point : Control-Driven Serial Behavior

BatchDistiller

«effbd»act [activity] Distill Water [Serial Behavior]



a2 : Boil Water


external : Heat

pure : H2O[Liquid]

loPress : Residue

steam : H2O[G as ]

hotDirty : H20[Liquid]

hiPress : Residue



a2 : Boil Water


external : Heat

pure : H2O[Liquid]

loPress : Residue

steam : H2O[G as ]


hiPress : Residue

Activity(Function)

Control(Sequence)

Things that flow(Object Nodes)

This activity diagram follows the optional SysML EFFBD profile, and formalizes thediagram in the problem statement.




«Block»




Item Types::Residue

«Activity»Heat Water

«Activity»Distill Water

«Activity»Boil Water

«Activity»Condense Steam

«Activity»Drain Residue «Block»

Item Types::H2O

«BlockProperty» cal/gm : specificHeat«BlockProperty» cal/(gm*deg C) : latentHeatRemove 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

1a1 : Heat Water

1 a2 : Boil Water

1 a3 : Condense Steam 1a4 : Drain Residue1

1

coldDirty : H2O

bdd [package] DistillerBehavior [Distiller Behaviour Breakdown]

Distiller Example – Block DefinitionDiagram: Distillerbehavior

Control(not shown on BDD)

Need toconsiderphasesof H20

Activities(Functions)

Things that flow (ObjectNodes)

This block definition diagram defines all the elements used in the activitydiagram. This allows some elaboration of properties of the water that flowsthrough the system. This shows the need to consider the water in both liquid andgaseous phase… the next diagram will formalize these phases in a finite statemachine.




stm [Block] H2O1

Gas

Liquid

Solid

Remove Latent Heat of Vaporisation/Add Latent Heat of Vaporisation/

Remove Latent Heat of Vaporisation/Add Latent Heat of Vaporisation/

Distiller Example – State MachineDiagram: States of H2O

Transitions

States

This state machine diagram formalizes the states of H2O as it flows through thesystem. Change of state requires adding or removing latent heat.




Distiller Example – Activity Diagram:I/O Driven: Continuous Parallel Behavior

Continuous Distiller

act [activity] Distill Water [Continuous Parallel Behavior]

pure : H2O[L iquid]

external : Heat

coldDirty : H2O[L iquid]

loPress : Residue


a2 : Boil Water

a4 : Drain Residue

recovered : Heat


steam : H2O[G as]

hiPress : Residue

pure : H2O[L iquid]

external : Heat

coldDirty : H2O[L iquid]

loPress : Residue


a2 : Boil Water

a4 : Drain Residue

recovered : Heat


steam : H2O[G as]

hiPress : Residue

It makes sense for the distiller design to allow a continuous flow of water throughthe system, rather than only discrete increments of water. The previous activitydiagram (EFFBD) has been recast to support continuous flow. Dirty H2O andHeat are inputs to the system, Pure H2O and Residue are outputs.




Distiller Example – Activity Diagram:No Control Flow – Simultaneous Behavior

act [activity] Distill Water [Simultaneous Behavior]

pure : H2O[Liquid ]

«continuous»



«continuous»



a2 : Boil Water

a4 : Drain Residue

recovered : Heat


«continuous»steam : H2O

[G as ]

«continuous»

hiPress : Residue

«continuous»

ShutDown pure : H2O[Liquid ]

«continuous»



«continuous»



a2 : Boil Water

a4 : Drain Residue

recovered : Heat


«continuous»steam : H2O

[G as ]

«continuous»

hiPress : Residue

«continuous»

ShutDown

This diagram is semantically equivalent to the previous diagram, but clearer andeasier to read.




bdd [Package] Distiller Structure [Structural Breakdown]

«Block»Boiler

«Block»Valve

«Block»


Item Types::Fluid«Block»



operationsTurnOn ()TurnOff ()

Distiller

«Block»Heat Exchanger

hx1 bx1 drain

satisfies«requirement» HeatExchanger

satisfies«requirement» Boiler

satisfies«requirement» Drain

Distiller Example – Block DefinitionDiagram: DistillerStructure

Generic Subsystems(Blocks)

Usage (Part) Names(Roles)

Generic ThingsThat Flow(Blocks)

The problem statement includes the initial product structure (Counter Flow HeatExchanger, Boiler, Drain), which are defined in this Block Definition Diagram.




Distiller Example – Activity Diagram(allocation with swimlanes): DistillWater

act[activity] DistillWater[SimultaneousBehaviorwithAllocations]

hx1

ShutDown

steam : H2O[ G as ]

«continuous»


«continuous»

recovered : Heat




«continuous»


: Heat Exchanger

«allocate»drain

a4 : Drain Residue

pure : H2O[Liquid ]

«continuous»


:V a lve

«allocate»bx1



: B oiler

«allocate»hx1

ShutDown

steam : H2O[ G as ]

«continuous»


«continuous»

recovered : Heat




«continuous»


: Heat Exchanger

«allocate»

ShutDown

steam : H2O[ G as ]

«continuous»


«continuous»

recovered : Heat




«continuous»


drain

a4 : Drain Residue

pure : H2O[Liquid ]

«continuous»


:V a lve

«allocate»

a4 : Drain Residue

pure : H2O[Liquid ]

«continuous»


bx1



: B oiler

«allocate»



Parts (Roles)

The previous Activity Diagram has been elaborated withAllocateActivityPartitions, showing how actions are allocated to blocks (parts).




ibd [Block] Distiller [Initial with Item Flows]

«Block»Distiller

DSDirty_Out : H2O

«BlockProperty»bx1 : Boiler

BLHotDirty_In : H2O

BLSteam_Out : H2O


BLPower_In : Power

BLExcess : H2O«BlockProperty»

drain : Valve

Fluid_In : Fluid Fluid_Out : Fluid

«BlockProperty»hx1 : Heat Exchanger

HEDirtyIn : H2O

HEClean_Out : H2O HEHotDirty_Out : H2O

HESteam_In : H2O

DSResidue_Out : Residue

DSClean_Out : H2O

DSPower_In : PowerDSExcess

DSDirty_Out : H2O


BLHotDirty_In : H2O

BLSteam_Out : H2O


BLPower_In : Power

BLExcess : H2O

BLHotDirty_In : H2O

BLSteam_Out : H2O


BLPower_In : Power

BLExcess : H2O«BlockProperty»

drain : Valve

Fluid_In : Fluid Fluid_Out : FluidFluid_In : Fluid Fluid_Out : Fluid


HEDirtyIn : H2O


HESteam_In : H2OHEDirtyIn : H2O


HESteam_In : H2O

DSResidue_Out : Residue

DSClean_Out : H2O

DSPower_In : PowerDSExcess

: H2O«ItemFlow»: H2O«ItemFlow»




: Residue«ItemFlow»: Residue«ItemFlow» : Residue

«ItemFlow»: Residue«ItemFlow»

: Power«ItemFlow»: Power«ItemFlow»


Distiller Example – Internal BlockDiagram: Distiller Initial Design

Parts(Blocks usedin context) Flow Ports

Things That FlowIn Context

(ItemFlows)

Connectors

This internal block diagram now shows how the parts are connected in thedistiller system. These flows are notional, and provide the initial basis forinterface specifications – note that they merely indicate direction of flow for eachinput/output… they don’t directly relate to the activity model yet. These flowswill later be referenced in a parametric heat balance analysis.

The flow ports can start to place restrictions on pressure, temperature, etc., whichwill be necessary to manufacture or procure these parts.




ibd [Block] Distiller [with Allocation]

«Block»Distiller


allocatedFroma2 : Boil Water

«BlockProperty»drain : Valve

allocatedFroma4 : Drain Residue


allocatedFroma3 : Condense Steama1 : Heat Water







m4 : H2Om4 : H2O

m1 : H2Om1 : H2O m3 : H2Om3 : H2O

m2 : H2Om2 : H2O

ItemFlow1 : H2OItemFlow1 : H2O

Q1 : PowerQ1 : Power

s1 : Residues1 : Residue


allocatedFromcoldDirty : H2O allocatedFrom

external : Heat

allocatedFromhotDirty : H20

allocatedFromsteam : H2O

allocatedFrompure : H2O

allocatedFromhiPress : Residue

allocatedFromloPress : Residue

Distiller Example –Internal BlockDiagram: Distiller with Allocation

Allocation Compartment(references Activities)

Allocation Callout(references Object Nodes)

This internal block diagram is now annotated with allocations from the previous“swimlane” diagram, accounting for flow allocation.




Distiller Example – ParametricDiagram: Heat Balance Equations

ValueProperties

Constraintcallouts

Constraints

Parts orItemFlows

ValueBindings

This parametric diagram helps the systems engineer to visualize the heat balanceof an isobaric (constant pressure) distiller system. This is an appropriate first-order approximation of the heat flow required to make the distiller functionproperly. The values referenced relate to the flows shown on the system internalblock diagram.




Distiller Example – Heat BalanceResults

table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]

specific heat cal/gm-°C 1latent heat cal/cm 540

wat

er_

in

hx_

wa

ter_

out

bx_

wa

ter_

in

bx_

stea

m_

out

wat

er_

out

mass flow rate gm/sec 6.75 6.75 1 1 1temp °C 20 100 100 100 100

dQ/dt cooling water cal/sec 540dQ/dt steam-condensate cal/sec 540condenser efficency 1heat deficit 0

dQ/dt condensate-steam cal/sec 540boiler efficiency 1dQ/dt in boiler cal/sec 540

Note: Cooling waterneeds to have 6x flowof steam!Need bypass betweenhx_water_out andbx_water_in!

Satisfies «requirement»WaterSpecificHeatSatisfies «requirement»WaterHeatOfVaporization

Satisfies «requirement»WaterInitialTemp

• Not a SysMLdiagram

• Constructed fromSysML diagraminformation

• Can be held inStudio a a textdiagram

This table was generated using the equations stated in the parametric diagram. Itis important to note that, in order to get the heat equations to balance, that 6.75times more water than steam is required to flow through the heat exchanger. Thedesign shown on the previous internal block diagram doesn’t allow this, so amodification must be made to the design in order to allow a bypass between theheat exchanger and the boiler.




Distiller Example – ActivityDiagram: Updated DistillWater

act [activity]Distill Water [Updated Simultaneous Behavior with Allocations]

drain

pure : H2O[ Liquid]

«continuous»

loPress : Residue«continuous»a4 : Drain Residue

hotDirty2 : H20[ Liquid]

«continuous»

hiPress : Residue

«continuous»

:V alve

«allocate»

bx1


hotDirty1 : H2O[ Liquid]

«continuous»

:B oiler

«allocate»

feed

steam : H2O[G as ]

«continuous»

a5 : Divert Feed

:V alve

«allocate»

drain

pure : H2O[ Liquid]

«continuous»



«continuous»

hiPress : Residue

«continuous»

:V alve

«allocate»

pure : H2O[ Liquid]

«continuous»



«continuous»

hiPress : Residue

«continuous»

bx1



«continuous»

:B oiler

«allocate»



«continuous»

feed

steam : H2O[G as ]

«continuous»

a5 : Divert Feed

:V alve

«allocate»

steam : H2O[G as ]

«continuous»

a5 : Divert Feed

hx1



«continuous»



recovered : Heat

hotDirty : H20[ Liquid]

«continuous»

ShutDown

: Heat Exchanger

«allocate»



«continuous»



recovered : Heat

hotDirty : H20[ Liquid]

«continuous»

ShutDown

added as a result of parametric analysis

The “Divert Feed” activity has been allocated to the feed valve, “hotDirty:H2O”to the boiler has been updated to “hotDirty1:H2O”, and “hotDirty2:H2O” is nowan additional output. hotDirty = hotDirty1+hotDirty2.




Distiller Example – Internal BlockDiagram: Updated Distiller

ibd [Block] Distiller [with Allocation - Updated]

«Block»Distiller







«BlockProperty»feed : Valve

allocatedFroma5 : Divert Feed








allocatedFroma5 : Divert Feed

m1 : H2Om1 : H2O

m4 : H2Om4 : H2O

m3 : H2Om3 : H2O

Q1 : PowerQ1 : Power



m2-1 : H2Om2-1 : H2O

m2-2 : H2Om2-2 : H2O

m2-1 : H2Om2-1 : H2O

allocatedFromhotDirty1 : H2O

allocatedFromhotDirty1 : H2O

allocatedFromhotDirty2 : H20

added as a result of parametric analysis

An additional port must be added to the HeatExchanger, allowing waste_water toflow out of the system. Note that the functional and flow allocations have beenupdated.




Distiller Example – Use Case andSequence Diagrams

ucd Distiller Use Cases

UserOperateDistiller

Description:Distiller«Block»

Distiller.ui1:Control Panel«BlockProperty»User

press start StartUpturn on Distiller TurnOndistill water ref Distill Water [detail]

press stop ShutDownturn off Distiller TurnOff

seq Operate Distiller [high level]




Distiller Example – Internal BlockDiagram: Distiller Controller

ibd [Block] Distiller [with Controller]

«Block»Distiller


blrSig




«BlockProperty»ui1 : Control Panel

«BlockProperty»cx1 : Controller

blrSig

IPower

ILamp ILamp

IPower

IValve

IValve

IValve IValve

m4 : H2O

m1 : H2O

m2-1 : H2O

m2-2 : H2O

m3 : H2O

m2-1 : H2O s1 : Residue

s2 : Residue

p1 : Power b1 : Power

We now enhance our view of the Distiller structure by adding a Controller andassociated Control Panel.




Distiller Example – State MachineDiagram: Distiller Controller

stm [block] Distiller Controller [Distiller States]

OffEntry/pwrLightOFF

FillingEntry/Open Feed : IValve

Warming UpEntry /bxHtrON

DistillingEntry/bxHtrON


Level OKEntry/Close Drain : IValve;Close Fill : IValve


Level LowEntry/Open Feed : IValve



Purging ResidueEntry/Open Drain : IValve













DrainingEntry/Open Drain : IValve

Cooling OffEntry/bxHtrOFF;Open Drain : IValve;Open Fill : IValve

pw rO n/

[NOT bxLevelLow]/

[bxTemp = 100degrees]/

[NOT bxLevelLow]/

[bxLevelLow]/

[bxLevelHigh]/

[NOT bxLevelHigh]/

/

DrainTim er/

Res idueTimer/

[bxLevelBelow]/[bxTemp < 100degrees]/

shutDown/

This final diagram capture the state based behavior of the Distiller through Controllerdetected events.




Distiller Problem – Process Used

• Organize the model, identify libraries needed• List requirements and assumptions• Model behavior

– In similar form to problem statement– Elaborate as necessary

• Model structure– Capture implied inputs and outputs

• segregate I/O from behavioral flows– Allocate behavior onto structure, flow onto I/O

• Capture and evaluate parametric constraints– Heat balance equation

• Modify design as required to meet constraints




Systems Modeling Activities - OOSEM

SynthesizePhysical

Architecture

DefineSystem

Requirements

DefineLogical

ArchitectureOptimize &Evaluate

Alternatives

Validate &Verify

System

AnalyzeNeeds Major SE Development Activities

Common Subactivities

•Engr Analysis Models•Trade studies

•Test cases/procedures

•Mission use cases/scenarios•Enterprise model

•System use cases/scenarios•Elaborated context•Req’ts diagram

•Logical architecture

•Node diagram•HW, SW, Data architecture

Copyright © Lockheed Martin Corporation 2000 – 2003 & INCOSE 2004-2006

Use ISSEP chart for Design and Verify System activity.Note: Mention IPT.

Try to show SE and software on same page

-- Highlight differences.




Using Process ImprovementTo Transition to SysML




Integrated Tool Environment

Project Management

CM

/DM

Pro

duct

Dat

aM

anag

emen

t

Req

uire

men

tsM

anag

emen

t

Engi

neer

ing

Per

form

ance

Ana

lysi

s

Ver

ific

atio

n&

Val

idat

ion

SoS / DoDAF / Business Process modeling

System modelingSysML

Software modelingUML 2

Hardware modelingVHDL, CAD, .. S

peci

alty

Engi

neer

ing

Ana

lysi

s

Documents

An Introduction to OMG Systems Modeling Lang · • Is a visual modeling language that provides ... Grumman, oose.de, Raytheon, THALES • Vendors – Artisan, EmbeddedPlus, Gentleware,