Lecture 4

1. Lecture 4 • Unified Process • Disciplines • Phases • Requirements • Use case models • UML • Use Case Diagrams • Class Diagrams • Sequence Diagrams • Statechart Diagrams

2. Hat Problem • Three persons each one wearing a hat that is either red or blue with 50% probability. • A person can see the colours of the other two hats but not its own colour. • Each player can either make no prediction or give a guess on the colour of its own hat. • The team wins if at least one player guessed correctly and no player guessed a wrong answer. • There is no form of communication between the players, in particular they do not know which decision any of the other players made. • The players can agree beforehand on a common fixed strategy.

3. Unified Process • The UP describes work activities, such as writing a use-cas model, within disciplines. • In the UP an artefact, is the general term for any work product, code, diagrams, models, database schema etc. . • There are several disciplines in the UP, business modeling, requirements, design, implementation, test, deployment, configuration and change management. • The course focuses on requirement analysis, design and implementation.

4. Unified Process • UP Phases • Inception: approximate vision, business case, scope, vague estimates inception = feasibility study • Elaboration: refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope • Construction: iterative implementation of the remaining lower risk and easier elements • Transition: beta tests, deployment

5. Unified Process Disciplines and phases: relative efforts

6. Unified Modeling Language • UML a complete language for capturing knowledge (semantics) about a subject and expressing knowledge (syntax) regarding the subject. • Modeling involves a focus on understanding (knowing) a subject (system) and capturing and being able to communicate this knowledge. • UML is the result of unifying the information systems and technology industry´s best engineering practices (principles, techniques, methods and tools) • UML is a notation not a method !!!

7. Unified Modeling Language • UML is used for specification, visualization and documentation of systems • UML is based on the object oriented paradigm • UML applies to a multitude of different types of systems, domains and methods or processes. • UML unifies the syntax and semantics of methods and tools previously used for object oriented design • UML was originally conceived by Rational Software Corporation and the ”Three Amigos” in 1995 • Grady Booch • James Rumbaugh • Ivar Jacobson

8. DIA • DIA is a diagram creation program from Linkoeping University http://www.lysator.liu.se/~alla/dia/dia.html • It can be used to draw many different kinds of diagrams • Entity relationship diagrams • UML diagrams • Flowcharts • Network diagrams • It is available by adding the module dia module add dia dia

9. Use Case Model • Writing use cases is an excellent technique to understand and describe requirements. • A use case is a story of using the system. • The Unified Process defines the Use-Case Model within the requirements discipline. • The set of all Use-Cases provides a model of the system’s functionality and environment.

10. Use Cases • An actor is something with behavior, such as a person (identified by a role), computer system or organization, for example a cashier. • A scenario is a specific sequence of actions and interactions between actors and the system under investigation, it is also called a use case instance, for example purchasing an item with cash. • A use case is a collection or related scenarios that describe actors using the system to support a goal.

11. Actors • Actors are classes that define roles that objects external to a system may play. They are used to model users outside of a system that interact directly with the system as part of coherent work units. This includes human users and other systems • Actors are characterized by their external view rather than their internal structure. • Actors participate in interactions involving message exchanges and actions with systems. • Actors have goals to be achieved by interacting with the system.

12. Use Cases • Uses cases are entities that define units of functionality or behavior provided by the system. • Use cases specify the external requirements of the system and the functionality offered by the system. • Use cases are specified by sequence diagrams representing the external interaction sequences among the systems and its actors. • Use cases are realized, or implemented, by collaboration diagrams representing the internal refinement of the services provided by the system.

13. Use Cases • When writing use cases you should ask the question: “How can using the system provide observable value to the user or fulfill their goals.” • Use cases describe the functional requirements of a system, that indicate what the system is supposed to do. • Use cases are primarily text documents (written stories) although the may contain UML use case diagrams, to illustrate the names of use cases and actors and their relationship.

14. Use Cases • Use cases describe the system as having responsibilities, they do not describe the internal workings of the system. They specify what the system must do (functional requirements) not how (design) it will do it. • Incorrect: The system writes the sale to a database. • Instead: The system records the sale.

15. Use Cases • Formats for use cases • Brief : one-paragraph summary, usually of the main success scenario • Casual : multiple paragraphs that cover various scenarios • Fully dressed : elaborate description, all steps and variations are written in detail, there are supporting sections, such as pre-conditions and success guarantees.

16. Use Cases • Example (brief format): Borrow book : A library user arrives at the check-out with books to borrow. The patron identifies herself to the check-out system and the system validates that she is a legitimate user. The patron uses the check-out system to record each borrowed book. The system validates, records each book and associates the book with the patron. The system updates the library inventory. The patron receives a receipt from the system that states the books borrowed and the loan period.

17. Requirement Analysis • Finding primary actors, goals and use cases • Choose the system boundary • Identify the primary actors • Identify the goals of the actors • Define uses cases that satisfy user goals

18. Use Cases Borrow book : Primary actor : patron Stakeholders and Interests: -patron : Wants to borrow and return books quickly and with minimal effort. Wants receipt over borrowed and returned books. -librarian : Wants system to accurately record transactions. Wants fast access to and automatic update of library inventory. -library : Wants to reduce operation costs. Wants reliable capture of transactions.

19. Use Case Diagrams • Use case diagrams render the user view of a system. • Use case diagrams describe the functionality provided by the system or class to external actors. • Use case diagrams contain • Actors • Use cases • Their relationships

20. Communicates Relationship • Communicates relationships are associations between actors and use cases. They are used to model communications between actors and use cases in which an actor participates, communicates with, or takes part in a use case. Borrow Items Return Items Renew Items Patron

21. Use Case Diagram Library system Borrow Items Return Items Renew Items Patron Librarian Manage Catalog Manage Patrons

22. Borrow Items Use Case • Detailing the functionality of the Borrow Item Use Case Borrow Item Borrow Book Borrow Periodical Librarian Borrow Electronic Media Patron

23. Extends Relationships • Extends relationships are generalizations between use cases. They are used to model relationships between use cases in which a base use case instance may include the behavior specified by an extending use case, subject to conditions specified in the extension. • Extends relationships are used to capture exceptional behavior or variations of normal behavior.

24. Extends Relationships • The arrow from the ”Pay by credit card” use case to the ”Purchase” use case is labeled with an <<extends>> stereotype to indicate that this use case is an option of the ”Purchase Item” use case Pay by Credit card <<extends>> Purchase Item Pay by Cheque <<extends>> Customer

25. Uses Relationships • Uses relationships are generalizations between use cases. They are used to model relationships between use cases in which a base use case instance will also include the behavior specified by a common use case. • Use relationships are used to share common behavior among use cases.

26. Uses Relationships • The arrow from the ”Group Graphics” and ”Move Graphics” use case to the ”Select Graphics” use case is labeled with an <<uses>> stereotype to indicate that the ”Select Graphics” use case is included in the group and move skills. Identify Patron Borrow Item <<uses>> Renew Items <<uses>> Patron

27. Unified Modeling Language • UML object model describes the static structure of the problem domain, it contains • Class diagram describes the class attributes (name and type), operations and the relationship among classes. A class diagram contains classes and associations • Object diagram A class model describes all possible situation, whereas an object model describes a particular situation. An object diagram contains objects and links which represent the relationship between objects

28. Unified Modeling Language • The UML dynamic model describes all temporal and dynamic aspects of the system, for example interaction among objects it contains • Sequence diagrams describe interactions among classes which are modeled as exchanges of messages. Sequence diagrams contain class roles, lifelines, activations and messages • Scenarios describe interactions among objects • Statechart diagrams describe the states and responses of a class. They contain states and transitions.

29. Domain Model & Design Model UML class, objects, sequence, statechart diagrams can be used during the OOA/D process for • Domain model : • Visual representation of conceptual classes or real world objects in a domain of interest. • A domain model is visualized by a set of class diagrams • Design Model : • Describes how a particular use case is realized in terms of responsibilities and collaborations of objects.

30. UML Class Diagrams • Class diagrams describe the static structure of a system rather than its behaviour. Class diagrams contain the following elements: • Domain objects or conceptual classes Which represent entities with common characteristics or features. • Attributes of conceptual classes • Associations between conceptual classes

31. Class Diagram Class name Attribute ------------------------------- Operation Account account number balance ------------------------------- withdraw(amount) deposit(amount)

32. Room Booking System • Develop a room reservation system that allows teachers to book lecture halls for their classes. • Each reservation contains information about the room that is booked, the date, start and end time, class, the name of the person who booked the room and a unique booking number. • The reservation system maintains a list of lecture halls including their features such as name, location, size and number.

33. Class Diagram: Classes & Attributes • conceptual classes • attributes of conceptual classes Teacher name position Booking Room number start_time end_time Course number seats room number name location name code

34. Class Diagram Associations gets booked by Room Teacher * * 1 teaches Booking * Class

35. Class Diagram: Associations records reservation enters Teacher Booking Room 1 * * 1 1 teaches * Class

36. Multiplicity of Associations Multiplicitly denotes how many objects of one class are associated with how many objects of the other class. The following symbols can be used to denote the multiplicity of a relationship • 1 : exactly one object is involved in the relationship • * : some objects are involved in the relationship • 1..* : some objects but at least one • 0..* : some objects but possibly zero • 0,1 : zero or one object

37. Multiplicity of Associations :A :B 1 1 Classes Objects A B :A :B :A :B 1 * :B A B :A :B :A :B * * A B :A :B :A :B 1 0,1 :A :B A B :A

38. Association • One object uses another to help it carry out a task. • Classes that collaborate are usually related through • associations. This type of relationship is also • called a uses relationship. owns Car Person * 1 string model int number --------------------- ... string name --------------------- ...

39. Association Class • An association class is a class that contains information about the relationship among other associated classes. Person borrows Book * * string name int libraryid --------------------- ... string title int isbnnumber --------------------- ... Loan date loan_date int loan_period bool returned --------------------- ...

40. Association Classes customer number * Supplier Customer buys from * * supplies part number * buys Part * quantity / date

41. Higher Order Associations 1 Supplier Order 1 Customer Part * quantity /date 1 Supplier * * 1 Customer * * Order ---------------------------- quantity Part

42. Multiple Associations • Sometimes two classes are associated with each other in more than one way accesses User File * * owns string name int uid --------------------- ... int size string name long index --------------------- ... 1 *

43. Self-Associations • Sometimes a class is associated to itself as different objects play different roles 1 manager works for Employee Company * 1 string name string position --------------------- ... string name string address --------------------- ... * subordinate

44. Navigability • An association can indicate the responsibility of the involved objects by an arrow that indicates the direction of the association. If navigability exists only in one direction we call the association uni-directional otherwise bidirectional. owns Cars Person * 1 string type --------------------- ... string name --------------------- ...

45. Aggregation Aggregation means that one object contains other objects. Aggregation is also called part-of relationship. Addressbook Persons * * class Person { string name; ...} class Addressbook { Person[] persons; ... }

46. Aggregation Document Paragraph Lines 1 * 1 * 1 class Line { string text; ...} class Paragraph { Line[] lines; ... } class Figure { ...} class Document { Paragraph[] paragraphs; Figure[] figures; } * Figures

47. Composition Composition is building objects from parts. It is stronge type of aggregation in which the parts are necessary to the whole, namely they are permanently bound to the object and do not exist outside the object. Composition is ”is build of” relationship Processor 1 1 1 1 Memory CPU I/O Port

48. Generalization Generalization is a relationship defined at the class level not the object level, which means that all objects of this class must obey the relationship. This is type of relationship is also called a is-a-kind-of relationship. class Vehicle: class Car : public Vehicle class Truck : public Vehicle class MotorCycle : public Vehicle Vehicle Car Truck Motor Cycle

49. Sequence Diagrams • Sequence diagrams describe interactions among classes. These interactions are modeled as exchanges of messages. • Sequence diagrams focus on classes and the messages they exchange to accomplish some desired behavior.

50. Sequence Diagrams • Sequence diagrams are a type of interaction diagrams that contain • Class roles represent roles that objects may play within the interaction. • Lifelines represent the existence of an object over a period of time. • Activations represent the time during which an object is performing an operation. • Messages represent communications between objects.