Document Sample
SysML - INCOSE Powered By Docstoc
					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        7 July 2011   1
• Background

• Request for Proposal (RFP)

• The Spec

• More Information

                               7 July 2011   2

             7 July 2011   3
• The SE community is moving
  from a document-centric
  approach to a model-driven
  – 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
                                         7 July 2011   4
“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
                              7 July 2011   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
                                                          7 July 2011   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

  – Behaviors                                                                                 <<include>>

     • Captures the high level behavior of the system
                                                                              use case 1


     • E.g. Use Cases & Activity Diagrams
                                                                                                         comm on use ca se


                                                                              use case 2

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

                                                                                                            7 July 2011      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

                                                                      7 July 2011   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 system
   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
   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
                                                             7 July 2011   9
The Request for Proposal

                       7 July 2011   10
           SysML Specification Timeline
                                  Sterotypes &
            Initial spec (v0.3)
          presented to INCOSE    Model Libraries                                      announces
         International Workshop Chapter submitted                                    the adoption
                                as an amendment                                        of OMG
                                   to spec v0.9
                                                          Draft specs                   SysML
2003                          2005                                        2006
     Mar May Jan Feb            Jan    May    July    Aug       Nov Dec            April   July
                             Spec v0.9
                          submitted to OMG                         INCOSE &
                                                                 OMG evaluate
                 Initial submission                               submissions
                                        demonstration of v0.9
                       to OMG            spec presented to                       SysML 1.0 Spec
UML for SE RFP                               INCOSE.                            Submitted to OMG

                                                                                            7 July 2011   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
                                                          7 July 2011   12
SE Conceptual Model
                        concepts of
                       engineering in
                      form of a UML

                           Used as
                          input for

                               7 July 2011   13
        Request for Information (RFI)
                             Companies that Responded
•   RFI Issued February
                             •   Tofs AB
                             •   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
                             •   I-Logix
    – Identify potential     •   INCOSE OOSEM WG
                             •   MITRE
    – Identify interested    •   Georgia Tech
                             •   ARTISAN Software Tools
                             •   Holistic Systems Engineering
                             •   Project Technology

                                                                7 July 2011   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
      • Hardware, software, data, personnel,
        procedures, and facilities
   – Capture system information precisely and
   – Allow for the analysis and evaluation of
     the modeled system
   – Provide clear communication of systems
     information among stakeholders

                                                7 July 2011   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

                                                          7 July 2011   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

                                                    7 July 2011   17
        Spec Mandatory Requirements (2)
                                     •   Requirement
•   Behavior                             –   Requirement specification
    – Functional Transformation of       –   Requirement properties
      Inputs to Outputs                  –   Requirement relationships
       •   Input/Outputs                 –   Problem
       •   System Store                  –   Problem association
       •   Function                      –   Problem cause
    – Function                       •   Verification
      activation/deactivation            –   Verification Process
       • Control input                   –   Test case
       • Control operator                –   Verification result
       • Events and conditions           –   Requirement verification
    – Function-based behavior            –   Verification procedure
    – State-based behavior               –   Verification system
       •   Activation time           •   Other
    – Allocation of behavior to          –   General relationships
      systems                            –   Model views & diagram types
                                         –   System role             7 July 2011   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
•   Testing model
•   Management model
                                        7 July 2011   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
     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

                                                             7 July 2011   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                 • Dienstleistungen fur
•   EmbeddedPlus Engineering              innovative Informatik GmbH
•   Eurostep Group AB                 •   PivotPoint Technology Corporation
•   Gentleware AG                     •   Raytheon
•   Georgia Institute of Technology   •   TelelogicAB
•   I-Logix                           •   THALES
•   International Business            •   Vitech
•   Lockheed Martin Corporation

                                                                         7 July 2011   21
The SysML Spec

                 7 July 2011   22
      SysML Language Architecture
             UML not required by SysML

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

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

                                                                  7 July 2011   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
•   Use Cases
                        • SysML::Requirements extends
                          Classes and dependencies
                                                      7 July 2011   24
SysML Diagram Taxonomy

                 SysML Merge Team Submission v0.99 p.9

                                             7 July 2011   25
Four Pillars of SysML

                        7 July 2011   26
                        SysML Summary
   View        Major Extensions                         Benefits
Structural     Model Elements         Standard way to capture views and design
               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
Crosscutting   Allocations            More flexible mapping capabilities
               Requirements           Ability to model requirements, their
                                      relationships, and links back to the design
                                                                                 7 July 2011   27
    Structural-Model Elements
• Model Elements                UML4SysML
  – Common elements that can      •Comment
    be used in any diagram        •Conform
  – Extended to be consistent     •Constraint
    with IEEE 1471 Standard       •Dependency
                                  •Element Import
• Diagrams                        •Model
  – Any diagram!                  •Package

                                                    7 July 2011   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


     A standard
   way to capture
  design decisions                                                                                 View
    and explicitly                                                                                 Point
    specify views
                                                                                                   7 July 2011   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
   – UML Equivalent: Classes                 •DataType
• Two Diagrams                               •isAbstract Classifier
   – 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

                                                                      7 July 2011   30
                     Structural- Blocks
• Value Type : values that express
  information about the system
    – UML Equivalent: Data Types                             Block
• 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 &
• 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

                                                              7 July 2011   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

                                                                                                  7 July 2011   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
• Flow                              •Service Port
  – Data passing through ports      •Flow Port
                                    •Flow Specification
• Two Diagrams                      •Item Flow
  – Block Definition Diagram
  – Internal Block Diagram

                                                          7 July 2011   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

                                                                  7 July 2011   34
         Structural – Ports & Flows
Block Definition Diagram                                             Internal Block Diagram
  Defines port composition                                              Defines how ports are used

                                                         does flow!

                                                                                                     7 July 2011   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
   – Package Diagram
                                                •Constraint Block
• Use Constraint Blocks                         •Constraint Property
   – Internal Block Diagrams
   – Parametric Diagrams
       • Specialized internal block diagram
       • Must be bound to Constraint

                                                                  7 July 2011   36
    Structural – Constraint Blocks
Block Definition Diagram                                               Parametric Diagram
 Defines the constraint blocks                                           Show how the constraint
                                                                            blocks are used

                                                    Nested property
                                                      constraints                        Integrate
                                                                                        analysis in
                                                    Property                               design
                                                                                                   7 July 2011   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

                                                                                  7 July 2011   38
                  Behavioral -Activities
                                      •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
   – Activity Diagram                                       •Parameter Set
       • Some modifications for UML
         2.0 diagrams                 SysML
                                          •No Buffer
                                                                          7 July 2011   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

                                                                     7 July 2011   40
Behavioral -Activities

                                                                     Explicitly capture
                                                                      flow rates and
                                                                     path probabilities



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

   – Sequence Diagram
   – Timing Diagram                           N/A

                                                                    7 July 2011   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

• Diagrams
  – State Machine Diagrams

                                                        7 July 2011   43
        Behavioral – Use Cases
• Use Cases                   UML4SysML
  – Describes the system‟s      •Use Case
    functionally and usage      •Actor
  – No changes from UML 2.0     •Subject
• Diagrams                      •Extends
  – Use Case Diagrams


                                                  7 July 2011   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

                                                                                   7 July 2011   45
         Crosscutting - Allocations
• Allocations
  – Denotes organized cross-      UML4SysML
  – 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

                                                            7 July 2011   46
         Crosscutting - Allocations
                Partitions to Allocate Activities

behavior to

              figure 15-10 in Submission Team spec v 0.98
                                                            Allocated Structure   7 July 2011   47
     Crosscutting - Requirements
• Requirement
  – Functionality that a system     •Namespace Relationship
    must provide
  – SysML can now represent
    requirements in graphical     SysML
    format                          •Requirement
                                    •Requirement Containment
• Diagrams                          •Test Case
  – Requirement Diagrams            •Derive Requirement
  – Tabular Representation          •Verify

                                                          7 July 2011   48
          Crosscutting - Requirements
•   DeriveRqt:Stereotype applied to an         •   Verify: Stereotype applied to an
    association in which one                       association where a test case
    requirement can be derived from a              fulfills a requirement
    different requirement                           – Verified: Stereotype added to
     – Derive: Stereotype added to                    requirement that it participates in a
       requirement in a DeriveRqt                     verify relationship
                                               •   TraceRqt: Stereotype applied to
•   RefineRqt: Stereotype applied to an            an association that adds a general
    association in which one                       purpose relationship between a
    requirement adds more detail to                requirement and any other model
    another 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 a
     – Satisfied: Stereotype added to              requirement is satisfied.
       requirement that it participates in a
       satisfy relationship
                                                                                     7 July 2011   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!

                                                                                             7 July 2011   50
                   Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98
Crosscutting – Profiles & Model Libraries

 • Profile                         UML4SysML
    – Mechanisms to extend SysML     •Class
                                     •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


                                                             7 July 2011   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
      • SysML interface with with standard requirement management tools unclear
                                                                                      7 July 2011   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

                                                                 7 July 2011   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

                                         7 July 2011   54
More Information

                   7 July 2011   55
   Available SysML Modeling Tools

• ARTiSAN Studio by ARTiSAN

• 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

                                                     7 July 2011   56
Now that you know the basics of SysML you can:
• Read the tutorial
    – Given at INCOSE 2006 Conference
    – Attend INCOSE-WMA SysML Tutorial on Aug 12
•   Participate in the OMG SysML Discussion Group
    – Official OMG sponsored group
•   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 #

                                                                         7 July 2011   57
            Of Related Interest

• RFP for UML Profile for DODAF/MODAF
  issued September 2005

                                                    7 July 2011   58
• SysML Spec
• OMG’s UML for Systems Engineering RFP
• UML Resource Page

                                                  7 July 2011   59

         7 July 2011   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 &
    –   UML Human-Usable Textual
        Notation (HUTN)
•   UML 2.0
                                              UML & Profiles
•   UML Profiles & Business Process
    & Rules

                                                               7 July 2011   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
•   Process and method
•   Compliant with the UML
•   Verifiable

                                                             7 July 2011   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)

                                                                                7 July 2011   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
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

                                                                                    7 July 2011   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
• Must show a commitment to support the specification & supporting
                                                                            7 July 2011   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
•   Issues & comments

                                                              7 July 2011   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
• Enable voting members to make
  an informed selection decision

                                      7 July 2011   67
           More on MDA
Portable                        Example -
                       PIM    Billing System

                              Billing System
                       PSM    Model for J2EE


                              J2EE Code for
                       Code   Billing System

                                               7 July 2011   68