Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications...

Methods: Deciding What to DesignMethods: Deciding What to Design

In-Young Koiko .AT. icu.ac.kr

Information and Communications University (ICU)

Fall 2005Fall 2005ICE0575ICE0575

Lecture #2Lecture #2

Use Case Modeling IUse Case Modeling I

Fall 2005 2 ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University

AnnouncementsAnnouncements

Project Teams?Project Teams? Please start working on the EVRsPlease start working on the EVRs

TTA TTA “Plans and Situated Actions” “Plans and Situated Actions” Posdata Posdata “Making Use” “Making Use” Hyundai Hyundai “I Sing the Body Electronic” “I Sing the Body Electronic”


Picture of the Day: Picture of the Day: The SEI BuildingThe SEI Building


ContextContext

Client RequirementsClient Requirements

Software DesignSoftware Design

Here aMiracle

Happens

Here aMiracle

Happens

Technical rqts

Technical rqts Architecture

Architecture

Biz, polic

, reg

Biz, polic

, reg

Usability

Usability

EngineeringEngineering

The content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.


Requirements AnalysisRequirements Analysis

Client RequirementsClient Requirements

Here aMiracle

Happens

Here aMiracle

Happens

Tech

nic

al rq

tsTech

nic

al rq

ts



Challenges & EvidencesChallenges & Evidences In 1994, In 1994, $250 billion$250 billion in US in IT application in US in IT application

development; corresponds to development; corresponds to 175,000 projects175,000 projects 31% of projects are cancelled = $81 billion31% of projects are cancelled = $81 billion 52.7% with 187% cost overrun = $59 billion52.7% with 187% cost overrun = $59 billion 16 % are on time in 199416 % are on time in 1994 In 2003, 34 % are on time, a big improvementIn 2003, 34 % are on time, a big improvement

Challenged projects (most commonly cited): Challenged projects (most commonly cited): Lack of user inputLack of user input (13%) (13%) Incomplete requirementsIncomplete requirements (12%) (12%) Changing requirementsChanging requirements (12%) (12%) Lack of technical skill (7%)Lack of technical skill (7%) Lack of resource (6%)Lack of resource (6%) Inadequate time (4%)Inadequate time (4%)

[Standish Group International, 1994 and 2003 Surveys]

1/21/2


Largest software development problems by categoryLargest software development problems by categoryESPITI [1995 in Leffingwell andESPITI [1995 in Leffingwell and WidrigWidrig., ., 2000. Managing Software Requirements, p. 6-7]2000. Managing Software Requirements, p. 6-7]

Challenges & EvidencesChallenges & Evidences

0

5

10

15

20

25

30

35

40

45

50

Req. Spec. Documentation Project Man

Major problem

Minor problem

Never a problem

Req. Spec Manag. Reqs Docmt. Testing Project Man. Coding

2/22/2


Plan for This UnitPlan for This Unit 09/02 : Fundamentals09/02 : Fundamentals

Scoping the problem through use casesScoping the problem through use cases 09/06 : Structuring a well use case model09/06 : Structuring a well use case model 09/09 : 09/09 : External viewpoints reportsExternal viewpoints reports on understanding on understanding

client’s needsclient’s needs Make a 15 minute presentationMake a 15 minute presentation Send an Send an abstract descriptionabstract description of the main idea by 09/06 of the main idea by 09/06

Suchman: Plans and Situated Accidents Suchman: Plans and Situated Accidents TTA TTA Carroll: Making Use Carroll: Making Use Posdata Posdata Moody: I Sing the Body Electronic Moody: I Sing the Body Electronic Hyundai Hyundai

09/16 : 09/16 : Project presentationsProject presentations of technical requirements of of technical requirements of the studio projects through use casesthe studio projects through use cases



Today’s PlanToday’s Plan

Requirement elicitation techniquesRequirement elicitation techniques Use case modeling as a requirement elicitation Use case modeling as a requirement elicitation

techniquetechnique Process centered versus problem centered Process centered versus problem centered

use case modelinguse case modeling FundamentalsFundamentals

Stakeholders, users, actorsStakeholders, users, actors Use casesUse cases Structuring use cases, relationshipsStructuring use cases, relationships ScenariosScenarios


Fall 2005 10

ICE 0575 – Methods: Deciding What to Design © In-Young Ko, Information and Communications University

OverviewOverview

Use case modeling is a technique for Use case modeling is a technique for requirement elicitationrequirement elicitation Facilitates early brainstorming of Facilitates early brainstorming of

functional requirementsfunctional requirements Can serve as a powerful tool for Can serve as a powerful tool for inter team inter team

and client communicationand client communication Helps Helps bridge business and domain specific bridge business and domain specific

concernsconcerns with software design requirements with software design requirements Provides mechanisms for Provides mechanisms for problem scopingproblem scoping


Fall 2005 11


No Silver BulletNo Silver Bullet

There is no method suitable for all There is no method suitable for all problemsproblems

There may be alternative ways to apply There may be alternative ways to apply one method one method in different contextsin different contexts

ResourcesResources will affect the method of will affect the method of choice choice

Good toolsGood tools may become handy at even may become handy at even unexpected circumstancesunexpected circumstances


Fall 2005 12


Requirement Elicitation TechniquesRequirement Elicitation Techniques


Ethnographic Observation and Protocol Analysis Ethnographic Observation and Protocol Analysis InterviewInterview Requirement WorkshopRequirement Workshop BrainstormingBrainstorming StoryboardingStoryboarding Use CasesUse Cases Role PlayingRole Playing PrototypingPrototyping Task AnalysisTask Analysis Contextual DesignContextual Design

Fall 2005 13


Use Case Modeling as a Use Case Modeling as a Requirement Elicitation TechniqueRequirement Elicitation Technique

ProsPros Mechanisms to Mechanisms to separate business context separate business context

from system contextfrom system context A use case model can serve as a problem A use case model can serve as a problem

scoping scoping communication mediumcommunication medium between the between the client and the developersclient and the developers

ConsCons Tempts direct transformation of use cases to Tempts direct transformation of use cases to

user interfaces, function calls, user interfaces, function calls, and object decompositions of the systemand object decompositions of the system


Fall 2005 14


Process vs. ProblemProcess vs. Problem

First there were First there were use casesuse cases (Jacobsen (Jacobsen early 1990s)early 1990s)

Then there was Rational Approach which Then there was Rational Approach which combined with OOSE to form combined with OOSE to form Rational Rational ObjectoryObjectory (1996)…. (1996)….

Then there was use case driven, Then there was use case driven, architecture centric, iterative and architecture centric, iterative and incremental incremental Rational Unified ProcessRational Unified Process


1/21/2

Fall 2005 15


Process vs. ProblemProcess vs. Problem

Use cases are very often used within Use cases are very often used within unified process driven software unified process driven software development managementdevelopment management

Use cases are invented in the context of Use cases are invented in the context of object-oriented methodologyobject-oriented methodology and and UMLUML

Yet, they are also very widely utilized as a Yet, they are also very widely utilized as a design tool isolated from the unified design tool isolated from the unified process driven approachesprocess driven approaches


2/22/2

Fall 2005 16


The Relationships Between The Relationships Between Stakeholders and Actors/Use CasesStakeholders and Actors/Use Cases

http://www.awprofessional.com/articles/article.asp?p=30162&rl=1

Fall 2005 17


StakeholdersStakeholders A stakeholder is someone who A stakeholder is someone who gets a benefitgets a benefit

from the outcome of software developmentfrom the outcome of software development

Identifying the stakeholders correctly helps Identifying the stakeholders correctly helps in in scoping the problemscoping the problem Asking the questions to the right peopleAsking the questions to the right people Negotiating the business case and requirements with Negotiating the business case and requirements with

the decision makersthe decision makers Different stakeholders will bring different constraints Different stakeholders will bring different constraints

which often times may contradict: financial, technical, which often times may contradict: financial, technical, long-term impact, privacy… long-term impact, privacy…


1/21/2

Fall 2005 18


StakeholdersStakeholders

UsersUsers have an added special impact as a have an added special impact as a stakeholder, we design for the usersstakeholder, we design for the users They They directly interactdirectly interact with the outcome with the outcome They may or may not be aware of (not to They may or may not be aware of (not to

mention careless) mention careless) other constraintsother constraints, e.g. time , e.g. time to shipto ship


2/22/2

Fall 2005 19


ActorsActors ActorsActors: an entity that interacts with the system: an entity that interacts with the system

The stakeholders that interact with the system influence how it The stakeholders that interact with the system influence how it may be designed may be designed

Software development is seldom from scratch, often there are Software development is seldom from scratch, often there are multiple interacting componentsmultiple interacting components where the new application is where the new application is the member of a larger collaborative scenario of multiple the member of a larger collaborative scenario of multiple applicationsapplications

Defining the actors helps define the Defining the actors helps define the boundaries of the boundaries of the systemsystem

Actors that interact with the system are Actors that interact with the system are rolesroles, i.e. , i.e. generally defined designationsgenerally defined designations, not specific people or , not specific people or instancesinstances


1/41/4

Fall 2005 20


ActorsActors

Who interacts with the system in what way may Who interacts with the system in what way may not always be easy to distinguishnot always be easy to distinguish Business use case modelingBusiness use case modeling

business actorsbusiness actors and and business use casesbusiness use cases Helps resolve conflicts later on as more constraints and Helps resolve conflicts later on as more constraints and

requirements start building uprequirements start building up Aids in separating business goals from system goalsAids in separating business goals from system goals

System use case modelingSystem use case modeling system actorssystem actors and and system use casessystem use cases

What we are eventually interested inWhat we are eventually interested in Focus is directly on the system to be builtFocus is directly on the system to be built


2/42/4

Fall 2005 21


ActorsActors Personality TypesPersonality Types: what is the relationship of : what is the relationship of

each actor to the overall systemeach actor to the overall system InitiatorInitiator External ServerExternal Server ReceiverReceiver Facilitator (Proxy)Facilitator (Proxy)

Abstract and Concrete ActorsAbstract and Concrete Actors As a rule of thumb As a rule of thumb any actor who does any actor who does not have a not have a

direct relationship with a use casedirect relationship with a use case is an abstract actor is an abstract actor The benefit of such categorizations is in The benefit of such categorizations is in structuring the structuring the

stakeholders domainstakeholders domain and fine-tuning the roles and and fine-tuning the roles and responsibilitiesresponsibilities


3/43/4

Fall 2005 22


ActorsActors

Identifying the stakeholdersIdentifying the stakeholders narrows down the narrows down the problem scope one stepproblem scope one step

Identifying the actorsIdentifying the actors narrows down the narrows down the problem scope even further and focuses on the problem scope even further and focuses on the technical aspectstechnical aspects of the problem of the problem Focus on how the system will be usedFocus on how the system will be used


4/44/4

Fall 2005 23


Defining the System BoundaryDefining the System Boundary

Studio projects are defined by multiple possible pathsStudio projects are defined by multiple possible paths

System actors are not always as obvious System actors are not always as obvious

Their role in the system may change depending on Their role in the system may change depending on how the problem is scopedhow the problem is scoped

Possible Human ActorPossible Human Actor Possible System ActorPossible System Actor

TTATTA Software TestersSoftware Testers Test Scenario GeneratorTest Scenario Generator

PosdataPosdata Car DriversCar Drivers Automobile Information Automobile Information SystemSystem

HyundaiHyundai Car DriversCar Drivers Automobile Multimedia Automobile Multimedia UnitUnit


Fall 2005 24


Use CasesUse Cases

A use case is a story about some A use case is a story about some way of usingway of using a system to do something usefula system to do something useful Describe Describe what the system doeswhat the system does at a conceptual levelat a conceptual level

A use case is A use case is goal orientedgoal oriented Not necessarily functionality oriented, but Not necessarily functionality oriented, but

functionality covers a lot of the use casesfunctionality covers a lot of the use cases A use case outlines a A use case outlines a single goalsingle goal and all the and all the possible possible

things that can happenthings that can happen as the users tries to as the users tries to reach that goalreach that goal

Use cases are Use cases are not simply menu items or functionsnot simply menu items or functions


Fall 2005 25


Why Use Cases?Why Use Cases?

Elicit Elicit functional requirementsfunctional requirements with a with a focus on focus on the userthe user ““abuse” and “use-less” casesabuse” and “use-less” cases All the possible ways of using the systemAll the possible ways of using the system

Form a Form a conceptual modelconceptual model of the system of the system Bind analysis, design and testsBind analysis, design and tests Introduce traceabilityIntroduce traceability Devise architectureDevise architecture Aid creating user manualAid creating user manual


Fall 2005 26


Functional DecompositionFunctional Decomposition Example: Example: Order processing systemOrder processing system

The user perspective The user perspective place orderplace order All the above are All the above are alternative flowsalternative flows of the place order of the place order

use caseuse caseThe content of this slide is adopted from the lecture materials of the Methods course (17-652) at Carnegie Mellon University.

Customer

Delete Order

Change Order

Add Order Approve Order

Order Quantity

1/31/3

Fall 2005 27


Functional DecompositionFunctional Decomposition

Cockburn view [Cockburn 2001]Cockburn view [Cockburn 2001] In principle they are separate if we take a In principle they are separate if we take a

goal centered approachgoal centered approach They may be carried out by They may be carried out by differentdifferent actors with actors with

differentdifferent requirements requirements Each represents a separate goalEach represents a separate goal

Initial requirement elicitationInitial requirement elicitation activities call for activities call for the bigger goalthe bigger goal

There is no general consensusThere is no general consensus


2/32/3

Fall 2005 28


Functional DecompositionFunctional Decomposition

Decomposing the system into Decomposing the system into small, isolated small, isolated chunks of behaviorchunks of behavior is the most appealing is the most appealing At first it seems easier to attack problems as small At first it seems easier to attack problems as small

bits of behaviorbits of behavior The focus of use case modeling should be on The focus of use case modeling should be on what what

the system doesthe system does How the use cases fit togetherHow the use cases fit together should be apparent should be apparent

The user should not need to reassemble the The user should not need to reassemble the value the system is to bringvalue the system is to bring

List of features do not map one to one with use List of features do not map one to one with use casescases


3/33/3

Fall 2005 29


Use Case ModelingUse Case Modeling Use case modelUse case model is the is the collection of diagramscollection of diagrams, ,

descriptions needed to represent the use cases descriptions needed to represent the use cases and actorsand actors

Use case modeling processUse case modeling process Defines the Defines the system boundarysystem boundary Finds the Finds the actorsactors Finds the Finds the use casesuse cases DescribesDescribes each use case each use case RefactorsRefactors the use case model the use case model PrioritizesPrioritizes use cases use cases AddAdds future requirements (s future requirements (change caseschange cases)) OrganizesOrganizes the use case model ( the use case model (packagespackages))


Fall 2005 30


Describing a Use CaseDescribing a Use Case Tedious to do all, but is worth spending time Tedious to do all, but is worth spending time in in

early onearly on as a requirement elicitation tool as a requirement elicitation tool The The templatestemplates give guidance for the thinking give guidance for the thinking

processprocess Which Which actor(s)actor(s), use cases initiate the use case, use cases initiate the use case What are the What are the preconditionspreconditions of the use case of the use case How does the use case proceed, i.e. what are the How does the use case proceed, i.e. what are the

flow of eventsflow of events What happens once the use case is over, what are What happens once the use case is over, what are

the the post conditionspost conditions What are the What are the alternative sequences of events alternative sequences of events

(exceptions)(exceptions), what are the , what are the decision pointsdecision points that may that may lead the user into alternative pathslead the user into alternative paths


1/21/2

Fall 2005 31


Describing a Use CaseDescribing a Use Case

Name:Actors:

Description:

Name:Actors:

Description:

Initial use case descriptions

Name:Actors:

Description:Sequence of Events:

Preconditions:Postconditions:

Assumptions:

Name:Actors:



Assumptions:

Base use case descriptions


2/22/2

Broad descriptions of system behaviors initiated by actors

Name:Actors:



Assumptions:

Name:Actors:



Assumptions:

Elaborated use case descriptions

Detail descriptions of behaviors including condition logic and alternative flows

Fall 2005 32


Use case Diagram – The UML Use case Diagram – The UML ContextContext

Concrete ActorsGeneralization

Relationship

Use Cases

Unidirectional Association

Abstract Actor

Student

Full time student

Register

Part time student

Enroll evening classes


1/31/3

Fall 2005 33


Use case Diagram – The UML ContextUse case Diagram – The UML Context

Relationships• Communication • Generalization• Includes or uses• Extends

[Booch, Rumbaugh, Jacobsen (1999)The Unified Modeling Language Guide]

communication

generalization

Validate User

Check Password

Retinal Scan

Place Rush OrderPlace Order

set priority

<<extend>>

<<include>>Customer

Track Order

<<include>>


2/32/3

Fall 2005 34


Use case Diagram – The UML ContextUse case Diagram – The UML Context

CommunicationCommunication The only relationship permissible between actors and use-The only relationship permissible between actors and use-

casescases GeneralizationGeneralization

Similar to parent/child relationshipSimilar to parent/child relationship The specific elements share structure and behavior with the The specific elements share structure and behavior with the

general elementgeneral element Includes/UsesIncludes/Uses

Used when a base use-case instance includes the behavior Used when a base use-case instance includes the behavior specified by another use-casespecified by another use-case

Models Models common behaviorcommon behavior among use-cases among use-cases ExtendsExtends

Used when one use-case Used when one use-case adds functionalityadds functionality onto another use onto another use case case

Extending use-case continues the activity of the starting Extending use-case continues the activity of the starting base use-casebase use-case


3/33/3

Fall 2005 35


ScenariosScenarios

Use cases describe Use cases describe abstract and general abstract and general behaviorbehavior

Use cases do Use cases do not describe what happensnot describe what happens when when a specific actor performs a specific action with a specific actor performs a specific action with specific valuesspecific values

Scenarios: specific executions Scenarios: specific executions also denoted also denoted as as use case instancesuse case instances Variations of input and output parametersVariations of input and output parameters Variations on flow of eventsVariations on flow of events


1/21/2

Fall 2005 36


ScenariosScenarios Scenarios carry use cases to a larger requirement Scenarios carry use cases to a larger requirement

elicitation contextelicitation context Validate requirementsValidate requirements Identify any unaddressed Identify any unaddressed nonfunctional requirementsnonfunctional requirements

Performance and usability commonlyPerformance and usability commonly Create a broader system prototypeCreate a broader system prototype Flow nicely into Flow nicely into test casestest cases Success and failure scenarios (Success and failure scenarios (primaryprimary and and secondarysecondary use use

cases)cases)

Scenarios can be used to Scenarios can be used to structure use casesstructure use cases Bottom up approachBottom up approach

Using scenarios Using scenarios ensures that the use case covers all of ensures that the use case covers all of the possible attemptsthe possible attempts to reach a goal to reach a goal


2/22/2

Fall 2005 37


Benefits of Use Case Modeling to Benefits of Use Case Modeling to StakeholdersStakeholders

CustomersCustomers

customer requirements, system scope, schedule & customer requirements, system scope, schedule & budget, acceptance criteriabudget, acceptance criteria

UsersUsers

user requirements, user interactionsuser requirements, user interactions

Project ManagersProject Managers

schedule & budget, feasibility & risk analysis, schedule & budget, feasibility & risk analysis, tracking development progresstracking development progress

1/21/2

Fall 2005 38


Benefits of Use Case Modeling to Benefits of Use Case Modeling to StakeholdersStakeholders

System ArchitectsSystem Architects

architectural requirements, technology selectionarchitectural requirements, technology selection

System DevelopersSystem Developers

design requirements, system documentationdesign requirements, system documentation

System MaintainersSystem Maintainers

guidance for system modification and evolutionguidance for system modification and evolution

Make the stakeholders be involved early Make the stakeholders be involved early in the system development effort!in the system development effort!

2/22/2

Fall 2005 39


Questions??Questions??

Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications...

Documents

Transcript of Methods: Deciding What to Design In-Young Ko iko.AT. icu.ac.kr Information and Communications...