1 System Requirements ΥΠΕΥΘΥΝΟΣ: Θ. ΜΑΝΑΒΗΣ UML Introduction – Use Case Diagrams

2 Remember... Software development lifecycle In the analysis phase we move from a vague description of the problem to be solved to a precise and unambiguous requirements specification. The requirements specification might be a precise, but informal description written in careful natural language text and diagrams. The requirements specification should be: complete, consistent, readable by application domain experts and software developers, independent of programming considerations. In the design phase, we move from a requirements specification to a design specification. The design specification gives the system structure. The design tasks are to: Break the programming task into manageable parts. Define the relationships among the parts. Incorporate any required or appropriate pre-existing components. Keep the design independent of implementation language and hardware details. In the implementation phase, we move from a design specification to a tested executable system. In the maintenance phase, we move from a complete "working" system to a modified system. The maintenance tasks are to: Repair any errors in analysis, design, or implementation that have been found. Adapt to the changes in requirements that have occurred. The cost of failure at different stages of the lifecycle

3 What is UML UML: Unified Modeling Language (Booch, Rumbaugh, Jacobson) Used for specification, analysis, design and implementation of OOSD process (Object- oriented System Development) Aim of using UML: UML is a visual modeling tool (uses text and graphics). Communicates the ideas of a design with a notation more precise than natural language (e.g., English), and not as precise as an actual programming language. In this sense, it has the same purpose as a pseudo-code language. UML is NOT a programming language! There are 3 levels at which UML can be used: CONCEPTUAL (resembles human language), SPECIFICATION and IMPLEMENTATION (the last 2 have strong connection with source code). UML has static and dynamic diagrams: Static diagrams provide a snapshot of the elements of the system but do not tell us how the elements will behave. Class and Object Diagrams belong to this type. Dynamic diagrams depict the interactions between the objects in response to the environment. Sequence, Collaboration and Statechart diagrams belong to the above category. UML is only a tool. Do not be fooled into thinking that knowing UML makes you a good designer!!

4 Use Cases and Use Case modeling A Use Case is a definition of a meaningful interaction with a computer system. If you have used the internet to buy things, an example of a Use Case would be choosing something from an online catalogue, and another might be paying for the goods. Use Case modeling is part of requirements definition and systems analysis. At the high level, a set of Use Case diagrams provide a general description of the system, and these are excellent tools for discussion with people who use the system (users) and people who will pay for the creation of it (sponsors). At a more detailed level, Use Case modeling is used to fully specify the functionality of a system (with the help of sequence diagrams it becomes a bridge between analysis and design). Use Case diagrams say "what" a system does. The detailed analysis of Use Cases begins to say something of "how" the system behaves in an environment. However, it does not say "how" a system is structured internally to provide that behaviour. In computer system development you will frequently see this separation emphasized. Before you decide how a system works, you need to determine what it does first - a simple and obvious rule, but one so often forgotten to many people's ultimate regret.

5 Use case diagrams Use cases define the required features of the system. Without these features the system cannot be used succesfully. Each use case is named using a verb phrase that shows a goal the system must accomplish, e.g: “deposit money”, “withdraw money” etc. By defining use cases like that the system is defined as a set of requirements rather than a solution. We do not describe HOW the system must work. We define WHAT the system must be able to do. Elements of a Use Case Diagram

6 Notation Association Notation: A line connecting an actor to a use case. Most associations are bidirectional (we omit the arrows), that means that the actor accesses the Use Case and the Use Case provides functionality to the actor. Stereotype notation: 2 types exist: 1. > dependency notation (one Use Case will include the functionality of another) 2. > dependency notation (one Use Case might need help from another Use Case). Difference between the two: >: always! >: possibly! Generalisation: Inheritance

7 Include, Extend, an example Keep this example in mind in order to understand the difference between the > and > notations. The > dependency means that the “Withdraw Cash” use case will DEFINITELY call the “Update Account” use case because it cannot be completed without it. The > dependency means that the “Withdraw Cash with Overdraft Protection” use case MAY NEED to call the “Protect Overdraft” use case. This will happen if the Customer will try to withdraw more cash than he/she has available in his/her account.

8 Defining a good use case 1/3 In order to create the use case diagram, we identify the actors first and then we try to find the most important use cases. A use case is an actor-initiated, complete, system behaviour that brings value to the actor. Sometimes it may be difficult to identify the initial set of use cases that our system offers. The solution is to try to see the “big picture”, which means that we try to find the most important functionality that the systems offers to the user. After the initial main use cases have been identified (the high level use case diagram (the one with not much detail)) we can refine the diagram by further analyzing the main use cases. This practically means that we try to break down the main use cases (by adding the > and > dependencies). In this way we create the more detailed (low level) use case diagram. As an analogy think of the Data Flow Diagram, where level 1 consists of the main processes of the system and levels 2 and below analyze the main processes of level 1. The list that follows provides several helpful (hopefully) hints for defining a good use case:

9 Defining a good use case 2/3  Choose a good name: A use case is a behavior, so you should name it with a verb phrase. To make it more precise, you should add a noun to the name to indicate the class of objects that the action effects. To help you choose the verb-noun phrase for the use case name, going back to the class diagrams that helped you find the actors may help identify the objects and the associations created by the use cases. Look at a possible good name for your use case, by examining the name of the relationships of the actor to the system’s objects.  Illustrate a complete behavior: A use case must be a complete behavior that starts with the initiating event from the primary actor and ends with the actor normally reaching his/her goal. If a proposed use case is only a step along the way to the goal, don’t treat it as a use case unless you can consider it a goal in itself. For example, Specify the Bed Size (such as king, queen, or double) is an activity that you have to perform to reserve a room— but it’s only a part of the Make a Room Reservation use case because it never really stands alone and doesn’t (by itself) return a useful result. It’s not really a goal for the actor to use the system. However, you may consider Check Room Availability important enough to be a use case. It returns a value and could stand alone.  Identify a completable behavior: To achieve a goal and produce value for an actor, the use case must complete. When you name the use case, choose a verb phrase form that implies completion or ending. For example, use Reserve a Room, rather than Reserving a Room, because the “ing” describes an ongoing behavior.

10 Defining a good use case 3/3  Provide “inverse” use cases: Whenever you see a use case that accomplishes a goal that is to change a state in the system, you probably need a use case to un-accomplish that goal. For example, the use case Make a Room Reservation is undone with Cancel Room Reservation. Use cases that just obtain information don’t need an undo. (For example, you don’t need an undo for Check Room Availability.)  Limit each use case to one behavior: Sometimes you might be tempted to have a use case achieve more than one goal or do more than one activity. To avoid confusion, keep the use case focused on only one thing. For example, the potential use case Check-in and Check- out is unfocused; it attempts to describe two different behaviors. If a proposed use-case name has an and or an or in the name, it’s probably too unfocused to be one activity.  Represent the actor’s point of view: Write the use case from the actor’s point of view, using the terminology of the actor, not that of the system. Doing so allows the actors to review their use case properly without having to learn your system’s terminology. In addition, it helps keep you and your team learning—and using—your user’s terminology, making you more responsive to their needs. For example, you would allow a Guest to use the system to help Reserve a Room (using common Guest terminology), but you would not name that use case Schedule Room Assignment, because that’s a Hotel’s terminology and not the Guest’s.  Tip : One hint that can help you find good names for your use cases is to put the name in the conversational words of a typical actor—for example, “System, please help me to.” When you use this form, you automatically force the use-case name to adopt the actor’s point of view.  A use case should not describe the user interface of the system