Upload
phamdung
View
232
Download
2
Embed Size (px)
Citation preview
©2008, ARTiSAN Software Tools 1
Introduction to SysML
Slide 1
Introduction to SysMLIntroduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights Reserved
An Introduction to theAn Introduction to theOMG Systems Modeling LanguageOMG Systems Modeling Language
(OMG SysML(OMG SysML™™))
Some slides Copyright © 2006 by Object Management Group.Published and used by INCOSE and affiliated societies with permission.
Clarence C. MorelandClarence C. MorelandPrincipal Consultant,Principal Consultant, ARTiSAN Software ToolsARTiSAN Software Tools
©2008, ARTiSAN Software Tools 2
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 2
Caveat
• This material is based on the Final AdoptedSysML specification (ad-06-05-04)– Adopted by OMG in May ’06
• Some of the slides are based on theOMG SysML tutorial and are used withpermission.
• OMG SysML Website– http://www.omgsysml.org/
©2008, ARTiSAN Software Tools 3
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 3
Objectives & Intended Audience
At the end of this tutorial, you should understand the:• Benefits of model driven approaches to systems engineering• Types of SysML diagrams and their basic constructs• Cross-cutting principles for relating elements across diagrams• Relationship between SysML and other Standards• High-level process for transitioning to SysML
This course is not intended to make you a systems modeler!You must use the language.
Intended Audience:• Practicing Systems Engineers interested in system modeling
– Already familiar with system modeling & tools, or– Want to learn about systems modeling
• Software Engineers who want to express systems concepts• Familiarity with UML is not required, but it will help
©2008, ARTiSAN Software Tools 4
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 4
Agenda
IntroductionSystems Engineering with SysMLRequirements and Requirements DiagramsStructural Diagrams
Blocks and Block DiagramsBehavioral Diagrams
Use Case modellingActivities and Activity DiagramsSequence DiagramsState Machines
Cross-cutting ConceptsRequirements traceabilityAllocationsPackage DiagramParametric Diagrams
Process IssuesQ&A
©2008, ARTiSAN Software Tools 5
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 5
SE Practices for DescribingSystems
• Specifications
• Interface requirements
• System design
• Analysis & Trade-off
• Test plans
Moving from Document centric to Model centricMoving from Document centric to Model centric
PastPast FutureFuture
©2008, ARTiSAN Software Tools 6
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 6
System Modeling
Requirements
Integrated System Model Must Address Multiple Aspects of a SysteIntegrated System Model Must Address Multiple Aspects of a Systemm
©2008, ARTiSAN Software Tools 7
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 7
Model Based SystemsEngineering Benefits
• Improved communications• Assists in managing complex system development
– Separation of concerns– Hierarchical modeling– Incremental development & evolutionary acquisition
• Improved design quality– Reduced errors and ambiguity– More complete representation
• Early and on-going verification & validation to reduce risk• Other life cycle support (e.g., training)• Enhanced knowledge capture
©2008, ARTiSAN Software Tools 8
Introduction to SysML
C opyright © 2006ARTISAN Software Tools All Rights ReservedSlide 8
What is SysML?
• A graphical modelling language in response to the UML forSystems Engineering RFP developed by the OMG,INCOSE, and AP233– a UML Profile that represents a subset of UML 2 with
extensions
• Supports the specification, analysis, design, verification,and validation of systems that include hardware, software,data, personnel, procedures, and facilities
• Supports model and data interchange via XMI and theevolving AP233 standard (in-process)
SysML is Key Enabler for Model Based Systems Engineering (MBSE)SysML is Key Enabler for Model Based Systems Engineering (MBSE)
©2008, ARTiSAN Software Tools 9
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 9
What is SysML (cont.)
• Is a visual modeling language that provides– Semantics = meaning– Notation = representation of meaning
• Is not a methodology or a tool– SysML is methodology and tool independent
©2008, ARTiSAN Software Tools 10
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 10
UML/SysML Status
• UML V2.0– Updated version of UML that offers significant capability
for systems engineering over previous versions– Finalized in 2005 (formal/05-07-04)
• UML for Systems Engineering (SE) RFP– Established the requirements for a system modeling
language– Issued by the OMG in March 2003
• SysML– Industry Response to the UML for SE RFP– Addresses most of the requirements in the RFP– Version 1.0 adopted by OMG in May ’06 / In finalization– Being implemented by multiple tool vendors
©2008, ARTiSAN Software Tools 11
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 11
SysML Team Members
• Industry & Government– American Systems, BAE SYSTEMS, Boeing, Deere & Company,
EADS-Astrium, Eurostep, Lockheed Martin, NIST, NorthropGrumman, oose.de, Raytheon, THALES
• Vendors– Artisan, EmbeddedPlus, Gentleware, IBM, Gentleware,
I-Logix, Mentor Graphics, Motorola, PivotPoint Technology,Sparx Systems, Telelogic, Vitech Corp
• Academia– Georgia Institute of Technology
• Liaison Organizations– INCOSE, AP233 WG
©2008, ARTiSAN Software Tools 12
Introduction to SysML
Slide 12
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Diagram OverviewDiagram Overview
©2008, ARTiSAN Software Tools 13
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 13
Reuse of UML 2.0 for SysML
UML 2.0SysML
UML notrequired by
SysML
SysMLExtensions
UML reusedby SysML
This workshop deals with the full set of SysML diagrams, boththe inherited UML diagrams and the additional ones.
©2008, ARTiSAN Software Tools 14
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 14
Stereotypes & Model Libraries
• Mechanisms for further customizing SysML• Profiles represent extensions to the language
– Stereotypes extend meta-classes with properties andconstraints
• Stereotype properties capture metadata about the model element
– Profile is applied to user model– Profile can also restrict the subset of the meta-model used
when the profile is applied
• Model Libraries represent reusable libraries of modelelements
©2008, ARTiSAN Software Tools 15
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 15
Stereotypes
Defining the Stereotype Applying the Stereotype
©2008, ARTiSAN Software Tools 16
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 16
Tag Definition and Tag Value
• Tag Definition– the definition (name, type) of an additional model item property– applied to a model item via linked stereotype(s)
• Tag Value– data value(s) for a specific tag definition for a specific model item
*
When you apply a stereotype to a model item, you often want to attach additionalinformation to that element. In the example of a «COTS» stereotyped board youmight want to specify the cost of that board. This is done by linking a tagdefinition (named, for example, ‘cost’) to the stereotype through which a tagvalue (for example, “24.50”) can be specified for that board.
©2008, ARTiSAN Software Tools 17
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 17
Applying a Profile andImporting a Model Library
©2008, ARTiSAN Software Tools 18
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 18
SysML Taxonomy of Diagrams
Diagram
Structure Behavior
BlockDefinition [1]
InternalBlock [2]
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
[1] Modified UML Class Diagram
[2] Enhanced UML Composite Structure Diagram
SysML reuses many of the major diagram types of UML. In some cases, the UMLdiagrams are strictly re-used such as use case, sequence, state machine, andpackage diagram, whereas in other cases they are modified so that they areconsistent with SysML extensions. For example, the block definition diagram andinternal block diagram are similar to the UML class diagram and compositestructure diagram respectively, but have extensions or omissions. Activitydiagrams have also been modified.
SysML does not use all of the UML diagram types such as the object diagram,communication diagram, interaction overview diagram, timing diagram, anddeployment diagram. This is consistent with the approach that SysML represents asubset of UML. In the case of deployment diagrams, the deployment of software tohardware can be represented in the SysML internal block diagram. In the case ofinteraction overview and communication diagrams, it is felt that the SysMLbehavior diagrams provided adequate coverage for representing behavior withoutthe need to include these diagram types. Two new diagram types have been addedto SysML : the requirement diagram and the parametric diagram.
[SysML v1.0]
©2008, ARTiSAN Software Tools 19
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide19
Modelling and Your Project
• Not all diagram types are essential– most projects will only use a subset
• You may have additional ‘specialized’modelling requirements:– process related– domain related– customer defined– etc.
*
For many organizations, any approach to modeling needs to be customized, toinclude standards, notation and information relevant to the organization, itscustomers, and the projects it undertakes. This need to extend the modelingcapability of the language is recognized within the UML by the specification ofextension mechanisms. The UML provides a mechanism for extending orcustomizing modeling information. This mechanism uses the above concepts to‘label’ model elements and to define additional properties for them.
©2008, ARTiSAN Software Tools 20
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 20
ibd [Block] Anti-Lock Controller1
«Block»Anti-Lock Controller
«BlockProperty»d1 : Traction Detector
«BlockProperty»m1 : Brake Modulator
«BlockProperty»d1 : Traction Detector
«BlockProperty»m1 : Brake Modulator
c1:modulator interface
use
interaction
par [constraint] StraightLineVehicleDynamics [Parametric Diagram]
: AccelerationEquationF c
a
: BrakingForceEquationtf
tl
bf
f
: DistanceEquation
vx
: VelocityEquation
a
v
{f = (tf*bf)*(1-tl)} {F = ma}
{v = dx/dt} {a = dv/dt}
The Four Pillars of SysML(ABS Example)
1. Structure
4. Parametrics
2. Behavior
Vehicle SystemSpecification
Braking SubsystemSpecification
«requirement»
id#102
txtThe vehicle shall stop from60 mph within 150ft on aclean dry surface.
Stopping Distance
«requirement»
id#337
txtThe Braking subsystem shallprevent wheel lockup underall braking conditions.
Anti-Lock Performance
req [Package] Vehicle Specifications [Braking]
«deriveReqt»
3. Requirements
bdd [Package] Vehicle [ABS]
«Block»Library::
ElectronicProcessor
«Block»Anti-LockController
«Block»Library::
Electro-HydraulicValve
«Block»TractionDetector
«Block»Brake
Modulator
d1 m1
definition
Gripping Slipping
Los sOfTrac tion/
RegainTrac tion/
stm Tire [Traction] state machine
Detect Loss OfTraction
TractionLoss ModulateBraking Force
act PreventLockup activity/function
Structuree.g., system hierarchies, interconnections
behavior
e.g., function-based behaviors, state-based behaviors
Propertiese.g., parametric models, time variable attributes
Requirements
e.g., requirements hierarchies, traceability
©2008, ARTiSAN Software Tools 21
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 21
SysML Diagram Frames
• Each SysML diagram represents a model element• Each SysML Diagram must have a Diagram Frame• Diagram context is indicated in the header:
– Diagram kind (act, bdd, ibd, seq, etc.)– Model element type (activity, block, interaction, etc.)– Model element name– Descriptive diagram name or view name
• A separate diagram description block is used to indicate if thediagram is complete, or has elements hidden
Header
Contents
Diagram Description
Version:Description:Completion status:Reference:(User-defined fields)
«diagram usage»
diagramKind [modelElementType] modelElementName [diagramName]
©2008, ARTiSAN Software Tools 22
Introduction to SysML
Slide 22
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
RequirementsRequirements
©2008, ARTiSAN Software Tools 23
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 23
The Requirements Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
The Requirements diagram sits out side the Structure/behavior organization of theremaining SysML diagram types.
©2008, ARTiSAN Software Tools 24
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 24
What are Requirements?
• Statement of a customer’s needs andexpectations
• Describes the essential characteristics of thecustomers goals
• Requirements should be problem based and notdescribe the solution. However, if there aresolution based elements in the requirements,these must be modelled and included in thesolution.
©2008, ARTiSAN Software Tools 25
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 25
The SysML Requirements DiagramWhat is it used for?
• The Requirements diagram can be used for a varietyof purposes throughout the system lifecycle:– Traditional text requirements and their properties (e.g., id,
statement, criticality, etc)– Grouping a set of requirements in a package– Breaking down requirements into constituent elements– Demonstrating traceability between derived and source
requirements– Showing which design elements satisfy which requirements– Verification of a requirement, or design element by a test case– Rationale for all of the above
How the requirements diagram is used will vary depending on the industry,company, project, and process. It’s main strength is in its ability to graphicallyrepresent requirements and how they pertain to the rest of the UML model.
©2008, ARTiSAN Software Tools 26
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 26
Requirements
• A requirement “specifies a capability or condition that must (orshould) be satisfied” [SysML]
• Can specify function to be performed or performance criteriato be met
• Basic attributes of a Requirement– ID: A unique identifier for the Requirement– Text: A Description of what is Required.
• Users can create stereotypes and tags to add specificproperties, e.g.
– Requirement type (Performance, Safety, Functional, etc.)– Criticality– Test method– Status– Etc.
«requirement»
txtThe System shall do...
reqtTypefunction
REQ_A1
©2008, ARTiSAN Software Tools 27
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 27
SysML Requirements DiagramElements
Design Elements
Model Element CModel Element C
Model Element T
Model Element A
«testCase»Model Element B
«requirement»
txtThe System shall do...
reqtTypefunction
REQ_A1
«requirement»REQ_A1.1
«requirement»REQ_A1.2
«requirement»REQ_B1
«requirement»REQ_C
«rationale»explanation
«problem»description of problem
«requirement»
derivedFromREQ_A1.1
req Requirement Diagram 1
«deriveReqt»
«refine»
«trace»
«satisfy»
«verify»
Requirement
Callout
Containment
«requirement»
txtsame text
REQ_D
«copy»
The requirement diagram shows both requirements and the different types ofrelationship that can be specified between them.Requirement properties (such as the textual description) can be shown ifrequired.Containment (sometimes referred to as ‘flowdown’) is used to show whererequirements are decomposed into sub-requirements.
The «deriveReqt» and «copy» relationships can only exist betweenrequirements. «trace», «refine», «satisfy» and «verify» can exist between arequirement and any other model element.
The «verify» relationship can only exist between a requirement and a behavioralmodel element stereotyped as a «testCase».An alternative to these direct relationships is to use the callout notation – onlyone example of the callout notation is shown here.«problem» and «rationale» comments can be added as required to any modelelement to capture issues and decisions.
©2008, ARTiSAN Software Tools 28
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 28
SysML Requirements DiagramExample
«activity»Distill Water
«UseCase»Distill Water
«requirement»
txtThe system must be ableto connect directly tomains water
Water Input
«requirement»
txtDistill dirty water into pure water
Produce Distilled Water
«requirement»
txtThe pure water outputmust be at a safetemperature
Water Output
«requirement»
txtThe system shall handle1 litre of water per minute
Water Throughput
Customer Brochure
«requirement»
txtThe system shall have aninput valve that is closedwhen the system is off
Provide Input Protection
«requirement»
txtThe system must have anoverflow valve in the mainheating vessel
Handle Overflow
«requirement»
txtThe condenser needs tocool the pure water to 30°C
Condenser Efficiency
«refine»
«satisfy»
«trace»
«deriveReqt»
«deriveReqt»
«deriveReqt»
«rationale»Analysis of this activityshow s that the throughputis possible
«rationale»Direct connection to highpressure mains w hen thesystem is off might causedamage
«rationale»High pressure w ater mayoverpow er the boiler soan overflow valve isneeded
«rationale»30 ° is deemed a safeoutput temperature
req [package] UserRequirements
©2008, ARTiSAN Software Tools 29
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 29
Problem and Rationale
Problem and Rationale can be attached to anyProblem and Rationale can be attached to anyModel Element to Capture Issues and DecisionsModel Element to Capture Issues and Decisions
©2008, ARTiSAN Software Tools 30
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 30
An Automotive Example
The Business Process
The Business Case
Marketing have identified a niche in the market for a mid-range engine, high-specification vehicle(Named: XSV-2001). The eventual cost of the vehicle will be in the range of £16K-£20K, with aproposed launch date of Spring 2003. Finance have made £300K available for Conception andDevelopment (including any re-tooling and training on the production line). The estimated profit marginis 10%-15% per production unit. Minimal changes will be made to existing production lines and tooling,and maximum use of existing components is mandated. A review wil l be held in 4-months todetermine ‘go-ahead’ of Development (and subsequent) phases. Target market: Executive Fleet andFamily.
Feature-Set
StandardFront-Wheel Drive, Front-engine, 5-Door (hatch-back), 5-Seat three-point inertial seat -belts (standardoptions of colour & cover); 1999ccm Variable Valve Control Petrol Engine; Integrated Traction &Cruise Control; Engine Management System (EMS) (including both Control and Diagnostics);Advanced Breaking System (ABS); Electric Windows & Seat Adjustment and Heating (Front seatsonly, Front windscreen only); …Optional:Front and Rear proximity sensors (including distance read-out and audio warning); GPS NavigationSystem (including audio instructions); (Sports Option) Engine Management System; …
The Business Case
Will specify the Requirement for a System (e.g. a Car)
May include (solution-based) capabilities of the System (e.g. CruiseControl, EMS, ABS)
May include Constraints (e.g. Cost, Time, Component Reuse, Tooling)
The Business Case defines that a ‘System’ is required and defines therequirements of the ‘System’ from the Business perspective. This will includesome high-level decisions regarding the ‘Systems’ Capabilities and Usage. TheBusiness Case will also identify business-level Constraints e.g. Development andProduction time and cost limits.
©2008, ARTiSAN Software Tools 31
Introduction to SysML
Slide 31
Introduction to SysMLIntroduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights Reserved
SysML StructureSysML Structure
©2008, ARTiSAN Software Tools 32
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 32
Block Diagrams
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
©2008, ARTiSAN Software Tools 33
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 33
Blocks are BasicStructural Elements
• Provides a unifying concept to describe the structure of anelement or system
– Hardware– Software– Data– Procedure– Facility– Person
• Multiple compartments can describe the blockcharacteristics
– Properties (parts, references, values)– Operations– Constraints– Allocations to the block (e.g. activities)– Requirements the block satisfies
©2008, ARTiSAN Software Tools 34
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 34
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
©2008, ARTiSAN Software Tools 35
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 35
Using Blocks
• Based on UML Class from UML Composite Structure– Eliminates association classes, etc.– Differentiates value properties from part properties, add nested
connector ends, etc.
• Block definition diagram describes the relationship amongblocks (e.g., composition, association, classification)
• Internal block diagram describes the internal structure of ablock in terms of its properties and connectors
• Behavior can be allocated to blocks
Blocks Used to Specify Hierarchies and InterconnectionBlocks Used to Specify Hierarchies and Interconnection
©2008, ARTiSAN Software Tools 36
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 36
bdd [Package] Block Defintion Diagram [bdd- Notation]
«Block»::Block1
«Block»
partsmyPart : Block4refParts : Block6 [*]sharedPart : Block5 [0..1]
referencesrefParts : Block6 [*]
valuesaValue : ValueType1
Block2
«Block»::Block1::Block3
«Block»Block4
«Block»Block5
«Block»Block6
«ValueType»
dimensionDimension1
unitUnit1
ValueType1
Actor1
1
1
myPart 0..1
1
sharedPart
*1refParts
11
Block Definition Diagram (bdd)Notation
Generalization
Namespacecontainment
Referenceassociation
SharedassociationPart
association
Multiplicity
Compartments
Part (role)names
Examples of blocks, and part, reference and value properties are shown here. Thegeneralization relationship indicates that Block 2 inherits properties of Block 1. Thereference association is used to indicate which parts are reference parts. A partassociation shows exclusively owned parts, a shared association indicates parts sharedwith other blocks. Multiplicity values indicate the number of parts.
©2008, ARTiSAN Software Tools 37
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 37
ibd [Block] Block2 [ibd Notation]
«Block»Block2
«BlockProperty»myPart : Block4
fPort1
fPort3
«BlockProperty»0..1
sharedPart : Block5
fPort2
sPort
«BlockProperty»
*
refParts : Block6
fPort4
Actor1
pI/F
rI/F
ItemFlow1 : ItemType«ItemFlow»
ItemFlow3 : DataType2«ItemFlow»
ItemFlow2 : ValueType1«ItemFlow»
Internal Block Diagram (ibd) Notation
EnclosingEnclosingBlockBlock
ConnectorConnector
PortPort
Item FlowItem Flow
Internal Block Diagram SpecifiesInternal Block Diagram SpecifiesInterconnection of PartsInterconnection of Parts
ReferenceReferencePropertyProperty
(in, but not of)(in, but not of)
PartPart
Note the consistency between this ibd and the previous bdd (part names, typesand multiplicities).
©2008, ARTiSAN Software Tools 38
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 38
Parts
• A Part is a property of a block that the block requiresin order to exist
• Used to illustrate the hierarchical composition of asystem and its components
• A part is normally typed by a block and representsan instance of that type within its enclosing block
• A referenced property is a part not owned by itsenclosing block, but referenced by some other partof that enclosing block
©2008, ARTiSAN Software Tools 39
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 39
SysML Port
• Specifies an interaction point on a block or a part– Supports integration of behavior and structure– Linked by a connector to one or more other ports
• Port types– Standard (UML) Port
• Specifies a set of operations and/or signals• Typed by a (UML) interface
– Flow Port• Specifies 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
©2008, ARTiSAN Software Tools 40
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 40
Port Notation
«BlockProperty»part1 sp1sp1
«BlockProperty»part2sp2sp2
«BlockProperty»part1
fp1 : ItemType1fp1 : ItemType1«BlockProperty»
part2
fp2 : ItemType1fp2 : ItemType1
«BlockProperty»part1
fp3 : FlowSpec1fp3 : FlowSpec1«BlockProperty»
part2
fp4 : FlowSpec1fp4 : FlowSpec1
Interface1 Interface1
Standard PortStandard Port
Atomic Flow PortAtomic Flow Port
NonNon--atomic Flow Portatomic Flow Port
Standard ports are typed by one or more interfaces. A provided interface (lollipop)specifies the services provided through the port; a required interface (cup) specifiesrequired services.
Note the consistency of direction of the atomic flow ports.
Flow port syntax is ‘name : type’, but what is actually shown may be either or both.
©2008, ARTiSAN Software Tools 41
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 41
Unit and Item Types
• Unit typesnormally basedon Real
• SI Units andDimensionsdefined in SysMLappendix
«block»
valueslh : J/kg = 520m : kg = 0press : Pash : J/kg/°C = 1t : °C
H2O
«block»
valuesQ : J
Heat
«block»
valueslh : J/kg = 520press : Pash : J/kg/°C = 1t : °C
Residue
«block»
valueslh : J/kg = 520press : Pash : J/kg/°C = 1t : °C
Fluid
«block»
valuesp : W
Electricity
bdd [package] Items
«valueType»
dimension = massunit = kilogram
kg
«valueType»
dimension = temperatureunit = degrees Centigrade
ºC
«valueType»
unit = Joules
J
«valueType»
unit = kilograms/second
kg/s
«valueType»
dimension = pressureunit = kilograms/square meter
kg/m²
bdd Units
©2008, ARTiSAN Software Tools 42
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 42
Port Typing
• An atomic flow specifies a single item that flows in our out.• A “flow specification” lists multiple items that flow.
«flowSpecification»
flowPropertyListin FuelSupply : Fuelout FuelReturn : Fuel
FPump-ICE
«flowSpecification»
flowPropertyListin TorqueIn : Torqueout TorqueOut : Torque
TorqueSpec
«valueType»Analogue
«flowSpecification»
flowPropertyListin Value : V
Digital
«Interface»EMU Msg
Send ()
«Interface»Set Throttle
Set Throttle ()
«block»
valuesMassFlowRate : gm/secPress : kg/m²Temp : °C
Liquid
«block»
valuesMassFlowRate : gm/secPress : kg/m²Temp : °C
Fuel
«valueType»°C
«valueType»kg/m²
«valueType»gm/sec
«valueType»SysML Extras::SI Unit Types::A«Interface»
TransmIF
Gear ()
Temp
Press
MassFlowRate
bdd [package] Flow Specifications
FlowFlowSpecificationSpecification
InterfaceInterface
BlockBlock Value TypeValue Type
©2008, ARTiSAN Software Tools 43
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 43
Delegation Through Ports
• Delegation can be usedto preserve encapsulationof block
• Interactions at outer portsof Block1 are delegatedto ports of child parts
• Ports must match (samekind, types, direction etc.)
• (Deep-nested)Connectors can breakencapsulation if required(e.g. in physical systemmodelling)
Child2:
Child1:
ibd [block]Block1[delegation]
©2008, ARTiSAN Software Tools 44
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 44
Connectors and Flows
«BlockProperty»Part 1 : Block B
fp1 : FlowSpec1fp1 : FlowSpec1 «BlockProperty»Part 2 : Block C
fp2 : FlowSpec1fp2 : FlowSpec1
ItemFlow1 : DataType1«ItemFlow»ItemFlow1 : DataType1«ItemFlow»
Flow Ports –type specifieswhat can flow
in/out
Item Flow -Specifies what
does flow(in context)
Connector
«FlowSpecification»
flowPropertyListin FlowProperty1 : Block3out FlowProperty2 : DataType1inout FlowProperty3 : ValueType2
FlowSpec1
A connector is a link between parts that enables communication between them.The flow ports, through their type, define what sort of things can flow across theconnector. This can be discrete items such as a data packet or an interrupt, orcontinuous flows like heat or fluids. What does actually flow in the specificcontext of a specific diagram is specified by one or more item flows, whose typemust be consistent with that of the flow ports.
©2008, ARTiSAN Software Tools 45
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 45
Structure vs. Usage
Definition– Block is a definition/type– Captures properties, etc.– Reused in multiple contexts
Usage– Part is the usage in a
particular context– Typed by a block– Also known as a role
Block Definition Diagram Internal Block Diagram
©2008, ARTiSAN Software Tools 46
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 46
Block Definition DiagramExample
• Parts compartmentshows structural children
• Values compartmentshows properties of theblock
• Flowports compartmentdescribes the interfaceto the block
• Operations compartmentshows functionalcapabilities (a means ofinvoking block activities– dealt with later)
bdd [Package] Distiller [Structure - with compartments]
«Block»
operationsTurnOn ()TurnOff ()
partsbx1 : Boilercx1 : Controllerdrain : Valvefeed : Valvehx1 : Heat Exchangerui1 : Control Panel
flowPortListout DSClean_Out : H2Oin DSDirty_Out : H2Oout DSExcess : H2Oin DSPower_In : Powerout DSResidue_Out : Residue
Distiller
«Block»
valuesMax : tempMin : temp
flowPortListout BLExcess : H2Oin BLHotDirty_In : H2Oin BLPower_In : Powerinout blrSig : blrSigout BLSteam_Out : H2Oout BLSteam_Out2 : Residue
Boiler
«Block»
flowPortListin Feed_HotDirty_In : H2Oout Feed_HotDirty_Out : H2Oin Fluid_In : Fluidout Fluid_Out : Fluid
Valve
«Block»
valuestempGradient : Real
flowPortListout HEClean_Out : H2Oin HEDirtyIn : H2Oout HEHotDirty_Out : H2Oin HESteam_In : H2O
Heat Exchanger
«Block»Control Panel
«Block»
operationspwrOn ()ResidueTimer ()DrainTimer ()shutDown ()
Controller
User
bx1
drain
hx1
1
1
feed
1
1
ui1
1
1
cx1
11user
The block definition diagram (bdd) shows block properties. Which specific blockproperties are shown is down to the choice of the modeler.
Parts (part properties) are normally shown using the UML composition relationship (thefilled in diamond), where the role names at the other end of the relationship specify thepart name (the block name at that end specifying the type). Part properties can also beshown in the Parts compartment of the containing block.
The Values compartment can be used to show any values (and their type) relevant to theblock.
The Flowports compartment (if shown) will list all flowports created on an internal blockdiagram (ibd) for the block or parts typed by the block.
The Operations compartment (if shown) will list all block operations. An operationspecifies a functional capability of the block, and acts as a means through which blockactivity can be invoked. This topic is dealt with in greater detail later in the course.
©2008, ARTiSAN Software Tools 47
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 47
ibd [block] Distiller
IBD for Distiller
• Non-Atomic Flow Ports (BC and HEC)– I/O is specified using FlowSpecification– FlowSpecification consists of properties
stereotyped «FlowProperty»– isConjugate promotes reuse of
flowSpecifications
• Atomic FlowPorts (dirtyWater,extPower …)
– In this case the port is directly typed bythe item type (Block or ValueType)
– Direction property specifies thedirection of flow
block Distiller
PureWater
loPressResidue
dirtyWater
hx :HeatExchangerfIn : Fluid
pFOut
HEC
tempWrn
bl : Boiler
SOut
BC
excess
blWrn
PwrIn
Rcnt
Ocntcontroller : Controller
ui
vO
vD
wrn
pwrIn
blrPwr
vI
UI : FrontPanelcnt
User
overFlow
extPower
inValve :FlowValveip
op
cnt
UserIO
ILamp
IPower
IValve
IValve
ILamp
IPower
IValve
IValve
IValve
IValve
waterOut : H2O
blSteamOut : H2O
hxWaterOut : H2O
PowerIn : Electricity
RegPower : Electricity
waterIn : H2O
Excess : H2O
blSludgeOut : Residue
« problem»Overflow water isvery hot!
©2008, ARTiSAN Software Tools 48
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 48
Internal Block Diagram Example 2 :Drill-down to show Boiler internals
ibd [Block] Boiler [drill down]
«Block»Boiler
«BlockProperty»heater : Element
ELPower_In : Power
ELHeat_Out : Heat
«BlockProperty»tank : Heating Vessel
HVHeat_In : HeatHVHotDirty_In : H2O
HVSteam_Out : H2O
HVSludge : Residue
HVExcess : H2O
BLHotDirty_In : H2O
BLSteam_Out : H2O
BLSteam_Out2 : Residue
«BlockProperty»vOverFlow : Valve
Fluid_In : FluidFluid_Out : Fluid
«BlockProperty»vResidue : Valve
Fluid_In : Fluid
Fluid_Out : Fluid
BLPower_In : Power
BLExcess : H2O
«BlockProperty»heater : Element
ELPower_In : Power
ELHeat_Out : Heat
ELPower_In : Power
ELHeat_Out : Heat
«BlockProperty»tank : Heating Vessel
HVHeat_In : HeatHVHotDirty_In : H2O
HVSteam_Out : H2O
HVSludge : Residue
HVExcess : H2O
HVHeat_In : HeatHVHotDirty_In : H2O
HVSteam_Out : H2O
HVSludge : Residue
HVExcess : H2O
BLHotDirty_In : H2O
BLSteam_Out : H2O
BLSteam_Out2 : Residue
«BlockProperty»vOverFlow : Valve
Fluid_In : FluidFluid_Out : Fluid
Fluid_In : FluidFluid_Out : Fluid
«BlockProperty»vResidue : Valve
Fluid_In : Fluid
Fluid_Out : Fluid
Fluid_In : Fluid
Fluid_Out : Fluid
BLPower_In : Power
BLExcess : H2O
• Shows parts (structural children) …• … and ports (interaction points on
block and parts)
• Supports consistency of ‘layers’
The ports on the (enclosing) Boiler block can be automatically populated on thisdiagram from the information on the previous diagram.
©2008, ARTiSAN Software Tools 49
Introduction to SysML
Slide 49
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Use CasesUse Cases
©2008, ARTiSAN Software Tools 50
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 50
SysML Use Case Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
The Use Case diagram in SysML is used to capture aspects of behavior.
©2008, ARTiSAN Software Tools 51
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 51
Use Cases
• Provide means for describing basic functionalityin terms of usages/goals of the system by actors
• Common functionality can be factored out viainclude and extend relationships
• Generally elaborated via other behavioralrepresentations to describe detailed scenarios
• No change to UML
©2008, ARTiSAN Software Tools 52
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 52
Use Case Diagram
Flight Crew
Navigator
Pilot
Air-To-AirTracking
Air-To-GroundStrike
WeatherMonitoring
ActorGeneralisation
Actor SubjectBoundary
Use Case
Subject Nameuc Diagram Name
The subject may be the entire system or a component of that system.SysML syntax use the prefix ‘uc’ followed by the name of the diagram in theouter frame.
©2008, ARTiSAN Software Tools 53
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 53
What is a Use Case?
*
• Use Cases describe the goals that actors have in relationto the system.
• A Use Case meets a need or solves a problem for anactor.
• So, what is an Actor ?
• An Actor is an entity which is eternal to the system, whichinteracts with the system, but is not a part of the system.
• Actors should reflect the entire system lifecycle including:manufacture, test, installation, maintenance, etc.
©2008, ARTiSAN Software Tools 54
Introduction to SysML
An actor is “anything outside the system to which the system interfaces”. Thismay be a person, an external system or item of equipment, or some more abstractconcept such as time.
Examples:
Person - Pilot, Operator, Maintainer, etcExternal System - EPOS, Mainframe, etc
Time - Timeouts, Scheduled events
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 54
What is an Actor?
A Person
An ExternalSystem
Abstractsuch as Time
*
Expected Actors Unexpected Actors
UnauthorizedUsers
AdverseEnvironmentalConditions
Threats
©2008, ARTiSAN Software Tools 55
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 55
What is a Use Case?
• Defines how the actors interact with the system
– Functionality triggeredby an actor(Primary Actors)
– Functionality usedby an actor
– Functionality in whichan actor participates(Secondary Actors)
Local operator
MonitorSystem
RemoteOperator
ShutdownPlant
Customer KioskOperator
FuelTransaction
©2008, ARTiSAN Software Tools 56
Introduction to SysML
A primary actor uses the system to achieve one or more specific goals. A use casespecifies what the system must do to satisfy a goal. Primary actors often initiatethe use case that delivers the goal.
It may be necessary for other actors to interact with the system in some well-defined manner in order for the primary actor’s goal to be realized by the system.These are referred to as secondary actors.
Stereotypes can be used to indicate primary or secondary actors.
An actor represents a role played by a user of the system. This is particularlyrelevant where the actor is human; the same person may be capable of playingmore than one role with respect to the system. This situation may also imply arequirement for access controls to use case functionality.
The UML Generalization relationship (shown using the triangle notation) can beused to indicate a situation where one actor inherits the same set of use caseinteractions shown for another actor. The specialized actor normally also hasadditional use case interactions.
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 56
Actor Characteristics
• Primary actor– Main beneficiary of use case– Normally initiates use case
• Secondary actor– Has interaction responsibilities, but does not initiate
*
• Actors represent ‘roles’– operator, supervisor, …
• Generalization of actors– indicates inheritance of
use case interactions
Operator«Primary»
Event LogSystem
«Secondary»
Supervisor
Start LocalSystem
RunDiagnostics
©2008, ARTiSAN Software Tools 57
Introduction to SysML
It is very important to describe each use case thoroughly and in simple English.This description should be signed off by the user. This description also acts as astarting point for a more structured breakdown of the use case in later stages ofdevelopment. For this it can be useful if the description employs a ‘subject - verb- object’ format, e.g. ‘customer inserts card’.
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 57
Use Case descriptions specifydetails
Automated Teller Machine
Withdraw Cash
Transfer FundsDeposit FundsCustomer
Use Case: Withdraw CashWhen a customer inserts a card, the machine readsthe code from the card and checks if it is anacceptable card. If so it asks the customer for a PINcode (4 digits). If not, the card is ejected.
When the PIN code is received the machine checkswhether the PIN code is correct for the specificcard. If so, the machine asks for what transactionthe customer wishes to perform.
When the customer selects cash withdrawal themachine asks for the amount. Only multiples of $20are allowed. ...
Use Case: Withdraw CashWhen a customer inserts a card, the machine readsthe code from the card and checks if it is anacceptable card. If so it asks the customer for a PINcode (4 digits). If not, the card is ejected.
When the PIN code is received the machine checkswhether the PIN code is correct for the specificcard. If so, the machine asks for what transactionthe customer wishes to perform.
When the customer selects cash withdrawal themachine asks for the amount. Only multiples of $20are allowed. ...
*
• Other Attributes– Pre-conditions– Post-conditions
(Guarantees)– Constraints– Intent– Alternate courses– Stakeholders– Priority– Complexity
©2008, ARTiSAN Software Tools 58
Introduction to SysML
Basic use cases specify the main services the system provides for its actors,ignoring exception situations. Subordinate (to their base use cases) use cases canbe specified for specifying exception handling or for specifying functionalactivity duplicated within more than one use case.
We can show the relationships between any subordinate use cases and their baseuse cases on the use case diagram.
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 58
A single goal may requiremore than one Use Case
• Focus initially on the basic Use Cases– The goals for each actor– Fundamental services, ignoring exceptions
• ‘Withdraw Cash’
• Consider optional Use Cases separately– Subordinate, alternate services– Often error or exception handling
• ‘Wrong PIN code’
• Look for repeated functionality– Subordinate, duplicated functional activity– Occur in more than one use case
• ‘Validate PIN code’
• Use Case organization defined by three types of relationship:– «extend» relationship– «include» relationship– Generalization relationship
*
©2008, ARTiSAN Software Tools 59
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 59
«include» relationship extractscommon courses of action
• Common behavior may be extracted from otheruse cases
• Defines a ‘must be done’ relationship
• Simplifies change
*
Card Validation
TransferFunds
WithdrawFunds
Deposit Funds
«include»«include»
«include»
An «include» relationship can be thought of as a subroutine type of relationship.In order to Withdraw Funds, Transfer Funds or Deposit Funds, it is essential tocarry out a Card Insertion.
©2008, ARTiSAN Software Tools 60
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 60
«extend» relationship modelsoptional courses of action
• Model an optional part of a usecase
• Allows introduction of separatesub-courses without affectingcourse of activity in base usecase
• Defines a ‘may get done’relationship
Bank CardTransaction
Reject InvalidCard
«extend»
In the example we have shown a base use case (Bank Card Transaction) and asubordinate ‘extended’ use case (Reject Invalid Card). Reject Invalid Card willonly be invoked from Bank Card Transaction in exceptional circumstances.
©2008, ARTiSAN Software Tools 61
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 61
Generalisation relationshipmodels specialized Behavior
• Child use cases inherit from parent use case
• Child use cases can extend behavior of parent
Operator
PowerSupply
InitializeSystem
Power UpInitialization
OperatorReset
A generalization relationship between use cases implies that the child use casecontains all the attributes, sequences of behavior, and extension points defined inthe parent use case, and participates in all relationships of the parent use case.The child use case may also define new behavior sequences, as well as addadditional behavior into, and specialize existing behavior of, the inherited ones.One use case may have several parent use cases and one use case may be a parentto several other use cases.
It is often possible to use «include» or «extend» relationships in place ofgeneralization.
©2008, ARTiSAN Software Tools 62
Introduction to SysML
A Use Case defines a service provided by a computer system for an actor. Forinstance, in using a word processor, some use cases would be :
– Make the text bold;
– Create an index;– Spellcheck the document;
The properties of a Use Case are that they :
– describe some coherent system function;– may be large or small;
– achieve a discrete goal for the actor;
Other possible properties include :– specifying actor intention in using the system;
– capturing pre- and post-conditions;
– defining alternate courses to the main flow of actions;
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 62
Use Cases
Use Cases• Use Cases specify, satisfy, realise,
and/or encapsulate functionalrequirements
• Provide efficient communicationmechanism between end users
and developers.• Provide a basis for design activity.• Use Cases define system requirements, and therefore system
test requirements• Define how a goal succeeds or fails.• Provide a framework for constraints and modes models.
Use Cases define testable system requirements froman external perspective
Use Cases define testable system requirements froman external perspective
Use Case Name
©2008, ARTiSAN Software Tools 63
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 63
Typical Use Cases
Local operator
RemoteOperator
AmmoniaSystem
Handle Alarm
StopCompressor
Start Up Plant
ShutdownPlant
Maintain GasPressure
StartCompressor
«include»«include»
«include»
«include»
«include»
«extend»
«extend»
«extend»
©2008, ARTiSAN Software Tools 64
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 64
Systems Engineering Use Cases
Local operator
RemoteOperator
AmmoniaSystem
Power
Maintainer
SystemInstaller
SafetyEngineer
Start Up Plant
ShutdownPlant
Maintain GasPressure
Power On Power Fail
CalibrateSensors
Replace SystemComponents
Install System
Run SiteAcceptance Tests
Power Off
AlarmVerification Tests
MonitorSystem
SafetyInspection
«include»
«include»
©2008, ARTiSAN Software Tools 65
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 65
Use Case Organisation
Multiple-Levels of Use Cases
Use Case Diagrams can be organisedaround different levels of abstractionfrom the ‘System of Systems’ perspectiveall the way to Use Cases supported by aspecific Sub-System.
Organisation by Domain
The lowest level of abstraction (i.e. theSub-System level) encapsulates all theservices (Use Cases) provided by aspecific domain.
Pilot«Primary Actor»
Mission Plan
«Secondary Actor»
Commander«Secondary Actor»
Navigator«Primary Actor»
Bombadier
«Primary Actor»«Equivalent»
Time
«Primary Actor»
Power
«Primary Actor»
Power UpCold
Store
Information
Load Mission
ContinuousBuilt-In Test
Communicate
ExecuteMission
Power UpBuilt-In Test
Power UpWarm
Power Up
Shutdown
«include»
«include»
«include»
«include»
«include»
«include»
«include»
See Execute Mission Use Case Diagram
SeeStore Information Use Case Diagram
Pilot«Primary Actor»
Navigator
«Primary Actor»Bombadier
«Primary Actor»«Equivalent»
Store Present
Position
Store NavigationInformation
StoreInformation
StoreTargetDestination
StoreSelectedWeaponType
StoreMarkpoint
Store Fix Error
On-TopFix HUD Fix
RADAR Fix
On-Top Mark
HUD Mark
RADAR Mark
StoreWeapons
Information
Bombadier Use Cases
NavigatorUse Cases
Any number of UseCaseDiagramscanbe created tokeep thediagramstidy. This diagram shows how different
types of informationcanbe storedwithin the system and by whom.
Systemof
Systems
System
Sub-System
Pilot
Deploy
Weapon
Store Target
Destination
Store Selected
Weapon Type
Store GeodeticPoint
«include»
«include»
«include»
©2008, ARTiSAN Software Tools 66
Introduction to SysML
Slide 66
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Activity DiagramsActivity Diagrams
©2008, ARTiSAN Software Tools 67
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 67
SysML Taxonomy of Diagrams
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
©2008, ARTiSAN Software Tools 68
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide68
Activity Modelling - Overview
• “Activity modelling emphasizes the inputs, outputs, sequences,and conditions for coordinating other behaviors.” (SysML)– ‘behavior’ as in something the system does– describes flow of activity and data– can link activity elements to owning block
• An activity diagram is owned by an activity and describes the detailof that activity
• Useful for many purposes, including:– Exploring system functionality– Human/subsystem communication modelling– Data/item flow modelling– General flow of control modelling– etc.
Activity modeling is one of the principal means for describing behavior inSysML. This behavior can be linked with structural modeling (blocks)through allocations which will be covered later in the course.
In practice, activity diagrams can be used for a surprisingly wide variety ofmodeling purposes. For systems engineering, exploring system functionalityis one of the principal uses of these diagrams.
©2008, ARTiSAN Software Tools 69
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide69
SysML Activity Modelling
• SysML activity modelling is based on, and inherits muchfrom, UML 2.0 activity modelling
• Key SysML extensions are :– Stronger semantics for activity decomposition– Control as data– Continuous systems– Probability
Although SysML adopts much of the UML activity model, in this sectionwe’ll consider SysML activity modeling as a ‘whole’, not distinguishingbetween which aspects are inherited and which are extensions.
©2008, ARTiSAN Software Tools 70
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 70
Activities
• Represent a unit of behavior– Specifies sequencing of subordinate actions– Can be parameterized
activityparameter
act name
initial node
activity final
action
decision
An activity is the specification of parameterized behavior as the coordinatedsequencing of subordinate units whose individual elements are actions.[UML]
©2008, ARTiSAN Software Tools 71
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 71
a2 : Activity 2 a3 : Activity 3
act [activity] Activity 1
Activity Decomposition
«activity»Activity 1
«activity»Activity 2
«activity»Activity 3
1
1
a21
1
a3
bdd Activity Breakdown
Definition Use
• Activity decomposition can be modeled on block definition diagrams• Allows initial functional decomposition independent of physical structure• Allocation of activities to blocks and parts can be done later
action name
An important aspect of SysML activity modeling is the principle thatactivities can be treated like classes or blocks with decomposition andassociation relationships modeled on a block definition diagram. The activitydiagram for that activity can then show instances of the sub-activities, whererole names on the bdd become the instance names on the activity diagram.
The meaning of activity decomposition is better defined in SysML (than inUML). For example, SysML specifies that if a composite activity isterminated then any currently executing ‘part’ activities are also terminated.
©2008, ARTiSAN Software Tools 72
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 72
Action Node
• Represents a single step within anactivity– not further decomposed– execution starts on entry to the action
node– and exit occurs when the execution is
completed
• ‘Callbehavior’ is a variant– an action node showing a behavior
invocation– typically a ‘part’ activity (activity
name may be hidden)– can be linked to a Block operation
action name : behavior name
action name
These are one of the principle components of activity diagrams. Each actionnode defines a single step within the owning activity.
Because activity diagrams can be used in a variety of situations, the wordingof the text can be whatever is best suited to the specific situation.
In general, actions are atomic (i.e. not further decomposed). Where theaction represents a complete sub-activity, typically a ‘part’ activity on a bdd,a Callbehavior action is used. This normally has both the bdd role name andthe part activity name displayed, although the latter can be hidden. Activitiescan be linked with Block operations – these operations are then themechanism through which the activity is invoked.
©2008, ARTiSAN Software Tools 73
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 73
Object Node
• Represents an instance of a block or data type– helps to define ‘flow’ in an activity (i.e. ‘what’ flows)– provides input to and/or is output from an action node– if composite part of activity, then destroyed when activity completed– multiplicity must include 0 – instance may not exist throughout activity
a2 : Activity 2 a3 : Activity 3
b1 : B lock1«Block»
dt1 : DataType1«DataType»
act [activity] Activity 1«activity»Activity 1
«Block»::Block1
«DataType»DataType1
«activity»Activity 2
«activity»Activity 3
0..1
1
b1 0..1
1
dt1
1
1
a2 1
1
a3
bdd Activity Breakdown - with objects
object node name
Object nodes allow the modelling of flow of elements through an activity.Activities can be associated with both blocks and data types as well as otheractivities to indicate what type of flow elements relate to the activity. Thiscan be by composition, where the flow element gets destroyed on completionof the activity.
©2008, ARTiSAN Software Tools 74
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 74
Control and Object Flows(Activity Edge)
• Control Flow– Solid or dashed arrow line showing flow of control– Not in to or out from object nodes– Can be named
• Object Flow– Solid arrow line linking objects to other elements– Can be named
Ac tion 1Object
Ac tion 2
Ac tion 1Object
Ac tion 2
Control flow Object flow
Object flow
Control flow
Control Flows are another key component of activity diagrams, providingsequencing information. Object flows are only ever used with object nodes.Both type of flows can be named if required.
Activity Edge is the formal name for both type of flow.
For those familiar with UML activity diagram modeling, note that thesolid/dashed convention is reversed in SysML.
©2008, ARTiSAN Software Tools 75
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 75
Pin vs. Object Node Notation
• Pins are kinds of Object Nodes– Used to specify inputs and outputs of actions– Typed by a block or data type
• Object flows between pins have two diagrammatic forms– Pins shown with object flow between– Pins hidden and object node shown with flow arrows in and out
ObjectNodePins (must be samename & type)
AJM4
Slide 75
AJM4 right-hand diagram should have action:activity like the left-hand one.Alan Moore, 5/17/2006
©2008, ARTiSAN Software Tools 76
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 76
• Accept Event– shows a signal that initiates activity in action node– may also link to action object (sender)
• Examples:
Send Signal and Accept Event
• Send Signal– shows a signal sent at completion of action node activity– may also link to action object (receiver)
Send Signal
Accept Event
re-open door
door interruptDoor
Signal send and accept event boxes correspond to the concept of a ‘signal’ eventon a state diagram. The ‘send’ represents a signal sent at completion of theactivity in the preceding action node; an ‘accept’ represents a signal that triggersthe activity of the subsequent action node.
A ‘send’ may also have an object flow going to the object that receives the signal;an ‘accept’ may have an object flow coming from the object that sends the signal.
Dragging an RtS event onto an activity diagram creates a send signal; itsproperties can then be used to change it to an accept event if required.
©2008, ARTiSAN Software Tools 77
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 77
Interruptible Activity Region
• A bounded region of activity thatcan be terminated prior tocompletion
regionboundary
interrupting event
interruptingedge
This feature, new to UML 2.0, allows you to explicitly identify areas of activitywhere interrupts are allowed to terminate the activity in the region beforecompletion.
In RtS the boundary is a frame box with View Options set to show dashed lines(strictly, it should have rounded corners). The interrupting edge is a control flowwith waypoints added.
©2008, ARTiSAN Software Tools 78
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 78
Activity Diagram – Model ElementsControl Nodes
• Coordinate flow in an Activity• Initial Node denotes start of flow in an Activity• Activity Final Node denotes end of flow in an Activity• Flow Final Node denotes termination of a flow
– No effect on other flows in the Activity
• Decision Node provides choice of outgoing flows– One incoming and multiple outgoing flows
• Merge Node brings together multiple alternate flows– Multiple incoming and one outgoing flows
• Fork Node splits a flow into multiple concurrent flows– One incoming and multiple outgoing flows
• Join Node synchronizes multiple flows– Multiple incoming and one outgoing flows
Control Nodes are activity nodes used to provide coordination between othernodes.
Note that an Activity Final Node denotes end of flow in the entire Activity,whereas a Flow Final Node only terminates one flow, and has no effect on otherflows (which might still be in effect) in the Activity.
The difference between a Decision Node and a Fork Node lies in the fact that in aDecision Node, a token arriving at the node will traverse only one of the multipleoutgoing flows, whereas in a Fork Node, the arriving token is duplicated acrossthe outgoing edges, each of which is traversed concurrently.
Similarly, a Merge Node is not used to synchronize multiple incoming flows, butto accept one among several alternate flows, whereas a Join Node synchronizesmultiple incoming flows.
©2008, ARTiSAN Software Tools 79
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide79
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.
©2008, ARTiSAN Software Tools 80
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 80
Nested Swimlanes
• Can be nested to any depth• Can link to model item
– uses model item name
Final Flow terminatesflow of activity in that
swimlane
©2008, ARTiSAN Software Tools 81
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 81
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.
©2008, ARTiSAN Software Tools 82
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 82
Explicit Allocation of Behaviorto Structure Using Swimlanes
Activity Diagram(without Swimlanes)
Activity Diagram(with Swimlanes)
©2008, ARTiSAN Software Tools 83
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 83
Other Activity Related Stereotypes
• «nobuffer»– applied to object nodes or parameters– indicates that items arriving at action may be lost
• «overwrite»– applied to object nodes or parameters– indicates that arriving item replaces previous item– valid also for FIFO/LIFO queues
• «optional»– applied to parameters– indicates that action may begin even without parameter arriving
• «rate»– applied to object flow or parameter– specifies rate at which items sent/received over object flow– or rate at which items arrive at parameter while action is executing
• requires {streaming} type parameter
These additional stereotypes are provided to bring greater detail into theSysML model. Full details are provided in the SysML spec..
©2008, ARTiSAN Software Tools 84
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 84
Probability
• «probability» stereotype applied tooutgoing edges (flows) from decision orobject nodes
• Defines value (range: 0 – 1) forprobability of any flow being taken– Total of values from one node must
equal 1
• Can also be applied to output parameterset from node– With same value constraints
action 1
action 2a action 2b
action 1
action 2a action 2b
«probability»«probability»p (x )
«probability»«probability»1-p(x )
When the «probability» stereotype is applied to edges coming out of decisionnodes and object nodes, it provides an expression for the probability that theedge will be traversed. These must be between zero and one inclusive, andadd up to one for edges with same source at the time the probabilities areused. When the «probability» stereotype is applied to output parameter sets,it gives the probability the parameter set will be given values at runtime.These must be between zero and one inclusive, and add up to one for outputparameter sets of the same behavior at the time the probabilities are used.[SysML]
©2008, ARTiSAN Software Tools 85
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide85
Activity Diagram – Distiller Example:Activity Structure
«Block»
valuescal/sec : dQ/dt
Item Types::Heat«Block»
valuesdegrees C : tempgm/sec : massFlowRatekg/gm^2 : press
Item Types::Residue
«Activity»Heat Water
«Activity»Distill Water
«Activity»Boil Water
«Activity»Condense Steam
«Activity»Drain Residue «Block»
Item Types::H2O
«BlockProperty» cal/gm : specificHeat
«BlockProperty» cal/(gm*deg C) : latentHeatRemove Latent Heat of Vaporisation ()Add Latent Heat of Vaporisation ()
1
1
hotDirty : H20
1
1
pure : H2O
1
1
recovered : Heat 1
1
hiPress : Residue
1
1
loPress : Residue1
1
external : Heat1
1
steam : H2O
1a1 : Heat Water
1 a2 : Boil Water
1 a3 : Condense Steam 1a4 : Drain Residue1
1
coldDirty : H2O
bdd [package]DistillerBehavior [Distiller Behaviour Breakdown]
©2008, ARTiSAN Software Tools 86
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide86
Activity Diagram – Distiller Example:Control-Driven: Serial Behavior
«effbd»act [activity] Distill Water [Serial Behavior]
coldDirty : H2O[Liquid]
recovered : Heata1 : Heat Water
a2 : Boil Water
a3 : Condense Steama4 : Drain Residue
external : Heat
pure : H2O[Liquid ]
loPress : Residue
steam : H2O[G as]
hotDirty : H20[Liquid ]
hiPress : Residue
coldDirty : H2O[Liquid]
recovered : Heata1 : Heat Water
a2 : Boil Water
a3 : Condense Steama4 : Drain Residue
external : Heat
pure : H2O[Liquid ]
loPress : Residue
steam : H2O[G as]
hotDirty : H20[Liquid ]
hiPress : Residue
fork
join
The «ephod» stereotype implies this activity conforms to the constraintsspecified for Enhanced Functional Flow Block Diagrams (a non-normativeSysML extension).
©2008, ARTiSAN Software Tools 87
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide87
Activity Diagram – Distiller Example:I/O Driven: Continuous Parallel Behavior
act [activity] Distill Water [Continuous Parallel Behavior]
pure : H2O[Liquid]
external : Heat
coldDirty : H2O[Liquid ] loPress : Residue
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid ]
steam : H2O[G as]
hiPress : Residue
pure : H2O[Liquid]
external : Heat
coldDirty : H2O[Liquid ] loPress : Residue
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid ]
steam : H2O[G as]
hiPress : Residue
©2008, ARTiSAN Software Tools 88
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide88
act [activity] Distill Water [Simultaneous Behavior with Allocations]
hx1
ShutDown
steam : H2O[G a s ]
«continuous»
hotDirty : H20[ L iquid]
«continuous»
recovered : Heat
a3 : Condense Steam«streaming»
a1 : Heat Water«streaming»
coldDirty : H2O[ L iquid]
«continuous»
external : Heat«continuous»
: Heat Exchanger
«allocate»drain
a4 : Drain Residue
pure : H2O[Liquid ]
«continuous»
loPress : Residue«continuous»
:V alve
«allocate»bx1
a2 : Boil Water«streaming»
hiPress : Residue«continuous»
: B o iler
«allocate»
Activity Diagram – Distiller Example:(Allocation with Swimlanes): DistillWater
Parts
©2008, ARTiSAN Software Tools 89
Introduction to SysML
Slide 89
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
InteractionsInteractions
©2008, ARTiSAN Software Tools 90
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 90
SysML Sequence Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
The Sequence Diagram is ‘re-used’ from UML and captures certain aspects ofbehavior.
©2008, ARTiSAN Software Tools 91
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 91
Usage Scenarios – Overview
• Usage Scenarios are created for two reasons:
– Understanding the requirements in more detail bycreating a model of the end-users problems (Modellingthe Problem)
– Typically however, after defining an initial SystemArchitecture and exploring the capabilities of thesystem (captured as Use Cases) you’ll want to see howthe capabilities are delivered by the components withinthe System Architecture (Modelling the Solution).
©2008, ARTiSAN Software Tools 92
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 92
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
©2008, ARTiSAN Software Tools 93
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 93
Descriptionpart a
:Block A
«Block»part b
:Block B
«Block»part c
:Block C
«Block»Actor1
seq signal1 {10ms}par
seq message 1 {250ms}loop
seq message 2break
seq
max.: {100ms}
message 2end loop
also par
alt
seq message 3seq message 4( param )
end alt
seq signal2end par
sd SD Concept
Sequence Diagrams
Describe usecase or scenariosequence
Specify timingbudgets andconstraints
Define loops andconditional pathsfor systemfunctionality
Demonstrateparallel andsynchronousfunctionality
©2008, ARTiSAN Software Tools 94
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 94
Interaction Fragment
• a ‘piece of interaction’ [UML] – e.g. part of asequence diagram
• no defined notation in UML/SysML• represented by an interaction frame in Studio
Loosely defined in the UML as ‘a piece of interaction’, it has no specifiednotation. In Studio we have made use of the ‘ interaction frame’ element to allowthe scoping of the required ‘piece of interaction’.
By default, the name given to the fragment is taken from the first description stepcovered by the frame, but it can be renamed.
©2008, ARTiSAN Software Tools 95
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 95
Sequence Diagram - Fragments
• A Fragment can be drawn around a set of interaction messages.
• Fragments are given default names (in italics) depending ontheir action:• Weak Sequencing (seq) denoting the order in which interactions
occur (most Sequence Diagrams are by default weakly sequenced).• Loop (loop) denoting a repeated order of interactions.• Alternative (alt) denoting a choice of behavior.• Strict Sequencing (strict) denoting a specific order of interactions.• Parallel (par) denoting that the fragment contains parallel execution
(used for concurrent systems).• Critical Region (critical) denoting an un-interruptible order of
interactions.• Option (opt) denoting execution of the fragment or not.• Break (break) denoting the contents of this fragment is executed
instead of the rest of the fragment.• Negative (neg) denoting an invalid order of interactions.• Reference (ref) another interaction diagram.
*
These default names can be replaced by something more meaningful if requiredin Studio.
©2008, ARTiSAN Software Tools 96
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 96
Sequence Diagram – ExampleFragments
Descriptionpart a
:Block A
«Block»part b
:Block B
«Block»part c
:Block C
«Block»Actor1
seq signal1 {10ms}par par
seq message 1 {250ms}loop loop
seq message 2break
seq
max.: {100ms}
message 2end loop
also par
alt altseq message 3seq message 4
end alt
seq signal2end par
sd SD Fragments
©2008, ARTiSAN Software Tools 97
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 97
Interaction Use
• a reference from a step on one sequence diagram to aninteraction (represented by another sequence diagram in Studio)
• allows partitioning of the interaction model – e.g. a single use casecan be split over several diagrams
This is a powerful facility within UML 2.0 that provides behaviouraldecomposition. With Studio an interaction use can be represented as a referenceframe linked to another diagram. The referenced diagram can be anothersequence diagram, or it can be an activity diagram, and it can be opened throughthe context menu of the frame.
©2008, ARTiSAN Software Tools 98
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 98
Part Decomposition
• a reference from an interaction entity (not necessarily a part) on onediagram to another diagram
• allows decomposition of the interaction model – e.g. the internalinteractions taking place within the entity, as a result of a message,can be shown separately
Similar in principle to an interaction occurrence, this form of decompositionreflects the structural decomposition represented on internal block diagrams.
In the above example the referenced ‘Start Boiler [detail]’ diagram would showthe interactions taking place between the component parts within the Boiler partof the Distiller in order for the Boiler part to implement the ‘powerOn’ operation.Typically then, there would be a internal block diagram (ibd) that would show theinteraction entities shown above with connectors consistent with the abovemessaging, and there would be another internal block diagram showing theinternal component parts of the Boiler and their connectors. It is these internalparts and their messaging that would be shown in the ‘Start Boiler [detail]’diagram.
©2008, ARTiSAN Software Tools 99
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 99
Part Decomposition - Example
Description:D istiller«B lock»
Distiller.ui1:Control Panel«B lockProperty»
Distiller.bx1:Boilerref Start Boiler
«BlockProperty»User
s tart up StartUps tart Dis tiller TurnOns tart Boiler powerOn
Description:Boiler«Block»
Boiler.heater:Element«BlockProperty»
Boiler.vOverFlow:Valve«BlockProperty»
Boiler.vResidue:Valve«BlockProperty»
power on boiler powerOnswitch on heater onopen overflow openopen residue open
sd Start Boiler
This example illustrates interaction modelling at 2 different levels of abstraction:black box (top diagram) and white box levels. The lower diagram is modellingwhat happens inside the boiler on receipt of the powerOn message.
Note the names of the various BlockProperty parts, indicating their parent block,as well as their block type.
©2008, ARTiSAN Software Tools 100
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 100
D escription:C ontrol P anel
«B lock»:C ontroller
«B lock»U ser
press s tart StartU pturn on Dis t iller pw rO n
show power onpwrLightON
wait for water to boil
show operating opLightONrepeat loop
alt altwater high hghLightON
els e altdraining drnLightON
els e alt
water low lowLightONend alt
unt il. . .
.. .pres s s top S hutD ow nturn off Dis t iller shutD ow nshow not operat ing
opLightOFFshow power off pwrLightOFF
seq O perate D istiller [U I Operations]
Identifying Block FunctionalRequirements with Use Case Scenarios
«Block»
operationspwrLightON ()opLightON ()hghLightON ()drnLightON ()lowLightON ()opLightOFF ()pwrLightOFF ()
Control Panel
• Messages implyneed for Blockoperations
• Block operationsdefine functionalrequirements forblock
• Operations canmap to actions
Operation callmessages
Operation call messages require corresponding operations to be supported by theblock typing the element owning the lifeline. Block operations can be linked withactions allocated to that block (e.g. via activity diagram swimlanes), whereby thearrival of the message triggers the action.
©2008, ARTiSAN Software Tools 101
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 101
Refinement through Iteration
*
Iterate
CandidateEntities
Use CaseDescription
SequenceDiagram
:Barrier Motor Red:Light
Green:Light
:Beam Sensor :Car Count:Controller:Pressure Sensor
entry beam detects car break {5ms}beam sensor signals controller car_arrived
controller checks for space isFull {5ms}If full
suspend entry Car WaitsEndIfopen barrier openturn off red light offturn on green light on
controller checks for space isFull {5ms}If full
suspend entry Car WaitsEndIf
suspend entry Car Waits
open barrier openturn off red light offturn on green light on
car passes through beam connectbeam sensor signals controller car_entered
increment car count incrementclose barrier closeturn off green light offturn on red light on
increment car count incrementclose barrier closeturn off green light offturn on red light on
car triggers pressure sensor detectpressure sensor signals controller car_exited
decrement car count decrementdecrement car count decrement
The principle of iteration is important not just in refining use cases and blocks,but also the ibds for blocks. For example, the messaging between the Controllerand the Control Panel shown in the previous slide, implies that the Controllerknows when the water level is high or low. This implies there must be someconnector between the Controller and the Boiler with appropriate ports and flowspec. – these would now be added to this ibd.
©2008, ARTiSAN Software Tools 102
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 102
Sequence Diagramversus Activity Diagram
• Both describe behavioural sequences– that can include control constructs and data flow– Sequence diagrams are message based
• Use when focus is on sequence of messages between system components• Or when timing information needs to be modelled• Messages can provide ‘events’ for state modelling (later)
– Activity diagrams are action based• Use when focus is on decomposition of activity
– not sensible to model the same behavior (e.g. a use case) with both
• Can link the two models– block operation can be defined for an activity action owned by that block– operations can be parameterized
• to show incoming/outgoing information• parameters show as action node pins on activity diagram, if action node
linked with operation in Studio
The choice whether to use activity diagrams or sequence diagrams to modelbehavior is not an easy one. It will largely depend whether you see it better tomodel action sequences or message sequences. It is unlikely that you will modelboth for a single aspect of behavior, such as a use case.
©2008, ARTiSAN Software Tools 103
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 103
Sequence Diagram andInternal Block Diagram
• Both can illustrate interaction between parts
• IBD provides ‘static’ view– Shows what can be sent, through port types– Shows what is actually sent, through item flows– Does not show why or when interaction occurs
• Sequence Diagram provides ‘dynamic’ view– Shows the ordering of the interactions– SysML does not allow item flows as messages– Studio does, as long as previously specified
It can be useful to see both a ‘static’ view of interaction (as shown on IBDs) and a‘dynamic’ view (as shown on sequence diagrams). A useful additional feature ofStudio is to allow item flows to be used as messages on sequence diagrams, aslong as their use has already been specified on the same parts on an IBD.
©2008, ARTiSAN Software Tools 104
Introduction to SysML
Slide 104
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
State MachinesState Machines
©2008, ARTiSAN Software Tools 105
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 105
SysML State Machine Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
The State Machine Diagram is re-used from UML and captures state-basedbehavior.
©2008, ARTiSAN Software Tools 106
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide106
State Machines - Overview
• Most embedded systems are state-based in behavior:– Even the simplest system will exhibit states of:
• Initialisation• ‘Doing Something’• Shutting Down
– More complex embedded systems may have:• Multiple sequential states (the system does multiple things in a specific
order).• Multiple concurrent states (the system does multiple things all at the
same time).• A mixture of the above…
• How do you document the required states of a system orone of its components?– Use a State Machine Diagram.– Almost identical to UML state machine semantics and notation.– State machine is child diagram of parent block.
State machine are used to specify the state-based behavior of a block. The blockmay correspond to a complete system or subsystem, or it may type a componentwithin a system/subsystem.
©2008, ARTiSAN Software Tools 107
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide107
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
©2008, ARTiSAN Software Tools 108
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide108
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
©2008, ARTiSAN Software Tools 109
Introduction to SysML
The UML state diagram provides a rich syntax for describing behavior. Thesubset illustrated on this slide is normally sufficient to describe the system-levelstate modelling. The following slides cover these modelling elements in moredetail. We’ll add a little detail later.
The ‘event [guard] / effect’ group is often referred to in Studio as an event-actionblock (EAB); an action being one type of effect (element of system behavior).
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 109
Main State DiagramModelling Elements
State 1 State 2
States
Transitions
event
Events
Effects
/ effect
*
Initial/Final States Guards
[guard]
©2008, ARTiSAN Software Tools 110
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide110
Events
• An ‘occurrence’ that may trigger potentialeffects
• Event types :– Signal - event name/
– Call – operation name/
– Time - after(time period)/
– Change - when(Boolean expression)/
– Entry - Entry/
– Exit - Exit/
– None - empty
Signal events represent the receipt of an asynchronous signal (e.g. the receipt of asignal message on a sequence diagram).
Call events represent the receipt of an operation call (a message arriving). Theoperation must belong to the block owning the state machine.
Time events model the expiry of a specified period of time. Timing starts onentry to the source state. Time events are identified by the use of the ‘after’keyword followed by the time period in brackets, e.g. after(200ms).A change event models the occurrence of a specified Boolean expressionbecoming true. Change events use the keyword ‘when’ preceding the Booleanexpression in brackets, e.g. when(a=0). Conceptually, change events arecontinuously evaluated.
An entry event is the event that completes an external transition and models theentry into the destination state. Entry events normally specify an effect (often as aset of actions) to be carried out when the event occurs, e.g.Entry/currentState=idle.
Similarly an exit event occurs at the start of a external transition and models theexit from the source state. It also normally specifies an effect, e.g. Exit/cleardisplay.
If no event is shown on a transition, the transition is deemed to be taken oncompletion of any activity within the source state.
©2008, ARTiSAN Software Tools 111
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide111
Transitions
external transitions
internal transition
• External transition– denotes exit from source state and entry to destination state– invokes Exit, transition and Entry effects
• Internal transition– no state transition– invokes transition effect(s) but not Exit/Entry effects
Transitions define the rules for responding to events.
External transitions are shown as an arrowed line running from the current(source) state to the new (destination) state. The source and destination statesmay be the same.
Internal transitions are represented by an event-action block within a state.Internal transitions will normally specify a set of actions to be carried out whenthe event (which may be guarded) occurs.
©2008, ARTiSAN Software Tools 112
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide112
Guard Conditions
• A Boolean expression associated with a transition
• Transition only occurs if expression evaluates to true
• Guards conditions are enclosed by square brackets [ ]and may or may not be preceded by an event
Guard conditions allow transitions to be executed conditionally.
If preceded by an event, the guard condition is evaluated when the event occursand the transition only takes place if true. Where a guard is shown without apreceding event, the condition is evaluated, while in the source state, wheneverany event occurs, and a transition takes place if true.
©2008, ARTiSAN Software Tools 113
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide113
Initial and Final States
State 1
/ init ial ac t ion
• Initial (pseudo)state• points to the entry state for a region of
a state machine• can have an initial action (effect)• only one permitted within any region of
a state machine
• Final State• Indicates completion of all state activity
for the region containing the final state• can be more than one in a region• can be named and show completion
action Final 1
/com pletion action
The term ‘region’ is used in the context of composite states (see later).
©2008, ARTiSAN Software Tools 114
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide114
stm [Block] H2O1Gas
Liquid
Solid
Remove Latent Heat of Vaporisation/
Add Latent Heat of Vaporisation/
Remove Latent Heat of Vaporisation/
Add Latent Heat of Vaporisation/
A Simple Example
Transitions
States
Events
A state machine for water.
©2008, ARTiSAN Software Tools 115
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide115
Junctions
• Allow merging of multiple incoming transitions to asingle outgoing transition
• Allow branching of single incoming transition intomultiple outgoing (guarded) transitions• can use [else]
junction
Although the above illustration is quite valid, it is also common to see a junctionused with several incoming transitions and only one outgoing one, or with onlyone incoming transition and several outgoing ones.
©2008, ARTiSAN Software Tools 116
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 116
stm [Block] Boiler
Heater On
Heater Off
OperatinghighResidue/open residue valvelowResidue/close residue valve
Heater On
Heater Off
when( temp=Max )/switch off heater
when( temp=Min )/switch on heater
powerOn/switch on heater
powerOff/switch off heater
Composite State - Sequential
Sequential State
Substates
Applies to all sub-states
UML defines a composite state as ‘a state that, in contrast to a simple state, has agraphical decomposition’.
Composite states can be considered to be of two types, Sequential andConcurrent.
Entry into a sequential state can be be specified either at the sequential state level(as illustrated), in which case one of its substates must be defined as the initialstate, or directly to a substate, where for example, you want to show differenttransitions going to different substates.
One of the benefits if using a sequential state here is that we can show the‘after(1min)’ once only, as an event-action block (EAB) of the sequential state.This now means that we can handle this event irrespective of which substate thesystem is in.
©2008, ARTiSAN Software Tools 117
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide117
Registering
Processing
Routing
Moving Idle
Scanning
Capturing data
Processing data
Routing
Moving IdleMoving Idle
Scanning
Capturing data
Processing data
Capturing data
Processing data
Concurrent States
join
concurrent state
region
forksynchstate
stm [block] Container
A concurrent state consists of two or more regions where each region describesconcurrent behavior. A concurrent state can be used to model a situation when anobject can be in two or more states simultaneously. In the above example acontainer can be scanned while it it being routed. Exit from the concurrentProcessing state occurs only when both regions are in their final states.
A synch state can be used to synchronize activity between regions. Here, forexample, we can only capture data after a movement step has completed andprevious data has been processed. It is possible to limit the number of outgoingtransitions from a synch state by setting a bound on the difference between thenumber of times incoming and outgoing transitions fire. The synch state has beendeprecated from UML 2.0 but will remain a part of Studio as it is an essentialconcept for capturing the synchronization mechanism (e.g. priority-ceilingprotocol) used in the synchronization of data between two concurrent stateregions.
Synchronization bars are used with synch states. There are 2 types of these, forkand join as illustrated above.
©2008, ARTiSAN Software Tools 118
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide118
doActivity
• An activity executed within a state
• May be continuous– until transition from containing state
• in which case activity is aborted
• May be of finite duration– completion triggers transition with no event
defined (if one exists)– or waits in state until transition event occurs
• Notation is ‘do : activityname’Operating
do : Boil Water
Activities have ‘significant’ duration whereas actions have ’insignificant’duration.
©2008, ARTiSAN Software Tools 119
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide119
More Complex Example
stm [block] Distiller Controller [Distiller States]
Off
Entry/pwrLightOFF
FillingEntry/Open Feed : IValve
Warming Up
Entry/bxHtrON
Distilling
Entry/bxHtrONControlling Boiler Level
Level OKEntry/Close Drain : IValve ;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level Low
Entry/Open Feed : IValve
Controlling Boiler Residue
Building Up ResidueEntry/Close Drain : IValve
Purging Residue
Entry/Open Drain : IValve
Controlling Boiler Level
Level OKEntry/Close Drain : IValve ;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level Low
Entry/Open Feed : IValve
Level OKEntry/Close Drain : IValve ;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level Low
Entry/Open Feed : IValve
Controlling Boiler Residue
Building Up ResidueEntry/Close Drain : IValve
Purging Residue
Entry/Open Drain : IValveBuilding Up Residue
Entry/Close Drain : IValve
Purging Residue
Entry/Open Drain : IValve
DrainingEntry/Open Drain : IValve
Cooling OffEntry/bxHtrOFF;Open Drain : IValve;Open Fill : IValve
pw rO n/
[NOT bxLevelLow]/
[bxTemp = 100degrees]/
[NOT bxLevelLow]/
[bxLevelLow]/
[bxLevelHigh]/
[NOT bxLevelHigh]/
/
DrainTim er/
Res idueTimer/
[bx LevelBelow]/[bxTemp < 100degrees]/
shutDown/
©2008, ARTiSAN Software Tools 120
Introduction to SysML
Slide 120
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
Requirements TraceabilityRequirements Traceability
©2008, ARTiSAN Software Tools 121
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 121
Requirements:Structure or Behavior?
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
The Requirements Diagram is neither a type of Structure Diagram nor is it atype of behavior Diagram. However it is highly likely that we would want torelate requirements to model elements that might appear on other diagramtypes, and to clearly see these relationships in the model.
©2008, ARTiSAN Software Tools 122
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 122
Design Elements
Model Element CModel Element C
Model Element T
Model Element A
«testCase»Model Element B
«requirement»REQ_A1
«requirement»REQ_A1.1
«requirement»REQ_A1.2
«requirement»REQ_B1
«requirement»REQ_C
«deriveReqt»
«refine»
«trace»
«satisfy»
«verify»
SysML Requirements Traceability
Traceabilityrelationshipsbetweenrequirementsand modelelements
«trace», «refine», «satisfy» and «verify» can exist between a requirementand any other model element (as we have already seen).These relationships are clearly visible from the Requirements Diagrams, butcan we see them from the diagrams that contain the relevant modelelements?
©2008, ARTiSAN Software Tools 123
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 123
Requirements Traceability fromOther Diagrams
Traceability callouts can be added from model elementswherever they appear in other diagrams in the model
Actor1
Actor2
Use Case A
Use Case B
refinesREQ_A1.2
satisfiesREQ_A1.1
Once the traceability relationship has been established in the model, calloutscan be added to show the relationship from the model element wherever thatelement appears.
Note that we have created a new use case and a «satisfy» relationshipbetween it and REQ_A1.1 to show in this illustration that all types oftraceability relationship can be added.
©2008, ARTiSAN Software Tools 124
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 124
SysML RequirementsTraceability Table
The table can be customized by adding or removing specific columns.
©2008, ARTiSAN Software Tools 125
Introduction to SysML
Slide 125
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
AllocationsAllocations
©2008, ARTiSAN Software Tools 126
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 126
Allocations
• Represent general relationships that map onemodel element to another
• Different types of allocation are:– Behavioral (i.e., function to component)– Structural (i.e., logical to physical)– Software to Hardware– ….
• Explicit allocation of actions to structure via swimlanes (i.e., activity partitions)
• Both graphical and tabular representations arespecified
©2008, ARTiSAN Software Tools 127
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 127
Different Allocation Representations(Tabular Representation Not Shown)
Explicit Allocation ofAction to Swim Lane
Allocate Relationship
Callout NotationCompartment Notation
«block»BlockName
allocatedFrom«elementType»ElementName
PartName
«allocate»:ElementName
ActionName
«block»BlockName
PartName
allocatedFrom«elementType»ElementName
ElementName1 Element
Name3
ElementName2
«allocate»
«allocate»
©2008, ARTiSAN Software Tools 128
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 128
act [activity] Distill Water [Simultaneous Behavior with Allocations]
hx1
ShutDown
steam : H2O[G as ]
«continuous»
hotDirty : H20[ Liquid ]
«continuous»
recovered : Heat
a3 : Condense Steam«streaming»
a1 : Heat Water«streaming»
coldDirty : H2O[ L iquid]
«continuous»
external : Heat«continuous»
:Heat Exchanger
«allocate»drain
a4 : Drain Residue
pure : H2O[ L iquid]
«continuous»
loPress : Residue«continuous»
:V a lve
«allocate»bx1
a2 : Boil Water
«streaming»
hiPress : Residue«continuous»
:B oiler
«allocate»
Parts
Behavioral Allocation – Actions to Partsusing Activity Diagram Swimlanes
Actions
Note the use of the «allocate» stereotype in the swimlanes, to indicate thatany actions in that swimlane are being allocated to the relevant part.
©2008, ARTiSAN Software Tools 129
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 129
Structural AllocationAbstract to Concrete
ibd [Block] Block1 [Abstract to Concrete Structural Allocation]
«Block»Block1
«BlockProperty»: AbstractExample
«BlockProperty»Part2
«BlockProperty»Part3
«BlockProperty»: ConcreteExample
«BlockProperty»Part4
«BlockProperty»Part5
«BlockProperty»Part6
«BlockProperty»: AbstractExample
«BlockProperty»Part2
«BlockProperty»Part3
«BlockProperty»Part2
«BlockProperty»Part3
«BlockProperty»: ConcreteExample
«BlockProperty»Part4
«BlockProperty»Part5
«BlockProperty»Part6
«BlockProperty»Part4
«BlockProperty»Part5
«BlockProperty»Part6
«Allocate»
«Allocate»
«A lloca te»
«Allocate»
«Allocate»
Systems engineers have a frequent need to allocate structural modelelements (e.g., blocks, parts, or connectors) to other structural elements. Forexample, if a particular user model includes an abstract logical structure, itmay be important to show how these model elements are allocated to a moreconcrete physical structure. The need also arises, when adding detail to astructural model, to allocate a connector (at a more abstract level) to a part(at a more concrete level). [SysML]
©2008, ARTiSAN Software Tools 130
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 130
Abstract to Concrete Allocation:Example
«BlockProperty»CC Sys : Cruise Control
System
«BlockProperty»PowSys : Power
Subsystem
Power-CC System
«BlockProperty»PowSys : Power Subsystem
CCIF : RS232
CCIF : Analogue
GearShiftIF : Force AccelIF : Force
CCIF : RS232
CCIF : Analogue
GearShiftIF : Force
«BlockProperty»CC Sys : Cruise Control
System
EMUIF : RS232
TransmIF : Analogue
BrakeIF : Digital
Power : Electric PowerEMUIF : RS232
TransmIF : Analogue
EMU : EMU Message
Set Throttle : AnalogueMessage
EMU : EMU Message
Set Throttle : AnalogueMessage
Gear : Analogue«ItemFlow»Gear : Analogue«ItemFlow»
allocatedFrom«Connector» Power-CC System
concreteimplementation
abstractconcept
Two fragments from IBDs have been used to illustrate this using the CruiseControl application. The lower fragment is from the initial ‘Vehicle MainSubsystems’ IBD; the upper fragment is from the later ‘Driver InterfaceConnections’ IBD, and shows implementation detail for the Power-CCSystem connector.
©2008, ARTiSAN Software Tools 131
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 131
SysML Allocation of SW to HW
• In UML thedeploymentdiagram isused to deployartifacts tonodes
• In SysMLallocation onibd and bdd isused to deploysoftware/datato hardware
ibd [node] SF Residence
«node»
SF R esid ence Installat i on
«hardware»: Site Processor
allocatedFrom« software» Device Mgr« software» Event Mgr« software» Site Config Mgr« software» Site RDBMS« software» Site Status Mgr« software» User I/F« software» User Valid Mgr
«hardware»*
: Optical Sensor
«hardware»: DSL Modem
«hardware»2
: DVD-ROM Drive
allocatedFrom«data» Video File
«hardware»: User Console
« hardware»
2
: Video Camera«hardware»
: Alarm
«hardware»: NW Hub
allocatedFrom«software» SF Comm I/F
« hardware»: Site Hard Disk
allocatedFrom«data» Site Database
©2008, ARTiSAN Software Tools 132
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 132
SysML AllocationsTraceability Table
©2008, ARTiSAN Software Tools 133
Introduction to SysML
Slide 133
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
SysML Package DiagramSysML Package Diagram
©2008, ARTiSAN Software Tools 134
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 134
The Package Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
©2008, ARTiSAN Software Tools 135
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 135
Package Diagram
• Package diagram is used to organize the model– Groups model elements into a name space– Often represented in tool browser
• Model can be organized in multiple ways– By System hierarchy (e.g., enterprise, system,
component)– By domain (e.g., requirements, use cases, behavior)– Use viewpoints to augment model organization
• Import relationship reduces need for fullyqualified name (package1::class1)
©2008, ARTiSAN Software Tools 136
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 136
Package DiagramOrganizing the Model
By Diagram Type By Hierarchy By IPT
©2008, ARTiSAN Software Tools 137
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 137
Package Diagram - Views
• Model is organized inone hierarchy
• Viewpoints can provideinsight into the modelusing another principle
– E.g., analysis viewthat spans multiplelevels of hierarchy
– Can specify diagramusages, constraints,and filtering rules
– Consistent with IEEE1471 definitions
©2008, ARTiSAN Software Tools 138
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 138
The Parametric Diagram
Diagram
Structure Behavior
BlockDefinition
InternalBlock
Package Activity
Use Case
StateMachine
Sequence
New forSysML
Requirements
Parametric
Modifiedfrom UML
Sameas UML
©2008, ARTiSAN Software Tools 139
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 139
Parametrics
• Used to express constraints (equations) between value properties– Provides support for engineering analysis
(e.g., performance, reliability)• Constraint block captures equations
– Expression language can be formal (e.g., MathML, OCL) or informal– Computational engine is defined by applicable analysis tool and not
by SysML• Parametric diagram represents the usage of the constraints in an
analysis context– Binding of constraint usage to value properties of blocks (e.g.,
vehicle mass bound to F= m a)
Parametrics Enable Integration of EngineeringParametrics Enable Integration of EngineeringAnalysis with Design ModelsAnalysis with Design Models
©2008, ARTiSAN Software Tools 140
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 140
Constraint Blocks
Defining reusable equations for Parametrics usingconstraint blocks on a block definition diagram
A constraint block is a block that packages the statement of a constraint so itmay be applied in a reusable way to constrain properties of other blocks. Aconstraint block includes the definition of one or more parameters which canbe bound to properties in a specific context where the constraint is used. In acontaining block where the constraint is used, the constraint block is used totype a property that holds the usage. A constraint parameter is a property ofa constraint block which may be bound to a property in a surrounding usagecontext. All properties of a constraint block define parameters of theconstraint block, with the exception of constraint properties that holdinternally nested usages of other constraint blocks. [SysML]
©2008, ARTiSAN Software Tools 141
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 141
Parametric Diagram – Example 1Vehicle Dynamics Analysis
Using theEquations ina ParametricDiagram toConstrain
ValueProperties
A parametric diagram is defined as a restricted form of internal block diagram. Aparametric diagram may contain constraint properties and their parameters, alongwith other properties from within the internal block context. All properties thatappear, other than the constraints themselves, must either be bound directly to aconstraint parameter, or contain a property that is bound to one (through anynumber of levels of containment). [SysML]
©2008, ARTiSAN Software Tools 142
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 142
Parametric Diagram – Example 2Direction Cosine Matrix
This diagram represents the conversion of Aircraft Heading (in Inertial Axes) into AircraftHeading (in Body Axes) using a Direction Cosine Matrix. The stereotype «constraint»contains the Direction Cosine Matrix (DCM).
The underlying data-types of each«constraintProperty»are captured. In thisexample,Aircraft.Inertial Headingis a Vector [x, y, z].
The type Vector isdefined elsewhere inthe design (as part ofthe Data-Model).
«constraint»Direction Cosine Matrix
«property»Aircraft.Yaw : Real
«property»Aircraft.Roll : Real
«property»Aircraft.Pitch : Real
«property»Aircraft.Inertial Heading : Vector
«property»Aircraft.Body Heading : Vector
©2008, ARTiSAN Software Tools 143
Introduction to SysML
C opyright © 2006ARTISAN Software Tools All Rights ReservedSlide 143
ibd [block] Anti-LockController[Internal Block Diagram]
d 1:TractionDetector
m1 :BrakeModulator
c1:modulatorinterface
ibd [block] Anti-LockController[Internal Block Diagram]
allocatedFrom«activity»DetectLosOfTraction
d1 :TractionDetector
allocatedFrom«activity»ModulateBrakingForce
m1: BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
act PreventLockup [Activity Diagram]
DetectLossOfTraction
ModulateBrakingForceTractionLoss:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[F = ma]
: VelocityEquation[a = dv/dt ]
:DistanceEquation[v = dx /dt]
:BrakingForceEquation
[f = (tf*bf )*(1-tl)]
tf : bf:tl:
f:
F:
c
a:a:
v:
v:
x:
Cross Connecting ModelElements - Summary
1. Structure 2. Behavior
3. Requirements 4. Parametrics
actPreventLockup [Swimlane Diagram]
«allocate»:TractionDetector
«allocate»:BrakeModulator
allocatedTo«connector»c1 :modulatorInterface
DetectLossOfTraction
ModulateBrakingForceTractionLoss:
req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]
Braking SubsystemSpecification
Vehicle SystemSpecification
id= “102”text =”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”
«requirement»StoppingDistance
id= ”337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”
«requirement»Anti-LockPerformance
«deriveReqt»
ibd [ block] Anti-LockController[Internal Block Diagram ]
allocatedFrom«activity»DetectLosOfTraction
d1 :TractionDetector
allocatedFrom«activity»ModulateBrakingForce
m1:BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti- LockPerformance
req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]
Braking SubsystemSpecification
Vehicle SystemSpecification
id=“ 102”text= ”The vehicle shall stopfrom 60 mph within 150fton a clean dry surface.”
«requirement»StoppingDistance
SatisfiedBy«block»Anti -LockController
id=” 337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”
«requirement»Anti- LockPerformance
«deriveReqt»
ibd [block] Anti- LockController[Internal Block Diagram]
allocatedFrom«activity»DetectLosOf Traction
d1:TractionDetector
valuesDutyCycle : Percentage
allocatedFrom«activity»ModulateBrakingForce
m1: BrakeModulator
allocatedFrom«ObjectNode»TractionLoss:
c1:modulatorInterface
satisfies«requirement»Anti-LockPerformance
par [ constraintBlock] StraightLineVehicleDynamics [Parametric Diagram ]
:AccellerationEquation[F = ma]
: VelocityEquation[a = dv/dt ]
: DistanceEquation[v = dx/dt]
:BrakingForceEquation
[f = (tf*bf)*(1- tl)]
tf: bf:tl:
f:
F:
m:
a:a:
v:
v:
x:
v.Position:
v .Weight:v.chassis .tire.
Friction:v.brake.abs.m1.
DutyCycle:v. brake.rotor .BrakingForce:
par [constraintBlock] StraightLineVehicleDynamics [Parametric Diagram]
:AccellerationEquation[ F = ma]
:VelocityEquation[a = dv/dt]
:DistanceEquation[v = dx /dt]
:BrakingForceEquation
[f = (tf*bf )*(1-tl)]
tf : bf:tl:
f:
F:
m :
a :a:
v:
v:
x:
v .Position:
v.Weight:v.chassis .tire.
Friction:v.brake.abs.m1.
DutyCycle :v.brake.rotor.BrakingForce :
req [package] VehicleSpecifications[Requirements Diagram - Braking Requirements]
Braking SubsystemSpecification
Vehicle SystemSpecification
VerifiedBy«interaction»MinimumStoppingDistance
id=“ 102”text=”The vehicle shall stopfrom 60 mph within 150 fton a clean dry surface.”
«requirement»StoppingDistance
SatisfiedBy«block»Anti -LockController
id= ”337"text =”Braking subsystemshall prevent wheel lockupunder all braking conditions .”
«requirement»Anti-LockPerformance
«deriveReqt»
satisfy
verify
valuebinding
allocate
Four types of cross-connecting principles:1. Allocation
2. Requirement satisfaction/derivation
3. Value Binding/Parametrics
4. Requirement Verification
©2008, ARTiSAN Software Tools 144
Introduction to SysML
Slide 144
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
Software Engineering HandoverSoftware Engineering Handover
©2008, ARTiSAN Software Tools 145
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 145
From Systems to SoftwareEngineering
• Why do systems engineers needs to understand some aspects ofsoftware engineering?
– Help specify software requirements– Ensuring software requirements are captured completely and that they are
traceable to system requirements– Take part in software design reviews– Involvement in integration/system testing– Manage change in system requirements and define impact on software
• What do they need to know?– Some basic concepts of object–orientation (OO)– Some essential UML terminology and notation– Some appreciation of how UML designs evolve from requirements to code
• Separate systems engineering model from software engineering model– Either: separate model for each (with package import/export)– Or: separate packages for each (within one Studio model)
©2008, ARTiSAN Software Tools 146
Introduction to SysML
Slide 146
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
Fundamentals of OOFundamentals of OO
©2008, ARTiSAN Software Tools 147
Introduction to SysML
Objects represent some entity relevant to the real world problem we are dealingwith. They may represent physical entities (e.g. devices), or non-physical entities.
Each object must have a clearly defined and coherent set of responsibilities thatdistinguishes it from other objects. It must also have a unique identity.
Objects are responsible for maintaining information they need in order to provideservices consistent with their responsibilities.
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 147
What is an Object ?
• An Object…
– Is a software abstraction of a real-world concept or thing foundin the problem domain
– Has a coherent set of responsibilities
– Provides a set of services (operations) consistent with itsresponsibilities
– Has a unique identity
– Maintains information (attributes) about itself
– Interacts with other objects
*
©2008, ARTiSAN Software Tools 148
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 148
The Object Oriented Paradigm (1)
• Objects work together in a ‘network’.– Networks are far more flexible to extend and modify than
hierarchies.
• Object Oriented techniques use hierarchy wherenecessary, not as a fundamental principle of design.– Composition and Aggregation Hierarchies– Inheritance Hierarchies
• Objects can represent the ‘roles’ they play within thenetwork, and not a position in an artificial hierarchy.
The origin of the word ‘hierarchy’ has its roots firmly planted in religious institutions. Originallyused to describe the ‘angelic host’ in the 4th century AD; three divisions of angels eachcomprising of three orders in a nine-fold celestial system. Later it became used to describe thesystem of ecclesiastical rule and only in its most recent application does it seem to have lost itsreligious meaning. When Darwin drew-up the hierarchy of living animals he put mankind at thetop because the hierarchy was ordered according to the ability to ‘control’, if the hierarchy wereordered by ‘ability to cooperate’ with other living animals, humans would be somewhere near thebottom. Hierarchies are an artificial mechanism to ascribe some subjective form of ‘order’ orclassification on something which is perceived to be chaotic – perhaps it would not be chaotic if itwere looked upon as a role-based network. Most organizations are hierarchically structured yetoperate, at an individual level, as a network. Individuals create a network of co-workers withwhom they work, so the hierarchy – far from providing direction and control – has no impact onan individual worker’s ability to perform their tasks.
One could define a hierarchy as ‘A partially-ordered structure of entities in which every entity butone is successor to at least one other entity; and every entity except the basic entities is apredecessor to at least one other entity’. This definition elaborates the basic problem withhierarchies, each entity within the hierarchy must be connected to at least one other (either assuccessor or predecessor) therefore to modify or remove one node in a hierarchy you also have totake into account its predecessors and successors as these may be affected. Object orientedtechniques do not impose a hierarchy (i.e. no artificial imposition of a predecessor or successor)on the evolving system; entities (or objects) can be modified, added and removed and the impactof these changes are apparent in the links (or associations) the object has with others in thenetwork.
©2008, ARTiSAN Software Tools 149
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 149
The Object Oriented Paradigm (2)
• Objects have ‘behavior’– Objects can have ‘state behavior’ which changes with time.– An Object can perform specific functions on the data it
owns or request other Object within the ‘network’ toperform functions on their data.
• Objects own ‘information’– It manages and maintains its own information.– OO focuses on the propagation of information to and from
other Objects.
©2008, ARTiSAN Software Tools 150
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 150
Types of things…
• You are all types of people… (assumption)• Car parks fill up with types of vehicle…• Libraries are full of types of publication…• A SysML Block is a type of system component…
However:
• It is particularly useful to classify something (i.e.identify its type) when there is more than one of them- why?
• Because the type becomes a convenient way ofdescribing the common characteristics of similarthings.
©2008, ARTiSAN Software Tools 151
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 151
Components, Objects andClasses
• A System is an artefact within which a collection of (reusable)‘objects’ collaborate in a network to deliver the desired behaviouraloutputs.
• Data and functionality are co-located within the ‘object’ (referred toas ‘encapsulation’, ‘modularization’ or ‘information hiding’)
• ‘Objects’ are classified (or typed) into groups of things exhibitingsimilar data and functionality.
• An ‘Object’ is defined by its class.• Relationships are created between classes to define the
permissible network of interactions allowed by the ‘object’.• ‘Objects’ can be organized into larger, more abstract units referred
to as ‘Components’.• ‘Components’ can also be typed by a ‘class’ that defines the data
storage and functionality of the ‘component’.
©2008, ARTiSAN Software Tools 152
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 152
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.
©2008, ARTiSAN Software Tools 153
Introduction to SysML
Copyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 153
Which came first?
In OO an Object is typed by a Class, but which comesfirst, the Class or the Object?
In software engineering, they are both required at thesame time.
We design a system using Objects…
… but we select the right Objects from their Classproperties.
©2008, ARTiSAN Software Tools 154
Introduction to SysML
Slide 154
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Cross Cutting ConceptsCross Cutting Concepts
Software Development with UMLSoftware Development with UML
©2008, ARTiSAN Software Tools 155
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 155
Lot 1 SpacesLot 2 FullLot 3 Spaces
A Simple Application
Exit
Entry
Pressure sensor
Parking Lot
System controller& barrier motor
Safety barrier
IR beamsensor
Traffic lightsLot 1 SpacesLot 2 FullLot 3 Spaces
Display Boards
Serial Link
The parking lot controller controls car access to the parking lot by keeping a dynamic count of thenumber of cars currently in the parking lot. It compares this value with an operator specified valuefor the total capacity of the parking lot to determine whether to admit cars.The system makes use of two sensors, an IR beam sensor at the entry point and a pressure sensor atthe exit point. When a new car enters the parking lot the current car count is incremented. When acar leaves the parking lot the count is decremented.
Access into the parking lot is controlled by a motorized safety barrier and pair of traffic lights, onered and one green (there is no amber light). The red light is illuminated until the entry beam sensordetects a car entering. The control system then checks for space. If there is space for the car, thered light is extinguished, the green light illuminated and the barrier motor opens the safety barrier.If the parking lot is full the red light stays illuminated until the pressure sensor detects a carleaving. When the car entering has passed through the entry beam sensor the red light isilluminated again, the green light extinguished and the barrier motor closes the safety barrier.
An operator I/O unit is provided to enable initial setting of, and any subsequent changes to, theparking lot capacity value. This unit consists of a 4 digit display, two function buttons (one todisplay current capacity value, the other to reset this value), and a numeric keypad. To set up orchange the capacity the operator presses the display button, this activates the display and shows thecurrent value (zero for initial setting). The operator then uses the keypad to enter the new value,which is displayed as each key is pressed. When the display is showing the required value theoperator presses the reset button to reset the value and de-activate the display.The system also needs to provide free space information, across a serial (RS422) data connection,for an external system that updates a number of remote display boards.
©2008, ARTiSAN Software Tools 156
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide156
«requirement»
txtThe System shall prevent a car fromentering if the parking lot is full.
REQ_1«requirement»
txtThe software shall input and store themaximum capacity value for the parking lot.
REQ_1_SW1
«requirement»
txtThe software shall maintain a count of carscurrently in the parking lot.
REQ_1_SW2
«requirement»
txtOn detecting a car arriving, the softwareshall compare current count value againstmaximum capacity to determine whetherthe car should be allowed to enter.
REQ_1_ SW3
req [Package] Reqts
«deriveReqt»
«deriveReqt»
«deriveReqt»
Software Requirements fromSystem Requirements
SystemRequirement
DerivedSoftware
Requirements
The SysML requirements diagram can show both system and (derived) softwarerequirements. In Studio, requirements diagrams can also be held in a UMLmodel.
©2008, ARTiSAN Software Tools 157
Introduction to SysML
A Context Diagram allows the software engineers to identify all inputs andoutputs that the software (to reside in a ‘black-box’ Control System) will need tohandle. Essential details for each item of input or output can be captured throughproperties.
SysML internal block diagrams and activity diagrams are the chief source ofinformation for the construction of the Context Diagram.
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide157
Capturing the Software IO Context
*
Parking Lot System
«interface device»Green Light
«interface device»Entry Beam Sensor
«interface device»Pressure Sensor
«interface device»Barrier Motor
«interface device»Red Light«subsystem»
Control System
«subsystem»Operator I/O Unit
«interface device»Keypad
«interface device»Display Button
«interface device»Reset Button
«interface device»Display
«interface device»Full Light :
«interface device»Green Light
«interface device»Entry Beam Sensor
«interface device»Pressure Sensor
«interface device»Barrier Motor
«interface device»Red Light«subsystem»
Control System
«subsystem»Operator I/O Unit
«interface device»Keypad
«interface device»Display Button
«interface device»Reset Button
«interface device»Display
«interface device»Keypad
«interface device»Display Button
«interface device»Reset Button
«interface device»Display
«interface device»Full Light :
Car
Operator
: car passes through: car breaks beam : car passes through: car breaks beam
: car triggers sensor: car triggers sensor
: reset press: reset press
: connect
: break
: connect
: break: detect: detect
: display press: display press
: raise
: lower
: raise
: lower
: set red: set red
: set green: set green
: clear display
: display
: clear display
: display
: key press: key press
: set full: set full
©2008, ARTiSAN Software Tools 158
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 158
Operator
Car
Use ParkingLot
Set Capacity
Car Waits
«extend»
Software Use Cases
• Software use cases aredefined from, and traceto, systems use cases
• They specify theservices provided bysoftware in the system
This shows a simple use case diagram for the parking lot application, with theDescription property for the Use Parking Lot use case visible.
Other properties can be specified for each use case as required.
These software use cases will be derived from wider system use cases, typicallydefined in a SysML model.
©2008, ARTiSAN Software Tools 159
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 159
System Interaction Diagrams SpecifyRequired Use Case Behavior
Use Parking LotDescription Barrier Motor Entry Beam SensorGreen Light Pressure SensorRed Light Control SystemCar
entry beam detects car car breaks beambeam sensor signals controller break
check for spaceIf full
suspend entry Car WaitsEndIf
open barrier raise{3ms}turn off red light set red( off )turn on green light set green( on )
car passes through beam car passes throughbeam sensor signals controller connect
increment car countclose barrier lowerturn off green light set green( off )turn on red light
max. {50ms}
set red( on )car triggers pressure sensor car triggers sensorpressure sensor signals controller detect
decrement car count
systemboundary
architecturalboundary
timingconstraint
Context Diagram ‘devices’
This diagram specifies the required ‘black-box’ behavior of the Control Systemfor the Use Parking Lot use case. One system interaction diagram is produced foreach software use case. The diagram defines the sequence of IO for the‘hardware’ elements defined on the Context diagram.
©2008, ARTiSAN Software Tools 160
Introduction to SysML
We now move into software design. A sequence diagram is produced for eachuse case, using candidate software objects. The purpose of these diagrams is toidentify software objects and the operations they will need to support to deliveruse case functionality. Detailed information (synchronicity, message parameters,data types, etc.) can be added as these diagrams are developed iteratively.
The note on the diagram is referring to a previous system interaction diagramwhich captured implicit hardware interactions specified for this same use case.
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide160
Initial Object Interaction for aUse Case
*
Description :Barrier Motor Red:Light
Green:Light
:Beam Sensor :Car Count:Controller:Pressure Sensor
entry beam detects car breakbeam sensor signals controller car_arrived
controller checks for space isFullIf full
suspend entry Car WaitsEndIfopen barrier openturn off red light offturn on green light on
car passes through beam connectbeam sensor signals controller car_entered
increment car count incrementclose barrier closeturn off green light offturn on red light on
car triggers pressure sensor detectpressure sensor signals controller car_exited
decrement car count decrement
This diagram is a further development of the previously created 'Use Parking Lot - analysis ' sequence diagram. This diagram illustratesthe same use case, but this time as a sequence of software object interactions. The diagram could be used in the early stages ofobject definition and would contribute to the specification of the object model.
©2008, ARTiSAN Software Tools 161
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide161
Example Class Diagram
Operator I/O Unit
I/O Unit
capacity : long-num : short-newValue : long-reset ()+activate ()+key (in number)+
Display
display (in data)+
Keypad Button
read () : short+
I/O Unit
capacity : long-num : short-newValue : long-reset ()+activate ()+key (in number)+
Display
display (in data)+
Keypad Button
read () : short+
Controller
car_entered ()+car_exited ()+car_arrived ()+
Pressure Sensor
threshold : float-initialize ()+read () : short+
Light
on ()+off ()+
Beam Sensor
initialize ()+read () : short+
Sensor{Abstract}
status : short-initialize ()+read () : short+
Barrier Motor
open ()+close ()+
Car Count
capacity : long-count : long = 0-increment ()+decrement ()+isFull () : boolean+set_capacity (in value : long)+get_capacity () : long+Car_Count ()+~Car_Count ()-
1
1 theIOUnit
myKeypad1
1
myDisplay1
1
resetButton
11
Notifies
theEntrySensor
theController
11
NotifiestheExitSensor theController
1
1
theGreenLight
1
1
displayButton
1
1
theMotor
1
1theCarCount
11 resets capacity
theCarCount
1
1
theRedLight
As software interaction models are developed, a class model is also evolving tocapture class properties and relationships.
©2008, ARTiSAN Software Tools 162
Introduction to SysML
State diagrams can be produced to model the behavior of classes over theirlifetime. This diagram specifies the dynamic behavior for the Controller class.Most of the events within the ‘Able to Admit Cars' composite state representoperations defined against the Controller class. The 'after(2000)' event specifies atime period of 2 seconds from entry into the Lowering Barrier state. (note thatthis solution implies that another car will not arrive within this time frame).
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 162
State Diagram Example
*
Raising Barrier
Entry/theMotor.open;theRedLight.off;theGreenLight. on;
Lowering Barrier
Idle
Able to Admit Cars
car_exited/theCarCount.decrement
Entry Suspended
Controller
«Des troy»/after( 2000 )/
«Create»/
c ar_arrived/ [theCarCount.isFull ]/
[e ls e ] /
car_entered/theCarCount.increment;theMotor.close;theGreenLight.off;theRedLight.on;
car_exited/theCarCount.decrement
«Des troy»/
©2008, ARTiSAN Software Tools 163
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide163
Model Concurrency
Sensor Flags
Display Press Flag
Car CountSemaphore
EventDetectionTask
Admit CarTask
ResetCapacity Task
Display
DisplayButton
Reset Button Keypad
Entry BeamSensor
PressureSensor
Red Light
Green Light
Barrier Motor
wait()
wait()
set()
set()
display press()break()
connect()detect()
key press()reset press()
get()
release()
increment()
isFull()
decrement()
reset_capacity()get_capacity()
This diagram represent an initial specification of the taskingmodel. It shows that three tasks have been identified and itdefines how task intercommunication is to take place. It alsoshows which system devices are handled by which task.
Event direction is conceptual only; in fact all input devices are polled
For multi-tasking processors a concurrency model can be developed that specifiesthe required tasks, their interaction and any mutual exclusion requirements.
The production of the concurrency model may extend the object architecturemodel, especially the class model.
Note that this example is not a standard UML diagram, but an ARTiSANextension.
©2008, ARTiSAN Software Tools 164
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide164
Updated Class Model
Operator I/O Unit
«CRconcurrent»
...
I/O Unit
capacity : long-num : short-newValue : long-main ()+activate ()+key (in number : short)+reset ()+
Display
display (in data)+
Keypad Button
read () : short+
«CRconcurrent»
...
I/O Unit
capacity : long-num : short-newValue : long-main ()+activate ()+key (in number : short)+reset ()+
Display
display (in data)+
Keypad Button
read () : short+
pRTOS
cEvent _Flag
flag : boolean-Set ()+Clear ()+Check () : boolean+Wait ()+
cEvent _Flag
flag : boolean-Set ()+Clear ()+Check () : boolean+Wait ()+
«CRconcurrent»Controller
main ()+car_exited ()+car_arrived ()+car_entered ()+
Pressure Sensor
threshold : float-initialize ()+read () : short+
Light
on ()+off ()+
Beam Sensor
initialize ()+read () : short+
Sensor{Abstract}
status : short-initialize ()+read () : short+
Barrier Motor
open ()+close ()+
Car Count
capacity : long-count : long = 0-increment ()+decrement ()+isFull () : boolean+set_capacity(invalue:...+get_capacity () : long+
«CRconcurrent»
...
Event Detection
main ()+
1
1theIOUnit
myKeypad1
1
myDisplay1
1
resetButton
11
Notifies
theEntrySensor
theController
11
NotifiestheExitSensor theController
1
1
theGreenLight1
1
theMotor
1
1 theCarCount
11 resets capacity
theCarCount
1
1
theRedLight
11DisplayPressFlag
21
Sensor Flags
1
1
Display
1
1
theIO
1
1
ExitDetector1
1
EntryDetector
As the software design becomes more detailed, implementation concerns start toappear in the class model. However these additions should not alter thefundamental (and traceable back to use cases) properties and relationships of theapplications classes.Composition has been used to reflect the active objects ‘owning’ their parts.
Otherwise little has changed other than the addition of the RTOS wrapper classesand their restricted access via the active object classes that use them.
©2008, ARTiSAN Software Tools 165
Introduction to SysML
The creation of the class model is often seen as key. Code can be generated orproduced from information in the class model. Language profiles allow morecode related information to be held within the model.
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 165
::Class1
Attribute1 : Typedef1Operation a ()Operation b (in param : Typedef1) : long
::Class2
Operation c ()
1
1
theC2
Evolve Class Modelfor Code Production
*
class Class1{
public:enum Typedef1{
Typedef1_enum1,Typedef1_enum2
};
// public operations
void Operation_a();
long Operation_b(const Typedef1 param);
private:
// private attributes
Typedef1 Attribute1;
// private roles
Class2* rtheC2;};
©2008, ARTiSAN Software Tools 166
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 166
Traceability/Impact Analysis
Requirements RequirementsModels
DesignModels
Systemtests
Integrationand Unit tests
Satisfies Satisfies
Acceptancetests
Tests
Tests
Tests
SourceFiles
Satisfies
What if …?
Why is … ?
©2008, ARTiSAN Software Tools 167
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 167
::Person
Name
Age
AssignUn-Assign
::Company
Name
::Contract
StartDateSalary
Grade
ChangeGrade
::WorkInstruction
Description
StartDate
DurationPerformanceRating
AgreePerformanceRating
::RevenueItem
Cost
::Product ::Service
::DevelopmentPlan
MeanPerformanceTrainingNeeds
CurrentSkills
::ContractualConstraint
DescriptionUpdate
::Term ::Condition
11..* WorksFor
Employee Employer
1..*
1
Manages
Manager
Worker
1..*
1
Markets
Manufacturer
1..*1 DescribesWorkOn
*
0..1
1
1
*
1
Updates
Supervisor
*1
1..*
1
Updates
1..*
1
Purchases
Customer
ItemType{Exclusive}ItemType{Exclusive}
ConstraintType{Inclusive}ConstraintType{Inclusive}
Class Model
Requirements
Pilot
StoresNavigationData
DeploysWeapon
PerformsSorte
Use Case Model
TheSoftware:TheSoftwarePilot DataEntryPanel
Pilot PressesKeyKeyPress
SoftwareDeterminesnewModeKeyPress(KEYID)
ifNAVKeythen
EnterNavigationModeSetMode(NAV)
elsifWeaponsKey then
case SelectedStore iswhenLoft Bombs=>
SetMode(LOFT)whenRetardBombs => SetMode(RETARD)
whenGuns=> SetMode(GUN)whenRockets =>
SetMode(ROCKET)endcase
endif
EnterNavigationModeSetMode(NAV)
elsifWeaponsKey then
case SelectedStore iswhenLoft Bombs=>
SetMode(LOFT)whenRetardBombs => SetMode(RETARD)
whenGuns=> SetMode(GUN)whenRockets =>
SetMode(ROCKET)endcase
case SelectedStore iswhenLoft Bombs=>
SetMode(LOFT)whenRetardBombs => SetMode(RETARD)
whenGuns=> SetMode(GUN)whenRockets =>
SetMode(ROCKET)endcase
whenLoft Bombs=>SetMode(LOFT)
whenRetardBombs => SetMode(RETARD)
whenGuns=> SetMode(GUN)whenRockets =>
SetMode(ROCKET)
TheSoftware:TheSoftwarePilot DataEntryPanel
Pilot PressesKey KeyPressSoftwareDeterminesnewMode KeyPress(KEYID)ifNAVKeythen
EnterNavigationMode SetMode(NAV)elsif WeaponsKeythen
caseSelectedStore iswhen Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)
when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcaseendif
EnterNavigationMode SetMode(NAV)elsif WeaponsKeythen
caseSelectedStore iswhen Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)
when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcase
caseSelectedStore iswhen Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)
when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcase
when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)
when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
TheSoftware:TheSoftwarePilot DataEntryPanel
Pilot PressesKey KeyPressSoftwareDeterminesnewMode KeyPress(KEYID)ifNAVKey then
EnterNavigationModeSet Mode(NAV)
elsif WeaponsKeythencase SelectedStoreis
when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcaseendif
EnterNavigationModeSet Mode(NAV)
elsif WeaponsKeythencase SelectedStoreis
when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcase
case SelectedStoreis
when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
endcase
when Loft Bombs=> SetMode(LOFT)when RetardBombs=> SetMode(RETARD)when Guns=> SetMode(GUN)when Rockets=> SetMode(ROCKET)
Scenario Model
Take-of f Valve
RemoteOperator
Local operator
Nitrogen Compression Plant
NCP System
HP Tank
HPT Switch HP Switch LPT SwitchLP Switch
Remote Monitoring Unit
Local Indication Panel
Compressor Unit
CompressorMotor
CompressorSensors
Valves
By-pass ValveVent ValveInlet Valve
Outle t Valve
NCP System
HP Tank
HPT Switch HP Switch LPT SwitchLP SwitchHPT Switch HP Switch LPT SwitchLP Switch
Remote Monitoring Unit
Local Indication Panel
Compressor Unit
CompressorMotor
CompressorSensors
CompressorMotor
CompressorSensors
Valves
By-pass ValveVent ValveInlet Valve
Outle t Valve By-pass ValveVent ValveInlet Valve
Outle t Valve
open()open() close()close()
250 bar()250 bar()
reset()
alarm()
reset()
alarm()
reset()
alarm()
reset()
alarm()
system stop()system stop()
alarm()
reset()
alarm()
reset()
150 bar()150 bar()
system start()
system stop()
system start()
system stop()
stop()
start()
stop()
start()
Context Diagram
Remote Monitoring Unit
RMU Display Stop ButtonRMU Display Stop Button
Local Indication Panel
stop/startbuttons
LIP Display stop/startbuttons
LIP Display
Plant Controller
system bus
display boardseria l i/f
I/O board
motherboard
remote comms.
seria l i/f
system bus
display boardseria l i/fseria l i/f
I/O board
motherboard
remote comms.
seria l i/fseria l i/f
Compressor Unit
CompressorMotor Low OilPressure switch
Inlet GasPressureTrip Switch
Outlet GasPressure Tr ip
Switch
Coolant FlowMeter
CompressorMotor Low OilPressure switch
Inlet GasPressureTrip Switch
Outlet GasPressure Tr ip
Switch
Coolant FlowMeter
HP Tank
HPT Switch
HP Switch
LPT Switch
LP Switch
HPT Switch
HP Switch
LPT Switch
LP Switch
Outlet Valve Vent ValveBy-pass ValveInlet Valve
3 wire RS2323 wire RS232
RS422RS422 All I/O board connections are 24V DC single phase. Valveconnectionsare in fact 2 single 1-way connections rather one 2-way
...
Hardware Architecture(Deployment) Diagram
Start/Stop Requests
Alarms Status
Timeout Events
Alarm Inhibits /Enables
Alarm MonitoringTask (AMT)
Display andCommunication
Task (DCT)
Timer Task
(TT)
CompressorController Task
(CCT)
Timer Requests
alarm status data
Plant Status
Real WorldTrips
Real WorldDevices
Networks ( for
LIP and RMU)
Set() Clear()Set() Clear()
Read()Read()
Set()Set()
Check()Check()
Post()Post()
Write()Write()
Read()Read()
Set()Set()
Read()
Clear()
Read()
Clear()
Write()Write()
Read()Read()
Write()Write()
Read()Read()Read()
Clear()
Read()
Clear()
Concurrency (Communication)Diagram
SourceFiles
How it all fits together
Starting Up SystemFail Safe
Shutting Down System
Compressor Off
Compressor On
State4
Compressor Off
Compressor On
after( 40s )/
system start/Start Up Plant
power down/
system stop/Shutdown Plant
alarm/ Handle Alarm
after( 180s )/Maintain Gas Pressurealarm/ Handle Alarm
power up/
[LPT and LOP alarms ringing] /
[ els e ]/
[els e] /
250 bar/S top Compressor
150 bar/Start Compress or
[LOP alarmringing] /
Interaction Overview(Modes) Diagram
TestScripts
OperationalParameters Performance
Loader Speed
Belt Speed
Containers ScanSuccess
DefectiveContainers Accuracy
Constraints Diagram
runningdown
Entry/monitor .inhibit(LOP);timer .set(40);motor. stop;
valve [inlet].close;valve [outlet]. close;valve [by-pass].open; ...
stopped
waitingforoilpressuretobuildEntry/monitor.inhibit(LOP);
valve[vent].close;timer.set (30);timer.set (40);
motor. start; ...
waitingforgaspressuretobuildoperating
timeup/
monitor .enable(LOP)
start compressor/
after(40s)/valve[vent]. open;...
after(10s )/
valve[by-pass].close;valve[inlet].open ;valve[outlet]. open; ...
stopcompressor/
«Destroy»/
stopcompressor/timer.cancel (30);timer.cancel (40);
stopcompressor/
timer.cancel(40);
«Create»/
[ !monitor. check(LOP)]/monitor .activate (LOP)
[monitor .check(LOP)]/
Dynamic Model
Bombadier
Select Target Destination
Authority
Bombadier
Select Weapon Type
Navigator
«Equivalent»
Select Target Destination
Authority
Bombadier
Select Weapon Type
Navigator
Pilot
Communicator
Strike Authorised
Navigate to Target
Communicator
Strike Authorised
Navigate to Target
Commander
Strike Authority
«Secondary Actor»
Strike Authority
Activity Diagram
«pConstraint»Direction Cosine Matrix
«property»Aircraft.Yaw : Real
«property»Aircraft.Roll : Real
«property»Aircraft.Pitch : Real
«property»Aircraft.Inertial Heading : Vector
«property»Aircraft.Body Heading : Vector
Parametric Diagram
ACME RADAR
: Signal Processing : RADAR Controller
: Array Antenna
: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Electronic Orientation
: User Displays
: Display : Keypad
: Signal Processing : RADAR Controller
: Array Antenna
: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Electronic Orientation: Receiver
: Transmitter
: Antenna Controller
: Power Supply
: Tx Rx Duplex
: Power Supply
: Tx Rx Duplex
: Array Orientation
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Mechanical Orientation
: Elevation Actuator
: Azimuthal Actuator
: Elevation Actuator
: Azimuthal Actuator
: Electronic Orientation
: User Displays
: Display : Keypad: Display : Keypad
Operator
Composite StructureDiagram
Specification
«generalRequirement»
RequirementCid = "Name"
text = "The system shall..."priority = High
status = "Assigned"
«performanceRequirement»
Requirement B
«functionalRequirement»
Requirement A
«generalRequirement»
RequirementCid = "Name"
text = "The system shall..."priority = High
status = "Assigned"
«performanceRequirement»
Requirement B
«functionalRequirement»
Requirement A
Derived Requirements
«functionalRequirement»RequirementX
«performanceRequirement»RequirementY
«functionalRequirement»RequirementX
«performanceRequirement»RequirementY
Design
SystemElementA
SystemElementB
SystemElementA
SystemElementB
Test Cases
«test Case»Test CaseA«test Case»Test CaseA
*
1
«trace»«trace»
«satisfy»
«satisfy»
«verify»
<<rationale>>
Reason
Requirements Diagram
The UML provides many ‘diagram types’. Each type of diagram focuses on unique perspective ofthe evolving system. Each perspective provides a unique ‘view’ of all the linked information withthe complete model. The green lines represent the same model element on different diagrams. Thered lines represent links between different model elements. Systems today require a detailedanalysis from many perspectives in order to describe the complete system. Within RtS we providethe following views of the system:
•Use Case view – providing details of services provided by the system and which actors areinvolved with the service.
•Interaction view – supported by both Scenario and Collaboration Diagrams which detail whatentities are involved in delivering the service.•Class view – providing details of the static architecture of the software.
•State view – provided at both system and software levels to detail the dynamic behavior of boththe system and the software.•Concurrency view – providing detailed analysis of both system and software concurrency
•Constraints view – providing a mechanism to capture and maintain non-functional requirementsof the system and software.
•Contextual view – providing details of user-system and system-software interfaces as well as anoverall system context.•Hardware view – providing details of processing nodes, especially the details traditionally sharedbetween hardware and software engineers e.g. hardware addresses.
©2008, ARTiSAN Software Tools 168
Introduction to SysML
Slide 168
Introduction to SysMLIntroduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights Reserved
Summary and WrapSummary and Wrap--upup
©2008, ARTiSAN Software Tools 169
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 169
Summary
• SysML sponsored by INCOSE/OMG with broad industry andvendor participation
• SysML provides a general purpose modeling language to supportspecification, analysis, design and verification of complexsystems– Subset of UML 2 with extensions– 4 Pillars of SysML include modeling of requirements, behavior,
structure, and parametrics
• OMG SysML Adopted in May 2006• Multiple vendor implementations announced• Standards based modeling approach for SE expected to improve
communications, tool interoperability, and design quality
©2008, ARTiSAN Software Tools 170
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 170
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
©2008, ARTiSAN Software Tools 171
Introduction to SysML
Copyright ©2006 ARTISAN Software Tools All Rights ReservedSlide 171
Additional Reading…
o The Unified Modeling Language Reference Manual (Addison-WesleyObject Technology Series) by James Rumbaugh, IvarJacobson, Grady Booch
o Applying UML and Patterns: An Introduction to Object-OrientedAnalysis and Design and the Unified Process (2nd Edition) by CraigLarman
o Writing Effective Use Cases by Alistair Cockburno Applying Use Cases: A Practical Guide by Geri Schneider, Jason
P. Winters, Ivar Jacobsono The Object-Oriented Thought Process by Matt Weisfeld, Bill
McCartyo Pattern-Oriented Software Architecture, Volume 2, Patterns for
Concurrent and Networked Objects by Douglas Schmidt
QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.QuickTime™ and a TIFF (Uncompressed) decompressor are needed to see this picture.
QuickTime™and a TIFF (Uncompressed) decompressor are needed to see this picture.QuickTime™and a TIFF (Uncompressed) decompressor are needed to see this picture.
©2008, ARTiSAN Software Tools 172
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 172
Questions and Answers
©2008, ARTiSAN Software Tools 173
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 173
How To Contact Us
If you would like to arrange a customized Webex ordemonstration on how ARTiSAN products & services canenhance your organizational processes’ capability andmaturation contact us at (703) 771-8008.
Speak with Mr. Phil Perri, Business DevelopmentManager, North America
©2008, ARTiSAN Software Tools 174
Introduction to SysML
Slide 174
Introduction to SysMLIntroduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights Reserved
Distiller Sample ProblemDistiller Sample Problem
©2008, ARTiSAN Software Tools 175
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 175
System DevelopmentProcess
SystemmodelingActivities
Integrated ProductDevelopment (IPD) isessential to improve
communications
A recursive V processthat can be applied tomultiple levels of the
system hierarchy
ComponentmodelingActivities
Procedures
ManageSystem
Development
Define SystemReqt's &Design
Integrate& TestSystem
System
StakeholderReqts
System archAllocated reqt's
DataHardware
SoftwareDevelopSystem
Components
VerifiedSystem
Component
Plan
StatusTechnical data Test procedures
There are many different process models in use by many organizations. The aboveoutlines just one (reasonably common) approach.
The main purpose of this section is not to define a process but to emphasize that,whatever the process, there will be important inter-relationships between various SysMLdiagrams that are evolved iteratively.
©2008, ARTiSAN Software Tools 176
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 176
Distiller Problem – Process Used
• Organize the model, identify libraries needed• List requirements and assumptions• Model behavior
– In similar form to problem statement– Elaborate as necessary
• Model structure– Capture implied inputs and outputs
• segregate I/O from behavioral flows– Allocate behavior onto structure, flow onto I/O
• Capture and evaluate parametric constraints– Heat balance equation
• Modify design as required to meet constraints
The process used to evolve the Distiller diagrams is outlined above. Note that this doesthings in a quite different order from the order we have introduced topics on this course.This reinforces the point that SysML is process independent. The following slides will(hopefully) also reiterate the need for, and benefits of, creating links between variousmodel elements, irrespective of the order in which they are created. It will also reiteratethe iterative nature of SysML Model development.
©2008, ARTiSAN Software Tools 177
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 177
Distiller Problem Statement
• The following problem was posed to the SysMLteam in Dec ’05 by D. Oliver:• Describe a system for purifying dirty water.
– Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger– Boil dirty water is performed by a Boiler– Drain residue is performed by a Drain– The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C, specific heat
1cal/gm deg C, heat of vaporization 540 cal/gm.• A crude behavior diagram is shown.
Dirty water@ 20 deg C
Heat Dirty waterTo 100 deg C
Heat to Dirtywater
Boil Dirty water
Dirty water@ 100 deg C
Steam
Residue
and
Condensesteam
DrainResidue
Purewater
Disposedresidue
andand
Heat to Boilwater
Energy tocondense
What are the real requirements?How do we design the system?
Problem statements come in many different forms. The systems engineer is oftenpresented with informal diagrams and text for the initial concept requirements,and is asked to formalize them into a specification.
©2008, ARTiSAN Software Tools 178
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 178
Distiller Types
BatchDistiller
ContinuousDistiller
©2008, ARTiSAN Software Tools 179
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 179
Distiller Problem – Package Diagram:Model Structure and Libraries
p kg [M ode l] D istille r M ode l 6 .1h1 [M ode l O ve rview ]
D istille r R equirem ents D istille r U se C ases
D istille r B ehaviour D istille r S truc ture
V alue T ypes Item T ypes
bdd [Package] Value Types1
«ValueType»Power
«Dimension»Heat Flow Rate
«Unit»cal/sec
«Dimension»Specific Heat
«Unit»cal/(gm*DegreeCelcius)
«Dimension»Latent Heat
«Unit»cal/gram
«ValueType»Real
«ValueType»
dimensionThermodynamicTemperature
unitDegreeCelsius
temp«ValueType»
dimensionPressure
unitN/M^2
press«ValueType»
dimensionMass Flow Rate
unitgm/sec
massFlowRate«ValueType»
dimensionHeat Flow Rate
unitcal/sec
dQ/dt
«ValueType»efficiency
«ValueType»
dimensionSpecific Heat
unitcal/(gm*DegreeCelcius)
specificHeat«ValueType»
dimensionLatent Heat
unitcal/gram
latentHeat
«Unit»N/M^2
«Dimension»Mass Flow Rate
«Unit»gm/sec
This diagram shows the structure used to build the distiller model, andemphasizes the units used.
©2008, ARTiSAN Software Tools 180
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 180
Distiller ExampleRequirements Diagram
Source
«requirement»
id#S0.0
txtDescribe a system for purifying dirty water.- Heat dirty water and condense steam are performed by a Counter Flow Heat Exchanger.- Boil dirty water is performed by a Boiler. Drain Residue is performed by a Drain.The water has properties: vol = 1 litre, density 1 gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporisation 540 cal/gm.
Original Statement
«requirement»
id#S1.0
txtThe System shall purify dirty water.
PurifyWater
«requirement»
id#S2.0
txtHeat dirty water and condensesteam are performed by a CounterFlow Heat Exchanger.
HeatExchanger «requirement»
id#S5.0
txtThe water has properties: vol = 1 litre, density 1gm/cm3, temp 20 deg C, specific heat 1cal/gm degC, heat of vaporisation 540 cal/gm.
Water Properties
«requirement»
id#S3.0
txtBoil dirty water is performed by a Boiler.
Boiler
«requirement»
id#S4.0
txtDrain residue is performed by a Drain.
Drain
«requirement»
id#S5.1
txtWater has an initial temp of 20degrees C.
WaterInitialTemp
«requirement»
id#D1.0
txtThe System shall purify water by boiling water.
Distill Water
The requirementfor a boilingfunction and aboiler impliesthat the watermust be purifiedby distillation.
req [Package] Distiller Requirements 1
«deriveReqt»
This diagram shows the Distiller Specification (including some rationale for whya distiller is an appropriate way to purify water), and a formal documentation forrelated assumptions, which are treated as requirements in this example.
©2008, ARTiSAN Software Tools 181
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 181
Distiller Example:Requirements Tables
id name textS0.0 OriginalStatement Describe a system for purifying dirty water. …S1.0 PurifyWater The system shall purify dirty water.S2.0 HeatExchanger Heat dirty water and condense steam are performed by a …S3.0 Boiler Boil dirty water is performed by a Boiler.S4.0 Drain Drain residue is performed by a Drain.S5.0 WaterProperties water has properties: density 1 gm/cm3, temp 20 deg C, …S5.1 WaterInitialTemp water has an initial temp 20 deg C
Tables will be used more often than requirements diagrams, because they aremore compact and more scaleable.
©2008, ARTiSAN Software Tools 182
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 182
Distiller Example – Activity Diagram:Start Point : Control-Driven Serial Behavior
BatchDistiller
«effbd»act [activity] Distill Water [Serial Behavior]
coldDirty : H2O[Liquid]
recovered : Heata1 : Heat Water
a2 : Boil Water
a3 : Condense Steama4 : Drain Residue
external : Heat
pure : H2O[Liquid]
loPress : Residue
steam : H2O[G as ]
hotDirty : H20[Liquid]
hiPress : Residue
coldDirty : H2O[Liquid]
recovered : Heata1 : Heat Water
a2 : Boil Water
a3 : Condense Steama4 : Drain Residue
external : Heat
pure : H2O[Liquid]
loPress : Residue
steam : H2O[G as ]
hotDirty : H20[Liquid]
hiPress : Residue
Activity(Function)
Control(Sequence)
Things that flow(Object Nodes)
This activity diagram follows the optional SysML EFFBD profile, and formalizes thediagram in the problem statement.
©2008, ARTiSAN Software Tools 183
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 183
«Block»
valuescal/sec : dQ/dt
Item Types::Heat«Block»
valuesdegrees C : tempgm/sec : massFlowRatekg/gm^2 : press
Item Types::Residue
«Activity»Heat Water
«Activity»Distill Water
«Activity»Boil Water
«Activity»Condense Steam
«Activity»Drain Residue «Block»
Item Types::H2O
«BlockProperty» cal/gm : specificHeat«BlockProperty» cal/(gm*deg C) : latentHeatRemove Latent Heat of Vaporisation ()Add Latent Heat of Vaporisation ()
1
1
hotDirty : H20
1
1
pure : H2O
1
1
recovered : Heat 1
1
hiPress : Residue
1
1
loPress : Residue1
1
external : Heat1
1
steam : H2O
1a1 : Heat Water
1 a2 : Boil Water
1 a3 : Condense Steam 1a4 : Drain Residue1
1
coldDirty : H2O
bdd [package] DistillerBehavior [Distiller Behaviour Breakdown]
Distiller Example – Block DefinitionDiagram: Distillerbehavior
Control(not shown on BDD)
Need toconsiderphasesof H20
Activities(Functions)
Things that flow (ObjectNodes)
This block definition diagram defines all the elements used in the activitydiagram. This allows some elaboration of properties of the water that flowsthrough the system. This shows the need to consider the water in both liquid andgaseous phase… the next diagram will formalize these phases in a finite statemachine.
©2008, ARTiSAN Software Tools 184
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 184
stm [Block] H2O1
Gas
Liquid
Solid
Remove Latent Heat of Vaporisation/Add Latent Heat of Vaporisation/
Remove Latent Heat of Vaporisation/Add Latent Heat of Vaporisation/
Distiller Example – State MachineDiagram: States of H2O
Transitions
States
This state machine diagram formalizes the states of H2O as it flows through thesystem. Change of state requires adding or removing latent heat.
©2008, ARTiSAN Software Tools 185
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 185
Distiller Example – Activity Diagram:I/O Driven: Continuous Parallel Behavior
Continuous Distiller
act [activity] Distill Water [Continuous Parallel Behavior]
pure : H2O[L iquid]
external : Heat
coldDirty : H2O[L iquid]
loPress : Residue
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid]
steam : H2O[G as]
hiPress : Residue
pure : H2O[L iquid]
external : Heat
coldDirty : H2O[L iquid]
loPress : Residue
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid]
steam : H2O[G as]
hiPress : Residue
It makes sense for the distiller design to allow a continuous flow of water throughthe system, rather than only discrete increments of water. The previous activitydiagram (EFFBD) has been recast to support continuous flow. Dirty H2O andHeat are inputs to the system, Pure H2O and Residue are outputs.
©2008, ARTiSAN Software Tools 186
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 186
Distiller Example – Activity Diagram:No Control Flow – Simultaneous Behavior
act [activity] Distill Water [Simultaneous Behavior]
pure : H2O[Liquid ]
«continuous»
external : Heat«continuous»
coldDirty : H2O[Liquid]
«continuous»
loPress : Residue«continuous»
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid ]
«continuous»steam : H2O
[G as ]
«continuous»
hiPress : Residue
«continuous»
ShutDown pure : H2O[Liquid ]
«continuous»
external : Heat«continuous»
coldDirty : H2O[Liquid]
«continuous»
loPress : Residue«continuous»
a1 : Heat Water a3 : Condense Steam
a2 : Boil Water
a4 : Drain Residue
recovered : Heat
hotDirty : H20[Liquid ]
«continuous»steam : H2O
[G as ]
«continuous»
hiPress : Residue
«continuous»
ShutDown
This diagram is semantically equivalent to the previous diagram, but clearer andeasier to read.
©2008, ARTiSAN Software Tools 187
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 187
bdd [Package] Distiller Structure [Structural Breakdown]
«Block»Boiler
«Block»Valve
«Block»
valuesdegrees C : tempgm/sec : massFlowRatekg/gm^2 : press
Item Types::Fluid«Block»
valuescal/sec : dQ/dt
Item Types::Heat«Block»
operationsTurnOn ()TurnOff ()
Distiller
«Block»Heat Exchanger
hx1 bx1 drain
satisfies«requirement» HeatExchanger
satisfies«requirement» Boiler
satisfies«requirement» Drain
Distiller Example – Block DefinitionDiagram: DistillerStructure
Generic Subsystems(Blocks)
Usage (Part) Names(Roles)
Generic ThingsThat Flow(Blocks)
The problem statement includes the initial product structure (Counter Flow HeatExchanger, Boiler, Drain), which are defined in this Block Definition Diagram.
©2008, ARTiSAN Software Tools 188
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 188
Distiller Example – Activity Diagram(allocation with swimlanes): DistillWater
act[activity] DistillWater[SimultaneousBehaviorwithAllocations]
hx1
ShutDown
steam : H2O[ G as ]
«continuous»
hotDirty : H20[ L iquid]
«continuous»
recovered : Heat
a3 : Condense Steam«streaming»
a1 : Heat Water«streaming»
coldDirty : H2O[ L iquid]
«continuous»
external : Heat«continuous»
: Heat Exchanger
«allocate»drain
a4 : Drain Residue
pure : H2O[Liquid ]
«continuous»
loPress : Residue«continuous»
:V a lve
«allocate»bx1
a2 : Boil Water«streaming»
hiPress : Residue«continuous»
: B oiler
«allocate»hx1
ShutDown
steam : H2O[ G as ]
«continuous»
hotDirty : H20[ L iquid]
«continuous»
recovered : Heat
a3 : Condense Steam«streaming»
a1 : Heat Water«streaming»
coldDirty : H2O[ L iquid]
«continuous»
external : Heat«continuous»
: Heat Exchanger
«allocate»
ShutDown
steam : H2O[ G as ]
«continuous»
hotDirty : H20[ L iquid]
«continuous»
recovered : Heat
a3 : Condense Steam«streaming»
a1 : Heat Water«streaming»
coldDirty : H2O[ L iquid]
«continuous»
external : Heat«continuous»
drain
a4 : Drain Residue
pure : H2O[Liquid ]
«continuous»
loPress : Residue«continuous»
:V a lve
«allocate»
a4 : Drain Residue
pure : H2O[Liquid ]
«continuous»
loPress : Residue«continuous»
bx1
a2 : Boil Water«streaming»
hiPress : Residue«continuous»
: B oiler
«allocate»
a2 : Boil Water«streaming»
hiPress : Residue«continuous»
Parts (Roles)
The previous Activity Diagram has been elaborated withAllocateActivityPartitions, showing how actions are allocated to blocks (parts).
©2008, ARTiSAN Software Tools 189
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 189
ibd [Block] Distiller [Initial with Item Flows]
«Block»Distiller
DSDirty_Out : H2O
«BlockProperty»bx1 : Boiler
BLHotDirty_In : H2O
BLSteam_Out : H2O
BLSteam_Out2 : Residue
BLPower_In : Power
BLExcess : H2O«BlockProperty»
drain : Valve
Fluid_In : Fluid Fluid_Out : Fluid
«BlockProperty»hx1 : Heat Exchanger
HEDirtyIn : H2O
HEClean_Out : H2O HEHotDirty_Out : H2O
HESteam_In : H2O
DSResidue_Out : Residue
DSClean_Out : H2O
DSPower_In : PowerDSExcess
DSDirty_Out : H2O
«BlockProperty»bx1 : Boiler
BLHotDirty_In : H2O
BLSteam_Out : H2O
BLSteam_Out2 : Residue
BLPower_In : Power
BLExcess : H2O
BLHotDirty_In : H2O
BLSteam_Out : H2O
BLSteam_Out2 : Residue
BLPower_In : Power
BLExcess : H2O«BlockProperty»
drain : Valve
Fluid_In : Fluid Fluid_Out : FluidFluid_In : Fluid Fluid_Out : Fluid
«BlockProperty»hx1 : Heat Exchanger
HEDirtyIn : H2O
HEClean_Out : H2O HEHotDirty_Out : H2O
HESteam_In : H2OHEDirtyIn : H2O
HEClean_Out : H2O HEHotDirty_Out : H2O
HESteam_In : H2O
DSResidue_Out : Residue
DSClean_Out : H2O
DSPower_In : PowerDSExcess
: H2O«ItemFlow»: H2O«ItemFlow»
: H2O«ItemFlow»: H2O«ItemFlow»
: H2O«ItemFlow»: H2O«ItemFlow»
: H2O«ItemFlow»: H2O«ItemFlow»
: Residue«ItemFlow»: Residue«ItemFlow» : Residue
«ItemFlow»: Residue«ItemFlow»
: Power«ItemFlow»: Power«ItemFlow»
: H2O«ItemFlow»: H2O«ItemFlow»
Distiller Example – Internal BlockDiagram: Distiller Initial Design
Parts(Blocks usedin context) Flow Ports
Things That FlowIn Context
(ItemFlows)
Connectors
This internal block diagram now shows how the parts are connected in thedistiller system. These flows are notional, and provide the initial basis forinterface specifications – note that they merely indicate direction of flow for eachinput/output… they don’t directly relate to the activity model yet. These flowswill later be referenced in a parametric heat balance analysis.
The flow ports can start to place restrictions on pressure, temperature, etc., whichwill be necessary to manufacture or procure these parts.
©2008, ARTiSAN Software Tools 190
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 190
ibd [Block] Distiller [with Allocation]
«Block»Distiller
«BlockProperty»bx1 : Boiler
allocatedFroma2 : Boil Water
«BlockProperty»drain : Valve
allocatedFroma4 : Drain Residue
«BlockProperty»hx1 : Heat Exchanger
allocatedFroma3 : Condense Steama1 : Heat Water
«BlockProperty»bx1 : Boiler
allocatedFroma2 : Boil Water
«BlockProperty»drain : Valve
allocatedFroma4 : Drain Residue
«BlockProperty»hx1 : Heat Exchanger
allocatedFroma3 : Condense Steama1 : Heat Water
m4 : H2Om4 : H2O
m1 : H2Om1 : H2O m3 : H2Om3 : H2O
m2 : H2Om2 : H2O
ItemFlow1 : H2OItemFlow1 : H2O
Q1 : PowerQ1 : Power
s1 : Residues1 : Residue
s2 : Residues2 : Residue
allocatedFromcoldDirty : H2O allocatedFrom
external : Heat
allocatedFromhotDirty : H20
allocatedFromsteam : H2O
allocatedFrompure : H2O
allocatedFromhiPress : Residue
allocatedFromloPress : Residue
Distiller Example –Internal BlockDiagram: Distiller with Allocation
Allocation Compartment(references Activities)
Allocation Callout(references Object Nodes)
This internal block diagram is now annotated with allocations from the previous“swimlane” diagram, accounting for flow allocation.
©2008, ARTiSAN Software Tools 191
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 191
Distiller Example – ParametricDiagram: Heat Balance Equations
ValueProperties
Constraintcallouts
Constraints
Parts orItemFlows
ValueBindings
This parametric diagram helps the systems engineer to visualize the heat balanceof an isobaric (constant pressure) distiller system. This is an appropriate first-order approximation of the heat flow required to make the distiller functionproperly. The values referenced relate to the flows shown on the system internalblock diagram.
©2008, ARTiSAN Software Tools 192
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 192
Distiller Example – Heat BalanceResults
table IsobaricHeatBalance1 [Results of Isobaric Heat Balance]
specific heat cal/gm-°C 1latent heat cal/cm 540
wat
er_
in
hx_
wa
ter_
out
bx_
wa
ter_
in
bx_
stea
m_
out
wat
er_
out
mass flow rate gm/sec 6.75 6.75 1 1 1temp °C 20 100 100 100 100
dQ/dt cooling water cal/sec 540dQ/dt steam-condensate cal/sec 540condenser efficency 1heat deficit 0
dQ/dt condensate-steam cal/sec 540boiler efficiency 1dQ/dt in boiler cal/sec 540
Note: Cooling waterneeds to have 6x flowof steam!Need bypass betweenhx_water_out andbx_water_in!
Satisfies «requirement»WaterSpecificHeatSatisfies «requirement»WaterHeatOfVaporization
Satisfies «requirement»WaterInitialTemp
• Not a SysMLdiagram
• Constructed fromSysML diagraminformation
• Can be held inStudio a a textdiagram
This table was generated using the equations stated in the parametric diagram. Itis important to note that, in order to get the heat equations to balance, that 6.75times more water than steam is required to flow through the heat exchanger. Thedesign shown on the previous internal block diagram doesn’t allow this, so amodification must be made to the design in order to allow a bypass between theheat exchanger and the boiler.
©2008, ARTiSAN Software Tools 193
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 193
Distiller Example – ActivityDiagram: Updated DistillWater
act [activity]Distill Water [Updated Simultaneous Behavior with Allocations]
drain
pure : H2O[ Liquid]
«continuous»
loPress : Residue«continuous»a4 : Drain Residue
hotDirty2 : H20[ Liquid]
«continuous»
hiPress : Residue
«continuous»
:V alve
«allocate»
bx1
a2 : Boil Water«streaming»
hotDirty1 : H2O[ Liquid]
«continuous»
:B oiler
«allocate»
feed
steam : H2O[G as ]
«continuous»
a5 : Divert Feed
:V alve
«allocate»
drain
pure : H2O[ Liquid]
«continuous»
loPress : Residue«continuous»a4 : Drain Residue
hotDirty2 : H20[ Liquid]
«continuous»
hiPress : Residue
«continuous»
:V alve
«allocate»
pure : H2O[ Liquid]
«continuous»
loPress : Residue«continuous»a4 : Drain Residue
hotDirty2 : H20[ Liquid]
«continuous»
hiPress : Residue
«continuous»
bx1
a2 : Boil Water«streaming»
hotDirty1 : H2O[ Liquid]
«continuous»
:B oiler
«allocate»
a2 : Boil Water«streaming»
hotDirty1 : H2O[ Liquid]
«continuous»
feed
steam : H2O[G as ]
«continuous»
a5 : Divert Feed
:V alve
«allocate»
steam : H2O[G as ]
«continuous»
a5 : Divert Feed
hx1
external : Heat«continuous»
coldDirty : H2O[ L iquid]
«continuous»
a1 : Heat Water«streaming»
a3 : Condense Steam«streaming»
recovered : Heat
hotDirty : H20[ Liquid]
«continuous»
ShutDown
: Heat Exchanger
«allocate»
external : Heat«continuous»
coldDirty : H2O[ L iquid]
«continuous»
a1 : Heat Water«streaming»
a3 : Condense Steam«streaming»
recovered : Heat
hotDirty : H20[ Liquid]
«continuous»
ShutDown
added as a result of parametric analysis
The “Divert Feed” activity has been allocated to the feed valve, “hotDirty:H2O”to the boiler has been updated to “hotDirty1:H2O”, and “hotDirty2:H2O” is nowan additional output. hotDirty = hotDirty1+hotDirty2.
©2008, ARTiSAN Software Tools 194
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 194
Distiller Example – Internal BlockDiagram: Updated Distiller
ibd [Block] Distiller [with Allocation - Updated]
«Block»Distiller
«BlockProperty»bx1 : Boiler
allocatedFroma2 : Boil Water
«BlockProperty»drain : Valve
allocatedFroma4 : Drain Residue
«BlockProperty»hx1 : Heat Exchanger
allocatedFroma3 : Condense Steama1 : Heat Water
«BlockProperty»feed : Valve
allocatedFroma5 : Divert Feed
«BlockProperty»bx1 : Boiler
allocatedFroma2 : Boil Water
«BlockProperty»drain : Valve
allocatedFroma4 : Drain Residue
«BlockProperty»hx1 : Heat Exchanger
allocatedFroma3 : Condense Steama1 : Heat Water
«BlockProperty»feed : Valve
allocatedFroma5 : Divert Feed
m1 : H2Om1 : H2O
m4 : H2Om4 : H2O
m3 : H2Om3 : H2O
Q1 : PowerQ1 : Power
s1 : Residues1 : Residue
s2 : Residues2 : Residue
m2-1 : H2Om2-1 : H2O
m2-2 : H2Om2-2 : H2O
m2-1 : H2Om2-1 : H2O
allocatedFromhotDirty1 : H2O
allocatedFromhotDirty1 : H2O
allocatedFromhotDirty2 : H20
added as a result of parametric analysis
An additional port must be added to the HeatExchanger, allowing waste_water toflow out of the system. Note that the functional and flow allocations have beenupdated.
©2008, ARTiSAN Software Tools 195
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 195
Distiller Example – Use Case andSequence Diagrams
ucd Distiller Use Cases
UserOperateDistiller
Description:Distiller«Block»
Distiller.ui1:Control Panel«BlockProperty»User
press start StartUpturn on Distiller TurnOndistill water ref Distill Water [detail]
press stop ShutDownturn off Distiller TurnOff
seq Operate Distiller [high level]
©2008, ARTiSAN Software Tools 196
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 196
Distiller Example – Internal BlockDiagram: Distiller Controller
ibd [Block] Distiller [with Controller]
«Block»Distiller
«BlockProperty»bx1 : Boiler
blrSig
«BlockProperty»drain : Valve
«BlockProperty»feed : Valve
«BlockProperty»hx1 : Heat Exchanger
«BlockProperty»ui1 : Control Panel
«BlockProperty»cx1 : Controller
blrSig
IPower
ILamp ILamp
IPower
IValve
IValve
IValve IValve
m4 : H2O
m1 : H2O
m2-1 : H2O
m2-2 : H2O
m3 : H2O
m2-1 : H2O s1 : Residue
s2 : Residue
p1 : Power b1 : Power
We now enhance our view of the Distiller structure by adding a Controller andassociated Control Panel.
©2008, ARTiSAN Software Tools 197
Introduction to SysML
Copyright © 2006 ARTISAN Software Tools All Rights ReservedSlide 197
Distiller Example – State MachineDiagram: Distiller Controller
stm [block] Distiller Controller [Distiller States]
OffEntry/pwrLightOFF
FillingEntry/Open Feed : IValve
Warming UpEntry /bxHtrON
DistillingEntry/bxHtrON
Controlling Boiler Level
Level OKEntry/Close Drain : IValve;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level LowEntry/Open Feed : IValve
Controlling Boiler Residue
Building Up ResidueEntry/Close Drain : IValve
Purging ResidueEntry/Open Drain : IValve
Controlling Boiler Level
Level OKEntry/Close Drain : IValve;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level LowEntry/Open Feed : IValve
Level OKEntry/Close Drain : IValve;Close Fill : IValve
Level HighEntry/Open Drain : IValve
Level LowEntry/Open Feed : IValve
Controlling Boiler Residue
Building Up ResidueEntry/Close Drain : IValve
Purging ResidueEntry/Open Drain : IValve
Building Up ResidueEntry/Close Drain : IValve
Purging ResidueEntry/Open Drain : IValve
DrainingEntry/Open Drain : IValve
Cooling OffEntry/bxHtrOFF;Open Drain : IValve;Open Fill : IValve
pw rO n/
[NOT bxLevelLow]/
[bxTemp = 100degrees]/
[NOT bxLevelLow]/
[bxLevelLow]/
[bxLevelHigh]/
[NOT bxLevelHigh]/
/
DrainTim er/
Res idueTimer/
[bxLevelBelow]/[bxTemp < 100degrees]/
shutDown/
This final diagram capture the state based behavior of the Distiller through Controllerdetected events.
©2008, ARTiSAN Software Tools 198
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 198
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
©2008, ARTiSAN Software Tools 199
Introduction to SysML
C opyright© 2006 ARTISAN Software Tools All Rights ReservedSlide 199
Systems Modeling Activities - OOSEM
SynthesizePhysical
Architecture
DefineSystem
Requirements
DefineLogical
ArchitectureOptimize &Evaluate
Alternatives
Validate &Verify
System
AnalyzeNeeds Major SE Development Activities
Common Subactivities
•Engr Analysis Models•Trade studies
•Test cases/procedures
•Mission use cases/scenarios•Enterprise model
•System use cases/scenarios•Elaborated context•Req’ts diagram
•Logical architecture
•Node diagram•HW, SW, Data architecture
Copyright © Lockheed Martin Corporation 2000 – 2003 & INCOSE 2004-2006
Use ISSEP chart for Design and Verify System activity.Note: Mention IPT.
Try to show SE and software on same page
-- Highlight differences.
©2008, ARTiSAN Software Tools 200
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 200
Using Process ImprovementTo Transition to SysML
©2008, ARTiSAN Software Tools 201
Introduction to SysML
Copyright © 2006ARTISAN Software Tools All Rights ReservedSlide 201
Integrated Tool Environment
Project Management
CM
/DM
Pro
duct
Dat
aM
anag
emen
t
Req
uire
men
tsM
anag
emen
t
Engi
neer
ing
Per
form
ance
Ana
lysi
s
Ver
ific
atio
n&
Val
idat
ion
SoS / DoDAF / Business Process modeling
System modelingSysML
Software modelingUML 2
Hardware modelingVHDL, CAD, .. S
peci
alty
Engi
neer
ing
Ana
lysi
s