1. By: Md Rezaul Huda Reza creativereza@yahoo.com

2.  Process of modelling a system’s functions in terms of:  business events  who initiated the events and  how the system responds to the events  Identifies and describes the system functions from the perspective of external users using a tool called use cases.  Identification of:  Actors  Use Cases  Business Tasks  Use Case Diagram (the result of use case modelling)

3.  An actor represents anything external to the system that needs to interact with it to exchange information.  An actor represents a role fulfilled by a user interacting with the system. It could be an organisation, an external system as well as a person. It interacts with and benefits from the system.  Actors are drawn as stick figures.  Example: Our Greenwich university book store. Are the Central Committee, Board of Directors and Managing Director UML actors? Student Registrar Professor Billing System

4.  Outside the system - actors are typically those entities whose behaviour cannot control or change.  An actor initiates system activity, a USE CASE, for the purpose of completing some business task.  An actor is not meant to portray a single individual or a job title. E.g. Actor Staff, not Actor Andrew  Define roles, not instances  Candidates for UML actors:  Most obvious are the humans in the system  Other systems (databases, servers maintained by other people, legacy systems) Example: When adding a new database system to manage a company's finances, your system will probably have to interface with their existing inventory management software  Inventory management system is a UML actor.  Identify them outside the boundary of the system.  Not always straightforward!

5.  Interesting examples:  The billing system for a credit card company automatically generates its bills on the fifth day of the month (billing date)  A bank reconciles its check transactions every day at 5:00pm  On a nightly basis a report is automatically generated listing which courses have been closed to enrolment and which courses are still open. WHO WOULD BE THE UML ACTOR?? TIME…why?  These are examples of temporal events.  A temporal event is a system event that is triggered by TIME.  All of the example events listed above were performed (or triggered) automatically when it became a certain date or time. Thus the actor of a temporal event is time.

6.  High-level activities to be supported by the system.  Scenarios (a sequence of steps) of how a particular system might be used by the end-user (or in some cases by another software system).  Each use case is written as scenarios of around one long paragraph in length. As the analysis continues these scenarios are elaborated further and may become quite long.  A use case is one way(case) of use of the system.  One actor (called the primary actor) is normally the initiator of each use case - (use cases are associated with actors by the means of a line)  An actor may be involved in more than one use-cases.

7.  Describe the functional requirements that the system is required to support.  Each use case represents one thing that the user wants the system to do. e.g. Place an Order, Enrol to a course  Capture and communicate requirements.  Start point for the dynamic model. Illustrate, but do not specify the behaviour of a system!! (not an object sequence diagram – don’t show how messages are exchanged, don’t show flow like flow charts)  UML represents a use case as an ellipse (oval) with the name inside the ellipse or below the ellipse. Place an Order Search for Books

8.  A use case is a pattern of behaviour the system exhibits.  Use cases capture who (actor) does what (interaction) with the system, for what purpose (goal), without dealing with system internals  In order to define them: Actors are examined to determine their needs  Registrar - maintain the curriculum  Professor - request course roster  Student – enroll to a course  Billing System - receive billing information from registration Request Course Roster Maintain Curriculum Enroll to a courseGet billing information

9.  Identifies and describes the system’s functionality from the perspective of the external user, using a tool called use-cases (bubbles).  Provides a high level and user oriented description of a system - not any design detail.  It defines the boundary of the system under analysis (what is part of our system and what is not).  Four major elements:  Actors: who participate in the system and their main activities/interactions with the system in order to get something done.  The system itself and the systems’ responds  Use cases that the system knows how to perform  Lines that represent the relationships between the elements  All actors on a diagram must related to at least one use case and all use cases must have at least one actor associated with them.

10.  A system may require many use case diagrams, and it is appropriate to keep them simple and direct.  Useful way of capturing and communicating functional requirements with users and other stakeholders.  Use case Diagrams are fundamentally different from object sequence diagrams or flow charts  they do not make any attempt to represent the order or number of times that the systems actions and sub-actions should be executed.  Should NOT use case diagrams to represent exception behaviour (when errors happen) or to try to illustrate the sequence of steps that must be performed in order to complete a task  Object Sequence diagrams should be used to show these design features.  A use case diagram may contain complex functionality consisting several steps that are difficult to understand. To simplify it we could extract the more complex steps into their own use cases, by using the “extend” relationship. The new use case is called an extension use case in that it extends the functionality of the original use case (idea of inheritance and polymorphism)  Two or more use cases might perform steps of identical functionality. It is best to extract these common steps into their own use case, by using the “includes” relationship (idea of reuse)

11. Customer Credit card processing system Choose an animal Place an order Track Order Pay for an Order Primary actor Initiates Secondary actor Primary actor is one having a goal requiring the assistance of the system – it thus initiates a system activity. Secondary actor is one from which the system needs assistance. Pet shop system System boundary

12. Tiime Generate annual sales analysis Generate quarterly reports Generate annual gold membership analysis Primary actor Initiates Reservation System System boundary Temporal events triggered Automatically when it became a certain time or date

13. Ticket Clerk Check in passenger Add reservation Cancel reservation Edit customer details Primary actor Initiates Reservation System System boundary

14.  A box around the Use Cases  Defining the boundary can be tricky! (where do you draw the line or what use cases shall be in it??)  An iterative process. Functional requirements (use cases) come always from the customer. Do not invent requirements. Check in passenger Add reservation Cancel reservation Edit customer details Initiates Reservation System Ticket Clerk Call Ticket Clerk WRONG!! Calling the Clerk is not a functionality of the system

15.  Use case diagrams represent functionality in a top-down way.  The initial step is to identify all of the top-level behaviour of the system.  described in a high-level way, all of the things your system knows how to do.  Continue to add detail by decomposing your use cases into other use cases which are used(included) by the top-level use cases.  At every stage of development, the use case diagram is a complete description of the system's functionality: it may lack detail, but it will not lack feature set elements.  If functionality or behaviour is added or deleted over the life of your project, the change you need to make is proportional to both the change in the system itself, and the maturity of your model  when your model is “young” (only high-level diagrams drawn) making sweeping changes to the system does not involve throwing very much work away.

16.  Two relationships that can be used to structure use cases and add more design detail to the use case diagram.  > or > and >  Support the idea of reuse, inheritance and polymorphism!  The are also relationships between actors. One popular relationship between Actors is Generalization/Specialization. This is useful in defining overlapping roles between actors.  The notation is a solid line ending in a hollow triangle drawn from the specialized to the more general actor

17.  Two or more use cases might perform steps of identical functionality. It is best to extract these common steps into their own use case, by using the > relationship (idea of reuse)  >  It is drawn from a use case A to another use case B to indicate that “the process of doing A involves doing B at least once” (although it may involve doing this many times)  B is included in A  A has B as apart of its behaviour  It can be seen as an aggregation operator as it indicates that a given use case is an aggregate - made up of the use cases that it uses.  An > relationship means that If a certain use case uses several others, all of those other use cases MUST BE COMPLETED, although in use case diagrams we don’t care about order in which these are completed. A B >

18. Source: the web

19. Register Edit email address Change password Search for book Customer Authenticate user >

20.  A use case may contain complex functionality consisting several steps that are difficult to understand.  To simplify it we could extract the more complex steps into their own use cases, by using the > relationship.  The new use case is called an extension use case in that it extends the functionality of the original use case (idea of inheritance and polymorphism)  >  is drawn from a use case B to a use case A to indicate that the use case B is a special case behaviour of the same type of the more general use case A.  You would use this in situations where your system has a number of use cases that all have some subtasks in common, but each one has something different about it that makes it impossible for you to just lump them all together into the same use case.  The extends use case might or might not happen, depending on the extension points. A B >

21. Source: the web

22. Register Edit email address Change password Search for book Customer Post membership details to new email address > Authenticate user >

23. Extension points: If one use case extends another, it adds behaviour under certain conditions. Those conditions are exception points. They therefore describe a point in a use case where an extending use case may provide additional behaviour.

24. For each use case (functionality) identified, write down its narrative. This includes providing the following information (Whitten et al. 2001 book) 1)Use case name 2)Actors involved (that initiate the use case) 3)Brief description 4)Typical course of events that includes the main flow of events (actor action and system response) and can be broken down to show Sub flows of events. 5)Alternative course of events to define exceptional situations. 6)Preconditions necessary for the use case to start. 7)Post conditions that define the state of the system after the use case ends. 8)Assumptions

25. Use case Name: Actors: Description: Typical course of events:Actor Action: System Response: Alternate course of events: Precondition: Postcondition: Assumptions

26. Use case nameChoose an animal ActorsCustomer DescriptionThis describes how a customer can select a particular animal from the website Typical course of eventsActor Action Step 1:This use case is initiated by a customer Step 3: Customer can search by name or skill. Step 5: Customer selects an animal from the list System response Step 2: Customer is presented with a web page with a selection of search criteria. Step 4: Customer is presented with a list of animals Alternate coursesStep 5: If the customer chooses an animal that is not available, then a notification is sent to the customer PreconditionThis use case is initiated by customers Post conditionList of animals AssumptionsNone at this time

27.  Step 1: Identify actors. For each actor, identify all the significant goals they have that the system will support.  Step 2: Create a use case for each goal (functional requirements).  Step 3: Construct the use case diagram to graphically depict the system scope and boundaries.  Avoid over-structuring of use-cases, as this can make the use cases harder to follow. Usually 7+-2 use cases in a diagram.

28.  Step 3: For each use case identified, document its narrative/story (the general steps – typical course and alternate courses of action).  Goal is to quickly document all the use cases in order to define and validate requirements.  This initial version of the use case is called requirements use case.  Top level use case is created here.  Step 4: Once all requirements use cases are approved by the users, each use case is refined to include more information in order to specify the system functionality in more detail.  Here is where you actually use the “extends” and “includes” relationships.  you add more design detail  In this step, in order to make the use case diagram more easily understood, new use cases may need to be created.  The resulting use cases are called analysis use cases.

29. University online Library system Each Student can borrow up to 3 books at a particular time. Students can browse an online catalogue for books. Loans should be recorded against particular book copies, rather than their titles, as there may be several copies of a particular book. If all of the copies of a book are out on loan, the student may wish to place a reservation for it. The reservation is placed against the book title. A student can also extend their loan, if the book was not already reserved. When a copy of that title becomes available, that copy is reserved for the student by the librarian, and the student is then notified that their copy is ready for collection.

30. Browse online catalogue Borrow a book Reserve a book Notify student to Collect Book Student > Check availability > Librarian Extend book loan

31.  Use case modelling with UML  Use case diagrams  Extends and includes relationships  Creating scenarios. Next week: Using UML notations to create class diagrams