Sysml Tutorial

Systems Modeling Language Overview
May 20, 2005
Objective
Provide overview of SysML specification Caveat

This material is based on Draft V0.9 of the SysML specification and is still subject to change
http://www.sysml.org
Presentation Outline

Background UML for SE Requirements SysML Design Approach Diagram Summary Diagram Descriptions SysML/AP-233 Alignment Future Directions with SysML Wrap-up
http://www.sysml.org 3
Background
SE Practices for Describing Systems

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

These 3 standards organizations are influencing the future of systems engineering
What does this mean to the future of tools for software development?
Who are these organizations, and why do I care what they are doing?
Why Model Based Approach ?

Improved communications Reduced ambiguity Reduced errors More complete representation Reduced maintenance costs Enhanced knowledge capture
Applying the Model Based Approach

Model based approach More rigorous and precise than traditional paper specifications and design documentation Can take more time up front Implementation Set stakeholder expectations up front (PM, customer, development team) Provide adequate tool and training support Use an incremental process to evolve the system models and manage the scope of the effort
Why UML for Systems Engineering ?

De-facto standard within the software community Robust and extensible language to adapt to SE needs OMG Infrastructure Broad international and industry representation Defined adoption process to evolve UML Part of larger family of MDA standards Availability of tool vendor and training support http://www.sysml.org
Unified Modeling Language (UML)

UML

Is a visual modeling language Is not a methodology Defacto standard for SW level OO modeling
Visual Modeling Language = Notation + Semantics

Semantics = meaning Notation = representation of meaning

The OMG Process
RFI optional Issued by Task Forces
RFI responses submitted by any interested party, evaluated by working groups
RFP
RFP responses, known as submissions
Published Specification
Finalization Task Force
Approved Submission
Reviews
11
The RFI is an optional process used by a subgroup to canvass a targeted industry segment for one or more of the following purposes: Acquiring general or specific information about industry requirements. Soliciting assistance in identifying potential technology sources. Soliciting input to and validate a subgroups roadmap. Generally speaking, the RFI process determines which Request For Proposals (RFPs) get issued (and, based on negative feedback, which don't) or influences the way a particular RFP is constructed.
UML Versions
1.0 Original submittal

Never released First approved standard Changed the presentation but not the technical content Clarifications and corrections Final document released in August 2001 Added Action Language Semantics
1.1 UML Partners final submittal

1.2 Editorial clean-up (1998)

1.3 Revisions, not enhancements

1.4 Revision Task Force completed assignment

1.5 Another RTF chartered

Jan 1997 - 1.0 July 1997 - 1.1 final submittal Nov. 1997 - 1.1 approved June 1998 - 1.2 Fall 1998 - 1.3 Changes to 1.4 include methods to specify components and collaborations and, perhaps most importantly, profiles -- ways to customize and extend UML by defining stereotypes. 2.0 will be a more complete overhaul, with changes anticipated in the language infrastructure and superstructure, object constraint language and diagram interchangeability (standards for placement, grouping, fonts and other aspects).
UML 2.0
3 UML 2.0 RFPs issued Sept. 2000

UML 2.0 Infrastructure UML 2.0 Superstructure UML 2.0 Object Constraint Language

UML 2.0 Diagram Interchange RFP - March 2001 Multiple respondents to each RFP

No single entity or group responded to all 4 RFPs Reviews of the proposals complicated by the fact that there are a lot of disparate views to bring together Revision Task Force formed immediately after approval vote
UML 2.0 Specification finalization approved Nov. 2004

Our Ourideal ideal... ...must mustbe beaalanguage languageas asclear clearas asglassthe glasstheperson personlooking lookingout outof ofthe the window knows there is glass there, but he is not concerned with it; what concerns window knows there is glass there, but he is not concerned with it; what concerns http://www.sysml.org him other himis iswhat whatcomes comesthrough throughfrom fromthe the otherside. side. --Elizabeth ElizabethBowen Bowen
13
SysML Partners
Informal partnership of modeling tool users, vendors, etc.

organized in May 2003 to respond to UML for Systems Engineering RFP The SysML Partners are collaborating to define a modeling language for systems engineering applications, called Systems Modeling Language (SysML). SysML will customize UML 2 to support the specification, analysis, design, verification and validation of complex systems that may include hardware, software, data, personnel, procedures, and facilities.
Charter
SysML Partners (cont.)

Industry
American Systems, BAE SYSTEMS, Boeing, Deere & Company, EADS Astrium, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, Northrop Grumman, oose.de, Raytheon, THALES DoD/OSD, NASA/JPL, NIST Artisan, Ceira, Gentleware, EmbeddedPlus, IBM, I-Logix, PivotPoint Technology, Popkin, Project Technology, 3SL, Telelogic, Vitech AP-233, CCSDS, EAST, INCOSE, Rosetta
Government
Vendors
Liaisons/Other Organizations
SysML Milestones

UML for SE RFP issued March 28, 2003 Kickoff meeting May 6, 2003 Overview presentation to OMG ADTF Oct 27, 2003 Initial draft submitted to OMG Jan 12, 2004 INCOSE Review January 25-26, 2004 INCOSE Follow-up Review May 25, 2004 Revised submission to OMG August 2, 2004 2nd Revised submission to OMG October 11, 2004 3rd Revised submission to OMG January 10, 2005 INCOSE Follow-up Review January 29, 2005 Tool vendor rapid prototyping feedback April 22, 2005 (Goal)
This effort is ongoing
16
SysML Milestones (2)

May 30 (Monday)
Submit final revised submission to OMG
June 22 (Wednesday): ADTF meeting at OMG Technical Meeting (Boston, MA)

Present final revised submission
Week of July 10: INCOSE Symposium (Rochester, NY)

SysML tutorial and vendor SysML demonstrations
August 22 (Wednesday)
Plan A: Submit errata; Plan B: Submit final changes & V2V request
September 14 (Wednesday): ADTF meeting at OMG Technical Meeting (Atlanta, GA)

Vote-to-recommend (followed by PTC vote-to-recommend and formation of FTF)

17
New Phase of SysML

V0.9 represents a critical milestone

Core features have stabilized Initial vendor feedback incorporated Early vendor prototype
Begin vendor rapid prototyping phase and detailed vendor feedback in H105

Artisan EmbeddedPlus Telelogic ILogix ???? www.sysml.org
Initiate public Google forum to capture issues

18
January 04 INCOSE Comments

Review a great success!

All worked as team looking for issues, 77 found Most of SysML excellent as presented Most issues in the grass and resolvable
Progress Based on SysML Requirements. Core version of SysML identified by team seven pillars.
Note: See SysML submission for mapping of pillars to version 1.0 specification
A summary of representative issues follows. Continued close cooperation of SysML/AP233/MDSD teams.

Coordination Recommendations
INCOSE endorse SysML as INCOSEs product copyright,

ISO/SC7 standard .

Joint effort of SysML/AP233/MDSD teams to define a core version of SysML. Build a model test set that vendors can use to verify and demo. Use the case study material for verification and best practices. SysML/AP233/MDSD teams act as a unit. Continue to use some of the regular AP233 telecons to
synchronize SysML drafts and progress.
20
UML for SE Requirements
UML for SE Request For Proposal

Specifies requirements for SE modeling language Joint requirements reviewed by OMG/INCOSE/AP-233 Issued by OMG on March 28, 2003

OMG Doc# ad/03-03-41

http://syseng.omg.org/UML_for_SE_RFP.htm RFP is available to the general public
RFP
Top Level Concept Model- INCOSE

contained in (2) Category categorizes built from C (5) System View reference for Domain (3) contained in of Interest
(7) Stakeholder part of
(6) Environment (1) Element C
has view exhibits
has (8) Stakeholder satisfied by Need Interacts with allocated to statement of (10) derived from verifies (12) Behavior Verification (see figure 10) C (14) Structure C (13) Physical Property (4) System (9) C Property reference for (11) Reference Document
represented by
System Requirement
allocated to http://www.sysml.org
budgeted to
23
Scope of RFP
Focuses on general purpose system modeling

Uses the INCOSE definition of systems RFP engineering physical systems including software, information, and hardware-intensive systems system-level vs. hw/sw implementation models (code, 3D geometry, VHDL, ...) integration with discipline specific models (i.e., reliability, safety, ...)
Scope (cont.)
Systems Engineering Process, Methods, & Artifacts
Customer Reqts
Reqts Analysis Arch Design Eval Altern Verify & Validate
System Solutions
SoS SoS
Applies Appliesto to Each EachLevel Levelof ofthe the System SystemHierarchy Hierarchy
Subsystem Subsystem
System System System System System System
Subsystem
Component Specific Methods (e.g. HW, SW)
Item Item11
Item ItemN N
Item Item11
Item ItemN N
25
Requirements Summary
Structure
e.g., system hierarchy, interconnection e.g., function-based behavior, state-based behavior e.g., parametric models, time property e.g., requirements hierarchy, traceability e.g., test cases, verification results e.g., trade studies
Behavior
Properties
Requirements
Verification
Other
RFP
Evaluation Criteria

Ease of use Unambiguous Precise Complete Scalable Adaptable to different domains Capable of complete model interchange Evolvable Process and method independent Compliant with UML metamodel Verifiable
RFP
27
UML for SE RFP Requirements Traceability

UML for SE Req't #
6.5 6.5.1 6.5.1.1 6.5.1.2 6.5.1.3 6.5.1.3.1 6.5.1.3.2 6.5.1.3.3 6.5.1.4 6.5.2 6.5.2.1 6.5.2.1.1 6.5.2.1.2 6.5.2.1.3 6.5.2.2 6.5.2.2.1 6.5.2.2.2 6.5.2.2.3 6.5.2.3 6.5.2.4 6.5.2.4.1 6.5.2.5
Requirement name
SysML Diagram / Chapter
Planned Version
Mandatory Requirements Structure System hierarchy Environment System interconnection Port System boundary Connection Deployment of components to nodes Behavior Functional Transformation of Inputs to Outputs Input/Output System store Function Function activation/deactivation Control input Control operator Events and conditions Function-based behavior State-based behavior Activation time Allocation of behavior to systems
Structure Class, Assembly Class, Assembly, Use Case Class, Assembly Assembly Assembly Class, Assembly Allocation, Special Usages Appendix Behavior Activity Activity, Auxiliary, Assembly Class, Assembly; Activity, Auxiliary, Activity, Sequence, State Activity, Sequence, State Activity, Sequence, State Activity Activity, Sequence, State Activity State Activity, Timing Diagram, State Allocation, Special Usages Appendix
1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0
See SysML Requirements Traceability Appendix for Details

28
Requirements Traceability
UML for SE Req't #
6.5.3 6.5.3.1 6.5.3.2 6.5.3.3 6.5.3.4 6.5.3.5 6.5.3.6 6.5.4 6.5.4.1 6.5.4.2 6.5.4.3 6.5.4.4 6.5.4.5 6.5.4.6 6.5.5 6.5.5.1 6.5.5.2 6.5.5.3 6.5.5.4 6.5.5.5 6.5.5.6 6.5.6 6.5.6.1 6.5.6.2 6.5.6.3 6.5.6.4
(contd)
Planned Version
1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.x 1.x 1.x 1.x 1.x 1.0 1.0 1.0 1.x 1.x 1.0 1.0 1.0 1.0 1.0 29
Requirement name
Property Property type Property value Property association Time property Parametric model Probe Requirement Requirement specification Requirement properties Requirement relationships Problem Problem association Problem cause Verification Verification Process Test case Verification result Requirement verification Verification procedure Verification system Other General relationships Model views Diagram types System role
Auxiliary Auxiliary Parametric Parametric, Interactions (Timing) Parametric Assembly Requirement Requirement, Model Library Requirement, Model Library Requirement
Requirement, Behavior (Activity, Seq, State) Requirement Requirement Requirement Assembly, Class Class Auxiliary Diagram Appendix Assembly http://www.sysml.org
Requirements Traceability
UML for SE Req't #
6.6 6.6..1 6.6..2 6.6..3 6.6..4 6.6.4.1 6.6.4.2 6.6..5 6.6..6 6.6..7 6.6..8 6.6..9 6.6..10
(cont.)
Planned Version
1.0 1.x 1.0 1.x
Requirement name
Optional Requirements Topology Documentation Trade-off studies and analysis Spatial representation Spatial reference Geometric relationships Dynamic structure Executable semantics Other behavior modeling paradigms Integration with domain-specific models Testing Model Management Model
Diagram Appendix Parametric
Activity Activity, Sequence, State Parametrics, AP-233 Appendix
1.0 1.0 1.x, 2.0 1.x
30
SysML Design Approach
SysML Design Approach

Reuse and extend UML 2.0

select the subset of UML 2.0 that is reusable for SE applications add new constructs and diagrams needed for SE UML2++--
Compatible With UML 2
32
SysML Design Approach (2)

AP-233 alignment
align with evolving AP-233 SE Data Interchange Standard extend the language incrementally, using SE feedback to ensure new extensions are valid
Incremental development
33
UML 2 Reuse
UML 2 subset needed to support the UML for SE RFP requirements and evaluation criteria
reduced tool implementation requirements for SE vendors reduced training requirements for SEs Two languages can be used together by teams that include both software and system engineers
SysML complements UML 2

UML 2.0 Support for SE

Structural decomposition and interconnection

via Parts, Ports, Connectors e.g., Sequences, Activities, State Machines e.g., data and control flow constructs, activity partitions/swim lanes e.g., alternative sequences, reference sequences, interaction overview, timing diagrams
Behavior decomposition
Enhancements to Activity diagrams

Enhancements to Interaction diagrams

UML 2.0 Support for SE (cont.)

Support for information flows between components Does not preclude continuous time varying properties Improved Profile and extension mechanisms Support for model interchange, including diagrams Compliance points and levels for standardizing tool compliance

Unified Modeling Language

Originated in object-oriented software community. However:

Wide lifecycle, including logical specifications and deployment. More than pictures:

Includes a repository model/API and and XML interchange.

Behavior models with virtual machines. Not just for software modeling.
Wide Lifecycle
Logical and physical modeling

Logical entities Physical and software entities

Environment System
Requirements

Use cases Constraints Artifacts tied to specification and delivery.

Deployment

More Than Pictures

Repository provides

APIs XML interchange Support for multiple notations
UML notation stores to repository and alternate notations can, too. Generate systems from repository: Notation Repository System
Model-Centered Development
Car color : Color [1..*] +car +driver 0..* 1
Person
Class Car { color : Color [1..*; driver : Person [1..1] } Class Person { car : Car [1..*; }
Presentation
Parsing
Repository
Model compilation Actual system

Language Extension Mechanisms

Stereotypes

UMLs built-in extension mechanism similar effect to subtyping the metamodel

can add properties, but not associations

does not modify the repository schema facilitates reuse of UML modeling tool subtypes the UML 2 metamodel allows adding meta-attributes and associations standardized models provided to promote reuse (e.g., hardware component taxonomy)
Metaclass extensions

Model libaries
Profiles
Profile is a package

Selectively imports reusable UML 2 packages Adds stereotypes Can include constraints on meta-classes Implement as much as possible of SysML as a profile Get as many vendors as possible to implement the profile out of the box Clarifications/extensions to UML2 profiles to be included as part of SysML submission
Goal
Language Architecture Top Level

Our first thought
<<instanceOf>>
43
This slide has animation that tells the story of how we arrived at the profile
SysML Underlying Semantic Model

UML 2 provides the underlying semantics that SysML builds upon

semantic consistency defined by UML 2
Methodology can enforce additional constraints to support further integration

SysML is intended to support multiple methodologies (e.g., OO, component-based, SA/SD)
Tool vendors can implement additional constraints to enforce a methodology

SysML Compliance Approach

Consistent with updated UML 2 Compliance Approach Must include UML packages / metaclasses that are required for SysML Compliance level for SysML packages based on both usage and vendor implementation considerations

Basic Advanced
Major Extensions to UML 2 (1)

Assembly Diagram

Assembly may be renamed Block
usage guidelines for Composite Structure enclosing class is an assembly ports are subclass of part supports deep nested connectors
Detail later
Activity Diagram
accommodate needs of Enhanced Functional Flow Block Diagrams (EFFBDs) extensions for continuous flow modeling, control operators, and probability Activity model supports physical as well as computational processes.
46

Allocations
defines allocation relationships to allocate functions to components, etc abstracts System Deployment and integrates with assembly diagram Requirement Diagram to provide a bridge with requirements management tools Parametric Diagram to support engineering analysis Example: Context diagram usage of class diagram
New Diagram Types

Allows for Other Diagram Usages

47

Other

extends Information Flows for use by assemblies and parametrics extends class notation (dependency set, specialization hierarchy) extends properties to support specification of units, values, and probability distributions specifies views and viewpoints adds primitive types for real and complex adds model reference data
48
Behavior Models

Multiple types of model. None dominant. Different emphasis in each one:

Activity models
Series of actions Messages between objects Objects reacting to events
Interaction models
State machines
Virtual machines defined for execution.

Activity Modeling
Activity modeling emphasizes the sequence and conditions for coordinating other behaviors using secondary constructs to show which classifiers are responsible for those behaviors. Focus is on what tasks need to be done, in what order, rather than who/what performs each task.
Activity Modeling
Tasks and ordering
Receive Order
Fill Order [order accepted]
Ship Order
Close Order
Send Invoice
Invoice
Make Payment
Accept Payment
51
Shows sequence and conditions for coordination of other behaviors. Arrows are not necessarily messages or other communications.
Activity Modeling

attribute performingDept: Department
plus resource assignments.
Order Department
Receive Order
Ship Order
Close Order
Acctg Department
Send Invoice
Accept Payment
Invoice
Customer
external
Make Payment
52
Resource assignment is another way of saying object-oriented. Ship order might be moved to another department. Original activity model doesnt change. Invoice on partiiton boundary because it represents pins, ie, inputs and outputs, and these are spread across two partitions. Partitions can also be multi-dimensional.
UML 2 Activities for SE

First-class behavior model:

Usable with or without objects Parameterized Behavior properties Concurrent branches operate independently. Queuing, storage Notation Multi-entry/exit For model execution and simulation.
Full parallelism
Input/output

Full action model

First-class Behavior Model

Object-orientation not required to model dynamics but supported when needed. Behaviors can be invoked directly, or through an object owning the behavior. Parameterized for input/output. Can have attributes, associations, operations, states,

UML 1.x did not have parameterized behavior models.
First-class Behavior Model

POEmployee sortMail() deliverMail() Deliver Mail
Keys Check Out Truck Put Mail In Boxes
Deliver Mail
resource
HowLong : Time Abort()

Truck
1
0..1
55
Deliver Mail activity can stand alone (be invoked directly) or be attached as a method to an object (be invoked by request to an object). It can be treated as an object, with attributes such as how long it has been executing, an operation for aborting it, a link to the resources it is using, and so on.
State-based UML 1.x Activities

(Activity)
A X Y B C Z
(State Machine)
B A X Y C Z
Trace:
A, B||X, C||Y, Z
UML 1.x activities are based on state machines. The parallel regions are actually synchronized so that one step happens in each region per cycle of the machine. Events are taken into the machine only between cycles. Regions must be wellnested.
Token-based UML 2 Activities

(Activity)
A X Y B C Z
(Token flow, not a notation)

A
C Z
Trace:
(B,C) || (X,Y) http://www.sysml.org
A,
,Z
57
UML 2 activities based on token flow through an unrestricted graph.
Unrestricted Parallelism in UML 2

(Activity, tokens not notation)
A N
C Z
Trace:
A,
(B,C) , Z || (X,Y) || N
UML 2 activities can be arbitrary graphs.
Queuing
Machine Part Polish Part Package Part
Tokens can

stack up in in/out boxes backup in network prevent upstream behaviors from taking new inputs
Applicable to systems with significant resource constraints, such as physical or manual processes.
Queuing
Machine Part
<<centralBuffer>>
Polish Part Part
Machine Part
Test Part
Tokens can be

Stored temporarily Divided between flows Flow in more than one direction, unless copied.
Tokens cannot
Non-queuing

No token interaction. For domains without resource constraint, such as computation.
Amount function update_account (a : Account, d : Amount) { Amount nb = a.balance + d; a.balance = nb; send_notice (a.customer, a, nb); return nb; }
Multiple data and control flows implicit in textual presentation of activity.
Non-Queueing
update_account Amount Deposit + Set Balance
Account
Get Balance
Get Customer
Send Notice
62
Parameter Sets
Sets of parameters can take input or provide output ... exclusive of each other at runtime. See multi-exit in EFFBD.

Full Action Model

Actions are the steps in an activity (round-cornered rectangles). Include:

Invoking behaviors/functions. Creating/destroying objects. Getting/setting property values.
For fully-executable models and simulations.

Extended Functional Flow Block Diagram

Control/data flow diagram.

2 Function in Concurrency 3 Multi-exit Function 3 times 4 cc#2 IT Function in Iterate IT 7 AND 5 Function in Select Construct OR 6 Function 2 in Select Construct OR AND Output Function cc#1 OR
1 Serial Function
From Long, James, "Relationships between Common Graphical Representations in System Engineering", ViTech Corporation, www.vitechcorp.com http://www.sysml.org
65
Extended Functional Flow Block Diagram

Most of EFFBD supported by UML 2 Activity diagrams. Some differences in execution to be addressed in SE profile for UML 2 or in minor revision to UML.

66
Function Behavior/Action
EFFBD Function and UML 2 Action/Behaviors are steps in a process flow.

(EFFBD)
#
(UML 2) Move Elevator
Move Elevator
Notation is different, but repository would be the same (except for adding #).
Semantics is the same, notation different. Applies to following slides also.
Control Flow
EFFBD and UML 2 Control Flow give time sequence to steps in a process flow.
# #
(EFFBD)
Close Doors
Move Elevator
(UML 2)
Close Doors
Move Elevator
68
Rectangles are classes in UML.
Data/Object Flow
EFFBD and UML 2 Data Flow specify how Function/Behavior outputs are provided to inputs.
#
(EFFBD)
#
Accept Input
Floor Number
Move Elevator
Accept Input
Floor Number
Move Elevator
(UML 2)
69
External I/O Parameter

EFFBD External Input/Output and UML 2 Parameter support I/O at the beginning/end of the entire diagram.
#
(EFFBD)
Floor Number
Move Elevator
Floor Number
Move Elevator
(UML 2)
Select Decision
EFFBD Select and UML 2 Decision specify mutually exclusive paths in a flow. branch annotation
OR OR
(EFFBD)
branch annotation [guard]
(UML 2)
[guard]
Line shapes, attachment points are not normative.
Concurrency Fork/Join
EFFBD Concurrency and UML 2 Fork/Join specify parallel paths
(EFFBD)
AND
AND
(UML 2)
Multi-exit Parameter Sets

EFFBD multi-exit functions and UML 2 Parameter Sets specify mutually exclusive outputs.
# completion condition
(EFFBD)
completion condition
TBD: Postcondition on parameter set
(UML 2)
Completion conditions are a property of the function.
Cycles
EFFBD and UML 2 flows can have cycles in the flow graph.
loop annotation
(EFFBD)
LP
#
LP
[guard] [else]
(UML 2)
EFFBD iteration determines number of loops at the end of the iteration. Extend UML for the EFFBD cycles, notationally, and for iteration and loop, semantically.
Edge Shortcuts
Notational shorthand for long flow lines:
Fill Order
Ship Order
is equivalent to
Fill Order Ship Order
75
Example EFFBD
4 cc#1 Function in Multi-exit Construct 2 Multi-exit Function OR
Data 1
Data 2
3 times
5 cc#2 IT Function in Iterate IT Data 5 1 Data 3 Serial Function AND AND Output Function 6
3 External Input Function in Concurrency
Data 4 External Output
Adapted from Long, James, "Relationships between Common Graphical Representations in System http://www.sysml.org Engineering", ViTech Corporation, www.vitechcorp.com
76
UML 2 Translation
4. Function in Multi-exit Construct
Data 1
2. Multi-exit Function
[ before third time ] Data 2 External Input 1. Serial Function 5. Function in an Iterate External Output
[ else]
Data 5 Data 3 6. Output Function 3. Function in Concurrency Data 4
77
To Be Addressed
Triggering and nontriggering inputs. Distinguish required from streaming. Multi-exit, queuing on control. Treat control as a kind of data. Completion conditions on multi-exit. Add postconditions to UML 2 ParameterSet. Control/data flows that disable functions. Extend control tokens.
Iteration Extend merge node. Continuous data flows. Fine-grained token flow.
RFP
For additional information on activity diagrams see
Search for Conrad Bock

78
Last two from SE UML RFP.
EFFBD ~ Activities
Significant similarity between EFFBD and UML 2 Activities. Entry point for SEs into UML. Integrates with other UML features useful to SE:

Classes Composition (Assembly) Information Flow Many other features not presented here.
Details of EFFBD Activity translation at:

http://syseng.omg.org/SE_DSIG_Coordination/U2P/seu2pactivitymap.pdf
Composition UML 1.x

UML 1.x supported part-whole

Car
Engine
Wheel
Boat
Engine
Propeller
80
Composition UML 1.x

but not part-part:

Car
Associations are global
Engine
powers 1 Boat 2
Wheel
Power to wheels on other peoples cars
Wheels on boats
(not legal UML anyway)
Engine 1
powers 1
Propeller
Propellers on cars
81
Associations are global and independent of each other. Not legal UML anyway, because powers links the same class to two others.
Parts, Ports, Connectors

Parts are properties that are enclosed by assemblies and typed by classes
Part is defined as internal to assembly vs. ordinary properties that reference other systems/objects notationally represented as a rectangle on the boundary of a part can connect parts with or without ports typed by associations features of the enclosing class Adaptation of UML Information Flow Can be Mass/Energy/Information Flow
Ports are parts that provide interaction points

Connectors bind one part to another

Flows

Composition UML 2.0

UML 2 supports part-part in context:

Car : powers : Wheel
: Engine
Engine as used in Car

Boat : powers : Propeller
Powers as used in Car
: Engine
Engine as used in Boat
Powers as used in Boat 83
Compare to UML 1.x collaborations. Multiplicities are local.
Composition UML 2.0

Enables better abstraction:

Vehicle
Vehicle
powers PowerSource 1 1..* PowerTransmitter
Boat
Car
Engine Wheel Propeller
CarEngine
BoatEngine
Global structure inherited by each kind of Vehicle

and constrained for each84kind
CarEngine and BoatEngine so that different kinds of engines can be used in cars and boats. Use redefinition of inherited composite structure.
Interfaces UML 1.x

UML 1.x supports interfaces, but only in one direction:

Engine PowerIn Wheel
Propeller PowerIn
Interface usage buried in client methods.

Engine needs to know about wheels and propellers if it ever creates instances.
Interfaces UML 2.0

Bidirectional interfaces:
Engine
PowerOut PowerIn
Whatever
required
provided
Car
: Engine
PowerOut PowerIn
Boat
: Wheel
: Engine
PowerOut PowerIn
: Propeller
86
Required and provided interfaces wired together in composite (component).
Composition 2.0 (Ports)

Ports = public parts.

Car
: Engine
PowerOut PowerIn
: Wheel
Boat
: Engine
PowerOut PowerIn
87
: Propeller
Composition 2.0 (Ports)

Multiple ports of the same type.

Home Office
: Computer
PowerOut PowerIn
: PowerStrip : Printer
PowerOut PowerIn
: Lamp
PowerOut PowerIn
88
SysML Assemblies
UML 2 Component is intended for modeling of software components SysML replaces the UML 2 Component with a domain-neutral concept of Assembly, based on relatively minor changes to UML 2 structured classes Assembly captures a module at any level in the system hierarchy. Can represent external systems, a system of interest, logical, physical, hardware, software, etc. Assemblies provide both black box view (without internal structure) and white box view (showing internal parts and connectors)
Structural Modeling Foundation

Basis for allocation and refinement across multiple structure breakdowns (e.g., mechanical vs. electrical) As much or as little detail as needed to serve purpose at each development stage Features specific to UML support for software components are deferred to domain-specific views (required/provided interfaces, ports with signaling behavior, )
90
Elements of Structure Shown in Two Views: System Example

* * cable 1 port throttle * 0..1 port throttle 0..1 Motor Assembly 0..1 * port ethernetPort ethernet 1 port ethernetPort * *
0..1
1 ThrottleActuator Actuator
1 EMC Ethernet Motor Controller
0..1
Class Diagram Structure Diagram
0..1
0..1 port port 1 serial 1 serial * RS232 *
Motor Assembly
throttle:cable throttle ethernetPort:ethernet
ThrottleActuator: EMC : Ethernet serial serial Motor Controller Actuator

ethernetPort
91
In this example, two representations of a motor assembly are shown. The Motor Assembly is made up of an Actuator and an Ethernet Motor Controller. The Actuator and Ethernet Motor Controller communicate via an RS232 serial link and both contain ports of this type, which are linked via a reflexive association. The Actuator is activate externally by the throttle cable and the motor assembly has a port to allow external access. Finally, the Motor Controller communicates via an Ethernet port, and the Motor Assembly also has a port to allow external access.
Information Flow
Very abstract flow model.

Customer product <<flow>> <<flow>> wage Company
Employee
Independent of message passing, parameters, etc, but can be tied to these. Applicable to Elaborated Context Diagrams
Functional Allocation w/Activity Partitions

Drive
b:ApplyBrakes v1:Engine v2:Brakes <<allocatedTo>> v2:Brakes
Allocation of Use (Action to Part)
a:Accellerate
b:ApplyBrakes <<allocatedTo>> ApplyBrakes Brakes
Allocation of Description (Activity to Class)

Activity Partition is allocation of use Allocation of description (class level) is sometimes needed SysML needs to support both allocation of use and allocation of description
Swimlane: Allocation of ObjectFlow to Connector

:Traction Detector :Brake Modulator
Detect Loss of Traction
Loss of Traction :modulator interface
Modulate Braking Force
Allocation of Function to Component
Activity Diagram w/Swimlanes

<<ObjectNode>> Loss of Traction
Allocation of ObjectFlow to Connector
<<allocatedTo>> :Traction Detector :modulator interface :Brake Modulator
Composition Diagram http://www.sysml.org
94
Nested Swimlanes Modeling a Continuous System

allocation Driver Acceleration Braking allocation Vehicle
<<Continuous>>
Vehicle Started
allocationSource=Brake Foot Pressure; ...
[brake applied] [accelerator applied]
runToCompletion Apply Brakes runToCompletion Apply Accelerator continuous allocation AcceleratorPosition
continuous allocation BrakePressure
runToDisable Control Brake Force runToDisable Control Power
continuous BrakeForce
continuous ExternalTorque
Ignition Off
allocationSource=Accelerator Foot Position
95
User-customisation example
UML also allows stereotyped classes to be represented by different icons to aid understanding. The lower diagram might be better understood by some users. Structure Diagram
Motor Assembly
ethernetPort:ethernet ethernetPort throttle:cable
EMC :Ethernet ThrottleActuator : throttle serial serial Actuator Motor Controller
Structure Diagram With Stereotypes

SystemBus: ethernet hardware MA:Motor Assembly ethernetPort ethernetPort EMC: Ethernet Motor Controller serial serial throttle ThrottleActuator: Actuator throttle human :Driver
Created with Artisan SW RtS
96
The diagram has been further transformed using icons to represent different types of stereotypes. The Driver Actor has the <<Human>> stereotype and is represented by the cartoon driver. The Ethernet bus has the <<Bus>> stereotype and is represented by a large arrow. The Ethernet Motor Controller and the Actuator have the <<Board>> stereotype and are represented by circuit boards.
Time Model

TimeLine3
Can be used to state constraints on processes:

Move Elevator
< 2 sec
td Timing Diagram go home aw ake alarm clock atw ork park asleep 0 20 40 60 80 100
Close Doors
97
Interaction Model
sdexample
ob1:C1 opti()
Gate
Interaction Operator
ob3:C3
Operand separator
ob4:C4
alt
[x>0]
create() foo(x)()
ob2:C2 doit(z)() doit(z)()
foo(x)()
else [ ]
bar(x)() doit(w)() doit(w)() bar(x)() more()
opti()
more()
UML 2 defines additional control operators on interactions.
Interaction Model
sd User_accepted
User
Code
AC System
Messages can overlap in time because begin and end events can be arbitrarily ordered
OK
o rd Ca ut
Unlock
99
Message have begin and end events that can be arbitrarily ordered.
Sequence Diagrams now like MSCs

sd Interactions :M inesw eeperApp :Game :PlayingField
ref New Game(numOfM ines)
Sequence Diagram s can be nested as 'Interaction Occurances'
ref Initialize Game
100
Deployment
Support for general mappings between design elements, artifacts, and deployment targets. Communication paths between nodes.
Supports locality diagrams.
101
UML2 Software Deployment

Software Component 1 <<manifest>> Software Artifact 1 <<manifest>> Execution Environment A Software Artifact 1 Software Artifact 2
<<manifest>> Software Component 2 <<manifest>> Software Artifact 2
Execution Environment A
Execution Environment A
Software Component 1
Software Artifact 1
Software Component 2
Not allowed in UML2! - should be considered for SysML?
OK
102
Software Artifact 2
SysML::Deployment
New SysML Relation Subsystem A <<software>> Comp1 <<SysML::Deploy>> Processor
<<SysML::Deploy>> <<software>> Comp2
:Execution Environment A
:Buffer/Isolater
:Execution Environment A :Display <<deployment>> <<software>> Comp1 <<software>> Comp2 :Operator :Operator <<deployment>> <<procedure>> Proc1
<<procedure>> Proc1
<<SysML::Deploy>>
Rick RickSteiner: Steiner: Name Namefor forSysML::Deploy SysML::Deploy relationship relationship Opportunity Opportunityfor for(deletion (deletionof of UML UMLdeploymment) deploymment)
Thoughts on Deployment
Deployment relationship is different than whole-part relationship

Is really peer-peer relationship The source of a deployment relationship (e.g. Software) cannot perform its function without the target (e.g. Hardware) The target provides resources (e.g. memory, processing power) that the source consumes in the execution of its behavior. This resource flow is elided by the relationship, and doesnt need to be modeled in detail. It can be handled parametrically. Procedures -> Humans Others?
Deployment may be used for other than HW/SW

Diagram Summary
Models, Views, and Diagrams

A system model provides a representation of the physical system and its environment

includes the semantics and notation can be graphically represented by one or more diagrams
A viewpoint is the perspective of a set of stakeholders that reflects the stakeholder concerns A view is intended to represent the model from a particular viewpoint
Viewpoint and View
View sets are required to support different frameworks and architecture description languages (RM-ODP, DoDAF, CCSDS)
UML 2 Diagram Taxonomy

UML 2 Diagram
Behavior Diagram
Structure Diagram
Activity Diagram
Use Case Diagram
Class Diagram
Com ponent Diagram
Deploym ent Diagram
Com posite Structure Diagram
Interaction Diagram
State Machine Diagram
Object Diagram
Package Diagram
Com m unication Diagram
Tim ing Diagram
Interaction Overview Diagram
Sequence Diagram
108
SysML Diagram Taxonomy
Derived from UML 2 Composite Structure
109
SysML Diagrams
Reuses UML 2 diagrams for: Class diagram Use case diagram State machine diagram Interaction diagrams (sequence, timing) Extends the following diagrams Activity diagram Assembly diagram (based on composite structure) Adds the following diagrams Parametric diagram Requirement diagram
Major Extensions to UML 2

Parametric diagram to integrate with engineering analysis models Requirements diagram to model requirements traceability and relationship to design and verification models and bridge with requirements management tools
Diagram Frames
112
Diagram Abbreviations

activity (act) assembly (asm) class (cls) interaction overview (iov)

sequence (seq) state machine (s-m) timing (tim) use case (u-c) verification (ver) reserved
Note: not part of SysML

logic (log) - reserved parametric (par) requirement (req)

Diagram Usage
Diagram usages can be added to the diagram taxonomy using the stereotype extension syntax
designated in the frame with guillemets
diagramKind
<<stereotype>> diagramUsage
114
Alternative Diagram Representations

Alternative concrete syntax

graphical tabular (optional) tree (optional)
Concrete syntax must conform to abstract syntax and constraints
115
Diagram Descriptions
Activity Diagram
Activity Modeling
Activity modeling emphasizes the inputs and outputs, sequence, and conditions for coordinating other activities (functions) Secondary constructs show which classifiers are responsible for those activities Focuses on what tasks need to be done, with what inputs, in what order, rather than what performs each task
Activity Modeling
Tasks and ordering
Receive Order [order accepted]
Fill Order
Ship Order
Close Order
Send Invoice
Invoice
Make Payment
Accept Payment
119
Shows sequence and conditions for coordination of other behaviors. Arrows are not necessarily messages or other communications.
Activity Modeling with Swimlanes

plus allocation to parts/assemblies via swim lanes (optional)
attribute performingDept: Department
Order Department
Receive Order
Ship Order
Close Order
Acctg Department
Send Invoice
Accept Payment
Invoice
Customer
external
Make Payment
120
Resource assignment is another way of saying object-oriented. Ship order might be moved to another department. Original activity model doesnt change. Invoice on partiiton boundary because it represents pins, ie, inputs and outputs, and these are spread across two partitions. Partitions can also be multi-dimensional.
Continuous Systems (flow rate)

interruptibleRegion
Driver
Turn Key On
Driving
Key off
continuous Brake Pressure
Brake System
Braking
ControlOperator
Enable on Brake Pressure > 0 continuous Modulation Frequency
ABS
Monitor Traction
121
Enhanced Functional Flow Block (EFFBD)

COMPLETION CRITERION IN FUNCTION 2
2. 2 Multi-exit Function OR 2. 4 cc#1 Function in Multi-exit Construct
DATA FLOW (TRIGGERING)

Item 1
Item 2
3 times
FUNCTION
2. 5 cc#2 IT Function in Iterate IT Item 3
DATA FLOW (NON TRIGGERING)
1 Source of External Input
2.1 Serial Function AND
2. 6
3 Sink of External Input
CONCURRENCY
2. 3 Item 4
AND
Output Function
External Input
Function in Concurrency
External Output
Adapted from Long, J., "Relationships between Common Graphical Representations in System Engineering", ViTech Corporation, www.vitechcorp.com
122
EFFBD UML
OBJECT NODE (PIN) PARAMETER SET
2.4 Function in Multi-exit Construct
MERGE
Item 1 2.2 Multi-exit Function optional
GUARD
[ before third time ]
OBJECT FLOW
Item 2 External Input 2.1 Serial Function
optional 2.5 Function in an Iterate
[ after third time ]
External Output
FORK
Item 3
optional 2.6 Output Function
DECISION ACTIVITY PARAMETER INVOCATION ACTION CONTROL FLOW

2.3 Function in Concurrency
JOIN
optional Item 4
123
Action Execution Rules

Before execution
An action waits for all required data/item inputs, in whatever quantity is required, and waits for all control inputs required, then begins. Note: resource constraint is defined but enforcement is left up to the implementation. Data/objects/items arriving at non-streaming inputs while the action is executing are queued. Actions support concurrent execution of queued inputs (reentrancy). This should be compared to replication. Data/objects/items arriving at streaming inputs are input to the action execution. Enabling control is queued if control pins are used, otherwise, enabling control is discarded. Disabling control aborts the action or behavior it invokes. An action must provide required streaming outputs, and can provide optional streaming outputs. An action provides all required, non-streaming data/item outputs, in whatever quantity is required, and all control outputs needed by 124 http://www.sysml.org outgoing control flow.
During execution

After execution
Activity Usage with Other Behavior Representations

Activity is a generic, reusable description of behavior Used in

Other activities (decomposition through actions) State machines

Transition activity Entry/Exit activity on states Do activity on states Methods for operations
Classes, Sequence Diagrams

Actions, states, and operations can reference the same activity

Activity Usage with Other Behavior Representations (cont.)

Activity
entry
exit doActivity
Invoked activity
Invoked method
Can dispatch different behaviors
+effect
State X
Activity X1
Class 2
Class1
Action 1
Op 2.1
Transition Activity T1
Class 1
Op 2.1 (para:type)
State Y
Activity Y1 Activity Y2
Action 2
States
Class Activities
126

State machine diagram capture

States of objects Transitions between states:

Events causing transitions Conditions under which a transition is taken (guard) Activities (if any) taken when the transition happens Entry, exit, and doActivity
Activities within states

Composite states are hierarchical

Can contain 1 region or 2 or more orthogonal regions Each region can contain one or more disjoint substates (mutually exclusive)
128
Objects can send/receive signals to communicate with other http://www.sysml.org objects during state transitions, etc
State Machine Diagram Showing Vehicle System Operate State
129
Interaction Diagrams
Sequence Diagrams
Object A: Class A Message
T < .1 sec
Object B: Class B
Lifeline
Message
Self Message
A sequence diagram represents a series of messages among objects arranged in time order A basic sequence diagram is made up of objects, messages, and constraints as shown here
131
Sequence Diagram with References and Decision Logic

seq: Continue
:A :B :C
seq: Question
:A
:B
ref
ask
Question
alt
DoSth
alt
ok yes ok nonono
notOK no
notOK
Derived from UML 2 Superstructure

Sequences With Lifeline Decomposition

seq: Environmental Sensors external :Environment ref Environment Detail sensors:Sensor
weather data road data environmental data
seq:Environment Detail
theRoad:Road theWeather:Weather otherEnv:ExternalObject
road data weather data Position data

Interaction Overview Diagram

UML 2 but not SysML A constrained use of an activity diagram that can reference or include interactions
sd GoHomeSetup
ref
Authorization
ref
FindLocation
sd
:ServiceUser SetHome
:ServiceBase
Can include control nodes

sd
:ServiceUser
:ServiceBase
Initial, final fork, join decision, merge

SetInvocationTime SetTransportPreferences
134
Timing Diagram

A type of interaction diagram Represents the change over time associated with changes in states, activities, or property values Can represent continuous or discrete changes
135
Timing Diagram Example
136
Use Case Diagram
Use Cases
System Use:
Sum m arize Weather Data
Weather Forec as ter
Obtain Current Air Data
Military Mis s ion Pla nner
Represents mission capabilities and/or uses of a system that are implemented by system, external systems, and actors
Obtai n Curre nt Water Da ta
138
Briefly explain stereotypes (Actor, System, IO)
Use Case Relationships

D A C
A includes B in that As behavior always includes behavior of B C extends A in that behavior of A can be augmented in some cases by behavior of C D inherits the behavior of A and adds some additional http://www.sysml.org behavior
139
Class Diagram
Class Diagram
Class diagrams capture Classes, packages Relationships including associations, dependencies, and generalization
Superclass Constituent of Superclass
Subclass 1
Subclass 2
Association
Class
Constituent 1 of Subclass 1
Constituent 2 of Subclass 1
141
Containment
This containment notations supports hierarchies that represent name space and not structure (whole/part)
Refer to classes chapter

Dependency Set
Groups a set of dependencies

Used in requirements trace, derive, satisfaction, verification and other areas
Refer to classes chapter

Class Diagram For Vehicle System Hierarchy
144
Assemblies
Structural Modeling Foundation

Assemblies are UML 2 structured classes Classes which support the ability to hold parts, ports, and internal connectors Assemblies provide both black-box view (without internal structure) and white-box view (showing internal parts and connectors) Basis for allocation and refinement across multiple structure breakdowns (e.g., mechanical vs. electrical) As much or as little detail as needed to serve purpose at each development stage Initial sketch for communication Comprehensive detail for simulation/execution Compatible with features specific to software components (required/provided interfaces, ports with signaling behavior, )
System Hierarchy
Context External System N External System 1 System
Part 1
Part 2
Part 1
Part 2
147
SysML Assemblies
assembly stereotype provides a common root for user-defined or domain-specific hierarchies of system component types Hardware Software Data Procedure Facility Person Assemblies provide the backbone of the system hierarchy or system of systems architecture which drives much of modern systems engineering
148
Assemblies, Parts, Ports, Connectors & Flows

Assembly
Item Flow
Port
Connector
149
Parts, Ports, Connectors

Parts are properties that are enclosed by assemblies and typed by classes SysML reuses UML 2 part and property Can be typed by UML 2 components or other types for hardware, etc. Ports provide interaction points SysML views ports as parts on a boundary represented as a rectangle on the boundary of a part can be typed like any other part UML 2 ports include specific forms of communication Connectors bind one part to another Typed by associations, which may themselves be structured classes (under consideration for SysML) Connector extended to support ends that are nested inside the parts of a containing assembly
Parts versus Instances

An instance is a specific member of a class A part relates the instances of the enclosing assembly to the instances of the class that types the part Describes the usage of a class in the particular context of the enclosing class Equivalent to a role or prototypical instance
151
Assembly Diagram Showing Power Subsystem
152
Control vs I/O Interface Requirements

Different approaches to specifying system and component interface requirements

Control interface specifies a set of operations the component must provide in response to a call (reqd i/f)
Protocol state machines can also be used
I/O interface specifies the inputs and outputs which implies a required function to perform the transformation
153
Alternative Interface Definitions

provided interface (provides the operations) Control Interface required interface (calls the operations)
I/O Interface item flow

Allocations
Allocations
Allocation is a key systems engineering concept that enables one set of model elements to be mapped to another set during design SysML provides support for multiple types of allocation
156
Uses of Allocation
Usage 1. Requirement Allocation 2. Behavioral Allocation 3. Logical Allocation 4. SW to HW From Requirement Packageable Element Function (activity), or State Object Node Assembly/Part, I/O (logical) Assembly/Part (software) To Requirement Requirement Assembly/Part Connector Assembly/Part, I/O (physical) Assembly/Part (hardware)
157
Implicit Allocation of Behavior to Structure: Example using Swimlanes
Activity Diagram (without Swimlanes)
Detect Loss of Traction
Loss of Traction
Modulate Braking Force
:T ra ctio nD ete cto r
:B rakeM od ula tor
Activity Diagram (with Swimlanes)
D e te ct L o sso f T rac tio n
Lo sso fT raction
M o d u late B rakin gF o rce
158
Examples of Allocation
An allocation reference can be used to show allocation from/to another element e.g. function to component An allocation compartment can be used to depict an allocation of a model element Function allocated to logical component
An allocation relationship can depict the source and target of the allocation Logical component allocated to physical component
SysML Allocation of SW to HW
More abstract form of deployment than UML::Deploy UML::Deploy only speaks to deployment of Artifacts to Nodes (ptc 03-08-02 section 10.3.4) SysML allocation allows for the modeling of deployment of assemblies to assemblies, procedures to humans, etc. Very often, systems engineers want to model the deployment of a software system to a piece of hardware without considering the Artifact or other implementation aspects of the software system in question. Enables deployment to be depicted on an assembly diagram
160
Item Flows
Requirements for Item Flows (RFP reqt 6.5.2.1.1)

Ability to represent both logical and physical aspects of things that flow. Logical aspect may be the information and the physical may represent the encoding of that information in the form of bits and a digital signal. The physical flows include the flow of mass and energy. Ability for items to have properties Ability to specialize, decompose, and instantiate items Ability to associate items with connectors in assembly diagrams and associations in class diagrams Ability to allocate object nodes to/from items and item flows Ability to bind item properties to parametric relationships for a particular use in a flow (reqt 6.5.3.3)

Item Flows

Items are classifiers that represent type of thing that flows Item flows are a subclass of an information flow (directed relationship) that is realized by a connector or other relationship that conveys the item(s) Item properties are properties that contextualize the item (i.e. relate the instances of the item to the instances of its enclosing class) The allocation relationship can be used to allocate the things that flow in activity diagrams (type of object node) to the things that flow in an assembly diagram (type of item properties). The allocation relationship can be used to allocate logical things that flow (e.g. information) to physical things that flow (e.g. signal encoding). Item properties can be bound to parametric constraints like any other property
Item Flows
An item that flows Object nodes in activity diagram
Car Weight: Kg
A1 : Produce
C:Car
A2 : Transport
Item flow in class diagram
Car Factory LogisticsSystem
asm : context
Item flow in assembly diagram
C: Car F1 : Factory L1 : Logistics
164
Simplified Item Flow Through a System
165
Parametric Diagram
Parametric Constraint
Used to express constraints between quantifiable properties (aka non-functional characteristics) of assemblies

Reusable Non-causal
Defined as a stereotype

Right now a stereotype of a SysML::Assembly Expression: text string specifies the constraint Expression language can be formal (e.g. MathML, OCL ) or informal Computational engine is defined by applicable analysis tool and not by SysML
Parametric Constraint
Usage
Notation: parametric diagram distinguishes the parametric constraints from other parts of a containing assembly Properties of parts connected to parameters of relation Value binding connector declares that parameter and property are bound to the same value
Parametric relation can be used to support evaluation of alternatives (trade-off analysis) Approach will be formalized post V1.0
Parametric Constraint Definitions
169
Parametric Diagram Showing Vehicle Performance Parameters
Rounded rectangles are parametric constraints Rectangles are properties (parameters)

Parametric Constraints
DragForce : Real paramConstraint {constraint = DragForce=0.5* dragCoef*rho*speed} DragForce
paramConstraint {constraint = f=m*a} Newton's Law
dragCoef : Real
Force f Mass m Acceleration a
rho : Real
speed : Real
paramConstraint Newton's Law (SI)
Newton's Law f : Force a : Acceleration
kg m N f m/s a
m : Mass
Newton's Law (SI) m : kg a : m/s
f:N
171
SysML Properties
SysML Extension for Property to address Quantity - Values, Units, and Dimensions Probability Distribution Example for a vehicle that weighs 1000 pounds with a uniform probability distribution:
New data types Real Complex
172
Treatment of Time
SysML views time as a property of a Continuous and/or Discrete Clock Clock and Synchronization errors can be modeled if required for the application Different units can be applied (seconds, days, ) Time intervals, triggers, and other concepts specified in UML 2 Any property may have a time dependence and used in a parametric relationship Time may be shown implicit or explicitly in parametric diagram, depending on need More elaborate models of time and clocks can be found in the UML schedulability, performance, and time profile.
Trade-off & Parametrics Reqt 6.6.3

Parametric relation can be used to support evaluation of alternatives (trade-off analysis) Alternatives represented by different models Evaluation function specified as a parametric relationship in terms of: Criteria, weighting Probability distributions can be applied to properties Evaluation result can be viewed as a measure of effectiveness Can be represented in typical table format Approach will be formalized post V1.0
174
Requirements Diagram
Approach
The Requirements diagram provides the following features: requirement stereotype that can represent text based requirements and properties (e.g., id, text statement) requirements can be decomposed into their constituent elements via the containment relationship requirements can be sub-classed using specialization derive relationship between derived and source requirements satisfy relationship between design models and requirements verify relationship between requirements and test cases generalized trace relationship between requirements and other model elements rationale for requirements traceability, satisfaction, etc Alternative graphical, tabular and tree representations
176
Requirements Flowdown
177
Requirement Hierarchy
178
Derived Requirements
Construction of derived requirements
179
Requirement Satisfaction
180
Requirement Verification
181
Requirements Subclass
182
Requirement Classification
Typical requirement properties

text ID
Users create stereotypes subclasses for specific requirements types, e.g. performance

add properties (e.g. criticality, ) add constraints (e.g. functional requirement can only be satisfied by an activity or method)
Typical requirement types defined in model library

Typical Requirements Stereotypes

Accommodates user specified requirements subclasses
184
Default subclass of requirements

Requirement subclass Constraints
Operational Functional Interface Performance Activation/deactivation Storage Physical Design constraint Specialized Measure of Effectiveness Satisfied by an activity, operation, or method. Satisfied by an activity or method. Satisfied by a connector, port and itemflow. Satisfied by one or more performance properties and associated parametric relationship. Satisfied by a state machine, activity, or sequence diagram. Satisfied by any part that represents a stored item. Satisfied by one or more physical properties and associated parametric relationships or a geometric model. Satisfied by any white box model element such as parts, ports, connectors, or implementations of black box behavior. Satisfied by any element modeling the specialized requirement. Satisfied by class attribute reporting a simulated/measured performance of a system.
UML Testing Profile

Adopted by the OMG to support software testing SysML Partners evaluated the profile to determine how well it addresses the verification requirements in the UML for SE RFP

Evaluation results indicate many of the requirements are addressed Minor adaptation required for full integration SysML will be compatible with testing profile
Integration of testing profile will be identified for SysML V1.1

SysML/AP233 Alignment
ISO 10303 (STEP) / AP233

Data interchange protocol for Systems Engineering Neutral (tool independent) format Defined based on the ISO 10303 modeling environment Captures versioning information of data elements (enables configuration control)

Alignment Objective
Enable exchange of SysML models and classic SE tools via AP233 Align SysML and AP233 models Set-up of data-exchange test-bed for SE data

189
SysML / AP-233 Alignment

SysMLTools
Systems Engineering Electrical CAE ISO 10303/AP-233 NEUTRAL SE DATA EXCHANGE FORMAT Engineering Analysis
Mechanical CAD
Algorithm Design
SW Dev Environment
Testing Tools
Planning Tools
190
Example Standards-based Tool Chain for DoDAF

Use SysML to represent DoDAF views Use AP233 to exchange data between SysML and other tools
DoDAF Representations
SV4 OV2
AP233
OV7
..... ..... ..... -
..... ..... .....
TV2
AP233
SysML Tool
Analysis Tool
INCOSE Insight July 2004: Ian Bailey, Fatma Dandeshi, Dandeshi, HueiHuei-Wan Ang , Dwayne Hardy Using Systems Engineering Standards in an Architecture Framework Framework
Alignment Approach

UML will be used as mapping platform Conversion of AP233 Express model to UML using ISO 10303 part 25 Baseline for data exchange is ISO 10303 part28 (XML) Create mapping model (MM) Mapping will be done on a module basis Flexible approach as both models evolve

192
Architectural Alignment
<<MetaModel>> UML 1.*
<<extends>>
<<MetaModel>> UML 2
<<Profile>> Express
<<extends>>
<<instantiates>>
<<MetaModel>> SysML
<<MetaModel>> AP233 (UML)
<<mapping>>
<<mapping>> <<MetaModel>> MappingModel
193
Future Directions with SysML
Challenges to Adopting UML for SE

Robustness of language to address broad based SE needs as defined by UML for SE RFP (e.g. reqts, evaluation criteria) Ability to integrate language, methods, and tools with hardware and software development, and engineering analysis environments Availability of model based methodologies Adequacy of tools and training support Acceptance of the model based approach by the SE community, implementers, PM, and customers Learning curve for systems engineers in language, methods, tools Continued evolution of the modeling language to support Simulation and fully executable specifications Comprehensive data / model interchange & tool interoperability

Proposed SysML Roadmap

SysML evolution

H22005 - SysML V1.0 H22006 - SysML V1.1 to address initial feedback from users and vendors H22008 - SysML V2.0 to address increased functionality integration with simulation and fully executable specifications and extended data/model interchange (e.g. AP-233)
Pursue SysML alignment with DoDAF & architectural frameworks Develop test cases for tool vendor compliance Establish SysML Certification Program Incorporate language and model based methods into 196 INCOSE handbook http://www.sysml.org

Background
In the early 90s, warfighting changed to involve new missions with new requirements, a need to employ changing technology and a greater need to interoperate Within services Within the DoD With coalition partners With national and international agencies
DoD needed to find the appropriate problem invariants that would support the management of the changes Invariant defined as some aspect that either does not change or changes very slowly Three different DoD sponsored studies from 1993 to 1995 all recommended architectures as the right invariant Air Force, Army and DoD Science Board studies
Architecture: Architecture: the the structure structure of of components, components, their their relationships, relationships,
and and the the principles principles and and guidelines guidelines governing governing their their design design and and based on IEEE STD 610.12 definition evolution over time. http://www.sysml.org evolution over time. based on IEEE STD 610.12 definition
197
The purpose of the DoD Architecture Framework, Version 1.0, is to provide guidance for describing architectures. The Framework provides the rules, guidance, and product descriptions for developing and presenting architecture descriptions that ensure a common denominator for understanding, comparing, and integrating architectures. This DoD Architecture Framework is an evolution of concepts introduced in the C4ISR Architecture Framework.
Purpose of the Framework
Note The framework is a way to describe architectures, not a method for developing architectures
OSD is looking at TOGAF ADM as a methodology
The DODAF is an evolution of the C4ISR AF but it was a long time in evolving so there have been significant changes in best practices and the DoD mission
The C4ISR AF

Version 2.0 was published in 1997 Work began in 1995 According to the AFCEA training material,
The C4ISR Architecture Framework was an untested draft that was (inadvertently) cast in concrete
The updates that the working group expected to happen, didnt happen due to budget cuts, etc. Not everyone in DoD is an enthusiastic supporter, but.
Historical Historical Perspective: Perspective: Java Java announced announced in in 1995 1995 UML specification published UML specification published Sept. Sept. 1997 1997 http://www.sysml.org The C++ ANSI Standard was published The C++ ANSI Standard was published in in 1998 1998
199
The Basic Elements

Operational View
Identifies Participant Relationships and Information needs
What needs to be done Who does it Information exchanges necessary to get it done Operational capability requirements Systems that support the activities and information exchanges Basic technology supportability New technical capabilities
Systems View
Specific capabilities required to satisfy information exchanges Technical criteria governing interoperable implementation
Technical Standards View

Prescribes Standards And Conventions
Relates Capabilities and Characteristics To Operational Requirements
Three Three connected connected views views of of the the architecture architecture http://www.sysml.org
200
All View Products

AV-1 Overview and Summary Information Integrated Dictionary Scope, purpose, intended users, environment depicted, analytical findings, if applicable Definitions of all terms used in the products
AV-2
A missing or poorly written AV-1 is like a missing or poorly written requirements document The AV-2 is more than a glossary it enables developers to keep terms and concepts consistent and complete across products and views AV AV products products span span all all of of the the architectural architectural views views
MoDAF/DoDAF Profiles
Tool vendors have been responding to user needs
OV-4 : Org Chart coordinates Al's Artillery * 1 Al's Office * 1 coordinates Al's Air Force * 1
11:10 GMT 11:00 GMT
Air Defence Corps * 1 coordinates Air Defence Cell 1 * 1 *
Logistics Corp * 1 coordinates Planning Office * 1 * 1
Squadron * 1
Air Crew
Flight Plan
1 *
Intel
WCO
Weapons Officer Intelligence Officer
Mission Commander
Flight Officer
Navigator
OV-2 : Mission Info Flow
SV-1 : Systems Interaction Overview systemNode MissilePlatform DeployedSystems Weapon : Class1 Reconnaisance systemNode Aircraft
DeployedSystems Flight Control : Class1 Navigation Reconnaisance
OperationalNode HQ InformationExchange HQ-MP : Mission Info InformationExchange MP-HQ : Mission Intel InformationExchange MP-ArtC : Mission Plan OperationalNode Artillery Command InformationExchange ArtC-MP : Weapons Intel OperationalNode Mission Planning InformationExchange ArtC-WO : WCO OperationalNode Intelligence OperationalNode Weapons Control InformationExchange I-AC : Weapons Intel
HQ-AC : Flight Data MHQ-MP : Target Data MP-MHQ : Intell Data interface AC-HQ : Intell Data systemNode Main HQ interface
InformationExchange AC-MP : Flight Intel
systemNode Mobile HQ
DeployedSystems : Class1 Defence Planning Weapon Coordinator Cartography
MHQ-HQ : Intell Data
InformationExchange MP-AC : Mission Plan
interface HQ-MHQ : Mission Data DeployedSystems Flight Assessment Flight Comms : Class1 Mission Planning Mission Assessment
OperationalNode Air Command InformationExchange AC-Aircraft : Flight Plan
OperationalNode Airbourne Unit
202
UPDM
UML Profile for DoDAF/MoDAF
The scope of this RFP is for a UPDM that satisfies the requirements outlined below. This includes representations for DODAF/MODAF views and products for modeling of the systems architecture (Systems View) along with their associated standards (Technical View) within the context of the business or enterprise architecture (Operational View). In addition it should be able to represent the UK modeling of the capability and strategic intent of the Enterprise (Strategic View) and the programmatic associated with the procurement of defense systems (Acquisition View). It should also provide a sufficiently robust capability and enhancements needed to support newly defined requirements for DODAF v2.0.
Wrap Up
Summary

UML for SE RFP requirements developed jointly between INCOSE, AP-233 and the OMG SysML Partners established in May 2003 to respond to UML for SE RFP includes wide range of contributors from industry, tool vendors and government agencies SysML extensively reuses a subset of UML 2 out of the box Extensions needed to address RFP requirements enhancements to composite structure and activity diagrams two new diagram types (requirements and parametrics) allocation relationships and auxiliary constructs SysML alignment with ISO AP-233 Early SysML tool implementation available Planned adoption of SysML v1.0 to begin early H2 2005
205
References

UML for SE RFP OMG doc# ad/03-03-41 SysML Specification V0.9 Draft (refer to www.sysml.org) [UML2 2003] UML 2 Superstructure (Final Adopted Specification) OMG doc# ptc/03-08-02 [UML2 2003] UML 2 Infrastructure (Final Adopted Specification) OMG doc# ptc/03-09-15 INCOSE 2004 Symposium Paper Extending UML to Support a Systems Modeling Language S. Friedenthal, C. Kobryn INCOSE 2003 Symposium Paper Extending UML from Software to Systems S. Friedenthal, R. Burkhart INCOSE Insight (June 2004) UPDM RFP
http://syseng.omg.org/UPDM.htm
Additional References
Bock, Conrad, "UML 2 Composition Model," Journal of Object Technology, 3:10, 47-73, http://www.jot.fm/issues/issue_2004_11/column5, Bock, Conrad, "UML 2 Activity and Action Models, Part 5: Partitions," Journal of Object Technology, 3:7, 3756, http://www.jot.fm/issues/issue_2004_07/column4, July/August 2004. Bock, Conrad, "UML 2 Activity and Action Models, Part 4: Object Nodes," Journal of Object Technology, 3:1, 27-41, http://www.jot.fm/issues/issue_2004_01/column3, January/February 2004. Bock, Conrad, "UML 2 Activity and Action Models, Part 3: Control Nodes," Journal of Object Technology, 2:6, 7-23, http://www.jot.fm/issues/issue_2003_11/column1, November/December 2003. Bock, Conrad, "UML 2 Activity Model Support for Systems Engineering Functional Flow Diagrams," Journal of The International Council on Systems Engineering, 6:4, 249-265, http://www.nist.gov/msidlibrary/doc/seuml2.pdf, October 2003. Bock, Conrad, "UML 2 Activity and Action Models," Part 2: Actions, Journal of Object Technology, 2: 5, 4156, http://www.jot.fm/issues/issue_2003_09/column4, September/October 2003. Bock, Conrad, "UML 2 Activity and Action Models," Journal of Object Technology, 2:4, 43-53, http://www.jot.fm/issues/issue_2003_07/column3, July/August 2003. Bock, Conrad, "UML Without Pictures," IEEE Software Special Issue on Model-Driven Development, 20:5, 3335, http://www.nist.gov/msidlibrary/doc/umlwopictures.pdf, September/October 2003. http://www.sysml.org 207
Further Info
Web
www.sysml.org Cris Kobryn

Chairs
cris.kobryn@telelogic.com; cris@sysml.org sanford.friedenthal@lmco.com; sandy@sysml.org
Sandy Friedenthal
208

Sysml Tutorial

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Sysml Tutorial

Uploaded by

Copyright:

Available Formats

Systems Modeling Language Overview

May 20, 2005

Provide overview of SysML specification Caveat

SE Practices for Describing Systems

Moving from Document centric to Model centric

These 3 standards organizations are influencing the future of systems engineering

Why Model Based Approach ?

Applying the Model Based Approach

Why UML for Systems Engineering ?

Unified Modeling Language (UML)

Visual Modeling Language = Notation + Semantics

Semantics = meaning Notation = representation of meaning

The OMG Process

RFI optional Issued by Task Forces

RFI responses submitted by any interested party, evaluated by working groups

RFP responses, known as submissions

Finalization Task Force

1.0 Original submittal

1.1 UML Partners final submittal

1.2 Editorial clean-up (1998)

1.3 Revisions, not enhancements

1.4 Revision Task Force completed assignment

1.5 Another RTF chartered

3 UML 2.0 RFPs issued Sept. 2000

UML 2.0 Specification finalization approved Nov. 2004

Informal partnership of modeling tool users, vendors, etc.

SysML Partners (cont.)

This effort is ongoing

SysML Milestones (2)

Submit final revised submission to OMG

June 22 (Wednesday): ADTF meeting at OMG Technical Meeting (Boston, MA)

Present final revised submission

Week of July 10: INCOSE Symposium (Rochester, NY)

SysML tutorial and vendor SysML demonstrations

September 14 (Wednesday): ADTF meeting at OMG Technical Meeting (Atlanta, GA)

Vote-to-recommend (followed by PTC vote-to-recommend and formation of FTF)

New Phase of SysML

V0.9 represents a critical milestone

Artisan EmbeddedPlus Telelogic ILogix ???? www.sysml.org

Initiate public Google forum to capture issues

January 04 INCOSE Comments

Review a great success!

A summary of representative issues follows. Continued close cooperation of SysML/AP233/MDSD teams.

INCOSE endorse SysML as INCOSEs product copyright,

synchronize SysML drafts and progress.

UML for SE Requirements

UML for SE Request For Proposal

OMG Doc# ad/03-03-41

Top Level Concept Model- INCOSE

(7) Stakeholder part of

(6) Environment (1) Element C

has view exhibits

Focuses on general purpose system modeling

System System System System System System

Component Specific Methods (e.g. HW, SW)

UML for SE RFP Requirements Traceability

SysML Diagram / Chapter

See SysML Requirements Traceability Appendix for Details

SysML Diagram / Chapter

SysML Diagram / Chapter

Diagram Appendix Parametric

Activity Activity, Sequence, State Parametrics, AP-233 Appendix

1.0 1.0 1.x, 2.0 1.x