An Introduction to OMG Systems Modeling Lang · • Is a visual modeling language that provides ... Grumman, oose.de, Raytheon, THALES • Vendors – Artisan, EmbeddedPlus, Gentleware,
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
• 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)
• 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
• 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.
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.
• 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.
• 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
• Describes the essential characteristics of thecustomers goals
• Requirements should be problem based and notdescribe the solution. However, if there aresolution based elements in the requirements,these must be modelled and included in thesolution.
The SysML Requirements DiagramWhat is it used for?
• The Requirements diagram can be used for a varietyof purposes throughout the system lifecycle:– Traditional text requirements and their properties (e.g., id,
statement, criticality, etc)– Grouping a set of requirements in a package– Breaking down requirements into constituent elements– Demonstrating traceability between derived and source
requirements– Showing which design elements satisfy which requirements– Verification of a requirement, or design element by a test case– Rationale for all of the above
How the requirements diagram is used will vary depending on the industry,company, project, and process. It’s main strength is in its ability to graphicallyrepresent requirements and how they pertain to the rest of the UML model.
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.
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
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.
• Based on UML Class from UML Composite Structure– Eliminates association classes, etc.– Differentiates value properties from part properties, add nested
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.
• 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
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.
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.
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.
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.
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
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.
It is very important to describe each use case thoroughly and in simple English.This description should be signed off by the user. This description also acts as astarting point for a more structured breakdown of the use case in later stages ofdevelopment. For this it can be useful if the description employs a ‘subject - verb- object’ format, e.g. ‘customer inserts card’.
Use Case: 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
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.
«include» relationship extractscommon courses of action
• Common behavior may be extracted from otheruse cases
• Defines a ‘must be done’ relationship
• Simplifies change
*
Card Validation
TransferFunds
WithdrawFunds
Deposit Funds
«include»«include»
«include»
An «include» relationship can be thought of as a subroutine type of relationship.In order to Withdraw Funds, Transfer Funds or Deposit Funds, it is essential tocarry out a Card Insertion.
«extend» relationship modelsoptional courses of action
• Model an optional part of a usecase
• Allows introduction of separatesub-courses without affectingcourse of activity in base usecase
• Defines a ‘may get done’relationship
Bank CardTransaction
Reject InvalidCard
«extend»
In the example we have shown a base use case (Bank Card Transaction) and asubordinate ‘extended’ use case (Reject Invalid Card). Reject Invalid Card willonly be invoked from Bank Card Transaction in exceptional circumstances.
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.
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.
• “Activity modelling emphasizes the inputs, outputs, sequences,and conditions for coordinating other behaviors.” (SysML)– ‘behavior’ as in something the system does– describes flow of activity and data– can link activity elements to owning block
• An activity diagram is owned by an activity and describes the detailof that activity
• Useful for many purposes, including:– Exploring system functionality– Human/subsystem communication modelling– Data/item flow modelling– General flow of control modelling– etc.
Activity modeling is one of the principal means for describing behavior inSysML. This behavior can be linked with structural modeling (blocks)through allocations which will be covered later in the course.
In practice, activity diagrams can be used for a surprisingly wide variety ofmodeling purposes. For systems engineering, exploring system functionalityis one of the principal uses of these diagrams.
• SysML activity modelling 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.
• 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]
• 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.
• 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.
• 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.
• 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.
• Pins are kinds of Object Nodes– Used to specify inputs and outputs of actions– Typed by a block or data type
• Object flows between pins have two diagrammatic forms– Pins shown with object flow between– Pins hidden and object node shown with flow arrows in and out
ObjectNodePins (must be samename & type)
AJM4
Slide 75
AJM4 right-hand diagram should have action:activity like the left-hand one.Alan Moore, 5/17/2006
• Accept Event– shows a signal that initiates activity in action node– may also link to action object (sender)
• Examples:
Send Signal and Accept Event
• Send Signal– shows a signal sent at completion of action node activity– may also link to action object (receiver)
Send Signal
Accept Event
re-open door
door interruptDoor
Signal send and accept event boxes correspond to the concept of a ‘signal’ eventon a state diagram. The ‘send’ represents a signal sent at completion of theactivity in the preceding action node; an ‘accept’ represents a signal that triggersthe activity of the subsequent action node.
A ‘send’ may also have an object flow going to the object that receives the signal;an ‘accept’ may have an object flow coming from the object that sends the signal.
Dragging an RtS event onto an activity diagram creates a send signal; itsproperties can then be used to change it to an accept event if required.
• 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.
• 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.
• 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
• «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..
• Defines value (range: 0 – 1) forprobability of any flow being taken– Total of values from one node must
equal 1
• Can also be applied to output parameterset from node– With same value constraints
action 1
action 2a action 2b
action 1
action 2a action 2b
«probability»«probability»p (x )
«probability»«probability»1-p(x )
When the «probability» stereotype is applied to edges coming out of decisionnodes and object nodes, it provides an expression for the probability that theedge will be traversed. These must be between zero and one inclusive, andadd up to one for edges with same source at the time the probabilities areused. When the «probability» stereotype is applied to output parameter sets,it gives the probability the parameter set will be given values at runtime.These must be between zero and one inclusive, and add up to one for outputparameter sets of the same behavior at the time the probabilities are used.[SysML]
Activity Diagram – Distiller Example: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).
– 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).
• 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.
• 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.
• 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.
• 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.
• 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.
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.
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.
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.
• 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.
• 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.
• 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.
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).
• 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.
• 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.
• 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.
• 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.
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.
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.
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.
«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?
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.
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]
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.
• 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
Defining reusable equations for Parametrics usingconstraint blocks on a block definition diagram
A constraint block is a block that packages the statement of a constraint so itmay be applied in a reusable way to constrain properties of other blocks. Aconstraint block includes the definition of one or more parameters which canbe bound to properties in a specific context where the constraint is used. In acontaining block where the constraint is used, the constraint block is used totype a property that holds the usage. A constraint parameter is a property ofa constraint block which may be bound to a property in a surrounding usagecontext. All properties of a constraint block define parameters of theconstraint block, with the exception of constraint properties that holdinternally nested usages of other constraint blocks. [SysML]
Parametric Diagram – Example 1Vehicle Dynamics Analysis
Using theEquations ina ParametricDiagram toConstrain
ValueProperties
A parametric diagram is defined as a restricted form of internal block diagram. Aparametric diagram may contain constraint properties and their parameters, alongwith other properties from within the internal block context. All properties thatappear, other than the constraints themselves, must either be bound directly to aconstraint parameter, or contain a property that is bound to one (through anynumber of levels of containment). [SysML]
Parametric Diagram – Example 2Direction Cosine Matrix
This diagram represents the conversion of Aircraft Heading (in Inertial Axes) into AircraftHeading (in Body Axes) using a Direction Cosine Matrix. The stereotype «constraint»contains the Direction Cosine Matrix (DCM).
The underlying data-types of each«constraintProperty»are captured. In thisexample,Aircraft.Inertial Headingis a Vector [x, y, z].
The type Vector isdefined elsewhere inthe design (as part ofthe Data-Model).
• 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)
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.
• 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.
• 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.
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.
txtThe System shall prevent a car fromentering if the parking lot is full.
REQ_1«requirement»
txtThe software shall input and store themaximum capacity value for the parking lot.
REQ_1_SW1
«requirement»
txtThe software shall maintain a count of carscurrently in the parking lot.
REQ_1_SW2
«requirement»
txtOn detecting a car arriving, the softwareshall compare current count value againstmaximum capacity to determine whetherthe car should be allowed to enter.
REQ_1_ SW3
req [Package] Reqts
«deriveReqt»
«deriveReqt»
«deriveReqt»
Software Requirements fromSystem Requirements
SystemRequirement
DerivedSoftware
Requirements
The SysML requirements diagram can show both system and (derived) softwarerequirements. In Studio, requirements diagrams can also be held in a UMLmodel.
A Context Diagram allows the software engineers to identify all inputs andoutputs that the software (to reside in a ‘black-box’ Control System) will need tohandle. Essential details for each item of input or output can be captured throughproperties.
SysML internal block diagrams and activity diagrams are the chief source ofinformation for the construction of the Context Diagram.
System Interaction Diagrams SpecifyRequired Use Case Behavior
Use Parking LotDescription Barrier Motor Entry Beam SensorGreen Light Pressure SensorRed Light Control SystemCar
entry beam detects car car breaks beambeam sensor signals controller break
check for spaceIf full
suspend entry Car WaitsEndIf
open barrier raise{3ms}turn off red light set red( off )turn on green light set green( on )
car passes through beam car passes throughbeam sensor signals controller connect
increment car countclose barrier lowerturn off green light set green( off )turn on red light
max. {50ms}
set red( on )car triggers pressure sensor car triggers sensorpressure sensor signals controller detect
decrement car count
systemboundary
architecturalboundary
timingconstraint
Context Diagram ‘devices’
This diagram specifies the required ‘black-box’ behavior of the Control Systemfor the Use Parking Lot use case. One system interaction diagram is produced foreach software use case. The diagram defines the sequence of IO for the‘hardware’ elements defined on the Context diagram.
We now move into software design. A sequence diagram is produced for eachuse case, using candidate software objects. The purpose of these diagrams is toidentify software objects and the operations they will need to support to deliveruse case functionality. Detailed information (synchronicity, message parameters,data types, etc.) can be added as these diagrams are developed iteratively.
The note on the diagram is referring to a previous system interaction diagramwhich captured implicit hardware interactions specified for this same use case.
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.
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).
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.
As the software design becomes more detailed, implementation concerns start toappear in the class model. However these additions should not alter thefundamental (and traceable back to use cases) properties and relationships of theapplications classes.Composition has been used to reflect the active objects ‘owning’ their parts.
Otherwise little has changed other than the addition of the RTOS wrapper classesand their restricted access via the active object classes that use them.
The creation of the class model is often seen as key. Code can be generated orproduced from information in the class model. Language profiles allow morecode related information to be held within the model.
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.
• 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
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.
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
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.
• 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.
• 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.
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.
id name textS0.0 OriginalStatement Describe a system for purifying dirty water. …S1.0 PurifyWater The system shall purify dirty water.S2.0 HeatExchanger Heat dirty water and condense steam are performed by a …S3.0 Boiler Boil dirty water is performed by a Boiler.S4.0 Drain Drain residue is performed by a Drain.S5.0 WaterProperties water has properties: density 1 gm/cm3, temp 20 deg C, …S5.1 WaterInitialTemp water has an initial temp 20 deg C
Tables will be used more often than requirements diagrams, because they aremore compact and more scaleable.
Distiller Example – 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.
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.
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.
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.
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.
This table was generated using the equations stated in the parametric diagram. Itis important to note that, in order to get the heat equations to balance, that 6.75times more water than steam is required to flow through the heat exchanger. Thedesign shown on the previous internal block diagram doesn’t allow this, so amodification must be made to the design in order to allow a bypass between theheat exchanger and the boiler.
Distiller Example – ActivityDiagram: Updated DistillWater
act [activity]Distill Water [Updated Simultaneous Behavior with Allocations]
drain
pure : H2O[ Liquid]
«continuous»
loPress : Residue«continuous»a4 : Drain Residue
hotDirty2 : H20[ Liquid]
«continuous»
hiPress : Residue
«continuous»
:V alve
«allocate»
bx1
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.
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.