UML 2'0 Superstructure Proposal 2nd revision

1
UML 2.0 Superstructure Proposal(2nd revision)

• U2 Partners(www.u2-partners.org)
• January 2003

2
Overview

• Proposal status
• Summary
• Quick Tour
• Pragmatics

3
Proposal Status

• Second revised submission
• UML Superstructure v. 2.0 (2nd revision)
• ad/03-01-02 in response to ad/00-09-02
• Support artifacts
• ad/03-01-04 Abstract Syntax (MDL format)
• ad/03-01-06 XMI (XMI format)
• Reuses
• UML Infrastructure v. 2.0 (3rd revision)
• ad/03-01-01 in response to ad/00-09-01
• Support artifacts
• ad/03-01-03 Abstract Syntax (MDL format)
• ad/03-01-05 XMI (XMI format)

4
U2 Partners

• Submitters
• Alcatel, CA, Ericsson, Fujitsu, HP, IBM, I-Logix,
  IONA, Kabira, Motorola, Oracle, Rational,
  SOFTEAM, Telelogic, Unisys
• Supporters
• Advanced Concepts Center LLC, Ceira Technologies,
  Commissariat à L'Energie Atomique, Compuware,
  DaimlerChrysler, Embarcadero Technologies, Enea
  Data, France Telecom, Fraunhofer FOKUS,
  Gentleware, Intellicorp, Jaczone, Kennedy Carter,
  Klasse Objecten, KLOCwork, Lockheed Martin,
  Mercury Computer, MSC.Software, Northeastern
  University, Popkin Software, Proforma, Sims
  Associates, Syntropy Ltd., Sun Microsystems,
  University of Kaiserslautern, University of Kent,
  VERIMAG, WebGain, and 88solutions

5
Goals

• Restructure and refine the language to make it
  easier to apply, implement and customize
• Strictly reuse U2P Infrastructure 2.0
• InfrastructureLibrary package reused by
  Superstructure ClassesKernel package
• consequently also architecturally aligned with
  sole MOF 2.0 Core submission

6
Goals Superstructure (contd)

• Improve support for component-based development
• specify both platform-independent components
  (e.g., business components) and platform-specific
  components (e.g., EJB, COM)
• Refine architectural specification capabilities
• support hierarchical composition of parts with
  interfaces (compare SDL blocks and processes)
• Increase the scalability, precision and
  integration of behavioral diagrams
• augment sequence diagrams with advanced
  constructs from MSCs that can be combined and
  integrated with other behavior
• update state machines diagrams to make
  generalizable and able to support a
  transition-centric view
• revise activity diagrams to support more flexible
  parallelism and furnish more I/O options
• support executable models
• Review all UML 1.x constructs and diagrams
• refine, retire or deprecate as appropriate

7
Language Formalism

• Refinement of UML 1.x formalism
• abstract syntax
• constraints
• semantics (natural language)
• Integrated semantics and notation
• straightforward mapping between notation and
  semantics
• New sections for semantic variation points,
  backward compatibility, design rationales, etc.
• pragmatic information previously lacking

8
RFP Requirements

• Proposal satisfies all RFP section 6.5 mandatory
  requirements and most section 6.6 optional
  requirements
• summary provided in Preface

9
Language Architecture

• Relationships to other OMG standards
• Package structure

10
Relationships to OMG Standards
MOF 2.0
InfrastructureLibrary
UML 2.0
The InfrastructureLibrary is self-contained
11
Top-Level Packages
12
Specification Outline

• Part I Structure
• Classes
• Components
• Composite Structures
• Deployments
• Part II Behavior
• Actions
• Activities
• Common Behaviors
• Interactions
• State Machines
• Use Cases
• Supplement
• Auxiliary Constructs
• Profiles
• Appendices

13
Quick Tour

• Structured Classifiers
• Components
• Interactions
• Activities
• State Machines

14
Structured Classifiers

• Overview
• Change summary
• core constructs
• diagrams
• Examples
• Backward compatibility
• User benefits

15
Overview

• Entities often cooperate with each other to
  produce the behavior of a system. Structured
  classifiers support
• The description of the structure and the
  relationships of the participants that jointly
  perform a task of the system, and
• The ability to encapsulate/isolate this internal
  structure to achieve plug-substitutability for a
  system.
• Structured classifiers are Classes,
  Collaborations, and Components.
• The core constructs of structured classifiers
  include Part, Connector, and Port.

16
Change Summary

• New core constructs added
• Part Represents a set of instances that are
  aggregated within a containing classifier
  instance. Parts may be joined by attached
  connectors and specify configurations of linked
  instances.
• Connector Specifies a link (an instance of an
  association) that enables communication between
  parts in a structure or with the environment.
• Port Specifies an interaction point between a
  classifier and its environment. Describes the
  services a classifier offers to its environment
  at this point, and the services the classifier
  expects from the environment.

17
Change Summary

• New diagrams added or modified
• Composite structure diagram Depicts the internal
  structure of a classifier. For scalability
  reasons, internal structure is usually not shown
  in a compartment of the classifier symbol (albeit
  it could be shown there).
• Collaboration diagram Depicts structure of the
  cooperating entities only their communication is
  shown in interaction or communication diagrams.
  Support for binding roles to parts in a realizing
  structure.

18
Example Parts / Connectors
Connector
Car
eEngine
driveAxle
wWheel
Part
runAxle
nwWheel

• Features that specify instances (objects and
  links) to come
• Contextualized
• Will be part of the same container instance the
  links will connect instances within this container

19
Example Parts / Connectors
Connector
Car
eEngine
1
2..
driveAxle
wWheel
Part
1..
2..
runAxle
2
nwWheel

• Multiplicities allow to specify the precise
  configuration of the internal structure
• to be created when an instance of the containing
  classifier is created
• Star, Array, or Bus configuration specifiable
• Dynamically reconfigurable at run time

20
Example Parts / Connectors
Instance
myIntegra Car
eng/eEngine
d/driveAxle
w1/w Wheel
w2/wWheel
r/runAxle
n2/nwWheel
n1/nwWheel

• Multiplicities allow to specify the precise
  configuration of the internal structure
• to be created when an instance of the containing
  classifier is created
• Star, Array, or Bus configuration specifiable
• Dynamically reconfigurable at run time

21
Example Ports
Car
eEngine
Port
1
2..
driveAxle
wWheel
1..
2..
runAxle
2
nwWheel

• Encapsulate communication with a classifier
• Provided interface specifies services offered by
  the classifier to its environment
• Required interface describes services the
  classifier expects from its environment
• Can be verified at run time

22
Example Ports
Car
eEngine
1
2..
driveAxle
wWheel
1..
2..
Shaft
runAxle
2
nwWheel

• Enables specification of a classifier without
  knowing anything about the environment in which
  the classifier will be used
• Send to port, receive messages from port
• Ports relay communication along connectors
• May have complex behavior (protocol)

23
Backward Compatibility

• Concepts to model internal structure are newly
  added
• A collaboration is a structured classifier which
  is not directly instantiated but realized by some
  other classifier(s).
• 1.x roles are generalized to parts and connectors
  in collaborations and specify that there must be
  instances in the realizing classifier which
  exhibit the features specified for the roles.
• Bind roles to parts in a realizing classifier.
• Several roles may be bound to the same part,
  supporting synthesis of classifiers from roles.

24
User Benefits

• Support representation of architectures
• through contextualized parts and connectors
• Support plug-substitutability of parts
• through ports establishing encapsulation
  boundaries
• through required and provided interfaces
  characterizing interaction with environment
• Improve scalability
• through hierarchical decomposition
• Harmonization with role-based modeling
• Foundation for behavior modeling
• See also RFP, section 6.1.1.2

25
Components

• Overview
• Change summary
• core constructs
• diagrams
• Examples
• Backward compatibility
• User benefits

26
Overview

• A Component represents a modular part of a system
  that encapsulates its contents through interfaces
  and is replaceable within its environment.
• Must be able to provide the basis for modeling
• Variety of sophistication in component modeling
  in industry, e.g.
• in Structure specification type level
  definitions (contract interfaces
  implementation)
• In ComplexStructure instance (part) level
  details
• Variety of application context of component
  concept in industry
• Component frameworks and technologies
• Development components

27
Meta model approach

• Basic Component concept as subtype of Class
  that constitutes
• a thing with a specification in terms of
  provided and required interfaces
• A thing that abstracts from a group of
  classifiers that form its realization
• Separate Packages define optional modeling
  details
• Add Ports if needed
• Add internal structure detail
• Add wiring detail
• Add more packaging detail
• Add deployment specifics

28
Components Core Constructs

• Specification aspect
• Interfaces (contract)
• virtual or concrete Features Association,
  Generalization
• optional addressable interaction points Ports
• optional detailed contract Protocol State
  Machine, Activities
• Realization (or implementation) aspect
• realization Classifiers
• nesting other Components
• optional internal structure to define instance
  containment Parts, Connectors
• Wiring (or assembly) aspect
• connect provided and required Interfaces with
  Dependencies
• plug substitutable element (Subtype interfaces,
  Signal compatible interfaces)
• optional detailed wiring with Parts and Connectors

29
Specification, Realization, Wiring
30
Components Core Constructs

• Packaging aspect
• self contained building block Classes,
  Interfaces Artifacts
• option to contain Use Cases, State Machines, etc
• large scale units subsystem , development
  component
• Manifestation (or implementation) aspect
• Artifacts represent physical component
  implementations
• various kinds source, executable
• Artifacts are Classes that can be instantiated to
  represent copies
• Deployment aspect
• Deployment environment consists of Nodes
  interconnected through CommunicationPaths
• model deployment environment at classifier or
  instance level
• optional DeploymentSpecification can parameterize
  deployment to ExecutionEnvironment
• optional deployment groups can be defined as
  componentAssembly

31
Packaging
32
Manifestation, Deployment
See Deployment chapter for details
33
Component Diagrams

• Kinds of Component diagrams include
• Component diagrams (structure diagrams)
• Related diagrams (optional) include
• Internal Structure diagrams
• Collaboration diagrams
• Deployment diagrams (include component deployment
  aspects)

34
Change Summary

• constructs
• new supertype
• StructuredClassesClass option to define Parts,
  Connectors, Ports
• new related concepts
• DeploymentSpecification
• ExecutionEnvironment
• UML 1.4 core Component construct updates
• explicit provided and required interfaces
  realization
• explicit definition of wiring of components

35
Change Summary

• standard stereotypes
• subsystem
• specification, realization
• developmentComponent
• diagrams
• Component diagrams repositioned as structure
  diagrams
• Composite structure diagrams (via
  StructuredClassifier)

36
Definition and Usage
Note can also use Dependencies to wire
components together
37
Component Wiring
38
Deployment

39
Backward Compatibility

• Generally all UML 1.x component models are UML
  2.x models
• Some meta model mapping required
• New capabilities are additive
• Basic component notation of protruding rectangles
  replaced by equivalent icon
• UML 1.x notation was difficult to scale
• old notation supported as option for backward
  compatibility
• The term implementation diagram is retired
• used to be collective term for deployment
  diagrams and component diagrams these are now
  structure diagrams

40
User Benefits

• Component concept supported across life cycle
• In 1.x implementation heritage
• Provided and Required Interfaces
• also model the requirements on environment
• Wiring or Assembly of components
• Model the connections between Provided and
  Required Interfaces (must be type substitutable)
• Option to tie into Collaborations to model
  detailed usages (or reuse) of components
• Option to add contracts (any Behavior) to
  Connectors
• Detailed internal structure option
• Model the internal structure of complex
  components by defining the instance level
  structure

41
Interactions

• Overview
• Change summary
• core constructs
• diagrams
• Examples
• Backward compatibility
• User benefits

42
Overview

• Interactions focus on the communications between
  instances, using message passing to express
  operation invocation and signal sending
• Interactions are used
• during analysis, to improve individual or group
  understanding of inter-object behavior
• during design, to precisely describe
  inter-process communication
• during testing, the traces can be compared with
  those described in the earlier phases.
• The core constructs in an Interaction include
• lifeline, message, interaction occurrence,
  combined fragment, decomposition
• The kinds of Interaction diagrams include
• sequence diagram, communication diagram,
  interaction overview diagram, timing diagram,
  interaction table

43
Change Summary

• New core constructs added
• Lifeline represents one ConnectableElement object
  of an internal structure
• Interaction occurrence refer from one Interaction
  to another for better structure
• Combined fragment express control structures such
  as choice, loop, parallel merge etc.
• Decomposition taking advantage of the Internal
  structure and defining the behavior accordingly
• UML 1.4 core constructs updated
• Instance replaced by the concept of Lifeline
• ClassifierRole subsumed by Property in a
  Collaboration
• New diagrams added
• Interaction Overview improving behavior overview
  
• Timing Diagram for more detailed view of time
  and timing
• Interaction Table more suitable for some
  operations, e.g. hiding

44
Interaction Context
Class or Collaboration
Behaviors (Interactions) notation to be
determined
Internal Structure
ConnectableElement
Other concepts which may themselves have an
internal structure
45
Interaction Occurrences
Frame and Name
Lifeline is one object of a ConnectableElement
Interaction Occurrence
Combined Fragment
Plain asynchronous message
46
Decomposition
Detailed context
Decomposition with global constructs
corresponding to those on decomposed lifeline
Decomposed lifeline
47
Combined Fragments and Data
loop
Choice
Operand Separator
Guarding InteractionOperand with an
InteractionConstraint
48
Interaction Overview Diagram
Interaction with the syntax of Activity Diagram
Interaction Occurrence
Expanded sequence diagram
49
Timing Diagram
StateInvariant
Duration constraint
Lifeline
Time constraint
Timing ruler
Time values
Message event
50
Interaction Table
One row per event occurrence
Explicit ordering information such that rows may
be permuted and hidden for different purposes
51
Backward Compatibility

• The context of Interactions is a Classifier since
  Interactions are Behaviors
• Lifelines are properties of internal structure
• anonymous properties replace Classes on Lifelines
• Collaboration Diagrams (UML 1.4) describing
  Interactions are now called Communication
  Diagrams
• Communication Diagrams do not have the same power
  as new Sequence Diagrams
• Guards on Messages replaced by the more general
  alternative combined fragments

52
User Benefits

• Integrated with class internal structure
• facilitates automatic verification of
  Interactions vs. other behavioral descriptions of
  the same context
• Improved expressiveness via
• structuring mechanisms
• various combined fragment operators
• Improved scalability via
• Interaction Occurrences
• Decomposition

53
Activity Modeling

• Overview
• Change summary
• core constructs
• diagrams
• Examples
• Backward compatibility
• User benefits

54
Overview

• Activities are behaviors that emphasize the
  sequence and conditions for executing other
  behaviors.
• Secondary constructs show classifiers responsible
  for those behaviors.
• The core constructs in an Activity include
• Nodes Action, Object, Control, Parameter
• Edges Control and Object Flows
• Typical applications of Activities are process
  modeling in a wide variety of domains
• Computational
• Business
• Physical
• Systems
• Requirements

55
Action/Activity Integration

• Eliminate overlapping semantics, create synergy.
• Data/control flow model of actions is replaced
  with the more general flow model of activities.
• Procedure replaced with Activity.
• Behavior invocation of Activities is replaced
  with the more general action model.
• InvocationNode replaced with Action.
• Composite actions become structured nodes,
  replace IterationGroups.
• Map/FilterAction replaced with ExpansionRegion,
  IteractionAction with LoopNode, ReduceAction
  removed.
• Activities define the flow graph (procedure),
  Actions define the nodes that perform behaviors.
  Collection actions folded into flow model.

56
Action/Activity Integration

• Activity notation is optional, allows
  vendor-specific action languages.
• Activity notation available for graphical
  presentation of flow, with action node notation
  still vendor-specific.

function Amount update_account (a Account, d
Amount) Amount nb a.balance d
a.balance nb send_notice (a.customer, a,
nb) return nb
57
Action/Activity Example
update_account
Amount
Deposit
Account
58
Change Highlights

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

stream
Polish Part
Package Part
Machine Part
59
Change Highlights

• Parallelism in UML1 activities

60
Change Highlights

• Parallelism in UML2 activities

61
Change Highlights

• Unrestricted flow patterns in UML2 activities

62
Change Summary

• Integration of actions and activities
• New core constructs added
• Pins (input/output, alternative sets)
• Groupings (structured nodes, interruptible
  regions)
• UML 1.4 core constructs updated
• Edges (token flow)
• Object nodes (queuing, signals, parameters)
• Parameters (streaming, exceptions)
• Partitions (multidimensional, hierarchical,
  external)
• Control nodes (fork, join, decision, merge)
• Activities (attributes, operations, etc.)

63
Racing Flows

• From Workflow Process Definition RFP

64
Streaming Parameters

• Ongoing business activities

65
Hierarchical Partitions
66
Backward Compatibility

• UML 1.x activity diagrams have the same semantics
  in U2P, assuming U2P defaults.
• UML 1.x activity models using object flow state
  will map to pins in the U2P model.
• UML 1.x dynamicInvocation maps to
  ExpansionRegions, without multiplicity.

67
User Benefits

• Supports modeling a wider variety of processes
• computational
• physical
• business
• workflow
• More intuitive for process modelers.
• Supports a wider set of stakeholders by using
  varying levels of presentation detail.

68
State Machines

• Overview
• Change summary
• core constructs
• notation
• Examples
• Backward compatibility
• User benefits

69
Overview

• State machines specify discrete behavior by
  mapping received events into sets of states. They
  may specify detailed behaviors of classes or
  constrain operational sequences of ports or
  interfaces.
• The core constructs in statemachines include
• States, Regions, Transitions, Events
• Notated using state machine diagrams
• Typical applications of statemachines include
• object lifecycle
• states an order object might be in
• event-driven behaviors of embedded controllers
• UI controllers
• valid Sequences of calls via interfaces or ports

70
Change Summary

• Dynamic semantic foundation extracted
• Metamodel refactoring
• New core constructs added
• Fully encapsulated submachines (entry/exit
  points)
• State machine specialization defined
• State machine termination
• Protocol State machines
• Transitions with pre/post conditions
• Protocol conformance between state machines
• Notational enhancements
• Graphical notation for transitions
• State lists

71
Entry/Exit Points Definition

• Encapsulation of sub-state machines

ReadAmountSM
definition of exit point
abort
otherAmount
selectAmount
amount
abort
EnterAmount
aborted
ok
definition of entry point
again
72
Entry/Exit Points Usage
ATM
VerifyCard
use of exit point
acceptCard
outOfService
ReadAmount ReadAmountSM
aborted
OutOfService
again
rejectTransaction
use of entry point
releaseCard
VerifyTransaction
73
Redefinition by Specialization

• as part of class specialization

74
State Machine of General Class
ATM
VerifyCard
final
acceptCard
ReadAmount
outOfService
OutOfService
final
releaseCard
VerifyTransaction
ReleaseCard
final
final
75
State Machine Specializations

• States and transitions can be added
• States can be extended
• Regions can be added, and regions can be extended
• Submachine states can be replaced
• Transitions can be replaced or extended
• Actions can be replaced
• Guards can be replaced
• Targets can be replaced

FlexibleATM extended
ReadAmount
extended
otherAmount
SelectAmount
EnterAmount
EnterAmount
ok
rejectTransaction
VerifyTransaction
76
State Machine Specialization

• Independent class specialization
• Facilitates reuse of behavior specification

77
Protocol State Machines

• Equivalent to pre and post conditions added to
  the related operations
• takeOff()
• Pre
• in state "checked"
• cleared for take off
• Post
• landing rear is retracted
• in state "flying"

78
Notation Enhancements
79
Backward Compatibility

• All UML 1.4 state machine concepts are preserved
  in the 2.0 proposal
• Submachines stub-states replaced by connection
  points
• Specialization from a note in 1.4 to
  specification text in 2.0
• Protocol state machines now explicitly supported

80
User Benefits

• Entry/Exit Points
• reuse via encapsulation of statemachine control
  interfaces
• scalability
• Specialization
• reuse of behavior specification
• Protocol State Machines
• use state machines at higher level of abstraction

81
Other Improvements

• Refinement of Common Behavior
• Appendices have been added to provide additional
  reference information
• All other areas have been reviewed and updated to
  improve quality and readability

82
Pragmatics

• Proof of concept (RFP section 4.8)
• validated by multiple vendors with prototypes and
  implementations
• Other verification validation
• strict reuse of U2P Infrastructure
• automated generation of XMI
• partial automated verification of model
• reviewed by .NET/COM and J2EE/EJB experts
  regarding component-based development support
• reviewed by Systems Engineering DSIG, AP-233
  (systems engineering), STEP/EXPRESS
  (manufacturing) and Radio SW domain experts
  regarding architectural alignment
• reviewed by 40 U2 Partners and their customers

83
Pragmatics (contd)

• Compliance
• FoundationKernel and FoundationPrimitiveTypes
  are required FoundationProfiles is optional
• all other packages are optional compliance points
• Changes to OMG adopted specifications
• UML Infrastructure UML Superstructure
  recommended to replace UML 1.x Semantics
  Notation with Action Semantics
• recommend retirement of IDL for model interchange
• backward compatibility addressed in detail

84
Support for MDA

• Infrastructure Appendix B addresses how U2P
  proposals support MDA concepts
• family of languages
• specifying platform independent models (PIMs) and
  platform specific models (PSMs)
• specifying platforms
• transforming PIMs ? PSMs

85
Wrap up

• 2nd revised Superstructure satisfies all RFP
  mandatory requirements and most optional
  requirements (RFP sections 6.5 6.6)
• summary provided in submission Preface
• Proofs of concept include prototypes and
  implementations (RFP section 4.8)
• Submission is architecturally aligned with
• U2P Infrastructure 2.0 (3rd revision)
• MOF 2.0 Core and MOF 2.0 XMI submissions
• Next steps
• provide technical errata and a convenience
  document NLT 3 weeks prior to the Orlando meeting
• other corrections can be made in an FTF

86
Further Info

• www.u2-partners.org
• mailtou2p-info_at_yahoogroups.com
• mailtou2p-issues_at_yahoogroups.com