Software design

What are some basic design principles and how can you measure design quality?

The software landscape When systems were not large enough to merit an

explicit design phase, software was considered to encompass all of the forms that were concerned with generating “executable binary code” that was intended for execution on a single machine

The structure of the system was largely fixed when the code was compiled and so the idea(s) of the designer were directed towards producing a single monolithic unit of binary code

Systems are now large and typically distributed across several machines

The designers now have to decide how functionality and data would be partitioned or shared between machines, the form of communication mechanisms to employ, and the likely performance effects of these choices

Mim

ari Y

ap

ı

Java, EJB, J2EE

App Servers

Teknolojiler

MicrosoftCOM, MTS,

MQ, ASP

IBMAS400

Notes, MQ

WebHTML, XML

e-mail

DatabasesData

warehousing

Çalışma Alanı

Lojistik

Uygulama Alanları

Müşteri İlişkileri Yönetimi

KanalEntegrasyonu

İşlemKayıtları

Tedarik Zinciri Yönetimi

ATM, ADSLWAP

TCP/IP

Windows NTLinux, UNIX

Tandem

Kargo

Sü

reçle

r

Which Technology?

Fatura

İrsaliye

Operasyon

Satış

Tek giriş Arayüzler (XML, HTTP..)

Uyarlama, sürüm yönetimi

WebSunucu

E-MailSunucu

IVR Sunucu

ÇağrıMerkeziSunucu

WAPsunucu

OR

AC

LE

ER

PMüşteri

Bireysel

İş ortağı

Tedarikçi

Çalışanlar

Intranet

Internet

PSTN

Veri madenciliğiKab

losu

z

E S

A S

Veritabanı

YerelVeritabanı

CRM

Software design The process of design is divided into two

distinct phases Architectural or logical design: designer develops a highly

abstract model of the system in which only externally visible properties of the model elements are included; this black-box partitioning is largely concerned with the nature and form of the problem and is less strongly influenced by the eventual form that will be adopted for its solution

Detailed or physical design: the abstract “chunks” of the problem that were identified in the first phase are mapped on to technologically-based units turning the black-box into a white-box

Software design Following properties of software make the

design process a challenging task: Complexity: no two parts of a system are alike and it

may possess very many states during execution Conformity: software is expected to conform to the

standards imposed by other components Changeability: software suffers constant need for

change Invisibility: this constraints our ability to

conceptualize the characteristics of software and also hinders communication among those involved with its development

Measuring design quality (1) “When you can measure what you are

speaking about, and express it in numbers, you know something about it, but when you cannot measure it, when you cannot express it numbers, your knowledge is of a meager and unsatisfactory kind.” (Lord Kelvin)

Ideas about measurement originally emerged largely within a community of scientists and engineers who were seeking to capture ideas about physical properties such as mass, length, velocity, etc.

The scales used for such properties are ratio scales; they possess well defined intervals and a zero point

Measuring design quality (1) Once we move away from this

context, we often are limited Many of the properties of interest to

us are more likely to be measured using an ordinal scale

“Measurement is concerned with capturing information about the attributes of entities.” (Fenton and Pfleeger, 1997)

Measuring design quality (2)

Role Definition ExampleQuality Concept

Abstract ideas about what constitutes “good” and “bad” properties of a system, and which will need to be assessed by the designers when making decisions about design choices

Complexity

Measurable characteristic

Provide a set of measurable (or at least, identifiable) characteristics of the design entities and so provide mappings between the abstract idea of a property and the countable features of the actual design (and therefore effectively correspond to the general concept of a metric)

McCabe’s Cyclomatic Complexity

Measure Identifying lexical features of a representation that will need to be counted in order to obtain some form of values for the metrics

Counting nodes and edges

Consider the building architecture (1) Structure

An architecture defines the arrangement of structural elements

Relates to form, function and characteristics Architectural style is the underlying structuring

principle and philosophy

Space Construction is both a physical and

spatial transformation of a pre-existing situation

Consider the building architecture (1) Boundaries

Building has a logical aspect too Separates notions of the “inside” and

“outside” Architecture addresses the

complex whole of interrelationship between such domains

Consider the building architecture (2)

Neighborhoods as Domains The logical structure of an architecture is based

on spatial domains Buildings, rooms, etc.

And connection domains between them Streets, alleys, hallways, corridors, doors, etc.

And how they are configured as a whole Logical coupling and cohesion

Consider the building architecture (2) Neighborhood Boundary

The strength of the boundary is essential to a neighborhood. If the boundary is too weak the neighborhood will not be able to maintain its own identifiable character

Encourage the formation of a boundary around each neighborhood, to separate it from the next door neighborhoods. Form this boundary by closing down streets and limiting access to the neighborhood

Place gateways at those points where the restricted access paths cross the boundary; and make the boundary zone wide enough to contain meeting places for the common functions shared by several neighborhoods

Example

Consider the squares in the grid to be spaces; the blue line to be the walls. At B3 is an external entrance; use exactly 8 other internal entrances to connect the rooms so that every room is accessible

The solution you will come up with will have same number of external and internal openings the difference being the location of cell entrances But this radically changes the patterns of movement through the buildings Which offers more opportunities for “private” space?

A B C

3

2

1

Dependencies

Consider rooms A2, B2 and C2 in each of these configurations and the routes by which they can be reached.

Which other rooms is each directly dependent on? Which other rooms is each indirectly dependent upon? Which other rooms directly depend on A2, B2 and C2? Are there any parallels with software?

A B C

3

2

1

Software and space Software does not deal with physical

spaces But space is not merely a physical

construct in architecture of the built environment; it also embodies notions of logical and social spaces

We can consider modules, packages, components, etc. to occupy virtual spaces in software And connectors to be access paths to these

spaces which make them interdependent

Object-oriented software construction Objects and Classes are behavioral

abstractions We separate objects in Class A from those in

Class B on the basis of their different behavior But in the machine an object instance is a

data abstraction A pointer or reference is returned to the

object’s data variables only Objects are therefore logical abstractions

Don’t really exist at the machine level

Responsibility driven design (1) Designing object systems involves

Identifying behavioral abstractions (Object Types)

Assigning them responsibilities Mapping object types to object classes

Enforcing encapsulation and information hiding Creating interfaces so that client objects know how to

request executable behavior from server objects Turning responsibilities into operations

And the methods that implement them Turning collaborating classes into data

members to hold object IDs

Responsibility driven design (2) A well established technique for

responsibility-driven design is CRC cards 6”x4” index cards

Divided into 3 fields (Class, Responsibility, Collaborators)

One for each candidate object Used to role play scenarios to see if

responsibilities have been distributed properly Cheap and fun way to validate the dynamic

behavior of object systems prior to coding

Encapsulation Encapsulation is the hiding of all design

decisions that the client doesn’t need to know about. Typically this includes: Data structures Collaborating classes and objects Methods Private operations, etc.

An object is therefore a sort of protected virtual space Like a neighborhood as discussed before

Interfaces (1) Ideally we would like the classes and objects

to be completely decoupled from each other But references (object IDs) are needed otherwise

programs won’t work Collaboration requires some objects to know how

to call other objects and request their behavior Therefore, interfaces are needed

Compare with gateways and access paths in neighborhood boundary

In Java a special interface construct is provided In C++ an abstract class can be used as a protocol

class to the same effect

Interfaces (2) Interfaces should be designed to be stable

Operation names and parameters of abstract behaviors

Implementation can therefore vary without the client object needing to know Different methods, even different collaborating

objects can handle the request for executable behavior

Client only needs guarantee that the behavior will be performed correctly in response to the request (message)

Note: A class can support 1 or many interfaces

Significance of interfaces for architecture

An interface can be thought of as an access path or gateway to an encapsulated space Space can be an object instance, a class, a package

or any logical computational component We need to narrow interface bandwidth

between spaces An interface also implies a dependency

If Class A holds a reference to Class B it is dependent upon it

If the Interface is physically separate from the class that realizes it and the reference is to the interface the clients only dependent on the interface (recommended)

Interfaces can form a “scaffolding” for the system

Dependency heuristics Minimize all dependencies As far as possible make dependencies

unilateral i.e. one way

Only use bilateral or cyclical dependencies if classes are designed to work together in all circumstances In which case package them together as

components

Levelization Levelization is desirable

Assuming a bottom level 0, each component in a dependency hierarchy can be assigned a unique level number

Implies a structure which is a directed acyclic graph (DAG)

In “good” OO system structures Abstract, stable (unchanging) classes tend to be at or

near level 0 Concrete, volatile (often changing) classes tend to be

at the highest levels We want to minimize the number of classes dependent on

changeable classes

Analyzing structure in OO systems (1) Simple measurements can be used to measure the

structural quality of OO systems Abstractness

The total number of abstract classes (and interface types in Java) divided by the total number of classes and types. The measurement range is 0..1

Stability/Volatility The number of efferent (outside) couplings (Ce) divided by the number of

efferent couplings plus the number of afferent (inside) couplings (Ce + Ca), range is 0..1

Ce is the number of classes outside a package that classes inside the subject package directly depend on

Ca is the number of classes outside the package that depend on classes inside the subject package

Relational Cohesion Relational cohesion (H) is the total number of internal relationships (R) +

1 divided by the total classes within the package (N) H = (R + 1) / N

Analyzing structure in OO systems (2)

All of these metrics can be arrived at by mapping class relationships on a spreadsheet

The values of abstractness, stability can be plotted on a stability graph

1

0 1

Abstractness

Volatility

Distance from main sequence The Main Sequence is idealized by the line

(A + S = 1) Where A = abstractness, S = stabilty

Any package’s distance from the main sequence can be calculated by the formula D = |(A + S – 1)/SQRT(2)|

This means ignore sign, range is 0..0.7 Can be normalized to a range 0..1 by

D’ = |(A + S – 1)| The value of D or D’ closer to 0 is better

Key points Objects are logical structures to which

responsibilities are allocated in design Objects can therefore be thought of as architectural

spaces As can classes, components and packages

We can apply the lessons of neighborhood boundary Use encapsulation, interfaces to minimize dependencies

We can measure the quality of a structure with simple dependency metrics

References D. Budgen, Software Design,

Addison-Wesley, 2003. R. Wirfs-Brock and A. McKean,

Object Design: Roles, Responsibilities and Collaborations, Addison-Wesley, 2003.