Chapter 1 , 2 , 3 and 4 Applying UML and Patterns -Craig Larman Last lecture Chapter 1 , 2 , 3 and 4 Applying UML and Patterns -Craig Larman

The Unified Process A standardized approach to analysis and design helps to ensure that all necessary tasks are understood and completed in software development. The course, will focus on the Unified Process developed at Rational Software by Ivar Jacobsen, Grady Boch, Jim Rumbaugh, and others.

Applying UML UML is just a standard diagramming notation. It is just a tool. Knowing UML helps you communicate with others in creating software NB: Goal of this class: Learning Object-Oriented Analysis and Design, not how to draw diagrams.

The Most Important Concept Each iteration will include requirements, analysis, design, and implementation. Iterations are timeboxed. Incremental : system grows over time

Example: Building a House Incremental: Start with a modest house, keep adding rooms and upgrades to it. Iterative: On each iteration, the house is re-designed and built a new.

Rational Unified Process Phases Process Workflows Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n Iter. #n+1 Iter. #n+2 Iter. #m Iter. #m+1 Iterations within phases

Iterations

Another approach :Waterfall Model All or most of the requirements are defined before development begins Requirements Design Implementation Test

Example Questions in Inception Ask questions such as: What is the vision and business case for this project? Feasible? Buy and/or build? Buy components and glue them together or from scratch? Estimate potential risks Rough estimate of cost: Is it $10K-100K or in the millions? Should we proceed or stop? If the answer is YES …..

What Artifacts (documents or model) may start in Inception? Vision and Business Case: describes the high-level goals and constraints, provides an executive summary; Use Case Model (chap 6 Today): describes the fundamental requirements: during inception identify the names of the use cases and analyse perhaps 10% of the them; Supplementary specification (chap 7 Today ): describe non-functional requirements, look-and-feel, atmosphere etc. 10

What artifacts (documents or model) may start in Inception? Glossary (Chap 7 today): keeping track to key terms; Risk list and risk management plan: describe the risks (business, technical, resource, schedule) and ideas for their mitigation; Prototypes and proof-of-concepts: to clarify the vision, and validate technical ideas; Iteration Plan : Describes what to do in the first elaboration iteration, and overall goals of the elaboration phase; IMPORTANT : Artifacts will be partial at this stage. Will be refined in later iterations.

Any question before we go on with new topic?

Chapter 5 and 6 Applying UML and Patterns -Craig Larman Use Cases Chapter 5 and 6 Applying UML and Patterns -Craig Larman

Program for today What is a Use case? How find stakeholders ? Find Use cases Prioritize Use Cases Detailled Use cases Organize the use case Model

Use Cases Use cases are stories (scenarios) of how actors use (interact with) the system to fulfill his goal. Use cases are ‘tasks’ done by the system and has observable value to the actor Process sale Place Order Loan book A full description of a use case includes: a basic course of events; a number of alternative and exceptional courses.

Use Case 1 Use case Text documents, not diagrams Use case modeling is writing text, not drawing diagrams. Nothing object-oriented about use cases; Use cases are a key requirements input to classic OOA/D. Functional requirements that indicate what the system will do. 16

The purpose of use cases Uncover and describe all tasks that need doing in a system (of both human and system actors) Give a clear and consistent description of what the system should do. Provide a basis for performing tests that verify the system delivers the functionality stated. To analyse what functionality that need developing for the system

Use cases documented in two ways Verbal description Describes the content of each use case Typically uses a pre-defined template Use Case diagrams Give an overview of visible use scenarios in the system Describes what actors that interact with the system Describes any linkages between use cases

Use Case Formats (verbal description) Brief Terse one-paragraph summary, usually the main success scenario. During early requirements analysis Casual Informal, multiple paragraphs that cover various scenarios. Fully dressed The most elaborate. All steps and variations are written in detail and there are supporting sections with preconditions etc.

Use case diagram Boundary of the system (1) Actor (2) Linkage between use cases (4) Use case (3)

Actors - stakeholders Actor: external entity interacts (behavior) with system, such as a person (identified by role), computer system, or organization; for example, a cashier. 21

Actors - stakeholders Three kind of Actors - Stakeholders Primary actor has user goals fulfilled through using services. (e.g., the cashier). Supporting actor provides a service (e.g., the automated payment authorization service is an example). Often a computer system, but could be an organization or person (external interfaces) (e.g. : tax calculation ) Offstage actor has an interest in the behavior of the use case, but is not primary or supporting (e.g., a government tax agency). 22

How to find actors (stakeholders) ? Who will use the system? Good Habits: keep a few individuals (two or three) in mind and make sure that the actors you identify cover their needs. Usefull questions to have in mind : Who will supply, use, or remove information? Who will use this functionality? Who is interested in a certain requirement? Where in the organization is the system used? Who will support and maintain the system? What are the system's external resources? What other systems will need to interact with this one?

How to find Use cases ? Choose the system boundary Recommended procedure: Choose the system boundary Find the primary actors Find the primary actor´s goals Define a use case for each How? Ask: what are your goals?

Case Study

How to find Use cases ? Stakeholders Goals Use case Primary actor Receptionist Xxxxx Xxxxxx Xxxxxxx Head waiter xxxxxxxxx To be able to record booking To be able to cancel booking To be able to record arrival To be able to make table transfer Record Booking Cancel Booking Record Arrival Transfer table Supporting actors Tax calculator Yyyyyyyy Offstage actor Sale tax agency Zzzzzz

Basic (normal/happy)path UC1 : Record Booking Receptionist enters date of requested reservation; System displays bookings for that date; There is a suitable table available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number); System records and displays new booking. 4/22/2017 CPSC-4360-01, CPSC-5360-01, Lecture 3

Other Use Case Description Template Actor System Receptionist enters date of requested reservation; there is a suitable table available: Receptionist enters details (customer’s name, phone number, time of booking, number of covers, table number); System displays bookings for that date. System records and displays new booking. 4/22/2017 CPSC-4360-01, CPSC-5360-01, Lecture 3

Alternative path Alternative flows, if no table is available UC1 : Record Booking – No Table Available: Alternative path Receptionist enters date; System displays bookings; no table available: end of use case. 4/22/2017 CPSC-4360-01, CPSC-5360-01, Lecture 3

Detailled verbal description

Use Case - verbal description There is no standardised notation for how a use case is described, verbally The description typically includes: Use Case name (use imperative verbs! e.g . Process Sale) Purpose Actors Start conditions : What needs to be done for the use case to begin? Description of the use case steps What does the actor do ? How does the system react? Any exceptions Any variants End conditions (result) : What is the result of the use case?

Preconditions and Postconditions Example: A precondition for the use case Cash Withdrawal in the ATM machine: The customer has a personally-issued card that fits in the card reader, has been issued a PIN number, and is registered with the banking system.Balance is + A postcondition for the use case Cash Withdrawal in the ATM machine: At the end of the use case, all account and transaction logs are balanced, communication with the banking system is reinitialized and the customer has withdrawn cash and been returned his card.

Detailled Use Case Examples

Use case #1 : Add Book Primary actor : Librarian Description : Create a new book in library Pre-conditions : Library logged in. Post-condition : new book is added to the library system Basic Course: The use case begins when the librarian wants to add new books The system display the ”create book” form The librarian enters book details (ISBN nr, Title, Author, Publication year , publisher and genre) and clicks on the ”create” button.

Use case #1 : Add Book The new book is created and added to the book list steps 2 ,3 and 4 are repeated as long as the librarian wants to add more books. The system displays the list of books and the use case ends. Alternate Course A : ISBN already exists A.5 . The system asks the user to enter a valid ISBN A.6 The new book is created and added to the book list A.7 The system displays the list of books and the use case ends.

Use case #2 : Search Book Primary actor : Librarian Description : search book based on title or author Pre-conditions : Book exists in the library. Post-condition : Book is found Basic Course: The use case begins when the librarian wants to search a book The system display the ”search book” screen. The librarian enters book title/author and clicks on the ”search” button.

Use case #2 : Search Book The system search for the book and displays the list of found books , then the use case ends. Alternate Course A : No book of this title exists What to do ?

Use case #3 : register Unemployed Use case: book work-shop Primary actor : Unemployed Description : Record booking transactions and satisfy the unemployed´s interests. Precondition : no specific pre-conditions Postcondition : work-shops are allocated to the customer   Unemployed enter : www.ABC.dk Unemployed enters the period , work-shop type and click search System display a list of work-shops Unemployed click on the work-shop link to read its detail System display work-shop details Unemployed clicks “book button” Step 4, 5 and 6 are repeated as long as the unemployed wants to participate to a work-shop System display payment form Customer enter his details and his billing info and click submit. System validates billing info and display the result

What we did so far ?

Thank you for your attention! Questions? 4/22/2017 CPSC-4360-01, CPSC-5360-01, Lecture 3