You are on page 1of 68

An Overview of the Systems Modeling

(SysML) Specification

Shana L. Lloyd
Julie A. Street

The Aerospace Corporation

Systems Modeling Language (SysML) and


Unified Model Language (UML) are a registered
trademarks of Object Management Group, Inc. in the
United States and/or other countries November 4, 2021 1
Outline
• Background

• Request for Proposal (RFP)

• The Spec

• More Information

November 4, 2021 2
Background

November 4, 2021 3
Background
• The SE community is moving
from a document-centric
approach to a model-driven
approach
– Need integration of SE models with
other discipline-specific models
(software, hardware, simulation &
analysis, etc.)
• Unified Modeling Language
(UML) was designed for
Software Engineers
– Lacks all of the mechanisms
needed for Systems Engineers
November 4, 2021 4
SysML
“SysML is a general-purpose
graphical modeling
language for specifying,
analyzing, designing and
verifying complex systems
that may include hardware,
software, information,
personnel, procedures, and
facilities.”
November 4, 2021 5
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
November 4, 2021 6
Modeling in UML
• What can you model in UML?
– Structures
• Captures the physical & compositional structure of
the system
• E.g. Class Diagrams & Deployment Diagrams
System

– Behaviors <<include>>

use case 1

• Captures the high level behavior of the system Actor1

comm on use ca se

• E.g. Use Cases & Activity Diagrams <<include>>

use case 2
Actor2

– Interactions
• Captures the details behind the behavior of the
system
• E.g. Sequence Diagrams, Collaboration Diagrams
and Timing Diagrams

November 4, 2021 7
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 integration
problems by supplying open, vendor-neutral portability,
interoperability and reusability specifications based on
Model Driven Architecture (MDA).”
• Established Standards
– Common Object Request Broker Architecture (CORBA)
– Unified Modeling Language (UML)
– Meta-Object Facility (MOF)
– And more

November 4, 2021 8
Model Driven Architecture (MDA)
• Purpose of Model Driven Architecture
– Separate the specification of system functionality
from specification of implementation (i.e. a specific
technology platform)
• Concepts of MDA
1. Model : presentation of a function, structure,
and/or behavior of a
2. system
Platform: a subsystem that provides functionality through
interfaces and usage patterns that any system can use
without knowing the details of how that functionality is
implemented
3. Platform Independent Model (PIM): A system model that
contains no platform-specific information
4. Platform Specific Model (PSM): A system model that
includes technology and platform-specific information
5. Mapping: Transforming the elements of one model to
another model
November 4, 2021 9
The Request for Proposal

November 4, 2021 10
SysML Specification Timeline
Sterotypes &
OMG
Initial spec (v0.3)
presented to INCOSE Model Libraries announces
International Chapter the adoption
Workshop submitted as an of OMG
amendment to
spec v0.9 Draft specs SysML
submitted
2003 2005 2006
Mar May Jan Feb Jan May July Aug Nov Dec April July

2004
Spec v0.9
submitted to OMG INCOSE &
OMG
Multi-vendor
Initial submission evaluate
demonstration of v0.9
to OMG submissions
spec presented to SysML 1.0 Spec
UML for SE RFP INCOSE. Submitted to OMG
issued

November 4, 2021 11
Request for Proposal (RFP) Background
• Decision to pursue UML
for systems engineering
made at INCOSE
International Workshop
in January 2001
• Memorandum of
Understanding between SE DSIG Activities
OMG & INCOSE signed – Issued of Request for
• Systems Engineering Information (RFI)
Domains Special – Developed Systems
Interest Group (SE Engineering Conceptual
DSIG) chartered Model
– Collaborated with UML 2.0
• SE DSIG Kickoff submission teams
Meeting Sept. 2001 – Developed a requirements
analysis
November 4, 2021 12
SE Conceptual Model
Captures
essential
concepts of
systems
engineering in
form of a UML
model

Used as
input for
SysML
requirements

November 4, 2021 13
Request for Information (RFI)
• RFI Issued February Companies that Responded
• Tofs AB
2002 • BAE Systems, CNI Division
• Reponses Due August • Rational Software
2002 • Volvo Car Corporation
• Goals of the RFI • Lockheed Martin
• Frank Matyskiela Systems
– Help formulate SysML
Engineering Consul
requirements
• I-Logix
– Identify potential • INCOSE OOSEM WG
solutions
• MITRE
– Identify interested • Georgia Tech
stakeholders • ARTISAN Software Tools
• Holistic Systems Engineering
• Project Technology

November 4, 2021 14
SysML Request for Proposal (RFP)
• Solicited submissions that specify a
customization of UML for Systems
Engineering (SysML)
– Released March 28,2003
• Specification Goals
– Support modeling a broad range of
systems
• 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 systems
information among stakeholders

November 4, 2021 15
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 are
substitutable and interoperable
• Be compatible with ISO’s Reference Model of Open
Distributed Processing [RM-ODP]
• Address security questions and concerns
• Specify the degree of internationalization support

November 4, 2021 16
Spec Mandatory Requirements
• Structure
Systems Modeling – System hierarchy
Elements – Environment
• Structure – System interconnection
• Port
• Property • System Boundary
• Connection
• Behavior – Deployment to nodes
• Requirement • Property
• Verification – Property type
– Property value
• Other
– Property association
– Time property
– Parametric model
– Probe
November 4, 2021 17
Spec Mandatory Requirements (2)
• Requirement
• Behavior – Requirement specification
– Functional Transformation of – Requirement properties
– Requirement relationships
Inputs to Outputs – Problem
• Input/Outputs – Problem association
• System Store – Problem cause
• Function • Verification
– Function – Verification Process
– Test case
activation/deactivation – Verification result
• Control input – Requirement verification
• Control operator – Verification procedure
– Verification system
• Events and conditions
• Other
– Function-based behavior – General relationships
– State-based behavior – Model views & diagram types
• Activation time – System role
– Allocation of behavior to
systems

November 4, 2021 18
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-specific
models
• Testing model
• Management model
November 4, 2021 19
Submission Requirements
• Include ‘proof of concept’ • Submit a requirements
statement explaining how resolution matrix
specifications are • Grant OMG world-wide,
technically viable royalty-free license of the
– “An implementation of this spec
specification
has been in beta-test for 4- • Show commitment to
months” support commercial
– “A named product (with a success of products
specified customer base)
is a realization of this
specification.”

November 4, 2021 20
SysML Team
• American Systems Corporation • Mentor Graphics
• ARTISAN Software Tools • Motorola, Inc.
• BAE SYSTEMS • National Institute of Standards and
• The Boeing Company Technology
• Deere & Company • Northrop Grumman Corporation
• EADS Astrium GmbH • oose.de Dienstleistungen fur
• EmbeddedPlus Engineering innovative Informatik GmbH
• PivotPoint Technology Corporation
• Eurostep Group AB
• Raytheon
• Gentleware AG
• • TelelogicAB
Georgia Institute of Technology
• • THALES
I-Logix
• • Vitech
International Business
Machines
• Lockheed Martin Corporation

November 4, 2021 21
The SysML Spec

November 4, 2021 22
SysML Language Architecture
UML not required by SysML

SysML:
UML • Reuses a subset of
UML 2.0
• Uses UML 2.0 profile
mechanisms to
specify extensions for
UML reused by UML4SysML SysML
SysML

SysML
extensions
SysML to UML
(Have no counterpart in UML
or place UML constructs)

November 4, 2021 23
Reuse & Extensions
Extensions to UML
UML reused for SysML
• SysML::Model Elements refactors
• Actions
and extends Kernel
• Activities
• SysML:: Blocks reuses Composite
• Classes structures & Model Elements
• General Behavior • SysML::ConstraintBlocks extends
• Information Flows Blocks
• Interactions • SysML::Ports & Flows extends UML
• Models Ports
• Profiles • SysML::Activities extends UML
• State Machines Activities
• Structures • SysML::Allocations extends UML
dependencies
• Use Cases
• SysML::Requirements extends
Classes and dependencies
November 4, 2021 24
SysML Diagram Taxonomy

SysML Merge Team Submission v0.99 p.9

November 4, 2021 25
Four Pillars of SysML

November 4, 2021 26
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 what
actually 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
November 4, 2021 27
Structural-Model Elements
• Model Elements UML4SysML
– Common elements that can •Comment
be used in any diagram •Conform
– Extended to be consistent •Constraint
•Dependency
with IEEE 1471 Standard
•Element Import
• Diagrams •Model
– Any diagram! •Package
•Realization
•Refine

SysML
•Problem
•Rationale
•View
•ViewPoint
November 4, 2021 28
Structural – Model Elements
• View: View of a whole system • Rationale: Capture analysis,
from single perspective decisions, requirements
– Model Notation – Stereotype <<rationale>>
• ViewPoint: View for addressing a inside a comment
set of stakeholder concerns
– Class Notation

View

A standard
way to capture
design decisions View
and explicitly Point
specify views
Rationale
November 4, 2021 29
Modified version of figure 7-3 in Submission Team spec v 0.98
Structural - Blocks
• Block: Basic modular unit for UML4SysML
structure of system •Package
•Actor
– UML Equivalent: Classes •DataType
• Two Diagrams •isAbstract Classifier
•Stereotype
– Block Definition Diagram •Dependency
• Defines relationships between •Association
blocks •Generalization
• UML equivalent: Class •Generalization Set
Diagrams •Nested Classifier
– Internal Block Diagram •Connector
• Defines internal structure of a SysML
block •Block
• UML equivalent: Structured •Block Property
Class Diagrams •Value Type
•Compartment

November 4, 2021 30
Structural- Blocks
• Value Type : values that express
information about the system
– UML Equivalent: Data Types Block
Compartments
• 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
• Property Specification Type: keyword on
any internal property of a block to indicate
Property
its standard SysML taxonomy
Specification
– «part», «reference», and «value»
– Internal Block Diagrams only

November 4, 2021 31
Structural-Block Examples
Block Definition Diagram Internal Block Diagram
Defines system composition and Defines internal structure and how
relationships blocks are used

Easily capture
non-software parts
with the flexibility
to add custom
properties

November 4, 2021 32
Modified version of figure 8-8 & 8-9 in Submission Team spec v 0.98
Structural – Ports & Flows
• Ports
– Interaction point between a
block or part and its UML4SysML
environment •Interface
– Clearly-defined interfaces
– Used on Block Diagrams
SysML
• Flow •Service Port
– Data passing through ports •Flow Port
•Flow Specification
• Two Diagrams •Item Flow
– Block Definition Diagram
– Internal Block Diagram

November 4, 2021 33
Structural – Ports & Flows
• Flow Port : What can flow • Item Flow: What does
in or out of a block flow between blocks in
– Used for asynchronous, some context
broadcast, or send and forget – Used for asynchronous,
interactions. broadcast, or send and
forget interactions.
– Extension of UML 2.0 ports
– Extension of UML 2.0 ports
– E.g. Liquid can flow through a – E.g. Gasoline does flow
pipe through a car’s engine pipe

• Flow Property: A single • Service Port:Interaction


flow element point provided by a block
– Contains services to and
• Flow Specification: A set from its environment
of flow properties – Equivalent to UML 2.0 ports

November 4, 2021 34
Structural – Ports & Flows
Block Definition Internal Block Diagram
Diagram Defines how ports are used
Defines port composition

What
does flow!

November 4, 2021 35
Modified version of figure 9-3 & 9-6 in Submission Team spec v 0.98
Structural – Constraint Blocks
• Constraint Block
– Capture reusable engineering
analysis with blocks
• E.g. Mathematical expressions that
relate physical properties UML4SysML
• Constraint Property •N/A
– Block Property typed as
Constraint Block
• Define Constraint Blocks
– Block Definition Diagram
SysML
– Package Diagram
•Constraint Block
• Use Constraint Blocks •Constraint Property
– Internal Block Diagrams
– Parametric Diagrams
• Specialized internal block diagram
• Must be bound to Constraint
Parameter

November 4, 2021 36
Structural – Constraint Blocks
Block Definition Parametric Diagram
Diagram Show how the constraint
Defines the constraint blocks blocks are used

Nested property
constraints Integrate
analysis in
Property design
constraints
November 4, 2021 37
Modified version of figure 10-2 & 10-3 in Submission Team spec v 0.98
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

November 4, 2021 38
Behavioral -Activities
UML4SysML
•Action •Initial/Final/
• Activities •Activity Final Flow Node
•Activity Edge •Interruptible
– Typically used for business Region
•Activity Node
process modeling or logic in •Activity Final •Fork/Join/Merge
a single use case •Activity Parameter Node
Node •isControl Pin
– Extends UML 2.0 to support •isStream Parameter
•Activity Partition
disabling of actions that are •Control Operator •Pre/Post Conditions
already executing •Control Flow •No Buffer
•Control/Decision •Object Node
• Diagrams Node •Object FLow
•Parameter Set
– Activity Diagram
• Some modifications for UML
2.0 diagrams SysML
•No Buffer
•Overwrite
•Optional
•Probability
•Rate/Continuous/Discrete
November 4, 2021 39
Behavioral -Activities
• Overwrite: Stereotype added to a object node to signify that if a
new token 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

November 4, 2021 40
Behavioral -Activities

Explicitly capture
flow rates and
path probabilities

Probability

Rate

November 4, 2021 41
Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98
Behavioral - Interactions
UML4SysML
• Interactions •Interaction
– Describe interactions between •Lifeline
entities •Execution Specification
•Interaction Use
– Extends UML Timing Diagram
•Combined Fragment
• Additionally represent properties
•Continuation
and actions on the y-axis
•Creation/Destruction Event
• Additionally can mode continuous
•Interaction Duration/
varying values
Time Constraint
– Excludes Communication & •Messages
Interaction Overview Diagrams •General Ordering
• Diagrams •State Invariant

– Sequence Diagram
SysML
– Timing Diagram N/A

November 4, 2021 42
Behavioral – State Machines
• State Machines
– Describes entities behavior UML4SysML
•State Machine
with states and transitions
•Pseudo States
– Also used for defining •State
protocols •Region
– No changes from UML 2.0 •Submachine State
•Transition

• Diagrams
– State Machine Diagrams
SysML
N/A

November 4, 2021 43
Behavioral – Use Cases
• Use Cases
UML4SysML
– Describes the system’s •Use Case
functionally and usage •Actor
– No changes from UML 2.0 •Subject
•Associations
•Includes
• Diagrams •Extends
•Generalization
– Use Case Diagrams

SysML
N/A

November 4, 2021 44
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 fragment’s

November 4, 2021 45
Crosscutting - Allocations
• Allocations
– Denotes organized cross- UML4SysML
N/A
associations
– Custom Types
– SysML defined Types
• Behavior
• Flow SysML
• Structure •Allocated Stereotype
• Diagrams •Allocated Properties
•Allocation Activity
– Block Definition Diagrams •Allocation
– Internal Block Diagrams
– Activity Diagrams
– Tabular Representation

November 4, 2021 46
Crosscutting - Allocations
Partitions to Allocate Activities
(Behavior)

Explicitly
allocate
behavior to
structure

figure 15-10 in Submission Team spec v 0.98


Allocated StructureNovember 4, 2021 47
Crosscutting - Requirements
• Requirement
UML4SysML
– Functionality that a system •Namespace Relationship
must provide
– SysML can now represent
requirements in graphical SysML
format •Requirement
•Requirement Containment
•Copy
• Diagrams •Test Case
•Derive Requirement
– Requirement Diagrams
•Satisfy
– Tabular Representation •Verify
•Refine
•Trace

November 4, 2021 48
Crosscutting - Requirements
• DeriveRqt:Stereotype applied to an • Verify: Stereotype applied to an
association in which one requirement association where a test case
can be derived from a different fulfills a requirement
requirement – Verified: Stereotype added to
– Derive: Stereotype added to requirement that it participates in a
requirement in a DeriveRqt verify relationship
relationship
• TraceRqt: Stereotype applied to
• RefineRqt: Stereotype applied to an an association that adds a general
association in which one requirement purpose relationship between a
adds more detail to another requirement and any other model
requirement element
– Refine: Stereotype added to – Traced: Stereotype added to
requirement in a RefineRqt
requirement that denote that the
relationship
two elements are related in a
certain way using the value of its
• Satisfy: Stereotype applied to an derived properties.
association in which a model element
fulfills a requirement • Test Case: A method for verifying
– Satisfied: Stereotype added to
requirement that it participates in a a requirement is satisfied.
satisfy relationship

November 4, 2021 49
Crosscutting - Requirements
Requirements Diagram
Defines system requirements
Requirements Diagram
Shows a test case that adds more
detail to a requirement

Standard way
to capture
requirements and
link then within
the model!

November 4, 2021 50
Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98
Crosscutting – Profiles & Model Libraries
• Profile UML4SysML
•Stereotype
– Mechanisms to extend SysML •Class
•Profile
•Model Library
• Model Library •Extension
– Defines all the packages a •Generalization
model uses •Profile Application
•Package Import
•Element Import
• Diagrams •Unidirectional Association
•Note/In Node/On Edge/
– Package Diagrams In Compartment/
Compartment Stereotype

SysML
N/A

November 4, 2021 51
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 Management
Tools
• SysML interface with with standard requirement management tools unclear
November 4, 2021 52
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 management
tools

November 4, 2021 53
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

November 4, 2021 54
More Information

November 4, 2021 55
Available SysML Modeling Tools
• ARTiSAN Studio by ARTiSAN Software

• SysML Toolkit by EmbeddedPlus


• 3rd Party Plug-in to IMB Rational Suite

• TAU G2 by Telelogic
• Telelogic recently acquired competitor I-Logix

• Enterprise Architect by Sparx Systems

November 4, 2021 56
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-lo
w_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 Special
Interest 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/

November 4, 2021 57
Of Related Interest
• RFP for UML Profile for DODAF/MODAF
issued September 2005
– http://www.omg.org/cgi-bin/doc?dtc/2005-09-12

November 4, 2021 58
References
• SysML Spec
– http://www.omg.org/cgi-bin/doc?ptc/06-05-04
• OMG
– www.omgsysml.org
– www.omg.org
• OMG’s SE DSIG
– syseng.omg.org/SysML.htm
• OMG’s UML for Systems Engineering RFP
– www.omg.org/cgi-bin/doc?ad/2003-3-41
• UML Resource Page
– www.uml.org

November 4, 2021 59
Backup

November 4, 2021 60
Use Existing OMG Specs
The UML spec is the
Proposals may build upon the foundation of the SysML spec
following specifications
• Unified Modeling Language (UML) ?
v1.4 & 1.5
• Meta Object Facility (MOF) v.1.4
– Framework for management and SysML
interchange of UML models
– XMI Metadata Interchange v1.2 &
2.0 MOF
– UML Human-Usable Textual
Notation (HUTN)
• UML 2.0
UML & Profiles
• UML Profiles & Business Process
& Rules

November 4, 2021 61
Spec Evaluation Criteria
• Ease of use • To be used by submitters
• Unambiguous and provide guidance to
• Precise the evaluators
• Complete • Apply to solutions as a
• Scalable whole. Not to each
• Adaptable to different domains individual requirement
• Evolvable
• Capable of model interchange
• Capable of diagram
interchange
• Process and method
independent
• Compliant with the UML
metamodel
• Verifiable

November 4, 2021 62
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 OMG’s 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)

November 4, 2021 63
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 act
adopt the standard.”
12. Finalization Task Force (FTF) is charted
• Prepares the adopted submission for publishing as a formal, publicly available
specification
• Ensures standard is implementable
• Produces prototype implementations
13. FTF recommends adoption of the draft standard, called the “Available
Specification”
14. TC recommends adoption to the Board of Directors
• Board of Directors votes and accepts the specification
15. OMG publishes the formal specification
16. Revision Task Force manages issues filed against the specification

November 4, 2021 64
OMG’s 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
November 4, 2021 65
Requirements Resolution Matrix
• Each proposal must include a matrix explain how it
satisfied the requirements
Many mandatory
– Full, Partial, or No Solution requirements may be
• Accomplished using: satisfied by the
existing UML spec.
– 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

November 4, 2021 66
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 concerns
in revised submissions
• Build consensus on acceptable
solutions
• Enable voting members to make
an informed selection decision

November 4, 2021 67
More on MDA
Portable Example -
PIM
PIM Billing System
Model
transform

Billing System
PSM
PSM Model for J2EE

transform

J2EE Code for


Code
Code Billing System

November 4, 2021 68

You might also like