# Presentation: 227590

## UML 2 for Systems Engineering

**Conrad Bock**
**NIST**
**conrad.bock@nist.gov**

## Unified Modeling Language

**Originated in object-oriented software community.**
**However:**
**Wide lifecycle, including logical specifications and deployment.**
**More than pictures:**
**Includes a repository model/API and**
**... ****and XML interchange.**
**Behavior models with virtual machines.**
**Not just for software modeling.**

## Wide Lifecycle

**Logical and physical modeling**
**Logical entities**
**Physical and software entities**
**Environment**
**System**
**Requirements**
**Use cases**
**Constraints**
**Deployment**
**Artifacts**
**... ****tied to specification and delivery.**

## More Than Pictures

**Repository provides**
**API’s**
**XML interchange**
**Support for multiple notations**
**UML notation stores to repository   ... and alternate notations can, too.**
**Generate systems from repository: Notation ******** ****Repository ******** ****System**

## Model-Centered Development

## Behavior Models

**Multiple types of model.**
**None dominant.**
**Different emphasis in each one:**
**Activity models**
**Series of actions**
**Interaction models**
**Messages between objects**
**State machines**
**Objects reacting to events**
**Virtual machines defined for execution.**

## UML Status

**First version adopted in 1997 (1.1).**
**Minor revision in 1999 (1.3).**
**Coding models added in 2001 (1.5).**
**Major revision finishing now (2.0).**
**Primary submission is created by many modeling vendors and users.**
**Expect adoption in mid-year, 2003.**

## New Areas in UML 2 for SE

**Activity model supports physical as well as computational processes.**
**Composition model supports inter-part connections.**
**Deployment model ties specification to delivered system.**
**Information Flow.**
**Time model.**
**And others.**

## Activity Modeling

**Activity modeling emphasizes the sequence and conditions for coordinating other behaviors**
**... ****using secondary constructs to show which classifiers are responsible for those behaviors.**
**Focus is on what tasks need to be done, in what order, rather than who/what performs each task.**

## Activity Modeling

**Tasks and ordering ...**

**Notes:**
Shows sequence and conditions for coordination of other behaviors. Arrows are not necessarily messages or other communications.

## Activity Modeling

**... ****plus resource assignments.**

**Notes:**
“Resource assignment” is another way of saying “object-oriented”. Ship order might be moved to another department.  Original activity model doesn’t change. Invoice on partiiton boundary because it represents pins, ie, inputs and outputs, and these are spread across two partitions.  Partitions can also be multi-dimensional.

## UML 2 Activities for SE

**First-class behavior model:**
**Usable with or without objects**
**Parameterized**
**Behavior properties**
**Full parallelism**
**Concurrent branches operate independently.**
**Input/output**
**Queuing, storage**
**Notation**
**Multi-entry/exit**
**Full action model**
**For model execution and simulation.**

## First-class Behavior Model

**Object-orientation not required to model dynamics ...**
**... ****but supported when needed.**
**Behaviors can be invoked directly, or through an object owning the behavior.**
**Parameterized for input/output.**
**Can have attributes, associations, operations, states, ... **

**Notes:**
UML 1.x did not have parameterized behavior models.

## First-class Behavior Model

**Notes:**
Deliver Mail activity can stand alone (be invoked directly) or be attached as a method to an object (be invoked by request to an object).  It can be treated as an object, with attributes such as how long it has been executing, an operation for aborting it, a link to the resources it is using, and so on.

## State-based UML 1.x Activities

**(Activity)**

**Notes:**
UML 1.x activities are based on state machines.  The “parallel” regions are actually synchronized so that one step happens in each region per cycle of the machine.  Events are taken into the machine only between cycles.  Regions must be well-nested.

## Token-based UML 2 Activities

**(Activity)**

**Notes:**
UML 2 activities based on token flow through an unrestricted graph.

## Unrestricted Parallelism in UML 2

**(Activity,**
***tokens not***
***notation*****)**

**Notes:**
UML 2 activities can be arbitrary graphs.

## Tokens can
stack up in “in/out” boxes
backup in network
prevent upstream behaviors from taking new inputs
Applicable to systems with significant resource constraints, such as physical or manual processes.

**stack up in “in/out” boxes**
**backup in network**
**prevent upstream behaviors from taking new inputs**
**Applicable to systems with significant resource constraints, such as physical or manual processes.**

**Queuing**

## Queuing

**Tokens can be**
**Stored temporarily**
**Divided between flows**
**Tokens cannot**
**Flow in more than one direction, unless copied.**

**Machine**
**Part**

**Test Part**

**<<centralBuffer>>**
**Part**

**Polish Part**

**Machine**
**Part**

## Non-queuing

**No token interaction.**
**For domains without resource constraint, such as computation.**

**Amount function update_account**
**	****	****	****(a : Account, d : Amount)**
**{**
**  ****Amount nb = a.balance + d;**
**  ****a.balance = nb;**
**  ****send_notice (a.customer, a, nb);**
**  ****return nb;**
**}**

**Notes:**
Multiple data and control flows implicit in textual presentation of activity.

## Non-queuing

## Parameter Sets

**Sets of parameters can take input or provide output ...**
**... ****exclusive of each other at runtime.**
**See multi-exit in EFFBD.**

## Full Action Model

**Actions are the “steps” in an activity (round-cornered rectangles).**
**Include:**
**Invoking behaviors/functions.**
**Creating/destroying objects.**
**Getting/setting property values.**
**For fully-executable models and simulations.**

## Extended Functional Flow Block Diagram

**Control/data flow diagram.**

**From Long, James, "Relationships between Common Graphical Representations in System Engineering", ViTech Corporation, www.vitechcorp.com**

## Extended Functional Flow Block Diagram

**Most of EFFBD supported by UML 2 Activity diagrams.**
**Some differences in execution ...**
**... ****to be addressed in SE profile for UML 2 or in minor revision to UML.**

## Function  Behavior/Action

**EFFBD Function and UML 2 Action/Behaviors are steps in a process flow.**

**Notation is different, but repository would be the same ****(except for adding #).**

**Notes:**
Semantics is the same, notation different.  Applies to following slides also.

## Control Flow

**EFFBD and UML 2 Control Flow give time sequence to steps in a process flow.**

**Notes:**
Rectangles are classes in UML.

## Data/Object Flow

**EFFBD and UML 2 Data Flow specify how Function/Behavior outputs are provided to inputs.**

## External I/O  Parameter

**EFFBD External Input/Output and UML 2 Parameter support I/O at the beginning/end of the entire diagram.**

## Select  Decision

**EFFBD Select and UML 2 Decision specify mutually exclusive paths in a flow.**

**Notes:**
Line shapes, attachment points are not normative.

## Concurrency  Fork/Join

**EFFBD Concurrency and UML 2 Fork/Join specify parallel paths**

## Multi-exit  Parameter Sets

**EFFBD multi-exit functions and UML 2 Parameter Sets specify mutually exclusive outputs.**

**Notes:**
Completion conditions are a property of the function.

## Cycles 

**EFFBD and UML 2 flows can have cycles in the flow graph. **

**Notes:**
EFFBD iteration determines number of loops at the end of the iteration.  Extend UML for the EFFBD cycles, notationally, and for iteration and loop, semantically.

## Edge Shortcuts

**Notational shorthand for long flow lines:**

## Example EFFBD

**Adapted from Long, James, "Relationships between Common Graphical Representations in System Engineering", ViTech Corporation, www.vitechcorp.com**

## UML 2 Translation

**External**
**Input**

**External**
**Output**

**1. Serial**
**Function**

**2. Multi-exit**
**Function**

**3. Function in**
**Concurrency**

**Data 1**

**4. Function in**
**Multi-exit**
**Construct**

**5. Function in**
**an Iterate**

**[ before third time ]**

**Data 2**

**[ else]**

**6. Output**
**Function**

**Data 3**

**Data 5**

**Data 4**

## To Be Addressed

**Triggering and non-triggering inputs.**
**Distinguish required from streaming.**
**Multi-exit, queuing on control.**
**Treat control as a kind of data.**
**Completion conditions on multi-exit.**
**Add postconditions to UML 2 ParameterSet.**
**Control/data flows that disable functions.**
**Extend control tokens.**
**Iteration**
**Extend merge node.**
**Continuous data flows.**
**Fine-grained token flow.**

**Notes:**
Last two from SE UML RFP.

## EFFBD ~ Activities

**Significant similarity between EFFBD and UML 2 Activities.**
**Entry point for SE’s into UML.**
**Integrates with other UML features useful to SE:**
**Classes**
**Composition (Assembly)**
**Information  Flow**
**Many other features not presented here.**
**Details of EFFBD ********  Activity translation at: ****http://www.u2-partners.org /outgoing/syseng/seu2pactivitymap.zip**

## Composition UML 1.x

**UML 1.x supported part-whole ...**

## Composition UML 1.x

**... ****but not part-part:**

**Associations are global**

**(not legal**
**UML anyway)**

**Notes:**
Associations are global and independent of each other.  Not legal UML anyway, because powers links the same class to two others.

## Composition UML 2.0

**UML 2 supports part-part in context:**

**Notes:**
Compare to UML 1.x collaborations.  Multiplicities are local.

## Composition UML 2.0

**Enables better abstraction:**

**Notes:**
CarEngine and BoatEngine so that different kinds of engines can be used in cars and boats.  Use redefinition of inherited composite structure.

## UML 1.x supports interfaces, but only in one direction:

**Interfaces UML 1.x**

**Interface usage buried in client methods.**

**Notes:**
Engine needs to know about wheels and propellers if it ever creates instances.

## Interfaces UML 2.0

**Bidirectional interfaces:**

**Notes:**
Required and provided interfaces “wired” together in composite (component).

## Ports = public parts.

**Composition 2.0 (Ports)**

## Composition 2.0 (Ports)

**Multiple ports of the same type.**

## Very abstract flow model.

**Information Flow**

**Independent of message passing, parameters, etc, but can be tied to these.**
**Applicable to Elaborated Context Diagrams**

## Time Model

**Can be used to state constraints on processes:**

## Interaction Model

**sd **

**example**

**ob4:C4**

**doit(z)()**

**ob2:C2**

**doit(z)()**

**ob3:C3**

**doit(w)()**

**doit(w)()**

**ob1:C1**

**create()**

**more()**

**more()**

**opti()**

**opti()**

**[x>0]**

**[**

**else**

**]**

**alt**

**Notes:**
UML 2 defines additional control operators on interactions.

## Interaction Model

**Notes:**
Message have begin and end events that can be arbitrarily ordered.

## Deployment

**Support for general mappings between design elements, artifacts, and deployment targets.**
**Communication paths between nodes.**
**Supports locality diagrams.**

## Summary

**UML is**
**wide lifecycle**
**applicable to multiple domains**
**a repository for multiple notations**
**UML 2 adds new models useful to systems engineering ...**
**... ****in both structure and behavior.**
**Latest draft of UML 2 submission: ****http://doc.omg.org/ad/03-03-02****.**
**Updates:**** http://www.omg.org/uml**