CSC 395

1
CSC 395 Software Engineering

• Lecture 15
• Object-Oriented Design or
• Ask For Whom The Data Tolls

2
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

3
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 thats how it is done
• Progress is impossible without change, and those
  who cannot change their minds cannot change
  anything. -- George Bernard Shaw

4
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

5
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

6
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

7
Why Care About Data Flow?

• Computers are very fast very stupid
• Humans far better at all but most precise tasks
• Computers used when work is too tedious
• Basically giant devices transforming information
• Data flow diagrams model systems goal well
• Classes, methods, fields should be means to an
  end

input
output
8
Data Flow Diagram Notation

• Drawn using 4 different pieces
• External Entity
• Process
• Data Flow
• Data Store

9
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?

10
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

11
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

base
compute triangle area
area
height
12
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

sensor
look-upsensordata
sensor , type, location, age
report required
type, location, age
sensor number
sensor data
13
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

14
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 15 between levels
• Ultimately, each process should do exactly 1
  thing
• Data flows may be expanded in lower levels
• Data dictionary provides information for expansion

15
Data Flow Hierarchy
P
a
b
x
y
level 0
level 1
p2
c
a
p1
f
p4
p5
b
d
p3
g
e
16
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

17
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

18
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