Object-Oriented Software Engineering

Requirements Formulation

On a big project you have to start somewhere; that somewhere is capturing requirements.
Our model process goes roughly like this
1. brainstorm, write down some fuzzy ideas and pictures, then make a feature list;
2. Next, make a first pass at the use-cases;
3. Check if the features we had in mind were well-covered; if not, add/modify/refine the use-cases as well as the GUI sketches, feature list, etc.

Feature Lists

One good first concrete step is to make a feature list, a list of supported features
Make some GUI sketches, brainstorm, look at related software, and produce a feature list.
This initial data will be helpful in the next step of refinement, writing out some use-cases.
Requirements lists as defined in the book are closely related to feature lists, they are lists of things the software should do, including features but also including operating constraints

Vision Statements

For larger projects you may not even be able to start with concrete features; at least start with a vision statement:

Mainly an English description of what the application should do
This may include a very fuzzy list of features
Chapter 6 of the book gives an example vision statement - see p.254.

On your projects you get to write a vision statement and a feature/requirements list.

Use-cases

Use-cases are the primary focus of requirements gathering.
Chapter 3 of the HFOOA&D book covers use-cases in detail.

Definition A use-case is a scenario describing a series of events involving actors which describes one functionality the system should have.

You can develop class designs from the use cases
Continually elaborate and expand on the use-cases, until they are defined enough to implement.
New use cases will arise as the requirements evolve, existing use cases may change, and some use cases may be dropped.
The overall development plan can be driven by implementing use cases:
"implement these use cases today, those use cases tomorrow".

Example use cases: ATM Machine

Here are some very simple use cases to give you the idea of the structure.

Login
Primary Actor: customer
Secondary Actor: bank
Goal: customer gets access to different account options
Main Path

insert card
card id read; prompt and accept PIN input from user
if correct, display list of choices deposit/withdraw/..

Withdrawl
Primary Actor: customer
Secondary Actor: bank
Goal: get money from machine
Main Path

user presses withdrawl choice
prompt for checking/savings withdrawl and user indicates
money entered
transaction processed and authorized, money is dispensed, card and receipt returned.

Alternate Path

4.1 transaction not authorized, message displayed
4.2.1 card immediately returned

Finding the right use cases

Use cases should cover the core things the application needs to do
imagine scenarios of use and make sure there is a use-case about them
Use the feature lists, GUI sketches, etc as fodder for rooting out the use-cases.
(p. 78 and pp 304-305 give examples of extracting use-cases from feature lists)
Use cases are also found by looking at what the actors need to get out of the software system.
(actors are the external entities involved with the software system: people, devices, computers, etc)
Initially use cases may be somewhat vague; they will be elaborated, and some steps may turn into their own use-cases

The Format for Writing Use Cases

Many formats are good. We are going to use the format followed by the book, in particular the way they are defined on p. 562.

Title which is a capsule summary, and perhaps a version number
Actors involved in the use-case (for "actor", think real-world role, e.g. people: salesperson, customer; or, computer systems/components: backend database, web server, etc). The Primary Actor is the initiator, and the Secondary Actor(s) are any other actors.
A Goal stating briefly what the use-case should do.
the Pre-Condition of the use-case, a state or event that causes it to begin.
the Main Path of the use-case, which is a numbered list of actions described in English; use the numbering scheme in the book
Alternate Paths of the use-case (note p. 562 calls them "Extensions" but in most of the book they call them alternate paths, so we will use that term).
Other things that may be useful to include are post-conditions that will hold when the case is all over, UML diagrams associated with the use-case (we cover that below), etc.

Examples of use-cases

Chapters 2-4 and 10 of HFOOA&D are filled with examples of use-cases and their refinement.

One of the most complete examples is in the book on p. 124
A more detailed ATM example - click on "use cases" on the left to see them.
use-cases from a past OOS project.
Here is a webpage with a simple example: Coffee maker stories.

We will work through a larger example in class.

UML and Use-Cases

(We don't discuss the diagram syntax in these notes, see the Course UML Notes and references therein)

Use-case diagrams

UML supports a use-case diagram

It shows the relationships between the use-cases and the actors (entities outside the system acting on it)
For many applications there isn't much interesting in the diagram so it is not needed
For systems with many actors and distinct activities it can be very helpful

What use-case diagrams give you

It can be a very good way to start gathering the requirements -- making a use-case diagram is the second step in the process defined in the book, see Ch 10 pp 496-500.
They are the "big picture", showing you the whole system on a single page
They can help you map fuzzy features onto more precise use-cases.

The HFOOA&D book likes use-case diagrams.

HFOOA&D pp. 295-306 goes into a lot more detail on how use-case diagrams can be integrated into design.
For example, pages 304 and 305 show a final use-case diagram and how it can be used to assign features to use-cases.

Activity Diagrams for Individual Use Cases

Activity diagrams are not object-centric so they can be used for elaborating the structure of complex use cases with many alternate paths.
Each step in the use-case is an activity in the diagram.

We will draw an activity diagram for a use case in class.

Here is one example from a 2006 OOSE project for a multiplayer Tetris game on cellphones:

Initial Architecture Modeling aka The Big Break-Up

See the HFOOA&D book pp. 310-... and 501-...

An initial stab at the component and deployment structure can be made at this point, including what technologies/frameworks you propose to use.
It won't be perfect, but the principle of divide-and-conquer is critical and you need to start early.

Domain Analysis and Domain Modeling

(This topic is not in the HFOOA&D book)

Domain Analysis as used in the book is a broad term meaning any activity which increases the understanding of the underlying domain the software is working in.
Most of requirements gathering is in fact domain analysis.
One particularly important form of domain analysis is called domain modeling or business modeling, which we cover in detail now (its not in the book)

Domain Modeling

A Domain model is a conceptual model the underlying domain, not of the actual program.
Example: in a restaurant (even without a computer) the "domain" is the actual, physical restaurant and some entities in the domain include Orders, Menu Items, Payments, Receipts, Waitron, etc.
If you want to make a computerized ordering process it is important to have a precise idea what is happening in the physical world first
One of the best ways to make such a model is to use UML class and activity diagrams

Domain use cases

A domain use-case is a use-case which concerns a process happening in the "real world" which

either it needs to be modeled in the software (e.g. paper invoicing process),
or the software is to interact with it (e.g. load pizzas in car, plan route and deliver).

Domain use cases are, like domain modeling in general, used to better understand the application domain.

UML and domain modeling

UML class diagrams are useful for clarifying the domain entities (real or imagined) and how they relate
UML activity diagrams are useful for modeling the processes that occur in the domain.

We will develop a UML class diagram for a restaurant and a UML activity diagram for the process of taking an order in class

Requirements Capture for the Course Projects

We will cover what you will be doing for Iteration 1 of your projects.