210 likes | 386 Vues
An Introduction to UML 2.0. Bran Selic IBM Distinguished Engineer IBM Rational Software – Canada bselic@ca.ibm.com. UML: The Foundation of MDA. 3Q2004. UML 1.5. Rumbaugh. Booch. Harel. Jacobson. UML 1.4 (action semantics). UML 1.3 (extensibility). UML 1.1 (OMG Standard). 1Q2003. 1997.
E N D
An Introduction to UML 2.0 Bran SelicIBM Distinguished EngineerIBM Rational Software – Canadabselic@ca.ibm.com
UML: The Foundation of MDA 3Q2004 UML 1.5 Rumbaugh Booch Harel Jacobson UML 1.4 (action semantics) UML 1.3 (extensibility) UML 1.1 (OMG Standard) 1Q2003 1997 1998 1996 2001 1967 UML 2.0 (MDA) Foundations of OO (Nygaard, Goldberg, Meyer,Stroustrup, Harel, Wirfs-Brock, Reenskaug,…)
Formal RFP Requirements • Infrastructure – UML internals • More precise conceptual base for better MDA support • 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 graphic information (model diagrams)
Language Structure Complete Level StateMachines StructuredClasses andComponents Activities Interactions DetailedActions Flows Intermediate Level Basic Level • A core language + a set of optional “sub-languages” • Defined in three separate compliance levels Multiple levels of compliance MOF Profiles OCL Basic UML(Classes, Basic behavior, Internal structure, Use cases…) UML Infrastructure
Infrastructure Example: Classifier Definition Ownership Element «import» Namespace Element Classifiers Namespace NamedElement NamedElement Classifier name : String «import» Feature Namespace • Constructed from a basic set of primitive concepts
UML 2.0: Run-Time Semantics . . . Actions Activities StateMachines BehaviorFoundation Interactions(Communications) Basic Structural Concepts
Behavioral Foundations ActivityM Action2 . . . . . . . . . Action1 . . . . . . . . . Action3 . . . . . . VariableA • Data/control flow foundations for maximal implementation flexibility Control Flow OutputPin(typed) Input Pin(typed) Data Flow
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)
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)
Activity Graph Example Order ProcessingInvoice : InvoiceKind Cancelorder Shiporder Receiveorder Fillorder Closeorder Order Sendinvoice Makepayment Acceptpayment Invoice Ordercancelrequest parameter contracts InterruptibleRegion «precondition» Order entered «postcondition» Order complete Inputpin
Interaction Diagrams sd ATM-transaction sd CheckPin client: atm: dbase: result(chk) result(chk) askForPIN check(PIN) insertCard data(PIN) client: atm: dbase: ref ref [chk= OK] DoTransaction CheckPin error(badPIN) alt [else] Interaction Frame Lifeline is one object or a part Interaction Occurrence Combined (in-line) Fragment
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) • Critical Region (region) • Traces cannot be interleaved with events on any of the participating lifelines • Assertion (assert) • Only valid continuation • Loop (loop) • Optional guard: [<min>, <max>, <Boolean-expression>] • No guard means no specified limit
Structured Classes • Classes with • Internal (collaboration) structure • Ports (optional) • Primarily intended for architectural modeling • Heritage: architectural description languages (ADLs) • UML-RT profile: Selic and Rumbaugh (1998) • ACME: Garlan et al. • SDL (ITU-T standard Z.100)
Structured Objects: Ports • Multiple points of interaction • Each dedicated to a particular purpose e.g., Database Object e.g., Database Admin port e.g., Database User ports
Port Semantics «interface»SlaveIF «interface»MasterIF start ( ) : voidstop ( ) : voidqueryState ( ) : state… stateChange ( s : state ) : void… «provides» c:ClassX «uses» p1 • 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
Assembling Structured Objects sender : Fax receiver : Fax remote remote FaxSender FaxReceiver :FaxProtocol • These connections can be constrained to a protocol • Ports can be joined by connectors • Static checks for dynamic type violations are possible • Eliminates “integration” (architectural) errors
Structured Classes: Internal Structure c c remote sender:Fax sendCtrl receiver:Fax receiveCtrl remote • Structured classes may have an internal structure of (structured class) parts and connectors Delegation connector FaxCall Part
Structure Refinement Through Inheritance sender:Fax receiver:Fax ProductArchitecture mgr:FaxMgr sender:Fax receiver:Fax sender:Fax receiver:Fax ProductB ProductA • Using standard inheritance mechanism (design by difference)
Summary: UML 2.0 • First major revision of UML • Primarily motivated by the need to better support MDD • Characterized by • Modular language structure • Increased semantic precision and conceptual clarity • Recursive concepts definition for scalability • Small number of new modeling features – selected to better support scalability • Structured classes for architectural specifications • Complex and reusable interactions modeling • Sophisticated functional modeling capabilities (activities)
QUESTIONS? (bselic@ca.ibm.com)