Business Applications with Object-Oriented Paradigm: A Use-Case Modeling

1. Business Applications with Object-Oriented Paradigm:A Use-Case Modeling Professor Chen School of Business Gonzaga University Spokane, WA 99258 chen@gonzaga.edu

2. Figure: A Use-Cases Example System Boundary ACTOR Use Case <initiate> <communicate> Signing an insurance policy Sales Statistics <send> <receive> <deliver tangible value to> (Role) Customer Statistics

3. Purposes of the Use-Case Modeling • What a new system should do • What an existing system already does

4. What is an Actor? • An actor is a class not an instance. • It represents a role, not an individual user of the system. • primary vs. secondary actors • customer/user, developer, test teams vs. manager or board members • active vs. passive • initiate/never initiate use case

5. Figure: An Library Use-Cases Example Library Borrow books Return books Interlibrary loan Circulation Clerk Do research Read books, newspaper Member Purchase supplies Supplier

6. Summary • Use-case modeling is a technique used to describe the functional requirements of a system • A use case is a set of sequence of actions performed in the system. • A scenario is an illustration or an example (instance) of a use case or collaboration. • An actor represents a role that an external entity (user, hardware) plays in interacting with the system. N

8. N

9. Activity Diagram Diagrams Collaboration [space] ACTOR Use Case <realizes> [time] Sequence Collaboration [work] Internal Activity [Implementation Independent] [Interaction relationship] <OUTPUT> IMPLEMENTS} (Role) class [CONTEXT] External Behavior [Implementation Independent]

10. Figure 3.8 An activity diagram used to describe the interaction between the actor and the use case. Inserts coins into machine Check that enough coins have been inserted Show that drink now can be chosen Show that drink is not available Choose drink Drink Consumer [drink not available] [drink available] Deliver drink

11. refers to a describe a  Is an instance of a Perspective Model Type Modeling Language Model (Document) Use Case Text in natural language Description of a use case Outside the system Is a realization of a (implements) Sequence diagram (time) Collaboration (context and interaction) (space) Collaboration diagram Description of an interaction Inside the system boundary (work)  Activity diagram Is an instance of a may be illustrated by one or more Sequence diagram An execution path through the system (time) Scenario (space) Collaboration diagram Description of a scenario (work) Activity diagram Figure 3.10 The relationships between use case, collaboration, and scenario.

12. Insurance company Insurance contract 1 0..* 0..* 1..* Figure 4.1: A simple mode of an insurance business. One insurance company has many (zero-to-many) insurance contracts. An insurance customer has many (zero-to-many) insurance contracts. An insurance contract is related to one insurance company. The insurance contract is related to many (one-to-many) insurance customers. The entities shown in the model are classes. Customer

13. Name Attributes Operations Figure 4.2 A Class in UML

14. Car registration number data speed direction Figure 4.3 A class car with the attributes registration number, data, speed, and direction. Attribute names typically begin with a lowercase letter

15. Car Invoice registration number: String data: CarData speed: integer direction: Direction +amount : Real + date: Date + customer: String +specification: String -administrator: String Figure 4.5: A class with public and private attributes Figure 4.4 The car with typed attributes

16. Invoice +amount : Real + date: Date=Current date + customer: String +specification: String -administrator: String=“Unspecified” Figure 4.6 A class with attributes and their default values

17. Invoice +amount : Real + date: Date=Current date + customer: String +specification: String -administrator: String=“Unspecified” -number_of_invoices: integer Figure 4.7 A class with a class-scope attribute. The attribute number_of_invoices is used to count the invoices; the values of this attribute is the same in all objects because the attributes is shared between them

18. Invoice +amount : Real + date: Date=Current date + customer: String +specification: String -administrator: String=“Unspecified” -number_of_invoices: integer + status: Status=unpaid { unpaid, paid Figure 4.8 An attribute with an enumeration type status: The property-list is { unpaid, paid

19. Invoice +amount : Real +date: Date=Current date +customer: String -number_of_invoices: integer = 0 Public class Invoice { public double amount; public Date date = new Date(); public String customer; static private int number_of_invoices = 0; //Constructor, called every time an objects is created public Invoice () { // Other Initialization number_of_invoices++; //Increment the class attributes } // Other methods go here }; Figure 4.9 An Invoice class

20. Car + registration number: String + data: CarData + speed: integer + direction: Direction + drive (speed: integer, direction: Direction) + getData() : CarData Figure 4.10 The car has attributes and operations. The operation drive has two parameters, speed and direction. The operation getData has a return type, CarData.

21. Associations: Normal Association Uses Author Computer Figure 4.15 An author uses a computer The author class has an association to the Computer class.

22. Owns 0..* Person 1..* Car Owned by Figure 4.16 A person owns many (zero-to-many) cars, A car can be owned by many (one-to-many) persons.

23. Owns 0..* Person Car Figure 4.17 A navigable association says that a person can own many cars, but it does not say anything about how many people can own a car.

24. Insurance policy Web Insurance policy 0..1 0..1 is expressed in an Expressed an  Insurance company Insurance contract has 1 0..* refer to 0..* has refer to 1..* Customer Figure 4.18 A class diagram describing an insurance business

25. Author Computer Bob:Author Bob’s PC COMPUTER name : String age: Integer name : String money: Integer name : String age: Integer name : String money: Integer 0..* 0..* 1..* 1..* Figure4.19 A class diagram and an object diagram and an example of the class diagram being instantiated

26. Node Connects Recursive Association Person married to Figure 4.20 A network consists of many nodes connected to each other.

27. Insurance company Insurance contract contracts 1 0..* refer to Figure 4.22 Insurance company has associations to Insurance contract

28. Associations • The topics of the association we have learned from last class include: • association name • multiplicity (default is 1) • normal association • recursive association • We will learn the following topics today: • how to transform from *..* to 1..* and why • roles • qualified • or and more ...

29. A B * * Can be transformed into A C B 1 1 * * Figure 4.23 A bidirectional many-to-many association can be transformed into two one-to-many associations.

30. Example of mapping an M:N relationship (Fig.4.23) (a) Requests relationship (M:N)

31. Example of mapping an M:N relationship (Fig.4.23) (a) Associative entity (ORDER_LINE)

32. Mapping an associative entity: Three resulting relations PK PK FK FK PK

33. An example of Roles in Association * drives Car * Person company car driver Figure 4.24 What roles do Person and Car play in this association?

34. Person wife husband married to Roles in Association  Figure 4.25A husband is married to a wife. Both husband and wife are people. If a person is not married, then he or she cannot play the role of husband or wife, which means that the married to association is no applicable.

35. Insurance policy Roles in an Association 0..1 is expressed in an Expressed an  Insurance company Insurance contract 1 has 0..* refer to insurer 0..*  has refer to Figure 4.26 A class can play different roles in different associations. The model from Figures 4.18 and 4.25 are combined. In this model, a person can play the role of husband, wife, or policyholder. The insurance company plays the insurer role. policyholder 1..* Person wife husband married to 

36. Canvas * * Figure Canvas * Figure figure id Qualified Association Figure 4.27 In the Canvas class, the association is represented with a unique identification for each figure (figure id).

37. Directory * File * Another example for Qualified Association Directory * File file name

38. Or-Association Insurance company Insurance contract 1 0..* 0..* 0..* 1..* 1..* Person Company Figure 4.28 An insurance contract cannot have associations to both company and person at the same time

39. or Or-Association Insurance company Insurance contract 1 0..* 0..* 0..* 1..* 1..* Person Company Figure 4.29 An or-association shows that only one of the associations is valid at a time

40. 0..* Insurance company Insurance contract 1 has 0..* refer to insurer 1..* 1..* 0..* Company  has refer to policyholder Person wife husband married to Or-Association or Results of Figures 4.26, 28, and 29: An insurance contract cannot have associations to both company and person at the same time 

41. Insurance contract 0..* Window ordered ordered 0..* 1..* Customer 1..* Figure 4.30: Twoexamples withordered associations Screen

42. Figure 4.31 The association class Queue could be extended with operations to add requests to the queue, to read and remove requests from the queue, and to read the length. If operations or attributes are added to the association class, they should be shown as in a class. Association Class Queue Elevator control Elevator 4 * Button

43. Figure 4.31 The association class Queue could be extended with operations to add requests to the queue, to read and remove requests from the queue, and to read the length. If operations or attributes are added to the association class, they should be shown as in a class. Association Class Queue add read remove Elevator control Elevator 4 * Button

44. Authorization priority privilege start session home directory Directory * Another example with association class Authorize on User 0..* Workstation 0..*

45. Insurance company Insurance contract 1 0..* insurer 0..* Insurance policy 0..1 policyholder 1..* Person Figure 4.32 A ternary association connects three classes.

46. Flight date flight# cancel delay Seat location reserve Another ternary example:A passenger’s seat in a plane Passenger name Reserve Figure: A ternary association connects three classes.

47. Exercise:3.14 (Figure E3.7)

48. Q: Why not use the normal association? Navy * Warship Contains Figure 4.33 The Navy contains many warships. Some warships can be removed and it is still anavy, and some warships can be added and it is still a navy. This is significant for a normal aggregation (but not for a compositionaggregation, as described later). The parts (the warships) compose the whole (the Navy). The hollow diamond shows the shared aggregation.

49. Teams * * Person Members Figure 4.34 A team is composed of team Members. One person could be a member of many teams. The model shows an example of a shared aggregation, where the people are the shared parts.

50. * * * * Text Listbox Button Menu Window Figure 4.36The diamond shows the composition aggregate; the window contains ( is aggregated of) many menus, buttons, listboxes, and texts. All types of aggregation can have a name.