Introduction to Sysml an Introduction to the OMG Systems Modeling

Introduction to SysML

An Introduction to the OMG Systems Modeling Language (OMG SysML™) Clarence C. Moreland Principal Consultant, ARTiSAN Software Tools

Caveat

• This material is based on the Final Adopted SysML specification (ad-06-05-04) – Adopted by OMG in May ’06 • Some of the slides are based on the OMG SysML tutorial and are used with permission.

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

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

Introduction Systems Engineering with SysML Requirements and Requirements Diagrams Structural Diagrams Blocks and Block Diagrams Behavioral Diagrams Use Case modelling Activities and Activity Diagrams Sequence Diagrams State Machines Cross-cutting Concepts Requirements traceability Allocations Package Diagram Parametric Diagrams Process Issues Q&A

SE Practices for Describing Systems

Past • Specifications Future

• Interface requirements

• System design

• Analysis & Trade-off

• Test plans

Moving from Document centric to Model centric

System Modeling

Requirements

Integrated System Model Must Address Multiple Aspects of a System

Model Based Systems Engineering Benefits

• Improved communications • Assists in managing complex system development – Separation of concerns – Hierarchical modeling – Incremental development & evolutionary acquisition • Improved design quality – Reduced errors and ambiguity – More complete representation • Early and on-going verification & validation to reduce risk • Other life cycle support (e.g., training) • Enhanced knowledge capture

What is SysML?

• A graphical modelling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 – a UML Profile that represents a subset of UML 2 with extensions

• Supports the specification, analysis, design, verification, and validation of systems that include hardware, software, data, personnel, procedures, and facilities

• Supports model and data interchange via XMI and the evolving AP233 standard (in-process)

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

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

SysML Team Members

• Industry & Government – American Systems, BAE SYSTEMS, Boeing, Deere & Company, EADS-Astrium, Eurostep, Lockheed Martin, NIST, Northrop Grumman, oose.de, Raytheon, THALES • Vendors – Artisan, EmbeddedPlus, Gentleware, IBM, Gentleware, I-Logix, Mentor Graphics, Motorola, PivotPoint Technology, Sparx Systems, Telelogic, Vitech Corp • Academia – Georgia Institute of Technology • Liaison Organizations – INCOSE, AP233 WG

Introduction to SysML

Diagram Overview

Reuse of UML 2.0 for SysML

UML 2.0 SysML

UML not UML reused SysML required by by SysML Extensions SysML

This workshop deals with the full set of SysML diagrams, both the 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 and constraints • Stereotype properties capture metadata about the model element – Profile is applied to user model – Profile can also restrict the subset of the meta-model used when the profile is applied • Model Libraries represent reusable libraries of model elements

Stereotypes

Defining the Stereotype Applying the Stereotype

Tag Definition and Tag Value

• Tag Definition – the definition (name, type) of an additional model item property – applied to a model item via linked stereotype(s) • Tag Value – data value(s) for a specific tag definition for a specific model item

When you apply a stereotype to a model item, you often want to attach additional information to that element. In the example of a «COTS» stereotyped board you might want to specify the cost of that board. This is done by linking a tag definition (named, for example, ‘cost’) to the stereotype through which a tag value (for example, “24.50”) can be specified for that board.

Applying a Profile and Importing a Model Library

SysML Taxonomy of Diagrams

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition [1] Block [2] Machine

Sequence Use Case

Parametric [1] Modified UML Class Diagram

[2] Enhanced UML Composite Structure Diagram

SysML reuses many of the major diagram types of UML. In some cases, the UML diagrams are strictly re-used such as use case, sequence, state machine, and package diagram, whereas in other cases they are modified so that they are consistent with SysML extensions. For example, the block definition diagram and internal block diagram are similar to the UML class diagram and composite structure diagram respectively, but have extensions or omissions. Activity diagrams have also been modified. SysML does not use all of the UML diagram types such as the object diagram, communication diagram, interaction overview diagram, timing diagram, and deployment diagram. This is consistent with the approach that SysML represents a subset of UML. In the case of deployment diagrams, the deployment of software to hardware can be represented in the SysML internal block diagram. In the case of interaction overview and communication diagrams, it is felt that the SysML behavior diagrams provided adequate coverage for representing behavior without the need to include these diagram types. Two new diagram types have been added to SysML : the requirement diagram and the parametric diagram. [SysML v1.0]

Modelling and Your Project

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

• You may have additional ‘specialized’ modelling requirements: – process related – domain related – customer defined – etc.

For many organizations, any approach to modeling needs to be customized, to include standards, notation and information relevant to the organization, its customers, and the projects it undertakes. This need to extend the modeling capability of the language is recognized within the UML by the specification of extension mechanisms. The UML provides a mechanism for extending or customizing modeling information. This mechanism uses the above concepts to ‘label’ model elements and to define additional properties for them.

The Four Pillars of SysML (ABS Example)

1. Structure ibd [Block] Anti-Lock Controller1 2. Behavior «Block» bdd [Package] Vehicle [ABS] Anti-Lock Controller interaction

«Block» «Block» «Block» stm Tire [Traction] Library:: Anti-Lock Library:: «BlockProperty» state machine Electronic Controller d1 : Traction Detector Electro-Hydraulic Los sOfTrac tion/ Processor Valve act PreventLockup activity/ c1:modulator interface Gripping functionSlipping «BlockProperty» d1 m1 m1 : Brake Modulator Detect Loss Of TractionLossRegainTraction/Modulate «Block» «Block» Traction Braking Force Traction Brake Detector Modulator use definition

par [constraint] StraightLineVehicleDynamics [Parametric Diagram]

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

req [Package] Vehicle Specifications [Braking] : BrakingForceEquation : AccelerationEquation 3. Requirements tf f F c Vehicle System Braking Subsystem tl Specification Specification

bf a «requirement» «requirement» Stopping Distance Anti-Lock Performance 4. Parametrics id# id# 102 337 : DistanceEquation : VelocityEquation txt txt x v v The vehicle shall stop from The Braking subsystem shall 60 mph within 150ft on a prevent wheel lockup under a clean dry surface. all braking conditions.

{v = dx/dt} {a = dv/dt} «deriveReqt»

Structure e.g., system hierarchies, interconnections behavior e.g., function-based behaviors, state-based behaviors Properties e.g., parametric models, time variable attributes Requirements e.g., requirements hierarchies, traceability

SysML Diagram Frames

• Each SysML diagram represents a model element • Each SysML Diagram must have a Diagram Frame • Diagram context is indicated in the header: – Diagram kind (act, bdd, ibd, seq, etc.) – Model element type (activity, block, interaction, etc.) – Model element name – Descriptive diagram name or view name • A separate diagram description block is used to indicate if the

diagram is complete, or has elements hidden Diagram Description

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

«diagram usage» diagramKind [modelElementType] modelElementName [diagramName] Contents

Introduction to SysML

Requirements

The Requirements Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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

What are Requirements?

• Statement of a customer’s needs and expectations • Describes the essential characteristics of the customers goals • Requirements should be problem based and not describe the solution. However, if there are solution based elements in the requirements, these must be modelled and included in the solution.

The SysML Requirements Diagram What is it used for?

• The Requirements diagram can be used for a variety of purposes throughout the system lifecycle: – Traditional text requirements and their properties (e.g., id, statement, criticality, etc) – Grouping a set of requirements in a package – Breaking down requirements into constituent elements – Demonstrating traceability between derived and source requirements – Showing which design elements satisfy which requirements – Verification of a requirement, or design element by a test case – Rationale for all of the above

How the requirements diagram is used will vary depending on the industry, company, project, and process. It’s main strength is in its ability to graphically represent requirements and how they pertain to the rest of the UML model.

Requirements

• A requirement “specifies a capability or condition that must (or should) be satisfied” [SysML] • Can specify function to be performed or performance criteria to be met • Basic attributes of a Requirement – ID: A unique identifier for the Requirement – Text: A Description of what is Required. • Users can create stereotypes and tags to add specific properties, e.g. – Requirement type (Performance, Safety, Functional, etc.) – Criticality – Test method «requirement» – Status REQ_A1 – Etc. txt The System shall do... reqtType function

SysML Requirements Diagram Elements

req Requirement Diagram 1 «rationale» «requirement» explanation «problem» REQ_A1 description of problem txt The System shall do... Model Element T reqtType «trace» function Requirement Containment

«requirement»

derivedFrom «requirement» «requirement» Model Element A REQ_A1.1 REQ_A1.1 REQ_A1.2 «refine»

«deriveReqt» «testCase» Model Element B «requirement» «verify» Callout REQ_B1

Design Elements «requirement» REQ_D «requirement» Model Element C «copy» txt REQ_C «satisfy» same text

The requirement diagram shows both requirements and the different types of relationship that can be specified between them. Requirement properties (such as the textual description) can be shown if required. Containment (sometimes referred to as ‘flowdown’) is used to show where requirements are decomposed into sub-requirements. The «deriveReqt» and «copy» relationships can only exist between requirements. «trace», «refine», «satisfy» and «verify» can exist between a requirement and any other model element. The «verify» relationship can only exist between a requirement and a behavioral model element stereotyped as a «testCase». An alternative to these direct relationships is to use the callout notation – only one example of the callout notation is shown here. «problem» and «rationale» comments can be added as required to any model element to capture issues and decisions.

SysML Requirements Diagram Example

req [package] UserRequirements Customer Brochure

«UseCase» «trace» Distill Water

«requirement» «refine» Produce Distilled Water «requirement» txt «rationale» 30 ° is deemed a safe Condenser Efficiency Distill dirty water into pure water «deriveReqt» output temperature txt The condenser needs to «requirement» cool the pure water to 30 Water Output °C txt rationale The pure water output « » High pressure w ater may «requirement» must be at a safe overpow er the boiler so Handle Overflow temperature an overflow valve is txt needed The system must have an «requirement» Water Input overflow valve in the main heating vessel «deriveReqt» txt The system must be able «deriveReqt» «requirement» to connect directly to Provide Input Protection mains water txt «rationale» The system shall have an Direct connection to high «requirement» input valve that is closed pressure mains w hen the when the system is off Water Throughput system is off might cause damage txt The system shall handle «activity» 1 litre of water per minute «satisfy» Distill Water «rationale» Analysis of this activity show s that the throughput is possible

Problem and Rationale

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

An Automotive Example

The Business Process

The Business Case

Marketing have identified a niche inThe the market Business for a mid-range Case engine, high-specification vehicle (Named: XSV-2001). The eventual cost of the vehicle will be in the range of £16K-£20K, with a proposed launch date of Spring 2003. Finance have made £300K available for Conception and DevelopmentWill (includingspecify any re the-tooling Requirement and training on the for production a System line). (e.g. The estimated a Car) profit margin is 10%-15% per production unit. Minimal changes will be made to existing production lines and tooling, and maximum use of existing components is mandated. A review will be held in 4-months to determineMay include‘go-ahead (solution’ of Development-based) (and subsequent) capabilities phases. of Target the System market: Executiv (e.g.e Cruise Fleet and Family. Control, EMS, ABS)

FeatureMay include-Set Constraints (e.g. Cost, Time, Component Reuse, Tooling) Standard Front-Wheel Drive, Front-engine, 5-Door (hatch-back), 5-Seat three-point inertial seat-belts (standard options of colour & cover); 1999ccm Variable Valve Control Petrol Engine; Integrated Traction & Cruise Control; Engine Management System (EMS) (including both Control and Diagnostics); Advanced Breaking System (ABS); Electric Windows & Seat Adjustment and Heating (Front seats only, Front windscreen only); … Optional: Front and Rear proximity sensors (including distance read-out and audio warning); GPS Navigation System (including audio instructions); (Sports Option) Engine Management System; …

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

Introduction to SysML

SysML Structure

Block Diagrams

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

Blocks are Basic Structural Elements

• Provides a unifying concept to describe the structure of an element or system – Hardware – Software – Data – Procedure – Facility – Person

• Multiple compartments can describe the block characteristics – Properties (parts, references, values) – Operations – Constraints – Allocations to the block (e.g. activities) – Requirements the block satisfies

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 among blocks (e.g., composition, association, classification) • Internal block diagram describes the internal structure of a block in terms of its properties and connectors • Behavior can be allocated to blocks

Blocks Used to Specify Hierarchies and Interconnection

Block Definition Diagram (bdd) Notation

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

«Block» «Block» Generalization ::Block1 ::Block1::Block3

Compartments Namespace containment «ValueType» «Block» 1 * «Block» ValueType1 Block2 Block6 refParts dimension parts Dimension1 myPart : Block4 unit refParts : Block6 [*] Unit1 sharedPart : Block5 [0..1] Reference references refParts : Block6 [*] association values aValue : ValueType1 Shared Part (role) association Part 1 1 association names myPart 1 1 0..1 sharedPart 1 «Block» «Block» Block4 Block5 Actor1 Multiplicity

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

Internal Block Diagram (ibd) Notation

ibd [Block] Block2 [ibd Notation]

«Block» Enclosing Block2 Block Part fPort1 fPort2 0..1 «BlockProperty» «BlockProperty» myPart : Block4 «ItemFlow» sharedPart : Block5 ItemFlow1 : ItemType pI/F ItemItem Flow Flow fPort3 sPort «ItemFlow» ItemFlow2 : ValueType1 rI/F fPort4 Port * Reference «BlockProperty» refParts : Block6 Property «ItemFlow» (in,(in, but but not not of) of) ItemFlow3 : DataType2

Connector Internal Block Diagram Specifies

InterconnectionInterconnection of of Parts Parts Actor1

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

Parts

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

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

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

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

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

Interface1 Interface1

«BlockProperty» «BlockProperty» part1 sp1 sp2 part2

Standard Port

fp1 : ItemType1 fp2 : ItemType1 «BlockProperty» «BlockProperty» part1 part2

Atomic Flow Port

fp3 : FlowSpec1 fp4 : FlowSpec1 «BlockProperty» «BlockProperty» part1 part2

Non--atomic Flow Port

Standard ports are typed by one or more interfaces. A provided interface (lollipop) specifies the services provided through the port; a required interface (cup) specifies required services.

Note the consistency of direction of the atomic flow ports.

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

Unit and Item Types

bdd Units bdd [package] Items • Unit types «block» Heat «valueType» normally based kg values Q:J on Real dimension = mass unit = kilogram «block» • SI Units and Electricity «valueType» values Dimensions J p : W unit = Joules defined in SysML «block» appendix Fluid «valueType» values kg/m² lh: J/kg = 520 press : Pa dimension = pressure sh : J/kg/°C = 1 unit = kilograms/square meter t : °C

«valueType» kg/s

unit = kilograms/second «block» «block» H2O Residue «valueType» values values ºC lh : J/kg = 520 lh : J/kg = 520 m : kg = 0 press : Pa dimension = temperature press : Pa sh : J/kg/°C = 1 unit = degrees Centigrade sh : J/kg/°C = 1 t : °C t : °C

Port Typing

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

bdd [package] Flow Specifications «valueType» Flow °C «Interface» «flowSpecification» «block» Temp Specification Digital Set Throttle Liquid «valueType» flowPropertyList values Set Throttle () kg/m² in Value : V MassFlowRate : gm/sec Press Press : kg/m² Temp : °C «valueType» «Interface» gm/sec MassFlowRate EMU Msg «flowSpecification» FPump-ICE Send () flowPropertyList in FuelSupply : Fuel out FuelReturn : Fuel «block» «valueType» «Interface» Fuel SysML Extras::SI Unit Types::A TransmIF values MassFlowRate : gm/sec Gear () Press : kg/m² Temp : °C

«valueType» «flowSpecification» Analogue TorqueSpec flowPropertyList Interface in TorqueIn : Torque out TorqueOut : Torque Block Value Type

Delegation Through Ports

• Delegation can be used to preserve encapsulation of block ibd [block]Block1[delegation] • Interactions at outer ports of Block1 are delegated Child1: to ports of child parts • Ports must match (same kind, types, direction etc.) Child2: • (Deep-nested) Connectors can break encapsulation if required (e.g. in physical system modelling)

Connectors and Flows

Flow Ports – «FlowSpecification» FlowSpec1 type specifies flowPropertyList what can flow in FlowProperty1 : Block3 in/out out FlowProperty2 : DataType1 inout FlowProperty3 : ValueType2

fp1 : FlowSpec1 fp2 : FlowSpec1 «BlockProperty» «BlockProperty» Part 1 : Block B Part 2 : Block C «ItemFlow» ItemFlow1 : DataType1

Item Flow - Specifies what Connector does flow (in context)

A connector is a link between parts that enables communication between them. The flow ports, through their type, define what sort of things can flow across the connector. This can be discrete items such as a data packet or an interrupt, or continuous flows like heat or fluids. What does actually flow in the specific context of a specific diagram is specified by one or more item flows, whose type must be consistent with that of the flow ports.

Structure vs. Usage

Block Definition Diagram Internal Block Diagram

Definition Usage – Block is a definition/type – Part is the usage in a – Captures properties, etc. particular context – Typed by a block – Reused in multiple contexts – Also known as a role

Block Definition Diagram Example

bdd [Package] Distiller [Structure - with compartments] «Block» Heat Exchanger «Block» Distiller values tempGradient : Real • Parts compartment operations flowPortList TurnOn () shows structural children out HEClean_Out : H2O TurnOff () in HEDirtyIn : H2O 1 parts out HEHotDirty_Out : H2O • Values compartment bx1 : Boiler hx1 in HESteam_In : H2O cx1 : Controller shows properties of the drain : Valve feed : Valve «Block» block hx1 : Heat Exchanger Boiler ui1 : Control Panel values • Flowports compartment flowPortList Max : temp out DSClean_Out : H2O Min : temp describes the interface in DSDirty_Out : H2O bx1 flowPortList out DSExcess : H2O out BLExcess : H2O to the block in DSPower_In : Power in BLHotDirty_In : H2O out DSResidue_Out : Residue in BLPower_In : Power • Operations compartment inout blrSig : blrSig out BLSteam_Out : H2O shows functional 1 out BLSteam_Out2 : Residue capabilities (a means of drain «Block» 1 cx1 Valve invoking block activities 1 «Block» flowPortList – dealt with later) Controller feed in Feed_HotDirty_In : H2O out Feed_HotDirty_Out : H2O operations in Fluid_In : Fluid pwrOn () 1 ui1 out Fluid_Out : Fluid ResidueTimer () DrainTimer () «Block» 1 1 shutDown () Control Panel user

User

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

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

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

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

The Operations compartment (if shown) will list all block operations. An operation specifies a functional capability of the block, and acts as a means through which block activity can be invoked. This topic is dealt with in greater detail later in the course.

IBD for Distiller

PureWater

block Distiller ibd [block] Distiller waterOut : H2O

pFOut dirtyWater waterIn : H2O ipinValve : hx : FlowValve op fIn : Fluid HeatExchangerHEC hxWaterOut : H2O BC

cnt blSludgeOut : Residue tempWrn blSteamOut : H2O SOut loPressResidue IValve blWrn bl : Boiler IValve IValve Excess : H2O IValve excess overFlow IPower IPower vI UserIO cnt wrn vO RegPower : Electricity Ocnt UI : FrontPanel controller : Controller PwrIn User ui blrPwr Rcnt ILamp ILamp vD pwrIn IValve problem PowerIn : Electricity IValve « » Overflow water is very hot! extPower • Non-Atomic Flow Ports (BC and HEC) • Atomic FlowPorts (dirtyWater, – I/O is specified using FlowSpecification extPower …) – FlowSpecification consists of properties – In this case the port is directly typed by the item type (Block or ValueType) stereotyped «FlowProperty» – Direction property specifies the – isConjugate promotes reuse of direction of flow flowSpecifications

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

ibd [Block] Boiler [drill down]

«Block» Boiler

BLSteam_Out : H2O HVSteam_Out : H2O Fluid_In : Fluid BLSteam_Out2 : Residue «BlockProperty» HVSludge : Residue vResidue : Valve Fluid_Out : Fluid «BlockProperty» tank : Heating Vessel HVExcess : H2O

HVHotDirty_In : H2O HVHeat_In : Heat BLExcess : H2O «BlockProperty» vOverFlow : Valve Fluid_Out : Fluid BLHotDirty_In : H2O ELHeat_Out : Heat Fluid_In : Fluid

«BlockProperty» • Shows parts (structural children) … heater : Element • … and ports (interaction points on ELPower_In : Power block and parts) BLPower_In : Power • Supports consistency of ‘layers’

The ports on the (enclosing) Boiler block can be automatically populated on this diagram from the information on the previous diagram.

Introduction to SysML

Use Cases

SysML Use Case Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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

Use Cases

• Provide means for describing basic functionality in terms of usages/goals of the system by actors • Common functionality can be factored out via include and extend relationships • Generally elaborated via other behavioral representations to describe detailed scenarios • No change to UML

Use Case Diagram

uc Diagram Name Subject Name

Weather Actor Monitoring Subject

Flight Crew Boundary Actor Generalisation

Air-To-Ground Use Case Strike

Pilot

Air-To-Air Tracking

Navigator

The subject may be the entire system or a component of that system. SysML syntax use the prefix ‘uc’ followed by the name of the diagram in the outer frame.

What is a Use Case?

• Use Cases describe the goals that actors have in relation to the system. • A Use Case meets a need or solves a problem for an actor. • So, what is an Actor ? • An Actor is an entity which is eternal to the system, which interacts with the system, but is not a part of the system. • Actors should reflect the entire system lifecycle including: manufacture, test, installation, maintenance, etc.

What is an Actor?

Expected Actors Unexpected Actors

Unauthorized A Person Users

An External Threats System

Adverse Abstract Environmental such as Time Conditions

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

Examples: Person - Pilot, Operator, Maintainer, etc External System - EPOS, Mainframe, etc Time - Timeouts, Scheduled events

What is a Use Case?

• Defines how the actors interact with the system

– Functionality triggered Shutdown by an actor Plant (Primary Actors) Remote Operator

– Functionality used by an actor Monitor System

Local operator

– Functionality in which Fuel an actor participates Transaction (Secondary Actors) Customer Kiosk Operator

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, … Start Local «Primary» System Operator «Secondary» Event Log • Generalization of actors System – indicates inheritance of Run use case interactions Diagnostics

A primary actor uses the system to achieve one or more specific goals. A use case specifies what the system must do to satisfy a goal. Primary actors often initiate the use case that delivers the goal.

It may be necessary for other actors to interact with the system in some well- defined manner in order for the primary 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 particularly relevant where the actor is human; the same person may be capable of playing more than one role with respect to the system. This situation may also imply a requirement for access controls to use case functionality.

The UML Generalization relationship (shown using the triangle notation) can be used to indicate a situation where one actor inherits the same set of use case interactions shown for another actor. The specialized actor normally also has additional use case interactions.

Use Case descriptions specify details

Automated Teller Machine

Withdraw Cash UseUse Case: Case: Withdraw Withdraw Cash Cash WhenWhen a a customer customer inserts inserts a a card, card, the the machine machine reads reads Deposit Fundsthe code fromTransfer the card Funds and checks if it is an Customer the code from the card and checks if it is an acceptableacceptable card. card. If If so so it it asks asks the the customer customer for for a a PIN PIN codecode (4 (4 digits). digits). If If not, not, the the card card is is ejected. ejected. • Other Attributes WhenWhen the the PIN PIN code code is is received received the the machine machine checks checks – Pre-conditions whetherwhether the the PIN PIN code code is is correct correct for for the the specific specific – Post-conditions card.card. If If so, so, the the machine machine asks asks for for what what transaction transaction (Guarantees) thethe customer customer wishes wishes to to perform. perform. – Constraints WhenWhen the the customer customer selects selects cash cash withdrawal withdrawal the the – Intent machinemachine asks asks for for the the amount. amount. Only Only multiples multiples of of $20 $20 – Alternate courses areare allowed. allowed...... – Stakeholders – Priority – Complexity * Slide 57 Copyright ©2006 ARTISAN Software Tools All Rights Reserved

It is very important to describe each use case thoroughly and in simple English. This description should be signed off by the user. This description also acts as a starting point for a more structured breakdown of the use case in later stages of development. For this it can be useful if the description employs a ‘subject - verb - object’ format, e.g. ‘customer inserts card’.

A single goal may require more 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

Basic use cases specify the main services the system provides for its actors, ignoring exception situations. Subordinate (to their base use cases) use cases can be specified for specifying exception handling or for specifying functional activity duplicated within more than one use case.

We can show the relationships between any subordinate use cases and their base use cases on the use case diagram.

«include» relationship extracts common courses of action

Card Validation

«include» «include» «include» Transfer Funds Deposit Funds Withdraw Funds • Common behavior may be extracted from other use cases

• Defines a ‘must be done’ relationship

• Simplifies change

An «include» relationship can be thought of as a subroutine type of relationship. In order to Withdraw Funds, Transfer Funds or Deposit Funds, it is essential to carry out a Card Insertion.

«extend» relationship models optional courses of action

• Model an optional part of a use case

• Allows introduction of separate sub-courses without affecting course of activity in base use case Bank Card Transaction

• Defines a ‘may get done’ relationship «extend»

Reject Invalid Card

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

Generalisation relationship models specialized Behavior

Initialize System

Power Supply

Power Up Initialization

Operator Reset

Operator • Child use cases inherit from parent use case

• Child use cases can extend behavior of parent

A generalization relationship between use cases implies that the child use case contains all the attributes, sequences of behavior, and extension points defined in the parent use case, and participates in all relationships of the parent use case. The child use case may also define new behavior sequences, as well as add additional behavior into, and specialize existing behavior of, the inherited ones. One use case may have several parent use cases and one use case may be a parent to several other use cases.

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

Use Cases

Use Cases • Use Cases specify, satisfy, realise, and/or encapsulate functional Use Case Name requirements • Provide efficient communication mechanism 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.

UseUse Cases Cases define define testable testable system system requirements requirements from from ananexternalexternalperspectiveperspective

A Use Case defines a service provided by a computer system for an actor. For instance, in using a word processor, some use cases would be : – Make the text bold; – Create an index; – Spellcheck the document;

The properties of a Use Case are that they : – describe some coherent system function; – may be large or small; – achieve a discrete goal for the actor;

Other possible properties include : – specifying actor intention in using the system; – capturing pre- and post-conditions; – defining alternate courses to the main flow of actions;

Typical Use Cases

Start Compressor

«include» Start Up Plant «include»

«extend» Maintain Gas «extend» Pressure

«extend» Local operator Handle Alarm Ammonia System «include» «include»

Shutdown Stop Plant «include» Compressor

Remote Operator

Systems Engineering Use Cases

Safety Engineer System Installer

Safety Install System Maintain Gas Inspection Pressure

Run Site Acceptance Tests Ammonia Start Up Plant System

Local operator «include» Monitor System Shutdown Plant «include» Alarm Verification Tests

Calibrate Power Off Sensors Maintainer

Replace System Remote Power On Power Fail Components Operator

Use Case Organisation

Power Up «include» Continuous Warm Built-In Test

Power Up Cold «Primary Actor» Multiple-Levels of Use Cases «Primary Actor» «include» Time Power «include» Power Up System Power Up Built-In Test SeeStore Information Use Case Diagram

«include» «Primary Actor» Pilot Shutdown Store «include» of Information

«include»

Execute Mission «include» Systems Communicate Use Case Diagrams can be organised Load Mission «Secondary Actor» Mission Plan

See Execute Mission Use Case Diagram

«Secondary Actor» «Primary Actor» «Primary Actor» Commander Navigator «Equivalent» around different levels of abstraction Bombadier from the ‘System of Systems’ perspective all the way to Use Cases supported by a

Store Information «PrimaryActor» «PrimaryActor» «Equivalent» Pilot «PrimaryActor» Bombadier specific Sub-System. Navigator

StoreWeapons Store Present Information Store Position Markpoint Store Navigation Information StoreTarget Destination System StoreSelected RADARFix WeaponType HUDMark Bombadier Use Cases

On-Top Mark

Store FixError Organisation by Domain RADARMark Any number of UseCaseDiagrams canbe createdtokeepthediagrams tidy. This diagram shows how different On-TopFix HUDFix types of informationcanbe stored NavigatorUse Cases withinthe system and by whom. The lowest level of abstraction (i.e. the Sub-System level) encapsulates all the Deploy Weapon

«include»

services (Use Cases) provided by a Pilot «include»

Store Target Store Selected Destination Weapon Type Sub- specific domain. «include» System Store Geodetic Point

Introduction to SysML

Activity Diagrams

SysML Taxonomy of Diagrams

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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 detail of that activity

• Useful for many purposes, including: – Exploring system functionality – Human/subsystem communication modelling – Data/item flow modelling – General flow of control modelling – etc.

Activity modeling is one of the principal means for describing behavior in SysML. This behavior can be linked with structural modeling (blocks) through allocations which will be covered later in the course. In practice, activity diagrams can be used for a surprisingly wide variety of modeling purposes. For systems engineering, exploring system functionality is one of the principal uses of these diagrams.

SysML Activity Modelling

• SysML activity modelling is based on, and inherits much from, UML 2.0 activity modelling

• Key SysML extensions are : – Stronger semantics for activity decomposition – Control as data – Continuous systems – Probability

Although SysML adopts much of the UML activity model, in this section we’ll consider SysML activity modeling as a ‘whole’, not distinguishing between which aspects are inherited and which are extensions.

Activities

• Represent a unit of behavior – Specifies sequencing of subordinate actions – Can be parameterized

activity parameter

act name decision

initial node action activity final

An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions. [UML]

Activity Decomposition

• 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

bdd Activity Breakdown act [activity] Activity 1 «activity» action name Activity 1

1 1 a2 : Activity 2 a3 : Activity 3 a2 a3 1 1 «activity» «activity» Activity 2 Activity 3

Definition Use

An important aspect of SysML activity modeling is the principle that activities can be treated like classes or blocks with decomposition and association relationships modeled on a block definition diagram. The activity diagram for that activity can then show instances of the sub-activities, where role names on the bdd become the instance names on the activity diagram.

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

Action Node

• Represents a single step within an activity

– not further decomposed action name – 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 action name : behavior name invocation – typically a ‘part’ activity (activity name may be hidden) – can be linked to a Block operation

These are one of the principle components of activity diagrams. Each action node defines a single step within the owning activity.

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

In general, actions are atomic (i.e. not further decomposed). Where the action represents a complete sub-activity, typically a ‘part’ activity on a bdd, a Callbehavior action is used. This normally has both the bdd role name and the part activity name displayed, although the latter can be hidden. Activities can be linked with Block operations – these operations are then the mechanism through which the activity is invoked.

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

bdd Activity Breakdown - with objects act [activity] Activity 1 «activity» 1 Activity 1 «DataType» dt1 : DataType1

1 1 1 a2 1 1 a3 a2 : Activity 2 a3 : Activity 3 «activity» «activity» Activity 2 Activity 3

dt1 0..1 b1 0..1 «Block» «Block» «DataType» b1 : B lock1 ::Block1 DataType1 object node name

Object nodes allow the modelling of flow of elements through an activity. Activities can be associated with both blocks and data types as well as other activities to indicate what type of flow elements relate to the activity. This can be by composition, where the flow element gets destroyed on completion of the activity.

Control and Object Flows (Activity Edge)

Object Control flow A c tion 1 Object flow

Object flow

Control flow Ac tion 2

• 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

Control Flows are another key component of activity diagrams, providing sequencing information. Object flows are only ever used with object nodes. Both type of flows can be named if required.

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

For those familiar with UML activity diagram modeling, note that the solid/dashed convention is reversed in SysML.

AJM4 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

Pins (must be same ObjectNode name & type)

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

Send Signal and Accept Event

• Send Signal Send Signal – shows a signal sent at completion of action node activity – may also link to action object (receiver)

• Accept Event Accept Event – shows a signal that initiates activity in action node – may also link to action object (sender) • Examples:

Door door interrupt

re-open door

Signal send and accept event boxes correspond to the concept of a ‘signal’ event on a state diagram. The ‘send’ represents a signal sent at completion of the activity in the preceding action node; an ‘accept’ represents a signal that triggers the activity of the subsequent action node.

A ‘send’ may also have an object flow going to the object that receives the signal; an ‘accept’ may have an object flow coming from the object that sends the signal.

Dragging an RtS event onto an activity diagram creates a send signal; its properties can then be used to change it to an accept event if required.

Interruptible Activity Region

• A bounded region of activity that can be terminated prior to region completion boundary

interrupting event

interrupting edge

This feature, new to UML 2.0, allows you to explicitly identify areas of activity where interrupts are allowed to terminate the activity in the region before completion. In RtS the boundary is a frame box with View Options set to show dashed lines (strictly, it should have rounded corners). The interrupting edge is a control flow with waypoints added.

Activity Diagram – Model Elements Control Nodes

• Coordinate flow in an Activity • Initial Node denotes start of flow in an Activity • Activity Final Node denotes end of flow in an Activity • Flow Final Node denotes termination of a flow – No effect on other flows in the Activity • Decision Node provides choice of outgoing flows – One incoming and multiple outgoing flows • Merge Node brings together multiple alternate flows – Multiple incoming and one outgoing flows • Fork Node splits a flow into multiple concurrent flows – One incoming and multiple outgoing flows • Join Node synchronizes multiple flows – Multiple incoming and one outgoing flows

Control Nodes are activity nodes used to provide coordination between other nodes.

Note that an Activity Final Node denotes end of flow in the entire Activity, whereas a Flow Final Node only terminates one flow, and has no effect on other flows (which might still be in effect) in the Activity.

The difference between a Decision Node and a Fork Node lies in the fact that in a Decision Node, a token arriving at the node will traverse only one of the multiple outgoing flows, whereas in a Fork Node, the arriving token is duplicated across the outgoing edges, each of which is traversed concurrently.

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

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 terminates flow 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 Behavior to 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 the SysML model. Full details are provided in the SysML spec..

Probability

• «probability» stereotype applied to action 1 outgoing edges (flows) from decision or object nodes

«probability» «probability» • Defines value (range: 0 – 1) for p (x ) 1-p(x ) probability of any flow being taken – Total of values from one node must equal 1 action 2a action 2b

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

When the «probability» stereotype is applied to edges coming out of decision nodes and object nodes, it provides an expression for the probability that the edge will be traversed. These must be between zero and one inclusive, and add up to one for edges with same source at the time the probabilities are used. When the «probability» stereotype is applied to output parameter sets, it gives the probability the parameter set will be given values at runtime. These must be between zero and one inclusive, and add up to one for output parameter sets of the same behavior at the time the probabilities are used. [SysML]

Activity Diagram – Distiller Example: Activity Structure

bdd [package]DistillerBehavior [Distiller Behaviour Breakdown] 1 1 «Activity» Distill Water 1

a1 : Heat Water 1 1 a2 : Boil Water «Activity» «Activity» Heat Water Boil Water

a3 : Condense Steam a4 : Drain Residue 1 1 pure : H2O coldDirty : H2O 1 1 «Activity» 1 «Activity» Condense Steam Drain Residue «Block» Item Types::H2O

«BlockProperty» cal/gm : specificHeat 1 1 «BlockProperty» cal/(gm*deg C) : latentHeat Remove Latent Heat of Vaporisation () Add Latent Heat of Vaporisation () 1 recovered : Heat 1 hiPress : Residue «Block» 1 1 external : Heat «Block» 1 hotDirty : H20 steam : H2O Item Types::Heat Item Types::Residue 1 loPress : Residue values values cal/sec : dQ/dt degrees C : temp gm/sec : massFlowRate kg/gm^2 : press

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

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

recovered : Heat coldDirty : H2O a1 : Heat Water [Liquid]

hotDirty : H20 [Liquid ] external : Heat a2 : Boil Water

steam : H2O hiPress : Residue [G a s] fork

loPress : Residue a4 : Drain Residue a3 : Condense Steam

pure : H2O [Liquid ] join

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

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

act [activity] Distill Water [Continuous Parallel Behavior]

coldDirty : H2O recovered : Heat hiPress : Residue [Liquid ] loPress : Residue

a1 : Heat Water a3 : Condense Steam a4 : Drain Residue

hotDirty : H20 steam : H2O [Liquid ] [G a s]

external : Heat a2 : Boil Water pure : H2O [Liquid]

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

Parts

«allocate» «allocate» «allocate» hx1 bx1 drain : Heat Exchanger : B oiler :V alve act [activity] Distill Water [Simultaneous Behavior with Allocations]

«continuous» «continuous» «continuous» hiPress : Residue «continuous» loPress : Residue coldDirty : H2O recovered : Heat [ Liquid] steam : H2O [G a s ]

a4 : Drain Residue «streaming» «streaming» a1 : Heat Water a3 : Condense Steam

«continuous» hotDirty : H20 [ Liquid]

«continuous» «streaming» «continuous» external : Heat a2 : Boil Water pure : H2O [Liquid ] ShutDown

Introduction to SysML

Interactions

SysML Sequence Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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

Usage Scenarios – Overview

• Usage Scenarios are created for two reasons:

– Understanding the requirements in more detail by creating a model of the end-users problems (Modelling the Problem)

– Typically however, after defining an initial System Architecture and exploring the capabilities of the system (captured as Use Cases) you’ll want to see how the capabilities are delivered by the components within the 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

Sequence Diagrams

sd SD Concept

Describe use Description Actor1 «Block» «Block» «Block» case or scenario part a part b part c :Block A :Block B :Block C sequence seq signal1 {10ms} Specify timing par budgets and seq message 1 {250ms} constraints loop seq max.: {100ms} message 2 Define loops and break conditional paths seq message 2 for system end loop functionality also par alt seq Demonstrate message 3 parallel and seq message 4( param ) synchronous end alt functionality seq signal2 end par

Interaction Fragment

• a ‘piece of interaction’ [UML] – e.g. part of a sequence diagram • no defined notation in UML/SysML • represented by an interaction frame in Studio

Loosely defined in the UML as ‘a piece of interaction’, it has no specified notation. In Studio we have made use of the ‘ interaction frame’ element to allow the scoping of the required ‘piece of interaction’. By default, the name given to the fragment is taken from the first description step covered by the frame, but it can be renamed.

Sequence Diagram - Fragments

• A Fragment can be drawn around a set of interaction messages. • Fragments are given default names (in italics) depending on their 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. * Slide 95 Copyright © 2006 ARTISAN Software Tools All Rights Reserved

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

Sequence Diagram – Example Fragments

sd SD Fragments

Description Actor1 «Block» «Block» «Block» part a part b part c :Block A :Block B :Block C

seq signal1 {10ms} par par seq message 1 {250ms} loop loop seq max.: {100ms} message 2 break seq message 2 end loop

also par alt alt seq message 3 seq message 4 end alt

seq signal2 end par

Interaction Use

• a reference from a step on one sequence diagram to an interaction (represented by another sequence diagram in Studio) • allows partitioning of the interaction model – e.g. a single use case can be split over several diagrams

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

Part Decomposition

• a reference from an interaction entity (not necessarily a part) on one diagram to another diagram • allows decomposition of the interaction model – e.g. the internal interactions taking place within the entity, as a result of a message, can be shown separately

Similar in principle to an interaction occurrence, this form of decomposition reflects the structural decomposition represented on internal block diagrams. In the above example the referenced ‘Start Boiler [detail]’ diagram would show the interactions taking place between the component parts within the Boiler part of the Distiller in order for the Boiler part to implement the ‘powerOn’ operation. Typically then, there would be a internal block diagram (ibd) that would show the interaction entities shown above with connectors consistent with the above messaging, and there would be another internal block diagram showing the internal component parts of the Boiler and their connectors. It is these internal parts and their messaging that would be shown in the ‘Start Boiler [detail]’ diagram.

Part Decomposition - Example

Description User «BlockProperty» «B lock» «BlockProperty» Distiller.ui1:Control Panel :Distiller Distiller.bx1:Boiler ref Start Boiler

s tart up StartUp start Distiller TurnOn start Boiler powerOn

sd Start Boiler

Description «Block» «BlockProperty» «BlockProperty» «BlockProperty» :Boiler Boiler.heater:Element Boiler.vOverFlow:Valve Boiler.vResidue:Valve

power on boiler powerOn switch on heater on open overflow open open residue open

This example illustrates interaction modelling at 2 different levels of abstraction: black box (top diagram) and white box levels. The lower diagram is modelling what happens inside the boiler on receipt of the powerOn message.

Note the names of the various BlockProperty parts, indicating their parent block, as well as their block type.

Identifying Block Functional Requirements with Use Case Scenarios

seq Operate Distiller [UI Operations] «Block» Control Panel Description U ser «B lock» «B lock» :Control Panel :Controller operations pwrLightON () pres s s tart StartU p opLightON () turn on Distiller pw rO n hghLightON () show power on Operation call pw rLightO N drnLightON () wait for water to boil messages lowLightON () show operating opLightO N opLightOFF () repeat loop pwrLightOFF () alt alt water high hghLightO N els e alt • Messages imply draining drnLightO N els e alt need for Block water low low LightO N operations end alt • Block operations until... define functional ...press stop S hutD ow n requirements for turn off Distiller shutD ow n show not operating block opLightO FF show power off pwrLightOFF • Operations can map to actions

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

Refinement through Iteration

Use Case Candidate Sequence Description Entities Diagram

:Barrier Motor Red Green :Beam Sensor :Pressure Sensor :Controller :Car Count :Light :Light

entry beam detects car break {5ms} beam sensor signals controller car_arrived controller checks for space isFull {5ms} If full suspend entry Car Waits EndIf open barrier open turn off red light off turn on green light on car passes through beam connect beam sensor signals controller car_entered increment car count increment close barrier close turn off green light off turn on red light on car triggers pressure sensor detect pressure sensor signals controller car_exited decrement car count decrement

Iterate

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 Controller and the Control Panel shown in the previous slide, implies that the Controller knows when the water level is high or low. This implies there must be some connector between the Controller and the Boiler with appropriate ports and flow spec. – these would now be added to this ibd.

Sequence Diagram versus 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 model behavior is not an easy one. It will largely depend whether you see it better to model action sequences or message sequences. It is unlikely that you will model both for a single aspect of behavior, such as a use case.

Sequence Diagram and Internal 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 of Studio is to allow item flows to be used as messages on sequence diagrams, as long as their use has already been specified on the same parts on an IBD.

Introduction to SysML

State Machines

SysML State Machine Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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

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 or one 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 block may correspond to a complete system or subsystem, or it may type a component within 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

Main State Diagram Modelling Elements

event [guard] / effect State 1 State 2

States Events

Initial/Final States Guards

Transitions Effects

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

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

Events

• An ‘occurrence’ that may trigger potential effects

• 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 a signal message on a sequence diagram). Call events represent the receipt of an operation call (a message arriving). The operation must belong to the block owning the state machine. Time events model the expiry of a specified period of time. Timing starts on entry 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 expression becoming true. Change events use the keyword ‘when’ preceding the Boolean expression in brackets, e.g. when(a=0). Conceptually, change events are continuously evaluated. An entry event is the event that completes an external transition and models the entry into the destination state. Entry events normally specify an effect (often as a set 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 the exit from the source state. It also normally specifies an effect, e.g. Exit/clear display. If no event is shown on a transition, the transition is deemed to be taken on completion of any activity within the source state.

Transitions

• 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 external transitions

internal transition

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 states may 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 when the 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 occurs and the transition only takes place if true. Where a guard is shown without a preceding event, the condition is evaluated, while in the source state, whenever any event occurs, and a transition takes place if true.

Initial and Final States

• Initial (pseudo)state

• points to the entry state for a region of /initial action a state machine • can have an initial action (effect) • only one permitted within any region of State 1 a state machine

• Final State • Indicates completion of all state activity /completion action for the region containing the final state • can be more than one in a region • can be named and show completion action Final 1

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

A Simple Example

stm [Block] H2O1 Gas

Remove Latent Heat of Vaporisation/ Transitions

States Add Latent Heat of Vaporisation/

Liquid

Remove Latent Heat of Vaporisation/

Add Latent Heat of Vaporisation/ Events

Solid

A state machine for water.

Junctions

• Allow merging of multiple incoming transitions to a single outgoing transition • Allow branching of single incoming transition into multiple outgoing (guarded) transitions • can use [else]

junction

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

Composite State - Sequential

Applies to all sub-states Sequential State

stm [Block] Boiler Operating highResidue/open residue valve lowResidue/close residue valve

powerOn/switch on heater

Heater On

when( temp=Max )/ switch off heater powerOff/switch off heater when( temp=Min )/ switch on heater

Heater Off Substates

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

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

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 initial state, or directly to a substate, where for example, you want to show different transitions 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 the system is in.

Concurrent States

stm [block] Container concurrent state

Processing region Routing

join

Moving Idle

Registering Scanning

Capturing data fork synch state Processing data

A concurrent state consists of two or more regions where each region describes concurrent behavior. A concurrent state can be used to model a situation when an object can be in two or more states simultaneously. In the above example a container can be scanned while it it being routed. Exit from the concurrent Processing state occurs only when both regions are in their final states. A synch state can be used to synchronize activity between regions. Here, for example, we can only capture data after a movement step has completed and previous data has been processed. It is possible to limit the number of outgoing transitions from a synch state by setting a bound on the difference between the number of times incoming and outgoing transitions fire. The synch state has been deprecated from UML 2.0 but will remain a part of Studio as it is an essential concept for capturing the synchronization mechanism (e.g. priority-ceiling protocol) used in the synchronization of data between two concurrent state regions. Synchronization bars are used with synch states. There are 2 types of these, fork and 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

Operating • Notation is ‘do : activityname’ do : Boil Water

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

More Complex Example

stm [block] Distiller Controller [Distiller States] Cooling Off Entry/bxHtrOFF; [bxTemp < 100degrees]/ Draining Open Drain : IValve; [bxLevelBelow]/ Off Entry/Open Drain : IValve Open Fill : IValve Entry/pwrLightOFF s hutDown/ pw rO n/ Distilling Entry/bxHtrON Filling Controlling Boiler Level Entry/Open Feed : IValve [NOT bxLevelLow]/ [bxLevelHigh]/

Level Low Level OK Level High [NOT bxLevelLow]/ Entry/Open Drain : IValve Entry/Open Feed : IValve Entry/Close Drain : IValve ; Close Fill : IValve [bxLevelLow]/ [NOT bxLevelHigh]/ Warming Up Controlling Boiler Residue Entry/bxHtrON

/ ResidueTimer/ [bxTemp = 100degrees]/ Building Up Residue Purging Residue Entry/Close Drain : IValve Entry/Open Drain : IValve DrainTimer/

Introduction to SysML

Cross Cutting Concepts

Requirements Traceability

Requirements: Structure or Behavior?

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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

SysML Requirements Traceability

«requirement» Model Element T REQ_A1 «trace» Traceability relationships between

«requirement» «requirement» Model Element A requirements REQ_A1.1 REQ_A1.2 «refine» and model elements «deriveReqt» «testCase» Model Element B «requirement» «verify» REQ_B1

Design Elements

«requirement» Model Element C REQ_C «satisfy»

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

Requirements Traceability from Other Diagrams

refines Use Case A REQ_A1.2

Actor1

satisfies Use Case B REQ_A1.1

Actor2

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

Once the traceability relationship has been established in the model, callouts can be added to show the relationship from the model element wherever that element appears. Note that we have created a new use case and a «satisfy» relationship between it and REQ_A1.1 to show in this illustration that all types of traceability relationship can be added.

SysML Requirements Traceability Table

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

Introduction to SysML

Cross Cutting Concepts

Allocations

• Represent general relationships that map one model 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 swim lanes (i.e., activity partitions) • Both graphical and tabular representations are specified

Different Allocation Representations (Tabular Representation Not Shown)

«allocate» «allocate» Element Name2 :ElementName Element Name1 Element ActionName «allocate» Name3

Allocate Relationship Explicit Allocation of Action to Swim Lane

«block» BlockName «block» BlockName allocatedFrom PartName «elementType»ElementName

allocatedFrom PartName «elementType»ElementName

Compartment Notation Callout Notation

Behavioral Allocation – Actions to Parts using Activity Diagram Swimlanes

Parts

«allocate» «allocate» «allocate» hx1 bx1 drain :Heat Exchanger :B oiler :V alve act [activity] Distill Water [Simultaneous Behavior with Allocations]

«continuous» «continuous» «continuous» hiPress : Residue «continuous» loPress : Residue coldDirty : H2O recovered : Heat steam : H2O [Liquid] [G as ]

a4 : Drain Residue «streaming» «streaming» a1 : Heat Water a3 : Condense Steam

«continuous» hotDirty : H20 [Liquid ]

«continuous» «streaming» «continuous» external : Heat a2 : Boil Water pure : H2O Actions [Liquid] ShutDown

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

Structural Allocation Abstract to Concrete

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

«Block» Block1

«BlockProperty» : ConcreteExample «BlockProperty» : AbstractExample «Allocate» «BlockProperty» Part4 «BlockProperty» Part2 «A llocate»

«BlockProperty» «Allocate» Part5

«BlockProperty» «Allocate» Part3 «BlockProperty» Part6 «Allocate»

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

Abstract to Concrete Allocation: Example

EMU : EMU Message CCIF : RS232

EMUIF : RS232 «BlockProperty» Power : Electric Power Set Throttle : AnalogueMessage CC Sys : Cruise Control System

«BlockProperty» CCIF : Analogue TransmIF : Analogue PowSys : Power Subsystem «ItemFlow» BrakeIF : Digital Gear : Analogue concrete allocatedFrom implementation «Connector» Power-CC System

GearShiftIF : Force AccelIF : Force

«BlockProperty» Power-CC System «BlockProperty» abstract PowSys : Power CC Sys : Cruise Control Subsystem System concept

Two fragments from IBDs have been used to illustrate this using the Cruise Control application. The lower fragment is from the initial ‘Vehicle Main Subsystems’ IBD; the upper fragment is from the later ‘Driver Interface Connections’ IBD, and shows implementation detail for the Power-CC System connector.

SysML Allocation of SW to HW

ibd [node] SF Residence

«node» SF R esid ence Installati on

* 2 • In UML the «hardware» « hardware» «hardware» : Optical Sensor deployment : Video Camera : Alarm diagram is used to deploy «hardware» artifacts to : Site Processor «hardware» nodes allocatedFrom : NW Hub «hardware» « software» Device Mgr : DSL Modem allocatedFrom « software» Event Mgr «software» SF Comm I/F « software» Site Config Mgr • In SysML « software» Site RDBMS « software» Site Status Mgr allocation on « software» User I/F 2 « software» User Valid Mgr «hardware» ibd and bdd is : DVD-ROM Drive used to deploy allocatedFrom «data» Video File software/data

«hardware» to hardware « hardware» : User Console : Site Hard Disk allocatedFrom «data» Site Database

SysML Allocations Traceability Table

Introduction to SysML

Cross Cutting Concepts

SysML Package Diagram

The Package Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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 fully qualified name (package1::class1)

Package Diagram Organizing the Model

By Diagram Type By Hierarchy By IPT

Package Diagram - Views

• Model is organized in one hierarchy • Viewpoints can provide insight into the model using another principle – E.g., analysis view that spans multiple levels of hierarchy – Can specify diagram usages, constraints, and filtering rules – Consistent with IEEE 1471 definitions

The Parametric Diagram

Same Modified New for as UML from UML SysML

Diagram

Structure Requirements Behavior

Block Internal State Package Activity Definition Block Machine

Sequence Use Case

Parametric

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 Engineering Analysis with Design Models

Constraint Blocks

Defining reusable equations for Parametrics using constraint blocks on a block definition diagram

A constraint block is a block that packages the statement of a constraint so it may be applied in a reusable way to constrain properties of other blocks. A constraint block includes the definition of one or more parameters which can be bound to properties in a specific context where the constraint is used. In a containing block where the constraint is used, the constraint block is used to type a property that holds the usage. A constraint parameter is a property of a constraint block which may be bound to a property in a surrounding usage context. All properties of a constraint block define parameters of the constraint block, with the exception of constraint properties that hold internally nested usages of other constraint blocks. [SysML]

Parametric Diagram – Example 1 Vehicle Dynamics Analysis

Using the Equations in a Parametric Diagram to Constrain Value Properties

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

Parametric Diagram – Example 2 Direction Cosine Matrix

This diagram represents the conversion of Aircraft Heading (in Inertial Axes) into Aircraft Heading (in Body Axes) using a Direction Cosine Matrix. The stereotype «constraint» contains the Direction Cosine Matrix (DCM). «property» The underlying data- Aircraft.Inertial Heading : Vector types of each «constraintProperty» «property» are captured. In this Aircraft.Roll : Real example, «constraint» Aircraft.Inertial Heading «property» Direction Cosine Matrix is a Vector [x, y, z]. Aircraft.Pitch : Real The type Vector is «property» defined elsewhere in Aircraft.Yaw : Real the design (as part of the Data-Model). «property» Aircraft.Body Heading : Vector

Cross Connecting Model Elements - Summary 1. Structure 2. Behavior

ibdibd[[block] AntiAnti-LockControllerLockController satisfiessatisfies actPreventLockup [Swimlane Diagram] [[InternalInternal Block Block Diagram Diagram] «requirement»«requirement» AntiAnti--Lock «allocate» «allocate» PerformancePerformance act PreventLockup [Activity Diagram] :TractionDetector :BrakeModulator ibd [block] Anti-LockController [Internal Block Diagramd11:TractionDetector]

c1:modulator allocatedFrom c1:modulator «activity»DetectLosd 1:Traction te Interface a Interface OfOfTraction TractionDetector loc c1:modulator al interface DetectLossOf Modulate TractionLossTractionLoss:: Traction BrakingForce mm1:BrakeModulatormBrakeModulator1 :Brake allocatedFrom allocatedFromModulator «ObjectNode» «activity»Modulate TractionLoss:: BrakingForce value allocatedTo values «connector»c1 :modulatorInterface DutyCycle : Percentage binding satisfy par [constraintBlockconstraintBlock] StraightLineVehicleDynamicsStraightLineVehicleDynamics [Parametric Diagram]] reqreq [package] VehicleSpecifications [[RequirementsRequirements Diagram Diagram-- Braking Requirements] v.chassis .tire. v.brake.abs.m11.. v.brakebrake.rotor.. Friction:: DutyCycleDutyCycle: BrakingForceBrakingForce: v..WeightWeight::

par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] Vehicle System Braking Subsystem Specification Specification tftf: tl:: bf: mmc:

:BrakingForce f:f: :Accelleration «requirement» «requirement»«requirement» :BrakingForce :Accelleration Equation EquationEquation StoppingDistance Anti--LockPerformance F: [f = (tf*bfbf)*(1-tltl)])] [[F == ma] id=““102”” id=””337"" text==”The vehicle shall stop text =”Braking subsystem aa: from 60 mph within 150ftft shall prevent wheel lockup a: on a clean dry surface.” under all braking conditions .” v: VerifiedBy SatisfiedBy :DistanceEquationDistanceEquation :VelocityEquationVelocityEquation «interaction»MinimumStopp «block»Anti-LockController [v = dxdx/dt] vv: [a == dv/dt]] ingDistance «deriveReqt» xx::

«deriveReqt» vv.Position:: 3. Requirements verify 4. Parametrics

Four types of cross-connecting principles: 1. Allocation 2. Requirement satisfaction/derivation 3. Value Binding/Parametrics 4. Requirement Verification

Introduction to SysML

Cross Cutting Concepts Software Engineering Handover

From Systems to Software Engineering

• Why do systems engineers needs to understand some aspects of software 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)

Introduction to SysML

Cross Cutting Concepts Fundamentals of OO

What is an Object ?

• An Object…

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

– Has a coherent set of responsibilities

– Provides a set of services (operations) consistent with its responsibilities

– Has a unique identity

– Maintains information (attributes) about itself

– Interacts with other objects

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

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

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

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 where necessary, not as a fundamental principle of design. – Composition and Aggregation Hierarchies – Inheritance Hierarchies

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

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

One could define a hierarchy as ‘A partially-ordered structure of entities in which every entity but one is successor to at least one other entity; and every entity except the basic entities is a predecessor to at least one other entity’. This definition elaborates the basic problem with hierarchies, each entity within the hierarchy must be connected to at least one other (either as successor or predecessor) therefore to modify or remove one node in a hierarchy you also have to take into account its predecessors and successors as these may be affected. Object oriented techniques 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 impact of these changes are apparent in the links (or associations) the object has with others in the network.

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’ to perform 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 of describing the common characteristics of similar things.

Components, Objects and Classes

• A System is an artefact within which a collection of (reusable) ‘objects’ collaborate in a network to deliver the desired behavioural outputs. • Data and functionality are co-located within the ‘object’ (referred to as ‘encapsulation’, ‘modularization’ or ‘information hiding’) • ‘Objects’ are classified (or typed) into groups of things exhibiting similar 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 comes first, the Class or the Object?

In software engineering, they are both required at the same time.

We design a system using Objects…

… but we select the right Objects from their Class properties.

Introduction to SysML

Cross Cutting Concepts Software Development with UML

A Simple Application

Pressure sensor

Display Boards System controller Lot 1 Spaces & barrier motor Exit LotLot 1 2Spaces Full Traffic lights LotLot 2 3 Full Spaces Lot 3 Spaces Parking Lot Entry Serial Link Safety barrier

IR beam sensor

The parking lot controller controls car access to the parking lot by keeping a dynamic count of the number of cars currently in the parking lot. It compares this value with an operator specified value for 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 at the exit point. When a new car enters the parking lot the current car count is incremented. When a car 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, one red and one green (there is no amber light). The red light is illuminated until the entry beam sensor detects a car entering. The control system then checks for space. If there is space for the car, the red 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 car leaving. When the car entering has passed through the entry beam sensor the red light is illuminated 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, the parking lot capacity value. This unit consists of a 4 digit display, two function buttons (one to display current capacity value, the other to reset this value), and a numeric keypad. To set up or change the capacity the operator presses the display button, this activates the display and shows the current 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 the operator 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.

Software Requirements from System Requirements

req [Package] Reqts

«requirement» «requirement» REQ_1 REQ_1_SW1 txt «deriveReqt» txt The System shall prevent a car from The software shall input and store the entering if the parking lot is full. maximum capacity value for the parking lot.

«requirement» «deriveReqt» REQ_1_SW2

System txt The software shall maintain a count of cars Requirement currently in the parking lot.

«deriveReqt» «requirement» REQ_1_ SW3

txt Derived On detecting a car arriving, the software shall compare current count value against Software maximum capacity to determine whether Requirements the car should be allowed to enter.

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

Capturing the Software IO Context

Parking Lot System

«subsystem» : car breaks beam : car passes through Operator I/O Unit «interface device» Entry Beam Sensor : clear display «interface device» : car triggers sensor Display : display «interface device» : break Pressure Sensor : detect

: connect Car : key press «interface device» Keypad Operator «interface device» «subsystem» Red Light Control System : set red

: display press «interface device» Display Button «interface device» : raise Green Light : set green

: lower

: reset press «interface device» : set full «interface device» Reset Button Full Light : «interface device» Barrier Motor

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

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

Software Use Cases

• Software use cases are defined from, and trace to, systems use cases • They specify the services provided by software in the system

Use Parking Lot «extend» Car Car Waits

Set Capacity

Operator

This shows a simple use case diagram for the parking lot application, with the Description 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, typically defined in a SysML model.

System Interaction Diagrams Specify Required Use Case Behavior

Context Diagram ‘devices’ Use Parking Lot Description Car Barrier Motor Red Light Green Light Entry Beam Sensor Pressure Sensor Control System

entry beam detects car car breaks beam beam sensor signals controller break check for space If full suspend entry Car Waits EndIf

open barrier {3ms} raise turn off red light set red( off ) turn on green light set green( on ) car passes through beam car passes through beam sensor signals controller connect increment car count max. {50ms} close barrier lower turn off green light set green( off ) turn on red light set red( on ) car triggers pressure sensor car triggers sensor pressure sensor signals controller detect decrement car count

timing system architectural constraint boundary boundary

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

Initial Object Interaction for a Use Case

Description :Barrier Motor Red Green :Beam Sensor :Pressure Sensor :Controller :Car Count :Light :Light

entry beam detects car break beam sensor signals controller car_arrived controller checks for space isFull If full suspend entry Car Waits EndIf open barrier open turn off red light off turn on green light on car passes through beam connect beam sensor signals controller car_entered increment car count increment close barrier close turn off green light off turn on red light on car triggers pressure sensor detect pressure 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 illustrates the same use case, but this time as a sequence of software object interactions. The diagram could be used in the early stages of object definition and would contribute to the specification of the object model.

We now move into software design. A sequence diagram is produced for each use case, using candidate software objects. The purpose of these diagrams is to identify software objects and the operations they will need to support to deliver use 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 diagram which captured implicit hardware interactions specified for this same use case.

Example Class Diagram

Sensor Light Barrier Motor {Abstract} + on () +open () - status : short + off () 1 +close () + initialize () 1 1 theMotor + read () : short theRedLight theGreenLight

Pressure Sensor Beam Sensor 1 1 - threshold : float + initialize () 1 +initialize () Controller + read () : short +read () : short Notifies 1 1 1 theExitSensor theController + car_entered () theEntrySensor 1 + car_exited () Notifies theController + car_arrived () Operator I/O Unit 1

I/O Unit theCarCount - capacity : long 1 - num : short Car Count - newValue : long 1 + reset () 1 resets capacity 1 - capacity : long + activate () theCarCount - count : long = 0 + key (in number) + increment () + decrement () 1 theIOUnit + isFull () : boolean + set_capacity (in value : long) myDisplay displayButton resetButton + get_capacity () : long 1 myKeypad 1 1 1 + Car_Count () Display Keypad Button - ~Car_Count ()

+ display (in data) +read () : short

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

State Diagram Example

Controller Able to Admit Cars car_exited/theCarCount.decrement «Des troy»/

Idle Entry Suspended car_arrived/ [theCarCount.isFull]/

[e ls e ] /

«Create»/ Raising Barrier Entry/theMotor.open; theRedLight.off; car_exited/ theGreenLight. on; theCarCount.decrement car_entered/ theCarCount.increment; theMotor.close; theGreenLight.off; theRedLight.on;

«Des troy»/ Lowering Barrier after( 2000 )/

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

Model Concurrency

Display Pressure Entry Beam Button Sensor Sensor

break() display press() detect() connect()

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

Red Light

Event wait() DetectionTask set() Sensor Flags

decrement() increment() Admit Car Green Light release() Task set() isFull() Semaphore get() Car Count

get_capacity() reset_capacity() wait() Barrier Motor

Display Press Flag Reset Capacity Task This diagram represent an initial specification of the tasking model. It shows that three tasks have been identified and it defines how task intercommunication is to take place. It also shows which system devices are handled by which task. reset press() key press()

Reset Button Keypad Display

For multi-tasking processors a concurrency model can be developed that specifies the required tasks, their interaction and any mutual exclusion requirements. The production of the concurrency model may extend the object architecture model, especially the class model.

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

Updated Class Model

1 «CRconcurrent» Sensor Event Detection 1 {Abstract} Light Barrier Motor + main () - status : short ... + initialize () + on () + open () + read () : short + off () 1 + close () 1 theRedLight 1 theMotor theGreenLight

1 ExitDetector 1 1 1 EntryDetector Pressure Sensor Beam Sensor - threshold : float «CRconcurrent» Controller + initialize () + initialize () 1 + read () : short + read () : short + main () theExitSensor Notifies theController 1 1 1 + car_exited () theEntrySensor 1 + car_arrived () pRTOS Notifies theController + car_entered () Operator I/O Unit 1 1 «CRconcurrent» 2 cEvent _Flag I/O Unit Sensor Flags - flag : boolean - capacity : long 1 1 + Set () DisplayPressFlag - num : short 1 + Clear () 1 - newValue : long theCarCount + Check () : boolean Car Count + main () 1 resets capacity 1 + Wait () + activate () theCarCount - capacity : long + key (in number : short) 1 - count : long = 0 + reset () theIO + increment () ... + decrement () theIOUnit 11 + isFull () : boolean myDisplay + set_capacity(invalue:... 1 1 myKeypad + get_capacity () : long 1 resetButton 1 Display Keypad Button 1 Display + display (in data) + read () : short

As the software design becomes more detailed, implementation concerns start to appear in the class model. However these additions should not alter the fundamental (and traceable back to use cases) properties and relationships of the applications 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 classes and their restricted access via the active object classes that use them.

Evolve Class Model for Code Production

class Class1 ::Class1 { Attribute1 : Typedef1 public: Operation a () enum Typedef1 Operation b (in param : Typedef1) : long { Typedef1_enum1, 1 Typedef1_enum2 }; 1 theC2 ::Class2 // public operations Operation c () void Operation_a();

long Operation_b(const Typedef1 param);

private:

// private attributes

Typedef1 Attribute1;

// private roles

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

Traceability/Impact Analysis

Requirements Requirements Design Source Models Models Files

? … t if Satisfies Satisfies Satisfies ha W T T T e e e s s s t t t s s s W h y i s … ?

Acceptance System Integration tests tests and Unit tests

How it all fits together

Local Indication Panel

Nitrogen Compression Plant LIP Display stop/start HP Tank Valves buttons ACME RADAR Inlet Valve Outlet Valve By-pass Valve Vent Valve

system start/Start Up Plant [LPT and LOP alarms ringing] / : User Displays HPT Switch Outlet Valve Vent Valve By-pass Valve 3 wire RS232 Inlet Valve : Signal Processing : RADAR Controller Plant Controller

[els e] / : Display : Keypad serial i/f display board HP Switch power up/ Operator Starting Up System Compressor Unit Fail Safe Remote Monitoring Unit open() close() after( 180s )/ : Array Antenna power down/ LPT Switch alarm/ Handle Alarm Maintain Gas Pressure Compressor start() NCP System Remote : Antenna Controller : Array Orientation Motor system stop() Operator : Receiver : Electronic Orientation I/O board Compressor Unit stop() : Mechanical Orientation State4 Local Indication Panel : Power Supply after( 40s/ ) reset() system start() system bus Inlet GasPressure LP Switch CompressorMotor Low Oil Trip Switch alarm() : Elevation Actuator Pressure switch system stop() alarm/ Handle Alarm Compressor alarm() Shutting Down System Sensors : Transmitter : Tx Rx Duplex Local operator motherboard system stop/Shutdown Plant Compressor On alarm() : Azimuthal Actuator

250 bar() 150 bar() Coolant Flow Outlet Gas Meter Pressure Trip 250 bar/ reset() reset() Switch [ LOP alarm remote comms. Stop Compressor ringing] / HP Tank serial i/f

Remote Monitoring Unit

[ els e ]/ Take-off Valve HPT Switch HP S witch LP Switch LPT Switch

RS422 All I/O board connections are 24V DC single phase. Valve RMU Display Stop Button connectionsare in fact 2 single 1-way connections rather one 2-way 150 bar/ ... Start Compressor Composite Structure Interaction Overview Compressor Off Diagram (Modes) Diagram Context Diagram Hardware Architecture (Deployment) Diagram

TheSoftware Pilot DataEntryPanel :TheSoftware TheSoftware PilotPressesKey Pilot DataEntryPanel :TheSoftware KeyPress SoftwareDeterminesnewMode TheSoftware KeyPress(KEYID) Stores PilotPressesKey Pilot DataEntryPanel :TheSoftware NavigationData if NAVKeythen KeyPress SoftwareDeterminesnewMode Real World KeyPress(KEYID) Trips EnterNavigationModePilotPressesKey Alarm Monitoring if NAVKeythen KeyPress SetMode(NAV) Networks ( for Task (AMT) elsifWeaponsKey then Write() SoftwareDeterminesnewMode LIP and RMU) EnterNavigationMode KeyPress(KEYID) Deploys case SelectedStore is SetMode(NAV) elsif WeaponsKeyif NAVKey thenthen Weapon whenLoftBombs=> Set() Clear() EnterNavigationMode SetMode(LOFT) Check() Pilot caseSelectedStore is whenRetardBombs => SetMode(RETARD)SetMode(NAV) elsifwhenWeaponsKeyLoftBombsthen=> SetMode(LOFT) alarm status data whenGunscase =>SelectedStoreis SetMode(GUN) when RetardBombs=> SetMode(RETARD) whenRockets => Read() when LoftBombs=> SetMode(ROCKET) Read() Performs when Guns=> SetMode(GUN)SetMode(LOFT) Alarms Status endcase Sorte whenwhenRocketsRetardBombs=> => SetMode(RETARD) Alarm Inhibits /Enables Timer Task SetMode(ROCKET) endif when Guns=> Display and (TT) endcase SetMode(GUN) Communication Task (DCT) Read() Timer Requests endif when Rockets=> SetMode(ROCKET) Post()

endcase Set() Set() endif Start/Stop Requests Write() Read() Read() Requirements Clear() Use Case Model Write() Clear() Timeout Events Read() Plant Status Compressor Controller Task Scenario Model (CCT) Real World Devices «Equivalent» Pilot «Secondary Actor» «Create»/ Bombadier Commander «Destroy»/ runningdown stopped Communicator Strike Authority after(40s)/ Entry/monitor .inhibit(LOP); valve[vent]. open;... timer .set(40); Strike Authorised startcompressor/ motor. stop; valve [inlet].close; valve [outlet]. close; Authority [ !monitor. check(LOP)]/ valve [by-pass].open; ... monitor .activate (LOP) Select Weapon Type Concurrency (Communication) stopcompressor/ timer.cancel (30); [monitor .check(LOP)]/ timer.cancel (40); Select Target Destination Diagram Bombadier stopcompressor/ waitingforoilpressuretobuild Entry/monitor.inhibit(LOP); valve[vent].close; Navigate to Target timer.set (30); stopcompressor/ timer.set (40); ::Product ::Service timer.cancel(40); motor. start; ... Navigator ItemType{Exclusive} Test timeup/ ::WorkInstruction monitor .enable(LOP) Description StartDate 1 DescribesWorkOn 1..* ::RevenueItem Duration PerformanceRating Cost Scripts operating waitingforgaspressuretobuild after(10s)/ AgreePerformanceRating 1..* 1..* valve[by-pass].close; * valve[inlet].open ; Markets Purchases Activity Diagram valve[outlet]. open; ... Manages 1..* 1 Manufacturer 1 Worker Customer 1 ::Person 1..* WorksFor 1 ::Company Manager Name Employee Employer Name Age 1 Assign Un-Assign Specification «property» Dynamic Model 1 1 Supervisor Updates «generalRequirement» Design Aircraft.Inertial Heading : Vector 0..1 RequirementC Operational 1..* id = "Name" SystemElementA 1 ::Contract ::ContractualConstraint «satisfy» Performance ::DevelopmentPlan text = "The system shall..." Parameters 1 * priority = High * StartDate Description 1 MeanPerformance Salary Update «property» status = "Assigned" TrainingNeeds Updates Grade CurrentSkills Aircraft.Roll : Real ChangeGrade

«functionalRequirement» «performanceRequirement» ConstraintType{Inclusive} «pConstraint» Requirement A Requirement B Containers Scan Direction Cosine Matrix Loader Speed ::Term ::Condition «property» <> Success Aircraft.Pitch : Real «trace» Reason Derived Requirements «trace» * «functionalRequirement» «performanceRequirement» SystemElementB RequirementX RequirementY «satisfy» «property» Belt Speed Defective Aircraft.Yaw : Real Containers Accuracy Class Model Test Cases «verify»

«test Case» Test CaseA «property» Source Aircraft.Body Heading : Vector Files Requirements Diagram Constraints Diagram Parametric Diagram Slide 167 Copyright © 2006 ARTISAN Software Tools All Rights Reserved

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

•Use Case view – providing details of services provided by the system and which actors are involved with the service. •Interaction view – supported by both Scenario and Collaboration Diagrams which detail what entities 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 both the 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 requirements of the system and software. •Contextual view – providing details of user-system and system-software interfaces as well as an overall system context. •Hardware view – providing details of processing nodes, especially the details traditionally shared between hardware and software engineers e.g. hardware addresses.

Introduction to SysML

Summary and Wrap-up

Summary

• SysML sponsored by INCOSE/OMG with broad industry and vendor participation • SysML provides a general purpose modeling language to support specification, analysis, design and verification of complex systems – Subset of UML 2 with extensions – 4 Pillars of SysML include modeling of requirements, behavior, structure, and parametrics • 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-Wesley Object Technology Series) by James Rumbaugh, Ivar Jacobson, Grady Booch o Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) by Craig Larman o Writing Effective Use Cases by Alistair Cockburn o Applying Use Cases: A Practical Guide by Geri Schneider, Jason P. Winters, Ivar Jacobson o The Object-Oriented Thought Process by Matt Weisfeld, Bill McCarty o 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 thispicture. QuickTime™and a TIFF (Uncompressed) decompressor are needed to see thispicture.

Questions and Answers

How To Contact Us

If you would like to arrange a customized Webex or demonstration on how ARTiSAN products & services can enhance your organizational processes’ capability and maturation contact us at (703) 771-8008.

Speak with Mr. Phil Perri, Business Development Manager, North America

Introduction to SysML

Distiller Sample Problem

System Development Process

Stakeholder Manage Plan System Reqts Development

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

Integrated Product A recursive V process Development (IPD) is that can be applied to essential to improve multiple levels of the communications system hierarchy

There are many different process models in use by many organizations. The above outlines 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 SysML diagrams 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 does things 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 various model elements, irrespective of the order in which they are created. It will also reiterate the 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. Energy to Pure Dirty water condense Dirty water Steam water @ 20 deg C @ 100 deg C Condense steam Heat Dirty water Boil Dirty water and To 100 deg C and Drain Residue Residue Heat to Dirty Disposed water Heat to Boil residue water What are the real requirements? How do we design the system?

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

Distiller Types

Batch Distiller

Continuous Distiller

Distiller Problem – Package Diagram: Model Structure and Libraries

bdd [Package] Value Types1 p k g [Model] Distiller Model 6.1h1 [Model Overview]

Distiller Requirements Distiller Use Cases

«ValueType» «ValueType» Real Power

Distiller Behaviour Distiller Structure

«ValueType» «ValueType» «ValueType» «ValueType» temp press massFlowRate dQ/dt dimension dimension dimension dimension ThermodynamicTemperature Pressure Mass Flow Rate Heat Flow Rate V alue T yp e s Ite m T yp e s unit unit unit unit DegreeCelsius N/M^2 gm/sec cal/sec

«ValueType» «ValueType» «ValueType» efficiency specificHeat latentHeat

dimension dimension Specific Heat Latent Heat unit unit «Unit» cal/(gm*DegreeCelcius) cal/gram N/M^2

«Unit» «Unit» «Dimension» «Dimension» gm/sec cal/(gm*DegreeCelcius) Mass Flow Rate Specific Heat

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

Distiller Example Requirements Diagram

req [Package] Distiller Requirements 1

Source

«requirement» Original Statement

id# S0.0 txt 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 litre, density 1 gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporisation 540 cal/gm.

«requirement» «requirement» HeatExchanger «requirement» PurifyWater Water Properties id# id# S2.0 id# S1.0 txt S5.0 txt Heat dirty water and condense txt steam are performed by a Counter The System shall purify dirty water. The water has properties: vol = 1 litre, density 1 Flow Heat Exchanger. gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporisation 540 cal/gm. «requirement» Boiler

The requirement id# «requirement» for a boiling S3.0 WaterInitialTemp function and a txt boiler implies id# Boil dirty water is performed by a Boiler. that the water S5.1 must be purified txt by distillation. Water has an initial temp of 20 «requirement» degrees C. Drain

id# «deriveReqt» S4.0 txt Drain residue is performed by a Drain.

«requirement» Distill Water

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

Distiller Example: Requirements Tables

id name text S0.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 are more compact and more scaleable.

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

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

recovered : Heat coldDirty : H2O a1 : Heat Water [Liquid] Control hotDirty : H20 (Sequence) [Liquid] external : Heat a2 : Boil Water

Things that flow (Object Nodes) steam : H2O hiPress : Residue [G as ]

Activity loPress : Residue (Function) a4 : Drain Residue a3 : Condense Steam

pure : H2O Batch [Liquid] Distiller

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

Distiller Example – Block Definition Diagram: Distillerbehavior

bdd [package] DistillerBehavior [Distiller Behaviour Breakdown] 1 1 «Activity» Distill Water 1

Need to a1 : Heat Water 1 1 a2 : Boil Water consider «Activity» «Activity» Heat Water Boil Water phases

of H20 Activities (Functions) a3 : Condense Steam a4 : Drain Residue 1 1 pure : H2O coldDirty : H2O 1 1 «Activity» 1 «Activity» Condense Steam Drain Residue «Block» Item Types::H2O

«BlockProperty» cal/gm : specificHeat 1 1 «BlockProperty» cal/(gm*deg C) : latentHeat Remove Latent Heat of Vaporisation () Add Latent Heat of Vaporisation () 1 recovered : Heat 1 hiPress : Residue 1 1 external : Heat «Block» «Block» hotDirty : H20 steam : H2O Item Types::Heat Item Types::Residue 1 1 loPress : Residue values values cal/sec : dQ/dt degrees C : temp gm/sec : massFlowRate kg/gm^2 : press Control (not shown on BDD) Things that flow (ObjectNodes)

This block definition diagram defines all the elements used in the activity diagram. This allows some elaboration of properties of the water that flows through the system. This shows the need to consider the water in both liquid and gaseous phase… the next diagram will formalize these phases in a finite state machine.

Distiller Example – State Machine Diagram: States of H2O

stm [Block] H2O1

Gas

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

Transitions Liquid

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

Solid

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

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

act [activity] Distill Water [Continuous Parallel Behavior]

coldDirty : H2O recovered : Heat hiPress : Residue [Liquid] loPress : Residue

a1 : Heat Water a3 : Condense Steam a4 : Drain Residue

hotDirty : H20 steam : H2O [Liquid] [G as]

external : Heat a2 : Boil Water pure : H2O [Liquid]

Continuous Distiller

It makes sense for the distiller design to allow a continuous flow of water through the system, rather than only discrete increments of water. The previous activity diagram (EFFBD) has been recast to support continuous flow. Dirty H2O and Heat 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]

«continuous» «continuous» recovered : Heat hiPress : Residue coldDirty : H2O «continuous» [Liquid] loPress : Residue

a1 : Heat Water a3 : Condense Steam a4 : Drain Residue

«continuous» «continuous» steam : H2O hotDirty : H20 [G a s ] [Liquid ]

a2 : Boil Water «continuous» «continuous» ShutDown pure : H2O external : Heat [Liquid ]

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

Distiller Example – Block Definition Diagram: DistillerStructure

bdd [Package] Distiller Structure [Structural Breakdown]

«Block» «Block» «Block» Distiller Item Types::Fluid Item Types::Heat

operations values values TurnOn () degrees C : temp cal/sec : dQ/dt TurnOff () gm/sec : massFlowRate kg/gm^2 : press

hx1 bx1 drain «Block» «Block» «Block» Heat Exchanger Boiler Valve

satisfies satisfies satisfies «requirement» HeatExchanger «requirement» Boiler «requirement» Drain

Generic Things Usage (Part) Names Generic Subsystems That Flow (Blocks) (Roles) (Blocks)

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

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

Parts (Roles)

act[activity] DistillWater[SimultaneousBehaviorwithAllocations] «allocate» «allocate» «allocate» hx1 bx1 drain : Heat Exchanger : B oiler :V alve

«continuous» «continuous» «continuous» hiPress : Residue «continuous» loPress : Residue coldDirty : H2O recovered : Heat steam : H2O [ Liquid] [ G as ]

a4 : Drain Residue «streaming» «streaming» a1 : Heat Water a3 : Condense Steam

«continuous» hotDirty : H20 [ Liquid]

«continuous» «streaming» «continuous» external : Heat a2 : Boil Water pure : H2O [Liquid ] ShutDown

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

Distiller Example – Internal Block Diagram: Distiller Initial Design

ibd [Block] Distiller [Initial with Item Flows]

«Block» Distiller DSClean_Out : H2O

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

DSResidue_Out : Residue

HEClean_Out : H2O HEHotDirty_Out : H2O BLHotDirty_In : H2O BLSteam_Out2 : Residue Fluid_In : Fluid Fluid_Out : Fluid

BLExcess : H2O «BlockProperty» «BlockProperty» «BlockProperty» hx1 : Heat Exchanger bx1 : Boiler drain : Valve

HEDirtyIn : H2O HESteam_In : H2O BLSteam_Out : H2O BLPower_In : Power DSDirty_Out : H2O

«ItemFlow» «ItemFlow» : H2O : H2O

DSExcess DSPower_In : Power «ItemFlow» «ItemFlow» : Power : H2O

Parts Things That Flow Connectors (Blocks used In Context in context) Flow Ports (ItemFlows)

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

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

Distiller Example –Internal Block Diagram: Distiller with Allocation

ibd [Block] Distiller [with Allocation]

«Block» allocatedFrom allocatedFrom Distiller hotDirty : H20 pure : H2O

m2 : H2O m4 : H2O

s1 : Residue «BlockProperty» hx1 : Heat Exchanger «BlockProperty» «BlockProperty» bx1 : Boiler drain : Valve s2 : Residue allocatedFrom a3 : Condense Steam allocatedFrom allocatedFrom a1 : Heat Water a2 : Boil Water a4 : Drain Residue

ItemFlow1 : H2O

m1 : H2O m3 : H2O allocatedFrom allocatedFrom steam : H2O allocatedFrom hiPress : Residue loPress : Residue

Q1 : Power allocatedFrom coldDirty : H2O allocatedFrom external : Heat

Allocation Compartment Allocation Callout (references Activities) (references Object Nodes)

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

Distiller Example – Parametric Diagram: Heat Balance Equations

Parts or ItemFlows

Value Properties

Value Constraints Constraint Bindings callouts

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

Distiller Example – Heat Balance Results

table IsobaricHeatBalance1 [Results of Isobaric Heat Balance] Satisfies «requirement» specific heat cal/gm-°C 1 WaterSpecificHeat • Not a SysML latent heat cal/cm 540 Satisfies «requirement» WaterHeatOfVaporization diagram t t

u • Constructed from u o n o i _ t _ _ r r

u SysML diagram m n e e i t t a o _ e _ a a Satisfies «requirement» r t r information w w s e e t t WaterInitialTemp _ _ _ a a x x x w h b b w mass flow rate gm/sec 6.75 6.75 1 1 1 • Can be held in temp °C 20 100 100 100 100 Studio a a text dQ/dt cooling water cal/sec 540 diagram dQ/dt steam-condensate cal/sec 540 Note: Cooling water condenser efficency 1 needs to have 6x flow of steam! heat deficit 0 Need bypass between hx_water_out and dQ/dt condensate-steam cal/sec 540 bx_water_in! boiler efficiency 1 dQ/dt in boiler cal/sec 540

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

Distiller Example – Activity Diagram: Updated DistillWater

act [activity]Distill Water [Updated Simultaneous Behavior with Allocations] «allocate» «allocate» «allocate» «allocate» hx1 feed bx1 drain : Heat Exchanger :V alve :B oiler :V alve

«continuous» «continuous» coldDirty : H2O recovered : Heat steam : H2O «continuous» [ Liquid] a4 : Drain Residue [G a s ] loPress : Residue

«streaming» «streaming» a1 : Heat Water a3 : Condense Steam «continuous» pure : H2O [ Liquid] «continuous» «streaming» «continuous» hotDirty : H20 a2 : Boil Water hiPress : Residue [ Liquid]

«continuous» «continuous» hotDirty1 : H2O [ Liquid] external : Heat ShutDown a5 : Divert Feed «continuous» hotDirty2 : H20 [ Liquid]

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 now an additional output. hotDirty = hotDirty1+hotDirty2.

Distiller Example – Internal Block Diagram: Updated Distiller

ibd [Block] Distiller [with Allocation - Updated]

«Block» Distiller

added as a result of parametric analysis

m4 : H2O

m1 : H2O s2 : Residue m3 : H2O s1 : Residue «BlockProperty» «BlockProperty» hx1 : Heat Exchanger «BlockProperty» «BlockProperty» feed : Valve bx1 : Boiler drain : Valve allocatedFrom allocatedFrom a3 : Condense Steam allocatedFrom allocatedFrom a1 : Heat Water a5 : Divert Feed a2 : Boil Water a4 : Drain Residue m2-1 : H2O m2-1 : H2O

Q1 : Power m2-2 : H2O

allocatedFrom allocatedFrom allocatedFrom hotDirty1 : H2O hotDirty1 : H2O hotDirty2 : H20

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

Distiller Example – Use Case and Sequence Diagrams

ucd Distiller Use Cases

User Operate Distiller

seq Operate Distiller [high level]

Description User «Block» «BlockProperty» :Distiller Distiller.ui1:Control Panel

press start StartUp turn on Distiller TurnOn distill water ref Distill Water [detail]

press stop ShutDown turn off Distiller TurnOff

Distiller Example – Internal Block Diagram: Distiller Controller

ibd [Block] Distiller [with Controller]

«Block» Distiller m1 : H2O m2-2 : H2O

m2-1 : H2O m2-1 : H2O s1 : Residue

«BlockProperty» «BlockProperty» «BlockProperty» «BlockProperty» s2 : Residue hx1 : Heat Exchanger feed : Valve bx1 : Boiler drain : Valve

blrSig

m3 : H2O IValve IValve

m4 : H2O p1 : Power b1 : Power IValve blrSig

«BlockProperty» «BlockProperty» IPower IPower ui1 : Control Panel cx1 : Controller IValve

ILamp ILamp

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

Distiller Example – State Machine Diagram: Distiller Controller

stm [block] Distiller Controller [Distiller States] Cooling Off Entry/bxHtrOFF; Draining [bxTemp < 100degrees]/ Open Drain : IValve; [bxLevelBelow]/ Off Entry/Open Drain : IValve Open Fill : IValve Entry/pwrLightOFF s hutDown/ pw rO n/ Distilling Filling Entry/bxHtrON Controlling Boiler Level Entry/Open Feed : IValve [NOT bxLevelLow]/ [bxLevelHigh]/

Level Low Level OK Level High [NOT bxLevelLow]/ Entry/Open Drain : IValve Entry/Open Feed : IValve Entry/Close Drain : IValve; Close Fill : IValve [bxLevelLow]/ [NOT bxLevelHigh]/

Warming Up Controlling Boiler Residue Entry/bxHtrON

/ ResidueTimer/ [bxTemp = 100degrees]/ Building Up Residue Purging Residue Entry/Close Drain : IValve Entry/Open Drain : IValve DrainTimer/

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

Distiller Problem – Process Used

Systems Modeling Activities - OOSEM

Analyze Needs Major SE Development Activities

•Mission use cases/scenarios •Enterprise model Define System Requirements

•System use cases/scenarios •Elaborated context •Req’ts diagram Define Logical Optimize & Architecture Evaluate Alternatives •Logical architecture

Synthesize •Engr Analysis Models Physical •Trade studies Validate & Architecture Verify System •Node diagram •HW, SW, Data architecture •Test cases/procedures Common Subactivities

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 Improvement To Transition to SysML

Integrated Tool Environment

Project Management s i s i s s y l y t SoS / DoDAF / Business Process modeling l a t n a n n e n e A n A m

o m e e i g e c t g n g n a a i a a d r n i l e n a m a e a

r System modeling M n V o M i f s

SysML g t r & a

t e n n n a E e P

o D i g y m t t t l e n a c i r a M c i r i u i D u e f c d / i e

q Software modeling Hardware modeling r e o e n M r e p i

C P R UML 2 VHDL, CAD, .. V S g n E