Understanding UML Modelling: Techniques and Tools for Object-Oriented Design

1. Modelling III

2. Objects • Object – direct relationship with the real world • Object • memory -> data -> Attributes • processes -> Operations -> Messages • Object - Organization – Hierarchy • aggregation • generalization

3. Object Orientation • Most famous: • Booch • OMT • Jacobson

4. UML Birth • Several methods and techniques for OO, with many common aspects but using different notations • Difficult to learn, to apply, to build and to use tools • Diferences among different approaches (authors) There was the need for a standard notation

5. UML • “Unified Method” • Grady Booch e Jim Rumbaugh • First presented at OOPSLA’95 • Rational Software • Grady Booch, Jim Rumbaugh e Ivar Jacobson • Rational Rose CASE tool

6. UML It is a Modelling language not a method ! • A method consists of notation language + process • The proposed process is called Objectory • We can use UML regardless the process we use

7. UML Basic Representation: • Static Model • ERD evolution • Internal Dynamic Model • Data Flow • State Machines • External Dynamic Model • use cases • Languages for interconecting objects

8. Use Case Diagrams Actors and their connections with the system Textual description for the Use Case Class Diagram Static Structure for the system classes Object Diagram Simplify the class diagram UML - Diagrams • Use Case Diagrams • Static Structure Diagrams

9. State Diagram Possible states an object may have and events that cause state change Activity Diagram Sequential flow of activities UML - Diagrams • State Diagram

10. Sequence Diagram Dynamic collaboration expressed as messages exchanges among objects triggered by a function or a sequence in time Collaboration Diagram Dynamic Collaboration using interaction among objects (context) Component Diagram Physical structure of the code in the form of code components Distribution Diagram Hardware and Software Physical Architecture UML - Diagrams • Interaction Diagrams • Implementation Diagrams

11. States Sequence Distribution Use Cases Classes Colaboration Components Activity (work flow, use cases) Activity (object behavior, operation algorithms) UML - Diagrams Implementation Requriements Design

12. Use Case <<extend>> Print Receipt Make a Sale Saleman Finance System

13. Use Case • An Use Case performs a broader aspect of the product functionality: • Must produce one or more benefits for the client or users • represent: • User interaction • User manual auxiliar • Test cases Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”

14. Use Case • Textual Part • Use Case << name>> • pre-condition • Main flow • sub-flow<<name>> • Alternative flow • pre-condition • steps Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”

15. Use Cases Exemplo: Make a sale Salesman Finance System Manage stock Manually Stock Manager Open Cash Register Manager Close cash register Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”

16. Use Cases • Example: • Use Case << Make a Sale>> • pre-conditions: Every Product on sale must have been previously registered in the system. The system must be in the Sale mode • Main flow • Salesman start the sale. • The System generates a code for the sale operation • For each item to be sold call the sub-flow Register • Salesman register form of payment • Salesman finishes sale • For each item call the sub-flow Print Receipt Line Filho, W.P.P em “Engenharia de Software: Fundamentos, Métodos e Padrões”

17. Use Cases • Identifying actors; • Who is interested in the requirements • Who will benefit from the product; • Who will give information to the software; • Who will use the software; • Who will remove information from the software. • Identifying use cases: • What are the actors’ tasks ; • Which information each actor creates, stores, consults, changes or removes; • Which information each use case creates,consults, changes or removes.

18. Use Cases • Determining use case flow • When and how a use cases starts. • How the use case interacts with the actors. • Standard Sequences for steps for a use case. • Exceptions Sequences and alternative sequences for a use case.

19. Class Diagrams • Describe system objects and their static relations • Objects can be part of the real world or conceptual entities • Objects are connected to other objects through relationships (association, agregation…)

20. Class/Object • Class: • Describe a set of objects that share the same properties (Attributes), behavior (operation), relationships with other objects and semantics • Object: • An Object is an instance or occurrence of a class

21. Properties: Fuel capicity Km/galon availability km Behavior: travel refuel car A Class / Object instanciation instanciation car B

22. Car FuelCapacity: Integer kmpergalon: Real availability: Real Km: Integer travel (Kms: Real) Refuel (quantity: Real) Class name attributes operations

23. rj5015: Car FuelCapacity: 200 kmpergalon: 40 Availability: 40 km: 1400 Car - FuelCapcity: Integer - Kmpergalon: Real - availability: Real = 0 - km: Real = 0 ... Objeto com valores Class • Attributes • Examples: Class whit attributes

24. Inheritance • Inheritance • A subclass inherits attributes, operations, state diagram and associations from a superclass • Inherited properties may be reused from the superclass or redefined in the subclass • New properties can be added to the subclass • Can be • Simple: only ine superclass • Multiple: more tha one superclass

25. Inheritance • Multiple • A class inherits attributes, operations and association from multiple classes • Offer a greater modelling power but leads to a greater complexity

26. Vehicle water land Boat Car Amphibian Example • Multiple

27. Employee YeartoDate: Real calculatePay() {abstract} MonthlyBasis HourBasis Normalhours: RealExtraHours: Real Normalhours: RealExtraHours: Real computarPagamento() calculatePay() Inheritance

28. Company Managers Project Employee Employee schedule HourBasis MonthlyBasis Class Schema Agregation • Example: Company 0..N 1 Association Class 0..N Generalization

29. Problems with OO • Disadvantages (Jackson): • The idea of objects comes from programming languages and it is not suitable to most of the individuals in a real worlds. • When have someone sent a message to the paycheck? • When have a doctor sent a message to Patient’s Record?

30. Cenários Anlysis Is my understanding (vision) correct? Domínio do problema Compreender modelo Communication • It is necessary to have a good communication between user/stakeholder and developers Scenarios Problem Domain Understand the Models

31. Scenarios • Easy to understand (written using the problem language) • Help to unify criteria • Stimulate thinking • Help with training • Help on tracking/traceability • Help identifying Non-Functional Requirements Scenarios are situations

32. Scenarios Real World Universo de Informações Universe of Discourse Situações Situations Lista de Situações List of Situations

33. Scenarios • Situation’s Characteristics • Purpose – A situation deals with the satisfaction of a goal. • Actors – A situation encompass a certain and identifiable numbers of actors (people or devices within organizations). • Resources – Elements that are necessary in one particular situation. • Time – represent a specific moment. • Place – Situations take place within a geographical context. • Constraints – The might have pre-conditions to a situation to happen. • Independent – need to be understood alone. • Inter-related – Are related to other situations, although still independent. • Concrete – Are anchored in reality. • Alternatives – May lead to alternative actions.

34. Write Scenarios • Describe situations of the macrosystem • Describe situations and their relationship with the system-to-be • May be used to describe interaction between system components • Use a semi-structured natural language

35. Scenarios

36. Why Semi-Structured? • Avoid confusion • Provide an homogeneous description style • Works as a reminder of the several aspects that might be considered within the scenario • Facilitates to have it validated with the users/stakeholders

37. Scenarios • Title: Store checks client’s registration • Objective : Verify if information on client’s registration are correct • Context: Client hand over client’s registration and show a photo id • Actors: Store, Client. • Resources: photo id, client’s registration • Episodes • Store fills up blank spaces in client’s registration using the initial “NE” (Non-existent) • Stores verify id number on client’s registration against the one in the photo id • Constraint: id number must comply with standards • Store verify address and phone number calling the number in client’s registration

38. Scenarios • Title: Add Book Exemplar to library collection • Objective: Book Exemplar belongs to library collection • Context: Number of Book exemplars available on library collection is not sufficient • There is enough physical space to store new book exemplar • Book exemplar can be bought or donated • Library clerk is always present • Library Management System is working • Actors: Library clerks • Resources: Book Exemplar, book, library collection, library management system • Episodes • 1 Library clerk gets book exemplar to be added to library collection • 2. If book data is not yet filed in the library management system,library clerk must file book in library collection • 3Library clerk file book exemplar in the library management system • 4Library clerk reserve a physical space to place book exemplar according to information retrieved from the library management system, • 5.Library Clerk place book exemplar in the correct physical space

39. Identifying Scenarios • List Situations • 1. Is there a goal? Is it general (abstract) enough)? Are there different outputs or is it a sole case? • 2. Who is involved? Are there other important artifacts or important structures? • 3. Are there any information or physical elements that are important to this situation? • 4. Organize identified situations in a list.

40. Fill in the scenarios • Don’t Guess !!! Stick to what you know and can validate • Use the application vocabulary (LEL) • Using the scenario grammar fill in the candidate scenarios (pair programming with clients is always best)

41. Notation • Title • [ Sentence | ( [ Actor | Resource ] + Verb + Predicate ) ] • Example: Store checks client’s registration • Objective • [ [ Subject ] + Verb + Predicate ]] • Example: • Verify if information on client’s registration are correct Where: + - composition {x} – zero or more occurrences of x ( ) - group | - or [ ] - optional

42. Notation • Context • The context is described detailing time, place and pre-conditions. At least one of them should appear “Client hand over client’s registration and show a photo id “

43. Notation • Where • local is Phrase + {Constraint} • Time is Phrase + {Constraint} • Pre-condition is • [Subject| Actor| Resource] + Verb + Predicate + {Restriction}

44. Notation • Resource • Relevant Physical elements or information that should be available to the scenario • [ Substantive + {Constraint} ]

45. Notation • Episodes • Main course of action • Includes variations and alternatives • Exceptions may happen, enforcing the presence of obstacles to the goals (objectives) • Exceptions may be simple actions but can also be other scenarios SUB SCENARIO

46. Notation • Episodes • There are 3 types of episodes • Simple – needed to complete the scenario • Conditionals – depend on essential conditions (If .. Then) • Optional – May happen or not depending on the course of action

47. Style • Short phrases • Try to avoid more than one verb per phrase • The objective must be concrete and precise • At least one of the components for the context must be filled • Resources must be those directly involved in the episodes. Avoid trivial things

48. Requirements Sentences • The system must + [verb + object | verbal phrase ] + [agent complement| null] + [conditions | null] • Three classes of sentences: (Input, Output, State change} • Verb is a simple verb which express the requirements functionality • Verbal phrase is a phrase which expresses the requirements functionality • Agent Complement is the identification for an agent related with the requirement. Sometimes this complement may be described by the direct object. An agent can be a person, an organization, a group or a device external to the software • Sentences can be : Functional, non-functional and reverse

49. Requirements Sentences • The system must produce a receipt for the client • The system must produce a receipt in less than 2 seconds • The system must register the client if the client has a photo id • The system must change an available tape into a rented tape when a client rent a tape • The system must register library clerks • The system must not allow a book to be reserved for more than 2 weeks

50. Organization • Lexicon --> hypertext • Scenarios --> Relations (complement, pre-condition, equivalent, exception, sub-set, possible, precedence, inclusion). • Sentences (numerical itemization, chapters)