An Overview of UML 2.0

An Overview of UML 2.0 : An Overview of UML 2.0 Bran Selic IBM Rational Software bselic@ca.ibm.com

Overview : Overview Introduction: software modeling, model-driven development, and MDA UML 2.0: requirements, philosophy, and structure Salient features: Modeling software architectures Modeling complex interactions Process modeling capabilities (activities) Other important features

Why Engineers Build Models : Why Engineers Build Models It’s all about understanding complex systems… A model is a reduced version of a system that emphasizes the essential and obscures the irrelevant  abstraction To detect errors and omissions in requirements and solutions before committing resources to full-fledged implementation To communicate with stakeholders Clients, users, implementers, testers, documenters, etc. To guide the implementation For software systems, this has special significance

Characteristics of Useful Models : Characteristics of Useful Models Abstract Emphasize important aspects while hiding/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 Most software models of the past failed on one or more of these points!

Models of Software : Models of Software

Model Evolution: Adding Detail : Model Evolution: Adding Detail Detail can be added continuously until the specification is complete

The Remarkable Thing About Software : 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; the model and the modeled system are identical The model becomes the implementation

Slide8 : Model-Driven Development and MDA

Model-Driven Style of Development : Model-Driven Style of Development An approach to software development in which the focus and primary artifacts of development are models (as opposed to programs) Working closer to the problem domain rather than the implementation (technology) domain Enables platform (technology) independence Based on increased use of automation Automatic generation of programs from models (= model compilation) Computer executable models

Modeling Language Requirements for MDD : Modeling Language Requirements for MDD The semantic underpinnings of modeling languages must be precise It should be possible to easily specialize a modeling language for a particular domain UML profiles It should be possible to easily define new specialized languages Meta-Object Facility (MOF): a standardized language for defining new modeling languages A small subset of UML

Model Driven Architecture (MDA) Initiative : Model Driven Architecture (MDA) Initiative The success of UML and the availability of mature commercial MDD technologies have led the OMG to formulate the MDA initiative A strategic plan for a set of standards to support MDD Standard modeling languages and profiles Model transformation (compilation) standards Model versioning and related standards UML 2.0 and MOF 2.0 are at the core of MDA

The Languages of MDA : The Languages of MDA For general OO modeling For exchanging information about business data UML “bootstrap”

Slide13 : The Unified Modeling Language – version 2.0

IMPORTANT DISCLAIMER! : IMPORTANT DISCLAIMER! The technical material described here is still under development and is subject to modification prior to adoption by the OMG

UML 2.0 Definition Process : UML 2.0 Definition Process Started in October 2000 Multiple submission teams One submission at the end (April 2003) Over 50 companies, academic and research institutions participated First phase of adoption commenced in June 2003 Single submission accepted as basis for UML 2.0 by OMG members Finalization: allows implementors and users to review and provide feedback to OMG (April 2004) Anticipated final adoption: June 2004

UML 2.0 Characteristics : UML 2.0 Characteristics More precise and consolidated semantics definition Necessary capability for MDD (automatic code generation and executable models) Consolidation (e.g., common semantic model of behavior) Number of new features intentionally kept small Features required for modeling large-scale software systems Non-intrusive on UML 1.x users and tool builders Backward compatibility with 1.x Vast majority of 1.x models (>90%) should be automatically convertible to 2.0

Formal RFP Requirements : Formal RFP Requirements Infrastructure – UML internals More rigorous definition of semantic undeprinnings Superstructure – User-level features New capabilities for large-scale software systems Consolidation of existing features OCL – Constraint language Full conceptual alignment with UML Diagram interchange standard For exchanging diagram information

Language Structure : Language Structure A core language + a set of optional “sub-languages” OCL Basic UML (Classes, Basic behavior, Internal structure, Use cases…) MOF Profiles UML Infrastructure

Slide19 : Structured Classes and Protocols: UML as an Architectural Description Language

Structured Classes: External View : Structured Classes: External View Distributed active (concurrent) objects with Full two-way encapsulation Multiple interaction points: ports

New Feature: Ports : c : ClsX S1 S2 New Feature: Ports Boundary objects that help separate different (possibly concurrent) interactions fully isolate an object’s internals from its environment

Port Semantics : 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 Outgoing signals/calls MasterIF SlaveIF

Assembling Communicating Objects : Connectors model communication channels A connector is constrained by a protocol Static typing rules apply (compatible protocols) remote remote Assembling Communicating Objects Ports can be joined by connectors to create peer collaborations composed of structured classes

Structured Classes: Internal Structure : FaxCall receiveCtrl sendCtrl remote remote c c Structured Classes: Internal Structure Structured classes may have an internal structure of (structured class) parts and connectors Delegation connector Part

Product Family Architectures : Product Family Architectures Using standard inheritance mechanism (design by difference)

Slide26 : Modeling Complex Interactions

Interaction Diagrams : sd ATM-transaction client: atm: dbase: Interaction Diagrams insertCard CheckPin ref alt [chk= OK] [else] error(badPIN) DoTransaction ref sd CheckPin client: atm: dbase: askForPIN data(PIN) check(PIN) result(chk) result(chk) Interaction Frame Lifeline is one object or a part Interaction Occurrence Combined (in-line) Fragment

Combined Fragments and Data : Combined Fragments and Data loop Choice Operand Separator Guarding Data Constraint parameter

Combined Fragment Types (1 of 2) : 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

Combined Fragment Types (2 of 2) : 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

Interaction Overview Diagram : Interaction Overview Diagram Flow-chart like composition of interaction specifications Can mix and match different forms (sequence, collaboration interactions)

Timing Diagrams (cont.) : sd Reader r : Reader t1 Timing Diagrams (cont.) State Event Occurrence Constraint Observation

Protocols: Reusable Interaction Sequences : 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

Modeling Protocols with UML 2.0 : Modeling Protocols with UML 2.0 A collaboration structure with interactions Call AckCall (parms) Xrparms(par) AckData Data AckHangup Hangup loop sd FaxCall

Protocols with Ports : Protocols with Ports Ports play protocol roles based on their interfaces «provides» «uses»

Slide36 : Dynamic Process Modeling Capabilities (Activities)

Activities : 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) 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) A significant increase in the use of activity diagrams is anticipated

Activity Graph Example : Activity Graph Example Order Cancel order Interruptible Region Order Processing Invoice : InvoiceKind Input pin «precondition» Order entered «postcondition» Order complete contracts parameter

“Unstructured” Activity Graphs : “Unstructured” Activity Graphs Not possible in 1.x A3 A2

Partitioning capabilities : Partitioning capabilities Company

Activities: Execution Models : Activity 2 Activity 1 Activities: Execution Models Activity executions (tokens) can Be mutually exclusive Or concurrent (identified by a {stream} adornment on a pin or object node)

Slide42 : Some Other Important Features

Example: State Machine Redefinition : Example: State Machine Redefinition State machine of ATM to be redefined VerifyCard ReadAmount selectAmount acceptCard ReleaseCard VerifyTransaction selectAmount amount outOfService releaseCard OutOfService ATM {final} {final} {final} {final}

State Machine Specialization : VerifyCard acceptCard ReleaseCard VerifyTransaction outOfService releaseCard OutOfService ATM {final} {final} {final} {final} ReadAmount selectAmount amount State Machine Specialization Subclass state machine

Action Semantics : Action Semantics For specifying fine-grained behavior Only semantics are defined but no syntax Allows implementation using any programming language Integrated with rest of UML Consolidated with other forms of behavior (activities, statecharts, etc.) Categories of Actions in UML 2.0: 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)

Notation for Actions : Notation for Actions No specific symbols (some exceptions) alternatives

Summary : Summary Model-driven methods and technologies have matured and are being used successfully today in large-scale industrial apps Greater use of automation – but no real change in method Significant increases in productivity and reliability The “next generation” UML is characterized by: Scalability to large software systems (e.g., architectural modeling capabilities) Increased semantic precision and conceptual clarity Suitable foundation for MDA (executable models, full code generation)

Slide49 : Bran Selic bselic@ca.ibm.com