Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Overview of the Systems Modeling (SysML) Specification

Similar presentations

Presentation on theme: "An Overview of the Systems Modeling (SysML) Specification"— Presentation transcript:

1 An Overview of the Systems Modeling (SysML) Specification
Shana L. Lloyd Julie A. Street The Aerospace Corporation Systems Modeling Language (SysML) and Unified Model Language (UML) are a registered trademarks of Object Management Group, Inc. in the United States and/or other countries

2 Outline Background Request for Proposal (RFP) The Spec
More Information

3 Background

4 Background The SE community is moving from a document-centric approach to a model-driven approach Need integration of SE models with other discipline-specific models (software, hardware, simulation & analysis, etc.) Unified Modeling Language (UML) was designed for Software Engineers Lacks all of the mechanisms needed for Systems Engineers Reword

5 SysML “SysML is a general-purpose graphical modeling language for specifying, analyzing, designing and verifying complex systems that may include hardware, software, information, personnel, procedures, and facilities.” Quote taken from Allow model driven systems engineering

6 What is UML? Unified Modeling Language (UML) Goals of 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 Modeling in UML What can you model in UML? Structures Behaviors
Captures the physical & compositional structure of the system E.g. Class Diagrams & Deployment Diagrams Behaviors Captures the high level behavior of the system E.g. Use Cases & Activity Diagrams Interactions Captures the details behind the behavior of the system E.g. Sequence Diagrams, Collaboration Diagrams and Timing Diagrams

8 Object Management Group (OMG)
OMG is leading the SysML Effort Who is OMG? International software consortium established in 1989 Members include vendors, developers, and end users Mission “To help computer users solve enterprise integration problems by supplying open, vendor-neutral portability, interoperability and reusability specifications based on Model Driven Architecture (MDA).” Established Standards Common Object Request Broker Architecture (CORBA) Unified Modeling Language (UML) Meta-Object Facility (MOF) And more

9 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 Model : presentation of a function, structure, and/or behavior of a system Platform: a subsystem that provides functionality through interfaces and usage patterns that any system can use without knowing the details of how that functionality is implemented Platform Independent Model (PIM): A system model that contains no platform-specific information Platform Specific Model (PSM): A system model that includes technology and platform-specific information Mapping: Transforming the elements of one model to another model

10 The Request for Proposal

11 OMG announces the adoption of OMG SysML
SysML Specification Timeline OMG announces the adoption of OMG SysML Initial spec (v0.3) presented to INCOSE International Workshop Sterotypes & Model Libraries Chapter submitted as an amendment to spec v0.9 Draft specs 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 submissions Multi-vendor demonstration of v0.9 spec presented to INCOSE. Initial submission to OMG SysML 1.0 Spec Submitted to OMG UML for SE RFP issued

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

13 Used as input for SysML requirements
SE Conceptual Model Captures essential concepts of systems engineering in form of a UML model Joint effort between INCOSE, ISO AP-233, and SE DSIG Used model to as an input to the SysML requirements analysis process There is a supporting Semantic Dictionary AP-233 is focused on developing a data interchange standard for systems engineering, which is intended to provide a neutral data format to exchange systems engineering information among tools. AP-233 is a working from of ISO TC-184 (Technical Committee on Industrial Automation Systems and Integration Used as input for SysML requirements

14 Request for Information (RFI)
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 RFI Issued February 2002 Reponses Due August 2002 Goals of the RFI Help formulate SysML requirements Identify potential solutions Identify interested stakeholders

15 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

16 Proposal Requirements
Express models in OMG modeling languages (i.e. UML) Be precise and functionally complete Identify mappings between platform independent model (PIM) & platform specific models (PSMs) Specify what features are required in implementations and which are optional Be compatible and useable with existing OMG specs Justify changes or extensions to existing OMG specs Preserve maximum implementation flexibility Allow for independent implementations that are substitutable and interoperable Be compatible with ISO’s Reference Model of Open Distributed Processing [RM-ODP] Address security questions and concerns Specify the degree of internationalization support PIM – platform independent model PSM – platform specific model ISO – International Organization for Standardization The rapid growth of distributed processing has led to a need for a co-ordinating framework for the standardization of Open Distributed Processing (ODP). As a result, a Reference Model for Open Distributed Processing (RM-ODP) is undergoing the process of standardization in a joint effort of ISO and ITU-T (formerly CCITT). ODP describes systems that support heterogeneous distributed processing both within and between organizations through the use of a common interaction model.

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

19 Spec Optional Requirements
Topology Documentation Trade-off studies and analysis Spatial representation Spatial reference Geometric relationships Dynamic structure Executable semantics Other behavior modeling paradigms Integration with domain-specific models Testing model Management model

20 Submission Requirements
Include ‘proof of concept’ statement explaining how specifications are technically viable “An implementation of this specification has been in beta-test for 4-months” “A named product (with a specified customer base) is a realization of this specification.” Submit a requirements resolution matrix Grant OMG world-wide, royalty-free license of the spec Show commitment to support commercial success of products Look at backup slide “Business Committee Requirements” to see the details of how they evaluate also consider proposals.

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 Dienstleistungen fur innovative Informatik GmbH PivotPoint Technology Corporation Raytheon TelelogicAB THALES Vitech

22 The SysML Spec

23 SysML Language Architecture
UML not required by SysML SysML: Reuses a subset of UML 2.0 Uses UML 2.0 profile mechanisms to specify extensions for SysML UML reused by SysML SysML extensions to UML (Have no counterpart in UML or place UML constructs)

24 Reuse & Extensions Extensions to UML UML reused for SysML
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 UML reused for SysML Actions Activities Classes General Behavior Information Flows Interactions Models Profiles State Machines Structures Use Cases

25 SysML Diagram Taxonomy
SysML Merge Team Submission v0.99 p.9

26 Four Pillars of SysML Taken from

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

28 Structural-Model Elements
UML4SysML Comment Conform Constraint Dependency Element Import Model Package Realization Refine Model Elements Common elements that can be used in any diagram Extended to be consistent with IEEE 1471 Standard Diagrams Any diagram! SysML Problem Rationale View ViewPoint

29 Structural – Model Elements
View: View of a whole system from single perspective Model Notation ViewPoint: View for addressing a set of stakeholder concerns Class Notation Rationale: Capture analysis, decisions, requirements Stereotype <<rationale>> inside a comment View A standard way to capture design decisions and explicitly specify views Only use comments in UML ViewPoint Rationale Modified version of figure 7-3 in Submission Team spec v 0.98

30 Structural - Blocks Block: Basic modular unit for structure of system
UML Equivalent: Classes Two Diagrams Block Definition Diagram Defines relationships between blocks UML equivalent: Class Diagrams Internal Block Diagram Defines internal structure of a block UML equivalent: Structured Class Diagrams UML4SysML Package Actor DataType isAbstract Classifier Stereotype Dependency Association Generalization Generalization Set Nested Classifier Connector SysML Block Block Property Value Type Compartment

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

32 Structural-Block Examples
Block Definition Diagram Defines system composition and relationships Internal Block Diagram Defines internal structure and how blocks are used Easily capture non-software parts with the flexibility to add custom properties Modified version of figure 8-8 & 8-9 in Submission Team spec v 0.98

33 Structural – Ports & Flows
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 UML4SysML Interface SysML Service Port Flow Port Flow Specification Item Flow

34 Structural – Ports & Flows
Flow Port : What can flow in or out of a block Used for asynchronous, broadcast, or send and forget interactions. Extension of UML 2.0 ports E.g. Liquid can flow through a pipe Flow Property: A single flow element Flow Specification: A set of flow properties Item Flow: What does flow between blocks in some context Used for asynchronous, broadcast, or send and forget interactions. Extension of UML 2.0 ports E.g. Gasoline does flow through a car’s engine pipe Service Port:Interaction point provided by a block Contains services to and from its environment Equivalent to UML 2.0 ports

35 Structural – Ports & Flows
Block Definition Diagram Defines port composition Internal Block Diagram Defines how ports are used What does flow! Modified version of figure 9-3 & 9-6 in Submission Team spec v 0.98

36 Structural – Constraint Blocks
Capture reusable engineering analysis with blocks E.g. Mathematical expressions that relate physical properties Constraint Property Block Property typed as Constraint Block Define Constraint Blocks Block Definition Diagram Package Diagram Use Constraint Blocks Internal Block Diagrams Parametric Diagrams Specialized internal block diagram Must be bound to Constraint Parameter SysML Constraint Block Constraint Property UML4SysML N/A

37 Structural – Constraint Blocks
Block Definition Diagram Defines the constraint blocks Parametric Diagram Show how the constraint blocks are used Integrate analysis in design Nested property constraints Property constraints Modified version of figure 10-2 & 10-3 in Submission Team spec v 0.98

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

40 Behavioral -Activities
Overwrite: Stereotype added to a object node to signify that if a new token arrives, it will replace any existing tokens Optional: Stereotype added to a parameter to signify it is not required for activity to begin execution Probability: Stereotype added to signify probability of usage Edges from decision or object nodes Output parameter sets Rate: Stereotype added to activity edge to specify the number of objects and values that pass an edge at a given time interval Special cases = Continuous and Discrete

41 Behavioral -Activities
Explicitly capture flow rates and path probabilities Probability Rate Versions of figure & in Submission Team spec v 0.98

42 Behavioral - Interactions
UML4SysML Interaction Lifeline Execution Specification Interaction Use Combined Fragment Continuation Creation/Destruction Event Interaction Duration/ Time Constraint Messages General Ordering State Invariant Interactions Describe interactions between entities Extends UML Timing Diagram Additionally represent properties and actions on the y-axis Additionally can mode continuous varying values Excludes Communication & Interaction Overview Diagrams Diagrams Sequence Diagram Timing Diagram SysML N/A

43 Behavioral – State Machines
UML4SysML State Machine Pseudo States State Region Submachine State Transition State Machines Describes entities behavior with states and transitions Also used for defining protocols No changes from UML 2.0 Diagrams State Machine Diagrams SysML N/A

44 Behavioral – Use Cases Use Cases Diagrams UML4SysML
Actor Subject Associations Includes Extends Generalization Use Cases Describes the system’s functionally and usage No changes from UML 2.0 Diagrams Use Case Diagrams SysML N/A

45 Behavioral Overall Assessment
Advantages Easy to Understand with UML 2.0 Knowledge Minimal changes and additions in SysML Timing Diagram Enhancements Increased capability to model time & continuous values Increased Data Flow Control Addition of rates and probabilities increases the ability to model different types of input rates and paths through the system. Limitations Behavior Across Multiple Scenarios in One Diagram Communication diagrams are excluded Limited Sequence Diagram fragment’s

46 Crosscutting - Allocations
UML4SysML N/A Allocations Denotes organized cross-associations Custom Types SysML defined Types Behavior Flow Structure Diagrams Block Definition Diagrams Internal Block Diagrams Activity Diagrams Tabular Representation SysML Allocated Stereotype Allocated Properties Allocation Activity Allocation

47 Crosscutting - Allocations
Partitions to Allocate Activities (Behavior) Explicitly allocate behavior to structure Allocated Structure figure in Submission Team spec v 0.98

48 Crosscutting - Requirements
UML4SysML Namespace Relationship Requirement Functionality that a system must provide SysML can now represent requirements in graphical format Diagrams Requirement Diagrams Tabular Representation SysML Requirement Requirement Containment Copy Test Case Derive Requirement Satisfy Verify Refine Trace

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

50 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! Versions of figure & in Submission Team spec v 0.98

51 Crosscutting – Profiles & Model Libraries
UML4SysML Stereotype Class Profile Model Library Extension Generalization Profile Application Package Import Element Import Unidirectional Association Note/In Node/On Edge/ In Compartment/ Compartment Stereotype Profile Mechanisms to extend SysML Model Library Defines all the packages a model uses Diagrams Package Diagrams SysML N/A

52 Crosscutting Overall Assessment
Advantages Requirement Modeling Potential to increase requirements traceability Allocations Useful for clearly identifying cross cutting structures or responsibilities Good Extension Mechanisms Same as UML 2.0 Good for reusable domain specific elements Limitations Diagram Clutter Requirement stereotypes are captured in comments, which have the potential to clutter diagrams. Trace Requirement Relationship vague Vague trace requirement relationship definition Unknown Interoperability with Requirements Management Tools SysML interface with with standard requirement management tools unclear

53 Summary Assessment Advantages Limitations
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

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

56 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

57 Recommendations 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 the SE DSIG chair with their contact info & INCOSE member #

58 Of Related Interest RFP for UML Profile for DODAF/MODAF issued September 2005 DODAF – Department of Defense Architecture Framework

59 References SysML Spec OMG OMG’s SE DSIG
OMG OMG’s SE DSIG OMG’s UML for Systems Engineering RFP UML Resource Page SE DSIG – Systems Engineering Domain Special Interest Group

60 Backup

61 The UML spec is the foundation of the SysML spec
Use Existing OMG Specs The UML spec is the foundation of the SysML spec Proposals may build upon the following specifications Unified Modeling Language (UML) v1.4 & 1.5 Meta Object Facility (MOF) v.1.4 Framework for management and interchange of UML models XMI Metadata Interchange v1.2 & 2.0 UML Human-Usable Textual Notation (HUTN) UML 2.0 UML Profiles & Business Process & Rules MOF SysML UML & Profiles ? Note. The drawing is not an exact representation of the building blocks of SysML. It was intended to be notational. “Even though UML was initially designed to support the specification and design of software, the language is sufficiently general-purpose and extensible so that it can be customized to meet many of the needs of systems engineering…A strength of UML is its built-in mechanisms for specializing the generic forms of its modeling elements to more application-specific variants. Collectively, these provide a capability for UML “Profiles” that package specific terminology and substructures for a particular application domain.” RFP. Pg 22

62 Spec Evaluation Criteria
Ease of use Unambiguous Precise Complete Scalable Adaptable to different domains Evolvable Capable of model interchange Capable of diagram interchange Process and method independent Compliant with the UML metamodel Verifiable To be used by submitters and provide guidance to the evaluators Apply to solutions as a whole. Not to each individual requirement Bullets 2 & 3 are when possible

63 OMG Adoption Process RFPs are drafted
Written by OMG members Presented to the appropriate Task Force (TF) RFPs are issued by a Technology Committee (TC) Upon the recommendation of the TF & the Architecture Board (AB) 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 OMG members register to vote to select a specification Initial submissions, revisions, and revised submissions are reviewed TF evaluates final submissions Registered OMG members vote to select a submission Result is a recommendation to adopt a specification to the TC AB reviews the proposal for MDA compliance and technical merit TC votes to recommend adoption to the OMG Board of Directors (BoD) TF – Task Force AB – Architecture Board TC – Technology Committee OMG – Object Management Group RFPs – Request for Proposals Submitting members of the spec must submit a response to the BoD Business Committee Questionnaire detailing how they will use the standard in products.

64 OMG Adoption Process (2)
OMG Board of Directors vote Resulting draft standard called “Adopted Specification” 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.” 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 FTF recommends adoption of the draft standard, called the “Available Specification” TC recommends adoption to the Board of Directors Board of Directors votes and accepts the specification OMG publishes the formal specification Revision Task Force manages issues filed against the specification BoD – Board of Directors FTF – Finalization Task Force

65 OMG’s Business Committee Requirements
There must be neither technical, legal nor commercial obstacles to [technologies] implementation.” Looks for commitment by submitter to the commercial success of products Looks for evidence that each major feature has been implemented “Preferably more than once and by separate organizations” Should demonstrate cross-platform availability & interoperability Must show that products based on the spec are commercially available or will be within 12 months If the submitter is not a commercial SW provider, BC requires evidence of 2 or more independent implementations of the specification Will not adopt a spec if an intellectual property right infringement will occur Must grant OMG worldwide, royalty-free license of the submitted specification Must show a commitment to support the specification & supporting technology Will do IPR if OMG believes the IPR owner will grant a license to organizations on non-discriminator & commercially reasonable terms to make use of the spec

66 Requirements Resolution Matrix
Each proposal must include a matrix explain how it satisfied the requirements Full, Partial, or No Solution Accomplished using: UML construct without modification UML construct with modification Extension mechanism to define a new UML modeling element Other approach Reference to the satisfying syntax Reference to samples problem that demonstrates satisfaction Issues & comments Many mandatory requirements may be satisfied by the existing UML spec.

67 Goals of RFP Evaluation
Fair and open process Facilitate critical review of the submissions by OMG members Provide feedback to submitters to allow them to address concerns in revised submissions Build consensus on acceptable solutions Enable voting members to make an informed selection decision

68 More on MDA Portable Example - Billing System Model PIM
transform PSM Billing System Model for J2EE transform Code J2EE Code for Billing System

Download ppt "An Overview of the Systems Modeling (SysML) Specification"

Similar presentations

Ads by Google