1. Software Design Principles
“Producing the software blueprint”

2. Objectives
To understand the importance of design in developing quality software
To describe the translation from the requirements analysis model to the design model
To understand the principles that guide proper design of software

3. Designing A House If you are asked to design a house… D W W Kitchen
Room 2 D WC D
Living
Room
Room 1 D W W

4. What Is Design? Explaining the idea/concept of something
Usually with graphical diagrams
With the intention to build from the explanation
The design is a representation of a product or a system with sufficient detail for implementation

5. The Second Task Problem Analysis Design Models Development Solution
Testing

6. Designing Software
From our understanding of the problem, we start building the software
Translate the analysis model into the design model
Map the information from the analysis model to the design representations - data design, architectural design, interface design, procedural design

7. Translation Model Data Object Description
Entity-
Relationship
Diagram
Data Object Description
Process Specification (PSPEC)
Procedural design
Data Dictionary
Data Flow
Diagram
Interface design
State-Transition
Diagram
Architectural design
Control Specification (CSPEC)
Data design

8. Design Principles
Design process should not suffer from “tunnel vision”
The design should be traceable to the analysis model
The design should not reinvent the wheel; Time is short
The design should “minimize intellectual distance” between the software and the problem in the real world

9. Design Principles (Continued)
The design should exhibit uniformity and integration
The design should be structured to accommodate change
The design should be structured to degrade gently.

10. Design Principles (Continued)
Design is not coding, coding is not design
The design should be assessed for quality as it is being created, not after the fact
The design should be reviewed to minimize conceptual errors

11. Design Concepts
Fundamental concepts which provide foundation to design correctly:
Abstraction
Refinement
Modularity
Software Architecture
Control Hierarchy
Structural Partitioning
Data Structure
Software Procedure
Information Hiding

12. Abstraction Identifying important features for representation
There are many levels of abstraction depending on how detailed the representation is required
Data abstraction - representation of data objects
Procedural abstraction - representation of instructions

13. Refinement
Stepwise refinement - top-down design strategy by Niklaus Wirth
Starting at the highest level of abstraction, every step of refinement ‘decompose’ instructions into more detailed instructions
Complementary to abstraction

14. Modularity
Software is divided into separately named and addressable modules
“Divide and conquer” approach - problem is broken into manageable pieces
Solutions for the separate pieces then integrated into the whole system

15. Divide And Conquer S1 S2 P1 P2 S5 P5 P4 P3 S3 S4

16. Software Architecture
Modules can be integrated in many ways to produce the system
Software architecture is the overall structure of the software
The hierarchy of components and how they interact, and the structure of data used by the components
Use of framework models, and possible reuse of architectural patterns

17. Software Architecture Patterns
Recurring pattern help designers reuse successful designs by basing new designs on prior experience.
A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.

18. Why use Design Patterns?
Reuse successful practices.
Not new – recognised that this is something that engineers have done for years.
Improve communication
Step towards a software engineer’s handbook

19. Examples of Software Architecture
Program structure
Batch sequential pattern S3 S2 S4 S5 S1

20. Control Hierarchy
Hierarchy of modules representing the control relationships
A super-ordinate module controls another module
A subordinate module is controlled by another module
Measures relevant to control hierarchy: depth, width, fan-in, fan-out

21. Structure Terminology
Fan-out a b c
Depth d e f g h
Fan-in i
Width

22. Structural Partitioning
Program structure partitioned horizontally and vertically
Horizontal partitioning defines separate branches for each major program function - input, process, output
Vertical partitioning (aka factoring) defines control (decision-making) at the top and work at the bottom

23. Software Procedure Processing details of individual modules
Precise specification of processing, including sequence of events, exact decision points, repetitive operations, and data organization/structure
Procedure is layered - subordinate modules must be referenced in processing details

24. Information Hiding
Information (procedure and data) contained within a module is inaccessible to other modules that have no need for such information
Effective modularity is achieved by independent modules, that communicate only necessary information
Ease of maintenance - testing, modification localized and less likely to propagate

25. References
“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001
“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001

26. Thanks…