TK2023 Object-Oriented Software Engineering

Slides:



Advertisements
Similar presentations
Object-Oriented Analysis and Design Evolutionary Requirements.
Advertisements

10 Software Engineering Foundations of Computer Science ã Cengage Learning.
Actors and use cases Use-case diagram Brief notation Prioritization Fully dressed notation Requirements Functional requirements  Use-cases.
Writing Use Cases: Requirements in Context
Use cases.
Object-Oriented Analysis and Design
CS3773 Software Engineering Lecture 03 UML Use Cases.
January Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box.
Jan Ron McFadyen1 Use Cases in the UML Functionality under consideration is represented by use cases (named ellipses) enclosed in a box Actors.
Design analysis implementation testing maintenance Waterfall Development Process Linear one phase is completed before the next begins in practice, must.
COMP 350: Object Oriented Analysis and Design Lecture 3 Case Studies, Inception & Use Cases References: Craig Larman Chapters 3-6.
January Ron McFadyen1 Ch 9. Use-case model: drawing System Sequence Diagrams Elaboration Iteration 1: a simple cash-only success scenario of.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” - may be of.
Fall 2009ACS-3913 Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
Use Cases & Requirements Analysis By: Mostafa Elbarbary.
Understanding Requirements
Object Oriented Analysis Process
Copyright ©2004 Cezary Z Janikow 1 Use Cases n Within Requirements discipline/workflow n Verbal descriptions of important functional (behavioral, transactional,
1 Lecture 1: Processes, Requirements, and Use Cases.
Jan 8, Ron McFadyen1 Waterfall Spiral UP Case study UML Use Cases.
Object-Oriented Analysis and Design
Marcelo Santos – OOAD-CDT309, Spring 2008, IDE-MdH 1 Object-Oriented Analysis and Design - CDT309 Period 4, Spring 2008 More on use cases System sequence.
Marcelo Santos – OOAD-CDT309, Spring 2008, IDE-MdH Object-Oriented Analysis and Design - CDT309 Period 4, Spring 2008 Use cases: deciding what you want.
The first step in getting what you want is to decide what you want.
TK2023 Object-Oriented Software Engineering CHAPTER 6 SYSTEM SEQUENCE DIAGRAMS.
Object-Oriented Analysis and Design
Requirements Elicitation. Requirement: a feature or constraint that the system must satisfy Requirements Elicitation: specification of the system that.
Object-Oriented Analysis - Instructor Notes
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
Rational Unified Process (Part 1) CS3300 Fall 2015.
Requirements Functional requirements  Use-cases
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
4 2009/10 Object Oriented Technology 1 Topic 4: The Object-Oriented Approach to Requirements Adopted from: Ch.7 The Object-Oriented Approach to Requirements.
Chapter 6 Use Cases. Use Cases: –Text stories Some “actor” using system to achieve a goal –Used to discover and record requirements –Serve as input to.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Writing Use Cases: Requirements in Context.
SOFTWARE DESIGN AND ARCHITECTURE LECTURE 20. Review Software Requirements Requirements Engineering Process.
USE CASE Bayu Adhi Tama, MTI Faculty of Computer Science, University of Sriwijaya Slides are adapted from Petrus Mursanto
Object-Oriented Analysis and Design Jan 14, 2009.
Requirements Analysis via Use Cases SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
Chapter 7 Applying UML and Patterns Craig Larman
 Development is organized in a series of short, fixed-length mini-projects called iterations  Iterations are also incremental  Successive enlargement.
OOSE Use Case. Requirement Functional: –Features, capabilities, and security Non Functional: –Usability: Human factors, help, and documentation –Reliability:
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
Chapter 9 Applying UML and Patterns -Craig Larman
1 Object-Oriented Modeling Using UML CS 3331 Section 2.4 Modeling Requirements with Use Cases.
Goals and Scope of a Use Case
Systems Analysis and Design in a Changing World, 6th Edition
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Chapter 1 Applying UML and Patterns. The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary.
OO Methodology Inception Phase.
Chapter 5 Evolutionary Requirements. Introduction 5.1 Definition: Requirements 5.2 Evolutionary vs. Waterfall Requirements 5.3 What are Skillful Means.
Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Software Engineering 1 Object-oriented Analysis and Design Chap 24 Iteration 2 More Patterns.
CS212: Object Oriented Analysis and Design Lecture 32: Use case and Class diagrams.
Sept Ron McFadyen1 Use Cases Introduced by Ivar Jacobson in 1986 literal translation from Swedish ”usage case” Used to capture and describe.
1 What is the Software Life Cycle? The stages of developing a software application Requirements Analysis High-level Design Plan Low-level Design Implementation.
PRESENTATION ON USE CASE. Use Case Modeling Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is.
Chapter 6: Use Cases.
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Writing Use Cases: Requirements in Context.
Understanding Requirements
Larman chapter 61 Use cases Larman chapter 6. 2 Fig. 6.1.
Requirements capture: Using UML Use Cases David Millard and Yvonne Howard {dem,
Jan Ron McFadyen1 Use Cases Used to capture functional requirements – there are other requirements categories such as usability, reliability,
Elaboration popo.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Evolutionary requirements
Use Case Modeling.
Software Requirements
Other System Requirements
Use cases Dr. X.
Presentation transcript:

TK2023 Object-Oriented Software Engineering CHAPTER 4 REQUIREMENTS AND USE CASES

REQUIREMENTS Requirements are capabilities and conditions to which the system must conform. A prime challenge of requirements work is to find, communicate, and remember (record) what is really needed, in a form that can be understood by the client and development team members. UP promotes a systematic approach to finding, documenting, organizing, and tracking the changing requirements of a system.

THE REQUIREMENTS DISCIPLINE IN UP Sample UP Disciplines Business Modeling Requirements Requirements Design Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations

TYPES OF REQUIREMENTS UP categorizes requirements according to the FURPS+ model: Functional - features, capabilities, securities Usability - human factors, help, documentation Reliability - frequency of failure, recoverability, predictability Performance - response times, throughput, accuracy, availability, resource usage Supportability - adaptability, maintainability, internationalization, configurability

Ancillary and sub-factors, such as Implementation - resource limitations, languages and tools, hardware, … Interface - constraints imposed by interfacing with external systems Operations - system management in its operational setting Packaging Legal - licensing, etc Requirements are sometimes broadly categorized as functional (behavioural) and non-functional (everything else).

INTRODUCTION TO USE CASES Customers and end users have goals and want computer systems to help meet them. Informally, use cases are stories of using a system to meet goals. Example (brief format): Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line-item details. The cashier enters payment information, which the system validates and records. The system updates inventory. The system produces a receipt. The customer receives the receipt from the cashier and then leaves with the items.

The essence of use cases is the discovering and recording of functional requirements through writing stories of using a system to help fulfill various stakeholder goals. The idea of use cases to describe functional requirements was introduced by Ivar Jacobson in 1986.

ACTOR An actor is an external entity which interacts with the SuD (System under Discussion) to achieve a desired goal. It can be a person (identified by its role), computer system or organization. Actors are basically users of the SuD. For example, cashier.

SCENARIO A scenario is a specific sequence of actions and interactions between actors and the SuD. It is also called a user story or a use case instance. Example, Use case: Process Sale Possible scenarios: Successfully purchasing items with cash Failure to purchase items because credit card is rejected by the system.

In other words, a use case is a collection of related success and failure scenarios that describe actors using a system to support a goal.

ANOTHER EXAMPLE (CASUAL FORMAT) Handle Returns Main Success Scenario: A customer arrives at a checkout with items to return. The cashier uses the POS system to record each returned item … Alternate Scenarios: If the credit authorization is rejected, inform the customer and ask for an alternate payment method.

If the item identifier is not found in the system, notify the Cashier and suggest manual entry of the identifier code. If the system detects failure to communicate with the external tax calculator system, … …

ANOTHER FORMAT (TWO-COLUMN FORMAT) Process Sale Main Success Scenario: Actor Action (or Intention) System Responsibility Customer arrives at a POS checkout with goods Cashier starts a new sale Cashier enters item identifier Cashier repeats 3-4 until indicates done Cashier tells Customer the total, and asks for payment. Customer pays Records each sale line item and presents item description and running total. System presents total with taxes calculated Handles payment

BLACK-BOX USE CASES Black-box use cases are use cases that do not describe the internal workings of the SuD, its components or design. They specify what the SuD must do (the functional requirements) without deciding how it will do it (the design). Black-box use cases should be written during requirements analysis. Black-box style Not The system records the sale. The system writes the sale to a database. … The system generates an SQL INSERT statement for the sale …

USE CASE FORMATS The format used for writing a use case depends on the current need. brief Terse one-paragraph summary, usually of the main success scenario. casual Informal paragraph format. Multiple paragraphs that cover various scenarios. fully dressed The most elaborate format. All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees. EXAMPLE

GOAL LEVELS Use cases can be expressed at different levels, depending on the system boundary, actors and goals. Generally, there are 3 goal levels: Summary Level User Level Subfunction Level

SUMMARY GOAL LEVEL Example (Handle a Claim): 1. Customer reports a claim (paper, phone or fax) to Clerk. 2. Clerk finds the policy, registers loss in System, and assigns an Adjuster. 3. Adjuster investigates the claim and updates the claim with additional information. 4. Adjuster enters progress notes over time. 5. Adjuster corrects entries and sets monies aside over time. …

USER GOAL LEVEL Example: The manager requests for a hardcopy of a certain report from his personal assistant. The personal assistant turns to his computer to accomplish a goal i.e. to print the document. He works with the computer for a while and finally accomplishes the goal. He then passes the hardcopy to the manager.

SUBFUNCTION LEVEL Subfunction-level goals are normally referred to by user-level goals. Examples: Open a file Find a product Find a customer Log into system

USER GOAL-LEVEL USE CASES Actors have goals (or needs) and use computer applications to help satisfy them. A user goal-level use case is one that serves to fulfill a goal of a user of the SuD. When identifying such use cases, one should first ask Example: Goal: capture or process a sale Use case: process sale What are the goals of the primary actors?

Some guidelines in identifying user goal-level use cases: A use case should yield an observable result of value to a particular actor (refer Boss Test). Is “Log In” a use case at the user goal level? The use case should not be just a single small step. The main success scenario is probably 5 to 10 steps. The use case can be executed in a single session (probably between a few minutes to an hour). It should not take days and multiple sessions.

USE CASE EXAMPLE: ATM Some user goal-level use cases: Start Up ATM Shut Down ATM Deposit Fund Withdraw Fund Transfer Fund Check Account Balance

PROCEDURE FOR DEFINING USE CASES The basic procedure: Choose the system boundary Identify the primary actors Identify user goals Define the use cases

STEP 1: CHOOSE SYSTEM BOUNDARY Can be done by determining what is outside the boundary of the SuD i.e what are the primary and supporting actors? Primary actors have user goals fulfilled through using the SuD. Supporting actors provide services to the SuD. For the case study, the POS system itself is the SuD. Cashiers, payment authorization service, inventory control system, etc are outside the system boundary.

STEPS 2 & 3: IDENTIFY PRIMARY ACTORS AND GOALS There are three types of actors: Primary actor has user goals fulfilled through services of the SuD Example: cashier Supporting actor provides a service to the SuD Example: printer subsystem Offstage actor has an interest in the behaviour of the use case but is not primary or supporting Example: customer

Note that the SuD itself is an actor (when it calls upon the services of other systems). Recall that primary actors can be other than persons.

Record the primary actors and their user goals in an actor-goal list Record the primary actors and their user goals in an actor-goal list. For example, Actors Goals Cashier Process sale Process rentals Process returns … System Administrator Add users Modify users

Questions that can help in brainstorming actors and goals: Who starts and stops the system? Who does user and security management? Who does system administration? Is there a monitoring process that restarts the system if it fails? Who evaluates system activity or performance? … (refer textbook p 83)

The identification of primary actors and user goals depends on the system boundary. Why is Customer not the primary actor in the use case Process Sale? Customer Goal: Buy items Sales Tax Agency Collect taxes on sales Enterprise Selling Things Checkout Service Sales Activity System Cashier POS System Goal: Analyze sales and performance data Goal: Process sales

STEP 4: DEFINE USE CASES In general, define one use case for each user goal. A common exception is to combine CRUD (Create, Retrieve, Update, Delete) separate goals into one CRUD use case (Manage <X>). Example: Define “Manage Users” use case to satisfy the goals “create user”, “delete user”, “edit user”, etc.

Name the use case similar to the user goal Name the use case similar to the user goal. Make sure use case names start with a verb. Examples: Process Sale, Handle Returns, Start System

USE CASE LEVEL FOR REQUIREMENTS ANALYSIS What is a useful level to express use cases for application requirements analysis? For requirements analysis for a computer application, focus on use cases at the user goal level.

WRITING USE CASES Use cases written at the start of development are always imperfect and incomplete. Writing use cases is not a “waterfall” process. There needs to be an ongoing personal communication between the developers and those who understand the domain (domain experts) and can make requirement decisions.

Use cases are said to be written in an essential style if the narrative is expressed at the level of user's intentions and system's responsibilities rather than their concrete actions. Compare the following actor's action 2. Cashier enters ID and password with 2. Cashier identifies self

Use cases written in an essential style are free of technology and mechanism details, especially those related to the UI (User Interface). They focus on the real user intent. If user interface decisions are embedded in the text of a use case then that use case is said to be written in a concrete style.

Example (Concrete form/Not in essential form): … 1. Administrator enters ID and password in dialog box (see Picture 3). 2. System authenticates Administrator 3. System displays the “edit users” window (see Picture 4).

Example (Written in essential/abstract form): … 1. Administrator identifies self 2. System authenticates identity

Use cases written in a concrete style are useful later in design work. Use cases should be written in an essential style during early requirements work. Why? Use cases written in a concrete style are useful later in design work.

USE CASE DIAGRAMS The UML provides a notation called the use case diagram to illustrate use cases, actors and the relationships between them. NextGen POS Manage Users . . . Cashier System Administrator actor use case communication system boundary Payment Authorization Service «actor» Tax Calculator Accounting alternate notation for a computer system actor HR System Cash In Sales Activity Manage Security Analyze Activity Customer Manager Process Sale Handle Returns

REMEMBER THIS… A use case diagram makes a good context diagram. It is a communication tool that summarizes the behaviour of a system and its actors. Use case diagrams and use case relationships are secondary in use case work. Focus on writing use cases.

Actors can be represented using the following notation or as below stereotype

Actors are associated with use cases by solid lines. It is optional to put an arrowhead at the end of the line to indicate the direction of the initial invocation or to indicate the primary actor in the use case.

USE CASES ARE NOT OBJECT-ORIENTED It needs to be understood that there is nothing object-oriented about use cases. They are a requirements analysis tool that can also be applied to non-object-oriented projects.

USE CASES WITHIN THE UP Use cases are very important in the UP. In fact, UP encourages use-case driven development. Requirements are primarily recorded in use cases; other requirement techniques are secondary. Use cases play an important role in iterative planning. Use-case realizations drive the design. Use cases often influence the organization of user manuals.

USE CASES IN THE INCEPTION PHASE User goal-level use cases are identified in this phase. Most of the interesting, complex or risky use cases are written in brief format. Through this exercise, the team should have a high-level picture of the system's functionalities. 10% to 20% of the use cases that represent core complex functions or risky ones are rewritten in fully dressed format. This is done to better comprehend the magnitude and complexities of the project. inc. elaboration construction transition

USE CASES IN THE ELABORATION PHASE In the elaboration phase, risky, high-value, and architecturally significant parts of the system are incrementally built. Also, majority of the requirements are identified and clarified in this phase. Use cases are prioritized and each iteration focuses on a subset of the most important ones. inc. elaboration construction transition

The team's understanding of the requirements increases after each iteration through feedback from previous iterations. Requirements are iteratively and adaptively refined and becomes stable gradually. More and more use cases are written, and rewritten, in fully dressed format. By the end of the elaboration phase, 80% - 90% of the use cases should have been written in detail.

USE CASES IN THE CONSTRUCTION PHASE The construction phase focuses on completing the system, once the risky and core unstable issues have settled down in elaboration. There will be some minor use case writing but much less so than in the elaboration phase. Majority of core functional and non-functional requirements should have iteratively and adaptively stabilized. inc. elaboration construction transition

YOUR FIRST ASSIGNMENT Suppose you are involved in a project to develop an online cinema reservation system. Identify three user goal-level use cases. Draw a use case diagram showing those use cases and the actors involved. Determine which of those use cases you think is the most complex one and do the following tasks: Write the use case in the casual format with at least two alternate paths. Write a happy path for that use case in the two-column format. Write one success scenario and one failure scenario for that use case. The use cases you write must be black-box use cases and written in essential style. Your handwritten assignment must be submitted by 10:00 am, 1 February 2010 (Monday).