Body

Topics -- Use Cases, Iterative Development, Conceptual Model

Use Case	A textual description of user interaction with a system process Use cases provide value to an actor Use cases are complete
Scenario	A specific instance of a use case
Actor	External agent that interacts with the system
Requirements specification	Document describing the functions & attributes of a software system

Answer these important questions

1) Who are the users of the system and what are they trying to do?

2) What are the "real world" objects in the problem domain and
what are the relevant associations among them?

3) What objects are needed for each use case?

4) How do the objects work together to complete each use case goal?

Three significant features of an Object Oriented Analysis & Design Approach

1) Iterative and incremental. Multiple iterations of analysis and development.

2) High degree of trace-ability -- Always refer back to requirements (user needs)

3) Streamlined usage of the UML -- minimalist approach .

Problem analysis -- Brainstorming

for

understanding the problem,
identifying constraints,
expanding the information available
until there is a relatively complete understanding of the problem.

Difficulties during problem analysis

organizing the plethora of information

Use Cases can help

decide and describe the functional requirements of the system
bring agreement between the customer and software developer
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.
trace the functional requirements into actual classes and operations in the system.

Methods of identifying Use Cases

Source	Activity
Documents	Review requirement specifications
Domain Experts	Interview Experts
Actors	Identify the processes they use
Events the domain responds to	Identify the actors and corresponding use cases

Finding Actors for a system

Identify who

uses the main functionality?
needs support to do their daily tasks?
needs to maintain, administer, and keep the system working?
has interest in reports or files produced by the system

Identify what

hardware devices should be handled?
other systems that provide support or need output?

Finding Use Cases for a system

For each actor identified, determine

what needs to be done?
which functions are required?
is there a read, create, destroy, modification or storage of information?
are there simplifications that can improve the work?

Finding Use Cases for a system where events may not be obviously related to actors,

determine

What output does the system produce?
Where does the output go?
What are the major problems with the current implementation?

Use Case Type -- Real

Describes a process in terms of

current design,
specific input and output technology,
user interfaces and widget interaction.

Typical Course of Events: ATM Withdraw Cash (Real Description)
Actor Actions:	System Response:
1) The Customer inserts their card	2) Prompts for PIN
3) Enters PIN on keypad	4) Displays options menu

Typical Course of Events: Item Checkout (Real Description)
Actor Actions:	System Response:
1) For each item, the Cashier types in the UPC in the UPC input field of Window1. Then press the "Enter Item" button with the mouse or press the <Enter> Key.	2) Displays the item price and adds the item information to the running sales transaction. The description and price of the current item are displayed in Textbox 2 of Window1.

Real descriptions during the analysis phase restrict creative solutions.

Create real use cases during the design phase.

Use Case Type -- Essential

Describes a process abstractly in terms of its

essential activities
motivations
relatively free of input and output technology,
relatively free of design decisions

Typical Course of Events: ATM Withdraw Cash (Essential Description)
Actor Actions:	System Response:
1) The Customer identifies themselves	2) Presents options

Typical Course of Events: Item Checkout (Essential Description)
Actor Actions:	System Response:
1) The Cashier records the identifier from each item If there is more than one of the same item, the Cashier can enter the quantity as well	2) Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are presented.

The typical course of events

is the most common sequence of events between an actor and the system

The alternative courses of events

are the infrequent exceptions to the typical sequence

Alternative Sequences -- Buy Items with Cash
Line Number	Cause	Response
Line 2	Invalid identifier entered	Indicate error
Line 7	Customer didn't have enough cash.	Cancel Sales transaction.

Also likely alternatives -- branching

Typical Course of Events: Buy Items
Actor Actions:	System Response:
1) (steps skipped ...)
2) Customer chooses payment type, if payment type is Cash, see Pay by Cash section Credit, see pay by Credit section Check, see pay by Check section
	3) Logs the completed sale 4) Prints a receipt

Section:	Pay By Cash
Typical Course of Events
Actor Actions:	System Response:
1) The Customer gives a cash payment -- the "cash tendered" -- possibly greater than the sale total.
2) The Cashier records the cash tendered	3) Shows the balance due the Customer
4) The Cashier deposits the cash received and extracts the balance owning to give to the Customer.

Relating Use Cases -- Include Relationships (Also known as uses relationships)

a use case is incomplete and will not work unless it includes or uses the behavior of another use case (dependency relationship).

The <<include>> use case

is usually a scenario found in multiple use cases.
becomes a component of reuse.
is graphically portrayed with stereotype << include>> or << uses >> next to a dependency arrow from base case pointing to included case.

A stereotype can be used to give extra information about a model element on a diagram.

Typical Course of Events: Buy Items (Text example of Uses/includes)
Actor Actions:	System Response:
1) (steps skipped ...)
2) Customer chooses payment type, if payment type is Cash, initiate Pay by Cash Credit, initiate Pay by Credit Check, initiate Pay by Check

Relating Use Cases -- Extend Relationships (variations on the typical course)

a use case is normally sufficient but an available option requires the added scenario of another use case.

The <<extend>> use case

requires the base case to have an extension point where the optional behavior may occur
is graphically portrayed with stereotype << extend>> next to a dependency arrow where the extended case points to the base case.
can list the extension point(s) by the arrow.
(Stereotypes are used to give extra information about a model elements)

Typical Course of Events: Buy Items (Text example of Uses/includes)
Actor Actions:	System Response:
1) (steps skipped ...)
12) (delivery address option) The Customer leaves with the items purchased.

Relating Use Cases -- Open Modeling Language Concepts

Invokes -- one use case invokes another -- stereotype <<invokes>>

Precedes -- use cases must be ordered in a logical sequence -- stereotype <<precedes>>

Use Case Relationships (UML Version 1.1)

Use Case Relationships (UML Version 1.3)

Showing Relationships in UML

Dependency Arrow -- A is dependent on B if a change in B may force a change in A. Dashed line from A with arrow pointing to B

Association Line -- A set of links representing a conceptual relationship or responsibility between objects. Solid line between A and B ( may include multiplicity and role)

Generalization -- B (child) inherits the structure and behavior of A (parent). Solid line from B with hollow arrowhead pointing to A.

Generalization Relationships

a use case can inherit the behavior and meaning of the parent. An Example is Validate user with children Check password, Retinal Scan.

The generalization relationship is illustrated in 16-5 (B) p227

Setting Priorities -- Rank Order Use cases

Many factors may be need to be balanced when ranking Use cases:

a. Impact on the architectural design
b. Information and insight regarding the design
c Risky, time-critical, or complex functions
d. New or risky technology.
e. Represent line-of-business processes
f. Directly support increased revenue or decreased costs.

Use Case	a	b	c	d	e	f	Sum
Buy Items	5	3	2	0	5	3	18
Add New Users	3	3	2	0	2	2	12
Start Up	3	2	2	0	2	2	11

It is also possible to do simpler classifications -- high, medium, low

Rank	Use Case	Justification
High	Buy Items	Scores on most increased ranking criteria.
Medium	Add New Users Log In Refund Items	Affects security subdomain Affects security subdomain Important process; affects accounting
Low	Cash Out Start Up Shut Down	Minimal effect on architecture Definition is dependent on other use cases Minimal effect on architecture.

Use case versions for development cycles

Time-box development cycles have a fixed time frame.
Complex use cases may require multiple development cycles to be fully implemented.
Create simplified versions of the complex use case that can be developed within each subsequent time-box.

Use Case:	Buy Items (L) pp. 67-68
Simplify & Constrain the Typical Course of Events:
Actor Actions:	System Response:
1) This Use case starts when a Customer arrives at POST with items to purchase.
2) The Cashier records each item. If there is more than one of an item, the Cashier can enter the quantity as well	3) Determines the item price and adds the item information to the running sales transaction. Show description and price of the current item
4) On completion of item entry, the Cashier indicates to the POST that item entry is complete.	5) Calculates and presents the sale total.
6) The Cashier tells the customer the total
7) The Customer chooses payment type: If cash, see Pay by Cash If credit, see Pay by Credit If check, see Pay by Check	8) Logs the completed sale 9) Updates inventory levels 10) Generates a receipt
11) The Cashier gives the receipt to the Customer
12) The Customer leaves with the items purchased.

Analysis and Preliminary Design

Problem domain -- real-world things and concepts related to the problem that the system is being designed to solve.

Domain modeling is the task of discovering objects that represent those things or concepts. The domain model serves as a glossary of terms.

Build a conceptual model containing the classes that accurately represent real abstractions of the problem domain.

This can be done shortly after gathering Use Cases

or it can be done concurrently with the definition of Use cases

Best sources of classes

High level problem statement
Lower-level requirements
Expert knowledge of the problem space.

Conceptual Model

shows important real-world concepts in the vocabulary of the problem domain.
becomes a foundation for the class model

consists of

concepts (objects, roles, events, interactions)

and may also contain

associations
attributes

In general

Nouns and noun phrases become objects and attributes
Verbs and verb phrases become operations and associations.
Possessive phrases indicate that nouns should be attributes rather than objects

Concept

"An idea or notion we share that applies to certain things in our awareness. Also called an object type"

"Our reality consists of those concepts that we possess and those things, or objects, to which our concepts apply." James J. Odell

When a concept has a clear definition (intension), the definition can be

tested against other objects to see if they belong to the same class (extension).

The intension and extension of a concept can be referred to symbolically by a name and/or graphic representation i.e. musical instrument.

Concepts can be represented by symbols. ie. Musical Instrument

Total conceptual model (Ideal?)

All significant concepts in the domain.

Minimal conceptual model (Practical?)

Consists of the important real-world concepts in the use case being developed.

Strategies for finding domain concepts

Noun Phrase Identification (try Use Case 1)
Consultation with domain experts (conceptual understanding)
Concept Check List (Larman pp. 92-93)

How to make a conceptual model

List the candidate concepts

Draw them in a model

Add needed associations

Add needed attributes

Mapmaker strategy

Use existing names of the territory (which one?)
Exclude irrelevant features (noisy things -- true, but not necessary now)
Do not add things that do not exist in the territory (true, but not here)

Specification objects

How to knowledgeably buy an object that has not been seen?
Need specifications -- a description of the object .

Assignment (10 points)

Requirements of the project should be defined as functions needed

(Use function list based on Craig Larman's format).