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 stupid Computers are very fast & very stupid Humans far better at all but most precise tasks Humans far better at all but most precise tasks Computers used when work is too tedious Computers used when work is too tedious Basically giant devices transforming information Basically giant devices transforming information Data flow diagrams model system’s goal well Classes, methods, fields… should be means to an end input output

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 compute triangle 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-up sensor 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 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 P x x y y a b p1 p2 p3 p4 p5 a b c d e 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