TCS2411 Software Engineering2 Lecture Objectives zTo understand the importance of design in developing quality software zTo describe the translation from the requirements analysis model to the design model zTo understand the principles that guide proper design of software
TCS2411 Software Engineering3 Designing A House zIf you are asked to design a house… Room 1 Living Room Kitchen Room 2 D D D D W WW W WC
TCS2411 Software Engineering4 What Is Design? zExplaining the idea/concept of something zUsually with graphical diagrams zWith the intention to build from the explanation zThe design is a representation of a product or a system with sufficient detail for implementation
TCS2411 Software Engineering5 The Second Task Problem Models Solution Analysis Design Development Testing
TCS2411 Software Engineering6 Designing Software zFrom our understanding of the problem, we start building the software zTranslate the analysis model into the design model zMap the information from the analysis model to the design representations - data design, architectural design, interface design, procedural design
TCS2411 Software Engineering7 Translation Model Data Dictionary Entity- Relationship Diagram Data Flow Diagram State-Transition Diagram Data design Architectural design Interface design Procedural design
TCS2411 Software Engineering8 Design Principles zDesign process should not suffer from “tunnel vision” zThe design should be traceable to the analysis model The design should not reinvent the wheel; Time is short zThe design should “minimize intellectual distance” between the software and the problem in the real world
TCS2411 Software Engineering9 Design Principles (Continued) zThe design should exhibit uniformity and integration zThe design should be structured to accommodate change zThe design should be structured to degrade gently.
TCS2411 Software Engineering10 Design Principles (Continued) zDesign is not coding, coding is not design zThe design should be assessed for quality as it is being created, not after the fact zThe design should be reviewed to minimize conceptual errors
TCS2411 Software Engineering11 Design Concepts zAbstraction zRefinement zModularity zSoftware Architecture zControl Hierarchy zStructural Partitioning zData Structure zSoftware Procedure zInformation Hiding Fundamental concepts which provide foundation to design correctly:
TCS2411 Software Engineering12 Abstraction zIdentifying important features for representation zThere are many levels of abstraction depending on how detailed the representation is required zData abstraction - representation of data objects zProcedural abstraction - representation of instructions
TCS2411 Software Engineering13 Refinement zStepwise refinement - top-down design strategy by Niklaus Wirth zStarting at the highest level of abstraction, every step of refinement ‘decompose’ instructions into more detailed instructions zComplementary to abstraction
TCS2411 Software Engineering14 Modularity zSoftware is divided into separately named and addressable modules z“Divide and conquer” approach - problem is broken into manageable pieces zSolutions for the separate pieces then integrated into the whole system
TCS2411 Software Engineering16 Software Architecture zModules can be integrated in many ways to produce the system zSoftware architecture is the overall structure of the software zThe hierarchy of components and how they interact, and the structure of data used by the components zUse of framework models, and possible reuse of architectural patterns
TCS2411 Software Engineering17 Software Architecture Patterns zRecurring pattern help designers reuse successful designs by basing new designs on prior experience. zA designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.
TCS2411 Software Engineering18 Why use Design Patterns? zReuse successful practices. yNot new – recognised that this is something that engineers have done for years. zImprove communication zStep towards a software engineer’s handbook
TCS2411 Software Engineering20 Control Hierarchy zHierarchy of modules representing the control relationships zA super-ordinate module controls another module zA subordinate module is controlled by another module zMeasures relevant to control hierarchy: depth, width, fan-in, fan-out
TCS2411 Software Engineering21 Structure Terminology ghed i f abc M Fan-out Fan-in Width Depth
TCS2411 Software Engineering22 Structural Partitioning zProgram structure partitioned horizontally and vertically zHorizontal partitioning defines separate branches for each major program function - input, process, output zVertical partitioning (aka factoring) defines control (decision-making) at the top and work at the bottom
TCS2411 Software Engineering23 Software Procedure zProcessing details of individual modules zPrecise specification of processing, including sequence of events, exact decision points, repetitive operations, and data organization/structure zProcedure is layered - subordinate modules must be referenced in processing details
TCS2411 Software Engineering24 Information Hiding zInformation (procedure and data) contained within a module is inaccessible to other modules that have no need for such information zEffective modularity is achieved by independent modules, that communicate only necessary information zEase of maintenance - testing, modification localized and less likely to propagate
TCS2411 Software Engineering25 References z“Software Engineering: A Practitioner’s Approach” 5th Ed. by Roger S. Pressman, Mc-Graw-Hill, 2001 z“Software Engineering” by Ian Sommerville, Addison-Wesley, 2001
Your consent to our cookies if you continue to use this website.