Docstoc

SysML - INCOSE

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
               Outline
• Background

• Request for Proposal (RFP)

• The Spec

• More Information


                               7 July 2011   2
Background




             7 July 2011   3
                  Background
• The SE community is moving
  from a document-centric
  approach to a model-driven
  approach
  – Need integration of SE models with
    other discipline-specific models
    (software, hardware, simulation &
    analysis, etc.)
• Unified Modeling Language
  (UML) was designed for
  Software Engineers
  – Lacks all of the mechanisms
    needed for Systems Engineers
                                         7 July 2011   4
             SysML
“SysML is a general-purpose
 graphical modeling
 language for specifying,
 analyzing, designing and
 verifying complex systems
 that may include hardware,
 software, information,
 personnel, procedures, and
 facilities.”
                              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
                                                                     System




  – Behaviors                                                                                 <<include>>




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


                                                            Actor1




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

                                                                                           <<include>>



                                                                              use case 2
                                                            Actor2




  – Interactions
     • Captures the details behind the behavior of the
       system
     • 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
       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
                                                             7 July 2011   9
The Request for Proposal




                       7 July 2011   10
           SysML Specification Timeline
                                  Sterotypes &
                                                                                         OMG
            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
                                                          submitted
2003                          2005                                        2006
     Mar May Jan Feb            Jan    May    July    Aug       Nov Dec            April   July
                 2004
                             Spec v0.9
                          submitted to OMG                         INCOSE &
                                                                 OMG evaluate
                                           Multi-vendor
                 Initial submission                               submissions
                                        demonstration of v0.9
                       to OMG            spec presented to                       SysML 1.0 Spec
UML for SE RFP                               INCOSE.                            Submitted to OMG
    issued




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




                           Used as
                          input for
                            SysML
                        requirements


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

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

                                                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
    models
•   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
     specification
     has been in beta-test for 4-   • Show commitment to
     months”                          support commercial
   – “A named product (with a         success of products
     specified customer base)
     is a realization of this
     specification.”




                                                             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                 •   oose.de 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
    Machines
•   Lockheed Martin Corporation


                                                                         7 July 2011   21
The SysML Spec




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


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


                                         SysML
                                         extensions
                     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
                          dependencies
•   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
                                      decisions
               Blocks                 Flexibility to model non-software
                                      components with custom properties
               Ports and Flows        Differentiate between what could and what
                                      actually does travel through a port
               Constraint Blocks      Ability to integrate analysis in designs
Behavioral     New Activity Diagram   More control over activities, ability to model
                                      continuous streams and path probability
               Stereotypes            New stereotypes for easily behavior
                                      classification
Crosscutting   Allocations            More flexible mapping capabilities
               Requirements           Ability to model requirements, their
                                      relationships, and links back to the design
                                      diagrams
                                                                                 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
                                  •Realization
                                  •Refine

                                SysML
                                  •Problem
                                  •Rationale
                                  •View
                                  •ViewPoint
                                                    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

          View



     A standard
   way to capture
  design decisions                                                                                 View
    and explicitly                                                                                 Point
    specify views
                                                                                                 Rationale
                                                                                                   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
                                             •Actor
   – UML Equivalent: Classes                 •DataType
• Two Diagrams                               •isAbstract Classifier
                                             •Stereotype
   – Block Definition Diagram                •Dependency
      • Defines relationships between        •Association
        blocks                               •Generalization
      • UML equivalent: Class                •Generalization Set
        Diagrams                             •Nested Classifier
   – Internal Block Diagram                  •Connector
      • Defines internal structure of a   SysML
        block                                •Block
      • UML equivalent: Structured           •Block Property
        Class Diagrams                       •Value Type
                                             •Compartment

                                                                      7 July 2011   30
                     Structural- Blocks
• Value Type : values that express
  information about the system
    – UML Equivalent: Data Types                             Block
                                              Compartments
• Compartments: partition of a block with
  features for the compartment type
    – User-defined or standard SysML
    – SysML Compartments: Namespace,
      Constraint, Structure
    – UML Equivalent : Class Operations &
      Attribute
• Property Specification Type: keyword on
  any internal property of a block to indicate
                                               Property
  its standard SysML taxonomy
                                             Specification
    – «part», «reference», and «value»
    – Internal Block Diagrams only

                                                              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
                                                                                   properties

                                                                                                  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
                                  SysML
• 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




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



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




                                                              Probability

Rate




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

   – Sequence Diagram
                                            SysML
   – 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
                                    •Transition

• Diagrams
  – State Machine Diagrams
                                  SysML
                                    N/A




                                                        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
                                •Associations
                                •Includes
• Diagrams                      •Extends
                                •Generalization
  – Use Case Diagrams


                              SysML
                                N/A




                                                  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
                                    N/A
    associations
  – Custom Types
  – SysML defined Types
       • Behavior
       • Flow                     SysML
       • Structure                  •Allocated Stereotype
• Diagrams                          •Allocated Properties
                                    •Allocation Activity
  –   Block Definition Diagrams     •Allocation
  –   Internal Block Diagrams
  –   Activity Diagrams
  –   Tabular Representation

                                                            7 July 2011   46
         Crosscutting - Allocations
                Partitions to Allocate Activities
                           (Behavior)




 Explicitly
 allocate
behavior to
 structure

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



                                                          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
       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
                                     •Stereotype
    – Mechanisms to extend SysML     •Class
                                     •Profile
                                     •Model Library
 • Model Library                     •Extension
    – Defines all the packages a     •Generalization
      model uses                     •Profile Application
                                     •Package Import
                                     •Element Import
 • Diagrams                          •Unidirectional Association
                                     •Note/In Node/On Edge/
    – Package Diagrams               In Compartment/
                                     Compartment Stereotype

                                   SysML
                                     N/A

                                                             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
     Tools
      • 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
     tools

                                                                 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
  Software

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


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


• Enterprise Architect by Sparx
  Systems

                                                     7 July 2011   56
                   Recommendations
Now that you know the basics of SysML you can:
• Read the tutorial
    – Given at INCOSE 2006 Conference
       •   http://www.omgsysml.org/SysML-Tutorial-Baseline-to-INCOSE-060524-
           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 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/


                                                                         7 July 2011   57
            Of Related Interest

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




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



                                                  7 July 2011   59
Backup



         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 &
        2.0
                                                    MOF
    –   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
    interchange
•   Process and method
    independent
•   Compliant with the UML
    metamodel
•   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
    Specification”
14. TC recommends adoption to the Board of Directors
    •   Board of Directors votes and accepts the specification
15. OMG publishes the formal specification
16. Revision Task Force manages issues filed against the specification


                                                                                    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
  specification
• Must show a commitment to support the specification & supporting
  technology
                                                                            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
    satisfaction
•   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
  solutions
• Enable voting members to make
  an informed selection decision



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

                              Billing System
                       PSM    Model for J2EE

           transform

                              J2EE Code for
                       Code   Billing System


                                               7 July 2011   68

				
DOCUMENT INFO