An Overview of UML 2.0 (And MDA)

An Overview of UML 2.0 (and MDA)

IMPORTANT DISCLAIMER!

The technical material described here is still under development and is subject to modification prior to full adoption by the Object Management Group

2 IBM Software Group |

1 Tutorial Objectives

1. To introduce the major new features of UML 2.0 2. To explain the design intent and rationale behind UML 2.0 3. To describe the essence of model-driven development (as realized with UML 2.0)

3 IBM Software Group |

Tutorial Overview

Introduction: Modeling and Dynamic Semantics Software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

4 IBM Software Group |

2 A Skeptic’s View of Software Models…

PH reached X start

Monitor Control ble Current PH PH ena PH

ble stop disa Raise PH Input valve control

“…bubbles and arrows, as opposed to programs, …never crash” -- B. Meyer “UML: The Positive Spin” American Programmer, 1997

5 IBM Software Group |

The Problem with Bubbles…

PH reached X start

Monitor Control ble Current PH PH ena PH

ble stop disa Raise PH Input valve control ?

main () { BitVector typeFlags (maxBits); char buf [1024]; cout << msg; while (cin >> buf) { if ...

6 IBM Software Group |

3 Models in Traditional Engineering As old as engineering (e.g., Vitruvius) Traditional means of reducing engineering risk

7 IBM Software Group |

What Engineers Do Before they build the real thing...

…they first build models…and then learn from them ➼

8 IBM Software Group |

4 Engineering Models Engineering model: A reduced representation of some system that is easier to understand than the actual system

Modeled system Model

9 IBM Software Group |

Characteristics of Useful Models Abstract Emphasize important aspects while removing irrelevant ones Understandable Expressed in a form that is readily understood by observers Accurate Faithfully represents the modeled system Predictive Can be used to derive correct conclusions about the modeled system Inexpensive Much cheaper to construct and study than the modeled system To be useful, engineering models must satisfy all of these characteristics!

10 IBM Software Group |

5 How Models are Used To detect errors and omissions and to determine key tradeoffs in complex designs before committing full resources to realization Through (formal) analysis and experimentation Investigate and compare alternative solutions Minimize engineering risk To communicate with stakeholders Clients, users, implementers, testers, documenters, etc. To drive implementation

11 IBM Software Group |

A Problem with Models

Semantic Gap due to: . . • Idiosyncrasies of actual . construction materials • Construction methods • Scaling effects • Skill sets • Misunderstandings Can lead to serious errors and discrepancies in the realization

12 IBM Software Group |

6 Models of Software

SC_MODULE(producer) SC_CTOR(consumer) { { sc_outmaster out1; SC_SLAVE(accumulate, in1); sc_in start; // to kick-start the sum = 0; // initialize the producer accumulator}}; void generate_data () SC_MODULE(top) // structural module { { for(int i =0; i <10; i++).{ producer *A1; out1 =i ; //this will invoke the slave;} consumer *B1; } sc_link_mp link1; SC_CTOR(producer) SC_CTOR(top) { { SC_METHOD(generate_data); A1 = new producer(“A1”); sensitive << start;}}; A1.out1(link1); SC_MODULE(consumer) B1 = new consumer(“B1”); { B1.in1(link1);}}; sc_inslave in1; int sum; // declare as a module state variable void accumulate (){ sum += in1; «sc_method» «sc_link_mp» «sc_slave» cout << “Sum = “ << sum << endl;} producer consumer start out1link1 in1

13 IBM Software Group |

Software Model Evolution: Adding Detail

void generate_data() «sc_method» producer {for (int i=0; i<10; i++) producer {out1 = I;}} start out1 NotStarted producer start/generate_data( )

NotStarted Started

start St1 St2 Started

Detail can be added continuously until the specification is complete

14 IBM Software Group |

7 The Remarkable Thing About Software

Software has the rare property that it allows us to directly evolve models into full-fledged implementations without changing the engineering medium, tools, or methods!

⇒ This ensures perfect accuracy of software models; since the model and the system that it models are the same thing The model is the implementation

15 IBM Software Group |

Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

16 IBM Software Group |

8 Model-Driven Style of Development (MDD) An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs) Implies automatic generation of programs from models Using modeling languages directly as implementation tools “The model is the implementation”

17 IBM Software Group |

Modeling versus Programming Languages Cover different ranges of abstraction

high ∆ : HI statecharts, interaction diagrams, architectural Modeling Level of structure, etc. Languages Abstraction (UML,…) Programming Languages (C/C++, Java, …) ∆ : LO data layout, arithmetical and logical operators, low etc.

18 IBM Software Group |

9 Covering the Full Range of Detail “Action” languages (e.g., Java, C++) for fine-grain detail

high

Modeling Level of Languages Abstraction (UML,…) Programming Fine-grain logic, Languages arithmetic (Any) Action implementation (C/C++, Java, …) formulae, level detail Language etc. (application specific) low

19 IBM Software Group |

Example Spec Appropriate languages for each abstraction level

Fine-grain S1 logic in a traditional 3G e1[q=5]/ e2/ language {d = msg->data(); High-level {printf(q);} parts described send(oa,5, d);} using high-level abstractions S2 Advantage: exploits S21 e32/ • Existing tools S21 • Code libraries

end/ • Developer experience {printf(“bye”);}

20 IBM Software Group |

10 How We Learn From Models

By inspection ? mental execution Ξ = cos (η + π/2) Ξ =+ cos ξ∗5(η + π/2) + ξ∗5 unreliable

By formal analysis ? Ξ = cos (η + π/2) mathematical methods Ξ =+ cos ξ∗5(η + π/2) + ξ∗5 reliable (theoretically) software is very difficult to ? model mathematically! By experimentation (execution) Ξ = cos (η + π/2) Ξ =+ cos ξ∗5(η + π/2) more reliable than inspection + ξ∗5 direct experience/insight

21 IBM Software Group |

MDD Implications Ultimately, it should be possible to: Execute models Translate them automatically into implementations …possibly for different implementation platforms Platform independent models (PIMs) Modeling language requirements The semantic underpinnings of modeling languages must be precise and unambiguous It should be possible to easily specialize a modeling language for a particular domain It should be possible to easily define new specialized languages

22 IBM Software Group |

11 OMG’s Model-Driven Architecture (MDA) An OMG initiative A framework for a set of standards in support of MDD Inspired by: The widespread public acceptance of UML and The availability of mature MDD technologies OMG moving beyond middleware (CORBA) Purpose: Enable inter-working between complementary tools Foster specialization of tools and methods Good overview paper: http://www.omg.org/cgi-bin/doc?ormsc/2001-07-01

23 IBM Software Group |

The Languages of MDA Set of modeling languages for specific purposes

UML “bootstrap” General Real-Time Standard UML profile For general OO MetaObject modeling Facility (MOF) EAI profile MOF Common “core” Warehouse Metamodel (CWM) Software process profile A modeling language For exchanging for defining modeling information languages about business data etc.

etc.

24 IBM Software Group |

12 The “4-Layer” Architecture

01011 <2 tons> 01011 01011 Real Objects (M0) <5 tons> (computer memory, run-time environment)

«modeledBy» «modeledBy» «modeledBy»

Customer CustomerOrder Model (M1) id item (model repository) quantity

«specifiedBy» «specifiedBy» . . . (M2 = UML, Class Association Meta-Model (modeling tool) CWM)

«specifiedBy»

Class(MOF) . . . Meta-Meta-Model (M3 = MOF) (modeling tool)

25 IBM Software Group |

UML: The Foundation of MDA

3Q2003 UML 2.0 (MDA)

UML 1.5 1Q2003 2001 UML 1.4 (action semantics) 1998 UML 1.3 (extensibility) 1997 UML 1.1 (OMG Standard)

1996 Rumbaugh Booch Jacobson

Foundations of OO (Nygaard, Goldberg, Meyer, Stroustrup, Harel, Wirfs-Brock, Reenskaug,…) 1967

26 IBM Software Group |

13 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

27 IBM Software Group |

UML 1.x: What Went Right Timeliness (meeting a real need) Emphasis on semantics as opposed to notation model-based approach (versus view-based) detailed semantic specifications Higher-level abstractions beyond most current OO programming language technology state machines and activity diagrams support for specifying inter-object behavior (interactions) use cases Customizability (extensibility)

28 IBM Software Group |

14 Traditional Approach to Views in Modeling Multiple, informally connected views Combined in the final (integration) phase of design

View 1 View 2

29 IBM Software Group |

UML Approach: Single Model Views are projections of a complete model Continuous integration of views with dynamic detection of inconsistencies

View 1 View 2

Well-formedness rules defined by the P2

UML metamodel Pn P1 Mapping rules System defined by the model UML spec

30 IBM Software Group |

15 Specializing UML Avoiding the PL/I syndrome (“language bloat”) UML standard as a basis for a “family of languages”

Using built-in extensibility mechanisms: UML Standard 1.x profiles, stereotypes, etc.

Real-Time UML UML for EDOC …..etc.

31 IBM Software Group |

UML 1.x: What Went Wrong? Does not fully exploit MDD potential of models E.g., “C++ in pictures” Inadequate modeling capabilities Business and similar processes modeling Large-scale systems Non-functional aspects (quality of service specifications) Too complex Too many concepts Overlapping concepts Inadequate semantics definition Vague or missing (e.g., inheritance, dynamic semantics) Informal definition (not suitable for code generation or executable models) No diagram interchange capability Not fully aligned with MOF Leads to model interchange problems (XMI)

32 IBM Software Group |

16 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Structure of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

33 IBM Software Group |

Sources of Requirements MDA (retrofit) Semantic precision Consolidation of concepts Full MOF-UML alignment Practitioners Conceptual clarification New features, new features, new features… Language theoreticians My new features, my new features, my new features… Why not replace it with my modeling language instead? Dilemma: avoiding the “language bloat” syndrome

34 IBM Software Group |

17 Formal RFP Requirements

1) Infrastructure – UML internals More precise conceptual base for better MDA support 2) Superstructure – User-level features New capabilities for large-scale software systems Consolidation of existing features 3) OCL – Constraint language Full conceptual alignment with UML 4) Diagram interchange standard For exchanging graphic information (model diagrams)

35 IBM Software Group |

Infrastructure Requirements Precise MOF alignment Fully shared “common core” metamodel Refine the semantic foundations of UML (the UML metamodel) Improve precision Harmonize conceptual foundations and eliminate semantic overlaps Provide clearer and more complete definition of instance semantics (static and dynamic) Improve extension mechanisms Profiles, stereotypes Support “family of languages” concept 36 IBM Software Group |

18 OCL Requirements

Define an OCL metamodel and align it with the UML metamodel OCL navigates through class and object diagrams ⇒ must share a common definition of Class, Association, Multiplicity, etc. New modeling features available to general UML users Beyond constraints Ability to express business rules General-purpose query language

37 IBM Software Group |

Diagram Interchange Requirements

Ability to exchange graphical information between tools Currently only non-graphical information is preserved during model interchange Diagrams and contents (size and relative position of diagram elements, etc.)

38 IBM Software Group |

19 Superstructure Requirements (1 of 2) More direct support for architectural modeling Based on existing architectural description languages (UML-RT, ACME, etc.) Reusable interaction specifications (UML-RT protocols) Behavior harmonization Generalized notion of behavior and causality Support choice of formalisms for specifying behavior Hierarchical interactions modeling Better support for component-based development More sophisticated activity graph modeling To better support business process modeling

39 IBM Software Group |

Superstructure Requirements (2 of 2) New statechart capabilities Better modularity Clarification of semantics for key relationship types Association, generalization, realization, etc. Remove unused and ill-defined modeling concepts Clearer mapping of notation to metamodel Backward compatibility Support 1.x style of usage New features only if required

40 IBM Software Group |

20 UML 2.0 Schedule

Single 2.0 standard at the end: For weeding out inconsistencies and implementation issues

Superstructure RFP Initial Submission Revised Sub. Phase 1 Adoption Finalization

Infrastructure RFP Initial Submission Revised Sub. Ph. 1 Adoption Finalization

Sep/00 Apr/01 Jun/01 Aug/01 Oct/01 Dec/01 Feb/02

Jan/03 Apr/03 Aug/03 May/04

41 IBM Software Group |

UML 2.0 Standardization Sequence Complex adoption process Step 1: Endorsement by OMG architecture board (June 2003) Step 2: OMG membership vote (September 2003?) Step 3: OMG BoD endorsement (October 2003?) • Spec becomes “Adopted Specification” At this stage, UML 2 articles, books, tools are likely Step 4: UML 2.0 Finalization Task Force (FTF) (April 2004) Step 5: OMG membership vote (September 2004?) Step 6: OMG BoD endorsement (October 2004?) • Spec becomes “Available Technology” (i.e., a standard) When is UML 2.0 an “official” standard? Two main phases: October 2003 and October 2004 It can change up to October 2004

42 IBM Software Group |

21 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

43 IBM Software Group |

First, the Politics Multiple competing submissions (5) Most involved consortia of companies representing both UML tool vendors and UML users One prominent (800-lb gorilla) submission team (“U2P”) with most of the major vendors (Rational, IBM, Telelogic, ...) and large user companies (Motorola, HP, Ericsson…) Over time: Some submissions lapsed Some submissions were merged into the U2P Currently there is just one submission

44 IBM Software Group |

22 U2P Submission Approach Evolutionary rather than revolutionary Improved precision of the infrastructure Small number of new features New feature selection criteria Required for supporting large industrial-scale applications Non-intrusive on UML 1.x users (and tool builders) Backward compatibility with 1.x

45 IBM Software Group |

Language Structure A core language + a set of optional “sub-languages” Defined in three separate compliance levels Multiple levels of compliance

Complete Level State Structured Activities Interactions Detailed Flows Machines Classes and Actions Components Intermediate Level MOF Profiles OCL

Basic Level Basic UML (Classes, Basic behavior, Internal structure, Use cases…) UML Infrastructure

46 IBM Software Group |

23 UML-MOF Alignment Shared conceptual base MOF: language for defining modeling languages UML: general purpose modeling language

UML Superstructure MOF Superstructure

UML «import»

«import» MOF

Infrastructure Library

47 IBM Software Group |

Infrastructure Library Shared between MOF and UML Boolean, Integer, String, ... Primitive Types «import» «import» Basic definition of Class concept Namespace, Classifier, Relationship, Abstractions Generalization, Basic …

«import» Extended notion of Class, Association, «import» Constructs Profiles

48 IBM Software Group |

24 Class Diagram Semantics Represent relationships between instances of classes

0..* 0..* Company Person employer employee

Formal (set theoretic) interpretation:

Set of all Set of all Companies Link Persons

. . . Cn Pm . . . C3 P1

C2 P2 C1 P3

Set: employee(s) of C1

49 IBM Software Group |

Generalization Semantics Subclasses = specialized subsets of parent Subclass inherits all features of the parent and may add its own Relationship between classes

Set of all instances of Shape Shape

position : Point . . . sp s3 . . . sn

s2 s1 Ellipse Polygon Spline

50 IBM Software Group |

25 Association Specialization Also used widely in the definition of the UML metamodel Avoids covariance problems

owner accounts Customer Account 0..1 *

Corporate company accounts Corporate Customer 1 * Account {subsets {subsets owner} accounts} Private owner accounts Private Customer 1 0..5 Account {subsets {subsets owner} accounts}

51 IBM Software Group |

Example: Classifier Definition Constructed from a Ownership basic set of primitive concepts Element

«import»

Namespace

Element Classifiers Namespace

NamedElement name : String NamedElement Classifier

«import» Feature Namespace

52 IBM Software Group |

26 Kinds of Classifiers The following are all kinds of Kinds of Behavior Classifier in UML 2.0: Activity Association (including Interaction AssociationClass) State Machine Class (including structured classes) Protocol State Machine Component Collaboration Interface Data Type Use Case Signal Behavior ! etc.

53 IBM Software Group |

Infrastructure: Consolidation of Concepts The re-factoring of the UML metamodel into fine-grained independent concepts Eliminates semantic overlap Provides a better foundation for a precise definition of concepts and their semantics Conducive to MDD

54 IBM Software Group |

27 Package Merge: Motivation In some cases we would like to modify a definition of a class without having to define a subclass To retain all the semantics (relationships, constraints, etc.) of the original

Library

Customer 1 * Customer Account name: String name: String

Customer Slightly extended MyCustomer definition of the age: Integer name: String Customer class age: Integer

55 IBM Software Group |

Package Merge: Semantics Incremental redefinition of concepts Library Extend

1 * Library:: 1 * Library:: Customer Account Customer Account name: String name: String

«merge»

Extend 1 * Customer Account name: String Customer age: Integer age: Integer

56 IBM Software Group |

28 Package Merge: Metamodel Usage Enables common definitions for shared concepts with the ability to extend them according to need E.g. MOF and UML definitions of Class

Infrastructure Library UML

«merge» 0..1 * Class Class Behavior

MOF

«merge» Class xmi ( )

57 IBM Software Group |

Summary: Foundations The language has been restructured and modularized Set of specialized languages Multiple levels of sophistication There have been significant “under the hood” changes to the UML metamodel More precise language definition (suitable for MDD) Much semantic overlap eliminated

58 IBM Software Group |

29 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

59 IBM Software Group |

Structured Classes: Background Intended for architectural modeling Concept of objects with internal and external structure (architectural objects) Used primarily for modeling complex systems/subsystems Desired structure is asserted rather than constructed Class constructor automatically creates desired structures Class destructor automatically cleans up Major boost to expressiveness, product reliability, developer productivity Heritage: architectural description languages (ADLs) UML-RT profile: Selic and Rumbaugh (1998) ACME: Garlan et al. SDL (ITU-T standard Z.100)

60 IBM Software Group |

30 Aren’t Class Diagrams Sufficient? No! Because they abstract out certain specifics, class diagrams are not suitable for performance analysis Need to model structure at the instance/role level

N2:Node

N1:Node 0..1 N3:Node Node right

N4:Node left 0..1

Same class diagram N1:Node N2:Node N3:Node describes both systems!

61 IBM Software Group |

Structured Classes: External Structure Complex objects with multiple “faces” Multiple interaction points: ports Each port is dedicated to a specific purpose and presents the interface appropriate to that purpose

Ports

62 IBM Software Group |

31 Ports Boundary objects that help separate different (possibly concurrent) interactions fully isolate an object’s internals from its environment

c : ClsX

S1 Environment S2

“There are very few problems in computer science that cannot be solved by adding an extra level of indirection”

63 IBM Software Group |

Port Semantics A port can support multiple interface specifications Provided interfaces (what the object can do) Required interfaces (what the object needs to do its job)

Incoming signals/calls «interface» MasterIF «provides» stateChange ( s : state ) : void … c:ClassX «interface» «uses» p1 SlaveIF start ( ) : void stop ( ) : void queryState ( ) : state … Outgoing signals/calls

64 IBM Software Group |

32 Ports: Alternative Notation Shorthand “lollipop” notation with 1.x backward compatibility

MasterIF

c:ClassX

SlaveIF

65 IBM Software Group |

Protocols: Reusable Interaction Sequences Communication sequences that Conform to a pre-defined dynamic order Are defined generically in terms of role players E.g., fax call protocol

sender receiver Call

AckCall (parms)

XRparms(parms) loop Data

AckData

Hangup

AckHangup

66 IBM Software Group |

33 Modeling Protocols with UML 2.0 A collaboration structure with interactions

FaxCallProtocol

sender receiver Call «interface» «interface» FaxSender AckCall (parms) FaxReceiver

Xrparms(par) Call( ) AckCall(par) CallParms( ) AckData( ) loop Data Data( ) AckHangup( ) AckData Hangup( )

Hangup

AckHangup

sender receiver

67 IBM Software Group |

Associating Protocols with Ports Ports play individual protocol roles Ports assume the protocol roles implied by their provided and required interfaces

«interface» «interface» FaxSender FaxReceiver

Call( ) AckCall(par) CallParms( ) AckData( ) Data( ) AckHangup( ) Hangup( )

«provides»

sender receiver

«uses» Fax

68 IBM Software Group |

34 Assembling Communicating Objects Ports can be joined by connectors to create peer collaborations composed of structured classes

remote sender : Fax receiver : Fax remote

Connectors model communication channels A connector is constrained by a protocol Static typing rules apply (compatible protocols)

69 IBM Software Group |

Structured Classes: Internal Structure Structured classes may have an internal structure of (structured class) parts and connectors

Delegation connector

sendCtrl receiveCtrl

c c

remote sender:Fax receiver:Fax remote

FaxCall

Part

70 IBM Software Group |

35 Structure Refinement Through Inheritance For product families with a common architecture

/sender:Fax /receiver:Fax

AbsFaxCall

/sender:Fax /receiver:Fax /sender:Fax /receiver:Fax

T1FaxCall T2FaxCall

71 IBM Software Group |

Components A kind of structured class whose specification May be realized by one or more implementation classes May include any other kind of packageable element (e.g., various kinds of classifiers, constraints, packages, etc.)

(Structured) Class

0..1 * 0..1 * Packageable Component Realization Element

Class

72 IBM Software Group |

36 Subsystems A system stereotype of Component («subsystem») such that it may have explicit and distinct specification («specification») and realization («realization») elements Ambiguity of being a subclass of Classifier and Package has been removed (was intended to be mutually exclusive kind of inheritance) Component (specifications) can contain any packageable element and, hence, act like packages

73 IBM Software Group |

74 IBM Software Group |

37 Dynamic Modeling Concepts

Structure-Behavior Classes Dependency

Shared Behavior Semantics Different Behavior Formalisms Common Behaviors

Activities Interactions StateMachines UseCases

Actions

75 IBM Software Group |

Structure and Behavior Structure is the context for all behavior:

Obj1 Obj2 Object behavior s1 s1 (statechart)

s2 s2

Obj3

Inter-object behavior (interaction)

76 IBM Software Group |

38 How Things Happen in UML An action is executed May change the value of one or more variables or object attributes If it is a “messaging” action, it may: • Invoke an operation on another object • Send a signal to another object • Either one will eventually cause the execution of a procedure on the target object… • …which will cause other actions to be executed, etc. Successor actions are executed • May be controlled by control flow

77 IBM Software Group |

Common Behavior Metamodel

Classifier Class (from Kernel ) (from Kernel )

+ownedBehavior 0..1 {subsets ownedMember} {ordered, subsets ownedMember} BehavioredClassifier Behavior 0..1 +parameter +context Parameter * isReentrant : Boolean (from Kernel) * +classifierBehavior 0..1 {subsets ownedBehavior} +/formalParameter 0..1 0..1 {ordered} *

+/returnResult +specification +method {ordered} BehavioralFeature 0..1 * isAbstract : Boolean 0..1 *

* +redefinedBehavior {subsets redefinedElement}

Activity body : String language : String

78 IBM Software Group |

39 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

79 IBM Software Group |

Overview of New Features Interactions focus on the communications between collaborating instances communicating via messages Both synchronous (operation invocation) and asynchronous (signal sending) models supported Multiple concrete notational forms: sequence diagram communication diagram interaction overview diagram timing diagram interaction table

80 IBM Software Group |

40 Example: Interaction Context All interactions occur in structures of collaborating parts the structural context for the interaction

Interaction Context: Structured Class or Collaboration GoHomeServiceContext ServiceUser

sd GoHome sd Authorization Interactions

ServiceBase :ServiceUser :ServiceTerminal Internal Structure

:ServiceBase ServiceTerminal Part

81 IBM Software Group |

Interaction Occurrences

Interaction Frame Lifeline is one object or a part

sd GoHomeSetup Interaction Occurrence

:ServiceBase :ServiceUser :ServiceTerminal ref SB_GoHomeSetup

ref Authorization sd Authorization

opt :ServiceBase :ServiceUser :ServiceTerminal ref SB_Authorization ref FindLocation Code

SetHome OK OnWeb

SetInvocationTime OK

SetTransportPreferences

Combined (in-line) Asynchronous Fragment message (signal)

82 IBM Software Group |

41 Structural Decomposition in Sequence Diagrams

Detailed Decomposed lifeline context

ServiceBase

sd sd SB_GoHomeSetup SB_Authorization

sd GoHomeSetup :Central :Authorizer

:ServiceBase :ServiceUser :ServiceTerminal ref SB_GoHomeSetup :TimeKeeper

ref Authorization sd SB_GoHomeSetup opt

ref FindLocation :Central :TimeKeeper

SetHome ref SB_Authorization

SetInvocationTime opt SetTransportPreferences

SetHome

Decomposition with SetInvocationTime global constructs

corresponding to SetTransportPreferences those on decomposed lifeline

83 IBM Software Group |

Combined Fragments and Data

sd GoHomeInvocation(Time invoc)

:ServiceUser :Clock :ServiceBase :ServiceTerminal loop [Now>invoc] InvocationTime FindLocation

TransportSchedule Choice loop alt [Now>interv+last]

ScheduleIntervalElapsed Operand FindLocation Separator TransportSchedule

[pos-lastpos>dist] GetTransportSchedule

TransportSchedule

FetchSchedule

Guarding Data Constraint

84 IBM Software Group |

42 Combined Fragment Types (1 of 2) Alternatives (alt) choice of behaviors – at most one will execute depends on the value of the guard (“else” guard supported) Option (opt) Special case of alternative Break (break) Represents an alternative that is executed instead of the remainder of the fragment (like a break in a loop) Parallel (par) Concurrent (interleaved) sub-scenarios Negative (neg) Identifies sequences that must not occur

85 IBM Software Group |

Combined Fragment Types (2 of 2) Critical Region (region) Traces cannot be interleaved with events on any of the participating lifelines Assertion (assert) Only valid continuation Loop (loop) Optional guard: [, , ] No guard means no specified limit

86 IBM Software Group |

43 Interaction Overview Diagram An interaction with the syntax of activity diagrams

sd GoHomeSetup

ref Authorization

Interaction Occurrence

ref FindLocation

:ServiceUser :ServiceBase

SetHome Expanded sequence diagram

:ServiceUser :ServiceBase

SetInvocationTime

SetTransportPreferences

87 IBM Software Group |

Timing Diagrams Can be used to specify time-dependent interactions Based on a simplified model of time (use standard “real-time” profile for more complex models of time)

sd DriverProtocol

Idle Wait Busy Idle d : Driver

0111 0011 0001 0111 o : OutPin

t = 0 t = 5 t = 10 t = 15

88 IBM Software Group |

44 Timing Diagrams (cont.)

Constraint State

sd Reader {d..d+0.5}

Reading

r : Reader Idle Read ReadDone Read {t1..t1+0.1}

Uninitialized Initialize Event Occurrence

Observation

89 IBM Software Group |

90 IBM Software Group |

45 Actions in UML Action = fundamental unit of behavior for modeling fine-grained behavior Level of traditional programming languages UML defines: A set of action types A semantics for those actions • i.e. what happens when the actions are executed In general, no specific standard notation for actions • a few exceptions, e.g., “send signal” This provides a flexibility to use any language to realize the semantics In UML 2, the metamodel of actions was consolidated Shared semantics between actions and activities (Basic Actions)

91 IBM Software Group |

Shared Action/Activity Semantics Data/control flow foundations for maximal implementation flexibility OutputPin Control Flow (typed) ActivityM

. . . Action2 . . . .

...... Action1 ...... Action3 .

Input Pin (typed) VariableA

Data Flow

92 IBM Software Group |

46 Categories of Actions Communication actions (send, call, receive,…) Primitive function action Object actions (create, destroy, reclassify,start,…) Structural feature actions (read, write, clear,…) Link actions (create, destroy, read, write,…) Variable actions (read, write, clear,…) Exception action (raise)

93 IBM Software Group |

General Notation for Actions No specific symbols (some exceptions)

«precondition» {port.state > 0}

for(int i = 0; i send (sig) ia[i] = i++;

«postcondition» {port.state > 1} alternatives

sig on portP

94 IBM Software Group |

47 Activities Significantly enriched in UML 2.0 (relative to UML 1.x activities) More flexible semantics for greater modeling power (e.g., rich concurrency model based on Petri Nets) Many new features Major influences for UML 2.0 activity semantics Business Process Execution Language for Web Services (BPEL4WS) – a de facto standard supported by key industry players (Microsoft, IBM, etc.) Functional modeling from the systems engineering community (INCOSE)

95 IBM Software Group |

Activity Graph Example

parameter contracts Interruptible Region

Order Processing «precondition» Order entered Invoice : InvoiceKind «postcondition» Order complete

Order cancel Cancel request Input order pin

Ship Receive Fill Close Order order order order order

Send Make Accept Invoice invoice payment payment

96 IBM Software Group |

48 “Unstructured” Activity Graphs Not possible in 1.x

97 IBM Software Group |

Partitioning capabilities

Seattle Reno

Ship Receive Fill Close order order order order OrderDepartment Company

Send Accept invoice payment Accounting

Invoice

Make payment Customer

98 IBM Software Group |

49 Activities: Basic Notational Elements

Control/Data Flow Control Fork

Activity or Action Control Join

Object Node (may include state) Initial Node

Pin (Object) Activity Final

Choice

Flow Final

(Simple) Join

99 IBM Software Group |

Extended Concurrency Model Fully independent concurrent streams (“tokens”)

Concurrency fork Concurrency join

B C

A Z X Y

Trace: A, {(B,C) || (X,Y)} , Z “Tokens” represent individual execution threads (executions of activities)

NB: Not part of the notation

100 IBM Software Group |

50 Activities: Token Queuing Capabilities Tokens can queue up in “in/out” pins. backup in network. prevent upstream behaviors from taking new inputs.

Activity 2 Activity 3

…or, they can flow through continuously taken as input while behavior is executing given as output while behavior is executing identified by a {stream} adornment on a pin or object node

101 IBM Software Group |

102 IBM Software Group |

51 State Machine Improvements New modeling constructs: Modularized submachines State machine specialization/redefinition State machine termination “Protocol” state machines • transitions pre/post conditions • protocol conformance Notational enhancements action blocks state lists

103 IBM Software Group |

Modular Submachines: Definition

Submachine definition

ReadAmountSM

abort EXIT point otherAmount selectAmount

amount abort EnterAmount aborted

again

ENTRY point

104 IBM Software Group |

52 Modular Submachines: Usage

invoked submachine ATM VerifyCard

acceptCard

outOfService ReadAmount : aborted OutOfService ReadAmountSM

again usage of exit point rejectTransaction releaseCard VerifyTransaction ReleaseCard usage of entry point

105 IBM Software Group |

Specialization Redefinition as part of standard class specialization

ATM Behaviour Statemachine acceptCard() outOfService() amount()

FlexibleATM Behaviour Statemachine otherAmount() rejectTransaction()

106 IBM Software Group |

53 Example: State Machine Redefinition State machine of ATM to be redefined

ATM VerifyCard {final} acceptCard ReadAmount

OutOfService outOfService selectAmount {final} amount

releaseCard VerifyTransaction ReleaseCard {final} {final}

107 IBM Software Group |

State Machine Redefinition

ATM {extended} FlexibleATM VerifyCard {final} acceptCard ReadAmount {extended} otherAmount OutOfService outOfService selectAmount {final} amount enterAmount reject ok

releaseCard VerifyTransaction ReleaseCard {final} {final}

108 IBM Software Group |

54 Protocol State Machines For imposing sequencing constraints on interface usage (should not be confused with multi-party protocols)

ready ( ) Landed Ready

land ( ) [cleared] takeOff ( ) / [gearRetracted] Flying Equivalent to pre and post conditions added to the related operations: takeOff() Pre -in state ”Ready" -cleared for take off Post -landing gear is retracted -in state ”Flying"

109 IBM Software Group |

Notational Enhancements Alternative transition State lists notation

Idle VerifyCard, logCard Logged ReleaseCard

[ID<=10] [ID>10] Is a notational shorthand for MinorReq=Id; MajorReq=Id;

VerifyCard logCard Minor(Id) Major(Id) Logged ReleaseCard logCard Busy

110 IBM Software Group |

55 Introduction: modeling and Dynamic Semantics software Interaction Modeling Model-Driven Development Capabilities A Critique of UML 1.x Activities and Actions Requirements for UML 2.0 State Machine Innovations Foundations of UML 2.0 Other New Features Architectural Modeling Summary and Conclusion Capabilities

111 IBM Software Group |

Specializing UML Lightweight extensions Extend semantics of existing UML concepts by specialization Conform to standard UML (tool compatibility) Profiles, stereotypes, tagged values Heavyweight (MOF) extensions Add new non-conformant concepts or Incompatible change to existing UML semantics/concepts

Standard UML Semantics

Heavyweight Lightweight extension M extension

112 IBM Software Group |

56 Stereotyping versus Inheritance For semantics not expressible through standard UML mechanisms Stereotypes can be standardized (application independent)

Instance of the UML Class concept

Integer «clock» Stereotype of Class with added semantics: an active counter whose value changes synchronously with the progress of physical time

«clock» Stereotype-specific attribute MyClockClass {resolution = 500 ns} SetTime( )

113 IBM Software Group |

Profiles: Metamodel Semantically equivalent to 1.x from a user’s perspective But, new notation introduced Extension concept: a form of “specialization” of metaclasses

Package PackageImport Class Association Property (from Constructs) (from Constructs) (from Constructs) (from Constructs) (f ro m Co n st ru ct s)

appliedProfile ProfileApplication Extension Ext ensionEnd Package {subsets packageImport} Class /metaclass /extension ownedEnd / isRequired : Boolean / 1 * 1 * 1 1 * *

importedProfile Profile 1 {subsets importedPackage} Stereotype type ownedStereotype 1 1 {subsets ownedMember} *

metaclassReference ElementImport (from Constructs) 0..1 {subsets elementImport} *

metamodelReference PackageImport (from Constructs) 0..1 {subsets packageImport} *

114 IBM Software Group |

57 Profiles: Example Extension of the Components concept for standard component technologies Extension «profile» SimpleEJB

«metaclass» «stereotype» Component Bean

«stereotype» «stereotype» Entity Session

115 IBM Software Group |

Templates More precise model than UML 1.x Limited to Classifiers, Packages, and Operations Template parameter Template signature T > Number, k : IntegerExpression NumericArray Template arrayElement : T [k] binding

Class(ifier) template «bind» Integer, k -> 10> “Bound” class IntegerArray arrayElement : Integer [10]

116 IBM Software Group |

58 Collaboration Templates Useful for capturing design patterns

ObserverPattern oType, sType

subject : sType observer : oType

Collaboration template «bind» DeviceObserver

ObserverPattern DevicePoller, sType>Device>

117 IBM Software Group |

Package Templates Based on simple string substitution

CustomerAccountTemplate customer : StringExpression, kind : StringExpression

owner $Acct$ $ $$ 1..* 0..* Account$

«bind» Person, Name kind -> Personal Expression SavingsBank

owner PersonalAcct Personal Person 1..* 0..* Account

118 IBM Software Group |

59 Information Flows For specifying exchanges of information items between active entities at a very abstract level Do not specify details of the information (e.g., type) Do not specify how the information is relayed Do not specify the relative ordering of information flows

Customer «flow» «flow» Employee product wages

Company

119 IBM Software Group |

120 IBM Software Group |

60 Summary: Model-Driven Development Software has a unique advantage when it comes to using engineering models for development Seamless progression from design to product MDD has already indicated that it can significantly improve the reliability and productivity of software development Proven technologies Dedicated standards Increased use of automation The OMG has responded to this potential with the MDA initiative MOF and UML are two core OMG standard technologies that are part of MDA

121 IBM Software Group |

Summary: UML 2.0 First major revision of UML Original standard had to be adjusted to deal with MDD requirements (precision, code generation, executability) UML 2.0 characterized by Small number of new features + consolidation of existing ones Scaleable to large software systems (architectural modeling capabilities) Modular structure for easier adoption (core + optional specialized sub- languages) Increased semantic precision and conceptual clarity Suitable foundation for MDA (executable models, full code generation)

122 IBM Software Group |

61 QUESTIONS? ([email protected])

123 IBM Software Group |