UML Superstructure Proposal v. 2.0 beta R1

1
UML Superstructure Proposalv. 2.0 beta R1

• U2 Partners(www.u2-partners.org)
• September 2002

2
Overview

• Background
• goals
• language formalism
• language architecture
• Quick Tour
• Structured Classifiers
• Components
• Interactions
• Activities
• State Machines
• Pragmatics
• proof of concept
• other verification and validation
• proposed compliance points
• changes to adopted specifications

3
U2 Partners

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

4
Proposal Status

• Current draft
• UML Superstructure v. 2.0 beta R1
• ad/02-09-02 in response to ad/00-09-02
• UML Infrastructure v. 2.0 R1 (ad/02-09-01)
• ad/02-09-02 in response to ad/00-09-02
• InfrastructureLibrary reused by Superstructure
  FoundationKernel package
• Perspective
• 2 years after UML2 language RFPs issued in Sept.
  2000
• U2P proposals address all major RFP requirements

5
Goals

• Restructure and refine the language to make it
  easier to apply, implement and customize
• Infrastructure goals
• define a metalanguage kernel that
• defines (bootstraps) the UML language
• can be reused to define other OMG Model Driven
  Architecture metamodels (e.g., MOF, CWM)
• provide more powerful mechanisms to customize UML
• for platforms (e.g., J2EE, .NET)
• for domains (e.g., telecom, finance, systems
  engineering)
• for software and systems processes

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 scaleability, precision and
  integration of behavioral diagrams
• augment sequence diagrams with advanced contructs
  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
Language Architecture

• Relationships to other OMG standards
• UML package architecture

9
Relationships to OMG Standards
MOF 2.0
InfrastructureLibrary
UML 2.0
CWM 2.0
10
UML Architecture (with compliance levels)
11
Quick Tour

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

12
Structured Classifiers

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

13
Overview

• Structured classifiers describe the structure and
  the relationships of the participants that
  collaborate to perform system tasks. In addition,
  they
• support substitutability when constructing
  systems composed of parts
• typically cooperate with each other
• Structured classifiers include Classes and
  Components.
• The core constructs of structured classifiers
  include Part, Connector, and Port.
• Note Collaborations are harmonized with Parts
  and Connectors

14
Change Summary

• New core constructs added
• Part Represents a set of instances that are
  strongly 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 and with the environment.
• Port Specifies an addressable 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.

15
Change Summary (contd)

• New diagrams added or modified
• Internal 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.

16
Parts and Connectors
Connector
Car
eEngine
driveAxle
wWheel
Part
runAxle
nwWheel

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

17
Parts and 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
• Run-time multiplicities constrained in context
• Parts to be created when an instance of the
  containing classifier is created

18
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

19
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)

20
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
• bind roles to parts in a realizing classifier
• several roles may be bound to the same part,
  supporting synthesis of classifiers from roles

21
User Benefits

• Support flexible and scaleable representations 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

22
Issues

• Further harmonization between Class and
  Components to make the latter an evolution of the
  former (i.e., component paradigm evolves from
  object paradigm)
• Improvements to clarify explanations, including
  support for various behaviors
• Support for features on roles
• Additional examples

23
Components

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

24
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 model
• Variety of sophistication in component modeling
  in industry, e.g.
• structure specification type level definitions,
  instance (part) level definitions
• contract specification interfaces, ports,
  protocols
• Variety of application of component concept in
  industry
• e.g. Run-time components, Development components

25
Components Core Constructs

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

26
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
• model deployment environment at classifier or
  instance level
• optional DeploymentSpecification can parameterize
  deployment to ExecutionEnvironment
• optional deployment groups can be defined as
  ComponentAssembly

27
Component Diagrams

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

28
Change Summary

• New supertypes of Component in meta model
• PackagingNamespace ability to define which
  Interfaces, Classes and Components make up the
  Component
• EncapsulatedClassifier ability to define Parts,
  Connectors, Ports
• New related concepts
• DeploymentSpecification properties that
  parameterize the deployment of a component has
  associated Artifact
• ExecutionEnvironment Nodes are subtyped into
  Devices and ExecutionEnvironments (e.g.
  container, operating system)
• ComponentAssembly deployment group in a single
  Artifact
• UML 1.4 core Component construct updates
• not just provided interfaces, but also required
  interfaces
• explicit definition of wiring of components
• option to define internal structure
• New diagrams added
• Component diagrams repositioned as structure
  diagrams
• Internal structure diagrams (via
  StructuredClassifier)

29
Definition and Usage
30
Component Wiring
31
Deployment

32
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 the latter are
  now a kind of structure diagram

33
User Benefits

• Provided and Required Interfaces
• Model not just the provided or exposed
  functionality of a component but also the
  requirements that it has on its 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
• Detail internal structure
• Model the internal structure of complex
  components by defining the instance level
  structure
• Component concept supported across life cycle
• In 1.x implementation heritage

34
Issues

• Should Component be a subtype of Class in the
  meta model?
• currently it is a Classifier (inherited via
  StructuredClassifier from EncapsulatedClassifer)
• Are type level and part/instance level usage of
  Components both described appropriately in the
  spec?
• not everybody needs advanced components
• Show the application of the metamodel on various
  component models via profiles
• EJB, .NET, COM, BC4J, WSDL

35
Interactions

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

36
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

37
Change Summary

• New core constructs added
• Lifeline represents one object playing a Part in
  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 define the behavior accordingly
• UML 1.4 core constructs updated
• Instance replaced by the concept of Lifeline
• ClassifierRole subsumed by Part 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 eg. hiding

38
Interaction Context
Class or Collaboration
Behaviors (Interactions) notation to be
determined
Internal Structure
Part
Other concepts which may themselves have an
internal structure
39
Interaction Occurrences
Frame and Name
Lifeline is one object of a Part
Interaction Occurrence
Combined Fragment
Plain asynchronous message
40
Decomposition
Detailed context
Decomposition with global constructs
corresponding to those on decomposed lifeline
Decomposed lifeline
41
Combined Fragments and Data
loop
Choice
Operand Separator
Guarding Data Contraint
42
Interaction Overview Diagram
Interaction with the syntax of Activity Diagram
Interaction Occurrence
Expanded sequence diagram
43
Backward Compatibility

• Interactions appear in a context as Behaviors of
  a Classifier
• Lifelines representing Parts
• generic case Parts of a Collaboration
• anonymous Parts of given Classes replace Classes
  on Lifelines
• Collaboration Diagrams (UML 1.4) when describing
  Interactions are now Communication Diagrams
• Communication Diagrams do not have the same power
  as new Sequence Diagrams
• Guards on Messages deprecated
• Alternative fragments are more general

44
User Benefits

• Improved correspondence with class 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

45
Issues

• Minor modifications due to behavioral and
  notational harmonization
• Actions, Method Activations
• Parameters, Data
• Timing concepts
• Time constraints in Sequence Diagrams
• Timing Diagrams

46
Activity Modeling

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

47
Overview

• Activity modeling emphasizes the sequence and
  conditions for coordinating other behaviors,
  using secondary constructs to show which
  classifiers are responsible for those behaviors.
• The core constructs in an Activity include
• Nodes Invocation, Object, Control
• Edges Control and Data Flows
• Typical applications of Interactions include
• process modeling (business, physical)
• workflow modeling
• requirements

48
Change Highlights

• Parallelism in UML1 activities

49
Change Highlights

• Parallelism in UML2 activities

50
Change Highlights

• Unrestricted flow patterns in UML2 activities

51
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
52
Change Summary

• New core constructs added
• Parameter usages (input/output, alternative sets)
• Groupings (iteration, interruptible regions)
• UML 1.4 core constructs updated
• Edges (token flow)
• Object nodes (queuing, signals, parameters, data
  store)
• Parameters (streaming, exceptions)
• Partitions (multidimensional, hierarchical,
  external)
• Control nodes (join, merge, etc. handle token
  flow)
• Activities (attributes, operations, etc.)

53
Racing Flows

• From Workflow Process Definition RFP

54
Streaming Parameters

• Ongoing business activities

55
Hierarchical Partitions
56
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 parameter usages in the U2P model.

57
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

58
Issues

• Harmonization with Common Behavior
• Harmonization with other forms of Behavior
  inheritance
• Clarification of application of Diagram
  Interchange RFP

59
State Machines

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

60
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

61
Change Summary

• New core constructs added
• entry/exit points on submachines
• state machine specialization/redefinition
• state machine Termination
• protocol state machines
• transitions pre/post conditions
• protocol conformance
• UML 1.4 core constructs updated
• metamodel refactoring
• Notational enhancements
• action blocks
• state lists

62
Entry/Exit Points Usage
ATM
invoked submachine
VerifyCard
usage of exit point
acceptCard
outOfService
ReadAmount ReadAmountSM
aborted
OutOfService
again
rejectTransaction
usage of entry point
releaseCard
VerifyTransaction
63
Entry/Exit Points Definition
ReadAmountSM
definition of exit point
abort
otherAmount
selectAmount
amount
abort
EnterAmount
aborted
ok
definition of entry point
again
64
Specialization

• Redefinition as part of class specialization

65
State Machine Redefinition

• State machine of ATM to be redefined

ATM
VerifyCard
final
acceptCard
ReadAmount
selectAmount
selectAmount
outOfService
OutOfService
final
amount
releaseCard
VerifyTransaction
ReleaseCard
final
final
66
State Machine Redefinition

• FlexibleATM redefines ATM

FlexibleATM
ATM extended
VerifyCard
final
acceptCard
ReadAmount
extended
otherAmount
selectAmount
selectAmount
outOfService
OutOfService
final
amount
EnterAmount
ok
rejectTransaction
releaseCard
VerifyTransaction
ReleaseCard
final
final
67
State Machine Redefinition

• FlexibleATM Statemachine

• States and transitions can be added
• States and state machines can be extended
• Regions can be added, and regions can be extended
• Transitions can be replaced or extended
• Actions can be replaced
• Guards can be replaced
• Submachines can be replaced

extended
FlexibleATM ATM
ReadAmount
extended
SelectAmount
VerifyTransaction
68
State Machine Specialization

• Independent state machine specialization
• not as part of class specialization
• facilitates reuse of behaviours

ATMmachines
ltltstatemachinegtgt ATMsm
ltltstatemachinegtgt FlexibleATMsm
69
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"

check()
onGround
checked
cleared for take off takeOff() /landing rear
is retracted
flying
land()
postcondition instead of action
70
Example Notation Enhancements

• Transition notation

• State lists

VerifyCard, ReleaseCard
Logged
Is a notational shorthand for
71
Backward Compatibility

• In general all UML 1.4 state machine concepts are
  preserved in the 2.0 proposal
• Submachines stub-states replaced by connection
  points
• Specialization (only a note in UML 1.4) now
  specified
• Protocol state machines now specified as a
  separate compliance point

72
User Benefits

• Entry/Exit Points
• reuse via encapsulation of statemachine control
  interfaces
• scalability
• Specialization
• reuse, refinement
• Protocol State Machines
• usage of stat emachines at higher level of
  abstraction

73
Issues

• State machines for operations
• Currently not supported
• Is Event metaclass needed for state machines ?
• or only part of the runtime model?

74
Other Improvements

• All other areas have been reviewed and updated to
  improve integration and be consistent with
  changes in major areas
• Powertypes, Generalization Partitioning, and
  Information Flows added as optional compliance
  points
• Optional tabular notation for Interactions and
  other Behaviors
• see Appendix C and Fujitsu Superstructure
  presentation

75
Pragmatics

• Proof of concept
• validated by multiple vendors with prototype
  implementations (cf. WFR verification)
• Other verification validation
• checking options for automated verification
• integrated with U2P Infrastructure
• checking with .NET/COM and J2EE/EJB experts
  regarding component-based development support
• checking with AP-233 (systems engineering) and
  STEP/EXPRESS (manufacturing) and enterprise
  integration domain experts regarding
  architectural alignment

76
Pragmatics (contd)

• Proposed compliance points
• 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
• recommend retirement of IDL for model interchange

77
Issues

• Current top technical issues are listed on the U2
  Partners web
• www.u2-partners.org/issues.htm
• New technical issues should be submitted to
  dedicated mailing list
• u2p-issues_at_yahoogroups.org

78
Next Steps

• Expand review process to include more external
  reviews
• Systematically resolve outstanding issues
• Improve readability
• Collaborate with MOF2 submission teams to improve
  MOF2 alignment
• explore architectural options for generating XMI
  based on existing OMG adopted technologies in
  event that MOF2 is not completed in a timely
  manner
• Collaborate with other UML2 submission teams to
  incorporate complementary ideas
• Liaise with power users to stress test proposals
  with real-world examples
• Manufacturing DTF, Business Enterprise
  Integration DTF, Systems Engineering DSIG,
• customers and clients of 40 U2 Partners

79
Wrap up

• Current Superstructure proposal is a solid beta
• focus on tuning and integrating complementary
  ideas from other submissions
• able to complete in a timely manner if we dont
  keep changing requirements
• Superstructure is essential for a technical (cf.
  conceptual) MDA for domain power users, such as
  MfgDTF, BEI DTF, SE DSIG
• Critical that we shift focus from UML2
  Infrastructure to Superstructure, which offers
  the most benefits to end users
• Infrastructure tuning has reached point of
  diminishing returns
• risk losing work momentum and industry
  credibility if are tardy and let RFP scope creep
  prevail
• we need to keep user requirements first!

80
Further Info

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