Software Design Principles “Producing the software blueprint” 1
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 2
Designing A House • If you are asked to design a house… D W W Kitchen Room 2 D Living Room D W WC D Room 1 W 3
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 4
The Second Task Analysis Design Problem Models Development Testing Solution 5
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 6
Translation Model Entity. Relationship Diagram Data Flow Diagram Procedural design Data Dictionary Interface design State-Transition Diagram Architectural design Data design 7
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 8
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. 9
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 10
Design Concepts Fundamental concepts which provide foundation to design correctly: • Abstraction z. Structural • Refinement Partitioning • Modularity z. Data Structure • Software Architecture z. Software Procedure • Control Hierarchy z. Information Hiding 11
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 12
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 13
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 14
Divide And Conquer S 1 S 2 P 1 P 2 S 5 P 4 P 3 S 4 15
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 16
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. 17
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 18
Examples of Software Architecture S 1 Batch sequential pattern Program structure S 2 S 1 S 3 S 2 S 4 S 5 S 3 19
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 20
Structure Terminology M Fan-out a b c Depth d e f g h Fan-in i Width 21
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 22
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 23
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 24
References • “Software Engineering: A Practitioner’s Approach” 5 th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 • “Software Engineering” by Ian Sommerville, Addison-Wesley, 2001 25
Скачать презентацию Software Design Principles Producing the software blueprint 1
54ccd0995029a86996c22f8429ccdefc.ppt