Seminar The Unified Modeling Language (UML)

1. Seminar The Unified Modeling Language (UML)

2. Code as a representation of a piece of software package codemodel; public class Guitarist extends Person implements MusicPlayer { Guitar favoriteGuitar; public Guitarist (String name) {super(name);} // A couple of local methods for accessing the class's properties public void setInstrument(Instrument instrument) { if (instrument instanceof Guitar) { this.favoriteGuitar = (Guitar) instrument; }else { System.out.println("I'm not playing that thing!"); } } public Instrument getInstrument( ) {return this.favoriteGuitar;} } • It represents only the logic of its behavior, nothing else. • It is caught by humans very slowly • It does not help to reuse the design decisions

3. Natural language for representing software • It is ambiguous and even confusing • It takes a while to catch the idea and reason about it • It is difficult to process. Guitarist is a class that contains six members: one static and five non-static. Guitarist uses, and so needs an instance of, Guitar; however, since this might be shared with other classes in its package, the Guitar instance variable, called favoriteGuitar, is declared as default. Five of the members within Guitarist are methods. Four are not static. One of these methods is a constructor that takes one argument, and instances of String are called name, which removes the default constructor. Three regular methods are then provided. The first is called setInstrument, and it takes one parameter, an instance of Instrument called instrument, and has no return type. The second is called getInstrument and it has no parameters, but its return type is Instrument. The final method is called play. The play method is actually enforced by the MusicPlayer interface that the Guitarist class implements. The play method takes no parameters, and its return type is void.

4. Visual models for representing a piece of software

5. Unified Modeling Language • The Unified Modeling Language (UML) is a conceptual modeling language based on an object oriented methodology. • The objective of UML is enabling the representation of models for systems in general but in particular for software applications. • A model is a set of abstractions that represents a system in order to cope with its complexities in a given domain. • A UML model is formed by : • A set of modeling elements and rules that define the structure and functionality of the system collected in a common repository. • The presentation of those concepts by means of multiple graphical views, which formalize the creation and edition of the models according to the rules of the language and the purpose of the model.

6. Advantages of UML • It is based on a metamodel with a defined semantics. • Proposes a concrete graphical notation easy to use and learn. • It is an international standard supported and maintained by a solid standardization board, the Object Management Group (OMG). • It is independent of any concrete commercial tool vendor. • It is quite scalable, it allows the representation and management of massive as well as small systems’ models. • It is a language that was originally conceived and has evolved mainly as a development tool for software applications.

7. Basic semantic aspects of a system in UML • Functional aspects: It describes the functional specification of a system, independently of its implementation. It covers the usage of the system and the ways it is expected to react. • Structural aspects: It describes the elements that form the model as well as the parameters that characterize them in a quiantitaive way, and the relationships among them. • Behavioral aspects: It describes the inner behavior of the elements, concrete scenarios for their dynamics, and the externally visible interaction between groups of them.

8. UML diagrams • Static: Organizational/structural modeling resources • For modeling system’s functionality: • Use Case diagrams • For modeling system’s architecture: • Class diagrams • Components diagrams • Dynamic: Behavioral modeling resources: • For the dynamics of an element: • State charts (event driven model) • Activity diagrams (operational model/flow charts) • For concrete execution scenarios: • Sequence diagrams • Collaboration diagrams

9. Views of a UML model. • A UML model may target different levels of detail: • Architectural models: they express high level qualitative information. • Detailed models: they contain information for the validation of certain properties of the system, the code generation or other model transformations. • There is not just one graphical view that expresses the whole semantics of the system. The full semantics is stored in the repository. • Having multiple views allows the modeler to focus attention on specific aspects with the proper level of detail: • Use case view • Classes view • Deployment view • Components view • Graphical views are the mean to introduce the model in the repository. • The management of a UML model requires a specific tool that keeps the model consistent along the development process.

10. Basic structural modeling elements • The basic structure of a system is described using a reduced set of low level modeling elements: • Object: it is a run time concept that keeps linked a data structure with the set of operations that act on them. • The data stored in the object define its state and are called attributes or properties. • The procedures and/or functions that expose the behavior and/or the interaction protocol of the object and act over its data are called methods or operations.. • Class: it is a design time concept that describes the common characteristics of all objects of a kind. Objects are individual instances of a class. • Interface: it holds the signature of a set of operations, which as a whole defines a service, a protocol, or a behavior disregarding the way them may be implemented. It is meant for reusability of conceptual behaviors. An interface may not have objects, it has to be implemented by a class, which in turn may have objects exposing such functionality.

11. Class • It models the commonalities of a set of objects that share : • The same kinds of properties (Attributes) • The same behavioral units (Operations) • The same relations with other objects (Associations) • A common basic semantics (eventually common Stereotypes) • The analysis tries to identify the types of objects (classes) that are key to understand the problem that is to be solved. • To identify the relevant classes, the analysis process encompasses: • Identify names of objects that appear in the problem description. • Simple characteristics may indicate attributes while complex elements may indicate objects of other classes. • Classes may be categorized by generalization by defining abstract classes. • Classes are described identifying their attributes, the operations they offer to other classes objects, and the behavior they hold. • The systems behavior is described by collaborations among classes.

12. Documentation Name Stereotype <<Active>> Attributes Sensor Default Values - value: SensorData + calibrationConstant: constant LongInteger= 100 Documentación - Acquire(): SensorData + GetValue():Integer + SetCalibrationConstant(newCC:LongInteger) Visibility Operations Documentation Parameters SensorData Graphical representation of a class in UML

13. Class Diagrams

14. Declaration of Interfaces SensorClient <<Active>> PreassureSensor acquire getValue setCalibrationConstant I_Sensor <<depend>> <<realizes>> <<Interface>> I_Filter LowPassFilter filterValue(value:Integer):Integer -lowPassParam: Integer + filterValue(value:Integer):Integer + init(lp:Integer)

15. High-level structural modeling elements • These elements describe the system architecture from a high level of abstraction point of view: • Package: It is a container, used to manage modeling elements in an organized way. • Subsystem: This is a very high-level structural element, used to decompose the whole system into complementary blocks usually with a clearly distinctive functional interaction among them. • Component: A set of modeling elements that group them as a replaceable whole. This implies the need to specify its offered as well as its required interfaces. • Node: It models a physical computational element on which software elements can be executed.

16. Example of packages Medical Stuff Temperature Patient Parameter Heart Rate * PVC Count Patient User Interface Stuff view <<domain>> Window Control Window Histogram Control Waveform Control Scrollbar Icon Control

17. Subsystems <<interface>> I_Power <<subsystem>> Power Subsystem requestPower(amps:Float) Switch <<realizes> Battery Power Source Solar Panel Voltmeter I_Battery

18. Components and nodes Physician ECG Acquisition Module Display Computer TC/IP Stack Patient Data Base GUI Ethernet Data Adquisition Medical Monitoring Patient TC/IP Stack Math Library

19. Structural elements hierarchy <<system>> <<subsystem>> <<subsystem>> <<subsystem>> <<subsystem>> <<component>> <<component>> <<component>> <<component>> <<active>> <<active>> <<pasive>>

20. «link» Clase A Clase B «uses» Clase A Clase B Associations • They abstract relationships like: • Aggregation: “It is part of…” • Simple aggregation : “It is contained in…” • Composition: “It is composed of...” • Generalization: “It is a kind of...” • Inheritance: “It extends...” • Specialization: “It specializes...” • Dependency • Link: Have access to… • Abstraction: (<<refine>>, <<realize>>,...) • Bind: (Between generic and concrete classes) • Usage: (Make use of..., Have visibility to...) • Permission: (<<friend>>, <<son>>,...) Clase A Clase B Clase A Clase B Clase A Clase B

21. Examples of associations Base Lámpara Pantalla Incandescencia Conmutador Fluorescente Cables Casquillo Reactancia Cebador Base_bayoneta

22. Associations multiplicity Grade Assignment Student Diplome 1..n 0..n Title Name Mark Do 1 0..n 0..1 1 Room Number

23. student Person Class 1..n {subset} 0..n delegate Constraints on associations 0..n 1 Person Account {Ordered} Professor Person University 1..n {exclusive OR} 1..n Student Person Parent 1..2 Son 0..n

24. <<Abstract>> recipient CommunicatingObject Patient Heart Rate 0..n <<Subsystem>> 1 0..n Send(m:message) Receive():Message CommSubsystem Heart Rate Display 1 1 1 theTransQueue <<Abstract>> MsgQueue 1 Communicator 1 0..n Message theRecQueue 1 - head: Integer - tail:Integer - size: Integer 1 outputQueue Insert(m: Message) Remove(m: Message) GetSize(): Integer Init() IsEmpty():Boolean CANBus Communicator Ethernet Communicator 1 inputQueue 1 1 1 1 1 1 CacheQueue 1 Ethernet Interface CANBus Interface Semaphore - theFile: File Init() Save() Load() Ethernet CANBus Examples of associations in a class diagram

25. Modeling the behavior • The resources offered by UML to describe the dinamic behavior of structural elements like objects, classes, systems, subsystems and components at run time are presented in: • State charts: They are used to describe the internal evolution of a class or method due to the occurrence of external o internal events. It exposes the states in which the element can be and the events that trigger transitions between them.. • Activity diagrams: Represent the flow of execution of a method. • Sequence diagrams: They show concrete interactions between objects formulated as sequences of events or messages organized in time. • Collaboration diagrams: They work as sequence diagrams but highlight the concrete elements that participate and their links instead of the evolution of the interactions in time.

26. Actions and Activities • Action: It abstracts an executable primitive that is able to cause a change in the system state: generation of an event, change in the value of an attribute or link, etc. • It models a simple statement with the “run to completion” semantics (It runs disregarding others until it finishes) • Some kinds of actions: • CreateAction (constructor) or Destroy Action (deletion of an object). • CallAction (synchronous invocation of an operation). • ReturnAction (return of control from an operation) or TerminateAction (return of control signaling the end of a sequence of actions) • SendAction (asynchronous transference of an event) • ActionSequence) (an action composed by a sequence of them) • Activity: It is a sequence of actions that execute in the context of a particular state of an object. It finishes when the object changes its state, which may occur due to the arrival of an external or timed event, or because the sequence finishes. • It does not imply the assumption of a “run to completion” semantics

27. State charts • They are used to describe the behavior of structural elements or methods in a finite state machine. This implies to represent the possible states of the element and the potential transitions among them. • The actual behavior is specified by actions linked to: • Transitions between states • The “entry” to each state • The “exit” of each state • The staying in a state may have an activity associated. • UML State charts have significant expressive power and scalability: • A state may have an aggregated state chart. • They can express concurrency by introducing AND states. • Dynamic semantics is supported by using pseudo-states. • Transitions may be guarded and synchronized.

28. Opening • Closed • PushBotton • entry/ StartUp • do/ MotorStop • exit/ Stop • do/ MotorUp • PushBotton • FullyClosed • ObstacleFound • FullyOpen • PushBotton • Closing • Open • PushBotton • entry/ StartDown • do/ MotorStop • exit/ Stop • do/ MotorDown • TimeOff( 30 s ) Example: Garage door External events: - PushBotton - FullyOpen - FullyClosed - ObstacleFound Actions: - StartUp - StartDown - Stop Activities: - MotorUP - MotorDown - MotorStop

29. State chart notation operating processing Working Filtering Acquiring evDataReady entry/d=filterData(); do/x=Xdata(d); do/y=Ydata(d); entry/enableSensor(); do/D=GetData(); exit/disableSensor(); evAbort Idle [dataBad] Controlling Verifying [dataOk] entry/enableMotor(); do/SetAxis=(x,y); do/DisableMotor(); entry/CheckData(); do/CheckPosition(); testing evOK Handling Checking tm(CheckTime) evError entry/LogError(); do/if HANDABLE then GEN(evOK) else GEN(evBAD) Waiting do/ if FAILED then GEN(CheckData(); UnrecoverableError evBad/GEN(evAbort)

30. Activity diagram • It might by considered as a special case of a state machine used to describe the flow of control inherent to the execution of an operation. • It models sequential as well as concurrent flows of control. • The transition between two consecutive states is triggered by the end of the activity associate to the previous state. • They are used to describe the internals of the algorithms.

31. Elements of the activity diagrams. Decision Event_1 Wait event Activity_C Activity_A [T>20º] [T<=20º] Activity_A finished Activity_D Activity_E State Activity_B Activity_F Event_2 Raise event

32. A usual representation for concurrency. Activity_A Swimlane Generation of concurrent flows (fork) Thread_3 Thread_2 Thread_1 Activity_D Activity_C Activity_B Activity_E Convergence of concurrent flows (joint) Activity_F

33. Additional example of activity diagram. GraspAt(x,y,z) Proximity Sensor evIsNear Alarm System [area not clear] AnnunciateAlarm [area clear] ComputeJointAngles(a,b) OpenGrip Joint 1 to a Joint 2 to b RotateGrip Grasp Object

34. Interaction diagrams • They serve to model the collaborative behavior of groups of structural elements. • They are formulated as partial/typical/expected scenarios with the exchange of messages that express the interaction between objects. The messages are in practice events, the invocation of operations, or the creation/destruction of objects. • There are two behaviorally equivalent presentations: • Collaboration diagrams: These show concrete objects and links, and add to them the messages that they interchange ordered by means of a numbering notation. • Sequence diagrams: These diagrams present the interacting objects, and show the messages they exchange as arrows ordered graphically in a top-down way, indicating the partial order between them.

35. Sequence charts • This is used to express graphically time ordered interactions between objects. • Such interactions occur between them as an expression of their collaborate behavior to accomplish the responsibilities of the whole • Only one of the possible execution scenarios is shown. This corresponds to a particular execution of a function or use case of the system • It is the basic mechanism used by a non-expert to describe interactions • A sufficiently large set of sequence charts may actually bring the description of the whole system behavior, but this is tedious and significantly error prone. Other behavioral diagrams are used for such specification purposes instead.

36. Caller Phone Network Callee Example: A phone call Time Caller lifts receiver Dial tone begins Dial Dial tone ends Dial… Phone rings Ringing tone Answer phone Ringing stops Tone stops Hello?

37. Juan: Caller Pepe: Caller :Phone-System Interactions are between objects Different object may play The same role Class or role Anonymous object Object

38. Object_1 Object_2 Object_3 Object_4 Timing marks A.send=>A.Receive A B ¿¿A.send=>B.Send?? C A.Receive=>C.Send A.Reseive=>D.Send D E Partition line ¿¿B.Send=>E.Send?? G F D.Received=>F.Send H G.Send=>I.Send J I ¿¿G.Receive>=J.Send??

39. Synchronization of messages Object_A Object_B Object_C Object creation Asynchronous message Asynchronous message* Object_D Conditional message* Wait* Message with timeout* Synchronous message Self message Explicit return Stereotyped message <<Stereotype>> Object deletion * Notation deprecated in UML 2

40. Additional syntax in sequence charts Object_2 Object_1 [Condition] Message_1 if Condition then message_1 else message_2 [not Condition] Message_2 [X] Message_1 case Variable of X=> message_1 Y=> message_2 [Y] Message_2 *[X] Message While X do Message

41. Timing Constraints Object_C Object_B Object_A a {PERIOD(a)=10 s} e {AVERAGE(b-a)=5 s} f {f-e<=1s} b a’ b’

42. Collaborations (UML1.x) • They model interactions between objects that collaborate to implement a given functionality or use case. • They refer mainly to the links between objects. They are specially useful to describe protocols. • They describe concrete scenarios for particular situations, not general behaviors. • The expressive power is similar to sequence charts. The emphasis here is in the communication links, while in the other is on the order of occurrence.

43. A collaboration diagram example. 9. Display Message “That selection is empty” CokeRack:Rack :MessagerDisplay :Can 7. Release 8. Light on ButtonPanel 6. Push CokeButton:Button CokeLed:Led 10. Push FantaButton:Button 11. Release 5. Enable Buttons 12. Disable button FantaRack:Rack 13. Reset Coin :Can 1. Insert 50 c. 2. Insert 50 c. 3. Insert 20 c. :CoinReceptacle FantaLed:Led 4. Return 10 c. User

44. Elevator System 3a: Arrive 4a: Enter Potential passenger 2a: Status System 1a: Call Sensors & actuators Alarm Call Event • The status is observed • The call button is pushed • The elevator goes to that floor Floor Elevator Status Door Control Technical service 4b: Leave 3b: Status Interface LAN 2b: Other commands RS-232 1b: Select floor Passenger The order is expressed explicitly as an index

45. A sequence chart example :Coin Receptacle FantaRack: Rack :Button Panel CokeButton: Button CokeRack: Rack CokeLed: Led FantaButton: Button :Message Display User Insert 50 c. Insert 50 c. Insert 20 c. Return 10 c. Enable button Push Release Light On Display Message Push Release Disable buttons Reset

46. Use case diagrams • A use case describes an interaction between the system and an external agent called actor: • A use case capture a functionality that is visible for the user (actor). • A use case represent a concrete objective of the system for a user. • A use case may correspond to a very simple as well as to a quite complex function. In the later case it may be formulated in terms or simpler use cases. • Use case diagrams are used in UML to: • Delimit parts that belong to the system from those that are external to it. • Capture the functional elements of the system. • Identify and classify external elements with which the system interacts. • Formulate the protocols fo rthe interactions between the system and the actors.. • Use case diagrams encompass the system’s functionality, not its implementation. • Use case diagrams are an alternative to the context diagram and complement it to formulate the system’s requirements. • The functionality of the system expressed in the use cases is used as a guide along the rest of the phases in the development process (analysis, design, coding, tests, and deployment).

47. Use cases: Modeling requirements • A use case describes a concrete capacity or functionality required for the system that is offered to a concrete actor . • It specifies a function of the system as a whole, disregarding its internal parts or the concrete mechanisms used to deliver it. • It acts as a container for the diagrams or texts that are needed to describe its functionality and the quality of service required from the system. • Among use cases can be established relations like: • Generalization. • Inclusion. • Extension.

48. <<Actor>> <<Protocol>> System Use Case 1 <<extends>> Use Case 2 Actor_1 <<uses>> Actor_3 Use Case 3 Use Case 4 <<specializes>> Use Case 5 Actor_4 Actor_2 Elements in UML use case diagrams

49. Actors • It represents an entity that is external to the system but interacts with it. • Actors may be: • Main actors: Users utilizing the system functions. • Secondary actors: Users that make administrative or maintenance system tasks. • External elements: Equipment or devices that are related to or located in the environment of the application but are not developed with it. • Other systems: Systems external to the one under development that interact with it. • An object may implement several actors, and an actor may have several implementations.

50. Order Product Information Order status Update stock Client Get catalog Refill products Inventory Cancel order Charge payment Return product Enter discount Agent Treasurer Enter claim Print label Deliver package Calculate order cost Employee Courier Use Case diagram for an e-commerce web service