Requirements -> OOA -> OOD -> Implement / test

Requirements

identify and document what is required

• overview

• customers

• goals

• system functions

• system attributes

Use cases

• Narrative describing a sequence of events of an actor who uses a system to complete a process.
• Not requirements, but illustrate and imply requirements.
• Actors are external to the system

High level use cases

• name
• type
• description

Expanded use cases

• more details
• includes typical course of events
• may include alternatives

Essential use case

Use cases expressed in a way that does not imply an implementation.

Analysis

Conceptual model

• identify concepts
• associations
• attributes
• glossary
• sequence diagrams
• contracts

Conceptual model (chapter 9)

Basic problem solving approach
"chop up into more manageable chunks"

• divide and conquer
• decomposition
• implies: separation of concerns

Structured analysis : "chunks" are tasks

Object oriented : "chunks" are concepts or objects

Concepts

"real world" things

not software components

cashier, sale	Yes
window, database	No

have attributes, but no operations

finding concepts

(chapter 9)

category list

Identifying concepts by noun phrase

"Read the specifications documents and underline the nouns or noun phrases"

Recommended in most texts. Simple and obvious. Meyer says "no". (OOSC, ch 22) Only finds concepts so obvious that you would have found them anyway. Doesn't help in finding non-obvious but important concepts.

Candidate concepts for POST

Conceptual model (concepts only)

Names

• use existing names in domain
• exclude irrelevant things (trolley)
• don't put in things that aren't there

Concept or attribute?

• not always easy to decide
  (account number)
• if it is not a number or text in real world it is probably a concept

Specification (description) concepts

description of item different from item

maybe no items, but still description

Associations

(chapter 10)

• relationships between concepts

• connection must be of interest

• needs to be preserved for some duration

Associations are for analysis phase
may be implemented (as reference to object) but not necessarily.

UML notation

Records-current is name of association
use verb phrase

Multiplicity

Finding associations

Category	Examples
A is a physical part of B	Drawer - POST Wing - Plane
A is a logical part of B	SalesLineItem - Sale FlightLeg - FlightRoute
A is physically contained in B	Item - Shelf Passenger - Plane
A is logically contained in B	ItemDescription - Catalogue Flight - FlightSchedule
A is a description of B	ItemDescription - Item
A is a line item of a transaction or report B	SalesLineItem - Sale
A is recorded in B	Sale - POST
A is a member of B	Cashier - Store Pilot - Airline
A is an organizational subunit of B	Department - Store
A uses or manages B	Cashier - Store Pilot - Plane
A communicates with B	Customer - Cashier Hostess - Passenger
Category	Examples
B is a transaction and A is related to B	Customer - Payment Passenger - Ticket
A & B is are transactions and A is related to B	Payment - Sale Reservation - Cancellation
A is next to B	POST - POST Airport - Airport
A is owned by B	POST - Store Plane - Airline

Highest priority associations

• A is a physical or logical part of B

• A is physically or logically contained in B

• A is recorded in B

Applying associations checklist to post

Category	Examples
A is a physical part of B	not applicable
A is a logical part of B	SalesLineItem - Sale
A is physically contained in B	POST - Store Item - Store
A is logically contained in B	ProductSpecification - ProductCatalog ProductCatalog - Store
A is a description of B	ProductSpecification - Item
A is a line item of a transaction or report B	SalesLineItem - Sale
A is recorded in B	(current) Sale - POST (completed) Sale - Store
A is a member of B	Cashier - Store
A is an organizational subunit of B	not applicable
A uses or manages B	Cashier - POST Manager - POST Manager - Cashier ?
A communicates with B	Customer - Cashier
B is a transaction and A is related to B	Customer - Payment Cashier - Payment
A & B is are transactions and A is related to B	Payment - Sale
A is next to B	POST - POST ?
A is owned by B	POST - Store

Conceptual model for POST

(no attributes)

(Larman, fig 10.7)

Which associations go into the conceptual model, which are omitted?

Two criteria, "need to know" and "comprehension"

need to know

If don't need to know something, don't put it in.

According to specifications, we don't need to know that a sale was associated with a customer.

If specifications were different, there may be a need to know that sale is associated with customer.

eg build up customer profile
put weetbix beside fruit; cornflakes beside sweets
mailing list for advertising of weetbix promotions

comprehension

Conceptual model is a document. Should give understanding of domain.

The more complete, the better understanding it gives to reader. Also the more useful it is for the next application, or for extensions to this one.

But, the more complete, the more we have to omit when we implement.

Best balance is somewhere in middle.
all need-to-know associations
+ give essential understanding of domain.

Typing of languages

Strongly typed, weakly-typed, untyped languages

Suppose we have written a function to find the greatest common divisor of two integers.

	gcd(6,9) = 3 

But what happens if we use letters as the arguments.

	gcd('b','v') = ? 

In a strongly-typed language such as Pascal, Eiffel, Java you get a syntax error. (Signature is)

    int gcd(int a, int b) // Java
    gcd(INTEGER a, b) : INTEGER -- Eiffel

In a weakly-typed language (pre-Anscii C or
Fortran 77), you get

	gcd('b','v') = 7 

In an untyped language

Prolog:

	?gcd(b, v, Z)
	NO

Scheme and Smalltalk:

	execution error

Why have (strongly) typed languages?

Good semantics:

gcd is only defined on integers.

It does not make sense to ask for the gcd of two characters. (Some languages would be happy to find the gcd of a string and a record).

	gcd:	N X N -> N

Programmers have spelled out their intentions.

Good documentation:

The relevant domains are clear to the human reader.

Early error finding.

The compiler finds a class of errors for you.
(Static typing)

More efficient code

The compiler has more information and can generate more efficient code.

Generics (parameterised classes)

Strictly speaking not an OO concept

• present in non-OO languages (eg Ada).
• present in most typed OO languages. (~Java)
• not relevant for non-typed OO languages
  such as Smalltalk.

Language asides:
C++ : Generics is an add-on, called templates.
Java : No generics, relies on casting.

Generics is most useful in "collection" classes such as Stack, LinkedList, Queue, Array, ...

Eiffel	Java
str: String c: Character s: STACK[STRING] s.put("abc" str:= s.item	String str; Character c; Stack s; s.push("abc"); str = (String) s.peek();

Casting

The

 (String) in str = (String) s.peek();

Eiffel: c := s.item
syntax error

Java: c = (Character) s.peek();
execution error

Example: Read strings from keyboard and prints in reverse order, Java (no generics) needs to catch a ClassCastException

import java.io.*;
import java.util.*;
/**
  Reads strings and prints last string first etc
*/


public class Reverse {

    public static void main (String [] args)
                       throws ClassCastException {
	String line;
	BufferedReader keyboard;
	keyboard = new BufferedReader(new
                           InputStreamReader(System.in));
	Stack s;

	s = new Stack();
	line = keyboard.readLine();
	while (line.length() > 0) {
	    s.push(line);
	    line = keyboard.readLine();
	}
	while ( !s.empty()) {
	    line = (String) (s.peek());
	    System.out.println(line);
	    s.pop();
	}
    }
}
// main

Eiffel would not need this.