Software Design 1

7/31/2019 Software Design 1

1/38

THE SOFTWAREDESIGN PROCESSCSCE 315 Programming Studio

Spring 2010


2/38

Design when?

Software design ~ activity that turns requirementsto a plan or an outline of code

When software design takes place varies (size,

required quality, e.g., affect). Two opposite ends:1. Full detailed spec before anything programmed

2. Design takes place during construction (at thekeyboard)

Usually a mix

More often than not, some design in front of akeyboard


3/38

Outline

Challenges in Design

Design Concepts

Heuristics

Practices


4/38


Design is a wicked problem [Rittel, Webber

73]

A problem that can only be (clearly) defined by

solving it Only after solving it do you understand what

the needs actually are

e.g. Tacoma Narrows bridge Plan to throw one away

Problem of this class

Design problems are not wicked


5/38


Process is Sloppy Mistakes

Wrong, dead-end paths

Stop when good enough

It is not a bad thing that design is a sloppy activity Cheap to correct errors when nothing built yet

Tradeoffs and Priorities Goodness of a design dependent on priorities

Fast develoment time? Scalable? High-performance?Adaptable

Designers task to strike the right balance

Priorities can change


6/38


Restrictions are necessaryConstraints improve the result

Force simplifications and generalizations

Nondeterministic processNot one right solution

A Heuristic processRules of thumb vs. fixed process

Emergent Evolve and improve during design, coding


7/38

Brooks: Accidental vs. EssentialDifficulties

Accidental difficulties have been and areaddressed

Better languages, better IDEs, better debuggers,

etc. Essential difficulties unavoidable

Even with a perfect programming language,software must precisely model parts of real world.

This is inherently complex.


8/38

Primary goal of software design

Managing Complexity


9/38

Managing Complexity

All other goals secondary

Goal of minimizing complexity suggests twogoals

1. Minimize the amount of complexity that ahuman (programmer) must deal with at any onepoint of time

2. Minimize accidental complexity


10/38

Levels of Design

Software system as a whole

Division into subsystems/packages

Classes within packages

Data and routines within classes Internal routine design

Work at one level can affect those below and

above. Design can be iterated at each level


11/38

Key Design Concepts

Most Important: Manage Complexity

Software already involves conceptual hierarchies,abstraction

Goal: minimize how much of a program you haveto think about at once

Should completely understand the impact of codechanges in one area on other areas


12/38

Good Design Characteristics

Minimal complexity Favor simple overclever


13/38


Minimal complexity

Ease of maintenance

Imagine whatmaintainer of codewill want to know

Be self-explanatory


14/38


Minimal complexity

Ease of maintenance

Loose coupling

Keep connectionsbetween parts ofprograms minimized Avoid n2 interactions!

Abstraction,encapsulation,information hiding


15/38


Minimal complexity

Ease of maintenance

Loose coupling Extensibility

Should be able toadd to one part ofsystem without

affecting others


16/38


Minimal complexity

Ease of maintenance


Reusability

Design so codecould be lifted intoa different system

Good design, even ifnever reused

It should be pointed out that the preparation of a librarysub-routine requires a considerable amount of work. This

is much greater than the effort merely required to code

the sub-routine in its simplest possible form. [Whe52]


17/38


Minimal complexity

Ease of maintenance


Reusability

High fan-in

For a given class,have it used bymany others

Indicates reuseeffective


18/38


Minimal complexity

Ease of maintenance


Reusability

High fan-in

Low-to-medium fan-out

Do not use too manyother classes

Complexity

management


19/38


Minimal complexity

Ease of maintenance


Reusability

High fan-in


Portability

Consider what willhappen if moved toanother environment


20/38


Minimal complexity

Ease of maintenance


Reusability

High fan-in


Portability

Leanness

Dont add extraparts

Extra code will need

to be tested,reviewed in futurechanges


21/38


Minimal complexity

Ease of maintenance


Reusability

High fan-in


Portability

Leanness

Stratification

Design so that youdont have toconsider beyond the

current layer


22/38


Minimal complexity

Ease of maintenance

Loose coupling

Extensibility Reusability

High fan-in


Portability Leanness

Stratification

Standard Techniques

Use of commonapproaches make iteasier to follow code

laterAvoid unneededexotic approaches


23/38

Design Heuristics

Rules-of-thumb

Trials in Trial-and-Error

Understand the Problem

Devise a Plan

Carry Out the Plan

Look Back and Iterate


24/38

Find Real-World Objects

Standard Object-Oriented approach

Identify objects and their attributes

Determine what can be done to each object

Determine what each object is allowed to do toother objects

Determine the parts of each object that will be

visible to other objects (public/private) Define each objects public interface


25/38

Form Consistent Abstractions

View concepts in the aggregate

Car rather than engine, body, wheels, etc.

Identify common attributes

Form base class

Focus on interface rather than implementation

Form abstractions at all levels

Car, Engine, Piston


26/38

Inheritance

Inherit when helpful

When there are common features


27/38

Information Hiding

Interface should reveal little about innerworkings Example: Assign ID numbers

Assignment algorithm could be hidden

ID number could be typed

Encapsulate Implementation Details

Do not set interface based on what is easiest touse Tends to expose too much of interior

Think about What needs to be hidden


28/38

More on Information Hiding

Two main advantages

Easier to comprehend complexity

Localized effects allow local changes

Issues: Circular dependencies

A->B->A

Global data (or too-large classes)

Performance penalties

Valid, but less important, at least at first


29/38

Identify Areas Likely to Change

Anticipate Change Identify items that seem likely to change

Separate these items into their own class

Limit connections to that class, or create interfacethats unlikely to change

Examples of main potential problems:Business Rules, Hardware Dependencies, Input/Output,

Nonstandard language features, status variables,difficult design/coding areas


30/38

Keep Coupling Loose

Relations to other classes/routines

Small Size Fewer parameters, methods

Visible Avoid interactions via global variables

Flexible Do not add unnecessary dependencies

e.g. using method that is not unique to the class itbelongs to


31/38

Kinds of Coupling

Data-parameter (good) Data passed through parameter lists

Primitive data types

Simple-object (good) Module instantiates that object

Object-parameter (so-so) Object 1 requires Object 2 to pass an Object 3

Semantic (bad) One object makes use of semantic information about

the inner workings of another


32/38

Examples of Semantic Coupling

Module 1 passes control flag to Module 2 Can be OK if control flag is typed

Module 2 uses global data that Module 1 modifies

Module 2 relies on knowledge that Module 1 calls

initialize internally, so it doesnt call it Module 1 passes Object to Module 2, but only initializes

the parts of Object it knows Module 2 needs

Module 1 passes a Base Object, but Module 2 knows it

is actually a Derived Object, so it typecasts and callsmethods unique to the derived object


33/38

Design Patterns

Design Patterns, by Gang of Four (Gamma,Helm, Johnson, Vlissides)

Common software problems and solutions that

fall into patterns Provide ready-made abstractions

Provide design alternatives

Streamline communication among designers


34/38

More on Design Patterns

Given common names

e.g. Bridge builds an interface and animplementation in such a way that either can vary

without the other varying

Could go into much more on this


35/38

Other Heuristics

Strong Cohesion

All routines support the main purpose

Build Hierarchies

Manage complexity by pushing details away

Formalize Class Contracts

Clearly specify what is needed/provided

Assign Responsibilities Ask what each object should be responsible for


36/38

More Heuristics

Design for TestConsider how you will test it from the start

Avoid Failure

Think of ways it could fail Choose Binding Time ConsciouslyWhen should you set values to variables

Make Central Points of Control Fewer places to look -> easier changes


37/38

More Heuristics

Consider Using Brute Force

Especially for early iteration

Working is better than non-working

Draw Diagrams

Keep Design Modular

Black Boxes

D i P ti


38/38

Design Practices

(we may return to these)

Iterate Select the best of several attempts Decompose in several different ways

Top Down vs. Bottom Up

Prototype

Collaborate: Have others review your designeither formally or informally

Design until implementation seems obvious Balance between Too Much and Not Enough

Capture Design Work Design documents

Documents

Software Design 1