An Overview of the Systems Modeling (SysML) Specification

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 registeredtrademarks of Object Management Group, Inc. in theUnited 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

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

6. What is UML? • Unified Modeling Language (UML) • Object modeling and specification language used in software engineering • Object Management Group (OMG) manages and maintains UML • Goals of UML • Provide a method of consistent and effective communication among software engineers • Provide a way to understand software designs without code or psuedocode • Specify, visualize, and document software designs • Raise the level of abstraction to focus on system aspects rather than implementation details • Provide multiple views of the system

7. 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. 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. SysML Specification Timeline OMG announces the adoption of OMG SysML Sterotypes & Model Libraries Chapter submitted as an amendment to spec v0.9 Initial spec (v0.3) presented to INCOSE International Workshop 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

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

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

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

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

21. SysML Team • Mentor Graphics • Motorola, Inc. • National Institute of Standards and Technology • Northrop Grumman Corporation • oose.de Dienstleistungen fur innovative Informatik GmbH • PivotPoint Technology Corporation • Raytheon • TelelogicAB • THALES • Vitech • 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

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

27. SysML Summary

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 ViewPoint Rationale Modified version of figure 7-3 in Submission Team spec v 0.98

30. Structural - Blocks • UML4SysML • Package • Actor • DataType • isAbstract Classifier • Stereotype • Dependency • Association • Generalization • Generalization Set • Nested Classifier • Connector • 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 • SysML • Block • Block Property • Value Type • Compartment

31. 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 Internal Block Diagram Defines internal structure and how blocks are used Block Definition Diagram Defines system composition and relationships 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 • 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 • UML4SysML • Interface • SysML • Service Port • Flow Port • Flow Specification • Item Flow

34. Structural – Ports & Flows • 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 • 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

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

36. UML4SysML • N/A • SysML • Constraint Block • Constraint Property 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

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 andpath probabilities Probability Rate Versions of figure 11-11 & 11-12 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 • ExcludesCommunication & 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 • UML4SysML • Use Case • 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 15-10 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 • 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. • 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

50. Crosscutting - Requirements Requirements Diagram Defines system requirements Requirements Diagram Shows a test case that adds more detail to a requirement Standard wayto capture requirements and link then withinthe model! Versions of figure 11-11 & 11-12 in Submission Team spec v 0.98