INCOSE Evaluation: Systems Modeling Language (SysML)

1. INCOSE Evaluation: Systems Modeling Language (SysML) SysML Submission Team (SST) 13, 15, 20 December 2005 SST Chair: Sanford Friedenthal sanford.friedenthal@lmco.com

2. Topics • Introduction • MDSD Actions • Specification Updates • Specification Highlights • Language Architecture • Compliance Approach • Structural Constructs • Behavioral Constructs • Cross-cutting Constructs • Appendixes • Sample Problems • HSUV Example from Appendix B • Distiller Example (response to D. Oliver example) • Summary

3. Introductory Statement • Two competing specifications* submitted to the OMG on November 14, 2005 from: • SysML Submission Team (SST) chaired by S. Friedenthal • SysML Partners chaired by C. Kobryn • This highlights updates and selected features of the SST SysML Specification v0.98 (ad/2005-11-01) • A vote for adoption should occur at the next OMG meeting the week of February 13, 2006 * Available at http://syseng.omg.org/SysML.htm

4. What is SysML? • A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 • a UML Profile that represents a subset of UML 2 with extensions • Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities • Supports model and data interchange via XMI and the evolving AP233 standard (in-process) SysML is Critical Enabler for Model Driven SE

5. SysML Background • UML for SE RFP issued – 28 March 2003 • SysML Partners Kickoff meeting – 6 May 2003 • Chaired by S. Friedenthal and C. Kobryn • 3rd revised submission (v0.9) to OMG – 10 Jan 2005 • Addendum stereotypes chapter – 30 May 2005 • SysML Submission Team announced split from SysML Partners on August 30, 2005 to finalize thespecification • Differences in process, issue prioritization and resolutions • Both teams started from a common baseline • V0.9 plus Addendum Profiles chapter • Blocks/Parametrics approach • Satisfied most of the requirements of the UML for SE RFP • Submitted revised submissions on November 14, 2005 with planned vote for adoption at next OMG meeting in Feb ‘06

6. SysML Submission Team (SST) • Members • Industry & Government • American Systems, BAE SYSTEMS, Boeing, EADS-Astrium, Eurostep, Lockheed Martin, NIST, oose.de, Raytheon, THALES • Vendors • Artisan, EmbeddedPlus, IBM, I-Logix, Mentor Graphics, Sparx Systems, Vitech Corp • Neutral Collaborators • Deere & Company • Georgia Institute of Technology • NASA/JPL • INCOSE, AP233 SST broad based team of multiple end-users and tool vendors

7. SST Philosophy • Deliver solution to the users without delay • SysML 0.90 widely regarded as an “80% solution” • Systems engineering users demanding this language • Incorporate user and vendor feedback in future revisions • Provide sufficient features to make the language useful for systems engineers • Reuse UML at the package level to maintain language integrity • Limit fine grain selection of UML elements at this time

8. UML for SE RFPRequirements Summary • Structure • e.g., system hierarchy, interconnection • Behavior • e.g., function-based behavior, state-based behavior • Properties • e.g., parametric models, time property • Requirements • e.g., requirements hierarchy, traceability • Verification • e.g., test cases, verification results • Other • e.g., roles, views, relationship types, diagram types • Optional • e.g., trade studies, other behavior modeling paradigms Refer to SST Req’ts Traceability Matrix in Appendix E. SST submission provides robust solution that addresses most of the RFP requirements

9. SST Design Principles (Section 4.1) • Requirements driven • SysML is intended to satisfy the requirements of the UML for SE RFP. • UML reuse • SysML reuses UML wherever practical to satisfy the requirements of the RFP, and when modifications are required, they are done in a manner that strives to minimize changes to the underlying language. Consequently, SysML is intended to be relatively easy to implement for vendors who support UML 2 or later revisions. • UML extensions • SysML extends UML as needed to satisfy the requirements of the RFP. The primary extension mechanism is the UML 2 profile mechanism as further refined in the SysML Profiles & Model Libraries chapter of this specification. • Partitioning • The package is the basic unit of partitioning in this specification. The packages partition the model elements into logical groupings which minimize circular dependencies among them. • Layering • SysML packages are specified as an extension layer to the UML metamodel. • Interoperability • SysML inherits the XMI interchange capability from UML. SysML is also intended to be supported by the ISO AP233 data interchange standard to support interoperability among other engineering tools.

10. Highlights of SST Approach (1 of 3) • Coherent and consistent language architecture essential for integration with UML, model interchange, and standardized implementations • Utilizes UML solution for specifying profiles (e.g. subsetting UML via reference metamodel) • Reuse UML at the package level (vs. metaclass) to avoid breakage and maintain language integrity • Compliance approach that allows vendor to clearly state compliance and users to assess compliance • Consistent with UML • Unambiguous compliance points

11. Highlights of SST Approach (2 of 3) • Usefulness of the language to practicing SE’s • Maintain basic capability for modeling physical systems • deep nesting, design values with distributions, units tied in with dimensions, instance diagram for unique configurations, item flows, moe’s/objective function integrated with parametrics, timing diagram, explicit allocation for swim lanes (activity partitions), requirements refinement via models, … • Ensure understandability • Distinct flow port notations, requirements callout notation, elaborated diagram element tables, diagram conventions, …

12. Highlights of SST Approach (3 of 3) • Multi-vendor solution (Artisan, EmbeddedPlus/IBM, I-Logix, Sparx Systems) that is being implemented • Leverages broad based specification author team to maintain quality and completeness across chapters • This includes chapters that were reused by the other submission team such-as activities, allocations, and profiles & model libraries

13. Evaluating the Specifications • Specifications and RFP available at: • http://syseng.omg.org/SysML.htm • Specification review guidance • Use the SST Highlights & Comparison Matrix and the following slides to help understand the differences between the submissions • Available on INCOSE Evaluators Site or request from SST Chair • Review the following chapters in the SST Introduction • Language architecture and Compliance • Review the following subsections in each SST chapter • Overviews • Diagram elements (look for completeness) • UML extensions (targeted to tool vendors / language implementers) • Usage examples (consistent with Appendix B sample problem) • Review the SST Sample Problem in Appendix B • Provides overview of how language can be used • Review the following appendixes as time permits • Diagrams • Non-Normative Extensions • Model Interchange

14. UML for SE RFP Evaluation Criteria • 6.8.1 Ease of use • 6.8.2 Unambiguous • 6.8.3 Precise • 6.8.4 Complete • 6.8.5 Scalable • 6.8.6 Adaptable to different domains • 6.8.7 Capable of complete model interchange • 6.8.8 Evolvable • 6.8.9 Process and method independent • 6.8.10 Compliant with UML metamodel • 6.8.11 Verifiable

15. Language Feature Summary(Refer to SST Highlights & Comparison Matrix 051201-revb) No. Language Feature Impact/Priority RFP Evaluation Criteria Language Architecture Compliance Views & Viewpoints Value Types, Units & Dimensions Property Specific Types Instance Diagram Deep Nesting Item Flows Flow Port Features Flow Port Compatibility Rules Parametric Diagram Timing Diagram Allocation Types Allocate Activity Partition Requirement Callout Notation Refine Requirements Relationship Containment Symbol Diagram Conventions MOE’s & Objective Function Requirements Classification BNF Notation Chapter Updates 1 2 3 4 5 6 6a 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 H H M H M M H H M M H M M M H H L M H L M M 6.8.2, 6.8.8, 6.8.11 6.8.11 6.8.5 6.8.2, 6.8.3 6.8.1 6.8.4, 6.8.5 (RFP reqt 6.8.4) 6.8.1, 6.8.10 6.8.1, 6.8.4, 6.8.10 6.8.1, 6.8.2 6.8.1, 6.8.3 6.8.1 6.8.4, 6.8.12 (RFP reqt 6.5.2.4.1) 6.8.1, 6.8.2 6.8.1 6.8.1, 6.8.5 6.8.4 6.8.11 6.8.1, 6.8.2 6.8.3, 6.8.4 6.8.2 6.8.2, 6.8.9 6.8.2 Selected Language Features To Contrast Submissions

16. SysML SST Specification Outline • Preface • Part I of RFP Response • Part II of RFP Response • Part III of RFP Response • Part I – Introduction • Scope • Normative references • Additional information • Language Architecture • Compliance • Language Formalism • Part II – Structural Constructs • Model Elements • Blocks • Ports and Flows • Parametrics • Part III – Behavioral Constructs • Activities • Interactions • State Machines • Use Cases • Part IV – Crosscutting Constructs • Allocations • Requirements • Profiles & Model Libraries • Part V Appendices • Diagrams • Sample Problem • Non-Normative Extensions • Model Interchange (AP233 & XMI) • Requirements Traceability • Terms and Definitions • BNF Diagram Syntax Definitions

17. MDSD Recommendations & Response From INCOSE IW Jan 29-30, 2005

18. MDSD Recommendations & ResponseINCOSE IW – Jan ‘05 • Improve SysML tutorial • emphasize 5 Core diagrams and be driven by Requirements diagrams • replace UML-specific definitions with domain-specific explanations • present update at INCOSE Symposium (MDSD plenary) RESPONSE: Will continue to elaborate and refine current tutorial material and make available when adoption begins in February. • Increase readability of SysML specification for engineers and tool vendors • replace UML-specific definitions with domain-specific explanations RESPONSE: Current specification includes a superset of terms in Appendix F that includes definitions from the UML for SE RFP, UML 2, and the SysML extensions. This superset needs to distilled and refined to include the relevant terms needed for the tool vendors and end users. • include a domain metamodel RESPONSE: Use the SE Concept Model to express basic domain concepts. Will work with INCOSE MDSD to capture additional key SysML concepts such as usage/roles, etc.

19. MDSD Recommendations & Response (cont.) • Include a model library for Requirement taxonomy • RESPONSE: Updated requirements taxonomy (refer to Appendix C.2) • include MeasureOfEffectiveness (MOE; properties: weight, optimizationDirection) • RESPONSE: Defined an MOE stereotype which integrates with parametrics to support engineering analysis (refer to Appendix C.3) • MOE may also include a complementary Parametric construct to effect MOE constraints • RESPONSE: Defined a general purpose objective function stereotype which integrates with parameterics to support engineering analysis and optimization (refer to Appendix C.3)

20. MDSD Recommendations & Response (cont.) • Include a model library for Assemblies that includes PhysicalAssembly (properties: supplier, modelNumber, serialNumber, lotNumber) • RESPONSE: Example included in Fig 17-10 in Profiles & Model Libraries chapter. • Harmonize concepts, constructs, and usage examples for Allocations • make implicit Allocations explicit • RESPONSE: Made swim lanes explicit form of allocation (Fig 15-2, Section 15.3.3.3) • test usability of multiple UI options via vendor prototypes • RESPONSE: Multiple UI options explored and incorporated including allocation/requirement compartments, callout, and tabular formats (refer to diagram extensions in 15.3.1 and 16.3.1) • Encourage and promote vendor SysML prototypes at INCOSE Symposium vendor exhibits • RESPONSE: Multi-vendor prototype demonstrations at INCOSE Symposium in July ‘05 at MDSD and on exhibitor floor

21. Specification Updates

22. Progress On Issues • Resolved open issues from v0.9 • Resolved previously identified critical issues • Resolved 237 issues from original issue list • 4 deferred/5 to incorporate into v1.0 • Incorporated issue resolutions into v0.98

23. Refer to Slide 15: No. 21 Specification Updates • Updated Specification Outline • Refined chapters • Simplified chapter organization • Improved overviews, descriptions, diagram extensions, and usage examples • Elaborated diagram element tables to include more complete concrete syntax • Aligned usage examples with sample problem appendix • Updated for consistency with language architecture and compliance approach Enhanced Completeness, Consistency and Understandability of SST Specification v0.98

24. SysML Specification Outline - Authors • Preface • Part I – Introduction – Alan Moore/Sandy Friedenthal • Part II – Structural Constructs • Model Elements - Tim Weilkiens with inputs from Roger Burkhart • Blocks - Alan Moore with inputs from Roger Burkhart • Ports and Flows - Eran Gery • Parametrics – Alan Moore with inputs from Roger Burkhart • Part III – Behavioral Constructs • Activities – Conrad Bock • Interactions – Cory Bialowas/Bran Selic • State Machines - Cory Bialowas/Bran Selic • Use Cases – JD Baker • Part IV – Crosscutting Constructs • Allocations – Rick Steiner • Requirements – Laurent Balmelli • Profiles & Model Libraries – Alan Moore • Part V Appendices • Diagrams – Sandy Friedenthal • Sample Problem – Rick Steiner • Non-Normative Extensions – Conrad Bock/Sandy Friedenthal • Model Interchange (AP233 and XMI) – Bran Selic, Dwayne Hardy/David Price • Requirements Traceability – Sandy Friedenthal • Terms and Definitions – Sandy Friedenthal • BNF Diagram Syntax Definitions – Roger Burkhart

25. Refer to Slide 15: No. 21 Specification UpdatesTechnical Content Change Summary • Redefined Language Architecture and Compliance approach • Structure • Unified class and assembly into blocks* • Specified property subclasses for part, reference, and value • Provided mechanism for part specific subclasses to support design values • Replaced quantity with value type, units, dimensions, and distributions • Redefined ports to include UML (i.e. client-server) ports and flow ports * • Refined item flow semantics and notation • Refined parametric notation and semantics (constraint blocks and properties) • Updated View/Viewpoint to be consistent with IEEE 1471 • Updated diagram taxonomy to include package & instance diagram • Behavior • Refined/updated activity extensions* • Included protocol state machines • Cross cutting • Refined requirements semantics • Refined allocation semantics • Harmonized callout notation between requirements and allocations • Updated profiles per RTF * • Appendixes • Updated diagram frames & headings conventions • Significantly elaborated sample problem appendix and integrated with usage examples in chapters • Refined non-normative extensions for EFFBD profile*, requirements subclasses, and measures of effectiveness (MOE’s)* • Refined approach for XMI and AP233 harmonization • Updated requirements traceability matrix in Appendix E • Identified terms for glossary • Added BNF Diagram Syntax Definition appendix * Work started prior to split on Aug 30, 2005

26. SST Specification Highlights

27. Specification Highlights • Language Architecture • Compliance Approach • Structural Constructs • Behavioral Constructs • Cross Cutting Constructs • Appendixes Language Feature # (From Slide 15) Specification Topic 1 2 3-10, 18 11 12-16, 19 17-20 Refer to the Topic in the Following Slides for Details on the Referenced Language Features from Slide 15

28. Language Architecture

29. Relationship Between SysML and UML UML4SysML SysML Profile

30. SysML Diagram Taxonomy

31. SysML v0.9 Language Architecture • Issues • Reuse of UML was imprecisely defined • Only partial list of required meta-classes • UML2 Profiles chapter not clear on specification and application of UML subset • Profile structure was confusing • Contained sub-packages with no extensions • Package partitioning was inconsistent with chapters • Not tied in with compliance • Impacts • XMI and Interoperability • Ability to integrate UML applications with SysML • Ambiguity affects vendor ability to implement

32. Language Architecture Approach • Worked with UML2 RTF on profiles approach and used to define language architecture • Create UML2 Subset using merge • Reference this subset from the SysML profile • Define fine-grained restrictions on features in constraints • Apply reuse at package level vs metaclass level • Merge only works at package level • Easier to ensure that subset is well-formed with no dangling references • Profile structure redefined • Consistent with SysML chapter structure • Only introduce sub-profile if chapter contains extensions

33. Reuse of UML 2 – UML4SysML SysML Profile Retains UML Integrity

34. SysML Profile Package Modular & Cohesive Package Structure

35. Applying SysML Profile to a User Model

36. SysML Compliance

37. V0.9 Compliance • Issues • Criteria for basic/advanced choice unclear • Basic/Advanced approach too coarse for likely vendor and user community • Difficult for non-UML tools to state compliance • Didn’t fit with UML tool-vendors plans for UML implementation • Levels didn’t reflect break down of SysML language domains • Compliance based on Concrete Syntax • Impact • Difficult to get closure on Basic/Advanced subsets • Users unable to get simple compliance statements from SysML tool vendors • Hard to partition abstract syntax for compliance

38. Compliance Approach • Compliance Levels • Introduce compliance levels into UML4SysML • Strict subsets of UML compliance levels (L1, L2, L3) • Further compliance levels for SysML Profile • Each sub-profile is separate compliance level • Asserts minimal compliance on UML4SysML level • Reuse UML definitions of compliance • Abstract syntax • Concrete syntax • Compliance Statements • No • Partial (requires feature support statement) • Yes Compliance approach allows vendor to clearly state compliance and users to assess compliance

39. Compliance Summary Example Compliance level Abstract Syntax Concrete Syntax UML4SysML Level 1 YES YES UML4SysML Level 2 PARTIAL YES UML4SysML Level 3 NO NO Activities (without Probability) YES YES Activities (with Probability) NO NO Allocations PARTIAL PARTIAL Blocks YES YES Constraint Blocks YES YES Model Elements (without Views) YES YES Model Elements (with Views) NO NO Ports & Flows (w/o Item Flows) YES YES Ports & Flows (with Item Flow) NO NO Requirements YES YES

40. Feature Support Statement Note (1): States and state machines are limited to a single region. Shallow history pseudostates not supported Note (2): FIFO queueing in event pool Note (3): Don’t show Blocks::StructuredCompartment notation

41. Structural Constructs

42. Structural Constructs • Model Elements • Blocks • Ports and Flows • Parametrics

43. Model Elements

44. Model Elements • Includes fundamental modeling constructs such as model elements, packages, and dependencies • Used to organize model • Package diagram used to group model elements into a name space • SysML extension for view and viewpoint • Rational stereotype can be applied to any model element to capture decision

45. Organizing the User Model Package Diagram Used to Organize the Model

46. Views and Viewpoints • Consistent with IEEE 1471 • Viewpoint represents stakeholders, their concerns/purpose/intent, and construction rules for specifying a view • View is a read only mechanism that captures the model subset that addresses the stakeholder concerns • Realizes the viewpoint • Relationships between model elements established in model and not between views

47. IEEE 1471 • IEEE 1471 (section 5.3) prescribes that a viewpoint contains: • a) A viewpoint name • b) The stakeholders to be addressed by the viewpoint • c) The concerns to be addressed by the viewpoint • d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint • e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization)

48. SST View/Viewpoint Viewpoint as a stereotyped class Relationship between Viewpoints View realizes a viewpoint

49. Performance View Example

50. Rationale Rationale can link to a trade study or analysis report Rationale can be attached to any Model Element or Relationship to Capture decisions