CSC 395 –Software Engineering

Lecture 15:

Object-Oriented Design –or–

Ask For Whom The Data Tolls

In This Lecture

Analysis ends with specification document Client approves of pretty drawings. Have better, more detailed use-cases

Begins with completed architectural design Designed high-level modules (e.g., class design) (Also determined hardware requirements) Determine responsibilities for each module

Must develop the detailed design Determine smaller modules (e.g., fields/methods) Do everything in power to support code monkeys

“Solutions” & Solutions

Software engineering is iterative Decisions always reexamined & reevaluated

Nothing final until process completes In a good product, process is never complete

Best result is solution to current needs Worst answer is “because that’s how it is done”

Progress is impossible without change, and those who cannot change their minds cannot change anything. -- George Bernard Shaw

“Solutions” & Solutions

Important to consider timelines, too Best solutions rarely make it to market

Premature optimization is the root of all failure. -- Donald Knuth

In a group, requires respectful honesty

Honest differences are often a healthy sign of progress. -- Mahatma Gandhi

What is Architectural Design?

Architectural design takes in specifications Suggests it is part of design workflow Ends with modular decomposition We did this as part of analysis workflow

For classical (non-OO) software engineering Decomposes problem into functions and

functional units: this is the essence of design For object-oriented software engineering

Decomposes problem into classes and packages and should be done as part of analysis

Books (and organizations) split on placement

Detailed Design

Begins with lists of classes Each has list of responsibilities Diagrams show classes (& instances) interactions

Also have use-cases and scenarios Used these to develop & test our classes Spent time at end of analysis refining use-cases Use-cases now drive detailed design Best to start “old-school” -- data flow diagrams

Why Care About Data Flow?

Computers are very fast & very stupidComputers are very fast & very stupid Humans far better at all but most precise tasksHumans far better at all but most precise tasks

Computers used when work is too tediousComputers used when work is too tedious Basically giant devices transforming informationBasically giant devices transforming information

Data flow diagrams model system’s goal well Classes, methods, fields… should be means to

an end

inputinput outputoutput

Drawn using 4 different pieces:

External Entity

Process

Data Flow

Data Store

Data Flow Diagram Notation

External Entity

Denotes problems external to the software Should be actual cause of information Could be: user, mouse, file, database, sensor

All data originates outside of program Random number generators are external entities Could be another class when looking from

perspective of a class All data is ultimately sent to something

If not, what is point of the program?

Process

Transforms input in some manner Examples: compute taxes, read in from file,

mutilate important letter beyond recognition Should process data in consistent manner

Consider splitting if there is no common process Does not require everything be identical

May (should) have multiple transformations Each process performs single (reasonable) step Remember to look to use-cases for these

Data Flow

Shows how data should move along system Connects inputs & outputs during program Should follow where data flows Should NOT follow how system operates

Provides opportunity to simplify design Eliminates processes whose outputs are not used Split processes with multiple data outputs

computetriangle

area

base

height

area

Data Store

Data often stored externally to allow reuse May be in file or database Could set properties of piece of hardware

Could overlap with external entity Difference is in bi-directionality of information

look-upsensor

data

sensor #

report required

sensor #, type, location, age

sensor data

sensor number

type, location, age

DFD Rules

Label icons with meaningful names Label data flows using descriptive name Do not represent procedural logic DFD incorporate many levels of detail

Evolutionary approach that zooms-in on details Can be useful for detailed or complex flows

Begin with a context level diagram (level 0) Shows external entities and high-level processes Starting point for non-OO software engineering

Using A DFD

Review use-case(s) & scenarios Source of transforms needed for each datum

Often need 3 - 7 levels for adequate model Do not rush; keep diagram readable & continuous Process expansion ratio about 1:5 between levels Ultimately, each process should do exactly 1 thing

Data flows may be expanded in lower levels Data dictionary provides information for

expansion

Data Flow Hierarchy

Pxx yya b

p1

p2

p3

p4 p5

a

b

c

de

f

g

level 0

level 1

Split Along Module Boundaries

Find where input & output are most abstract Split into modules along those boundaries Must be done on case-by-case basis

Transactions Are Different

Be wary of transaction-based flows Single input step leading to multiple processes

Should be handled very differently Create single dispatcher calling abstract method Handler classes then override abstract method

In The Next Lecture

Now have idea of where to place methods Still too hard for the code monkeys Not very open for testing or considering

Converting detailed design into something usable Look at algorithms, patterns, and data dictionaries