A Brief Overview of the Unified Modeling Language

1. A Brief Overview of the Unified Modeling Language Bran SelicObjecTime Limited bran@objectime.com Rev.2

2. Overview • Introduction • The Object Paradigm • Modeling with the UML • Summary

3. What is the UML? 1996 OMT (Rumbaugh et al.) UML 0.9 UML 1.1 UML 1.4 Nov. 1997 Mar. 1999 OOSE (Jacobson et al.) Booch • General-purpose OO modeling language • convergence of a number of popular OO methods Catalysis ROOM etc.

4. Inside the Standard • Semi-formal semantic meta model • defines the basic modeling concepts • object, class, association, etc. • includes formal well-formedness rules expressed as constraints in the Object Constraint Language (OCL) • Graphical notation for modeling concepts • 8 different diagram types • Two predefined domain extensions

5. Introduction • The Object Paradigm • Modeling with the UML • Summary

6. A Brief History of Objects • 1967: Simula programming language • 1970’s: Smalltalk programming language • 1980’s: Theoretical foundations, C++, Objective-C, etc. • 1990’s: Object-oriented analysis and design methodologies (Booch, OMT, ROOM, etc.), Java • 1997: The Unified Modeling Language (UML) standardized by the Object Management Group (OMG)

7. The Object Paradigm • A synergistic combination of various proven techniques including: • encapsulation • inheritance • polymorphism/genericity • Salient characteristic: a software system is rendered as a structure of collaborating parts • the object paradigm is inherently structural

8. Structure • The individual parts of a system and their run-time topological relationships • Fundamental structural relationship types: • Containment (strong and weak) composition (strong) aggregation (weak) • Layering • Communication (links)

9. Objects void:offHook (); {busy = true; reqDialtone(); … }; • Entities that model some physical or conceptual entity • a unique identity (dedicated memory) • the conceptual becomes physical! • a public interface • a hidden (encapsulated) implementation methods public attributes Telephone1: +busy : boolean public operations +offHook() +onHook () +ring()

10. Conceptual Objects Telephone1 Telephone2 Telephone Call Telephone Call Object • Not all objects necessarily require a physical underpinning • For example, the “telephone call” object: abortCall () addParty (t:Telephone) reportDuration ()

11. Classes and Instances Telephone phone1:Telephone phone2:Telephone busy : boolean busy = true busy = false offHook() onHook () ring() offHook() onHook () ring() offHook() onHook () ring() • Design-time specifications for one or more distinct objects with a common form (structure and behavior) instance (run time) class (design time)

12. Object Behavior void:offHook (); {busy = true; obj.reqDialtone(); … }; • Simple basic reactive server model: InitializeObject Handling depends on specific request type and object state Wait forRequest HandleRequest Invokes operations on other objects TerminateObject

13. Programming Model 3.sendTone() 2.call() PhoneIF: CallProc: ToneGen: 1.offHook() 4.dialtone() • Combining objects into object structures

14. Object “Engines” InitializeObject Wait forRequest InitializeObject HandleRequest Wait forRequest HandleRequest TerminateObject TerminateObject • Passive objects: depend on external motive power (e.g., “main” program thread) • Active objects: self-powered (own thread of execution)

15. Inheritance and Polymorphism TelephoneClass RotaryDialTelephoneClass busy : boolean busy : boolean TouchToneTelephoneClass offHook() onHook () dialDigit() offHook() onHook () dialDigit() Polymorphism: an operation implemented differently in different classes busy : boolean offHook() onHook () dialDigit() playTone() • Generalization and re-use mechanisms Generalization (inheritance) association

16. Introduction • The Object Paradigm • Modeling with the UML • Summary

17. Why Build Models? • To understand the problem better • To communicate with stakeholders • To find errors or omissions • To plan out the design • To generate code

18. UML Model Views • Requirements (use case diagrams) • Static structure (class diagrams) • kinds of objects and their relationships • Dynamic behavior (state machines) • possible life histories of an object • Interactive behavior (activity, sequence, and collaboration diagrams) • flow of control among objects to achieve system-level behavior • Physical implementation structures (component and deployment diagrams) • software modules and deployment on physical nodes

19. Class Diagram - Static Structure FinancialInstitution client creditor 0..* 0..* owner 0..* Mortgage principal rate term Bank TrustCompany 0..* 1 • Shows the entities in a system and their general relationships association class Person generalization association residence 0..* {ordered} House

20. Object Instance Diagram RoyalBank : Bank JoeYu:Person first : Mortgage second : Mortgage cottage : House home : House • Shows object instances in a particular case link

21. State Machine Diagram InitializeObject Wait forEvent created start/^master.ready() HandleEvent ready stop/ poll/^master.ack() TerminateObject • Each state corresponds to a selective receive action state machine initial state state trigger action expression final state transition

22. State Machine Behavior poll/defer ready start created created start/^master.ready() ready ready stop/ start/ • Event handling details depend on state start/^master.ready()

23. Active Objects in the UML ActiveObject: • Concurrent incoming events are queued and handled one-at-a-time regardless of priority • run-to-completion (RTC) execution model

24. RTC and Concurrency ActiveObject: • Eliminates need to write complex and error-prone synchronization code • if all passive objects encapsulated by an active object, only a single thread can pass through each passive object passive encapsulated objects (protected attributes) The event handler is an implicit critical region

25. RTC Semantics • RTC step semantics must not be confused with uninterruptibility or unpre-emptabilty • interrupts do not have to be blocked • an active object can be pre-empted by another active object responding to a higher-priority event • priority inversion only occurs when an active object blocks itself (i.e. it cannot block any other active object) • The effectiveness of this is supported by the following empirical results • most event handling is trivial • in computer terms, events occur infrequently

26. State-Based Actions print/printContents(); Operational start/ stop/ • Entry action: executed whenever a state is (re-)entered • Exit action: executed whenever a state is departed • Internal transition: a self transition executed without leaving and re-entering a state entry/^m.entered(); exit/^m.departed() poll/^m.ack()

27. Hierarchical States and Transitions off/ OffLine on/ OnLine Ready done/ req/handle() Busy • Allows step-wise refinement and viewing of complex behavior group transition default transition composite state

28. Signals «signal»Alarm «signal»FireAlarm «signal»MedicalEmergency severity : integer severity : integer address : Address severity : integer type : EmergencyType • Used for asynchronous communication • specified by a special type of class • can be organized into class hierarchies

29. Sequence Diagrams Caller Operator Callee call number call ack ack transfer talk time • Assertions of legal interactions between objects (e.g., operator-assisted call) sequence diagram

30. Collaboration Diagram CallProc 2.call() 3.sendTone() PhoneIF ToneGen 4.dialtone() 1.offHook() • Show generic structure and behavior classifier role P2:TTSet P1:BusSet P2:TTSet P1:BusSet

31. Introduction • The Object Paradigm • Modeling with the UML • Summary

32. Summary: the UML • An industry standard for analysis and design of object-oriented systems • based on extensive experience and best practices • gaining rapid acceptance (training, tools, books) • Comprises: • set of modeling concepts • graphical notation • Leaf concepts organized into 8 diagram types • class, state machine, collaboration, use case, sequence, activity, component, deployment • The UML can be used in many different domains to capture domain-specific concepts and ideas