Systems Modeling Language (SysML)


Published on

Published in: Technology, Education
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Systems Modeling Language (SysML)

  1. 1. INCOSE Evaluation: Systems Modeling Language (SysML) SysML Submission Team (SST) 13, 15, 20 December 2005 SST Chair: Sanford Friedenthal [email_address]
  2. 2. Topics <ul><li>Introduction </li></ul><ul><li>MDSD Actions </li></ul><ul><li>Specification Updates </li></ul><ul><li>Specification Highlights </li></ul><ul><ul><li>Language Architecture </li></ul></ul><ul><ul><li>Compliance Approach </li></ul></ul><ul><ul><li>Structural Constructs </li></ul></ul><ul><ul><li>Behavioral Constructs </li></ul></ul><ul><ul><li>Cross-cutting Constructs </li></ul></ul><ul><ul><li>Appendixes </li></ul></ul><ul><li>Sample Problems </li></ul><ul><ul><li>HSUV Example from Appendix B </li></ul></ul><ul><ul><li>Distiller Example (response to D. Oliver example) </li></ul></ul><ul><li>Summary </li></ul>
  3. 3. Introductory Statement <ul><li>Two competing specifications* submitted to the OMG on November 14, 2005 from: </li></ul><ul><ul><li>SysML Submission Team (SST) chaired by S. Friedenthal </li></ul></ul><ul><ul><li>SysML Partners chaired by C. Kobryn </li></ul></ul><ul><li>This highlights updates and selected features of the SST SysML Specification v0.98 (ad/2005-11-01) </li></ul><ul><li>A vote for adoption should occur at the next OMG meeting the week of February 13, 2006 </li></ul>* Available at
  4. 4. What is SysML? <ul><li>A graphical modeling language in response to the UML for Systems Engineering RFP developed by the OMG, INCOSE, and AP233 </li></ul><ul><ul><li>a UML Profile that represents a subset of UML 2 with extensions </li></ul></ul><ul><li>Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities </li></ul><ul><li>Supports model and data interchange via XMI and the evolving AP233 standard (in-process) </li></ul>SysML is Critical Enabler for Model Driven SE
  5. 5. SysML Background <ul><li>UML for SE RFP issued – 28 March 2003 </li></ul><ul><li>SysML Partners Kickoff meeting – 6 May 2003 </li></ul><ul><ul><li>Chaired by S. Friedenthal and C. Kobryn </li></ul></ul><ul><li>3 rd revised submission (v0.9) to OMG – 10 Jan 2005 </li></ul><ul><ul><li>Addendum stereotypes chapter – 30 May 2005 </li></ul></ul><ul><li>SysML Submission Team announced split from SysML Partners on August 30, 2005 to finalize the specification </li></ul><ul><ul><li>Differences in process, issue prioritization and resolutions </li></ul></ul><ul><li>Both teams started from a common baseline </li></ul><ul><ul><li>V0.9 plus Addendum Profiles chapter </li></ul></ul><ul><ul><li>Blocks/Parametrics approach </li></ul></ul><ul><ul><li>Satisfied most of the requirements of the UML for SE RFP </li></ul></ul><ul><li>Submitted revised submissions on November 14, 2005 with planned vote for adoption at next OMG meeting in Feb ‘06 </li></ul>
  6. 6. SysML Submission Team (SST) <ul><li>Members </li></ul><ul><ul><li>Industry & Government </li></ul></ul><ul><ul><ul><li>American Systems, BAE SYSTEMS, Boeing, EADS-Astrium, Eurostep, Lockheed Martin, NIST,, Raytheon, THALES </li></ul></ul></ul><ul><ul><li>Vendors </li></ul></ul><ul><ul><ul><li>Artisan, EmbeddedPlus, IBM, I-Logix, Mentor Graphics, Sparx Systems, Vitech Corp </li></ul></ul></ul><ul><li>Neutral Collaborators </li></ul><ul><ul><li>Deere & Company </li></ul></ul><ul><ul><li>Georgia Institute of Technology </li></ul></ul><ul><ul><li>NASA/JPL </li></ul></ul><ul><ul><li>INCOSE, AP233 </li></ul></ul>SST broad based team of multiple end-users and tool vendors
  7. 7. SST Philosophy <ul><li>Deliver solution to the users without delay </li></ul><ul><ul><li>SysML 0.90 widely regarded as an “80% solution” </li></ul></ul><ul><ul><li>Systems engineering users demanding this language </li></ul></ul><ul><ul><li>Incorporate user and vendor feedback in future revisions </li></ul></ul><ul><li>Provide sufficient features to make the language useful for systems engineers </li></ul><ul><li>Reuse UML at the package level to maintain language integrity </li></ul><ul><ul><li>Limit fine grain selection of UML elements at this time </li></ul></ul>
  8. 8. UML for SE RFP Requirements Summary <ul><li>Structure </li></ul><ul><ul><li>e.g., system hierarchy, interconnection </li></ul></ul><ul><li>Behavior </li></ul><ul><ul><li>e.g., function-based behavior, state-based behavior </li></ul></ul><ul><li>Properties </li></ul><ul><ul><li>e.g., parametric models, time property </li></ul></ul><ul><li>Requirements </li></ul><ul><ul><li>e.g., requirements hierarchy, traceability </li></ul></ul><ul><li>Verification </li></ul><ul><ul><li>e.g., test cases, verification results </li></ul></ul><ul><li>Other </li></ul><ul><ul><li>e.g., roles, views, relationship types, diagram types </li></ul></ul><ul><li>Optional </li></ul><ul><ul><li>e.g., trade studies, other behavior modeling paradigms </li></ul></ul>SST submission provides robust solution that addresses most of the RFP requirements Refer to SST Req’ts Traceability Matrix in Appendix E.
  9. 9. SST Design Principles (Section 4.1) <ul><li>Requirements driven </li></ul><ul><ul><li>SysML is intended to satisfy the requirements of the UML for SE RFP. </li></ul></ul><ul><li>UML reuse </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>UML extensions </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Partitioning </li></ul><ul><ul><li>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. </li></ul></ul><ul><li>Layering </li></ul><ul><ul><li>SysML packages are specified as an extension layer to the UML metamodel. </li></ul></ul><ul><li>Interoperability </li></ul><ul><ul><li>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. </li></ul></ul>
  10. 10. Highlights of SST Approach (1 of 3) <ul><li>Coherent and consistent language architecture essential for integration with UML, model interchange, and standardized implementations </li></ul><ul><ul><li>Utilizes UML solution for specifying profiles (e.g. subsetting UML via reference metamodel) </li></ul></ul><ul><ul><li>Reuse UML at the package level (vs. metaclass) to avoid breakage and maintain language integrity </li></ul></ul><ul><li>Compliance approach that allows vendor to clearly state compliance and users to assess compliance </li></ul><ul><ul><li>Consistent with UML </li></ul></ul><ul><ul><li>Unambiguous compliance points </li></ul></ul>
  11. 11. Highlights of SST Approach (2 of 3) <ul><li>Usefulness of the language to practicing SE’s </li></ul><ul><ul><li>Maintain basic capability for modeling physical systems </li></ul></ul><ul><ul><ul><li>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, … </li></ul></ul></ul><ul><ul><li>Ensure understandability </li></ul></ul><ul><ul><ul><li>Distinct flow port notations, requirements callout notation, elaborated diagram element tables, diagram conventions, … </li></ul></ul></ul>
  12. 12. Highlights of SST Approach (3 of 3) <ul><li>Multi-vendor solution (Artisan, EmbeddedPlus/IBM, I-Logix, Sparx Systems) that is being implemented </li></ul><ul><li>Leverages broad based specification author team to maintain quality and completeness across chapters </li></ul><ul><ul><li>This includes chapters that were reused by the other submission team such-as activities, allocations, and profiles & model libraries </li></ul></ul>
  13. 13. Evaluating the Specifications <ul><li>Specifications and RFP available at: </li></ul><ul><ul><li> </li></ul></ul><ul><li>Specification review guidance </li></ul><ul><ul><li>Use the SST Highlights & Comparison Matrix and the following slides to help understand the differences between the submissions </li></ul></ul><ul><ul><ul><li>Available on INCOSE Evaluators Site or request from SST Chair </li></ul></ul></ul><ul><ul><li>Review the following chapters in the SST Introduction </li></ul></ul><ul><ul><ul><li>Language architecture and Compliance </li></ul></ul></ul><ul><ul><li>Review the following subsections in each SST chapter </li></ul></ul><ul><ul><ul><li>Overviews </li></ul></ul></ul><ul><ul><ul><li>Diagram elements (look for completeness) </li></ul></ul></ul><ul><ul><ul><li>UML extensions (targeted to tool vendors / language implementers) </li></ul></ul></ul><ul><ul><ul><li>Usage examples (consistent with Appendix B sample problem) </li></ul></ul></ul><ul><ul><li>Review the SST Sample Problem in Appendix B </li></ul></ul><ul><ul><ul><li>Provides overview of how language can be used </li></ul></ul></ul><ul><ul><li>Review the following appendixes as time permits </li></ul></ul><ul><ul><ul><li>Diagrams </li></ul></ul></ul><ul><ul><ul><li>Non-Normative Extensions </li></ul></ul></ul><ul><ul><ul><li>Model Interchange </li></ul></ul></ul>
  14. 14. UML for SE RFP Evaluation Criteria <ul><li>6.8.1 Ease of use </li></ul><ul><li>6.8.2 Unambiguous </li></ul><ul><li>6.8.3 Precise </li></ul><ul><li>6.8.4 Complete </li></ul><ul><li>6.8.5 Scalable </li></ul><ul><li>6.8.6 Adaptable to different domains </li></ul><ul><li>6.8.7 Capable of complete model interchange </li></ul><ul><li>6.8.8 Evolvable </li></ul><ul><li>6.8.9 Process and method independent </li></ul><ul><li>6.8.10 Compliant with UML metamodel </li></ul><ul><li>6.8.11 Verifiable </li></ul>
  15. 15. Language Feature Summary (Refer to SST Highlights & Comparison Matrix 051201-revb) <ul><li>Language Architecture </li></ul><ul><li>Compliance </li></ul><ul><li>Views & Viewpoints </li></ul><ul><li>Value Types, Units & Dimensions </li></ul><ul><li>Property Specific Types </li></ul><ul><li>Instance Diagram </li></ul><ul><li>Deep Nesting </li></ul><ul><li>Item Flows </li></ul><ul><li>Flow Port Features </li></ul><ul><li>Flow Port Compatibility Rules </li></ul><ul><li>Parametric Diagram </li></ul><ul><li>Timing Diagram </li></ul><ul><li>Allocation Types </li></ul><ul><li>Allocate Activity Partition </li></ul><ul><li>Requirement Callout Notation </li></ul><ul><li>Refine Requirements Relationship </li></ul><ul><li>Containment Symbol </li></ul><ul><li>Diagram Conventions </li></ul><ul><li>MOE’s & Objective Function </li></ul><ul><li>Requirements Classification </li></ul><ul><li>BNF Notation </li></ul><ul><li>Chapter Updates </li></ul>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.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 Language Feature Impact/Priority RFP Evaluation Criteria Selected Language Features To Contrast Submissions 1 2 3 4 5 6 6a 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 No.
  16. 16. SysML SST Specification Outline <ul><li>Preface </li></ul><ul><ul><li>Part I of RFP Response </li></ul></ul><ul><ul><li>Part II of RFP Response </li></ul></ul><ul><ul><li>Part III of RFP Response </li></ul></ul><ul><li>Part I – Introduction </li></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Normative references </li></ul></ul><ul><ul><li>Additional information </li></ul></ul><ul><ul><li>Language Architecture </li></ul></ul><ul><ul><li>Compliance </li></ul></ul><ul><ul><li>Language Formalism </li></ul></ul><ul><li>Part II – Structural Constructs </li></ul><ul><ul><li>Model Elements </li></ul></ul><ul><ul><li>Blocks </li></ul></ul><ul><ul><li>Ports and Flows </li></ul></ul><ul><ul><li>Parametrics </li></ul></ul><ul><li>Part III – Behavioral Constructs </li></ul><ul><ul><li>Activities </li></ul></ul><ul><ul><li>Interactions </li></ul></ul><ul><ul><li>State Machines </li></ul></ul><ul><ul><li>Use Cases </li></ul></ul><ul><li>Part IV – Crosscutting Constructs </li></ul><ul><ul><li>Allocations </li></ul></ul><ul><ul><li>Requirements </li></ul></ul><ul><ul><li>Profiles & Model Libraries </li></ul></ul><ul><li>Part V Appendices </li></ul><ul><ul><li>Diagrams </li></ul></ul><ul><ul><li>Sample Problem </li></ul></ul><ul><ul><li>Non-Normative Extensions </li></ul></ul><ul><ul><li>Model Interchange (AP233 & XMI) </li></ul></ul><ul><ul><li>Requirements Traceability </li></ul></ul><ul><ul><li>Terms and Definitions </li></ul></ul><ul><ul><li>BNF Diagram Syntax Definitions </li></ul></ul>
  17. 17. MDSD Recommendations & Response From INCOSE IW Jan 29-30, 2005
  18. 18. MDSD Recommendations & Response INCOSE IW – Jan ‘05 <ul><li>Improve SysML tutorial </li></ul><ul><ul><li>emphasize 5 Core diagrams and be driven by Requirements diagrams </li></ul></ul><ul><ul><li>replace UML-specific definitions with domain-specific explanations </li></ul></ul><ul><ul><li>present update at INCOSE Symposium (MDSD plenary) </li></ul></ul><ul><ul><li>RESPONSE: Will continue to elaborate and refine current tutorial material and make available when adoption begins in February. </li></ul></ul><ul><li>Increase readability of SysML specification for engineers and tool vendors </li></ul><ul><ul><li>replace UML-specific definitions with domain-specific explanations </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>include a domain metamodel </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  19. 19. MDSD Recommendations & Response (cont.) <ul><li>Include a model library for Requirement taxonomy </li></ul><ul><ul><li>RESPONSE: Updated requirements taxonomy (refer to Appendix C.2) </li></ul></ul><ul><ul><li>include MeasureOfEffectiveness (MOE; properties: weight, optimizationDirection) </li></ul></ul><ul><ul><ul><li>RESPONSE: Defined an MOE stereotype which integrates with parametrics to support engineering analysis (refer to Appendix C.3) </li></ul></ul></ul><ul><ul><li>MOE may also include a complementary Parametric construct to effect MOE constraints </li></ul></ul><ul><ul><ul><li>RESPONSE: Defined a general purpose objective function stereotype which integrates with parameterics to support engineering analysis and optimization (refer to Appendix C.3) </li></ul></ul></ul>
  20. 20. MDSD Recommendations & Response (cont.) <ul><li>Include a model library for Assemblies that includes PhysicalAssembly (properties: supplier, modelNumber, serialNumber, lotNumber) </li></ul><ul><ul><li>RESPONSE: Example included in Fig 17-10 in Profiles & Model Libraries chapter. </li></ul></ul><ul><li>Harmonize concepts, constructs, and usage examples for Allocations </li></ul><ul><ul><li>make implicit Allocations explicit </li></ul></ul><ul><ul><ul><li>RESPONSE: Made swim lanes explicit form of allocation (Fig 15-2, Section </li></ul></ul></ul><ul><ul><li>test usability of multiple UI options via vendor prototypes </li></ul></ul><ul><ul><ul><li>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) </li></ul></ul></ul><ul><li>Encourage and promote vendor SysML prototypes at INCOSE Symposium vendor exhibits </li></ul><ul><ul><li>RESPONSE: Multi-vendor prototype demonstrations at INCOSE Symposium in July ‘05 at MDSD and on exhibitor floor </li></ul></ul>
  21. 21. Specification Updates
  22. 22. Progress On Issues <ul><li>Resolved open issues from v0.9 </li></ul><ul><ul><li>Resolved previously identified critical issues </li></ul></ul><ul><ul><li>Resolved 237 issues from original issue list </li></ul></ul><ul><ul><ul><li>4 deferred/5 to incorporate into v1.0 </li></ul></ul></ul><ul><li>Incorporated issue resolutions into v0.98 </li></ul>
  23. 23. Specification Updates <ul><li>Updated Specification Outline </li></ul><ul><li>Refined chapters </li></ul><ul><ul><li>Simplified chapter organization </li></ul></ul><ul><ul><li>Improved overviews, descriptions, d iagram extensions, and usage examples </li></ul></ul><ul><ul><li>Elaborated diagram element tables to include more complete concrete syntax </li></ul></ul><ul><ul><li>Aligned usage examples with sample problem appendix </li></ul></ul><ul><ul><li>Updated for consistency with language architecture and compliance approach </li></ul></ul>Enhanced Completeness, Consistency and Understandability of SST Specification v0.98 Refer to Slide 15: No. 21
  24. 24. SysML Specification Outline - Authors <ul><li>Preface </li></ul><ul><li>Part I – Introduction – Alan Moore/Sandy Friedenthal </li></ul><ul><li>Part II – Structural Constructs </li></ul><ul><ul><li>Model Elements - Tim Weilkiens with inputs from Roger Burkhart </li></ul></ul><ul><ul><li>Blocks - Alan Moore with inputs from Roger Burkhart </li></ul></ul><ul><ul><li>Ports and Flows - Eran Gery </li></ul></ul><ul><ul><li>Parametrics – Alan Moore with inputs from Roger Burkhart </li></ul></ul><ul><li>Part III – Behavioral Constructs </li></ul><ul><ul><li>Activities – Conrad Bock </li></ul></ul><ul><ul><li>Interactions – Cory Bialowas/Bran Selic </li></ul></ul><ul><ul><li>State Machines - Cory Bialowas/Bran Selic </li></ul></ul><ul><ul><li>Use Cases – JD Baker </li></ul></ul><ul><li>Part IV – Crosscutting Constructs </li></ul><ul><ul><li>Allocations – Rick Steiner </li></ul></ul><ul><ul><li>Requirements – Laurent Balmelli </li></ul></ul><ul><ul><li>Profiles & Model Libraries – Alan Moore </li></ul></ul><ul><li>Part V Appendices </li></ul><ul><ul><li>Diagrams – Sandy Friedenthal </li></ul></ul><ul><ul><li>Sample Problem – Rick Steiner </li></ul></ul><ul><ul><li>Non-Normative Extensions – Conrad Bock/Sandy Friedenthal </li></ul></ul><ul><ul><li>Model Interchange (AP233 and XMI) – Bran Selic, Dwayne Hardy/David Price </li></ul></ul><ul><ul><li>Requirements Traceability – Sandy Friedenthal </li></ul></ul><ul><ul><li>Terms and Definitions – Sandy Friedenthal </li></ul></ul><ul><ul><li>BNF Diagram Syntax Definitions – Roger Burkhart </li></ul></ul>
  25. 25. Specification Updates Technical Content Change Summary <ul><li>Redefined Language Architecture and Compliance approach </li></ul><ul><li>Structure </li></ul><ul><ul><li>Unified class and assembly into blocks* </li></ul></ul><ul><ul><li>Specified property subclasses for part, reference, and value </li></ul></ul><ul><ul><li>Provided mechanism for part specific subclasses to support design values </li></ul></ul><ul><ul><li>Replaced quantity with value type, units, dimensions, and distributions </li></ul></ul><ul><ul><li>Redefined ports to include UML (i.e. client-server) ports and flow ports * </li></ul></ul><ul><ul><li>Refined item flow semantics and notation </li></ul></ul><ul><ul><li>Refined parametric notation and semantics (constraint blocks and properties) </li></ul></ul><ul><ul><li>Updated View/Viewpoint to be consistent with IEEE 1471 </li></ul></ul><ul><ul><li>Updated diagram taxonomy to include package & instance diagram </li></ul></ul><ul><li>Behavior </li></ul><ul><ul><li>Refined/updated activity extensions* </li></ul></ul><ul><ul><li>Included protocol state machines </li></ul></ul><ul><li>Cross cutting </li></ul><ul><ul><li>Refined requirements semantics </li></ul></ul><ul><ul><li>Refined allocation semantics </li></ul></ul><ul><ul><li>Harmonized callout notation between requirements and allocations </li></ul></ul><ul><ul><li>Updated profiles per RTF * </li></ul></ul><ul><li>Appendixes </li></ul><ul><ul><li>Updated diagram frames & headings conventions </li></ul></ul><ul><ul><li>Significantly elaborated sample problem appendix and integrated with usage examples in chapters </li></ul></ul><ul><ul><li>Refined non-normative extensions for EFFBD profile*, requirements subclasses, and measures of effectiveness (MOE’s)* </li></ul></ul><ul><ul><li>Refined approach for XMI and AP233 harmonization </li></ul></ul><ul><ul><li>Updated requirements traceability matrix in Appendix E </li></ul></ul><ul><ul><li>Identified terms for glossary </li></ul></ul><ul><ul><li>Added BNF Diagram Syntax Definition appendix </li></ul></ul>* Work started prior to split on Aug 30, 2005 Refer to Slide 15: No. 21
  26. 26. SST Specification Highlights
  27. 27. Specification Highlights <ul><li>Language Architecture </li></ul><ul><li>Compliance Approach </li></ul><ul><li>Structural Constructs </li></ul><ul><li>Behavioral Constructs </li></ul><ul><li>Cross Cutting Constructs </li></ul><ul><li>Appendixes </li></ul>1 2 3-10, 18 11 12-16, 19 17-20 Language Feature # (From Slide 15) Specification Topic Refer to the Topic in the Following Slides for Details on the Referenced Language Features from Slide 15
  28. 28. Language Architecture
  29. 29. Relationship Between SysML and UML UML4SysML SysML Profile
  30. 30. SysML Diagram Taxonomy
  31. 31. SysML v0.9 Language Architecture <ul><li>Issues </li></ul><ul><ul><li>Reuse of UML was imprecisely defined </li></ul></ul><ul><ul><ul><li>Only partial list of required meta-classes </li></ul></ul></ul><ul><ul><ul><li>UML2 Profiles chapter not clear on specification and application of UML subset </li></ul></ul></ul><ul><ul><li>Profile structure was confusing </li></ul></ul><ul><ul><ul><li>Contained sub-packages with no extensions </li></ul></ul></ul><ul><ul><ul><li>Package partitioning was inconsistent with chapters </li></ul></ul></ul><ul><ul><li>Not tied in with compliance </li></ul></ul><ul><li>Impacts </li></ul><ul><ul><li>XMI and Interoperability </li></ul></ul><ul><ul><li>Ability to integrate UML applications with SysML </li></ul></ul><ul><ul><li>Ambiguity affects vendor ability to implement </li></ul></ul>
  32. 32. Language Architecture Approach <ul><li>Worked with UML2 RTF on profiles approach and used to define language architecture </li></ul><ul><ul><li>Create UML2 Subset using merge </li></ul></ul><ul><ul><li>Reference this subset from the SysML profile </li></ul></ul><ul><ul><li>Define fine-grained restrictions on features in constraints </li></ul></ul><ul><li>Apply reuse at package level vs metaclass level </li></ul><ul><ul><li>Merge only works at package level </li></ul></ul><ul><ul><li>Easier to ensure that subset is well-formed with no dangling references </li></ul></ul><ul><li>Profile structure redefined </li></ul><ul><ul><li>Consistent with SysML chapter structure </li></ul></ul><ul><ul><li>Only introduce sub-profile if chapter contains extensions </li></ul></ul>
  33. 33. Reuse of UML 2 – UML4SysML SysML Profile Retains UML Integrity
  34. 34. SysML Profile Package Modular & Cohesive Package Structure
  35. 35. Applying SysML Profile to a User Model
  36. 36. SysML Compliance
  37. 37. V0.9 Compliance <ul><li>Issues </li></ul><ul><ul><li>Criteria for basic/advanced choice unclear </li></ul></ul><ul><ul><li>Basic/Advanced approach too coarse for likely vendor and user community </li></ul></ul><ul><ul><ul><li>Difficult for non-UML tools to state compliance </li></ul></ul></ul><ul><ul><ul><li>Didn’t fit with UML tool-vendors plans for UML implementation </li></ul></ul></ul><ul><ul><ul><li>Levels didn’t reflect break down of SysML language domains </li></ul></ul></ul><ul><ul><li>Compliance based on Concrete Syntax </li></ul></ul><ul><li>Impact </li></ul><ul><ul><li>Difficult to get closure on Basic/Advanced subsets </li></ul></ul><ul><ul><li>Users unable to get simple compliance statements from SysML tool vendors </li></ul></ul><ul><ul><li>Hard to partition abstract syntax for compliance </li></ul></ul>
  38. 38. Compliance Approach <ul><li>Compliance Levels </li></ul><ul><ul><li>Introduce compliance levels into UML4SysML </li></ul></ul><ul><ul><ul><li>Strict subsets of UML compliance levels (L1, L2, L3) </li></ul></ul></ul><ul><ul><li>Further compliance levels for SysML Profile </li></ul></ul><ul><ul><ul><li>Each sub-profile is separate compliance level </li></ul></ul></ul><ul><ul><ul><li>Asserts minimal compliance on UML4SysML level </li></ul></ul></ul><ul><li>Reuse UML definitions of compliance </li></ul><ul><ul><li>Abstract syntax </li></ul></ul><ul><ul><li>Concrete syntax </li></ul></ul><ul><li>Compliance Statements </li></ul><ul><ul><li>No </li></ul></ul><ul><ul><li>Partial (requires feature support statement) </li></ul></ul><ul><ul><li>Yes </li></ul></ul>Compliance approach allows vendor to clearly state compliance and users to assess compliance
  39. 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. 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 YES Note (3) YES Block SysML::Blocks Note(2) YES Note (1) StateMachines::BehaviorStateMachines UML4SysML::Level 2 Semantics Concrete Syntax Abstract Syntax Detail Compliance Level Feature Support Statement
  41. 41. Structural Constructs
  42. 42. Structural Constructs <ul><li>Model Elements </li></ul><ul><li>Blocks </li></ul><ul><li>Ports and Flows </li></ul><ul><li>Parametrics </li></ul>
  43. 43. Model Elements
  44. 44. Model Elements <ul><li>Includes fundamental modeling constructs such as model elements, packages, and dependencies </li></ul><ul><li>Used to organize model </li></ul><ul><ul><li>Package diagram used to group model elements into a name space </li></ul></ul><ul><ul><li>SysML extension for view and viewpoint </li></ul></ul><ul><li>Rational stereotype can be applied to any model element to capture decision </li></ul>
  45. 45. Organizing the User Model Package Diagram Used to Organize the Model
  46. 46. Views and Viewpoints <ul><li>Consistent with IEEE 1471 </li></ul><ul><li>Viewpoint represents stakeholders, their concerns/purpose/intent, and construction rules for specifying a view </li></ul><ul><li>View is a read only mechanism that captures the model subset that addresses the stakeholder concerns </li></ul><ul><ul><li>Realizes the viewpoint </li></ul></ul><ul><ul><li>Relationships between model elements established in model and not between views </li></ul></ul>
  47. 47. IEEE 1471 <ul><li>IEEE 1471 (section 5.3) prescribes that a viewpoint contains: </li></ul><ul><ul><li>a) A viewpoint name </li></ul></ul><ul><ul><li>b) The stakeholders to be addressed by the viewpoint </li></ul></ul><ul><ul><li>c) The concerns to be addressed by the viewpoint </li></ul></ul><ul><ul><li>d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint </li></ul></ul><ul><ul><li>e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization) </li></ul></ul>
  48. 48. SST View/Viewpoint Viewpoint as a stereotyped class View realizes a viewpoint Relationship between Viewpoints
  49. 49. Performance View Example
  50. 50. Rationale Rationale can be attached to any Model Element or Relationship to Capture decisions Rationale can link to a trade study or analysis report
  51. 51. Blocks
  52. 52. Blocks Highlights <ul><li>Unification of classes and assemblies </li></ul><ul><li>Property subclasses </li></ul><ul><li>Deep nesting </li></ul><ul><li>Design values </li></ul><ul><li>Specification of value types with units, dimensions, and probabilities </li></ul><ul><li>Instance diagrams </li></ul>Resolution of Blocks Issues Resulted in Solid Structural Foundation for SST Submission
  53. 53. Blocks Unify Class & Assembly from v0.9 <ul><li>Blocks provides a unifying concept to describe the structure of an element </li></ul><ul><ul><li>Based on UML class from UML Composite Structures </li></ul></ul><ul><li>Block definition diagram describes the relationship among blocks (e.g. composition, association, classification, ..) </li></ul><ul><li>Internal block diagram describes the internal structure of a block in terms of its properties and connectors </li></ul><ul><li>Behavior can be allocated to blocks </li></ul>
  54. 54. Power Subsystem Breakdown Block Definition Diagram Used to Specify System Hierarchy and Classification
  55. 55. Power Subsystem IBD Internal Block Diagram Used to Specify Interconnection Among Parts in Context of Enclosing Block Part Connector Enclosing Block
  56. 56. Property Subclasses <ul><li>Property is a structural feature of a block which is further sub-classed in SysML </li></ul><ul><ul><li>Part property aka. part (typed by a block) </li></ul></ul><ul><ul><ul><li>Usage of a block in the context of the enclosing block </li></ul></ul></ul><ul><ul><ul><li>Example - right-front:wheel </li></ul></ul></ul><ul><ul><li>Value property (typed by value type) </li></ul></ul><ul><ul><ul><li>Defines a value with units, dimensions, and probability distribution </li></ul></ul></ul><ul><ul><ul><li>Example - tirePressure:psi {distribution=Uniform (min=27,max=29)} </li></ul></ul></ul><ul><ul><li>Reference property (typed by a block) </li></ul></ul><ul><ul><ul><li>A part that is not owned by the enclosing block </li></ul></ul></ul><ul><ul><ul><li>Example - logical interface between 2 parts </li></ul></ul></ul>
  57. 57. ibd block Automotive Domain env : Environment road : Road vehicle : HSUV 2 front : Tire 2 rear : Tire Deep Nesting Provides Intuitive Modeling of Physical Systems and does not Impose Process Simple Example of Deep Nesting Connecting a Tire to a Road No need for modeler to specify intermediate connections
  58. 58. Design Values Example «part» 2 back : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=27,max=29)} «part» 2 front : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=25,max=27)} ibd SUV Car SUV Wheel tyrePressure : psi 2 1 back 2 1 front bdd Car Design [] Indicates part-specific block Supports different values & distributions for each part Design Values Ease Ability to Specify Different Values/Distributions on Parts in Same Context
  59. 59. Units and Dimensions «value» unit=second dimension=time s Units Tied Explicitly to Dimensions bdd [package] SI Unit Types ins [package] SI Units «block» second:Unit «block» time:Dimension bdd [package] Objects values t1:s t2:s Obj
  60. 60. Units Model Library Model Library Can be Expanded to Address Domain Needs
  61. 61. SST Instance Diagram <ul><li>Instances are a fundamental aspect of UML classes which is the foundation for blocks </li></ul><ul><li>Instances provide a means for uniquely identifying a member of a “class” (block) </li></ul><ul><ul><li>System configuration with unique serial number/id </li></ul></ul><ul><ul><li>Specific examples with unique values </li></ul></ul><ul><ul><li>Specific items under test with test results (e.g. failed item for causal analysis) </li></ul></ul><ul><ul><li>… . </li></ul></ul>
  62. 62. Test Result Instance Example Use of Instance Diagram for Specifying a Unique System Test Configuration and Values
  63. 63. Ports and Flows Issues
  64. 64. Ports <ul><li>V0.9 Issue </li></ul><ul><ul><li>Did not have ability to specify what can flow in or out of a block (I/O) </li></ul></ul><ul><ul><li>Did not include UML port capability </li></ul></ul><ul><li>Impact </li></ul><ul><ul><li>Could not specify what flows in or out of a block independent of its usage </li></ul></ul><ul><ul><ul><li>e.g. fluid can flow in or out of a tank </li></ul></ul></ul><ul><ul><li>Did not meet needs of service oriented designs and integration with software </li></ul></ul>
  65. 65. Ports Approach <ul><li>Ports represent block interaction points via which Blocks provide or consume data/material/energy or services </li></ul><ul><li>Support specification of interfaces on a block independent of a specific usage (e.g. this component requires 110 volts of power input) </li></ul><ul><li>Approach is to specialize two port types </li></ul><ul><ul><li>Flow ports </li></ul></ul><ul><ul><ul><li>Port type specifies what can flow in our out of block/part </li></ul></ul></ul><ul><ul><ul><li>A connection point through which there is a flow of information, material, or energy (I/O) </li></ul></ul></ul><ul><ul><ul><li>Typically asynchronous flow where producer is not aware when/who consumes the flow </li></ul></ul></ul><ul><ul><li>Client server ports </li></ul></ul><ul><ul><ul><li>Service oriented (request-reply) peer2peer interaction </li></ul></ul></ul><ul><ul><ul><li>Typically synchronous communication </li></ul></ul></ul><ul><ul><ul><li>Specified similar to UML2.0 ports using required/provided interfaces detailing the set of provided/required services </li></ul></ul></ul><ul><ul><ul><li>Allow signal exchanges for compatibility </li></ul></ul></ul>2 Distinct Port Types that Support Different Interface Concepts
  66. 66. FlowPorts <ul><li>Additional considerations </li></ul><ul><ul><li>Simple (natural) way for SEs to specify I/O via the port </li></ul></ul><ul><ul><li>Address the common case of atomic FlowPorts </li></ul></ul><ul><ul><li>Allow both signal flow and data/block instance flow </li></ul></ul><ul><li>FlowPorts Specification </li></ul><ul><ul><li>I/O is specified using an interface stereotyped FlowSpecification </li></ul></ul><ul><ul><li>FlowSpecification consists of properties stereotyped FlowProperties </li></ul></ul><ul><ul><ul><li>FlowProperty has a direction attribute: in, out, inOut </li></ul></ul></ul><ul><ul><ul><li>FlowProperties can be typed by ValueTypes, Block, and Signals </li></ul></ul></ul><ul><ul><ul><li>isConjugate promotes reuse of flowSpecifications </li></ul></ul></ul><ul><li>Atomic FlowPorts </li></ul><ul><ul><li>It is common that a FlowPort flows a single item type </li></ul></ul><ul><ul><li>In this case the port is directly typed by the item type (Block or Value) </li></ul></ul><ul><ul><li>Direction property specify the direction </li></ul></ul><ul><li>Compatibility rules on ports facilitate interface compatibility </li></ul>
  67. 67. Item Flows Approach <ul><li>Distinct from what can flow via the port specification </li></ul><ul><li>Supports compact and intuitive modeling of physical flows </li></ul><ul><li>Supports top down description of flows without imposing behavioral method (e.g. activities, state, interactions) </li></ul><ul><ul><li>Is aligned with behavior thru refinement and allocation </li></ul></ul><ul><li>Facilitates flow allocations from an object node, message, or signal from a behavioral diagram </li></ul><ul><li>Properties of item flow can be specified and constrained in parametric diagram </li></ul>Item Flow Representation is Classical SE Modeling Paradigm to Represent What Flows in a Particular Context
  68. 68. Power Subsystem IBD Client server port Flow port Item flow Specifying Interfaces on an IBD in Terms of Connectors, Ports and Flows Connector
  69. 69. Parametrics & MOE’s/Objective Functions
  70. 70. Parametrics <ul><li>Used to express constraints (equations) between value properties </li></ul><ul><ul><li>Provides support to engineering analysis (e.g. performance, reliability, etc) </li></ul></ul><ul><ul><li>Reusable (e.g. F=m*a is reused in many contexts) </li></ul></ul><ul><ul><li>Non-causal (i.e. declarative statement of the invariant without specifying dependent/independent variables) </li></ul></ul><ul><li>Constraint block defined as a simple extension of block </li></ul><ul><ul><li>Packages UML constraint so they are reusable and parameterized </li></ul></ul><ul><ul><li>Constraint and constraint parameters are specified </li></ul></ul><ul><ul><li>Expression language can be formal (e.g. MathML, OCL …) or informal </li></ul></ul><ul><ul><li>Computational engine is defined by applicable analysis tool and not by SysML </li></ul></ul><ul><li>Parametric diagram represents the usage of the constraints in an analysis context </li></ul><ul><ul><li>Binding of constraint usage to value properties of blocks (e.g. vehicle mass bound to F= m * a) </li></ul></ul><ul><ul><ul><li>Can use nested notation or dot notation </li></ul></ul></ul><ul><li>MOE’s and objective functions integrated with Parametrics to support trade studies and engineering analysis </li></ul>Parametrics Scalability & Integration with Engr Analysis Validated by Georgia Tech
  71. 71. Defining Vehicle Dynamics Defining Reusable Equations for Parametrics
  72. 72. Evaluating Vehicle Dynamics Using the Equations in a Parametric Diagram to Constrain the Value Properties
  73. 73. Evaluating Measures of Effectiveness MOE’s and objective function provide flexible support for trade study analysis that is fully integrated with parametrics
  74. 74. Constraint Blocks - Comparison of Block-based vs. Collaboration-based approach <ul><li>Concrete Syntax </li></ul><ul><ul><li>More notational changes to default collaboration notation required to support chosen Constraint Block notation </li></ul></ul><ul><li>Abstract Syntax </li></ul><ul><ul><li>Additional abstract syntax required for deep-nested bindings </li></ul></ul><ul><ul><li>Need to relax UML Collaboration constraints in order to support deep-nested bindings </li></ul></ul><ul><ul><li>CollaborationUse does not support inheritance or redefinition </li></ul></ul><ul><li>Semantics </li></ul><ul><ul><li>Constraint Blocks can denote objects to represent equations with state </li></ul></ul><ul><ul><ul><li>Collaboration Use cannot be a defining feature of a slot, so cannot build instance specification hierarchy for blocks with constraints </li></ul></ul></ul><ul><ul><li>Connectors can specify multiplicities on bindings to multi-valued parameters or properties </li></ul></ul>Blocks Based Approach Retains Structural Integrity and Simplifies Language
  75. 75. Behavioral Constructs
  76. 76. Behavioral Constructs <ul><li>Activities </li></ul><ul><li>Interactions </li></ul><ul><li>State Machines </li></ul><ul><li>Use Cases </li></ul>
  77. 77. Activities
  78. 78. Activities <ul><li>Activities used to specify flow of I/O and control </li></ul><ul><ul><li>Input/Output represented by object node/pins that are typed by blocks </li></ul></ul><ul><ul><ul><li>External I/O called a parameter </li></ul></ul></ul><ul><ul><li>Control flow represent enabling of activity </li></ul></ul><ul><ul><ul><li>Control constructs include decision, merge, fork, join, initial node, activity final, flow final </li></ul></ul></ul><ul><li>SysML extensions to Activities </li></ul><ul><ul><li>Alignment of activities with EFFBD </li></ul></ul><ul><ul><ul><li>Non normative appendix specifies specific execution rules for EFFBD support </li></ul></ul></ul><ul><ul><ul><ul><li>Does not explicitly support replication and resources </li></ul></ul></ul></ul><ul><ul><li>Support for continuous flow modeling </li></ul></ul>
  79. 79. SysML EFFBD Profile Aligning SysML with Proven Systems Engineering Techniques Refer to Appendix C.1 for Details & Execution Rules
  80. 80. Distiller Example Provided by D. Oliver Dirty water @ 20 deg C Heat Dirty water To 100 deg C Heat to Dirty water Boil Dirty water Dirty water @ 100 deg C Steam Residue and Condense steam Drain Residue Pure water Disposed residue Heat to Boil water Energy to condense and
  81. 81. Distill Water Activity Diagram (Initial) Representing Distiller Example in SysML Using EFFBD Profile
  82. 82. Distill Water Activity Diagram (Continuous Flow Modeling) Representing Distiller Example in SysML Using Continuous Flow Modeling
  83. 83. Interactions
  84. 84. Interactions <ul><li>Sequence diagrams provide representations for message based behavior </li></ul><ul><ul><li>Represents flow of control </li></ul></ul><ul><ul><ul><li>Less effective than activities for representing inputs from multiple sources </li></ul></ul></ul><ul><ul><li>UML 2 sequence diagrams significantly more scalable by providing reference sequences, control logic, and lifeline decomposition </li></ul></ul><ul><li>Timing diagrams provide representations for typical system timelines and value properties vs time </li></ul><ul><li>No change to UML </li></ul><ul><ul><li>Minor clarification on continuous time representations </li></ul></ul>
  85. 85. Black Box Interaction (Drive) UML 2 Sequence Diagram More Scalable by Supporting Control Logic and Reference Sequences
  86. 86. Black Box Sequence (StartVehicle) Simple Black Box Interaction References Lifeline Decomp For White Box Interaction
  87. 87. White Box Sequence (StartVehicle) Decomposition of Black Box Into White Box Interaction
  88. 88. Trial Result of Vehicle Dynamics Typical Example of a Timing Diagram Lifeline are value properties
  89. 89. State Machines
  90. 90. State Machines <ul><li>Supports event based behavior (generally asynchronous) </li></ul><ul><ul><li>Transition with event, guard, action </li></ul></ul><ul><ul><li>State with entry, exit and do-activity </li></ul></ul><ul><ul><li>Can include nested sequential or concurrent states </li></ul></ul><ul><li>Two types of state machines </li></ul><ul><ul><li>Behavior state machines is typical use </li></ul></ul><ul><ul><li>Protocol state machines used to specify sequence of operations or signals </li></ul></ul><ul><ul><ul><li>Can be used as a specification on a port </li></ul></ul></ul><ul><li>No change to UML </li></ul>
  91. 91. Operational States (Drive)
  92. 92. Use Cases
  93. 93. Use Cases <ul><li>Provides means for describing basic functionality in terms of usages of system by actors </li></ul><ul><li>Generally elaborated via other behavioral representations to describe detailed scenarios </li></ul><ul><li>No change to UML </li></ul>
  94. 94. Top Level Use Cases
  95. 95. Operational Use Cases
  96. 96. Cross-cutting Constructs
  97. 97. Cross-cutting Constructs <ul><li>Allocations </li></ul><ul><li>Requirements </li></ul><ul><li>Profiles & Model Libraries </li></ul>
  98. 98. Allocations
  99. 99. Allocations <ul><li>Provides general relationship to map one model element to another </li></ul><ul><li>Includes specific subclasses of allocation with constraints on their usage </li></ul><ul><ul><li>Behavioral </li></ul></ul><ul><ul><li>Structural </li></ul></ul><ul><ul><li>Flow </li></ul></ul><ul><li>Explicit allocation of activities to swim lanes (e.g. activity partitions) </li></ul><ul><li>Graphical and/or tabular representations </li></ul>
  100. 100. Different Allocation Representations (Tabular Representation Not Shown) Explicit Allocation of Activity to Swim Lane Allocate Relationship Callout Notation Compartment Notation
  101. 101. Requirements
  102. 102. Requirements <ul><li>Requirements represents a text based requirement </li></ul><ul><ul><li>Minimal properties specified for id and text based on user feedback </li></ul></ul><ul><ul><li>Stereotype mechanism used to categorize requirements (e.g. functional, physical) </li></ul></ul><ul><ul><ul><li>Able to specify constraints on what design elements can satisfy the requirement (refer to Appendix C.2) </li></ul></ul></ul><ul><ul><li>Stereotype of class (abstract) without instances </li></ul></ul><ul><li>Requirements containment used to specify requirements hierarchy as a collection of requirements (e.g., a specification) </li></ul><ul><ul><ul><li>SST uses cross hairs notation vs black diamond composition to be consistent with containment semantics </li></ul></ul></ul><ul><li>Requirements relationships based on subclasses of dependency </li></ul><ul><ul><li>Derive, Satisfy, Verify, Refine, .. </li></ul></ul>
  103. 103. Dependencies <ul><li>Used to specify relationships among requirements (other uses as well) </li></ul><ul><ul><li>Different concept for SE’s with arrow direction reversed from typical requirements flow-down </li></ul></ul><ul><ul><ul><li>Refer to next slide </li></ul></ul></ul><ul><li>Represents a relationship between client and supplier elements </li></ul><ul><ul><li>Client depends on supplier </li></ul></ul><ul><ul><ul><li>A change in supplier results in a change in client </li></ul></ul></ul><ul><ul><ul><li>Application to requirements: A change in requirement (supplier) results in a change in design element that satisfies it (client) or requirement derived from it (client) </li></ul></ul></ul>Dependency Relationship Is New Concept for Some SE’s
  104. 104. Example of Derive/Satisfy Requirement Dependencies Client Supplier Client Supplier Arrow Direction Opposite Typical Requirements Flow-Down
  105. 105. Requirements & Allocations Alignment <ul><li>V0.9 Issue </li></ul><ul><ul><li>Inconsistent concrete syntax for cross-cutting relationships </li></ul></ul><ul><ul><ul><li>Allocations used compartments/callouts, requirements did not </li></ul></ul></ul><ul><ul><li>Limitations in displaying requirement relationships </li></ul></ul><ul><ul><ul><li>Requirements needed to be shown on same diagram as target of relationship –> cluttered diagrams </li></ul></ul></ul><ul><ul><ul><li>Requirements couldn’t be shown on internal block diagrams. </li></ul></ul></ul><ul><ul><li>Basis for cross-cutting relationships seemed inconsistent, and needed to be unified </li></ul></ul><ul><ul><ul><li>Requirements relationships were built on Trace </li></ul></ul></ul><ul><ul><ul><li>Allocation relationship was built on Usage </li></ul></ul></ul>
  106. 106. Representing Requirements and Allocation Relationships Consistent and Compact Crosscutting Notations Allocations callout notation Requirements callout notation
  107. 107. Profiles & Model Libraries
  108. 108. Stereotypes & Model Libraries <ul><li>Mechanisms for further customizing SysML </li></ul><ul><li>Profiles </li></ul><ul><ul><li>Use of stereotype to extend meta-classes with properties and constraints </li></ul></ul><ul><ul><ul><li>Stereotype properties capture metadata about the model element that is not instantiated </li></ul></ul></ul><ul><ul><li>Profile is applied to user model </li></ul></ul><ul><ul><li>Profile can also restrict the subset of the model that is applied </li></ul></ul><ul><li>Model Libraries represent reusable libraries of model elements </li></ul>
  109. 109. Stereotypes Defining the Stereotype Applying the Stereotype
  110. 110. Appendixes
  111. 111. Appendixes <ul><li>Diagrams </li></ul><ul><li>Sample Problem </li></ul><ul><li>Non-Normative Extensions </li></ul><ul><li>Model Interchange </li></ul><ul><li>Requirements Traceability </li></ul><ul><li>Terms and Definitions </li></ul><ul><li>BNF Diagram Syntax Definitions </li></ul>
  112. 112. Appendix A Diagrams
  113. 113. Diagram Appendix A <ul><li>Provides general guidelines for the use of diagrams </li></ul><ul><ul><li>Diagram headings </li></ul></ul><ul><ul><ul><li>Naming of diagrams </li></ul></ul></ul><ul><ul><li>Diagram descriptions </li></ul></ul><ul><ul><ul><li>Capturing information about diagrams </li></ul></ul></ul><ul><ul><li>Diagram usages </li></ul></ul><ul><ul><ul><li>Specifying unique diagram kinds </li></ul></ul></ul><ul><ul><li>Other general guidelines (e.g. tabular representations, use of rake symbol, ..) </li></ul></ul>
  114. 114. Application of Diagram Guidelines Example A Diagram Description (refer to App A) Diagram Heading Names (refer to App A)
  115. 115. Appendix B Sample Problem
  116. 116. Sample Problem Appendix B <ul><li>Highlights selected features of SysML using a Hybrid SUV example </li></ul><ul><li>Refer to sample problem in later slides </li></ul>
  117. 117. Appendix C Non-Normative Extensions
  118. 118. Non-Normative Extensions Appendix C <ul><li>Provides set of non-normative extensions that may become normative in future revisions </li></ul><ul><ul><li>EFFBD profile </li></ul></ul><ul><ul><li>Requirements categories </li></ul></ul><ul><ul><li>Measures of effectiveness (moe) and objective function </li></ul></ul>
  119. 119. Appendix D Model Interchange
  120. 120. Model Interchange Appendix D <ul><li>SysML Model Interchange Standards </li></ul><ul><ul><li>XMI </li></ul></ul><ul><ul><li>AP233 </li></ul></ul><ul><li>XMI is the means for model exchange between SysML conformant tools </li></ul><ul><ul><li>SysML Profile metamodel defined in XMI 2.1 </li></ul></ul><ul><ul><ul><li>To be provided when XMI issues are sufficiently resolved in ballot 12 (TBD) </li></ul></ul></ul><ul><li>Model interchange with non-MOF/UML tools supported using ISO-10303 AP233 </li></ul><ul><ul><li>Both file and API-based SysML-AP233 interchange approaches are supported based on alignment with similar concepts in AP233 </li></ul></ul><ul><ul><li>Provides gateway to model repositories that are based on schema in use by </li></ul></ul><ul><ul><ul><li>other engineering disciplines (e.g, mechanical - MCAD) </li></ul></ul></ul><ul><ul><ul><li>user domains (e.g, DoD architectures – DoDAF/CADM) </li></ul></ul></ul><ul><ul><li>Supports INCOSE’s vision for model driven systems engineering </li></ul></ul>
  121. 121. Appendix E Requirements Traceability Matrix
  122. 122. Requirements Traceability Appendix E <ul><li>Provides traceability from SysML to requirements in UML for SE RFP </li></ul><ul><li>Section 6.2.1, of the RFP states &quot;Submitters may provide partial responses to these requirements, along with a roadmap to address the complete requirements.&quot; </li></ul><ul><li>Most requirements satisfied in v0.9 </li></ul><ul><ul><li>Matrix updated to be consistent with SST v0.98 </li></ul></ul><ul><li>Small number of mandatory requirements in 6.5 deferred to v2.0 </li></ul><ul><ul><li>Modeling of verification ( limited to “test case”. Initial analysis showed “test case” is key element to integrate with UML testing profile </li></ul></ul><ul><ul><li>Modeling of “Problem” (6.5.5) deferred to address causal analysis </li></ul></ul><ul><ul><li>Modeling of “replication” and “resources” under function ( not fully implemented per EFFBD semantics </li></ul></ul>
  123. 123. Appendix F Terms and Definitions
  124. 124. Terms & Definitions Appendix F <ul><li>Consists of a superset of terms from </li></ul><ul><ul><li>UML for SE RFP </li></ul></ul><ul><ul><li>UML 2 </li></ul></ul><ul><ul><li>SysML v0.9 </li></ul></ul><ul><ul><li>SysML v0.98 </li></ul></ul><ul><li>Will provide distilled list to support tool vendor implementation and user glossary </li></ul><ul><ul><li>Reuse terms & definitions as-is </li></ul></ul><ul><ul><li>Refine others to be consistent with chapters </li></ul></ul><ul><ul><li>Delete others </li></ul></ul>
  125. 125. Appendix G BNF Diagram Syntax Definitions
  126. 126. BNF Diagram Syntax Definitions App G <ul><li>A formalism provided by Deere & Company (R. Burkhart) to support a more precise mapping between the language abstract syntax / semantics and the concrete syntax (notation) </li></ul><ul><li>Initial input provided for Model Elements, Blocks, and Constraint Blocks chapters </li></ul><ul><ul><li>Provided valuable mechanism to define more complete diagram syntax tables </li></ul></ul><ul><li>Will be considered for broader application in future revisions </li></ul>
  127. 127. HSUV Sample Problem SST Appendix B
  128. 128. Sample Problem Examples <ul><li>The following examples are extracted from Appendix B of the SST Specification </li></ul><ul><ul><li>Highlights selected features of SysML </li></ul></ul><ul><ul><li>Modeling artifacts from typical SE process </li></ul></ul><ul><ul><ul><li>Slide ordering does not represent process sequence </li></ul></ul></ul><ul><ul><li>Visio used as a vendor neutral format </li></ul></ul><ul><li>Refer to Appendix B for a more complete description of the sample problem </li></ul><ul><li>Contact the vendor reps on SST to see their SysML implementations and sample problem demo </li></ul>
  129. 129. Sample Problem Coverage <ul><li>Organizing the model </li></ul><ul><li>Requirements </li></ul><ul><li>Behavior </li></ul><ul><li>Structure </li></ul><ul><li>Allocating behavior to structure </li></ul><ul><li>Analyzing performance & MOE’s </li></ul>
  130. 130. Setting up the User Model
  131. 131. Organizing the User Model
  132. 132. Setting the Context
  133. 133. Top Level Use Cases
  134. 134. Operational Use Cases
  135. 135. Black Box Interaction (Drive)
  136. 136. Operational States (Drive)
  137. 137. Black Box Sequence (StartVehicle)
  138. 138. White Box Sequence (StartVehicle)
  139. 139. Requirements Breakdown
  140. 140. Requirements Derivation
  141. 141. Reqts Refinement/Verification
  142. 142. Requirements Tables & Trees
  143. 143. Context/Enterprise Breakdown
  144. 144. System Breakdown
  145. 145. System Internal Block Diagram
  146. 146. Power Subsystem Breakdown
  147. 147. Power Subsystem IBD
  148. 148. Test Result Instance
  149. 149. Power Subsystem Interface Defn
  150. 150. Fuel System Definition
  151. 151. Fuel Flow Parametrics
  152. 152. Fuel Subsystem Design
  153. 153. Overall Analysis Context
  154. 154. Performance View Definition
  155. 155. Evaluating Measures of Effectiveness
  156. 156. Evaluating Fuel Economy
  157. 157. Evaluating Vehicle Dynamics
  158. 158. Defining Vehicle Dynamics
  159. 159. Trial Result of Vehicle Dynamics
  160. 160. “ ProvidePower” Functional Decomp
  161. 161. “ ProvidePower” Behavior & Allocation
  162. 162. Multiple Allocations shown on IBD
  163. 163. Allocation Table w/Allocation Type
  164. 164. Distiller Example David Oliver 12/7/05 An example to raise questions
  165. 165. Dave Oliver Preface System View Interconnection <ul><li>In my experience of watching the development of OMT in GE and then UML, it appeared that the many views introduced were not fully interrelated. The view represented facets of reality, yet they did not fully provide the interconnections that exist in reality. </li></ul><ul><li>This example is presented to help ask similar questions about SysML for the current review. Consider an activity model for distilling dirty water. A crude EFFBD is shown. </li></ul>
  166. 166. Distiller Example (as provided by D. Oliver) Dirty water @ 20 deg C Heat Dirty water To 100 deg C Heat to Dirty water Boil Dirty water Dirty water @ 100 deg C Steam Residue and Condense steam Drain Residue Pure water Disposed residue Heat to Boil water Energy to condense The ovals in the figure are I/O in AP233, items in CORE and I believe object nodes in the submissions. and
  167. 167. <ul><li>Q1: what is the list entities in the submission can be object nodes? </li></ul><ul><li>Q2: would the water, steam, etc be Blocks? </li></ul><ul><li>Q3: How would heat be represented? </li></ul><ul><li>The water has properties: vol = 1 liter, density 1 gm/cm3, temp 20 deg C, specific heat 1cal/gm deg C, heat of vaporization 540 cal/gm. </li></ul><ul><li>Q4: do the submissions allow the application of parametrics to the object nodes to calculate the heat required to heat the water, boil the water, and condense the water? </li></ul>Questions
  168. 168. <ul><li>The questions above relate only to the activity diagram (EFFBD). One does not have a design until the activities are allocated to physical thins, probably Blocks. </li></ul><ul><li>Allocate heat dirty water and condense steam to a block Counter Flow Heat Exchanger </li></ul><ul><li>Allocate boil dirty water to a block Boiler </li></ul><ul><li>Allocate drain residue to a block Drain </li></ul><ul><li>These allocations require that particular interconnections exist among these three blocks. </li></ul><ul><li>Q5: How does the language support or enforce the existence of the required interconnections among blocks? Does the engineer have to build this correctly without language support? </li></ul>Questions (cont.)
  169. 169. <ul><li>These allocations require that the object nodes are identical to the flows or interface specifications (the labels) associated with these interconnections. </li></ul><ul><li>Q6: How does the language support or enforce the identity between the object nodes and the labels associated with the interconnections? Does the engineer have to build this correctly without language support? </li></ul>Questions (cont.)
  170. 170. Response to Dave’s Example Distiller System
  171. 171. Distiller System – Package Overview Organizing the Model
  172. 172. Units Library Defining the Units
  173. 173. Behavior Breakdown Distill Activity Decomposition and Types of Flows
  174. 174. H 2 0 States
  175. 175. Distill Water Activity Diagram (Initial) Representing Distiller Example in SysML Using EFFBD Profile
  176. 176. Distill Water Activity Diagram (Continuous Activity Modeling) Representing Distiller Example in SysML Using Continuous Flow Modeling
  177. 177. Distill Water – Swim Lane Diagram Allocated Behavior Allocating the Activities to Swim Lane that Represent Blocks
  178. 178. Distiller System Hierarchy (Top Level) Describing the Distiller System and Its Components A Diagram Feature Provided by SST Submission (refer to App A)
  179. 179. Distiller Internal Block Diagram Describing the Interconnection of Parts And the Item Flows Between Them
  180. 180. Distiller Internal Block Diagram (with Allocations) Showing the Allocations from Activities and Object Nodes to Blocks and Item Flows
  181. 181. Heat Exchanger Interface Specs Describing the kind of things that can Flow (Fluid, Heat) And Constraints on Flow Ports
  182. 182. Parametric Diagram – Thermal Analysis (includes constraints on I/O) Defining the Thermal Equations as Constraints on the Flow Properties
  183. 183. Analysis Results - Isobaric Analysis Results Indicate Need for Modification to Existing Desgin
  184. 184. Behavior Breakdown - Revised New Activity Required To Meet the Need
  185. 185. Swim Lane Diagram - Revised New Activity Shown in Swim Lane Diagram
  186. 186. Distiller Internal Block Diag - Revised Additional Item Flow Required To Support Change
  187. 187. Parametric Diagram – Thermal Analysis (Revised) Revised Thermal Analysis To Support Change
  188. 188. Analysis Results – Non Isobaric Example Update to Analysis Results
  189. 189. Summary
  190. 190. SST SysML Submission <ul><li>Satisfies Most Requirements in the RFP </li></ul><ul><ul><li>Small number of remaining req’ts to be addressed along with user/vendor feedback in future revisions </li></ul></ul><ul><li>Critical Issues Resolved </li></ul><ul><li>Multi-vendor implementations </li></ul><ul><li>Our solution </li></ul><ul><ul><li>Architecturally sound & compatible with UML 2/ XMI </li></ul></ul><ul><ul><li>Implementable by multiple vendors </li></ul></ul><ul><ul><li>Meets the needs of SE’s </li></ul></ul><ul><li>Refer to Highlights and Comparison Matrix and these slides to contrast with SysML Partners submission </li></ul>