presentation from august 8, 2006 dinner meeting

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


2/68

10 June 2010 2

Outline

Background

Request for Proposal (RFP)

The Spec

More Information


3/68

10 June 2010 3

Background


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


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.


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


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/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)


Meta-Object Facility (MOF)

And more


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


10/68

10 June 2010 10

The Request for

Proposal


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


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


13/68

10 June 2010 13

SE Conceptual Model

Capturesessential

concepts ofsystems

engineering inform of a UML

model

Used asinput forSysML

requirements


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


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)


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


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


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


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


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.


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


22/68

10 June 2010 22

The SysML Spec


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)


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


25/68

10 June 2010 25

SysML Diagram Taxonomy

SysML Merge Team Submission v0.99 p.9


26/68

10 June 2010 26

Four Pillars of SysML


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


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


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


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


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


32/68

10 June 2010 32

Structural-Block Examples

Block Definition Diagram

Defines system composition and

relationships


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


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


34/68

10 June 2010 34


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


35/68

10 June 2010 35



Defines port composition


Defines how ports are used


What

does flow!


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


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


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


Property

constraints

Nested property

constraints


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


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


40/68

10 June 2010 40


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


41/68

10 June 2010 41


Rate

Probability

Explicitly capture

flow rates and

path probabilities

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


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


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


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


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


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


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


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


49/68

10 June 2010 49


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.


50/68

10 June 2010 50


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


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


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


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


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


55/68

10 June 2010 55

More Information


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


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/


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


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


60/68

10 June 2010 60

Backup


61/68

10 June 2010 61

Use Existing OMG Specs

Proposals may build upon thefollowing specifications


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

?


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


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)


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


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


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.


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


68/68

More on MDA

PIM

PSM

Code

transform

transform

Portable Example -

Billing System

Model

Billing System

Model forJ2EE

J2EE Code for

Billing System

presentation from august 8, 2006 dinner meeting

Documents