A Potential 2U Superstructure Submission

1
A Potential 2U Superstructure Submission

• Alan Moore

2
Key Features

• Extension of 2U infrastructure
• Infrastructure has complete (denotational)
  semantic domain, mapped to abstract syntax
• Translation from Superstructure to Infrastructure
  specified
• Coherent, consistent behavioural model
• Simple (but powerful) model of components
• Generic notion of scenario throughout structure
  and behaviour
• Complete concrete syntax and mapping to abstract
  syntax
• Fulfils RfP Requirements

3
RfP Requirements

• Enable the modeling of structural patterns, such
  as component-based development and the
  specification of run-time architectures.
• Clarify the semantics of the generalization,
  dependency, and association relationships.
• Support encapsulation and scalability in
  behavioral modeling, in particular, for state
  machines and interactions.
• Remove restrictions on activity graph modeling
  due to the mapping to state machines.

4
Structure of 2U Proposal

• Semantics of infrastructure is precise and
  complete
• Superstructure models (and instances thereof)
  translated to infrastructure models

5
Systems View of UML

• Generic Superstructure
• Specific domains (including software and
  sub-domains) as extensions
• Semantics (as defined by translation to
  infrastructure) is intended to be general but can
  be removed and a new one added if desired

6
Unified Behaviour Model

• Detail based on OCL expressions
  Update/Create/Send type actions
• Syntax and Semantics are superset of current
  state/activity/sequence
• Existing diagrams remain but are views on unified
  model
• Superstructure Abstract Syntax translated to
  Infrastructure to define semantics
• Partial support for continuous behaviour
• Expression syntax can express continuous
  expressions
• Need to add new expressions like derivative
• Semantics is (currently) discrete

7
Behavioural Model Structure
Identical to 2U Infrastructure
Adds state-machine concepts
Supports basic notion of activity
Adds pins to support data as well as control flow
Adds composite regular expressions for 3GL mapping
8
Activities Package

• Introduce the notion of guarded flow
• Flows owned by LCA
• Add minimal required pseudo-states

9
State Machine Package

• State and Region are Composite Actions
• Region may only have one active subaction
• Transition is a Flow
• Final is Simple Action with null Expression
• Need additional pseudo-actions

10
Concise Component Model

• Minimal extension to UML 1.4
• Any attribute can be a port
• Attributes can be connected directly to one
  another
• Feature direction can be in, out, inout
• Applicable to any type of system
• Extend to support EDOC and EAI
• Extend to create specific component model, e.g.
  in software sub-domain for COM, CORBA, EJB

11
Component Meta Model
Use of feature with respect to owner (in, out,
inout)
Whether the inverse of default direction of the
types features is used (equivalent to conjugate
port in ROOM
Whether the inverse of default direction of the
superclasses features is used (whether a subclass
requires or offers the features of the superclass)
12
Scenarios

• Notion of Role or Prototypical Instance
• Generalization of UML 1.x concept
• Applies to all abstract syntax elements
• Allows description of structural and behavioural
  scenarios

role

AS Element
1
Type Domain
Instance Domain
Extent
Class
Role/Class
13
Example Software Component Scenario
D1/D
Structure View
C1/C
C1p1/cp1int
C1p2/cp2int

• Roles used to express usage
• Containment does not imply composition
• Connection does not imply association
• Supports notion of dynamic topology

c1p3/cp3channel
c2/com2channel
Dp2int
comms
c1/com1channel
Dp1int
A2p3/Ap3channel
A2/A
Dp3int
A2p1/Ap1int
A2p2/Ap2int
Classification View
14
Example System Component Scenario
Roles of Valve Class
Connection with gt2 ends
Blue lines are Gas Red/Black are Power Green are
digital control
15
Use Cases

• Use cases are represented by collaborations
  (subtype of package) and template collaborations
• Collaboration roles can be used represent
  specific use case scenarios
• Shown on many diagrams, two forms
• As package symbol
• As use case symbol
• Subsystem (in SE terms) is a collaboration, not a
  classifier

16
Example Use Case Diagram
Package Extension
Class Generalization
For standard collaboration may represent
import/access For template collaboration may
represent actual parameter
Any Class (can use Class Symbol)
17
Collaborations on Sequence Diagrams

• Nested collaborations are a powerful mechanism
  for structuring scenarios
• Collaboration can have class/structure/action
  diagrams as well as sequence

Actor1
\A
\C
m1
ev
Collaboration
a2
a1
m

• Symbols that appear (even partially) within the
  boundary of Collaboration are imported or actual
  parameters to Collaboration
• Collaboration imports a1, a2 and m and uses them
  as anchors in its own action description
• Introduces a new role E and extra messages and
  actions

Collaboration
\A
\C
\E
a2
a1
m
m1
m2
18
Diagrams

• Concrete Syntax
• Extends diagram interchange model
• Default graphical symbols shown
• Mapping to abstract syntax including
  well-formedness rules
• Can display either elements or roles of those
  elements
• Structural
• Use Case
• Classification traditional class view
• Structure provides component-style view
• Behaviour
• State
• Activity
• Sequence
• Collaboration may redundant or become like
  Use-case Maps

19
Activity Diagram and Mapping
20
Component Diagram and Mapping
21
Deprecated Features

• Interface just pure class
• Node/Component/Artifact- either in specific
  extensions or just concrete syntax
• Subsystem just a collaboration?
• Actions this is a different approach to that
  taken in 1.4.1
• Messages on Collaboration diagrams may perhaps
  show actions and flows and messages, but not
  successor/predecessor relationship
• Signals now become equivalent to message
• Stereotypes now just metamodel extensions?

22
Meeting RfP Requirements

• Component-based development and the specification
  of run-time architectures
• Component model
• Generic scenario model
• Clarify the semantics of relationships
• Precise semantics for everything
• Support encapsulation and scalability in
  behavioral modeling
• Rationalised structure in behavioural model
• Generalisation of collaboration concept
• Remove restrictions on activity graph modeling
  (wrt to state machine)
• Common behavioural model superset of both

23
Conclusion

• The 2U Superstructure Proposal aims to
• Consolidate and simplify UML 1.4.1
• Make minimal additions consistent with meeting
  the RfP goals
• Define a precise semantics for all UML concepts
• Provide a precise definition of UML notation,
  mapped unambiguously to UML concepts
• Deprecate syntactic sugar and domain-specific
  concepts wherever possible