c++ programs simple program statement execution c++ statements name spaces
Post on 14-Dec-2015
224 Views
Preview:
TRANSCRIPT
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
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
top related