Goal – problem Analyse – design

1. Goal – problemAnalyse – design Lecture 4 - 5 09/10/2013 – 16/10/2013

2. Learning objective More practice and deeper understanding of use cases properties • Actors • Scenario • Scope • Analysis levels • Goals level

3. Flowcharts vs Use cases Flowcharts are often used for documentation purposes because many different people use that documentation and flowcharts are easier to follow Advantages: • Easy to draw and analysis. • Easy to understand. • High-level, end-to-end visualizations. • Widely used in the various purposes. Use case diagramshows how a system interacts with the external entities. Use case diagram shows what we want the system to do rather than describe how it can be accomplished.

4. Use cases and Use-Case Diagrams • A use case is a description of a specific usage of the system • Use cases define the functionality requirements (features) of the system • A use case usually represents a user-recognizable “end-to-end” process rather than an individual step or activity within a process (e.g., “rent a video” instead of “pay for video rental”) • A use-case diagram shows any number of external actors and their connection to the use cases that the system provides • A use-case diagram generally includes a number of use cases • Use cases are often identified by: • identifying actors who input to or receive something from the system • external events that the system must respond to (e.g., “purchase an airline ticket”, “check-out a video”)

5. Actor types • a role that a user (e.g., people, other systems, and objects) plays with respect to the system. • Primary Actor is the role that interacts with the system under discussion (SuD) to reach to a particular goal • Supporting Actor sometimes another actor need to provide a service to the SuD to support the process. • Hidden actors are actors that are not dealing with the system directly but should be considered at the early stages of system design (e.g. tax officers, organisation’s management board) • Example: • Accountant goal is report the sales history • Accountant conduct queries on sales information on the system • Sale department enters required information to the system • Accountant should prepare a report for tax officer

6. Information System Tax report <<include>> Run a query <<include>> Revenue report Accountant Insert data Sale department

7. Scenarios and use cases • A use case explains how a system should respond to the main user (main actor) to fulfil a particular goal of the actor. It will be done basically through a scenario which explains the sequence of steps • A series of use cases should explain responses to the all possible requests • It can capture most of functional requirements

8. Scenario • The most important part of a use case • Includes the sequential steps to fulfil the goals of the use case • Simple to read (not more than nine steps) • Be exact about the Actors/SuD doing what

9. What is the main scenario for preparing a tax report? Information System Tax report <<include>> Run a query <<include>> Revenue report Accountant Insert data Sale department

10. Main success scenario Every thing goes as it has been planned • Example Scenario: Register User • Main success scenario: 1. User types a user name of his or her choice 2. User types a password 3. User retypes the password Submit 4. System checks if the user name is not already in use 5. System checks if the two passwords are identical 6. System registers the new player with the given parameters (user name, password)

11. Extension rout Sometimes every thing does not go as it has been planned, at these situations extension scenarios should be followed. Example Scenario: Register User • • Extensions: • 4a. User name is already in use • .1 User is requested to select another user name and • password • 5a. The two passwords are different • .1 User is requested to retype (twice) his/her password • • Trigger: User selects the "Register User" link • • Precondition: User is not logged in • • Guarantee: User becomes a registered player

12. Practice • In groups of three, try to draw a use case diagram which includes “register user” success and extension scenarios.

13. Scope and level • Use cases can be written for different scopes from business scope to technical and in different levels, from high level of details into low level. • Design scope helps you understand boundary of your system

14. What is the boundary for accounting system? Define Promotions Tax report Run a query Marketing department Insert shipment info. Insert data Revenue report Sale department Accountant

15. Define promotions Accounting System Marketing department Tax report <<include>> Run a query <<include>> Revenue report Accountant Insert data Sale department Insert shipment info.

16. Scope • Scope of use case can be whole the organisation or a part of it (e.g. finance) • Any thing out the use case scope should be considered as another use case or another actor interact with use case

17. Level • A use case can be at summary level like “Run web cellphone reseller company”, user goal level “buy a phone” or sub-function level “log on”

18. Different levels of analysis • Conceptual, Logical and Physical • System Requirements • Functional • Non-Functional • Usability

19. Conceptual design • “The 'Owner': 'CONCEPTUALLY... I would like a pot of flowers in the centre of my patio about 10 feet off the ground. They would be purely for ascetic reasons, but I want the pot to be BIG and the flowers to be real.” • It is about “what you are trying to produce”

20. Logical design “The 'Designer': 'Hmmmm. Let me see now... the physics of this situation would suggest that there are two LOGICAL alternatives... either 1) you would have to have a pedestal about 10 feet high, the weight it would have to sustain is max of 100 pounds so if it was 10 square inches in area (cross-section) the material would have to hold 10 lbs per sq. inch. You're second alternative 2) would be to hang it from something above the pot... do you have a roof over the patio?? If not, that would mean we would have to construct a tripod to suspend the pot from the apex. Do you care if you see the tripod? Hmmmm. I recommend you go with the pedestal.” It is about “how it would be designed”

21. Physical design “The 'Builder:' 'Hmmmm... the Architect is suggesting a pedestal that would be 10 feet high and sustain 10 pounds per square inch. That Architect wouldn't recognize a lathe if he fell on one... but here's what we could do... we could PHYSICALLY build the thing in three pieces and then glue it together with superglue... just in case, we could make flanges on the pieces so we could bolt the pieces together to make sure they don't come apart. Your other alternative is to have it made in Japan and ship it in one piece and then we could install it by drilling a hole in the patio, sinking the base down 2 feet and filling in the hole with cement.” It is about “how you intend to build it”

22. Overall • “conceptually what you are trying to produce... logically how it would be designed... and physically how you intend to build it” http://www.zachman.com/ea-articles-reference/58-conceptual-logical-physical-it-is-simple-by-john-a-zachman

23. Different goal levels in use cases • Very high summary, an icon of a cloud • Summary, an icon of a flying kite • User-goal, an icon of waves at sea • Subfunction, an icon of a fish • Too low, an icon of a seabed clam-shell

24. Sample for different use case levels Information System Have an e-market <<include>> Owner Process an order <<include>> <<include>> Register to system Buy clothes Buyer

25. Precondition and guarantees • Precondition • A (set) of condition(s) that should hold true before the use case scenario starts. It can be a set of use cases. (E.g use has been registered) • Minimal guarantees Ascertains what to achieve at the end of any path of scenario • Success guarantees Illustrates what should happen at the end main success scenario or any other alternative routs

27. Sample • Precondition Phone call has been made • Minimal guarantee Customer personal information and the chosen product has been recorded • Success guarantee Customer’s personal information, product’s information, payment type and shipping address has been saved