Software Engineering

Software Engineering Key design concepts Design heuristics Design practices

Key design concepts • Managing complexity: • 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

Key design concepts • Managing complexity (cont): • Innefective design results from • A complex solution to a simple problem • A simple, incorrect solution to a complex problem • An inappropriate, complex solution to a complex problem

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 systemConsider 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 Application level classes Data storage 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?

Software Engineering