07 Software Design Heuristics

Software Design Guidelines
Michel Chaudron
Advanced Software Engineering 2011
Agenda
Design guidelines
Architectural Styles
MRV Chaudron
Sheet 2
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.

3
MRV Chaudron
Sheet 3
Why Care about Quality during Design?

Cost of Defect Repair Cost of repair increases exponentially As a project progresses, more and more work depends on earlier decisions.
Defects should be eliminated as soon as possible after their introduction

MRV Chaudron
Sheet 4
Architecture is making decisions

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.
Grady Booch
You will not have all information available
You will make mistakes, but you should learn from them
There is no objective measure for goodness
MRV Chaudron
Sheet 5
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'
Churchman, C. West, "Wicked Problems", Management Science, Vol. 14, No. 4, December 1967. Guest Editorial
Design of Software Architecture

Understand the Domain User Requirements Functional Requirements Group Functionality in subsystems Domain Requirements
Extra-Functional Requirements S.M.A.R.T.

Design approach for realizing extra-functional quality properties
Identify Trade-offs Sensitivity points
Design Metrics
Synthesize
UML, Views
MRV Chaudron
Select Architectural Style Reference Architecture Architecture Tactics
Model/Describe Analyze refine

7
RBD, QN, RMA, Sheet 7 ATAM, prototype
Design Principles
Simplicity Separation of Concerns Information Hiding Modularity Keep things that belong together in a single place
How to assess?
MRV Chaudron Sheet 8
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.
David Parnas 1941-
Goal: Isolate change Means: Information hiding, minimizing dependencies
The KWIC Problem

In his paper of 1972, Parnas proposed the following problem:
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.
D. L. Parnas, On the criteria to be used in decomposing systems into modules, Communications of the ACM, vol. 15, pp. 1053-1058, Dec.1972.
Parnas shows that different problem decompositions vary greatly in their ability to withstand design changes. Among the changes he 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 the alphabetization 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 several words.

Clouds are white. Ottawa is beautiful.
Output: a sorted list of all orderings of each input string.

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 different solutions for the same set of requirements
17
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 these boxes and arrows can add significant confusion to a software design process and the resulting design Oh, thats 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
19
Information hiding

each module has a secret design involves a series of decision: for each such decision, wonder who needs to know and who can be kept in the dark information hiding is strongly related to

abstraction: if you hide something, the user may abstract from that fact coupling: the secret decreases coupling between a module and its environment cohesion: the secret is what binds the parts of the module together
www.wileyeurope.com/college/van vliet 20
2008 John Wiley & Sons Ltd.
Faade pattern
Client classes
Faade
Note the effect on the fan-in/coupling of the component

MRV Chaudron
Sheet 21
21
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
22
Example Design Principles

Telecom Domain:
Separate the encoding/decoding of a message from the handling of a handle message, so
decode1 ; decode2 ; decode3 ; action1 ; action2 decode1 ; action1 ; decode2 ; action2 ; decode3
encode/ decode handle & encode/ decode

23
And not
MRV Chaudron
Sheet 23
Design Principle 1: Divide and conquer
Trying to deal with something big all at once is normally much harder than dealing with a set of smaller things
Each
individual component is smaller, and therefore easier to understand can be replaced or changed without having to replace or extensively change other parts. people can work on separate parts individual software engineer can specialize
24
Parts
Separate An
MRV Chaudron
Sheet 24
Ways of dividing a software system

A system is divided up into
Layers A
& subsystems
subsystem can be divided package is divided up into classes class is divided up into methods
up into one or more packages

A A
MRV Chaudron
Sheet 25
25
Layering
Goals: Separation of Concerns, Abstraction, Modularity, Portability Partitioning 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
MRV Chaudron
3 2 1 0
Sheet 26
26
MRV Chaudron
Sheet 27
27
Layering into levels of abstraction

Hearsay: speech understanding
Sentences Phrases Words Syllables Phonemes Acoustic waveform
MRV Chaudron
Sheet 28
28
Layering in Client / Server

Presentation layer Dialogue with users Application logic Application for individual user
presentation logic application logic business logic data management Unit of change Unit of responsibility Unit of deployment
29
client
Business logic
Logic for processing across users, divisions Data management Storage of data
MRV Chaudron
server
Sheet 29
Example 3-tier System

Diagram MRV Chaudron from Sheet 30 Wikipedia, 2007
30
Layering in Computer Networks: OSI & Internet

Application
Presentation Session Transport
Network
Data Link Physical
Picture from Jeremy Bradbury, Queens Univ. Canada
MRV Chaudron
Sheet 31
31
A Component-based Reference Architecture for Computer Games

(E. Folmer, 2007)
specific generic
MRV Chaudron
Sheet 33
33
What is Modularity?
We can see it via a Design Structure Matrix (DSM)
MRV Chaudron
Sheet 36
36
What is a dependency?
Component A requires B for it to work

Functional
coupling
Run-time
A change in module B requires change in module A

Implementation
coupling Typically requires: re-testing A & B

Development-time
MRV Chaudron
Sheet 37
37
Dependencies in the code

There
A
is coupling between two classes A and B if:

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
MRV Chaudron
Sheet 38
38
Dependency: Coupling
Coupling is the degree of interdependence between modules
high coupling
low coupling
Design Principle: Reduce coupling where possible

MRV Chaudron
Sheet 39
39
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 enhances
robustness
Page-Jones, M. 1980. The Practical Guide to Structured Systems Design. New York, Yourdon Press, 1980.
MRV Chaudron
Sheet 40
40
Example: Before Refactoring
Coupling Saat 7
Dynamic Coupling 10
Method Calls 25
Stat.-Filter
Stat.Calculator Analyser DB-Checker DB-Filler DB-Creator
0
0 0 0 0 0
3
3 4 2 5 2
0
0 0 0 0 0
Parser
MRV Chaudron
3
42
Sheet 42
Example: After Refactoring
Dynamic Coupling Coupling

Saat Stat.-Filter 2 1 0 3 0 1 0 0 2 2 2 3 1 4 1 1
Method Calls
2 1 0 12 0 10 0 0
43
Stat.Calculator
Analyser DB-Checker DB-Filler DB-Creator Parser
MRV Chaudron
Sheet 43
MetricView: Graphical Tool for Developer Feedback

http://www.win.tue.nl/empanada/metricview/
UML model Analysis Tool Quality Metrics/Rules

Completeness Consistency MRV Chaudron Conventions Sheet 44
Visualization of model + metrics
MetricView video
http://www.win.tue.nl/empanada/metricview/
http://www.youtube.com/watch?v=G3HJ_QR9EG4
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

number of calls between components
for as short a time as possible

minimize
Ref: Component are from Mars Chaudron & De Jong

MRV Chaudron
Sheet 46
46
Dependency: Cohesion
Cohesion is concerned with the interactions within a module
high cohesion
low cohesion
Heuristic:
Keep things together that belong together. High cohesion within a module is good
Coupling and Cohesion
Coupling is the degree of interaction between modules. Cohesion is a measure of the coherence of a module amongst the pieces of that module.
You want high cohesion and low coupling
49
How to reduce coupling in this design?
MRV Chaudron
Sheet 50
50
Faade pattern
Client classes
Faade
Note the effect on the fan-in/coupling of the component

MRV Chaudron
Sheet 51
51
Facade pattern
Bedoeling
Verschaf een uniforme interface tot een (verzameling interfaces van een) subsysteem
Motivatie

Subsystemen reduceren de complexiteit Belangrijk ontwerpdoel: minimaliseren van de communicatie en afhankelijkheden tussen subsystemen Eenvoudige, uniforme interface tot subsysteem is wenselijk Individuele interfaces moeten beschikbaar blijven
Types of Coupling
Data coupling
data from one module is used in another two modules use the same data type
Data type coupling
Control coupling
actions one module are controlled by another module (switch)
considered worse
Content coupling
a module refers to the internals of another module Bind to interface

of components
MRV Chaudron
Sheet 55
55
Highly coupled classes belong in the same component.
When two classes collaborate frequently, this is an indication they should be in the same domain component to reduce the network traffic between the two classes. This is especially true when that interaction involves large objects, either passed as parameters or received as return values. By including them in the same domain component you reduce the potential network traffic between them. The basic idea is that highly coupled classes belong together.
From Scott Ambler

56
Minimize the size of the message flow between components.
Client/server classes belong in a domain component, but there may be a choice as to which domain component they belong to. This is where you need to consider issues such as the information flow going into and out of the class. Communication within a component will often be simple message sends between objects in memory, communication between components may require an expensive marshalling effort in which a message and its parameters are converted to data, transmitted, and then converted back into a message again.
From Scott Ambler
57
Design Structure Matrix Map of a Laptop Computer

Drive 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 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 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
Main 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
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
Graphics controller on Main Board or not? If yes, screen specifications change; If no, CPU must process more; adopt different interrupt protocols
MRV Chaudron
Sheet 58
58
Design Structure Matrix Map of a Modular System

Design Rules . x x x . x x . x x x x x x x x x x x x x x Main 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 x x x x x x x . x . x Design Rules Task Group
Drive 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 . x x x . x x x x x x x x x x . x x .
Hidden Modules many Task groups
LCD 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 . x x x x x x . x x x x x x x . x x x x x x
P ackaging
System Testing & Integration
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 System x Integration and Testing x Task Group .
MRV Chaudron
Sheet 59
59
DSM of Mozilla before and after redesign

number of files
2.4 dependencies per KSLOC
1.3 dependencies per KSLOC
Formerly Mozilla was the commercial Netscape Navigator, then released into open source.
From: Exploring the Structure of Complex Software Designs: An Empirical Study of Open Source and Proprietary Code, Alan MacCormack, John Rusnak, Carliss Baldwin, MRV Chaudron Sheet 60 Harvard Business School, draft October 1st 2005
60
Conclusions

Simplicity Separation of Concerns
Information Hiding
Low Coupling, High Cohesion Layering, Modularity
61
9.9 Difficulties and Risks in Design Like modelling, design is a skill that requires 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

62
MRV Chaudron
Sheet 62
Difficulties and Risks in Design
It requires constant effort to ensure a software systems design remains good throughout 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
MRV Chaudron
Sheet 63
63
Inheritance vs. Composition
The two most common techniques for reusing functionality in object-oriented systems are class inheritance and object composition Class inheritance defines the implementation of one class in terms of anothers implementation. With inheritance the internals of parent classes are often visible to sub-classes (white box). In object composition new functionality is obtained by assembling or composing objects to get more complex functionality. Internal details of objects are not visible, objects appear as black boxes.
MRV Chaudron
Sheet 64
64
Pros and Cons of Inheritance
Pros: Class inheritance is defined statically at compile-time and is straightforward to use, since its supported directly by the programming language. Class inheritance makes it easier to modify the implementation being reused. Cons: You can not change the implementations being inherited at run-time. Inheritance exposes as subclass to details of its parents implementation. Any change in the parents implementation will force the subclass to change. One cure is to only inherit from abstract classes since they provide little or no implementation.
MRV Chaudron
Sheet 65
65
Pros and Cons of Composition

Composition is defined at run-time through objects acquiring references to other objects. Composition requires objects to respect each others interface. Because objects are accessed solely through their interfaces we dont break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Because an objects implementation is written in terms ob object interfaces, there are substantially fewer implementation dependencies.
MRV Chaudron
Sheet 66
66
Inheritance vs. Object Comp.
Favoring object composition over class inheritance helps you keep each class encapsulated 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 interrelationships instead of being defined in one class.
MRV Chaudron
Sheet 67
67
Chapter 9: Architecting and designing software
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
Lethbridge/Laganire 2005
ESE 4.68
Assigning Responsibilities ...
>
Keep information about one thing in one place

if multiple objects need access to the same information
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
1.
>
Share responsibilities among related objects

break down complex responsibilities
Lethbridge/Laganire 2005
ESE 4.69
Characterizing Classes
according to Rebecca J. Wirfs-Brock, IEEE Software, March/April 2006 Information holder: an object designed to know certain information and provide that information to other objects.
Structurer: an object that maintains relationships between objects and information about those relationships. Complex structurers might pool, collect, and maintain groups of many objects; simpler structurers 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 on demand. Controller: an object designed to make decisions and control a complex task.
Coordinator: an object that doesnt make many decisions but, in a rote or mechanical way, delegates work to other objects. The Mediator pattern is one example.
Interfacer: an object that transforms information or requests between distinct parts of a system. The edges of an application contain user-interfacer objects that interact with the user and external interfacer objects, which communicate with external systems. Interfacers also exist between subsystems. The Facade pattern is an example of a class designed to simplify interactions and limit clients visibility of objects within a subsystem. Lethbridge/Laganire 2005 ESE 4.70
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 Authenticator Choose a name that suits a role Objects named Manager organize and pool collections of similar objects AccountManager organizes Account objects
Wirfs-Brock Associates www.wirfs-brock.com Copyright 2000 71
Guidelines for Naming Inventions

Choose names that dont limit behavior options Account or AccountRecord? Recordinformation or facts set down in writingan informational object Accountsounds livelieran 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 or Timer? Eliminate naming conflicts by adding description Rename a Properties candidate to TransactionHistoryProperties
Wirfs-Brock Associates www.wirfs-brock.com Copyright 2000 72
Aspect Orientation
Design & maintain concerns in isolation
Automatically construct implementation

by weaving concerns
Wirfs-Brock Associates MRV Chaudron

Sheet 73
www.wirfs-brock.com
Copyright 2000
73
73
Summary Rational Unified Process
Structure model :, A C B D
Development model
Use cases view Deployment model : A B C D
Behaviour model : A B C D
Wirfs-Brock Associates MRV Chaudron

Sheet 74
www.wirfs-brock.com
Copyright 2000
74
74

07 Software Design Heuristics

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

07 Software Design Heuristics

Uploaded by

Copyright:

Available Formats

Software Design Guidelines

Advanced Software Engineering 2011

Advanced Software Engineering 2011

Different aspects of design

The various features of classes.

interface design Algorithm design:

The design of communications protocol.

Why Care about Quality during Design?

Advanced Software Engineering 2011

Defects should be eliminated as soon as possible after their introduction

Advanced Software Engineering 2011

Architecture is making decisions

You will not have all information available

Advanced Software Engineering 2011

Software design is a wicked problem

There is no definite formulation

There is no stopping rule/test

Every wicked problem is essentially novel and

Every solution to a wicked problem is a 'one shot

Advanced Software Engineering 2011

Design of Software Architecture

Extra-Functional Requirements S.M.A.R.T.

Select Architectural Style Reference Architecture Architecture Tactics

Model/Describe Analyze refine

RBD, QN, RMA, Sheet 7 ATAM, prototype

Advanced Software Engineering 2011

Advanced Software Engineering 2011

David Parnas 1941-

Goal: Isolate change Means: Information hiding, minimizing dependencies

MRV Chaudron Sheet 9

Advanced Software Engineering 2011

The KWIC Problem

Advanced Software Engineering 2011

Advanced Software Engineering 2011

Input: strings, each of which consists of several words.

Output: a sorted list of all orderings of each input string.

Advanced Software Engineering 2011

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

Advanced Software Engineering 2011

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

Advanced Software Engineering 2011

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

Advanced Software Engineering 2011

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

Advanced Software Engineering 2011

MRV Chaudron Sheet 17

Advanced Software Engineering 2011

Imprecision in design discussions

Advanced Software Engineering 2011

Basics of Information Hiding

MRV Chaudron Sheet 19

Advanced Software Engineering 2011

2008 John Wiley & Sons Ltd.

Advanced Software Engineering 2011

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

Advanced Software Engineering 2011

Separate What from How

MRV Chaudron Sheet 22

Advanced Software Engineering 2011

Example Design Principles

encode/ decode handle & encode/ decode

Advanced Software Engineering 2011

Design Principle 1: Divide and conquer