Post on 30-May-2018
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
1/68
10 June 2010 1
An Overview of the Systems Modeling
(SysML) Specification
Shana L. Lloyd
Julie A. Street
The Aerospace Corporation
Systems Modeling Language (SysML) andUnified Model Language (UML) are a registered
trademarks of Object Management Group, Inc. in theUnited States and/or other countries
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
2/68
10 June 2010 2
Outline
Background
Request for Proposal (RFP)
The Spec
More Information
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
3/68
10 June 2010 3
Background
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
4/68
10 June 2010 4
Background
The SE community is movingfrom a document-centricapproach to a model-drivenapproach
Need integration of SE models withother discipline-specific models(software, hardware, simulation &analysis, etc.)
Unified Modeling Language
(UML) was designed forSoftware Engineers Lacks all of the mechanisms
needed for Systems Engineers
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
5/68
10 June 2010 5
SysML
SysML is a general-purposegraphical modelinglanguage for specifying,
analyzing, designing andverifying complex systemsthat may include hardware,
software, information,personnel, procedures, andfacilities.
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
6/68
10 June 2010 6
What is UML?
Unified Modeling Language (UML)
Object modeling and specification language used in
software engineering
Object Management Group (OMG) manages and
maintains UML Goals of UML
Provide a method of consistent and effective
communication among software engineers
Provide a way to understand software designs
without code or psuedocode Specify, visualize, and document software designs
Raise the level of abstraction to focus on system
aspects rather than implementation details
Provide multiple views of the system
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
7/68
10 June 2010 7
Modeling in UML
What can you model in UML?
Structures
Captures the physical & compositional structure of
the system
E.g. Class Diagrams & Deployment Diagrams
Behaviors
Captures the high level behavior of the system
E.g. Use Cases & Activity Diagrams
Interactions Captures the details behind the behavior of thesystem
E.g. Sequence Diagrams, Collaboration Diagrams
and Timing Diagrams
c
s
c
s
s
c
s
ct
r
ct
r
s
c
s
st
c
s
c
s
s
c
s
ct
r
ct
r
s
c
s
st
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
8/68
10 June 2010 8
Object Management Group (OMG)
OMG is leading the SysML Effort
Who is OMG? International software consortium established in 1989
Members include vendors, developers, and end users
Mission To help computer users solve enterprise integrationproblems by supplying open, vendor-neutral portability,interoperability and reusability specifications based on ModelDriven Architecture (MDA).
Established Standards Common Object Request Broker Architecture (CORBA)
Unified Modeling Language (UML)
Meta-Object Facility (MOF)
And more
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
9/68
10 June 2010 9
Purpose of Model Driven Architecture Separate the specification of system functionality
from specification of implementation (i.e. a specifictechnology platform)
Concepts of MDA
1. Model : presentation of a function, structure,and/or behavior of a system
Model Driven Architecture (MDA)
2. Platform: a subsystem that provides functionality throughinterfaces and usage patterns that any system can usewithout knowing the details of how that functionality isimplemented
3. Platform Independent Model (PIM):A system model thatcontains no platform-specific information
4. Platform Specific Model (PSM):A system model thatincludes technology and platform-specific information
5. Mapping: Transforming the elements of one model to another
model
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
10/68
10 June 2010 10
The Request for
Proposal
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
11/68
10 June 2010 11
SysML Specification Timeline
2003
Initial spec (v0.3)
presented to INCOSE
International Workshop
Jan
Initial submission
to OMG
Feb
Spec v0.9
submitted to OMG
MayJan
Sterotypes &
Model Libraries
Chapter submitted
as an amendment
to spec v0.9
Multi-vendordemonstration of v0.9
spec presented to
INCOSE.
July Aug Nov AprilDec
Draft specs
submitted
INCOSE &
OMG evaluate
submissions
SysML 1.0 Spec
Submitted to OMG
Mar
UML for SE RFP
issued
May
2004
2005 2006
July
OMG
announces
the adoption
of OMG
SysML
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
12/68
10 June 2010 12
Request for Proposal (RFP) Background
Decision to pursue UMLfor systems engineeringmade at INCOSEInternational Workshopin January 2001
Memorandum ofUnderstanding betweenOMG & INCOSE signed
Systems EngineeringDomains SpecialInterest Group (SEDSIG) chartered
SE DSIG KickoffMeeting Sept. 2001
SE DSIG Activities Issued of Request for
Information (RFI)
Developed Systems
Engineering Conceptual
Model
Collaborated with UML 2.0
submission teams
Developed a requirements
analysis
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
13/68
10 June 2010 13
SE Conceptual Model
Capturesessential
concepts ofsystems
engineering inform of a UML
model
Used asinput forSysML
requirements
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
14/68
10 June 2010 14
Request for Information (RFI)
RFI Issued February
2002
Reponses Due August
2002
Goals of the RFI
Help formulate SysML
requirements
Identify potential
solutions
Identify interested
stakeholders
Companies that Responded Tofs AB
BAE Systems, CNI Division
Rational Software
Volvo Car Corporation
Lockheed Martin Frank Matyskiela Systems
Engineering Consul
I-Logix
INCOSE OOSEM WG
MITRE Georgia Tech
ARTISAN Software Tools
Holistic Systems Engineering
Project Technology
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
15/68
10 June 2010 15
Solicited submissions that specify acustomization of UML for SystemsEngineering (SysML) Released March 28,2003
Specification Goals Support modeling a broad range ofsystems
Hardware, software, data, personnel,procedures, and facilities
Capture system information precisely and
efficiently Allow for the analysis and evaluation of
the modeled system
Provide clear communication of systemsinformation among stakeholders
SysML Request for Proposal (RFP)
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
16/68
10 June 2010 16
Proposal Requirements
Express models in OMG modeling languages (i.e. UML) Be precise and functionally complete
Identify mappings between platform independent model(PIM) & platform specific models (PSMs)
Specify what features are required in implementations
and which are optional Be compatible and useable with existing OMG specs
Justify changes or extensions to existing OMG specs
Preserve maximum implementation flexibility
Allow for independent implementations that aresubstitutable and interoperable
Be compatible with ISOs Reference Model of OpenDistributed Processing [RM-ODP]
Address security questions and concerns
Specify the degree of internationalization support
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
17/68
10 June 2010 17
Spec Mandatory Requirements
Structure System hierarchy
Environment
System interconnection Port
System Boundary Connection
Deployment to nodes
Property Property type
Property value Property association
Time property
Parametric model
Probe
Systems Modeling
Elements
Structure
Property
Behavior
Requirement
Verification
Other
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
18/68
10 June 2010 18
Spec Mandatory Requirements (2)
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
Behavior Functional Transformation of
Inputs to Outputs
Input/Outputs
System Store
Function Function
activation/deactivation
Control input
Control operator
Events and conditions Function-based behavior
State-based behavior Activation time
Allocation of behavior tosystems
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
19/68
10 June 2010 19
Spec 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-specificmodels
Testing model
Management model
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
20/68
10 June 2010 20
Submission Requirements
Submit a requirementsresolution matrix
Grant OMG world-wide,
royalty-free license of the
spec Show commitment to
support commercial
success of products
Include proof of conceptstatement explaining how
specifications are
technically viable
An implementation of this
specification
has been in beta-test for 4-
months
A named product (with a
specified customer base)
is a realization of thisspecification.
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
21/68
10 June 2010 21
SysML Team
American Systems Corporation
ARTISAN Software Tools
BAE SYSTEMS
The Boeing Company
Deere & Company
EADS Astrium GmbH
EmbeddedPlus Engineering
Eurostep Group AB
Gentleware AG
Georgia Institute of Technology
I-Logix
International Business
Machines
Lockheed Martin Corporation
Mentor Graphics
Motorola, Inc.
National Institute of Standards and
Technology
Northrop Grumman Corporation
oose.de Dienstleistungen furinnovative Informatik GmbH
PivotPoint Technology Corporation
Raytheon
TelelogicAB
THALES Vitech
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
22/68
10 June 2010 22
The SysML Spec
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
23/68
10 June 2010 23
UML4SysML
UML
SysML
SysML Language Architecture
UML reusedby SysML
SysML: Reuses a subset of
UML 2.0
Uses UML 2.0 profilemechanisms to
specify extensions for
SysML
UML not required by SysML
SysMLextensionsto UML
(Have no counterpart in UMLor place UML constructs)
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
24/68
10 June 2010 24
Reuse & Extensions
UML reused for SysML
Actions
Activities
Classes
General Behavior
Information Flows
Interactions
Models
Profiles
State Machines
Structures
Use Cases
Extensions to UML SysML::Model Elements refactors
and extends Kernel
SysML:: Blocks reuses Composite
structures & Model Elements
SysML::ConstraintBlocks extends
Blocks
SysML::Ports & Flows extends UML
Ports
SysML::Activities extends UML
Activities
SysML::Allocations extends UML
dependencies
SysML::Requirements extends
Classes and dependencies
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
25/68
10 June 2010 25
SysML Diagram Taxonomy
SysML Merge Team Submission v0.99 p.9
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
26/68
10 June 2010 26
Four Pillars of SysML
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
27/68
10 June 2010 27
SysML Summary
View Major Extensions Benefits
Structural Model Elements Standard way to capture views and design
decisions
Blocks Flexibility to model non-software
components with custom properties
Ports and Flows Differentiate between what could and whatactually does travel through a port
Constraint Blocks Ability to integrate analysis in designs
Behavioral New Activity Diagram More control over activities, ability to model
continuous streams and path probability
Stereotypes New stereotypes for easily behavior classification
Crosscutting Allocations More flexible mapping capabilities
Requirements Ability to model requirements, their
relationships, and links back to the design
diagrams
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
28/68
10 June 2010 28
Structural-Model Elements
Model Elements
Common elements that can
be used in any diagram
Extended to be consistent
with IEEE 1471 Standard
Diagrams
Any diagram!
SysMLSysMLProblem
Rationale
View
ViewPoint
UML4SysMLUML4SysMLComment
Conform
Constraint
Dependency
Element ImportModel
Package
Realization
Refine
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
29/68
10 June 2010 29
Rationale: Capture analysis,decisions, requirements
Stereotype rationale
inside a comment
Structural Model Elements
View: View of a whole systemfrom single perspective
Model Notation
ViewPoint: View for addressing aset of stakeholder concerns
Class Notation
View
View
Point
Rationale
A standard
way to capturedesign decisions
and explicitly
specify views
Modified version of figure 7-3 in Submission Team spec v 0.98
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
30/68
10 June 2010 30
Structural - Blocks
Block: Basic modular unit forstructure of system
UML Equivalent: Classes
Two Diagrams
B
lock Definition Diagram Defines relationships betweenblocks
UML equivalent: Class
Diagrams
Internal Block Diagram
Defines internal structure of a
block
UML equivalent: Structured
Class Diagrams
UML4SysMLUML4SysMLPackage
Actor
DataTypeisAbstract Classifier
Stereotype
DependencyAssociation
Generalization
Generalization SetNested Classifier
Connector
SysMLSysMLBlock
Block Property
Value TypeCompartment
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
31/68
10 June 2010 31
Structural- Blocks
Value Type : values that expressinformation about the system
UML Equivalent: Data Types
Compartments: partition of a block with
features for the compartment type
User-defined or standard SysML SysML Compartments: Namespace,
Constraint, Structure
UML Equivalent : Class Operations &
Attribute
P
roperty SpecificationT
ype: keyword onany internal property of a block to indicate
its standard SysML taxonomy
part, reference, and value
Internal Block Diagrams only
Compartments Block
Property
Specification
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
32/68
10 June 2010 32
Structural-Block Examples
Block Definition Diagram
Defines system composition and
relationships
Internal Block Diagram
Defines internal structure and how
blocks are used
Easily capturenon-software parts
with the flexibility
to add custom
properties
Modified version of figure 8-8 & 8-9 in Submission Team spec v 0.98
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
33/68
10 June 2010 33
Structural Ports & Flows
Ports Interaction point between a
block or part and its
environment
Clearly-defined interfaces
Used on Block Diagrams
Flow
Data passing through ports
Two Diagrams
Block Definition Diagram Internal Block Diagram
SysMLSysMLService Port
Flow Port
Flow Specification
Item Flow
UML4SysMLUML4SysMLInterface
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
34/68
10 June 2010 34
Structural Ports & Flows
Flow Port : What can flowin or out of a block Used for asynchronous,
broadcast, or send and forget
interactions.
Extension of UML 2.0 ports E.g. Liquid can flow through a
pipe
Flow Property:A singleflow element
Flow Specification:A setof flow properties
Item Flow: What doesflow between blocks insome context Used for asynchronous,
broadcast, or send andforget interactions.
Extension of UML 2.0 ports E.g. Gasoline does flow
through a cars engine pipe
Service Port:Interactionpoint provided by a block Contains services to and
from its environment Equivalent to UML 2.0 ports
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
35/68
10 June 2010 35
Structural Ports & Flows
Block Definition Diagram
Defines port composition
Internal Block Diagram
Defines how ports are used
Modified version of figure 9-3 & 9-6 in Submission Team spec v 0.98
What
does flow!
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
36/68
10 June 2010 36
Structural Constraint Blocks
Constraint Block Capture reusable engineering
analysis with blocks E.g. Mathematical expressions that
relate physical properties
Constraint Property
Block Property typed asConstraint Block
Define Constraint Blocks
Block Definition Diagram
Package Diagram
Use Constraint Blocks
Internal Block Diagrams Parametric Diagrams
Specialized internal block diagram
Must be bound to ConstraintParameter
SysMLSysMLConstraint Block
Constraint Property
UML4SysMLUML4SysML
N/A
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
37/68
10 June 2010 37
Structural Constraint Blocks
Block Definition DiagramDefines the constraint blocks
Parametric DiagramShow how the constraint
blocks are used
Integrate
analysis in
design
Modified version of figure 10-2 & 10-3 in Submission Team spec v 0.98
Property
constraints
Nested property
constraints
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
38/68
10 June 2010 38
Structural Overall Assessment
Advantages Easy to Understand with UML 2.0 Knowledge
A lot of UML 2.0 reuse
Clear equivalent UML 2.0 diagrams & notations
Capturing System Elements Easy Blocks flexible enough to model any element
Custom compartments powerful for capturing element specialized characteristics
Capturing Design Decisions in Design Easy Rationale stereotype capturing design decisions any diagrams
Will need to define standard for its usage.
Limitations
Consistency Difficult Many different views & viewpoints can make consistency difficult
System Element Uniformity Different groups will use different compartments to model same element
Potential to lead to domain specific extensions
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
39/68
10 June 2010 39
Behavioral -Activities
Activities
Typically used for business
process modeling or logic in
a single use case
Extends UML 2.0 to supportdisabling of actions that are
already executing
Diagrams
Activity Diagram
Some modifications for UML2.0 diagrams SysMLSysML
No Buffer
Overwrite
Optional
Probability
Rate/Continuous/Discrete
UML4SysMLUML4SysMLActionActivity
Activity Edge
Activity Node
Activity FinalActivity ParameterNode
Activity PartitionControl Operator
Control FlowControl/DecisionNode
Initial/Final/Final Flow Node
Interruptible
Region
Fork/Join/Merge
NodeisControl Pin
isStream ParameterPre/Post Conditions
No Buffer
Object NodeObject FLow
Parameter Set
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
40/68
10 June 2010 40
Behavioral -Activities
Overwrite: Stereotype added to a object node to signify that if a newtoken arrives, it will replace any existing tokens
Optional: Stereotype added to a parameter to signify it is not
required for activity to begin execution
Probability: Stereotype added to signify probability of usage Edges from decision or object nodes
Output parameter sets
Rate: Stereotype added to activity edge to specify the number of
objects and values that pass an edge at a given time interval Special cases = Continuous and Discrete
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
41/68
10 June 2010 41
Behavioral -Activities
Rate
Probability
Explicitly capture
flow rates and
path probabilities
Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
42/68
10 June 2010 42
Behavioral - Interactions
Interactions
Describe interactions between
entities
Extends UML Timing Diagram
Additionally represent propertiesand actions on the y-axis
Additionally can mode continuous
varying values
Excludes Communication &
Interaction Overview Diagrams
Diagrams Sequence Diagram
Timing DiagramSysMLSysML
N/A
UML4SysMLUML4SysMLInteraction
LifelineExecution Specification
Interaction Use
Combined Fragment
ContinuationCreation/Destruction Event
Interaction Duration/Time Constraint
Messages
General Ordering
State Invariant
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
43/68
10 June 2010 43
Behavioral State Machines
State Machines
Describes entities behavior
with states and transitions
Also used for defining
protocols No changes from UML 2.0
Diagrams
State Machine DiagramsSysMLSysML
N/A
UML4SysMLUML4SysMLState Machine
Pseudo States
State
RegionSubmachine State
Transition
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
44/68
10 June 2010 44
Behavioral Use Cases
Use Cases
Describes the systems
functionally and usage
No changes from UML 2.0
Diagrams
Use Case Diagrams
SysMLSysMLN/A
UML4SysMLUML4SysMLUse Case
Actor
Subject
Associations
IncludesExtendsGeneralization
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
45/68
10 June 2010 45
Behavioral Overall Assessment
Advantages Easy to Understand with UML 2.0 Knowledge
Minimal changes and additions in SysML
Timing Diagram Enhancements
Increased capability to model time & continuous values
Increased Data Flow Control Addition of rates and probabilities increases the ability to model different
types of input rates and paths through the system.
Limitations
Behavior Across Multiple Scenarios in One Diagram Communication diagrams are excluded
Limited Sequence Diagram fragments
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
46/68
10 June 2010 46
Crosscutting - Allocations
Allocations
Denotes organized cross-
associations
Custom Types
SysML defined Types Behavior
Flow
Structure
Diagrams
Block Definition Diagrams Internal Block Diagrams
Activity Diagrams
Tabular Representation
SysMLSysMLAllocated Stereotype
Allocated PropertiesAllocation Activity
Allocation
UML4SysMLUML4SysMLN/A
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
47/68
10 June 2010 47
Crosscutting - Allocations
Partitions to Allocate Activities
(Behavior)
Allocated Structure
Explicitly
allocate
behavior to
structure
figure 15-10 in Submission Team spec v 0.98
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
48/68
10 June 2010 48
Crosscutting - Requirements
Requirement
Functionality that a system
must provide
SysML can now represent
requirements in graphicalformat
Diagrams
Requirement Diagrams
Tabular Representation
SysMLSysMLRequirement
Requirement Containment
Copy
Test Case
Derive Requirement
SatisfyVerify
Refine
Trace
UML4SysMLUML4SysMLNamespace Relationship
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
49/68
10 June 2010 49
Crosscutting - Requirements
DeriveRqt:Stereotype applied to anassociation in which onerequirement can be derived from adifferent requirement Derive: Stereotype added to
requirement in a DeriveRqtrelationship
RefineRqt: Stereotype applied to anassociation in which onerequirement adds more detail toanother requirement Refine: Stereotype added to
requirement in a RefineRqtrelationship
Satisfy: Stereotype applied to anassociation in which a modelelement fulfills a requirement Satisfied: Stereotype added to
requirement that it participates in asatisfy relationship
Verify: Stereotype applied to anassociation where a test casefulfills a requirement Verified: Stereotype added to
requirement that it participates in averify relationship
TraceRqt: Stereotype applied to
an association that adds a generalpurpose relationship between arequirement and any other modelelement Traced: Stereotype added to
requirement that denote that thetwo elements are related in a
certain way using the value of itsderived properties.
Test Case: A method for verifying arequirement is satisfied.
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
50/68
10 June 2010 50
Crosscutting - Requirements
Requirements Diagram
Defines system requirementsRequirements Diagram
Shows a test case that adds more
detail to a requirement
Standard way
to capture
requirements andlink then within
the model!
Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
51/68
10 June 2010 51
Crosscutting Profiles & Model Libraries
Profile
Mechanisms to extend SysML
Model Library
Defines all the packages a
model uses
Diagrams
Package Diagrams
SysMLSysMLN/A
UML4SysMLUML4SysMLStereotype
Class
Profile
Model LibraryExtension
GeneralizationProfile Application
Package Import
Element Import
Unidirectional Association
Note/In Node/On Edge/
In Compartment/Compartment Stereotype
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
52/68
10 June 2010 52
Crosscutting Overall Assessment
Advantages Requirement Modeling
Potential to increase requirements traceability
Allocations Useful for clearly identifying cross cutting structures or responsibilities
Good Extension Mechanisms Same as UML 2.0
Good for reusable domain specific elements
Limitations Diagram Clutter
Requirement stereotypes are captured in comments, which have the potential
to clutter diagrams. Trace Requirement Relationship vague
Vague trace requirement relationship definition
Unknown Interoperability with Requirements ManagementTools
SysML interface with with standard requirement management tools unclear
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
53/68
10 June 2010 53
Summary Assessment
Advantages Easy to understand with UML 2.0 knowledge
Easy to capture variety of system entities
Easy to document decisions in design
Increase data flow control mechanisms
Easy to do requirements modeling
Limitations Potential for diagram clutter
Potential for inconsistencies between views Limited ability to model behavior across multiple scenarios in
one diagram
Unknown interoperability with requirements managementtools
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
54/68
10 June 2010 54
Comments on the Submitted Spec
OMG & INCOSE Comments on the Spec
Good
Reuse of UML 2
Timing & instance diagrams
Issues Missing built from
Not reusing the same element in
different views
Lack of allocation
Syntax rules unclear
Specification hard to understand
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
55/68
10 June 2010 55
More Information
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
56/68
10 June 2010 56
Available SysML Modeling Tools
ARTiSAN StudioARTiSAN Studio byby ARTiSANSoftware
SysMLT
oolkitSysMLT
oolkit by EmbeddedPlus 3rd Party Plug-in to IMB Rational Suite
TAUTAU G2 by Telelogic Telelogic recently acquired competitor I-Logix
Enterprise ArchitectEnterprise Architect by SparxSystems
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
57/68
10 June 2010 57
Recommendations
Now that you know the basics of SysML you can:
Read the tutorial Given at INCOSE 2006 Conference
http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE-060524-low_res.pdf
Attend INCOSE-WMA SysML Tutorial on Aug 12
Participate in the OMG SysML Discussion Group Official OMG sponsored group
http://groups.yahoo.com/group/OMGSysML/
Join the OMG Systems Engineering Domain SpecialInterest Group (SE DSIG) INCOSE members who want to join should email the SE DSIG
chair with their contact info & INCOSE member #
http://syseng.omg.org/
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
58/68
10 June 2010 58
Of Related Interest
RFP forUML Profile for DODAF/MODAF
issued September 2005 http://www.omg.org/cgi-bin/doc?dtc/2005-09-12
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
59/68
10 June 2010 59
References
SysML Spec http://www.omg.org/cgi-bin/doc?ptc/06-05-04
OMG
www.omgsysml.org
www.omg.org OMGs SE DSIG
syseng.omg.org/SysML.htm
OMGs UML for Systems Engineering RFP
www.omg.org/cgi-bin/doc?ad/2003-3-41 UML Resource Page
www.uml.org
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
60/68
10 June 2010 60
Backup
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
61/68
10 June 2010 61
Use Existing OMG Specs
Proposals may build upon thefollowing specifications
Unified Modeling Language (UML)
v1.4 & 1.5
Meta Object Facility (MOF) v.1.4
Framework for management and
interchange of UML models
XMI Metadata Interchange v1.2 &
2.0
UML Human-Usable Textual
Notation (HUTN) UML 2.0
UML Profiles & Business Process
& Rules
The UML spec is thefoundation of the SysML spec
MOF
SysMLSysML
UML & Profiles
?
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
62/68
10 June 2010 62
Spec Evaluation Criteria
To be used by submittersand provide guidance to
the evaluators
Apply to solutions as a
whole. Not to each
individual requirement
Ease of use Unambiguous
Precise
Complete
Scalable
Adaptable to different domains Evolvable
Capable of model interchange
Capable of diagraminterchange
Process and methodindependent
Compliant with the UMLmetamodel
Verifiable
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
63/68
10 June 2010 63
OMG Adoption Process
1. RFPs are drafted
Written by OMG members
Presented to the appropriate Task Force (TF)
2. RFPs are issued by a Technology Committee (TC)
Upon the recommendation of the TF & the Architecture Board (AB)
3. Submitting organization provides a Letter of Intent to the OMG
Signifies a willingness to comply to the OMGs terms and conditions
A member organization must be a member of the TC that issued the RFP
4. OMG members register to vote to select a specification
5. Initial submissions, revisions, and revised submissions are reviewed
6. TF evaluates final submissions
7. Registered OMG members vote to select a submission Result is a recommendation to adopt a specification to the TC
8. AB reviews the proposal for MDA compliance and technical merit
9. TC votes to recommend adoption to the OMG Board of Directors (BoD)
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
64/68
10 June 2010 64
OMG Adoption Process (2)
10. OMG Board of Directors vote
Resulting draft standard called Adopted Specification
11. Submitting members complete BoD Business Committee Questionnaire
Details how to use the specification in products
If no organization commits to use the standard, then the BoD will not actadopt the standard.
12. Finalization Task Force (FTF) is charted
Prepares the adopted submission for publishing as a formal, publiclyavailable specification
Ensures standard is implementable
Produces prototype implementations
13. FTF recommends adoption of the draft standard, called the AvailableSpecification
14. TC recommends adoption to the Board of Directors Board of Directors votes and accepts the specification
15.15. OMG publishes the formal specificationOMG publishes the formal specification
16. Revision Task Force manages issues filed against the specification
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
65/68
10 June 2010 65
OMGs Business Committee Requirements
There must be neither technical, legal nor commercial obstacles to[technologies] implementation.
Looks for commitment by submitter to the commercial success of products
Looks for evidence that each major feature has been implemented
Preferably more than once and by separate organizations
Should demonstrate cross-platform availability & interoperability Must show that products based on the spec are commercially available or
will be within 12 months
If the submitter is not a commercial SW provider, BC requires evidence of 2 or
more independent implementations of the specification
Will not adopt a spec if an intellectual property right infringement will occur Must grant OMG worldwide, royalty-free license of the submitted
specification
Must show a commitment to support the specification & supporting
technology
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
66/68
10 June 2010 66
Requirements Resolution Matrix
Each proposal must include a matrix explain how itsatisfied the requirements
Full, Partial, or No Solution
Accomplished using:
UML construct without modification UML construct with modification
Extension mechanism to define a new UML modeling element
Other approach
Reference to the satisfying syntax
Reference to samples problem that demonstrates
satisfaction
Issues & comments
Many mandatoryrequirements may be
satisfied by theexisting UML spec.
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
67/68
10 June 2010 67
Goals of RFP Evaluation
Fair and open process
Facilitate critical review of the
submissions by OMG members
Provide feedback to submitters to
allow them to address concernsin revised submissions
Build consensus on acceptable
solutions
Enable voting members to makean informed selection decision
8/9/2019 Presentation from August 8, 2006 Dinner Meeting
68/68
More on MDA
PIM
PSM
Code
transform
transform
Portable Example -
Billing System
Model
Billing System
Model forJ2EE
J2EE Code for
Billing System