07 Software Design Heuristics

5/11/2018 07 Software Design Heuristics - slidepdf.com

http://slidepdf.com/reader/full/07-software-design-heuristics 1/67

Software Design Guidelines

Michel Chaudron



Advanced Software Engineering 2011

2MRV Chaudron

Sheet 2

Agenda

Design guidelines Architectural Styles




3MRV Chaudron

Sheet 3

Different aspects of design

Architecture design : The division into subsystems and components,

How these will be connected:

How they will interact:

Interface design & architectural style

Class design :

The various features of classes.

User interface design

Algorithm design : The design of computational mechanisms.

Protocol design :

The design of communications protocol.




MRV ChaudronSheet 4

Why Care about Quality during Design?

As a project progresses,more and more work

depends on earlier decisions.

Cost of

Defect Repair Cost of repair increases exponentially

Defects should be eliminated as soonas possible after their introduction




5MRV ChaudronSheet 5

Architecture is making decisions

The life of a software architect isa long (and sometimes painful)

succession of suboptimaldecisions made partly in the dark.

• You will not have all information available

• You will make mistakes, but you should learn from them

• There is no objective measure for „goodness‟

Grady Booch




Software design is a “wicked” problem

• There is no definite formulation

• There is no stopping rule/test

• Solutions are not simply true or false

• Every wicked problem is essentially novel and

unique.

• Every solution to a wicked problem is a 'one shot

operation'

6

Churchman, C. West, "Wicked Problems", Management Science, Vol. 14, No. 4, December 1967. Guest Editorial

http://en.wikipedia.org/wiki/Management_Science:_A_Journal_of_the_Institute_for_Operations_Research_and_the_Management_Sciences

http://en.wikipedia.org/wiki/Management_Science:_A_Journal_of_the_Institute_for_Operations_Research_and_the_Management_Sciences





Design of Software Architecture

Functional

Requirements

Extra-Functional

Requirements

DomainRequirements

UserRequirements

Group Functionalityin subsystems

Design approach forrealizing extra-functional

quality properties

Synthesize

Analyze refineRBD, QN, RMA,ATAM, prototype

S.M.A.R.T.

Design Metrics

Model/DescribeUML, Views

Identify•Trade-offs•Sensitivity points

Select•Architectural Style•Reference Architecture•Architecture Tactics

Understand the Domain




Design Principles

Simplicity Separation of Concerns

Information Hiding

Modularity

Keep things that belong together in asingle place

How to assess?





David Parnas

We propose that one begins with a list of difficult design decisions or design decisions which are

likely to change. Each module is then designed to

hide such a decision from the others.


Goal: Isolate change

Means: Information hiding, minimizing dependencies

David Parnas

1941-…




In his paper of 1972, Parnas proposed the following problem:

D. L. Parnas, “On the criteria to be used in decomposing systems intomodules,” Communications of the ACM, vol. 15, pp. 1053-1058, Dec.1972.

The KWIC [Key Word in Context] index system accepts an ordered set of

lines, each line is an ordered set of words, and each word is an ordered set of

characters. Any line may be ``circularly shifted'' by repeatedly removing the

first word and appending it at the end of the line. The KWIC index system

outputs a listing of all circular shifts of all lines in alphabetical order.

The KWIC Problem




Parnas shows that different problem decompositions vary greatly

in their ability to withstand design changes. Among the changeshe considers are:

• Changes in processing algorithm: For example, line shifting can

be performed on each line as it is read from the input device, on

all the lines after they are read, or on demand when thealphabetization requires a new set of shifted lines.

• Changes in data representation: For example, lines can be

stored in various ways. Similarly, circular shifts can be stored

explicitly or implicitly (as pairs of index and offset).




KWIC example

Input: strings, each of which consists of severalwords.

Clouds are white.

Ottawa is beautiful.

Output: a sorted list of all orderings of each inputstring.

are white Clouds

beautiful Ottawa is

Clouds are white

is beautiful Ottawa

Ottawa is beautiful

white Clouds are




Diagram from Shaw & Garlan: Introduction to Software Architecture (1994)
















Message: there are many differentsolutions for the same set of requirements





Imprecision in design discussions

Not all boxes in a design are the same thing Not all arrows in a design are the same thing

Imprecision in communication about theseboxes and arrows can add significantconfusion to a software design process andthe resulting design

Oh, that‟s the issue of clarity again

18




Basics of Information Hiding

Separate interfaces from implementations Implementations capture decisions likely to change

Interfaces capture decisions unlikely to change

Clients know only interface, not implementation

Implementations know only interface, not clients





Information hiding

20

• each module has a secret• design involves a series of decision:

for each such decision, wonder who needsto know and who can be kept in the dark

• information hiding is strongly related to

– abstraction: if you hide something, the user mayabstract from that fact

– coupling: the secret decreases coupling betweena module and its environment

– cohesion: the secret is what binds the parts of the module together

©2008 John Wiley & Sons Ltd. www.wileyeurope.com/college/van vliet





Façade pattern

Façade

Clientclasses

Note the effect on the fan-in/coupling of the component




Separation of Concerns

Separate What from How

The interface of a component exposes what

function it can perform, not how.

The ‘how’ is the information-hiding ‘secret’






Example Design Principles

Telecom Domain:Separate the encoding/decoding of a

message from the handling of a

message, so decode1 ; decode2 ; decode3 ;

action1 ; action2

And not

decode1 ; action1 ; decode2 ;action2 ; decode3

handle

encode/decode

handle &encode/decode





Design Principle 1: Divide and conquer

Trying to deal with something big all at onceis normally much harder than dealing with a

set of smaller things

Each individual component is smaller, andtherefore easier to understand

Parts can be replaced or changed without having to

replace or extensively change other parts.

Separate people can work on separate parts

An individual software engineer can specialize





Ways of dividing a software system

A system is divided up intoLayers & subsystems

A subsystem can be divided

up into one or more packages

A package is divided up into classes

A class is divided up into methods





Layering

2

1

0

3Partitioning in non-overlapping units that

- provide a cohesive set of services at an

abstraction level(while abstracting from their implementation)

- layer n is allowed to use services of layer n-1

(and not vice versa)

alternative:bridging layers: layer n may use layers <n

enhances efficiency but hampers portability

Goals: Separation of Concerns, Abstraction, Modularity, Portability

Ad d S f E i i





Ad d S f E i i 2011





Layering into levels of abstraction

Sentences

Phonemes

Syllables

Words

Phrases

Acousticwaveform

Hearsay: speech understanding

Ad d S ft E i i 2011





Layering in Client / Server

• Presentation layer

Dialogue with users

• Application logic

Application for individual user

• Business logic

Logic for processing

across users, divisions

• Data management

Storage of data

presentationlogic

businesslogic

datamanagement

applicationlogic

client

server

Unit of change

Unit of responsibility

Unit of deployment

Ad d S ft E i i 2011

http://upload.wikimedia.org/wikipedia/en/6/66/Overview_of_a_three-tier_application.png






E x a m p

l e 3 - t i

e r

S y s t e

m

Diagram fromWikipedia, 2007

Ad anced Soft are Engineering 2011









Layering in Computer Networks:OSI & Internet

Physical

Data Link

Network

Transport

Session

Presentation

Application

Picture from Jeremy Bradbury,Queens Univ. Canada






A Component-based ReferenceArchitecture for Computer Games

(E. Folmer, 2007)

genec

spefc






What is Modularity?

We can “see it” via a

Design Structure Matrix (DSM)






What is a dependency?

Component A requires B for it to work Functional coupling

A change in module B requires changein module A

Implementation coupling

Typically requires: re-testing A & B

Run-time

Development-time






Dependencies in the code

There is coupling betweentwo classes A and B if:A has an attribute that refers to (is of type) B.

A calls on services of an object B.A has a method which references B

(via return type or parameter).

A is a subclass of (or implements) class B.

This is not an exhaustive definition






Dependency: Coupling

Coupling is the degree of interdependencebetween modules

high coupling low coupling

Design Principle: Reduce coupling where possible






Benefits of Low Coupling/Dependencies

Fewer interconnections between modules reduces• time needed for understanding the modules and

interactions

• the chance that changes in one module cause

problems in other modules, which enhances

reusability

• the chance that a fault in one module will cause a

failure in other modules, which enhancesrobustness

Page-Jones, M. 1980. The Practical Guide to Structured Systems Design . New York, Yourdon Press, 1980.






Example: Before Refactoring

CouplingDynamicCoupling

MethodCalls

Saat 7 10 25

Stat.-Filter 0 3 0

Stat.-Calculator 0 3 0

Analyser 0 4 0

DB-Checker 0 2 0

DB-Filler 0 5 0

DB-Creator 0 2 0

Parser 0 3 0






Example: After Refactoring

CouplingDynamicCoupling

MethodCalls

Saat 2 2 2Stat.-Filter 1 2 1

Stat.-Calculator 0 2 0

Analyser 3 3 12

DB-Checker 0 1 0

DB-Filler 1 4 10

DB-Creator 0 1 0

Parser 0 1 0


MetricView: Graphical Tool for




MRV ChaudronSheet 44

MetricView: Graphical Tool forDeveloper Feedback

UML model

Visualization of model + metricsQuality Metrics/Rules• Completeness• Consistency

• Conventions

Analysis Tool

http://www.win.tue.nl/empanada/metricview/







MetricView video

http://www.youtube.com/watch?v=G3HJ_QR9EG4









a a g g

46

MRV Chaudron

Sheet 46

Guideline: Minimize Dependency

Avoid dependencies where possible:

Design components so that

they know about as few other components as possible

use as few parameters as possible for as short a time as possible

minimize number of calls between components

Ref: Component are from Mars – Chaudron & De Jong




g g

Dependency: Cohesion

Cohesion is concerned with the interactionswithin a module

Heuristic: Keep things together that

belong together.

High cohesion within a

module is good

low cohesionhigh cohesion




g g

Coupling and Cohesion

Coupling is the degree of interaction betweenmodules.

Cohesion is a measure of the coherence of amodule amongst the pieces of that module.

You want high cohesion and low coupling





g g

50

MRV Chaudron

Sheet 50

How to reduce coupling in this design?




g g

51

MRV Chaudron

Sheet 51

Façade pattern

Façade

Client

classes

Note the effect on the fan-in/coupling of the component




Facade pattern

Bedoeling Verschaf een uniforme interface tot een (verzameling

interfaces van een) subsysteem

Motivatie

Subsystemen reduceren de complexiteit

Belangrijk ontwerpdoel: minimaliseren van de communicatieen afhankelijkheden tussen subsystemen

Eenvoudige, uniforme interface tot subsysteem is wenselijk

Individuele interfaces moeten beschikbaar blijven




55

MRV Chaudron

Sheet 55

Types of Coupling

c o

n s i d er e d

w or s e

• Data coupling• data from one module is used in another

• Data type coupling• two modules use the same data type

• Control coupling•actions one module are controlledby another module (switch)

• Content coupling• a module refers to the internals

of another module Bind to interfaceof components




Highly coupled classes belong in

the same component. When two classes collaborate frequently, this is an

indication they should be in the same domaincomponent to reduce the network traffic between thetwo classes. This is especially true when thatinteraction involves large objects, either passed asparameters or received as return values. By includingthem in the same domain component you reduce the

potential network traffic between them. The basicidea is that highly coupled classes belong together.

From Scott Ambler





Minimize the size of the messageflow between components.

Client/server classes belong in a domain component,but there may be a choice as to which domaincomponent they belong to. This is where you need toconsider issues such as the information flow going

into and out of the class. Communication within acomponent will often be simple message sendsbetween objects in memory, communication betweencomponents may require an expensive marshalling

effort in which a message and its parameters areconverted to data, transmitted, and then convertedback into a message again.

From Scott Ambler





58

MRV Chaudron

Sheet 58

. x x x x x

x . x x x x x x x x x

Drive x x . x x x

System x x x . x x x x x x x x

x x . x

x x x x . x x x

x x x . x x

x x x . x x x x

x x x . x x x x x

Main x x x . x x x

Board x x x x x x x x . x x x x x

x x x x x . x x

x x x x x x . x x x

x x x . x

x x x . x x x

x x x x . x x x x

LCD x x x . x x

Screen x x x x . x x x

x x x x x x x . x x x

x x x . x

x x x x . x x x x

x x x . x x x x

x x x x x . x x x

Packaging x x x x . x x

x x x x x . x x

x x x x . x x

x x x x x .

x x x x x .

Graphics controller on Main Board or not?

If yes, screen specifications change;

If no, CPU must process more; adopt different interrupt protocols

Design Structure Matrix Map of a Laptop

Computer




59

MRV Chaudron

Sheet 59

Design Structure Matrix Map of a Modular System

. x x x x

x . x xDesign x . x x D esi gn R ul es Task Group

Rules x x . x

x x x .

x . x x x

x x . x x x

Drive x x x x . xSystem x x x x x . x x Hidden Modules

x x x . x many Task groupsx x x x .

x . x x

x x x x x . x x

x x . x x x xMain x x x x x . x x

Board x x x x x x x . x xx x x x x . x

x x x x x x . xx x x x x .

x x . x x x

x x x . x x x

LCD x x x . x

Screen x x x x x . x x

x x x x x . xx x x x x x .

x x . x x x x

x x x . x x x x

x x x . x x x

Pack- x x x x x x . x x

aging x x x . x xx x x x x . x x

x x x x x .x x x x x x .

x x x x x x . x x x xSystem x x x x x x x x . x x System

Testing x x x x x x x x x . x x x Integration& Integ- x x x x x x x x x x x x and Testing

ration x x x x x x x x . x Task Groupx x x x x x x x x x x .




60

MRV Chaudron

Sheet 60

DSM of Mozilla before and after redesign

Formerly Mozilla was the commercial Netscape Navigator,

then released into open source.

From: Exploring the Structure of Complex Software Designs: An Empirical Study of OpenSource and Proprietary Code, Alan MacCormack, John Rusnak, Carliss Baldwin,

Harvard Business School, draft October 1st 2005

number

of files

1.3 dependencies per KSLOC2.4 dependencies per KSLOC




Conclusions

Simplicity

Separation of Concerns

Information Hiding

Low Coupling, High Cohesion

Layering, Modularity





62

MRV Chaudron

Sheet 62

9.9 Difficulties and Risks in Design

Like modelling, design is a skill thatrequires considerable experience

Individual software engineers should not attempt the design of large systems

Aspiring software architects should actively study designs of other systems

Poor designs can lead to expensive

maintenance Ensure you follow the principles discussed

in this chapter




63

MRV Chaudron

Sheet 63

Difficulties and Risks in Design

It requires constant effort to ensure asoftware system‟s design remains goodthroughout its life

Make the original design as flexible as possible

so as to anticipate changes and extensions. Ensure that the design documentation is usable

and at the correct level of detail

Ensure that change is carefully managed




64

MRV Chaudron

Sheet 64

Inheritance vs. Composition

The two most common techniques for reusingfunctionality in object-oriented systems are class inheritance and object composition

Class inheritance defines the implementation of one

class in terms of another‟s implementation. Withinheritance the internals of parent classes are oftenvisible to sub-classes (white box ).

In object composition new functionality is obtained

by assembling or composing objects to get morecomplex functionality. Internal details of objects arenot visible, objects appear as black boxes .




65

MRV Chaudron

Sheet 65

Pros and Cons of Inheritance

Pros: Class inheritance is defined statically atcompile-time and is straightforward to use, sinceit´s supported directly by the programminglanguage. Class inheritance makes it easier to modifythe implementation being reused.

Cons: You can not change the implementationsbeing inherited at run-time. Inheritance exposes assubclass to details of its parent‟s implementation.Any change in the parent‟s implementation will force

the subclass to change. One cure is to only inheritfrom abstract classes since they provide little or noimplementation.




66

MRV Chaudron

Sheet 66

Pros and Cons of Composition

Composition is defined at run-time throughobjects acquiring references to other objects.

Composition requires objects to respect eachother‟s interface. Because objects are accessedsolely through their interfaces we don‟t breakencapsulation. Any object can be replaced atrun-time by another as long as it has the sametype.

Because an object´s implementation is written

in terms ob object interfaces, there aresubstantially fewer implementationdependencies.




67

MRV Chaudron

Sheet 67

Inheritance vs. Object Comp.

Favoring object composition over classinheritance helps you keep each classencapsulated and focused on one task.

Classes and class hierarchies remain small

and managable. A design based on object composition has

more objects (if fewer classes) and the system

behavior depends on their interrelationshipsinstead of being defined in one class.

Chapter 9: Architecting and designing software



© Lethbridge/Laganière 2005 ESE 4.68

Assigning Responsibilities

> Evenly distribute system intelligence— avoid procedural centralization of responsibilities— keep responsibilities close to objects rather than their clients

> State responsibilities as generally as possible— ―draw yourself‖ vs. ―draw a line/rectangle etc.‖

— leads to sharing

> Keep behaviour together with any related information — principle of encapsulation





Assigning Responsibilities ...

> Keep information about one thing in one place — if multiple objects need access to the same information

1. a new object may be introduced to manage the information, or

2. one object may be an obvious candidate, or

3. the multiple objects may need to be collapsed into a single one

> Share responsibilities among related objects— break down complex responsibilities





Characterizing Classesaccording to Rebecca J. Wirfs-Brock, IEEE Software, March/April 2006

■ Information holder : an object designed to know certain information and provide thatinformation to other objects.

■ Structurer : an object that maintains relationships between objects and information aboutthose relationships.

Complex structurers might pool, collect, and maintain groups of many objects; simplerstructurers maintain relationships between a few objects. An example of a generic

structurer is a Java HashMap, which relates keys to values.

■ Service provider : an object that performs specific work and offers services to others ondemand.

■ Controller : an object designed to make decisions and control a complex task.

■ Coordinator : an object that doesn’t make many decisions but, in a rote or mechanicalway, delegates work to other objects. The Mediator pattern is one example.

■ Interfacer : an object that transforms information or requests between distinct parts of asystem. The edges of an application contain user-interfacer objects that interact withthe user and external interfacer objects, which communicate with external systems.Interfacers also exist between subsystems. The Facade pattern is an example of aclass designed to simplify interactions and limit clients’ visibility of objects within a

subsystem.



71Wirfs-Brock Associates www.wirfs-brock.com Copyright 2000

Guidelines for Naming Inventions

“…the relation of thought to word is not a thing but a process, a continual

movement back and forth from thought to word and from word to thought. …Thought is not merely expressed in words; It comes into existence through

them.”

— Lev Vygotsky, thought and language

Fit a name into some naming scheme

Java example: Calendar GregorianCalendarJulianCalendar?

ChineseCalendar?

Give service providers “worker” names

Service providers are “workers”, “doers”, “movers” and “shakers “

Java example: StringTokenizer, ClassLoader, and AuthenticatorChoose a name that suits a role

Objects named “Manager” organize and pool collections of similar objects

AccountManager organizes Account objects

G id li f N i I ti



72Wirfs-Brock Associates www.wirfs-brock.com Copyright 2000

Guidelines for Naming Inventions

Choose names that don’t limit behavior options

Account or AccountRecord?Record — information or facts set down in writing — an informational

object

Account — sounds livelier — an object that makes informed decisions on

the information it represents

Choose a name that suits a lifetime

A ninety-year old named “Junior”?

ApplicationInitializer or ApplicationCoordinator?

Include facts most relevant to the users of a class

MillisecondTimerAccurateWithinPlusOrMinusTwoMilleseconds orTimer?

Eliminate naming conflicts by adding description

Rename a Properties candidate to TransactionHistoryProperties



73Wirfs-Brock Associates www.wirfs-brock.com Copyright 200073MRV ChaudronSheet 73

Aspect Orientation

Design & maintain concerns in isolation

Automatically construct implementation

by „weaving‟ concerns



Summary Rational Unified Process

Structure model :, Development model

Behaviour model:

A B

C D

A B C D

Deployment model :

AB

C D

Use cases view

Documents

07 Software Design Heuristics