April 10, 2023 1

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 theUnited States and/or other countries

April 10, 2023 2

Outline

• Background

• Request for Proposal (RFP)

• The Spec

• More Information

April 10, 2023 3

Background

April 10, 2023 4

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

April 10, 2023 5

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.”

April 10, 2023 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

April 10, 2023 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 the

system• E.g. Sequence Diagrams, Collaboration Diagrams

and Timing Diagrams

comm on use ca se

use case 1

<<include>>

Actor1

Actor2use case 2

<<include>>

System

comm on use ca se

use case 1

<<include>>

Actor1

Actor2use case 2

<<include>>

System

April 10, 2023 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 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

April 10, 2023 9

• Purpose of Model Driven Architecture– Separate the specification of system functionality

from specification of implementation (i.e. a specific technology platform)

• Concepts of MDA1. Model : presentation of a function, structure,

and/or behavior of a system

Model Driven Architecture (MDA)

2. 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

April 10, 2023 10

The Request for Proposal

April 10, 2023 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-vendor demonstration 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

April 10, 2023 12

Request for Proposal (RFP) Background

• Decision to pursue UML for systems engineering made at INCOSE International Workshop in January 2001

• Memorandum of Understanding between OMG & INCOSE signed

• Systems Engineering Domains Special Interest Group (SE DSIG) chartered

• SE DSIG Kickoff Meeting 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

April 10, 2023 13

SE Conceptual ModelCaptures essential

concepts of systems

engineering in form of a UML model

Used as input for SysML

requirements

April 10, 2023 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

April 10, 2023 15

• 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

SysML Request for Proposal (RFP)

April 10, 2023 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 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

April 10, 2023 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

April 10, 2023 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 to systems

April 10, 2023 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-specific

models• Testing model• Management model

April 10, 2023 20

Submission Requirements• Submit a requirements

resolution matrix• Grant OMG world-wide,

royalty-free license of the spec

• Show commitment to support commercial success of products

• Include ‘proof of concept’ statement 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 this specification.”

April 10, 2023 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 fur innovative Informatik GmbH

• PivotPoint Technology Corporation

• Raytheon

• TelelogicAB

• THALES

• Vitech

April 10, 2023 22

The SysML Spec

April 10, 2023 23

UML4SysML

UML

SysML

SysML Language Architecture

UML reused by SysML

SysML:• Reuses a subset of

UML 2.0

• Uses UML 2.0 profile mechanisms to specify extensions for SysML

UML not required by SysML

SysML extensions to UML

(Have no counterpart in UML or place UML constructs)

April 10, 2023 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

April 10, 2023 25

SysML Diagram Taxonomy

SysML Merge Team Submission v0.99 p.9

April 10, 2023 26

Four Pillars of SysML

April 10, 2023 27

SysML Summary

View Major Extensions Benefits

Structural Model Elements Standard way to capture views and design decisions

Blocks Flexibility to model non-softwarecomponents 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

April 10, 2023 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!

SysMLSysML•Problem•Rationale•View•ViewPoint

UML4SysMLUML4SysML•Comment•Conform•Constraint•Dependency•Element Import•Model•Package•Realization•Refine

April 10, 2023 29

• Rationale: Capture analysis, decisions, requirements – Stereotype <<rationale>>

inside a comment

Structural – Model Elements• View: View of a whole system

from single perspective – Model Notation

• ViewPoint: View for addressing a set of stakeholder concerns – Class Notation

View

ViewPoint

Rationale

A standard way to capture

design decisions and explicitly specify views

Modified version of figure 7-3 in Submission Team spec v 0.98

April 10, 2023 30

Structural - Blocks• Block: Basic modular unit for

structure of system– UML Equivalent: Classes

• Two Diagrams– Block Definition Diagram

• Defines relationships between blocks

• UML equivalent: Class Diagrams

– Internal Block Diagram• Defines internal structure of a

block

• UML equivalent: Structured Class Diagrams

UML4SysMLUML4SysML•Package•Actor•DataType•isAbstract Classifier•Stereotype•Dependency•Association•Generalization•Generalization Set•Nested Classifier•Connector

SysMLSysML•Block•Block Property•Value Type•Compartment

April 10, 2023 31

Structural- Blocks

• Value Type : values that express information 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

• Property Specification Type: keyword on any internal property of a block to indicate its standard SysML taxonomy – «part», «reference», and «value»

– Internal Block Diagrams only

Compartments Block

Property Specification

April 10, 2023 32

Structural-Block Examples

Block Definition DiagramDefines system composition and

relationships

Internal Block DiagramDefines internal structure and how

blocks are used

Easily capture non-software parts with the flexibility

to add custom properties

Modified version of figure 8-8 & 8-9 in Submission Team spec v 0.98

April 10, 2023 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

SysMLSysML•Service Port•Flow Port •Flow Specification•Item Flow

UML4SysMLUML4SysML•Interface

April 10, 2023 34

Structural – Ports & Flows• Flow Port : What can flow

in 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 single flow element

• Flow Specification: A set of flow properties

• Item Flow: What does flow between blocks in some context– Used for asynchronous,

broadcast, or send and forget interactions.

– Extension of UML 2.0 ports– E.g. Gasoline does flow

through a car’s engine pipe

• Service Port:Interaction point provided by a block– Contains services to and

from its environment– Equivalent to UML 2.0 ports

April 10, 2023 35

Structural – Ports & Flows

Block Definition Diagram

Defines port composition

Internal Block DiagramDefines how ports are used

Modified version of figure 9-3 & 9-6 in Submission Team spec v 0.98

What does flow!

April 10, 2023 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 as

Constraint 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 Constraint

Parameter

SysMLSysML•Constraint Block•Constraint Property

UML4SysMLUML4SysML•N/A

April 10, 2023 37

Structural – Constraint Blocks

Block Definition Diagram

Defines 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

April 10, 2023 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

April 10, 2023 39

Behavioral -Activities

• Activities– Typically used for business

process modeling or logic in a single use case

– Extends UML 2.0 to support disabling of actions that are already executing

• Diagrams– Activity Diagram

• Some modifications for UML 2.0 diagrams SysMLSysML

•No Buffer•Overwrite•Optional•Probability•Rate/Continuous/Discrete

UML4SysMLUML4SysML•Action•Activity•Activity Edge•Activity Node•Activity Final•Activity Parameter Node•Activity Partition•Control Operator•Control Flow•Control/Decision Node

•Initial/Final/Final Flow Node•Interruptible Region•Fork/Join/Merge Node•isControl Pin•isStream Parameter•Pre/Post Conditions•No Buffer•Object Node•Object FLow•Parameter Set

April 10, 2023 40

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

April 10, 2023 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

April 10, 2023 42

Behavioral - Interactions

• Interactions– Describe interactions between

entities– Extends UML Timing Diagram

• Additionally represent properties and actions on the y-axis

• Additionally can mode continuous varying values

– Excludes Communication & Interaction Overview Diagrams

• Diagrams– Sequence Diagram– Timing Diagram

SysMLSysMLN/A

UML4SysMLUML4SysML•Interaction•Lifeline•Execution Specification•Interaction Use•Combined Fragment•Continuation•Creation/Destruction Event•Interaction Duration/Time Constraint•Messages•General Ordering•State Invariant

April 10, 2023 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 Diagrams

SysMLSysMLN/A

UML4SysMLUML4SysML•State Machine•Pseudo States•State•Region•Submachine State•Transition

April 10, 2023 44

Behavioral – Use Cases

• Use Cases– Describes the system’s

functionally and usage– No changes from UML 2.0

• Diagrams– Use Case Diagrams

SysMLSysMLN/A

UML4SysMLUML4SysML•Use Case•Actor•Subject•Associations•Includes•Extends•Generalization

April 10, 2023 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 fragment’s

April 10, 2023 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

SysMLSysML•Allocated Stereotype•Allocated Properties•Allocation Activity•Allocation

UML4SysMLUML4SysMLN/A

April 10, 2023 47

Crosscutting - AllocationsPartitions to Allocate Activities

(Behavior)

Allocated Structure

Explicitly allocate

behavior to structure

figure 15-10 in Submission Team spec v 0.98

April 10, 2023 48

Crosscutting - Requirements

• Requirement– Functionality that a system

must provide– SysML can now represent

requirements in graphical format

• Diagrams– Requirement Diagrams– Tabular Representation

SysMLSysML•Requirement•Requirement Containment•Copy•Test Case•Derive Requirement•Satisfy•Verify•Refine•Trace

UML4SysMLUML4SysML•Namespace Relationship

April 10, 2023 49

Crosscutting - Requirements• DeriveRqt:Stereotype applied to an

association in which one requirement can be derived from a different requirement

– Derive: Stereotype added to requirement in a DeriveRqt relationship

• RefineRqt: Stereotype applied to an association in which one requirement adds more detail to another requirement

– Refine: Stereotype added to requirement in a RefineRqt relationship

• Satisfy: Stereotype applied to an association in which a model element fulfills a requirement

– Satisfied: Stereotype added to requirement that it participates in a satisfy relationship

• Verify: Stereotype applied to an association where a test case fulfills a requirement

– Verified: Stereotype added to requirement that it participates in a verify relationship

• TraceRqt: Stereotype applied to an association that adds a general purpose relationship between a requirement and any other model element

– Traced: Stereotype added to requirement that denote that the two elements are related in a certain way using the value of its derived properties.

• Test Case: A method for verifying a requirement is satisfied.

April 10, 2023 50

Crosscutting - Requirements

Requirements DiagramDefines system requirements

Requirements DiagramShows a test case that adds more

detail to a requirement

Standard wayto capture

requirements and link then within

the model!

Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98

April 10, 2023 51

Crosscutting – Profiles & Model Libraries

• Profile– Mechanisms to extend SysML

• Model Library– Defines all the packages a

model uses

• Diagrams– Package Diagrams

SysMLSysMLN/A

UML4SysMLUML4SysML•Stereotype•Class•Profile•Model Library•Extension•Generalization•Profile Application•Package Import•Element Import•Unidirectional Association•Note/In Node/On Edge/In Compartment/Compartment Stereotype

April 10, 2023 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 Management Tools

• SysML interface with with standard requirement management tools unclear

April 10, 2023 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 management

tools

April 10, 2023 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

April 10, 2023 55

More Information

April 10, 2023 56

Available SysML Modeling Tools

• ARTiSAN StudioARTiSAN Studio by by ARTiSAN Software

• SysML ToolkitSysML Toolkit by EmbeddedPlus • 3rd Party Plug-in to IMB Rational Suite

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

• Enterprise ArchitectEnterprise Architect by Sparx Systems

April 10, 2023 57

RecommendationsNow 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_re

s.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/

April 10, 2023 58

Of Related Interest

• RFP for UML Profile for DODAF/MODAF issued September 2005– http://www.omg.org/cgi-bin/doc?dtc/2005-09-12

April 10, 2023 59

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

April 10, 2023 60

Backup

April 10, 2023 61

Use Existing OMG Specs

Proposals may build upon the following 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 the foundation of the SysML

spec

MOF

SysMLSysML

UML & Profiles

?

April 10, 2023 62

Spec Evaluation Criteria

• To be used by submitters and 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 diagram

interchange• Process and method

independent• Compliant with the UML

metamodel• Verifiable

April 10, 2023 63

OMG Adoption Process1. 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)

April 10, 2023 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 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.15. OMG publishes the formal specification OMG publishes the formal specification 16. Revision Task Force manages issues filed against the specification

April 10, 2023 65

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

April 10, 2023 66

Requirements Resolution Matrix

• Each proposal must include a matrix explain how it satisfied 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 mandatory requirements

may be satisfied by the existing

UML spec.

April 10, 2023 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 concerns in revised submissions

• Build consensus on acceptable solutions

• Enable voting members to make an informed selection decision

April 10, 2023 68

More on MDA

PIMPIM

PSMPSM

CodeCode

transform

transform

Portable Example - Billing System

Model

Billing System Model for J2EE

J2EE Code for Billing System