Sys ML Review Sys ML Partners www sysml

Sys. ML™ Review Sys. ML Partners www. sysml. org INCOSE IW Review January 25 -26 January 2004 Sys. ML

Review Objectives n n n Describe Sys. ML approach for customizing UML 2 to satisfy UML for SE RFP requirements Solicit constructive feedback from INCOSE MDSD Obtain INCOSE endorsement of Sys. ML 2

Agenda n (1 of 2) Sunday, January 25 n n n 08: 30 - 09: 00 Introductions and agenda review 09: 00 - 09: 30 Background – Cris & Sandy 09: 30 - 10: 15 UML for SE RFP requirements review – Sandy 10: 15 - 10: 30 Break 10: 30 - 11: 30 AP-233 & INCOSE/MDSD concerns – Dave 11: 30 - 12: 00 Discussion 12: 00 - 13: 00 Lunch 13: 00 - 14: 30 UML 2 “out of the box” – Cris/Conrad 14: 30 - 15: 00 Design Approach & Diagram Taxonomy – Sandy 15: 00 - 15: 15 Break 15: 15 - 17: 30 Activity Diagrams and Comparison with EFFBD – Conrad/Rick 19: 00 Dinner expedition 3

Agenda n (2 of 2) Monday, January 26 n n n n n 09: 00 10: 15 10: 30 11: 15 12: 00 13: 00 14: 00 15: 15 16: 00 n n - 10: 15 10: 30 11: 15 12: 00 13: 00 14: 00 15: 15 16: 00 17: 00 Component Diagram – Roger/Conrad Break Allocation Diagram – Rick Parametric Diagram – Sandy Lunch Requirement Diagram – Laurent/Sandy AP-233 Alignment – Harald/Jim Break AP-233 Alignment Demo – Harald/Jim/Skipper Wrap up round-robin feedback action items next steps 19: 00 Dinner expedition 4

Background

Motivation n n Systems Engineers need a standard language for analyzing, specifying, designing, verifying and validating systems Many different modeling techniques n n Behavior diagrams, IDEF 0, N 2 charts, … Lack broad based standard that supports general purpose systems modeling needs n n n satisfies broad set of modeling requirements (behavior, structure, performance, …) integrates with other disciplines (SW, HW, . . ) scalable adaptable to different SE domains supported by multiple tools 6

Why UML for SE ? UML is already de facto standard within software engineering community n UML is mature and extensible, and can be adapted to support SE requirements n UML tools and training are widely available n OMG standardization process supports UML customization for specific domains (e. g. , systems engineering) n 7

INCOSE/OMG Joint Initiative n OMG Systems Engineering Domain Special Interest Group chartered by INCOSE-OMG initiative in 2001 n n create a semantic bridge between ISO 10303 -233 standard and ISO/IEC 19501 UML standard create UML extended modeling language for specifying, designing, and verifying complex systems using profiles, or other extensibility mechanisms. provide capability for rigorous transfer of specifications and related information among tools used by systems, software and hardware engineers bridge the semantic gap, the professional engineering discipline gap, and the training gap that exists between systems engineering and software engineering 8

SE DSIG Tasks n n n Drafted UML for SE RFI, issued by OMG in 2002 to validate SE usage and limitations Supported development of SE concept model Collaborated with UML 2 submission teams Performed detailed requirements analysis Drafted UML for SE Request for Proposal, issued by the OMG in March 2003 (ad/03 -0341) 9

Sys. ML Partners n Informal partnership of modeling tool users, vendors, etc. n n organized in May 2003 to respond to UML for Systems Engineering RFP Charter n The Sys. ML Partners are collaborating to define a modeling language for systems engineering applications, called Systems Modeling Language™ (Sys. ML™). Sys. ML will customize UML 2 to support the specification, analysis, design, verification and validation of complex systems that may include hardware, software, data, personnel, procedures, and facilities. 10

Sys. ML Partners n Industry n n Do. D/OSD, NASA/JPL, NIST Tool Vendors n n American Systems, Astrium Space, BAE SYSTEMS, Boeing, Deere & Company, Eurostep, Israel Aircraft Industries, Lockheed Martin, Motorola, Northrop Grumman, oose. de, Raytheon, THALES Government n n (cont. ) Artisan, Ceira, Gentleware, IBM/Rational, I-Logix, Pivot. Point Technology, Popkin, Project Technology, 3 SL, Telelogic, Vitech Liaisons n AP-233, CCSDS, EAST, INCOSE, Rosetta 11

Sys. ML Milestones n n n n UML for SE RFP issued – March 28, 2003 Kickoff meeting – May 6, 2003 Overview presentation to OMG ADTF – Oct 27, 2003 Initial draft submitted to OMG – Jan 12, 2004 INCOSE Review – January 25 -26, 2004 Final draft submitted to OMG – TBD OMG technology adoption – H 2 2004 12

Internal Process n Applying systematic approach to language development n n n requirements analysis language architecture & design verification & validation requirements traceability reviews with stakeholders Partnership collaboration mechanisms n n n weekly telecons monthly physical meetings intranet, web site, and mailing lists 13

Requirements Review

UML for SE Request For Proposal Specifies requirements for SE modeling language n Joint requirements reviewed by OMG/INCOSE/AP -233 n Issued by OMG on March 28, 2003 n OMG Doc# ad/03 -03 -41 n http: //syseng. omg. org/UML_for_SE_RFP. htm n 15

Scope of RFP n Focuses on general purpose system modeling n software and hardware intensive systems n system-level vs. hw/sw implementation models (code, 3 D geometry, VHDL, . . . ) n integration with discipline specific models (i. e. , reliability, safety, . . . ) 16

Requirements Summary n Structure n n Behavior n n e. g. , requirements hierarchy, traceability Verification n n e. g. , parametric models, time property Requirements n n e. g. , function-based behavior, state-based behavior Properties n n e. g. , system hierarchy, interconnection e. g. , test cases, verification results Other n e. g. , trade studies, spatial relationships 17

Evaluation Criteria n n n Ease of use Unambiguous Precise Complete Scalable Adaptable to different domains Capable of complete model interchange Evolvable Process and method independent Compliant with UML metamodel Verifiable 18

Requirements Traceability 19

Requirements Traceability (cont. ) 20

Requirements Traceability (cont. ) 21

AP-233 & INCOSE/MDSD Concerns

UML 2 “Out of the Box”

UML 2 “Out of the Box” n UML 2 provides many of the features that SEs require without modification n Composite Structure diagrams Activity diagrams However, UML 2 provides too many features (i. e. , suffers from “featuritis”) n Sys. ML subtracts gratuitous features to make room for needed new features 24

Sys. ML Compliance with UML 2 n Sys. ML reuses n n UML 2 Basic (Level 1): all packages UML 2 Intermediate (Level 2): most packages UML 2 Complete (Level 3): few packages See Sys. ML, Chapter 2: Compliance for details 25

UML 2 Examples n n n Include notations for new UML 2 constructs and diagrams Show what UML 2 can do for Systems Engineers “out of the box” References n [Kobryn 2003 a], [UML 2 2003] 26

Structure Diagram Example 27

Composite Structure Diagram Example 28

Sequence Diagram: References 29

Referenced Sequence Diagram 30

Order Department Acctg Department Fill Order Receive Order Ship Order Close Order [order accepted] Send Invoice Accept Payment Invoice Customer <> <> performing. Dept: Department Activity Diagrams: Hierarchical Partitions Make Payment 31

Design Approach

Design Principles n Reuse and extension n n Incremental development n n n select the subset of UML 2. 0 that is reusable for SE applications add new constructs and diagrams needed for SE UML 2++-extend the language incrementally, using SE feedback to ensure new extensions are valid prevent scope and schedule creep Architectural alignment n align with evolving AP-233 SE Data Interchange Standard 33

Language Architecture Top Level 34

UML 2 Superstructure Architecture 35

Sys. ML Language Architecture 36

Architectural Alignment 37

Extension Mechanisms n Metamodeling n n n Stereotypes n n n Subtyping the UML metamodel Adding associations and attributes Similar effect to subtyping the metamodel, but does not modify the repository schema Cannot add new associations Model libraries n Like any other user model, except that they are standardized and available to be imported by any user Profile = Stereotypes + Model Libraries + selective import of UML metamodel. 38

Major Extensions to UML 2 n Composite Structure Diagram n n integrate and extend Information Items and Information Flows to include physical flows include Deployment relationship distinguish clearly between Component and Collaboration diagram Activity Diagram n n n extensions for continuous flow modeling extensions to support disabling control and control operators. accommodate needs of Extended Functional Flow Block Diagrams (EFFBDs) 39

Major Extensions to UML 2 (cont. ) n New Diagram Types n n n Requirement Diagram Parametric Diagram Usages (for best practices) n n Concept Diagram (Class Diagram) Context Diagram (Structured Class Diagram) 40

Other Extensions Under Consideration n Other new diagram types and usages n n n Verification Decision Tree Causal Analysis Specialize Aggregation (Assembly aggregation) Add communications between objects and states to State Machine diagrams Allocation of behavior to structure 41

Underlying Semantic Model n UML 2 provides the underlying semantics that Sys. ML builds upon n n Methodology can enforce additional constraints to support further integration n n Semantic consistency defined by UML 2 Sys. ML is intended to support multiple methodologies Tool vendors can implement constraints to enforce the methodology 42

Diagram Taxonomy

Models, Views, and Diagrams n A model provides a description of the domain of interest to support the specification, design, analysis, and verification of a system. n n n composed of model elements, such as components, attributes, relationships, activities, state machines A model view specifies a projection of a model from the perspective of a set of stakeholders, and omits entities that not relevant to this perspective Model views can be represented by diagrams, tables, etc. n multiple diagram types may be used to represent a model view 44

UML 2 Diagram Taxonomy 45

Sys. ML Diagrams n Changes to UML 2 diagrams n new diagrams extensions and new usages of existing diagrams some UML 2 diagrams not used 46

Sys. ML Diagram Taxonomy 47

Diagram Frames Diagram Description Diagram Frame Header Date/Version: Purpose Completeness: Reference info: ? diagram. Type: frame. Name Contents External Connection under investigation 48

Model Element Reference Data n n n Model Elements can include reference data n version n text description n reference links n … Represented by a UML comment May include a version relationship between model element versions to support CM 49

Alternative Diagram Representations n Alternative representations of the abstract syntax n n n graphical tabular (optional) tree (optional) 50

Activity Diagram & Comparison With EFFBD

Activity Modeling n n n Activity modeling emphasizes the sequence, inputs and outputs, and conditions for coordinating other behaviors (functions) Secondary constructs show which classifiers are responsible for those behaviors. Focuses on what tasks need to be done, in what order, with what inputs, rather than what performs each task 52

Activity Modeling n Tasks and ordering … Receive Order Fill Order Close Order Ship Order [order accepted] Send Invoice Make Payment Accept Payment 53

Activity Modeling Acctg Department Customer Order Department «attribute» performing. Dept: Department» «external» n … plus component allocations (optional) Receive Order Fill Order Ship Order Close Order [order accepted] Accept Payment Send Invoice Make Payment 54

UML 2 Activities n First-class behavior model: n n Full parallelism n n concurrent branches operate independently. Input/output n n usable with or without objects parameterized behavior properties queuing, storage notation multi-entry/exit Full action model execution and simulation. 55

Activity Usage n n Activity is the a generic, reusable description of behavior Used in n n other activities (decomposition through actions) state machines n n Classes, Sequence Diagrams n n Transition activity Entry/Exit activity on states Do activity on states Methods for operations Actions, states, and operations can reference the same activity n not envisioned to be standard practice 56

Activity Usage Activity entry exit do. Activity invocation method +effect State X Class 2 Action 1 Activity X 1 Transition Activity T 1 Class 1 Op 2. 1 (msg: type) Class 1 State Y Activity Y 1 Activity Y 2 Action 2 Class States Activities 57

Functional Hierarchy F 0 F 1 F 2 F 1. 1 F 1. 2 F 2 Activity Function Hierarchy (UML extension) 58

Actions versus Activities F 0 F 1 F 0 Activity Action F 1 F 2 F 1 n Actions are usages of activities n The same activity can be used twice in the same diagram, by two different actions. 59

Relation Between Models n The models emphasize different aspects of behavior n n Activities: inputs, outputs, control States machines: reaction to events Operations: services of classes. Translation of activity and state models to sequence models n n Actions specify when messages are sent. Timing diagrams can be generated from model execution. 60

Sys. ML Activity Extensions n Control as Data n n n Continuous Systems n n n Additional control values: disabling. Control operators Flow rate Updating stale data Function patterns Probabilities Other extensions for EFFBD “profile” 61

Control as Data Enable on Brake Pressure > 0 « Control. Operator» [Brake Pressure > 0] « Value. Action» Enable Control. Value Brake Pressure « Value. Action» Disable [else] n Emits enabling or disabling control value based on input. 62

Control as Data Driving n Brake Pressure « Control. Operator» Enable on Brake Pressure > 0 Monitor Traction Brake Pressure determines when traction is monitored in ABS sytem. 63

Continuous Systems Monitor Traction « run. To. Disable» « run. To. Completion» Calculate Traction Index {rate = per 10 ms} Angular Velocity Input from Accelerometer n n Modulation Frequency {rate = continuous] {is. Overwrite} Input from optical sensor on wheel n [loss of of traction] « run. To. Completion » Calculate Modulation {rate = Frequency continuous, burst} Acceleration Flows rates on edges and parameters Overwriting stale data run. To. Complete, run. To. Disable 64

Continuous Systems Driver « interruptible. Region» Turn Key On « run. To. Disable» Driving {rate= continuous} Key off {stream } Brake System Brake Pressure {stream } « run. To. Disable» Braking « Control. Operator» « run. To. Completion» Enable on Brake Pressure > 0 {stream } ABS Modulation Frequency {rate = continuous, burst} {stream } « run. To. Disable» Monitor Traction 65

Probabilities n Flows from decisions nodes. n n n Can refer to root of decision tree. Parameter sets (= EFFBD multi-exit functions) Properties and parameters n n Over a single instance or execution over time or over all instances of a class and or executions of a behavior. 66

Extensions for EFFBD n n Postconditions on parameter sets (for completion conditions on multi-exit functions) Control parameters (for multi-exit functions that output control). Control pins (for control queuing) TBD: Replication 67

Extended Functional Flow Block COMPLETION CRITERION IN FUNCTION 2 2. 4 cc#1 Function in Multi-exit Construct 2. 2 DATA FLOW (TRIGGERING) Multi-exit Function OR Item 2 Item 1 3 times DATA FLOW (NON TRIGGERING) 2. 5 FUNCTION cc#2 IT Function in Iterate IT Item 3 1 Source of External Input 2. 1 Serial Function 2. 6 AND CONCURRENCY 2. 3 External Input 3 Output Function Sink of External Input Item 4 Function in Concurrency Adapted from Long, J. , "Relationships between Common Graphical Representations in System Engineering", Vi. Tech Corporation, www. vitechcorp. com External Output 68

EFFBD UML OBJECT NODE (PIN) Item 1 PARAMETER SET 2. 2 Multi-exit Function 2. 4 Function in Multi-exit Construct {optional} MERGE GUARD OBJECT FLOW [ before third time ] Item 2 External Input 2. 1 Serial Function {optional} 2. 5 Function in an Iterate FORK External Output [ after third time ] Item 3 {optional} DECISION ACTIVITY PARAMETER INVOCATION ACTION CONTROL FLOW 2. 3 Function in Concurrency 2. 6 Output Function JOIN {optional} Item 4 From Bock, C. , "UML 2 Activity Model Support for Systems Engineering Functional Flow Diagrams, " Journal of INCOSE Systems Engineering, vol. 6, no. 4, October 2003. 69

Function Behavior/Action n EFFBD Function and UML 2 Action/Behaviors are steps in a process flow. (EFFBD) (UML 2) # Move Elevator § Notation is different, but repository would be the same (except for adding #). 70

Control Flow n EFFBD and UML 2 Control Flow give time sequence to steps in a process flow. # # (EFFBD) Close Doors Move Elevator (UML 2) Close Doors Move Elevator 71

Data/Object (Item) Flow n EFFBD and UML 2 Data Flow specify how Function/Behavior outputs are provided to inputs. (EFFBD) # # Accept Input (UML 2) Floor Number Move Elevator 72

External I/O Parameter n EFFBD External Input/Output and UML 2 Parameter support I/O at the beginning/end of the entire diagram. (EFFBD) Floor Number # Move Elevator (UML 2) 73

Select Decision n EFFBD Select and UML 2 Decision specify mutually exclusive paths in a flow. branch annotation (EFFBD) OR OR branch annotation [guard] (UML 2) [guard] 74

Concurrency Fork/Join n EFFBD Concurrency and UML 2 Fork/Join specify parallel paths (EFFBD) AND (UML 2) 75

Multi-exit Parameter Sets n EFFBD multi-exit functions and UML 2 Parameter Sets specify mutually exclusive outputs. (EFFBD) # completion condition (UML 2) TBD: Postcondition on parameter set 76

Cycles n EFFBD and UML 2 flows can have cycles in the flow graph. loop annotation (EFFBD) LP LP # [guard] [else] (UML 2) 77

Other EFFBD UML n Triggering Item Input Non-streaming, mandatory parameter n Nontriggering Input Optional Parameter n Implicit fork in item flows Explicit fork 78

Action Execution Rules n Before execution n n During execution n n n an action waits for all mandatory, non-streaming data/item inputs, in whatever quantity is required, and waits for all control inputs required, then begins. data/objects/items arriving at non-streaming inputs while the action is executing are queued. actions support concurrent execution of queued inputs (reentrancy). This should be compared to replication. data/objects/items arriving at streaming inputs are input to the action execution. control arriving is queued if control pins are used, otherwise, control values arriving at an action already executing are discarded. (except run. To. Disable actions respond to disable control value) an action can provide streaming outputs. After execution n an action provides all mandatory, non-streaming data/item outputs, in whatever quantity is required, and all control outputs required. 79

EFFBD Profile n n n All actions require at least one control edge coming into them. All forks have a corresponding join. The EFFBD OR notation is inclusive (though implementations are exclusive). It translates to a UML fork. Function usages are numbered. Iteration indicators on decision nodes. Others TBD. 80

Component Diagram

Component Diagram - Example Vehicle abs : ABSBrake. System av : Speed. Sensor wheel. Assy : Wheel. Assembly : Electronic wheel : Wheel : Electronic : Mechanical Frequency. Port : Mechanical ecu : Electronic Control Unit tire : Tire : Electronic Position. Signal. Port mv : Modulator. Valve : Hydraulic wh. Cyl : Wheel. Cylinder Mechanical Hydraulic. Out. Port Hydraulic. In. Port Vertical. Load. Port mc : Master. Cylinder Hydraulic. In. Port 82

Composition in Class Diagrams n Class diagrams model part-whole … Boat Car 0. . 1 1. . 4 1 0. . 1 4 1 Engine Propeller 1 4. . 8 Piston Shared/reused classes (instances not shared) Wheel 1 1 Crankshaft Hierarchical decomposition 83

Composition in Class Diagrams n … but not part-part. Associations are global and independent of each other Boat Car 0. . 1 1. . 4 1 powers 1 Propellers on cars powers Engine Propeller 1 0. . 1 1 Power to wheels on other people’s cars. (not legal UML anyway because associations cannot target two classes) Wheel 2 Power to which two wheels? Wheels on boats 84

Composition in Components n UML 2 supports part-part in context: Car front : Wheel 2 e : Engine : powers 1 Engine as used in Car Powers as used in Car Boat e : Engine as used in Boat back : Wheel 2 1 : powers : Propeller 1 Powers as used 85 in Boat

Composition in Both Diagrams Car 0. . 1 Class Diagram 1 0. . 1 back e powers Engine 1 2 2 front Wheel 2 Car Component Diagram front : Wheel 2 e: Engine n 1 : powers back : Wheel 2 UML terminology: Parts = Association Ends, like “parts” in a play, rather than objects. 86

Composition in Instance Diagrams VIN#123 : Car Serial#345 : Engine back front e powers Serial#567 : Wheel n n back front Serial#789 : Wheel n Serial#890 : Wheel Serial#901 : Wheel Power goes to the correct wheels … … in the same car as the engine … … and not to propellers. 87

Composition in Instance Diagrams VIN#123 : Car Serial#345 : Engine / : powers Serial#567 / front : Wheel Serial#789 / front : Wheel Serial#890 / back : Wheel Serial#901 / front : Wheel n Equivalent to previous slide 88

Composition Improves Factoring n Reusable, refinable structure: Boat Vehicle Car powers Power. Source Power. Transmitter 1 Engine 1. . * Wheel Propeller Global structure inherited by each kind of Vehicle … … and constrained for each 89 kind

Item flow in Components Vehicle abs : ABSBrake. System wheel. Assy : Wheel. Assembly : Electronic av : Speed. Sensor wheel : Wheel Voltage : Electronic : Mechanical Frequency. Port : Mechanical ecu : Electronic Control Unit tire : Tire : Electronic Position. Signal. Port : Hydraulic mv : Modulator. Valve Hydraulic. Out. Port Oil Hydraulic. In. Port wh. Cyl : Wheel. Cylinder Mechanical Vertical. Load. Port mc : Master. Cylinder Hydraulic. In. Port 90

Interface Specification 91

Allocation

Uses of “Allocation” Usage Relationship From To 1. Requirement Allocation specifies UML: : trace (? ) assigned Element (model) Requirement Element (component, function, parameter) 2. Behavioral Allocation allocated. To (? ) or UML: : owned. Behavior Function (activity), or State Component 3. Logical Allocation allocated. To (? ) Component, I/O (logical) Component, I/O (physical) 4. SW deployment onto HW UML: : deployment? (software) Artifact? (hardware) Node? 5. “Operational” Allocation (method specification) UML: : method/specific ation Function (activity) Operation 6. Parametric Decomposition/ Allocation ? Parameter 7. Property Allocation ? Property Component, I/O 93

Behavioral Allocation: A Definition Allocation is the unique association of elements of behavior (activities, states, operations, messages, object flow) with elements of physical structure (hardware, software, networks; expressed as classes, components, ports, and connectors) As used in the OMG UML for SE RFP: 6. 5. 2. 5 Allocation of behavior to systems UML for SE shall provide the capability to model the allocation of behavior to systems and external systems as follows: a. Allocate function and states to systems b. Allocate inputs and outputs (including control inputs) to ports I/O may be more appropriately allocated to connectors, rather than ports (depending on type of flow) 94

Behavioral Allocation w/UML Allocation -> Binding: can be early, late, or implicit n Implicit Allocation n n Explicit Allocation n n Behavior built directly on top of physical structure Behavior built separately from physical structure, subsequently and explicitly linked thereto Additional Structure (extra “non-physical” structure to aid in implicit or explicit allocation) n n Use of non-physical structure as mechanism for organizing behavior and linking to physical structure, or Use of packages to organize behavior and link to physical structure 95

Sys. ML Diagram Types & Behavioral Allocation n “Pure” Behavioral Diagrams n n Activity Diagram (w/o Swimlanes) (AD)* State Machine Diagram (SMD) Use Case Diagram (UCD) n Hybrid Diagrams n n n Structural Diagrams n n Class Diagram Component Diagram Composite Structure Diagram** Deployment Diagram Activity Diagram (with Swimlanes) (SLD)* (explicit allocation) Interaction Diagrams (implicit allocation) n n Sequence Diagram (SD) Communication Diagram (Comm. D)** Timing Diagram (TD)** Interaction Overview Diagram** UML 2 “Collaboration Diagrams” (Use Case Realization) * Modified from UML 1. x ** New for UML 2. 0 96

Pure Behavior = Implementation Free n Activity Diagram without Swimlanes: n State Machine Diagram: n State “of what”? n n Usually, of a real world element, represented by a class… this implies allocation! Can get around this by making this the state “of the enterprise” or “of the system” Can use abstract classes to represent logical architecture States & Activities are hierarchical (nested) 97

1. Implicit Allocation - “Tight” Binding n n n Relies on logical or physical structure as starting point Adds behavioral aspects (operations, states) to structure (classes, components) Approaches 1. Operations in Classes n n Populated via Interaction Diagrams (Sequence & Communication Diagrams) Can provide only incomplete specification of behavior n 2. Operations, messages, but not actions or activities States of Classes n n Populated via State Machine Diagrams Can provide complete specification of behavior n n Rigorous behavior notation State Machine Overview (Proposed in Sys. ML) showing distribution of concurrent states across physical elements 98

Implicit Allocation – Interaction Diagrams Interaction Diagram implicitly allocates function to form using messages Procedure Call “tightly” binds function to form, provides formalism Message Procedure Call Sequence Diagram Building this diagram populates procedure in target class Communication Diagram (UML 2) 99

Implicit Allocation State Machine Diagram (Sys. ML) Power. Train Braking. System disengage Power. Train Engaged Idle release Power Train Disengaged • Engine states allocated to engine component Brakes Applied Apply Hydraulic Force engage tm(b. Time)/ expected. Pressure = calc. EP Engine push Monitor Hydraulic Force tm(m. TIme)/ get. Braking. Pressure(); if (braking. Pressure < expected) { the. PT->GEN(disengage); the. Engine->GEN(disengage Engine) GEN(Failed) } Failed Out of Gas Brakes Failed Engine off Ignition Off Ignition on/ enable Starter, open. Gas. Lines Engine Operating Disengage engine Engine engaged Engine Starting do/ run. Starter Engine unengaged Engage engine entry/ prime Carbourator do/ provide. Torque, provide. Current exit/ remove. Current, Clear. Carbourator 100

2. Explicit Allocation – “Flexible” Binding n Relies on pure behavioral representation as starting point n n n Explicitly maps behavioral elements to physical structure n n Hierarchical (activity diagrams, state charts) Provides complete representation of behavior (rigor) Mapping is separate from both behavior and structure Approaches n n Activity model segregated into Swim Lanes NEW DIAGRAM/Table showing behavioral elements, structural elements, and NEW <> relationship 101

Explicit Allocation – Activity Diagram w/Swimlanes n Swimlane Diagram (Activity Diagram w/Swimlanes)provides “loose”, flexible, reversible binding function to form n n easily manipulated, reconfigured, traded off UML 2 Spec supports associating Behavior (e. g. Activity) with Behaviored. Classifier (e. g. Component) and Behavioral. Feature (e. g. Operation) n n n Activity changes to Operation upon invocation – what does that mean to SE? How to do this in a usage-independent way to preserve reuse? I’ve not seen an example that fully illustrates this yet… 102

3. Use of Additional Structure/Layer/View Approaches: 1. Logical Architecture (separate structure of Logical components) 1. 2. 3. 4. 2. Operations in Logical components reused in Physical components (Balmelli) Tags or marks on Logical components that indicate allocation to Physical components (Mellor) Use packages to represent logical decomposition (Cantor) NEW DIAGRAM/Table showing Logical components, Physical components, and NEW <> relationship Locality (Cantor): Additional layer of structure to support physical properties 103

What is Logical Architecture? n n n Expressed as Structure (form), not Behavior (function) “Implementation Free” – not physical or configuration items Groups of behavior/function in manageable chunks n n Intuitive look at what the system does, without burden of describing rigorous behavior n n n Pre-package functions for allocation to physical architecture Provides top-level information flow, without detailed scenarios Granularity of logical arch. must eventually be finer than physical arch. to achieve unambiguous allocation Not necessarily executable, or even computable Frequent starting place for abstract system specification Often, basis for system level data engineering 104

What is Physical Structure? n n This is what is actually built, implementation specific (with implementation constraints). Hierarchy of physical elements and interconnections n n Includes specific hardware and software interfaces Generally, SE “stops” at specification of physical element, where further design/acquisition may be reliably accomplished by design engineering. n n For this purpose, software is physical Further detail then added by HW/SW designers, not just by systems engineers 105

Tracing Logical to Physical Architecture n n n Balmelli – build logical interactions first, then ensure physical interactions use same operations Mellor – use tags to generate a separate physical model from the logical model Steiner - build new diagram, new association (below) 106

UML: : owned. Behavior n Implication: n n n Activities may become owned behaviors of Classes Potential allocation mechanism Nomenclature: n n Activity equates to SE Function Action equates to SE Function. Use 107

Direct Behavioral Allocation 108

Functional – Logical – Physical Allocation 109

Allocation Summary n Need to complete mapping of “allocation use” table to concrete syntax n n Relation of Allocation and Deployment needs to be codified n n Issues of convention and notation to be resolved. Logical to physical, software to hardware Considering generalized operations 110

Parametric Diagram

UML for SE RFP Requirements 6. 5. 3. 5 Parametric model UML for SE shall provide the capability to model the following: a. Properties and their relationships, which represent an arbitrarily complex mathematical or logical expression or constraint, between properties b. The corresponding mathematical and logical expressions and constraints, which specify the allowable range of values for the properties c. A reference to the language used to state the expressions and constraints Note 1: This can include differential equations, logical expressions such as {when Y=7 or X<1}, or other constraints such as {Y< 3 x+7}, expressed in a specific language, such as Math. ML or a programming language. Note 2: Parametric models are generally captured in analysis models to support feedback and control, performance models, and engineering models for reliability, safety, mass properties, design to cost, etc. 112

Influences n Russell Peak (Georgia Tech) – Constrained Objects n n Georgia Institute of Technology response to the UML for Systems Engineering RFI syseng/02 -06 -06 Jacob Axellson (Volvo) – Invariants n n Volvo Car Corporation response to the UML for Systems Engineering RFI syseng/02 -05 -06 “Model-based Systems Engineering Using a Continuous-Time Extension of UML, ” Jacob Axellson, INCOSE Journal Volume 5, Number 3 May through June 2002 113

Parametric Relations n Used to express relations between quantifiable properties of composite structures n n n Specification n n Reusable Non-causal (optionally) Expression: text string in a … Language (e. g. Math. ML, OCL …) Parameters identify interface to relation May be defined in terms of other relations Usage n n Used in the context of a Sys. ML component Pins bind properties of parts to parameters of relation 114

Treatment of Time n n n Ultimately, time is a property of a Continuous and/or Discrete Clock Time may be implicit or explicit, depending on need Any property may have a time dependence and used in a parametric relationship car. distance : real s=½at 2 a : real car. acceleration : real t : real car. time : real 115

Parametric Metamodel For Specifying Parametric Relationships Literal example = Pin. Variable (Pin) is a usage of a parameter 116

Parametric Relationship - Example n n n Frame corresponds to parametric relation Pins on frame correspond to parameters May use other parametric relations in its specification 117

Repository Instances for M=D*V: Parametric. Relation owned. Parameter m: PR-Parameter owned. VBinding V v: PR-Parameter bound. Element : Variable. Binding owned. VBinding bound. Pin : Variable. Binding : Pin. Variable owned. Usage d: PR-Parameter bound. Element owned. VBinding : Variable. Binding owned. Pin = : PR-Usage bound. Pin : Pin. Variable bound. Element : Variable. Binding bound. Pin : Pin. Variable owned. Pin * : PR-Usage owned. Pin relation =: Parametric. Relation owned. Parameter owned. Usage *: Parametric. Relation parameter l : PR-Parameter r parameter owned. Parameter p: PR-Parameter 118

Parametric Metamodel n Components and classes can use parametric relations to express constraints on their properties and those of their parts. Sys. ML: : Class UML: : Element n 0. . 1 1 * owned. Usage PR-Usage 0. . * owned. VBinding Variable. Binding owned. PBinding * Property. Binding 0. . 1 * 1 Pin. Variable bound. Pin * 1 property 0. . * path Sys. ML: : Property Bindings bind the pins of the usage to properties 119

Parametric Example - Usage 120

Repository Model for Range Cannon: Property F=M*A: Parametric. Relation owned. Attribute path relation owned. Pin F: Pin. Variable bound. Pin : Property. Binding property Force: Property : PR-Evaluation owned. Pin A: Pin. Variable owned. Pin bound. Pin property : Property. Binding Acceleration : Property owned. Evaluation M: Pin. Variable bound. Pin path : Variable. Binding owned. Attribute range: Class bound. Pin M: Pin. Variable owned. Pin : PR-Evaluation path Shot: Property path owned. Evaluation owned. Pin V: Pin. Variable bound. Pin : Property. Binding property Volume: Property owned. Pin relation M=D*V: Parametric. Relation D: Pin. Variable bound. Pin : Property. Binding property Density: Property 121

Semantics n n n Properties and Literals provide Values, which can be collections (i. e. vector or set of values) Pins reference (share) those Values Bindings dictate which Values are shared Instances of PR-Evaluations are nested according to structure of their Parametric Relations Sys. ML relies on external languages (ie. Math. ML, OCL, . . . ) for interpreting the parametric relationships (equations) 122

Alternative Approaches for Parametrics n Use of Activity Model n n n Parametric relationships may optionally have no causality – i. e. parameters may have no direction, unlike activities Parametrics have a much simpler model (and semantics) than UML activities Use of OCL n OCL has no obvious analog for parametric relation n Query assumes return value, can’t have unspecified parameter direction OCL has no concept of property binding Parametric has much simpler semantics than OCL 123

Requirements Diagram

Approach n The Requirements diagram can represent the following: n n n text based requirements and properties (e. g. , id, text statement, criticality, etc) requirements specification package as a set of requirements hierarchies n n n decomposition into constituent elements traceability between derived and source requirements assignment of design elements to requirements rational for requirements traceability, assignment, etc specification models (use cases, sequence diagrams, etc. ) that further specify the requirements Alternative graphical, tabular and tree representations 125

Requirements Diagram Example rd Vehicle Specification Vehicle Design <> Vehicle Performance -id=” 3. 2. 1. 1" -text=”The system shall…" -pri=”H” -status=”no” <> Vehicle Comfort Vehicle -id=” 3. 2. 1. 2" -text=”The system shall…" -pri=”M” -status=”no” <> -Gross. Weight: Real -Net. Weight: Real -Numb. Wheels: Int -Speed: Real +accelerate() +decellerate() «functional. Requirement» Provide acceleration <> «performance. Requirement» Acceleration <> a=F/m <> Derived Requirements «functional. Requirement» Provide Fuel Flow «performance. Requirement» Vehicle Weight «performance. Requirement» Horsepower Engine <> -Max. Horse. Power: Real 126

Requirements Metamodel 127

Requirement Classification n Basic attributes in Requirement n n Users create stereotypes for specific types of requirements, e. g. performance n n n text ID criticality add properties add associations (e. g. , parametric relations) Predefined profiles for standard requirement types 128

Requirements Stereotypes • Company/Industry specific extensions 129

Requirements Hierarchies • Construction of requirements hierarchies using trace and containment 130

Requirements & Design Rational • Capture rational for trace and assign relationships • <> and <> link 131

Further Requirements Specification • Performance test model using <> relationship 132

AP-233 Alignment & Demo

ISO 10303 - STEP n n Provide neutral data interchange formats Tool independent meta model (ARM – Application Reference Model) Interpretation of meta model using integrated resources (AIM-Application Interpreted Model) Some methods of representing STEP data n n STEP file (part 21) C++ API (part 23) XML file (part 28) Tool vendor have multiple implementation options 134

ISO 10303/AP 233 - Overview n n Neutral exchange format for systems engineering data Data model covers whole systems engineering life cycle n n n requirements functional architecture physical architecture validation and verification management Stakeholder INCOSE/MDSD 135

AP 233 Data Exchange Systems Engineering Electrical CAE Mechanical CAD SW Dev Environment Engineering Analysis AP-233 NEUTRAL DATA EXCHANGE FORMAT Testing Tools Algorithm Design Planning Tools 136

ISO 10303/AP 233 - Status n Requirements Module implemented n n n text-based Requirements property-based Requirements basic structure module tracing between structure and requirements AP 233 Demonstrator Next Steps n n n structure module behavior module risk scheduling rules 137

AP 233 and related protocols 138

AP 233 Demonstrator n n n Tool developed as part of the AP 233 development activities Purpose is to facilitate and demonstrate implementation of AP 233 Interfaces to n n n AP 233 p 21 file XMI PDM schema MS Excel/Word High-level API (OLE based) Free for non-commercial usage 139

AP 233 -Sys. ML n Major standardization activities for systems engineering community n n n Sys. ML as systems modeling language AP 233 as pure data interoperability mechanism Same scope of data Critical element for both groups to demonstrate interoperability Requirement in the RFP for Sys. ML n n “… architectural alignment …” “… facilitate data interchange …” 140

Alignment Objectives n n n Ensure AP 233 and Sys. ML have consistent semantics and terminology Ensure AP 233 and Sys. ML do not have inconsistent semantics (conflicts) Define criteria for establishing what is meant by “consistency” n n pragmatic approach: selected scenarios Provide route-map for how consistency is established and can be demonstrated 141

AP 233<->Sys. ML Data Exchange Electrical CAE Sys. ML Tools Systems Engineering XMI XML Meta-model Interchange Engineering Analysis AP-233 NEUTRAL DATA EXCHANGE FORMAT Algorithm Design Mechanical CAD SW Dev Environment Testing Tools Planning Tools 142

Harmonization Approach n n n AP 233 harmonization with SE DSIG in development and review of UML for SE Rf. P requirements Several Joint members of AP 233 and Sys. ML (along with chair of AP 233 Jim U’Ren) Collaboration with the ‘exff’ (Express for free) group n n n ISO 10303/part 25 XMI to Express mapping MDA for STEP Provide meta model mapping from AP 233 to Sys. ML and vice versa 143

AP-233 Alignment Roadmap n n n First order mapping Sys. ML–AP 233 Define exchange scenarios (i. e. exchange of fragments of a model) Preliminary demonstration/support to INCOSE IW Review Jan 25 -26 2004 Definition configuration management use-case scenarios Detailed mapping of AP 233 elements to Sys. ML meta-model Demonstration April 2004 144

Wrap Up

Wrap Up n n n SE DSIG established as joint INCOSE/OMG initiative to extend UML to support SE and align with AP-233 n kickoff in September 2001 n joint SE DSIG/INCOSE/AP-233 requirements analysis and review n issued UML for SE RFP in March 2003 Sys. ML Partners established in May 2004 to respond to RFP n includes wide range of contributors from industry, tool vendors and government agencies Sys. ML approach architecturally extends UML 2 Superstructure n extensively reuses a subset of UML 2 “out of the box” Major changes to UML 2 include: n enhancements to composite structure and activity diagrams n two new diagram types (requirements and parametrics) n Sys. ML alignment with ISO AP-233 Working towards adoption of Sys. ML v 1. 0 in H 2 2004 Technical approach is being validated by prototypes and partial implementations 146

Wrap Up n n n (cont. ) Round-robin feedback Action items Next steps 147

References n UML for SE RFP n n [UML 2 2003] UML 2 Superstructure (Final Adopted Specification) n n OMG doc# ad/03 -03 -41 OMG doc# ptc/03 -08 -02 [Bock 2003 -4] Activities n INCOSE Journal n n Journal of Object Technology n n n www 3. interscience. wiley. com/cgi-bin/abstract/106557123/ABSTRACT www. jot. fm/issues/issue_2003_07/column 3 www. jot. fm/issues/issue_2003_09/column 4 www. jot. fm/issues/issue_2003_11/column 1 www. jot. fm/issues/issue_2004_01/column 3 [Kobryn 2003] C. Kobryn and E. Eric Samuelsson, “Driving Architectures with UML 2. 0”, Telelogic White Paper, Aug. 2003. 148

Further Info n Web n n Mailing lists n n n www. sysml. org info: sysml-info@yahoogroups. com issues: sysml-issues@yahoogroups. com Chairs n Cris Kobryn n n cris. kobryn@telelogic. com; cris@sysml. org Sandy Friedenthal n sanford. friedenthal@lmco. com; sandy@sysml. org 149