1. Lecture 2: Information Engineering Dr. Taysir Hassan Abdel Hamid October 12, 2015

2. Outline UML Diagrams * Behavioral Diagrams: Use Case, Interaction Diagrams (Activity, Sequence and Timing diagrams)

4. Business Use Case Diagram Business Use Case diagrams are used to represent the functionality provided by an organization as a whole They answer the questions "What does the business do?" and "Why are we building the system?" Business Use Case diagrams are drawn from the organizational perspective They do not differentiate between manual and automated processes Business Use Case diagrams show the interactions between business use cases and business actors

5. Business Use Case Diagram cont. When using UML to build software, business modeling can help to understand the context of the system to be build If we fail to understand the business, we may make faulty assumptions about what the software should do and how it can best be used by the business community The "world around the system" is an important consideration when building software Business modeling gives the team a view of the business itself, the workflows within it, and the way the new system will help automate portions of the workflow

6. Elements of Business Use Cases NotationRepresentationElement Business use cases Business actors Business workers A business actor is anyone or anything that is external to the organization but interacts with it (Individual, group, company,…) Secondary Actor It represents the workflow within the organization. It keeps focus on what the business is doing Named in the form of A business worker is a role within the organization Primary Actor Associations An arrow from a business actor or a business worker to a use case suggests that the actor or worker initiates the use case

8. Business Use Case Diagram (Airlines Example) Practice (Restaurant Example) To Do

9. Use Case Diagram Use cases represent system functionality, the requirements of the system from the user's perspective Use cases just focus on automated processes Use Case diagrams show the interactions between use cases and actors There is not a one-to-one relationship between business use cases and use cases

10. Actor An actor is anyone or anything that is outside the system’s scope but interacts with it (Individual, group, company,…) There are three primary types of actors: Users of the system  physical person, or a user who will be directly using the system Other systems that will interact with the system being built Time  Time becomes an actor when the passing of a certain amount of time triggers some event in the system (out of control) Elements of Use Case Diagram

11. Use Case It is the functionality the system will provide a value to the end user Use cases are an implementation-independent: High-level view of what the user expects from the system Focus on what the system should do, not how the system will do it A typical system will have somewhere between 20 and 70 use cases The use cases should be named in user terms, not technical terms, and should be meaningful to the customer Elements of Use Case Diagram

12. Use Case cont. So, when you have the final list of use cases, how do you know if you've found them all? - Is each functional requirement in at least one use case? If a requirement is not in a use case, it will not be implemented. - Have you considered how each end user will be using the system? - What information will each end user be providing for the system? - What information will each end user be receiving from the system? - Have you considered maintenance issues? Someone will need to start the system and shut it down. - Have you identified all of the external systems with which the system will need to interact? - What information will each external system be providing to the system and receiving from the system? Elements of Use Case Diagram

13. Use Case: Flow of Events To actually build the system, though, you'll need more specific details. These details are written as the flow of events The purpose of the flow of events is to document the flow of logic through the use case Although it is detailed, the flow of events is still implementation-independent Elements of Use Case Diagram

14. Use Case: Flow of Events cont. This document will describe in detail what the user of the system will do and what the system itself will do Notice the pattern in the flow of events: The user does something, then The system does something in response, Then the user does something, then the system responds, and so on Elements of Use Case Diagram

15. Use Case: Flow of Events cont. It includes: *A brief description: Each use case should include a short description that explains what the use case will do Preconditions: list any conditions that have to be met before the use case can start at all. For example, the precondition for one use case may be that another use case has run *Flow of events Post conditions: are conditions that must always be true after the use case has finished executing. Like preconditions, post conditions can be used to add information about the order in which the use cases are run Elements of Use Case Diagram

16. Use Case: Flow of Events Types There are three types of flows: Primary flow is the "happy day" scenario, or the most frequently used path through the use case Alternate flows are deviations from the primary flow that do not suggest an error condition Error flows are deviations from the primary or alternate flows that suggest some sort of error condition. Error flows suggest that there is a problem with the system itself Elements of Use Case Diagram

17. Use Case: Flow of Events Users There are three primary users of the flow of events: 1- The customers will be reviewing this document to make sure it accurately reflects their expectations 2- The system designers will be using it to create the system design and eventually to build the system 3- The quality assurance team will use the flow of events to create test scripts The flow of events must give them enough information to understand the sequence of events that needs to occur through the use case Elements of Use Case Diagram

18. Relationships The association relationship is used to show the relationship between a use case and an actor There are three types of relationships between use cases Includes relationship Extends relationship Generalization relationship These relationships are used when there is a certain amount of commonality between the use cases There is only one relationship allowed between actors. This is a generalization relationship Elements of Use Case Diagram

19. Relationships: Association Association relationship is used to show the relationship between a use case and an actor Every use case must be initiated by an actor, With the exception of use cases in includes and extends relationships Elements of Use Case Diagram

20. Relationships: Includes Includes relationship allows one use case to use the functionality provided by another use case This relationship can be used in one of two cases: First, if two or more use cases have a large piece of functionality that is identical The second case where an includes relationship is helpful is a situation in which a single use case has an unusually large amount of functionality An includes relationship suggests that one use case always uses the functionality provided by another Elements of Use Case Diagram > Purchase Ticket Check Credit

21. Relationships: Extends Extends relationship allows one use case the option to extend the functionality provided by another use case It is very similar to an includes relationship, because in both of these types of relationships, you separate some common functionality into its own use case Elements of Use Case Diagram An abstract use case is one that is not started directly by an actor. Instead, an abstract use case provides some additional functionality that can be used by other use cases. Abstract use cases are the use cases that participate in an includes or extends relationship > Change ReservationCheck Credit

22. Relationships: Generalization Generalization relationship is used to show that several actors or use cases have some commonality For example, you may have two types of customers. If the type A customers will be initiating some use cases that type B customers will not, it's probably worth including the actor generalizations. If both types of customers use the same use cases, it's probably not necessary to show an actor generalization Elements of Use Case Diagram Salaried Employee Employee Hourly Employee Phone Salesperson Salesperson In person Salesperson

24. Interaction Diagrams Shows, step-by-step, flows through a use case: - What objects are needed for the flow - What messages the objects send to each other - What actor initiates the flow - What order the messages are sent Sequence and Collaboration diagrams: - Show the same information but is organized differently - Show it in a way that is more useful to developers - Help to define how the system will do - Focus on objects (classes) that will be created to implement the functionality spelled out in the use cases

25. Interaction Diagrams The steps involved in creating them: - Find the Objects (Examine the nouns in the flow of events) (Take care of attributes) - Finding the Actors (External stimulus (who or what) that starts flow of events) - Add Messages (Communication)

26. Sequence Diagrams Sequence diagrams are interaction diagrams ordered by time Each diagram represent one of the flows through a use case Sequence Diagram users: Users can look at these diagrams to see the specifics of their business processing Analysts see the flow of processing in the Sequence diagrams Developers see objects that need to be developed and operations for those objects Quality assurance engineers can see the details of the process and develop test cases based on the processing

27. Sequence Diagrams Actors and Objects shown at the top of the diagram Each object has a lifeline, drawn as a vertical dashed line below the object - The lifeline begins when the object is instantiated and ends when the object is destroyed A Message is drawn between the lifelines of two objects to show that the objects communicate (each message will become an operation). Messages can also be reflexive, showing that an object is calling one of its own operations

28. 28 Sequence Diagram A sequence diagram is An interaction diagram that details how operations are carried out. What messages are sent and when. Sequence diagrams are organized according to time Object: Class Lifeline Operations Message

29. Depending on the type of action that was used to generate the message, message could be one of:action synchronous call asynchronous call asynchronous signal create delete reply

30. Messages (synchronous call)synchronous call Synchronous call typically represents operation call - send message and suspend execution while waiting for response. Synchronous call messages are shown with filled arrow head.

31. Messages (asynchronous call)asynchronous call Asynchronous call - send message and proceed immediately without waiting for return value. Asynchronous messages have an open arrow head.

32. Create Message Create message is sent to a lifeline to create itself. It is shown as a dashed line with open arrowhead (looks the same as reply message), and pointing to the created lifeline's head.lifelinereply message

33. Delete Message Delete message (called stop in previous versions of UML) is sent to terminate another lifeline.lifeline

34. Reply Message Reply message to an operation call is shown as a dashed line with open arrow head (looks similar to creation message).

36. Activity Diagrams Activity contains activity nodes which could be: action object control

37. May contain actions such as Occurrences of primitive functions, such as arithmetic functions. Communication actions, such as sending of signals. Manipulations of objects, such as reading or writing attributes or associations.

38. 38 Activities Diagram Activity diagrams describe the workflow behaviour of a system Start Fork Branch Merge Joint End

40. Activity partition Activity partition may be shown using a swimlane notation - with two, usually parallel lines, either horizontal or vertical, and a name labeling the partition in a box at one end. Any activity nodes, e.g. actions and edges placed between these lines are considered to be contained within the partition.

42. Example of process order

43. Examples of Activity Diagrams (1. Online Shopping) Online customer can browse or search items, view specific item, add it to shopping cart, view and update shopping cart, checkout. User can view shopping cart at any time. Checkout is assumed to include user registration and login.

44. Examples of Activity Diagrams (2. Document Management Process) A document goes through different state or stages - it is created, reviewed, updated, approved, and at some point archived. Different roles participating in this process are Author, Reviewer, Approver, and Owner. These roles are represented on the diagram by partitions rendered as horizontal "swimlanes".statepartitions

45. 2. Document Management Process

47. Timing Diagrams Timing diagrams are UML interaction diagrams used to show interactions when a primary purpose of the diagram is to reason about time.interaction diagrams Timing diagrams focus on conditions changing within and among lifelines along a linear time axis. Timing diagrams describe behavior of both individual classifiers and interactions of classifiers, focusing attention on time of events causing changes in the modeled conditions of the lifelines.classifiers

48. Timing Diagrams (Cont…) The following nodes and edges are typically drawn in a UML timing diagram: lifeline, state or condition timeline, destruction event, duration constraint, time constraint.lifelinestate or condition timelinedestruction eventduration constrainttime constraint

49. Timing Diagrams (Cont…) Lifeline is a named element which represents an individual participant in the interaction. named element

50. Timing Diagrams (Cont…) Timing diagram could show states of the participating classifier or attribute, or some testable conditions, such as a discrete or enumerable value of an attribute.classifier

51. Timing Diagrams (Cont…) Duration constraint is an interval constraint that refers to a duration interval. The duration interval is duration used to determine whether the constraint is satisfied.interval constraint

52. Timing Diagrams (Cont…) Time constraint is an interval constraint that refers to a time interval. The time interval is time expression used to determine whether the constraint is satisfied.interval constraint

53. Example 1: Alzheimer’s Stages