00 T2 Moreland

Introduction to SysML
An Introduction to the OMG Systems Modeling Language (OMG SysML)

Clarence C. Moreland Principal Consultant, ARTiSAN Software Tools
Some slides Copyright 2006 by Object Management Group. Published and used by INCOSE and affiliated societies with permission.
Slide 1
Copyright 2006 ARTISAN Software Tools All Rights Reserved
2008, 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/
Slide 2
Copyright 2006ARTISAN Software Tools All Rights Reserved
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
Slide 3
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

Slide 4
SE Practices for Describing Systems

Past
Specifications Interface requirements System design Analysis & Trade-off Test plans
Future
Moving from Document centric to Model centric

Slide 5
System Modeling
Requirements
Integrated System Model Must Address Multiple Aspects of a System Syste m

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

Slide 8
C opyright 2006ARTISAN Software Tools All Rights Reserved
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
Slide 9
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

Slide 10
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
10
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
Slide 11
11
Diagram Overview
Slide 12
C opyright 2006 ARTISAN Software Tools All Rights Reserved
12
Reuse of UML 2.0 for SysML
UML 2.0 SysML

UML not required by SysML UML reused by SysML SysML Extensions
This workshop deals with the full set of SysML diagrams, both the inherited UML diagrams and the additional ones.
Slide 13
13
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
Slide 14
14
Stereotypes
Defining the Stereotype
Applying the Stereotype
Slide 15
15
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
Slide 16
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.
16
Applying a Profile and Importing a Model Library
Slide 17
17
SysML Taxonomy of Diagrams

Same as UML Modified from UML New for SysML Diagram
Structure
Requirements
Behavior
Block Definition [1]
Internal Block [2]
Package
Activity
State Machine Sequence Use Case
Parametric
[1] Modified UML Class Diagram [2] Enhanced UML Composite Structure Diagram
Slide 18
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]
18
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.
Slide 19
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.
19
The Four Pillars of SysML (ABS Example)

1. Structure
bdd [Package] Vehicle [ABS] Block Library:: Electronic Processor Block Anti-Lock Controller
ibd [Block] Anti-Lock Controller1 Block Anti-Lock Controller
2. Behavior
interaction
stm Tire [Traction]
act PreventLockup
Block Library:: Electro-Hydraulic Valve c1:modulator interface m1 Block Brake Modulator
BlockProperty d1 : Traction Detector
state machine
Los s O fTrac tion/
Gripping
BlockProperty m1 : Brake Modulator
activity/ function Slipping
d1 Block Traction Detector
Detect Loss Of Traction
Modulate RegainTrac tion/ TractionLoss B raking Force
definition
par [constraint] StraightLineVehicleDynamics [Parametric Diagram]
{f = (tf*bf)*(1-tl)} {F = ma}
use
: BrakingForceEquation tf tl bf f F
: AccelerationEquation c
req [Package] Vehicle Specifications [Braking] Vehicle System Specification requirement Stopping Distance id# 102 txt The vehicle shall stop from 60 mph within 150ft on a clean dry surface.
3. Requirements
Braking Subsystem Specification requirement Anti-Lock Performance id# 337 txt The Braking subsystem shall prevent wheel lockup under all braking conditions.
4. Parametrics
: DistanceEquation x v v a
{v = dx/dt} {a = dv/dt}
: VelocityEquation
deriveReqt
Slide 20
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
20
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
Header
diagram usage
Version: Description: Completion status: Reference: (User-defined fields)
diagramKind [modelElementType] modelElementName [diagramName]
Contents
Slide 21
21
Requirements
Slide 22
22
The Requirements Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 23
The Requirements diagram sits out side the Structure/behavior organization of the remaining SysML diagram types.
23
What are Requirements?

Statement of a customers 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.
Slide 24
24
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
Slide 25
How the requirements diagram is used will vary depending on the industry, company, project, and process. Its main strength is in its ability to graphically represent requirements and how they pertain to the rest of the UML model.
25
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: Text: A unique identifier for the Requirement 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 requirement Test method REQ_A1 Status txt Etc.
The System shall do... reqtType function
Slide 26
26
SysML Requirements Diagram Elements

req Requirement Diagram 1 requirement REQ_A1 txt The System shall do... reqtType function rationale explanation
problem description of problem
Model Element T trace
Requirement
requirement derivedFrom REQ_A1.1 requirement REQ_A1.1
Containment
requirement REQ_A1.2 deriveReqt requirement REQ_B1 testCase Model Element B Model Element A refine
Callout
requirement REQ_D txt same text copy
verify
Design Elements requirement REQ_C Model Element C satisfy
Slide 27
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.
27
SysML Requirements Diagram Example

req [package] UserRequirements Customer Brochure UseCase Distill Water refine
trace requirement Produce Distilled Water txt Distill dirty water into pure water
rationale
30 is deemed a safe output temperature
requirement Condenser Efficiency deriveReqt txt The condenser needs to cool the pure water to 30 C requirement Handle Overflow txt The system must have an overflow valve in the main heating vessel requirement Provide Input Protection txt The system shall have an input valve that is closed when the system is off
requirement Water Output txt The pure water output must be at a safe temperature requirement Water Input txt The system must be able to connect directly to mains water deriveReqt deriveReqt
rationale
High pressure w ater may overpow er the boiler so an overflow valve is needed
rationale
requirement Water Throughput txt The system shall handle 1 litre of water per minute
Direct connection to high pressure mains w hen the system is off might cause damage
satisfy
activity Distill Water
rationale
Analysis of this activity show s that the throughput is possible
Slide 28
28
Problem and Rationale
Problem and Rationale can be attached to any Model Element to Capture Issues and Decisions
Slide 29
29
An Automotive Example
The Business Process The Business Case Marketing have identified a niche inThe the market for a mid-range engine, high-specification vehicle Business Case (Named: XSV-2001). The eventual cost of the vehicle will be in the range of 16K-20K, with a proposed launch date of Spring 2003. Finance have made 300K available for Conception and Development Will (including specify any re-tooling the 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 wil l be held in 4- months to May include (solution-based) capabilities ofTarget the System (e.g. Cruise determine go- ahead of Development (and subsequent) phases. market: Executive Fleet and Family. Control, EMS, ABS) Feature- Set
May include 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 C ontrol 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;
Slide 30
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.
30
SysML Structure
Slide 31
31
Block Diagrams
Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 32
32
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
Slide 33
33
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
Slide 34
34
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

Slide 35
35
Block Definition Diagram (bdd) Notation

bdd [Package] Block Defintion Diagram [bdd- Notation]
Generalization Compartments
ValueType ValueType1 dimension Dimension1 unit Unit1
Block ::Block1
Block ::Block1::Block3
Namespace containment
Block Block2 parts myPart : Block4 refParts : Block6 [*] sharedPart : Block5 [0..1] references refParts : Block6 [*] values aValue : ValueType1 1 refParts * Block Block6
Reference association Shared association

1 1 Block Block5 Actor1
Part association
Part (role) names
1 0..1 sharedPart
1 myPart Block Block4
Multiplicity
Slide 36
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.
36
Internal Block Diagram (ibd) Notation

ibd [Block] Block2 [ibd Notation] Block Block2
Enclosing Block
fPort1 BlockProperty myPart : Block4
Part
fPort2 ItemFlow ItemFlow1 : ItemType fPort3 0..1 BlockProperty sharedPart : Block5 pI/F sPort
Item Flow
ItemFlow ItemFlow2 : ValueType1
Reference Property
(in, (in, but but not not of) of)
fPort4 * BlockProperty refParts : Block6
Port
ItemFlow ItemFlow3 : DataType2
rI/F
Internal Block Diagram Specifies Interconnection of Parts

Slide 37
Connector
Actor1
Note the consistency between this ibd and the previous bdd (part names, types and multiplicities).
37
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
Slide 38
38
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
Slide 39
39
Port Notation
Interface1 Interface1
BlockProperty part1
sp1
sp2
BlockProperty part2
Standard Port
BlockProperty part1
fp1 : ItemType1
fp2 : ItemType1
BlockProperty part2
Atomic Flow Port
fp3 : FlowSpec1 BlockProperty part1
fp4 : FlowSpec1 BlockProperty part2
Non-atomic Flow Port

Slide 40
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.
40
Unit and Item Types

bdd Units
bdd [package] Items block Heat values Q:J block Electricity values p:W block Fluid
Unit types normally based on Real SI Units and Dimensions defined in SysML appendix
valueType kg dimension = mass unit = kilogram valueType J unit = Joules valueType kg/m dimension = pressure unit = kilograms/square meter valueType kg/s unit = kilograms/second valueType C dimension = temperature unit = degrees Centigrade
block H2O values lh : J/kg = 520 m : kg = 0 press : Pa sh : J/kg/C = 1 t : C
values lh : J/kg = 520 press : Pa sh : J/kg/C = 1 t : C
block Residue values lh : J/kg = 520 press : Pa sh : J/kg/C = 1 t : C
Slide 41
41
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
Flow Specification
valueType C flowSpecification Digital flowPropertyList in Value : V Interface Set Throttle Set Throttle () block Liquid values MassFlowRate : gm/sec Press : kg/m Temp : C Temp valueType kg/m Press valueType gm/sec
flowSpecification FPump-ICE flowPropertyList in FuelSupply : Fuel out FuelReturn : Fuel Send ()
Interface EMU Msg
MassFlowRate
Interface TransmIF Gear ()
block Fuel values MassFlowRate : gm/sec Press : kg/m Temp : C
valueType SysML Extras::SI Unit Types::A
flowSpecification TorqueSpec flowPropertyList in TorqueIn : Torque out TorqueOut : Torque
valueType Analogue
Interface Block Value Type
Slide 42
42
Delegation Through Ports

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

Flow Ports type specifies what can flow in/out
FlowSpecification FlowSpec1 flowPropertyList in FlowProperty1 : Block3 out FlowProperty2 : DataType1 inout FlowProperty3 : ValueType2
BlockProperty Part 1 : Block B
fp1 : FlowSpec1
fp2 : FlowSpec1
BlockProperty Part 2 : Block C
ItemFlow ItemFlow1 : DataType1
Item Flow Specifies what does flow (in context)

Slide 44
Connector
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.
44
Structure vs. Usage

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

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

PureWater
block Distiller
ibd [block] Distiller

waterOut : H2O
pFOut dirtyWater waterIn : H2O
: FlowValve op cnt
inValve ip
fIn : Fluid
hx : HeatExchanger HEC
hxWaterOut : H2O
BC blSludgeOut : Residue loPressResidue
tempWrn
blSteamOut : H2O blWrn
SOut
IValve IValve
bl : Boiler IPower
UserIO User cnt
IValve IPower vI
wrn ui
IValve
vO blrPwr vD pwrIn PowerIn : Electricity extPower
Excess : H2O excess overFlow
UI : FrontPanel ILamp ILamp
RegPower : Electricity
Ocnt
PwrIn
controller : Controller
Rcnt IValve IValve
problem
Overflow water is very hot!
Non-Atomic Flow Ports (BC and HEC)

I/O is specified using FlowSpecification FlowSpecification consists of properties stereotyped FlowProperty isConjugate promotes reuse of flowSpecifications
Atomic FlowPorts (dirtyWater, extPower )

In this case the port is directly typed by the item type (Block or ValueType) Direction property specifies the direction of flow
Slide 47
47
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 HVSludge : Residue BlockProperty tank : Heating Vessel HVExcess : H2O BlockProperty vResidue : Valve BLSteam_Out2 : Residue Fluid_Out : Fluid
HVHotDirty_In : H2O
HVHeat_In : Heat BlockProperty vOverFlow : Valve
BLExcess : H2O Fluid_Out : Fluid
BLHotDirty_In : H2O
ELHeat_Out : Heat BlockProperty heater : Element
Fluid_In : Fluid
ELPower_In : Power BLPower_In : Power
Shows parts (structural children) and ports (interaction points on block and parts) Supports consistency of layers
Slide 48
The ports on the (enclosing) Boiler block can be automatically populated on this diagram from the information on the previous diagram.
48
Use Cases
Slide 49
49
SysML Use Case Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 50
The Use Case diagram in SysML is used to capture aspects of behavior.
50
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
Slide 51
51
Use Case Diagram

uc Diagram Name Subject Name
Weather Monitoring Flight Crew
Actor Actor Generalisation
Subject Boundary
Air-To-Ground Strike Pilot
Use Case
Air-To-Air Tracking Navigator
Slide 52
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.
52
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.
Slide 53
53
What is an Actor?
Expected Actors
A Person
Unexpected Actors
Unauthorized Users
An External System
Threats
Abstract such as Time

Slide 54
Adverse Environmental 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
54
What is a Use Case?
Defines how the actors interact with the system

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

Local operator
Monitor System
Functionality in which an actor participates (Secondary Actors)
Fuel Transaction Customer Kiosk Operator
Slide 55
55
Actor Characteristics
Primary actor
Main beneficiary of use case Normally initiates use case
Secondary actor
Has interaction responsibilities, but does not initiate Actors represent roles operator, supervisor, Generalization of actors indicates inheritance of use case interactions
Supervisor
Slide 56
Primary Operator
Start Local System Secondary Event Log System
Run 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 welldefined manner in order for the primary actors goal to be realized by the system. These are referred to as secondary actors. Stereotypes can be used to indicate primary or secondary actors. An actor represents a role played by a user of the system. This is particularly relevant where the actor is human; the same person may be capable of 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.
56
Use Case descriptions specify details

Automated Teller Machine
Withdraw Cash
Use UseCase: Case:Withdraw WithdrawCash Cash

Customer
Deposit Funds the code
Other Attributes
Pre-conditions Post-conditions (Guarantees) Constraints Intent Alternate courses Stakeholders Priority Complexity
When inserts Whenaacustomer customer insertsaacard, card,the themachine machinereads reads Transfer Funds the codefrom fromthe thecard cardand andchecks checksififititis isan an acceptable acceptablecard. card.IfIfso soititasks asksthe thecustomer customerfor foraaPIN PIN code code(4 (4digits). digits).IfIfnot, not,the thecard cardis isejected. ejected. When Whenthe thePIN PINcode codeis isreceived receivedthe themachine machinechecks checks whether the PIN code is correct for the whether the PIN code is correct for thespecific specific card. card. IfIfso, so,the themachine machineasks asksfor forwhat whattransaction transaction the thecustomer customerwishes wishesto toperform. perform. When Whenthe thecustomer customerselects selectscash cashwithdrawal withdrawalthe the machine machineasks asksfor forthe theamount. amount. Only Onlymultiples multiplesof of$20 $20 are allowed. ... are allowed. ...
Slide 57
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.
57
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
Slide 58
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.
58
include relationship extracts common courses of action

Card Validation
include Transfer Funds include
include Deposit Funds Withdraw Funds
Common behavior may be extracted from other use cases Defines a must be done relationship Simplifies change
Slide 59
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.
59
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 Defines a may get done relationship
Bank Card Transaction
extend Reject Invalid Card
Slide 60
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.
60
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
Slide 61
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.
61
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. Use UseCases Casesdefine definetestable testablesystem systemrequirements requirementsfrom from an external perspective an external perspective
Slide 62
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;
62
Typical Use Cases
Start Compressor include
Start Up Plant
include extend Maintain Gas Pressure
extend extend Local operator Handle Alarm
Ammonia System include
include
Shutdown Plant
include
Stop Compressor
Remote Operator
Slide 63
63
Systems Engineering Use Cases
Safety Engineer
System Installer
Safety Inspection
Install System
Maintain Gas Pressure
Run Site Acceptance Tests Start Up Plant
Ammonia System
Local operator Monitor System Shutdown Plant include
include
Alarm Verification Tests
Power Off
Calibrate Sensors Maintainer
Remote Operator
Power On
Power Fail
Replace System Components
Slide 64
Power Copyright 2006ARTISAN Software Tools All Rights Reserved
64
Use Case Organisation
Multiple-Levels of Use Cases Use Case Diagrams can be organised around different levels of abstraction from the System of Systems perspective all the way to Use Cases supported by a specific Sub-System. Organisation by Domain The lowest level of abstraction (i.e. the Sub-System level) encapsulates all the services (Use Cases) provided by a specific domain.
Power Up Warm
include
Continuous Built-In Test
Power Up Cold Primary Actor include Power include Power Up Power Up Built-In Test
Primary Ac tor Time
See Store Information Use Case Diagram
include Primary Actor Pilot Shutdown include Information include Execute Mission Store
include
Communicate Load Mission Sec ondary Actor Mission Plan
System of Systems
See Ex ecute Mission Use Case Diagram
Secondary Actor Commander
Primary Ac tor Navigator
Primary Actor Equivalent Bombadier
Store Information Primary Actor Equivalent Bombadier Navigator Primary Actor Pilot Primary Actor
Store Weapons Store Present Information Store Markpoint Store Navigation Information Store Target Destination Store Selected Weapon Type HUD Mark
Bombadier Use Cases
Position
System
RADAR Fix Store Fix Error HUD Fix
On-Top Mark
RADAR Mark
Any number of Use Case Diagrams can be created to keep the diagrams tidy. This diagram shows how different
On-Top Fix
types of information can be stored within the system and by whom. Navigator Use Cases
Deploy Weapon include
Pilot
include
Store Target Destination
Store Selected Weapon Type
include
SubSystem
Store Geodetic Point
Slide 65
65
Activity Diagrams
Slide 66
66
SysML Taxonomy of Diagrams

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 67
67
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.
Slide 68
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.
68
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
Slide 69
Although SysML adopts much of the UML activity model, in this section well consider SysML activity modeling as a whole, not distinguishing between which aspects are inherited and which are extensions.
69
Activities
Represent a unit of behavior
Specifies sequencing of subordinate actions Can be parameterized activity
act name
parameter decision
initial node action activity final

Slide 70
An activity is the specification of parameterized behavior as the coordinated sequencing of subordinate units whose individual elements are actions. [UML]
70
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 activity Activity 1
act [activity] Activity 1
action name
1 1 a2
1 1 a3
a2 : A ctivity 2
a3 : Activity 3
activity Activity 2
activity Activity 3
Definition
Slide 71
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.
71
Action Node
Represents a single step within an activity
not further decomposed execution starts on entry to the action node and exit occurs when the execution is completed
action name
Callbehavior is a variant
an action node showing a behavior invocation typically a part activity (activity name may be hidden) can be linked to a Block operation
Slide 72
action name : behavior name
These are one of the principle components of activity diagrams. Each action node defines a single step within the owning activity. Because activity diagrams can be used in a variety of situations, the wording of the text can be whatever is best suited to the specific situation. In general, actions are atomic (i.e. not further decomposed). Where the action represents a complete sub-activity, typically a part activity on a bdd, a Callbehavior action is used. This normally has both the bdd role name and the part activity name displayed, although the latter can be hidden. Activities can be linked with Block operations these operations are then the mechanism through which the activity is invoked.
72
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
act [activity] Activity 1 DataType dt1 : DataType1
bdd Activity Breakdown - with objects activity Activity 1 1
1 1 a2 activity Activity 2
1 1 a3 activity Activity 3
a2 : A ctivity 2
a3 : A ctivity 3
0..1 b1 Block ::Block1
0..1
dt1
DataType DataType1
Block b1 : B loc k1
object node name

Slide 73
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.
73
Control and Object Flows (Activity Edge)

Control flow
A c tion 1
Object Object flow Object flow
Control flow
A c 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
Slide 74
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.
74
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 name & type)
ObjectNode
Slide 75
75
Slide 75 AJM4 right-hand diagram should have action:activity like the left-hand one.
Alan Moore, 5/17/2006
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
Slide 76
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.
76
Interruptible Activity Region

A bounded region of activity that can be terminated prior to completion
region boundary
interrupting event interrupting edge
Slide 77
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.
77
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
Slide 78
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.
78
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.
Slide 79
79
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
Slide 80
80
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.
Slide 81
81
Explicit Allocation of Behavior to Structure Using Swimlanes
Activity Diagram (without Swimlanes)
Activity Diagram (with Swimlanes)
Slide 82
82
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
Slide 83
These additional stereotypes are provided to bring greater detail into the SysML model. Full details are provided in the SysML spec..
83
Probability
probability stereotype applied to outgoing edges (flows) from decision or object nodes Defines value (range: 0 1) for probability of any flow being taken
Total of values from one node must equal 1
probability p (x )
ac tion 1
probability 1 -p (x )
ac tion 2a
ac tion 2b
Can also be applied to output parameter set from node

With same value constraints
Slide 84
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]
84
Activity Diagram Distiller Example: Activity Structure

bdd [package] DistillerBehavior [Distiller Behaviour Breakdown] 1 Activity Distill Water 1 1
a1 : Heat Water
1 a2 : Boil Water Activity Boil Water
Activity Heat Water
1 a3 : Condense Steam Activity Condense Steam 1
a4 : Drain Residue1 1 Activity Drain Residue
pure : H2O Block Item Types::H2O
coldDirty : H2O
BlockProperty cal/gm : specificHeat 1 1 BlockProperty cal/(gm*deg C) : latentHeat Remove Latent Heat of Vaporisation () Add Latent Heat of Vaporisation () 1 hotDirty : H20 1 steam : H2O
1 recovered : Heat external : Heat 1 Block Item Types::Heat values cal/sec : dQ/dt
1 hiPress : Residue Block 1 Item Types::Residue loPress : Residue values degrees C : temp gm/sec : massFlowRate kg/gm^2 : press
Slide 85
85
Activity Diagram Distiller Example: Control-Driven: Serial Behavior

effbd act [activity] Distill Water [Serial Behavior] coldDirty : H2O [Liquid] a1 : Heat Water recovered : Heat
hotDirty : H20 [Liquid ] external : Heat a2 : Boil Water
steam : H2O [G a s ]
hiPress : Residue
fork
loPress : Residue a4 : Drain Residue a3 : Condense Steam pure : H2O [Liquid ]
join
Slide 86
The ephod stereotype implies this activity conforms to the constraints specified for Enhanced Functional Flow Block Diagrams (a non-normative SysML extension).
86
Activity Diagram Distiller Example: I/O Driven: Continuous Parallel Behavior

act [activity] Distill Water [Continuous Parallel Behavior]
coldDirty : H2O [Liquid ]
recovered : Heat
hiPress : Residue loPress : Residue
a1 : Heat Water
a3 : Condense Steam
a4 : Drain Residue
hotDirty : H20 [Liquid ]
external : Heat
a2 : Boil Water
pure : H2O [Liquid]
Slide 87
87
Activity Diagram Distiller Example: (Allocation with Swimlanes): DistillWater

Parts
allocate hx1 : Heat Exchanger act [activity] Distill Water [Simultaneous Behavior with Allocations] allocate bx1 : B o iler allocate drain : V alve
continuous coldDirty : H2O [ Liquid]
recovered : Heat
continuous steam : H2O [G a s ]
continuous hiPress : Residue
continuous loPress : Residue
streaming a1 : Heat Water
a4 : Drain Residue streaming a3 : Condense Steam
continuous hotDirty : H20 [ Liquid] continuous external : Heat ShutDown streaming a2 : Boil Water continuous pure : H2O [Liquid ]
Slide 88
88
Interactions
Slide 89
89
SysML Sequence Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 90
The Sequence Diagram is re-used from UML and captures certain aspects of behavior.
90
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) youll want to see how the capabilities are delivered by the components within the System Architecture (Modelling the Solution).
Slide 91
91
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
Slide 92
92
Sequence Diagrams
sd SD Concept
Describe use case or scenario sequence Specify timing budgets and constraints Define loops and conditional paths for system functionality Demonstrate parallel and synchronous functionality
Slide 93
Description
Actor1
Block part a :Block A signal1 {10ms}
Block part b :Block B
Block part c :Block C
seq par seq loop seq break seq end loop also par alt seq seq end alt seq end par
message 1
{250ms} message 2 message 2
max.: {100ms}
message 3 message 4( param ) signal2
93
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
Slide 94
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.
94
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
These default names can be replaced by something more meaningful if required in Studio.
95
Sequence Diagram Example Fragments

sd SD Fragments Description Actor1 Block part a :Block A signal1 {10ms} par
seq loop seq break seq end loop also par alt seq seq end alt seq end par
Slide 96
Block part b :Block B
Block part c :Block C
seq par
message 1 loop max.: {100ms}
{250ms} message 2 message 2
alt message 3 message 4
signal2
96
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
Slide 97
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.
97
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
Slide 98
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.
98
Part Decomposition - Example

U ser
D escription
B lockP roperty B lock B lockP roperty D istiller.ui1:C o ntrol P anel :D istiller D istiller.b x1:B oiler ref S tart B oiler S tartU p T urnO n pow erO n
s tart up s tart Dis tiller s tart B oiler
sd Start Boiler
Description Block BlockProperty BlockProperty BlockProperty :Boiler Boiler.heater:Element Boiler.vOverFlow:Valve Boiler.vResidue:Valve powerOn on open open
power on boiler switch on heater open overflow open residue
Slide 99
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.
99
Identifying Block Functional Requirements with Use Case Scenarios

s e q O pe ra te D istille r [U I O p eratio ns] D escrip tion U ser B lo ck :C ontro l P a ne l S ta rtU p pw rO n B lo ck :C ontro ller
Block Control Panel operations pwrLightON () opLightON () hghLightON () drnLightON () lowLightON () opLightOFF () pwrLightOFF ()
pres s s tart tu rn o n D is tille r s ho w p ow er on wa it fo r w a te r to b oil s ho w o pera ting re pea t a lt w ate r high e ls e alt d ra in in g e ls e alt w ate r low e nd a lt until... ...pres s s to p tu rn off D is tille r s ho w n ot ope ra tin g s ho w p ow er off
Operation call messages

lo op a lt
p w rL ig htO N op L ig htO N
hg hL ig htO N d rnL ig htO N lo w L ig htO N
S hutD ow n shutD ow n op L ig htO F F p w rL ig htO F F
Messages imply need for Block operations Block operations define functional requirements for block Operations can map to actions
Slide 100
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.
100
Refinement through Iteration
Use Case Description
Candidate Entities
Sequence Diagram
:Barrier Motor
Red :Light
Green :Beam Sensor :Pressure Sensor :Light {5ms} car_arrived
:Controller :Car Count
entry beam detects car beam sensor signals controller controller checks for space If full suspend entry EndIf open barrier turn off red light turn on green light car passes through beam beam sensor signals controller increment car count close barrier turn off green light turn on red light car triggers pressure sensor pressure sensor signals controller decrement car count
break
isFull Car Waits open off on connect car_entered increment close off on detect car_exited decrement
{5ms}
Iterate
Slide 101
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.
101
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
Slide 102
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.
102
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
Slide 103
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.
103
State Machines
Slide 104
104
SysML State Machine Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 105
The State Machine Diagram is re-used from UML and captures state-based behavior.
105
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.
Slide 106
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.
106
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
Slide 107
107
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
Slide 108
108
Main State Diagram Modelling Elements
State 1
event [guard] / effect
State 2
States Initial/Final Transitions
Events
States
Guards Effects
Slide 109
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. Well 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).
109
Events
An occurrence that may trigger potential effects Event types :

Slide 110
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.
110
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
Slide 111
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.
111
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
Slide 112
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.
112
Initial and Final States

Initial (pseudo)state
points to the entry state for a region of a state machine can have an initial action (effect) only one permitted within any region of a state machine
/initial ac tion
State 1
Final State
Indicates completion of all state activity for the region containing the final state can be more than one in a region can be named and show completion action
/c om pletion ac tion
Final 1
Slide 113
The term region is used in the context of composite states (see later).
113
A Simple Example
stm [Block] H2O1 Gas
Rem ove Latent Heat of V aporis ation/
Transitions States
A dd Latent Heat of V aporisation/
Liquid
Rem ove Latent Heat of V aporisation/
A dd Latent Heat of V aporis ation/
Events
Solid
Slide 114
A state machine for water.
114
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
Slide 115
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.
115
Composite State - Sequential

Applies to all sub-states
stm [Block] Boiler Operating
highResidue/open residue valve lowResidue/close residue valve
powerOn/s witc h on heater
Sequential State
Heater On
when( tem p= M ax )/ switch off heater
powerOff/s witc h off heater
when( tem p= M in )/ switc h on heater
Substates
Heater Off
Slide 116
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.
116
Concurrent States
stm [block] Container
concurrent state
Processing
region
Routing
join
Moving Registering Idle
Scanning Capturing data
fork
synch state
Processing data
Slide 117
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.
117
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
Slide 118
Activities have significant duration whereas actions have insignificant duration.
118
More Complex Example

stm [block] Distiller Controller [Distiller States]
[bx Tem p < 100degrees ]/
Off
Entry/pwrLightOFF
[bx LevelB elow]/
Draining Entry/Open Drain : IValve
Cooling Off Entry/bxHtrOFF; Open Drain : IValve; Open Fill : IValve

s h utD ow n /
p w rO n /
Distilling Filling Entry/Open Feed : IValve

E ntry/bxHtrON Controlling Boiler Level
[bx Leve lHigh]/
[NO T b x LevelLow]/
Level Low
[NO T bx Leve lL ow]/
Entry/Open Feed : IValve

[bx Le ve lLow]/
Level OK Entry/Close Drain : IValve ; Close Fill : IValve
Level High Entry/Open Drain : IValve

[NO T bx LevelHigh ]/
Warming Up
E ntry/bxHtrON
Controlling Boiler Residue

/
[bx Tem p = 100degrees ]/
Building Up Residue Entry/Close Drain : IValve
Res id ueTim e r/ D rainTim e r/
Purging Residue
Entry/Open Drain : IValve
Slide 119
119
Cross Cutting Concepts

Requirements Traceability
Slide 120
120
Requirements: Structure or Behavior?

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 121
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.
121
SysML Requirements Traceability
requirement REQ_A1
Model Element T trace
requirement REQ_A1.1
requirement REQ_A1.2 deriveReqt requirement REQ_B1
Model Element A refine
Traceability relationships between requirements and model elements
verify
testCase Model Element B
Design Elements requirement REQ_C Model Element C satisfy
Slide 122
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?
122
Requirements Traceability from Other Diagrams
Use Case A
refines REQ_A1.2
Actor1
satisfies REQ_A1.1
Use Case B
Actor2
Traceability callouts can be added from model elements wherever they appear in other diagrams in the model
Slide 123
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.
123
SysML Requirements Traceability Table
Slide 124
The table can be customized by adding or removing specific columns.
124

Allocations
Slide 125
125
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
Slide 126
126
Different Allocation Representations

(Tabular Representation Not Shown)
allocate Element Name1 allocate
Element Name2 Element Name3
allocate :ElementName
ActionName
Allocate Relationship
Explicit Allocation of Action to Swim Lane
block BlockName PartName allocatedFrom elementTypeElementName
block BlockName
allocatedFrom elementTypeElementName
PartName
Compartment Notation
Slide 127
Callout Notation
127
Behavioral Allocation Actions to Parts using Activity Diagram Swimlanes

Parts
allocate hx1 : Heat Ex changer act [activity] Distill Water [Simultaneous Behavior with Allocations] allocate bx1 : B o iler allocate drain :V a lve
continuous coldDirty : H2O [ L iqu id]
recovered : Heat
a4 : Drain Residue streaming a1 : Heat Water streaming a3 : Condense Steam
continuous hotDirty : H20 [ Liquid ] continuous external : Heat ShutDown streaming a2 : Boil Water continuous pure : H2O [ L iq uid]
Actions
Slide 128
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.
128
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 llo c a te
Allocate
BlockProperty Part5
BlockProperty Part3
Allocate
BlockProperty Part6 Allocate
Slide 129
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]
129
Abstract to Concrete Allocation: Example

CCIF : RS232 EMU : EMU Message EMUIF : RS232 BlockProperty Power : Electric Power CC Sys : Cruise Control System
Set Throttle : AnalogueMessage
BlockProperty PowSys : Power Subsystem
CCIF : Analogue ItemFlow Gear : Analogue
TransmIF : Analogue BrakeIF : Digital
allocatedFrom Connector Power-CC System GearShiftIF : Force AccelIF : Force
concrete implementation
BlockProperty PowSys : Power Subsystem
Power-CC System
BlockProperty CC Sys : Cruise Control System
abstract concept
Slide 130
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.
130
SysML Allocation of SW to HW
ibd [node] SF Residence
n ode SF R esid ence Ins ta llat i on
hardware : Optical Sensor
* hardware : Video Camera
2 hardware : Alarm
hardware : Site Processor allocatedFrom software Device Mgr software Event Mgr software Site Config Mgr software Site RDBMS software Site Status Mgr software User I/F software User Valid Mgr
hardware : NW Hub allocatedFrom software SF Comm I/F
hardware : DSL Modem
In UML the deployment diagram is used to deploy artifacts to nodes In SysML allocation on ibd and bdd is used to deploy software/data to hardware
hardware : DVD-ROM Drive allocatedFrom data Video File hardware : User Console
hardware : Site Hard Disk allocatedFrom data Site Database
Slide 131
131
SysML Allocations Traceability Table
Slide 132
132

SysML Package Diagram
Slide 133
133
The Package Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 134
134
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)
Slide 135
135
Package Diagram Organizing the Model
By Diagram Type
Slide 136
By Hierarchy
By IPT
136
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
Slide 137
137
The Parametric Diagram

Structure
Requirements
Behavior
Block Definition
Internal Block
Package
Activity
Parametric
Slide 138
138
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

Slide 139
139
Constraint Blocks
Defining reusable equations for Parametrics using constraint blocks on a block definition diagram
Slide 140
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]
140
Parametric Diagram Example 1 Vehicle Dynamics Analysis
Using the Equations in a Parametric Diagram to Constrain Value Properties
Slide 141
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]
141
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 Aircraft.Inertial Heading : Vector
property Aircraft.Roll : Real constraint Direction Cosine Matrix
property Aircraft.Pitch : Real
The underlying datatypes of each constraintProperty are captured. In this example, Aircraft.Inertial Heading is a Vector [x, y, z]. The type Vector is defined elsewhere in the design (as part of the Data-Model).
property Aircraft.Yaw : Real
property Aircraft.Body Heading : Vector
Slide 142
142
Cross Connecting Model Elements - Summary

1. Structure
ibd ibd[[block] block] Anti-LockController Anti - LockController [Internal [Internal BlockDiagram Diagram] ] [InternalBlock Block Diagram] satisfies satisfies requirement requirement AntiAnti-Lock Lock Performance Performance ibd [block] Anti-LockController [Internal Block Diagram] d1 d 1:TractionDetector :TractionDetector
2. Behavior
act PreventLockup [Swimlane Diagram] allocate act PreventLockup [Activity Diagram ] :TractionDetector allocate :BrakeModulator
c1:modulator c1:modulator Interface Interface c1:modulator interface allocatedFrom ObjectNode TractionLoss TractionLoss: :
allocatedFrom activityDetectLos activityDetectLos d 1:Traction OfTraction Of Traction Detector

m m1: 1: BrakeModulator 1:BrakeModulator m1 :Brake Modulator allocatedFrom activityModulate BrakingForce
cate allo
value binding
v.chassis .tire. Friction: Friction:
DetectLossOf Traction
TractionLoss: TractionLoss:
Modulate BrakingForce
values DutyCycle : Percentage
allocatedTo connectorc1 :modulatorInterface
satisfy
req req [package] VehicleSpecifications [Requirements [Requirements Diagram Diagram -- Braking Requirements] Vehicle System Specification requirement StoppingDistance id= 102 id= 102 102 text= text =The The vehicle shall stop from 60 mph within 150 150ft ft on a clean dry surface. Braking Subsystem Specification requirement requirement Anti-LockPerformance AntiLockPerformance id= 337" id= 337" text =Braking subsystem shall prevent wheel lockup under all braking conditions .
par [constraintBlock] [ constraintBlock] StraightLineVehicleDynamics StraightLineVehicleDynamics [Parametric Diagram] Diagram ] v.brake .abs.m1. .abs.m 1. DutyCycle DutyCycle: : v. brake.rotor v.brake .rotor.. BrakingForce BrakingForce: :
v .Weight: v.Weight:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram] tf tf: : tl: tl : bf: f: f: F: m m: c: :Accelleration :Accelleration Equation Equation [[F F= = ma] a a: : a: v: v: v :
:BrakingForce :BrakingForce Equation [f = (tf*bf (tf* bf)*(1)*(1-tl)] tl)]
VerifiedBy SatisfiedBy interactionMinimumStopp blockAnti -LockController deriveReqt ingDistance
:DistanceEquation : DistanceEquation [v = dx dx/dt] /dt] x: x:
:VelocityEquation : VelocityEquation [a = = dv/dt] dv/dt ]
deriveReqt deriveReqt
v v.Position: .Position:
3. Requirements
Slide 143
verif y
4. Parametrics
C opyright 2006ARTISAN Software Tools All Rights Reserved
Four types of cross-connecting principles: 1. Allocation 2. Requirement satisfaction/derivation 3. Value Binding/Parametrics 4. Requirement Verification
143

Software Engineering Handover
Slide 144
144
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 objectorientation (OO) Some essential UML terminology and notation Some appreciation of how UML designs evolve from requirements to code
Separate systems engineering model from software engineering model

Either: separate model for each (with package import/export) Or: separate packages for each (within one Studio model)
Slide 145
145

Fundamentals of OO
Slide 146
146
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
Slide 147
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.
147
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.
Slide 148
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 workers 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.
148
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.
Slide 149
149
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.
Slide 150
150
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.
Slide 151
151
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.
Slide 152
152
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.
Slide 153
153

Software Development with UML
Slide 154
154
A Simple Application
Pressure sensor Display Boards
Lot 1 Spaces Lot Lot 1 2 Spaces Full Lot Lot 2 3 FullSpaces Lot 3 Spaces
System controller & barrier motor
Exit Traffic lights Parking Lot
Serial Link
Entry
Safety barrier
IR beam sensor
Slide 155
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.
155
Software Requirements from System Requirements

req [Package] Reqts
requirement REQ_1 txt The System shall prevent a car from entering if the parking lot is full. deriveReqt
requirement REQ_1_SW1 txt The software shall input and store the maximum capacity value for the parking lot. requirement deriveReqt REQ_1_SW2 txt The software shall maintain a count of cars currently in the parking lot. deriveReqt requirement REQ_1_ SW3 txt On detecting a car arriving, the software shall compare current count value against maximum capacity to determine whether the car should be allowed to enter.
System Requirement
Derived Software Requirements
Slide 156
The SysML requirements diagram can show both system and (derived) software requirements. In Studio, requirements diagrams can also be held in a UML model.
156
Capturing the Software IO Context

Parking Lot System
subsystem Operator I/O Unit interface device Entry Beam Sensor : clear display interface device Display
: car breaks beam
: car passes through
: car triggers sensor : display : break : detect : connect : key press Car interface device Pressure Sensor
Operator
interface device Keypad subsystem Control System : set red
interface device Red Light
interface device Display Button
: display press interface device Green Light : set green : lower
: raise
interface device Reset Button
: reset press : set full interface device Barrier Motor interface device Full Light :
Slide 157
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.
157
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 Car
extend Car Waits
Set Capacity
Operator
Slide 158
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.
158
System Interaction Diagrams Specify Required Use Case Behavior

Use Parking Lot Description
entry beam detects car beam sensor signals controller check for space If full suspend entry EndIf open barrier turn off red light turn on green light car passes through beam beam sensor signals controller increment car count close barrier turn off green light turn on red light car triggers pressure sensor pressure sensor signals controller decrement car count
Context Diagram devices

Car Barrier Motor Red Light Green Light Entry Beam Sensor Pressure Sensor car breaks beam break Control System
Car Waits raise set red( off ) set green( on ) car passes through connect max. {50ms} lower set green( off ) set red( on ) car triggers sensor detect
{3ms}
timing constraint
Slide 159
system boundary
architectural 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.
159
Initial Object Interaction for a Use Case

Description :Barrier Motor Red Green :Beam Sensor :Pressure Sensor :Light :Light :Controller :Car Count
entry beam detects car beam sensor signals controller controller checks for space If full suspend entry EndIf open barrier turn off red light turn on green light car passes through beam beam sensor signals controller increment car count close barrier turn off green light turn on red light car triggers pressure sensor pressure sensor signals controller decrement car count
break car_arrived isFull Car Waits open off on connect car_entered increment close off on detect car_exited 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.
Slide 160
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.
160
Example Class Diagram

Sensor {Abstract} - status : short + initialize () + read () : short + on () + off () 1 theGreenLight Light Barrier Motor + open () + close () theRedLight 1 theMotor
Beam Sensor + initialize () + read () : short 1 theEntrySensor Operator I/O Unit
Pressure Sensor 1 - threshold : float + initialize () + read () : short 1 theExitSensor Notifies Notifies 1 Controller theController 1 + car_entered () 1 + car_exited () theController + car_arrived () 1 I/O Unit - capacity : long - num : short - newValue : long + reset () + activate () + key (in number) 1 theIOUnit theCarCount 1 Car Count 1 1 - capacity : long theCarCount - count : long = 0 + increment () + decrement () + isFull () : boolean + set_capacity (in value : long) + get_capacity () : long displayButton resetButton 1 1 + Car_Count () Button - ~Car_Count () + read () : short resets capacity 1
myDisplay 1
myKeypad
Display + display (in data)
Keypad
Slide 161
As software interaction models are developed, a class model is also evolving to capture class properties and relationships.
161
State Diagram Example

Controller Able to Admit Cars
car_exited/theCarCount.decrement
D es troy /
Idle
c ar_ arrived/
[theCarCount.is Full ]/ [e ls e ] /
Entry Suspended
C re ate /
Raising Barrier
Entry/theMotor.open; theRedLight.off; theGreenLight. on;
car_entered/ theCarCount.increment; theMotor.close; theGreenLight.off; theRedLight.on;
c ar_exited/ theCarCount.dec rement
Des troy / after( 2000 )/
Lowering Barrier
Slide 162
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).
162
Model Concurrency
Display Button Pressure Sensor Entry Beam Sensor
display press()
detect()
break() connect()
Event direction is conceptual only; in fact all input devices are polled
Red Light Event DetectionTask wait() set() Sensor Flags
decrement() release()
increment()
Admit Car Task
Green Light
set() Semaphore
isFull() get() Car Count reset_capacity() Barrier Motor
get_capacity() wait() 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
Slide 163
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.
163
Updated Class Model

1 Sensor {Abstract} - status : short + initialize () + read () : short + on () + off () 1 theGreenLight 1 EntryDetector Beam Sensor + initialize () + read () : short 1 theEntrySensor Operator I/O Unit CRconcurrent I/O Unit - capacity : long - num : short - newValue : long + main () + activate () + key (in number : short) + reset () ... theIOUnit 1 1 myDisplay 1 Display + display (in data) 1 myKeypad Keypad 1 resetButton 1 Button + read () : short 1 1 ExitDetector Pressure Sensor - threshold : float + initialize () + read () : short 1 theExitSensor Notifies 1 Notifies CRconcurrent Event Detection + main () ... 1
Light
Barrier Motor + open () + close () theRedLight 1 theMotor
1 CRconcurrent Controller
theController 1 + main () + car_exited () 1 + car_arrived () theController + car_entered () 1 1
pRTOS
1 1 theIO
resets capacity
1 theCarCount - capacity : long - count : long = 0 + increment () + decrement () + isFull () : boolean + set_capacity(invalue:... + get_capacity () : long 1 Display
2 Sensor Flags 1 + DisplayPressFlag + 1 theCarCount + Car Count +
cEvent _Flag flag : boolean Set () Clear () Check () : boolean Wait ()
Slide 164
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.
164
Evolve Class Model for Code Production

class Class1 { public:
::Class1 Attribute1 : Typedef1 Operation a () Operation b (in param : Typedef1) : long 1 1 theC2 ::Class2
enum Typedef1 { Typedef1_enum1, Typedef1_enum2 }; // public operations
Operation c ()
void Operation_a(); long Operation_b(const Typedef1 param); private: // private attributes Typedef1 Attribute1; // private roles Class2* rtheC2; };
Slide 165
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.
165
Traceability/Impact Analysis
Requirements
Requirements Models
Design Models
Source Files
t if a Wh
Tests
?
Satisfies Satisfies
Satisfies
Tests
Tests
Wh y
is
Acceptance tests
Slide 166
System tests
Integration and Unit tests
166
How it all fits together

Loc al Indic ation Panel
Nitro gen Co mpression Plant

LIP Display
Valves
stop/start buttons Inlet V alv e Outlet Valve By-pass V alve Vent Valve
HP Tank
ACME RADAR
system start/Start Up Plant e ls e] / [ power up/

Fail Safe
LPT and LOP alarms ringing] / [

Outle t Valve Inlet Valve Ve nt Valve By-p ass Valve
: Use r Displays
3 wir e RS232
HPT Switch
: Signal Proce ssing
: RADAR Controller
Plant Contr oller
: Displa y
: Ke ypa d Ope rato r
se ria l i/f
dis play board
HP Switch
Starting Up System
Com pre ssor Unit Re mote M onitoring Unit
power down/
alarm/ Handle Alarm aft er( 40s /)

Shutting Down System
after( 180s ) / Maintain Gas Pressure State4
op en() Comp ressor Mo tor sta rt() stop() NCP System
close()
: Array Antenna
LP T S witc h
system sto p() Local Indication Panel rese t() alarm () system start()
Remo te Operator
: A ntenna Controller : Re ceiver
: Arra y Orie ntation : Electronic Orientation : Mechanica l Orie ntation

I/O boar d Compr essor Unit
: Po wer Supp ly
system bus Compressor Motor
: Eleva tio n Actuator

system stop ()
Low Oil Pressure switch
Inlet Gas P ressure Trip Switch
LP S witch
alarm/ Handle Alarm

Compressor On
Compressor Sensors
alarm ()
: Transmitter
: Tx Rx Duplex
motherboard
system stop/ Shutdown Plant
Local o pera tor alarm () 250 bar() 15 0 bar() reset()
: Azimuthal Actuato r
Coolant Flow Meter remote comms. Outlet Gas P res sure Tr ip Switch
[ LO P a larm ring ing] /
250 bar/ S top Compressor

HP Tank
rese t()
se ria l i/f
Remote Monitoring Unit
[ els e ]/
150 bar/ Start Compress or
Take-of f Valve
HPT Switch
HP S witch
LP Switch
LPT Switch
RS 422 A ll I/O board connections are 24V DC s ingle phas e. Valve c onnections are in fact 2 single 1-way connections rather one 2-way ...
Interaction Overview (Modes) Diagram
Compressor Off
Context Diagram
P ilot
Composite Structure Diagram
RMU Display
S top Button
Hardware Architecture (Deployment) Diagram

D ataE ntryPanel
P ilot P ressesK ey P ilot KeyP res s S oftw areD eterm inesnewM ode P ilot P ressesK ey Pilot if N A VKey then KeyP res s S oftw areD eterm inesnewM ode E nter N P av ilot igationM P ressesK ode ey if N A VKey then K eyPress els if W eaponsK ey then S oftw areD eterm inesnewM od e E nter N av igationM ode cas e SelectedStore is els if if W N eaponsK A VK eyey then then whenLoft B om bs = > E nter N av igationM ode cas e SelectedStore is whenR etardB om bs => els if when W eaponsK Loft B ey om th bs en = > whencas G uns e Selecte => dSto re is when R etardB om bs=> whenR ockets => when Loft B om bs => when G uns => en dcas e whenwhen R ockets R etardB => om bs= > endif when G uns = > en dcas e endif when R ockets= > en dcase endif
Read()
Store s N a viga tio nD a ta
T heSoftw are :Th eSo ftware T heSoftw are D ataE ntryPanel :Th eSo ftw are T heS oftw are K eyPress (K EYID) D ataEntryPanel :TheSo ftw are
K eyPress (K EYID)
S etM ode( N AV)
Networks ( for LIP and RMU) Write()
Alarm Monitoring Task (AMT)
Real World Trips
D ep lo ys W e ap on P ilot
KeyP ress (KE YID) S etM ode(N AV)

S etM ode( LO FT) SetM ode(S R et E M TA ode(N R D) AV) S etM ode(LO FT) SetM ode( G U N) SetM ode(R E TA R D) SetM ode( R O C KE T) SetM ode(G SetM U ode(LO N) F T) SetM ode(R E TA R D) SetM ode(R O C KE T) SetM ode(G U N) SetM ode(R O C KE T)
Set()
Clear()
Check()
alarm status data Read() Alarms Status Alarm Inhibits /Enables Display and Communication Task (DCT) Read() Timer Requests Set() Write() Read() Write() Clear() Compressor Controller Task (CCT) Real World Devices Clear() Timeout Events Read() Read() Timer Task (TT) Post()
P erfo rm s S orte
Set() Start/Stop Requests
Requirements
Equivalent Bombadier Pilot Secondary Actor Commander
Use Case Model Scenario Model

Create/ De stro y/
sto pp ed
Communicator Strike Authority
Plant Status
ru n nin gdo wn after(40s)/ E ntry/mo n ito r. in hibit(L O P); va lve [ven t]. ope ... ; n time r. se t(40 ); m oto r. sto ; p
va lve [in le t].clo se; va lve [ou tle t]. clo se ; va lve [by-pa ss]. o pe n;
Strike Authorised
sta rt com presso r/
Authority
[ ! m on ito .r ch eck (L O P)] / mo nitor . a ctiva te (L O P)
...
Select W eapon Type
m [ on ito r. ch eck (LO P )] /

Select Target Destination
stopcom presso r/ time r. can cel (30 ); time r. can cel (40 );
Concurrency (Communication) Diagram

::P roduc t ::Se rv ice ::W orkIns truction D e scription S tart D ate D u ration P erform anceR atin g A greePe rform an ceR a ting * M an ag es 1..* 1 M ana ger N a m e A ge W o rke r ::Pe rs on 1 D escrib esW o rkOn 1..* C ost 1 ..* M a rke ts 1..* P urch ases 1 ::R ev enueItem ItemTyp e{E xclu sive}
Bombadier
w a itin gfo r oil p ress uretob u ild E n try/m o nitor inh . ib it(LO P );
Navigate to Target
sto pco mpre ssor/
v a lv [ e v en t].clo se; tim er set (3 . 0 ); tim er set (4 . 0 );
stopcom pre sso r/ time r. can ce (40 l );

...
Navigator
Test Scripts
m o tor . star ;t
time up / m on ito r. en able (L O P)
w a itin gfo r ga sp re ssuretob u ild
o pe ratin g
afte r(10 s )/ valve[by-pass]. clo se; valve[in le t].o pe n; valve[ou tle t]. o pe ;n ...
Activity Diagram
Specification generalRequirem ent RequirementC id = "Name" satisfy text = "The system shall..." priority = High 1 status = "Assigned" Design SystemElementA
1M an ufa ctu rer 1..* Em p loyee W orksFor 1 ::C om pany
C usto m er
Em p lo yer N am e 1
Dynamic Model
Operational Parameters
0..1
A ssign U n -Assign 1 1S up erviso r U p dates
property Aircraft.Inertial Heading : Vector property Aircraft.Roll : Real
Performance
1 ::D ev elopm e ntP lan M e anPe rfo rm an ce TrainingN ee ds C urren tS kills * U pd ate s
::C on tract Start D a te Sa lary G rade C h an geG ra de 1 *
1..* ::C ontractua lC on straint D e scription U p date
functionalRequirement Requirement A
performanceRequirement Requirement B
<<rationale>>
C o nstraintType{Inclusive}
Loader Speed
*
Containers Scan Success
::Term
::C ondition
trace Derived Requirements trace
Reas on
property Aircraft.Pitch : Real
pConstraint Direction Cosine Matrix
functionalRequirement RequirementX
performanceRequirement RequirementY satisfy
SystemElementB
Belt Speed
Test Cases verify test Case Test CaseA
Defective Containers Accuracy
Class Model Source Files
property Aircraft.Yaw : Real property Aircraft.Body Heading : Vector
Requirements Diagram Slide 167
Constraints Diagram
Parametric Diagram
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.
167
Summary and Wrap-up
Slide 168
168
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
Slide 169
169
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
Slide 170
170
Additional Reading
o The Unified Modeling Language Reference Manual (Addison-Wesley Object Technology Series) by James Rumbaugh, Ivar Jacobson, Grady Booch Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition) by Craig Larman Writing Effective Use Cases by Alistair Cockburn Applying Use Cases: A Practical Guide by Geri Schneider, Jason P. Winters, Ivar Jacobson The Object-Oriented Thought Process by Matt Weisfeld, Bill McCarty Pattern-Oriented Software Architecture, Volume 2, Patterns for Concurrent and Networked Objects by Douglas Schmidt
o o o o
QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture. QuickTime and a TIFF (Uncompressed) decompressor are needed to see this picture.
QuickT imeand a T IFF (Uncompressed) decompressor are needed to see this picture. QuickT imeand a T IFF (Uncompressed) decompressor are needed to see this picture.
Slide 171
171
Questions and Answers
Slide 172
172
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
Slide 173
173
Distiller Sample Problem
Slide 174
174
System Development Process

Stakeholder Reqts
Manage System Development Status Technical data Plan
Define System Reqt's & Design
Test procedures System arch Allocated reqt's

Procedures Data Hardware Software
Integrate & Test System
System
System modeling Activities
Verified System Component
Component modeling Activities
Develop System Components
Integrated Product Development (IPD) is essential to improve communications

Slide 175
A recursive V process that can be applied to multiple levels of the 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.
175
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
Slide 176
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.
176
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.
Dirty water @ 100 deg C Energy to condense Condense steam and Drain Residue Disposed residue Pure water
A crude behavior diagram is shown.

Dirty water @ 20 deg C Steam
Heat Dirty water To 100 deg C
Boil Dirty water
and
Residue Heat to Dirty water Heat to Boil water
What are the real requirements? How do we design the system?

Slide 177
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.
177
Distiller Types
Batch Distiller
Continuous Distiller
Slide 178
178
Distiller Problem Package Diagram: Model Structure and Libraries

bdd [Package] Value Types1
p k g [M o d e l] D istille r M o d e l 6 .1 h 1 [M o d e l O ve rvie w ] D istille r R e q u ire m e n ts D istille r U se C a se s
ValueType Real
ValueType Power
D istille r B e h a vio u r
D istille r S tru c tu re
ValueType temp dimension ThermodynamicTemperature unit DegreeCelsius
ValueType press dimension Pressure unit N/M^2
ValueType massFlowRate dimension Mass Flow Rate unit gm/sec
ValueType dQ/dt dimension Heat Flow Rate unit cal/sec

V a lu e T yp e s Ite m T yp e s
ValueType efficiency
ValueType specificHeat dimension Specific Heat unit cal/(gm*DegreeCelcius)
ValueType latentHeat dimension Latent Heat unit cal/gram
Unit N/M^2
Unit gm/sec
Unit cal/(gm*DegreeCelcius)
Dimension Mass Flow Rate
Dimension Specific Heat
Slide 179
Unit cal/sec
Unit cal/gram
Dimension Heat Flow Rate
Dimension Latent Heat
This diagram shows the structure used to build the distiller model, and emphasizes the units used.
179
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 PurifyWater id# S1.0 txt The System shall purify dirty water. S2.0 txt Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger. requirement Boiler
The requirement for a boiling function and a boiler implies that the water must be purified by distillation.
HeatExchanger id# S5.0
requirement Water Properties id# txt 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.
id# S3.0 txt Boil dirty water is performed by a Boiler. S5.1
requirement WaterInitialTemp id# txt Water has an initial temp of 20 degrees C.
requirement Drain deriveReqt id# S4.0 txt Drain residue is performed by a Drain.
requirement Distill Water id# D1.0 txt The System shall purify water by boiling water.
Slide 180
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.
180
Distiller Example: Requirements Tables
id S0.0 S1.0 S2.0 S3.0 S4.0 S5.0 S5.1
name OriginalStatement PurifyWater HeatExchanger Boiler Drain WaterProperties WaterInitialTemp
text Describe a system for purifying dirty water. The system shall purify dirty water. Heat dirty water and condense steam are performed by a Boil dirty water is performed by a Boiler. Drain residue is performed by a Drain. water has properties: density 1 gm/cm3, temp 20 deg C, water has an initial temp 20 deg C
Slide 181
Tables will be used more often than requirements diagrams, because they are more compact and more scaleable.
181
Distiller Example Activity Diagram: Start Point : Control-Driven Serial Behavior

effbd act [activity] Distill Water [Serial Behavior] coldDirty : H2O [Liquid] a1 : Heat Water recovered : Heat
Control (Sequence)
external : Heat a2 : Boil Water
hotDirty : H20 [Liqu id]
Things that flow (Object Nodes) Activity (Function)
hiPress : Residue
loPress : Residue a4 : Drain Residue a3 : Condense Steam pure : H2O [Liquid]
Batch Distiller
Slide 182
This activity diagram follows the optional SysML EFFBD profile, and formalizes the diagram in the problem statement.
182
Distiller Example Block Definition Diagram: Distillerbehavior

bdd [package] DistillerBehavior [Distiller Behaviour Breakdown] 1 Activity Distill Water 1 1
a1 : Heat Water
1 a2 : Boil Water Activity Boil Water
Activity Heat Water
Activities (Functions)
1 a3 : Condense Steam Activity Condense Steam 1 a4 : Drain Residue 1 1 Activity Drain Residue
Need to consider phases of H 2 0
pure : H2O Block Item Types::H2O
coldDirty : H2O
1 recovered : Heat external : Heat 1 Block Item Types::Heat values cal/sec : dQ/dt
1 hiPress : Residue Block Item Types::Residue 1 loPress : Residue values degrees C : temp gm/sec : massFlowRate kg/gm^2 : press
BlockProperty cal/gm : specificHeat BlockProperty cal/(gm*deg C) : latentHeat Remove Latent Heat of Vaporisation () Add Latent Heat of Vaporisation () 1 hotDirty : H20 1 steam : H2O
Control (not shown on BDD) Things that flow (ObjectNodes)

Slide 183
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.
183
Distiller Example State Machine Diagram: States of H2O

stm [Block] H2O1
Gas
A dd Latent Heat of Vaporis ation/
Rem ove Latent Heat of Vaporis ation/
States
Transitions
Liquid
A dd Lat ent Heat of V aporis ation/
Rem ove Latent Heat of V aporis ation/
Solid
Slide 184
This state machine diagram formalizes the states of H2O as it flows through the system. Change of state requires adding or removing latent heat.
184
Distiller Example Activity Diagram: I/O Driven: Continuous Parallel Behavior

act [activity] Distill Water [Continuous Parallel Behavior]
coldDirty : H2O [ L iqu id]
recovered : Heat
hiPress : Residue loPress : Residue
a1 : Heat Water
a3 : Condense Steam
a4 : Drain Residue
hotDirty : H20 [ Liqu id]
steam : H2O [ G a s]
external : Heat
a2 : Boil Water
pure : H2O [ L iqu id]
Continuous Distiller
Slide 185
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.
185
Distiller Example Activity Diagram: No Control Flow Simultaneous Behavior
act [activity] Distill Water [Simultaneous Behavior]
continuous coldDirty : H2O [Liquid]
recovered : Heat
continuous hiPress : Residue continuous loPress : Residue
a1 : Heat Water
a3 : Condense Steam
a4 : Drain Residue
continuous hotDirty : H20 [Liquid ]
a2 : Boil Water continuous external : Heat ShutDown
continuous pure : H2O [Liquid ]
Slide 186
This diagram is semantically equivalent to the previous diagram, but clearer and easier to read.
186
Distiller Example Block Definition Diagram: DistillerStructure

bdd [Package] Distiller Structure [Structural Breakdown] Block Distiller operations TurnOn () TurnOff () Block Item Types::Fluid values degrees C : temp gm/sec : massFlowRate kg/gm^2 : press Block Item Types::Heat values cal/sec : dQ/dt
hx1 Block Heat Exchanger
bx1 Block Boiler
drain Block Valve
satisfies requirement HeatExchanger
satisfies requirement Boiler
satisfies requirement Drain
Generic Subsystems (Blocks)

Slide 187
Usage (Part) Names (Roles)

Generic Things That Flow (Blocks)
The problem statement includes the initial product structure (Counter Flow Heat Exchanger, Boiler, Drain), which are defined in this Block Definition Diagram.
187
Distiller Example Activity Diagram (allocation with swimlanes): DistillWater

Parts (Roles)
act[activity] D istill W ater[Sim ultaneousBehaviorw ithAllocations]
allocate hx1 : Heat Exchanger allocate bx1 : B o iler allocate drain : V a lve
continuous coldDirty : H2O [ L iqu id ]
recovered : Heat
continuous steam : H2O [Gas ]
a4 : Drain Residue streaming a1 : Heat Water streaming a3 : Condense Steam
continuous hotDirty : H20 [ L iqu id ] continuous external : Heat ShutDown streaming a2 : Boil Water continuous pure : H2O [Liquid ]
Slide 188
The previous Activity Diagram has been elaborated with AllocateActivityPartitions, showing how actions are allocated to blocks (parts).
188
Distiller Example Internal Block Diagram: Distiller Initial Design

ibd [Block] Distiller [Initial with Item Flows] Block Distiller DSClean_Out : H2O ItemFlow : H2O
ItemFlow : H2O
ItemFlow : Residue
ItemFlow : Residue DSResidue_Out : Residue
HEClean_Out : H2O
HEHotDirty_Out : H2O
BLHotDirty_In : H2O
BLSteam_Out2 : Residue BLExcess : H2O
Fluid_In : Fluid BlockProperty drain : Valve
Fluid_Out : Fluid
BlockProperty hx1 : Heat Exchanger
BlockProperty bx1 : Boiler BLSteam_Out : H2O
HEDirtyIn : H2O DSDirty_Out : H2O ItemFlow : H2O
HESteam_In : H2O
BLPower_In : Power
ItemFlow : H2O DSExcess
DSPower_In : Power
ItemFlow : Power
ItemFlow : H2O
Parts (Blocks used in context)

Slide 189
Connectors Flow Ports

Things That Flow In Context (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 dont 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.
189
Distiller Example Internal Block Diagram: Distiller with Allocation

ibd [Block] Distiller [with Allocation] Block Distiller allocatedFrom pure : H2O
allocatedFrom hotDirty : H20
m2 : H2O m4 : H2O s1 : Residue BlockProperty hx1 : Heat Exchanger allocatedFrom a3 : Condense Steam a1 : Heat Water BlockProperty bx1 : Boiler allocatedFrom a2 : Boil Water BlockProperty drain : Valve allocatedFrom a4 : Drain Residue
s2 : Residue
ItemFlow1 : H2O m1 : H2O m3 : H2O allocatedFrom steam : H2O
allocatedFrom hiPress : Residue
allocatedFrom loPress : Residue
allocatedFrom coldDirty : H2O
Q1 : Power allocatedFrom external : Heat
Allocation Compartment (references Activities)

Slide 190
Allocation Callout (references Object Nodes)

This internal block diagram is now annotated with allocations from the previous swimlane diagram, accounting for flow allocation.
190
Distiller Example Parametric Diagram: Heat Balance Equations

Parts or ItemFlows
Value Properties
Value Bindings
Constraints
Constraint callouts
Slide 191
This parametric diagram helps the systems engineer to visualize the heat balance of an isobaric (constant pressure) distiller system. This is an appropriate firstorder 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.
191
Distiller Example Heat Balance Results

table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]
specific heat cal/gm-C latent heat cal/cm
1 540
Satisfies requirement WaterSpecificHeat Satisfies requirement WaterHeatOfVaporization
Not a SysML diagram Constructed from SysML diagram information Can be held in Studio a a text diagram
bx_steam_out
hx_water_out
bx_water_in
Satisfies requirement WaterInitialTemp
mass flow rate gm/sec temp C dQ/dt cooling water cal/sec dQ/dt steam-condensate cal/sec condenser efficency heat deficit dQ/dt condensate-steam cal/sec boiler efficiency dQ/dt in boiler cal/sec
6.75 6.75 1 1 1 20 100 100 100 100 540 540 1 0 540 1 540
Note: Cooling water needs to have 6x flow of steam! Need bypass between hx_water_out and bx_water_in!
Slide 192
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 doesnt allow this, so a modification must be made to the design in order to allow a bypass between the heat exchanger and the boiler.
water_out
water_in
192
Distiller Example Activity Diagram: Updated DistillWater

act [activity] Distill Water [Updated Simultaneous Behavior with Allocations]
allocate hx1 : Heat Exchanger
allocate feed :V a lve
allocate bx1 :B o iler
allocate drain :V a lve
continuous coldDirty : H2O [ L iq uid]
recovered : Heat
a4 : Drain Residue
streaming a1 : Heat Water
streaming a3 : Condense Steam continuous pure : H2O [ Liqu id]
continuous hotDirty : H20 [ Liqu id]
streaming a2 : Boil Water
continuous continuous external : Heat a5 : Divert Feed hotDirty1 : H2O [ Liquid] continuous hotDirty2 : H20 [ Liquid]
ShutDown
added as a result of parametric analysis
Slide 193
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.
193
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 m3 : H2O s1 : Residue BlockProperty hx1 : Heat Exchanger allocatedFrom a3 : Condense Steam a1 : Heat Water m2-1 : H2O BlockProperty feed : Valve allocatedFrom a5 : Divert Feed BlockProperty bx1 : Boiler allocatedFrom a2 : Boil Water m2-1 : H2O BlockProperty drain : Valve allocatedFrom a4 : Drain Residue
s2 : Residue
Q1 : Power
m2-2 : H2O
allocatedFrom hotDirty1 : H2O
allocatedFrom hotDirty1 : H2O
allocatedFrom hotDirty2 : H20
Slide 194
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.
194
Distiller Example Use Case and Sequence Diagrams

ucd Distiller Use Cases
User Operate Distiller

seq Operate Distiller [high level] Description User Block :Distiller BlockProperty Distiller.ui1:Control Panel StartUp TurnOn ref Distill Water [detail] ShutDown TurnOff
press start turn on Distiller distill water press stop turn off Distiller
Slide 195
195
Distiller Example Internal Block Diagram: Distiller Controller

ibd [Block] Distiller [with Controller] Block Distiller m1 : H2O m2-1 : H2O BlockProperty hx1 : Heat Exchanger BlockProperty feed : Valve m2-2 : H2O m2-1 : H2O BlockProperty bx1 : Boiler blrSig m3 : H2O IValve IValve s1 : Residue BlockProperty drain : Valve s2 : Residue
p1 : Power
m4 : H2O IValve
b1 : Power blrSig
BlockProperty ui1 : Control Panel
IPower
IPower
BlockProperty cx1 : Controller IValve
ILamp
ILamp
Slide 196
We now enhance our view of the Distiller structure by adding a Controller and associated Control Panel.
196
Distiller Example State Machine Diagram: Distiller Controller

stm [block] Distiller Controller [Distiller States] Cooling Off
[bx LevelB elow]/ [bxTem p < 100degrees ]/
Draining
Off Entry/pwrLightOFF
p w rO n /
Entry/bxHtrOFF; Open Drain : IValve; Open Fill : IValve

s h utDow n /
Distilling Filling Entry/ Open Feed : IValve

Entry/bxHtrON
Controlling Boiler Level [NO T bxLevelLow]/ Level OK

Entry/Close Drain : IValve; Close Fill : IValve
[bx LevelHigh]/
[NO T bxLevelLow]/
Level Low
Entry/Open Feed : IValve
[bx LevelLow]/
Level High
[NO T bx LevelHigh]/
Warming Up E ntry /bxHtrON

[bxTem p = 100degrees ]/
Controlling Boiler Residue

/
Building Up Residue Entry/Close Drain : IValve
Res idueTim er/ D rainTim e r/
Purging Residue
Entry/ Open Drain : IValve
Slide 197
This final diagram capture the state based behavior of the Distiller through Controller detected events.
197
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
Slide 198
198
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 Define Reqts diagram

Optimize & Evaluate Alternatives
Logical Architecture
Logical architecture
Synthesize Physical Architecture
Engr Analysis Models Trade studies
Validate & Verify System
Test cases/procedures
Node diagram HW, SW, Data architecture
Common Subactivities
Slide 199
Copyright Lockheed Martin Corporation 2000 Rights 2003 & INCOSE 2004-2006 C opyright 2006 ARTISAN Software Tools All Reserved
Use ISSEP chart for Design and Verify System activity. Note: Mention IPT. Try to show SE and software on same page -- Highlight differences.
199
Using Process Improvement To Transition to SysML
Slide 200
200
Integrated Tool Environment
Project Management
Engineering Performance Analysis Specialty Engineering Analysis
Requirements Management
CM/DM Product Data Management
SoS / DoDAF / Business Process modeling

Verification & Validation
System modeling SysML
Software modeling UML 2
Hardware modeling VHDL, CAD, ..
Slide 201
201

00 T2 Moreland

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

00 T2 Moreland

Uploaded by

Copyright:

Available Formats

Introduction to SysML

An Introduction to the OMG Systems Modeling Language (OMG SysML)

2008, ARTiSAN Software Tools

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Objectives & Intended Audience

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Process Issues Q&A

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

SE Practices for Describing Systems

Moving from Document centric to Model centric

2008, ARTiSAN Software Tools

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

2008, ARTiSAN Software Tools

Model Based Systems Engineering Benefits

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

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

2008, ARTiSAN Software Tools

What is SysML (cont.)

Is not a methodology or a tool

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

UML for Systems Engineering (SE) RFP

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

SysML Team Members

Copyright 2006 ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

C opyright 2006 ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Reuse of UML 2.0 for SysML

UML 2.0 SysML

2008, ARTiSAN Software Tools

Stereotypes & Model Libraries

Model Libraries represent reusable libraries of model elements

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Defining the Stereotype

Applying the Stereotype

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Tag Definition and Tag Value

Copyright 2006 ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Applying a Profile and Importing a Model Library

Copyright 2006ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

SysML Taxonomy of Diagrams

Block Definition [1]

Internal Block [2]

State Machine Sequence Use Case

Copyright 2006 ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

Modelling and Your Project

You may have additional specialized modelling requirements:

Copyright 2006 ARTISAN Software Tools All Rights Reserved

2008, ARTiSAN Software Tools

The Four Pillars of SysML (ABS Example)

Block Library:: Electro-Hydraulic Valve c1:modulator interface m1 Block Brake Modulator

BlockProperty d1 : Traction Detector