C++ Programs

Simple Program Statement Execution C++ Statements Name Spaces

Simple Program

Accidental versus Essential features e.g. Engine is an essential feature in a car,

whereas a sound system is an accidental feature

Software contains essential and accidental sources of complexity (and hence of difficulties): Minimise essential complexities Eliminate as much as possible of accidental

complexities

Simple Program

Program Features Comments:

// /* */

Preprocessor directives: # Libraries: <..>, “ “ Name spaces: using... Program: main(){ } Variable Declaration ;

Key design concepts

Managing complexity (cont): “There are two ways of constructing a

software design: one way is to make it so simple that there are obviously no deficiencies, and the other is to make it so complicated that there are no obvious deficiencies.”

C. A. R. Hoare

Key design concepts

Managing complexity is the key to success. It should be regarded as the foundational activity and primary goal in software design.

General guidelines can be given for managing complexity. There is no generic formal process to manage complexity.

Key design concepts

Desirable characteristics of a design: a good design should balance the following (sometimes competing) characteristics Minimal complexity – simple and easy

to understand design is better than “clever” design. Good design lets you safely ignore most other parts of the program when analysing one specific part

Key design concepts

Desirable characteristics of a design: Ease of maintenance – the maintenance

programmer should be the target audience of a good design

Loose coupling – connections among different parts of a program should be minimised. Loose coupling minimises work during integration, testing and maintenance

Key design concepts

Desirable characteristics of a design: Extensibility – the system should admit

alterations without needing to change the underlying structure. Most likely changes should cause the least trauma

Reusability – pieces of the system being designed should be reusable in other systems

Key design concepts

Desirable characteristics of a design: High fan-in – many classes should use a

given class. High fan-in implies good use of utility classes at lower levels in the system

Low fan-out – each single class should use a low number of other classes (typically, less than seven)

Key design concepts

Desirable characteristics of a design: Portability – a system should be

designed to be portable Leanness – a system should not have

more in it than what is absolutely necessary

Stratification – a system should be designed in such way as to allow complete readings at different levels of abstraction

Key design concepts

Desirable characteristics of a design:

Standard techniques – exotic design and implementation hinders readability and clarity. Standardised, common approaches are better than “clever” ones

Key design concepts

Levels of design: Level 1: software system

Consider the system as a whole Level 2: subsystems or packages

How to partition system into subsystems How to connect subsystems

Key design concepts

Levels of design: Level 2: subsystems or packages

(cont)User interface Graphics

Data storageApplication

level classes

Business rules

Enterprise-level tools

Key design concepts

Levels of design: Level 2: subsystems or packages

(cont)User interface Graphics

Data storageApplication

level classes

Business rules

Enterprise-level tools

Key design concepts

Levels of design: Level 2: subsystems or packages

(cont) Common subsystems:

Business rules User interface Database access System (platform) dependencies

Key design concepts

Levels of design:

Level 3: division of subsystems into classes

Level 4: division of classes into routines

Level 5: internal routine design

Design heuristics

Find real-world objects: Identify the objects and their attributes Determine what can be done to each

object Determine what each object is allowed to

do to other objects Determine the parts of each object that

will be visible to other objects Define each object’s interfaces

Design heuristics

Form consistent abstractions:

Encapsulate implementation details:

Design heuristics

Use inheritance to simplify design Use information hiding to enforce

modularisation Hide complexity Hide sources of change so that, when

change occurs, effects are localised Identify and isolate areas likely to

change

Design heuristics

Keep coupling loose: Coupling criteria:

Size: few parameters are better than many; few public methods are better than many

Visibility: explicit parameter passing is better than access to global variables

Flexibility: the more easily other modules can call a module the better

Design heuristics

Keep coupling loose: Kinds of coupling:

Simple-data-parameter: all data passed between modules are of primitive data types and all data is passed through parameter lists

Simple-object: an object instantiates another Object-parameter: one object requires

another the passing of a third object Semantic: one module must know the

internals of the other

coupling

Design heuristics

Look for common design patterns Other heuristics

Keep intra-module cohesion strong Build hierarchies Formalise class contracts Assign responsibilities to modules Design for test Choose binding time carefully

Design heuristics

Other heuristics (cont) Build central points of control Consider using brute force Use diagrams Keep your design modular

Design practices

Iterate through candidate designs Divide and conquer Divide and conquer II: incremental

refinement Iterate between Top-down and

Bottom-up approaches Do experimental prototyping Exercise collaborative design

Design practices

Should your design be more detailed? Should it be less detailed?

Should your design be more formal? Should it be less formal?

Should your design be “more” documented? Should it be “less” documented?