Lecture 3 Uses Cases

Lecture 3 Uses Cases

Topics Topics UML Use Cases pop quiz

Readings: Chapter 3Readings: Chapter 3

January 24, 2008

CSCE 492 Software Engineering

– 2 – CSCE 492 Spring 2008

OverviewOverviewLast TimeLast Time

Corrections to slides: Added spiral model figure 492Website/Resources/SpiralModelBoehm.pdf Rational Unified Process, Extreme Programming XP Model Driven Architecture

Pragmatics UML references, Teams

Models for the process of software development Waterfall model, Spiral model, Agile,

Requirements

Today’s Lecture Today’s Lecture UML review Requirements

References: References: Chapters 3 of the text http://www.omg.org/, http://www.holub.com/goodies/uml/

Next Time: Next Time:

– 3 – CSCE 492 Spring 2008

UML – Unified Modeling LanguageUML – Unified Modeling Language

UML referencesUML references http://www.holub.com/goodies/uml/ http://www.uml.org/

Poseidon tool for UML Poseidon tool for UML http://gentleware.com/index.php

Website of Quick Reference CardsWebsite of Quick Reference Cards http://www.digilife.be/quickreferences/quickrefs.htm

– 4 – CSCE 492 Spring 2008

What's new in UML 2.0What's new in UML 2.0

Nested Classifiers: In UML 2.0, you can nest a set of Nested Classifiers: In UML 2.0, you can nest a set of classes inside the component that manages them, or classes inside the component that manages them, or embed a behavior (such as a state machine) inside embed a behavior (such as a state machine) inside the class or component that implements it.   the class or component that implements it.  

Improved Behavioral Modeling: Improved Behavioral Modeling:

Improved relationship between Structural and Improved relationship between Structural and Behavioral Models:Behavioral Models:

– 5 – CSCE 492 Spring 2008

Verifying RequirementsVerifying Requirements

A structured walkthrough with the end users is a good A structured walkthrough with the end users is a good technique for ensuring that the user needs are being technique for ensuring that the user needs are being addressedaddressed

To ensure that the resulting software supports the To ensure that the resulting software supports the requirements specification, items on the supported requirements specification, items on the supported activity list are numbered and propagated through activity list are numbered and propagated through the software models and source codethe software models and source code

– 6 – CSCE 492 Spring 2008

The Process of Requirements AnalysisThe Process of Requirements Analysis Create verified requirements specificationCreate verified requirements specification

Create list of primary classesCreate list of primary classes

Create informal scenariosCreate informal scenarios

Create use casesCreate use cases

Create scenariosCreate scenarios

Create class diagramsCreate class diagrams

Create use case diagramsCreate use case diagrams

– 7 – CSCE 492 Spring 2008

Determining Primary ClassesDetermining Primary Classes

Select nouns from the requirements Select nouns from the requirements specification and inspect each noun for the specification and inspect each noun for the following propertiesfollowing properties

Retained informationRetained information

Needed servicesNeeded services

Multiple attributesMultiple attributes

Common attributesCommon attributes

Common operationsCommon operations

Essential requirementsEssential requirements

– 8 – CSCE 492 Spring 2008

LMS Case Study:Primary ClassesLMS Case Study:Primary Classes

PatronPatron

Student, faculty, library staffStudent, faculty, library staff

ResourceResource

Book, music CD, video, softwareBook, music CD, video, software

Reference resource, reserved resource, Reference resource, reserved resource, requested resource, online research resourcerequested resource, online research resource

Inter-library loan requestInter-library loan request

Overdue chargeOverdue charge

Overdue form lettersOverdue form letters

– 9 – CSCE 492 Spring 2008

Identifying Use CasesIdentifying Use Cases

A use case is a description of a scenario (or closely A use case is a description of a scenario (or closely related set of scenarios) in which the system related set of scenarios) in which the system interacts with users of the systeminteracts with users of the system

The behavior of the system is expressed without The behavior of the system is expressed without specifying how the behavior is implementedspecifying how the behavior is implemented

Use cases are initially described as a narrative, and Use cases are initially described as a narrative, and then modeled graphically by then modeled graphically by class diagramsclass diagrams and and interaction diagramsinteraction diagrams (to be discuss later) (to be discuss later)

Informal scenarios are a good starting point for use Informal scenarios are a good starting point for use casescases

– 10 – CSCE 492 Spring 2008

Characteristics of Use CasesCharacteristics of Use Cases

Use cases are more abstract than informal Use cases are more abstract than informal scenariosscenarios

A single use case may encompass multiple A single use case may encompass multiple scenariosscenarios

Use cases avoid redundancyUse cases avoid redundancy

Use cases are more formally structured than Use cases are more formally structured than scenariosscenarios

Use cases seek to capture complete breadth of Use cases seek to capture complete breadth of system behaviorsystem behavior

– 11 – CSCE 492 Spring 2008

Use Case LayoutUse Case Layout

PreconditionPrecondition What conditions must be true at the beginning of the use

case?

Main flow of eventsMain flow of events Describe the essential behavior associated with the use

case

Post conditionPost condition What occurs as a result of the use case executing

Exceptional flow of events ( zero to many)Exceptional flow of events ( zero to many) Enumerate possible erroneous flow of events

– 12 – CSCE 492 Spring 2008

LMS Case Study: Use CasesLMS Case Study: Use Cases

Validate patronValidate patron

Check out resourceCheck out resource

Check in resourceCheck in resource

Request resourceRequest resource

Reserve resourceReserve resource

Manage ResourceManage Resource

Manage PatronManage Patron

Generate form letterGenerate form letter

– 13 – CSCE 492 Spring 2008

LMS Case Study: Check out Resource Use CaseLMS Case Study: Check out Resource Use CasePreconditionPrecondition

Library staff and patron validated to LMS Library DB initialized

Main flow of eventsMain flow of events Enter resource Determine due date

Exceptional flow of eventsExceptional flow of events Patron ID not valid Patron has over due resources or too many checked Resource number not valid

– 14 – CSCE 492 Spring 2008

More LMS Case Study: Check out Resource Use CaseMore LMS Case Study: Check out Resource Use Case

PostconditionPostcondition Patron DB entry updated to reflect new resource Resource DB entry updated to reflect changed

status: checked out Due date assigned to the resource DB entry

– 15 – CSCE 492 Spring 2008

Scenario DevelopmentScenario Development

Scenarios are derived from use casesScenarios are derived from use cases

Scenarios are like informal scenarios, but are more Scenarios are like informal scenarios, but are more formally structuredformally structured

Informal scenarios may be modified to produce Informal scenarios may be modified to produce scenariosscenarios

Use cases are abstract because they do Use cases are abstract because they do notnot reference reference specific valuesspecific values

Scenarios are concrete because they Scenarios are concrete because they do do referencereference specific valuesspecific values

Multiple scenarios may be required for a single use Multiple scenarios may be required for a single use casecase

– 16 – CSCE 492 Spring 2008

Modeling the System with UMLModeling the System with UML

The process of modeling parallels and supports The process of modeling parallels and supports the process of understanding the system the process of understanding the system requirementsrequirements

Two types of models support the analysis Two types of models support the analysis processprocess Class diagrams Use case diagrams

– 17 – CSCE 492 Spring 2008

Class DiagramsClass Diagrams

Models the composition of classes and the essential Models the composition of classes and the essential relationships between classesrelationships between classes

Models a static perspective of the systemModels a static perspective of the system

May expresses a more or less abstract representation May expresses a more or less abstract representation of the systemof the system

The notational building blocks The notational building blocks Classes Interfaces Relationships Collaborations

– 18 – CSCE 492 Spring 2008

Notational Elements of Class DiagramsNotational Elements of Class Diagrams

Class Name

Class Detailed Class Interface

Relationships:Dependency Association Generalization

Collaboration

CollaborationName

– 19 – CSCE 492 Spring 2008

LMS Case Study: Class DiagramLMS Case Study: Class Diagram

Requests

Browses

Checks out

ReturnsPatron Resource

Overdueform Letter

lists

Library staffgenerates

proce

sses

deletesad

ds

reshelv

es

– 20 – CSCE 492 Spring 2008

LMS Case Study: Class Diagram for Check out ResourceLMS Case Study: Class Diagram for Check out Resource

Resource

Software Book Music CDVideo

PatronLibrarystaff

processesChecks out

– 21 – CSCE 492 Spring 2008

Use Case DiagramsUse Case Diagrams

Use case diagrams depict use cases interacting with external Use case diagrams depict use cases interacting with external actorsactors

External actors are entities that interact with the software system, External actors are entities that interact with the software system, like system users, databases, or books like system users, databases, or books

Use cases represent system requirements and show a functional Use cases represent system requirements and show a functional partitioning of the systempartitioning of the system

Functional partitioning is useful for a dividing a system into Functional partitioning is useful for a dividing a system into smaller piecessmaller pieces

– 22 – CSCE 492 Spring 2008

Notational Elements of Use Case DiagramsNotational Elements of Use Case Diagrams

Use casename

Actor Use case

Relationships:Dependency Association Generalization

– 23 – CSCE 492 Spring 2008

LMS Case Study: Use Case DiagramLMS Case Study: Use Case Diagram

BrowseResource

RequestResource

ReserveResourcePatron Resource

– 24 – CSCE 492 Spring 2008

Steps in UCCD Analysis ProcessSteps in UCCD Analysis Process

Use Case Centered Design (UCCD) ProcessUse Case Centered Design (UCCD) Process

Create/refine requirements specificationCreate/refine requirements specification

Create informal scenarios Create informal scenarios brainstorm with stakeholders

Create list of primary classesCreate list of primary classes

Create use casesCreate use cases

Create scenarios from use casesCreate scenarios from use cases

Create class diagrams showing basic inter-class Create class diagrams showing basic inter-class relationshipsrelationships

Model key class collaborationsModel key class collaborations

Create use case diagramsCreate use case diagrams

– 25 – CSCE 492 Spring 2008

Evolving the SystemEvolving the System

Requirements analysis may be done iteratively Requirements analysis may be done iteratively throughout system developmentthroughout system development

The system to be developed may be partitioned into The system to be developed may be partitioned into development subgoalsdevelopment subgoals

Each subgoal has its own requirements analysis phase Each subgoal has its own requirements analysis phase that it followed by design, implementation, and that it followed by design, implementation, and testingtesting

Each subset of the system is made work before the Each subset of the system is made work before the next subgoal is analyzednext subgoal is analyzed

– 26 – CSCE 492 Spring 2008

Analyzing the Class ProjectAnalyzing the Class Project

List the primary classesList the primary classes

Create a basic class diagram showing aggregation and inheritanceCreate a basic class diagram showing aggregation and inheritance

Create use cases Create use cases

Create class diagrams Create class diagrams

Create use case diagramsCreate use case diagrams

Create one or more scenarios for each use caseCreate one or more scenarios for each use case

Engage in a structured walkthrough with your customerEngage in a structured walkthrough with your customer

– 27 – CSCE 492 Spring 2008

Working in TeamsWorking in Teams

Development teams should meet at least once a weekDevelopment teams should meet at least once a week

A common list of primary classes should be created by A common list of primary classes should be created by the teamthe team

The creation of use cases, class diagrams, and The creation of use cases, class diagrams, and scenarios should be divided amongst development scenarios should be divided amongst development team membersteam members

The team as a whole should review the individual The team as a whole should review the individual products to ensure that the pieces fit togetherproducts to ensure that the pieces fit together

– 28 – CSCE 492 Spring 2008

Additional Pointers for Effective Team WorkAdditional Pointers for Effective Team Work

The role of the chair is to facilitate discussionThe role of the chair is to facilitate discussion

Each team member should have equal opportunity to be heardEach team member should have equal opportunity to be heard

The meeting chair to make an extra effort to hear from less The meeting chair to make an extra effort to hear from less aggressive team membersaggressive team members

Team members should not be interrupted unless they are being Team members should not be interrupted unless they are being long-windedlong-winded

Everyone should strive to make their points as concisely as Everyone should strive to make their points as concisely as possiblepossible