Presentation is loading. Please wait.

Presentation is loading. Please wait.

7 February 2014 1 An Overview of the Systems Modeling (SysML) Specification Shana L. Lloyd Julie A. Street The Aerospace Corporation Systems Modeling Language.

Similar presentations

Presentation on theme: "7 February 2014 1 An Overview of the Systems Modeling (SysML) Specification Shana L. Lloyd Julie A. Street The Aerospace Corporation Systems Modeling Language."— Presentation transcript:

1 7 February 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 7 February Outline Background Request for Proposal (RFP) The Spec More Information

3 7 February Background

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

5 7 February 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.

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

8 7 February 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 7 February 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 Model Driven Architecture (MDA) 2.Platform: a subsystem that provides functionality through interfaces and usage patterns that any system can use without knowing the details of how that functionality is implemented 3.Platform Independent Model (PIM): A system model that contains no platform-specific information 4.Platform Specific Model (PSM): A system model that includes technology and platform-specific information 5.Mapping: Transforming the elements of one model to another model

10 7 February The Request for Proposal

11 7 February SysML Specification Timeline 2003 Initial spec (v0.3) presented to INCOSE International Workshop Jan Initial submission to OMG Feb Spec v0.9 submitted to OMG MayJan Sterotypes & Model Libraries Chapter submitted as an amendment to spec v0.9 Multi-vendor demonstration of v0.9 spec presented to INCOSE. JulyAugNov April Dec Draft specs submitted INCOSE & OMG evaluate submissions SysML 1.0 Spec Submitted to OMG Mar UML for SE RFP issued May July OMG announces the adoption of OMG SysML

12 7 February 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 SE DSIG Activities –Issued of Request for Information (RFI) –Developed Systems Engineering Conceptual Model –Collaborated with UML 2.0 submission teams –Developed a requirements analysis

13 7 February SE Conceptual Model Captures essential concepts of systems engineering in form of a UML model Used as input for SysML requirements

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

15 7 February Solicited submissions that specify a customization of UML for Systems Engineering (SysML) –Released March 28,2003 Specification Goals –Support modeling a broad range of systems Hardware, software, data, personnel, procedures, and facilities –Capture system information precisely and efficiently –Allow for the analysis and evaluation of the modeled system –Provide clear communication of systems information among stakeholders SysML Request for Proposal (RFP)

16 7 February 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 ISOs Reference Model of Open Distributed Processing [RM-ODP] Address security questions and concerns Specify the degree of internationalization support

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

19 7 February 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 7 February Submission Requirements Submit a requirements resolution matrix Grant OMG world-wide, royalty-free license of the spec Show commitment to support commercial success of products Include proof of concept statement explaining how specifications are technically viable –An implementation of this specification has been in beta-test for 4- months –A named product (with a specified customer base) is a realization of this specification.

21 7 February 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 7 February The SysML Spec

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

24 7 February Reuse & Extensions UML reused for SysML Actions Activities Classes General Behavior Information Flows Interactions Models Profiles State Machines Structures Use Cases Extensions to UML SysML::Model Elements refactors and extends Kernel SysML:: Blocks reuses Composite structures & Model Elements SysML::ConstraintBlocks extends Blocks SysML::Ports & Flows extends UML Ports SysML::Activities extends UML Activities SysML::Allocations extends UML dependencies SysML::Requirements extends Classes and dependencies

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

26 7 February Four Pillars of SysML

27 7 February SysML Summary ViewMajor ExtensionsBenefits StructuralModel ElementsStandard way to capture views and design decisions BlocksFlexibility to model non-software components with custom properties Ports and FlowsDifferentiate between what could and what actually does travel through a port Constraint BlocksAbility to integrate analysis in designs BehavioralNew Activity DiagramMore control over activities, ability to model continuous streams and path probability StereotypesNew stereotypes for easily behavior classification CrosscuttingAllocationsMore flexible mapping capabilities RequirementsAbility to model requirements, their relationships, and links back to the design diagrams

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

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

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

32 7 February 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 7 February Structural – Ports & Flows Ports –Interaction point between a block or part and its environment –Clearly-defined interfaces –Used on Block Diagrams Flow –Data passing through ports Two Diagrams –Block Definition Diagram –Internal Block Diagram SysML Service Port Flow Port Flow Specification Item Flow UML4SysML Interface

34 7 February 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 cars engine pipe Service Port:Interaction point provided by a block –Contains services to and from its environment –Equivalent to UML 2.0 ports

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

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

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

38 7 February 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 7 February Behavioral -Activities Activities –Typically used for business process modeling or logic in a single use case –Extends UML 2.0 to support disabling of actions that are already executing Diagrams –Activity Diagram Some modifications for UML 2.0 diagrams SysML No Buffer Overwrite Optional Probability Rate/Continuous/Discrete 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

40 7 February 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 7 February Behavioral -Activities Rate Probability Explicitly capture flow rates and path probabilities Versions of figure & in Submission Team spec v 0.98

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

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

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

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

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

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

48 7 February Crosscutting - Requirements 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 UML4SysML Namespace Relationship

49 7 February 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 7 February 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 7 February Crosscutting – Profiles & Model Libraries Profile –Mechanisms to extend SysML Model Library –Defines all the packages a model uses Diagrams –Package Diagrams SysML N/A 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

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

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

56 7 February Available SysML Modeling Tools ARTiSAN Studio byARTiSAN Studio by ARTiSAN Software SysML ToolkitSysML Toolkit by EmbeddedPlus 3 rd Party Plug-in to IMB Rational Suite TAUTAU G2 by Telelogic Telelogic recently acquired competitor I-Logix Enterprise ArchitectEnterprise Architect by Sparx Systems

57 7 February Recommendations Now that you know the basics of SysML you can: Read the tutorial –Given at INCOSE 2006 Conference low_res.pdf low_res.pdf –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 7 February Of Related Interest RFP for UML Profile for DODAF/MODAF issued September 2005 –

59 7 February References SysML Spec – OMG – – OMGs SE DSIG – OMGs UML for Systems Engineering RFP – UML Resource Page –

60 7 February Backup

61 7 February Use Existing OMG Specs Proposals may build upon the following specifications Unified Modeling Language (UML) v1.4 & 1.5 Meta Object Facility (MOF) v.1.4 –Framework for management and interchange of UML models –XMI Metadata Interchange v1.2 & 2.0 –UML Human-Usable Textual Notation (HUTN) UML 2.0 UML Profiles & Business Process & Rules The UML spec is the foundation of the SysML spec MOF SysML UML & Profiles ?

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

63 7 February OMG Adoption Process 1.RFPs are drafted Written by OMG members Presented to the appropriate Task Force (TF) 2.RFPs are issued by a Technology Committee (TC) Upon the recommendation of the TF & the Architecture Board (AB) 3.Submitting organization provides a Letter of Intent to the OMG Signifies a willingness to comply to the OMGs terms and conditions A member organization must be a member of the TC that issued the RFP 4.OMG members register to vote to select a specification 5.Initial submissions, revisions, and revised submissions are reviewed 6.TF evaluates final submissions 7.Registered OMG members vote to select a submission Result is a recommendation to adopt a specification to the TC 8.AB reviews the proposal for MDA compliance and technical merit 9.TC votes to recommend adoption to the OMG Board of Directors (BoD)

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

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

66 7 February 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 7 February 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 7 February More on MDA PIM PSM Code transform Portable Example - Billing System Model Billing System Model for J2EE J2EE Code for Billing System

Download ppt "7 February 2014 1 An Overview of the Systems Modeling (SysML) Specification Shana L. Lloyd Julie A. Street The Aerospace Corporation Systems Modeling Language."

Similar presentations

Ads by Google