lecture5Spring2011 - CSc 131 CSc Computer Software...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: CSc 131 CSc Computer Software Engineering Spring 2011 Software Design Software Design Concepts and Principles Design Software Design Software – Goal: To produce a model or representation To that will later be built that Software design is the first of three Software technical activities (Design, Implementation, and Test) Implementation, Where Do We Begin? Where modeling Prototype Spec Models Documentation Design Software Design Model Software Functional model Behavioral model Information model Data design Design Architectural design Code Other requirements Procedural design Program modules Test Integrated & validated software Software Design Software Design – Top-down approach: breaking a system into a set Top-down of smaller subsystems of – Object-oriented approach: identification of a set of Object-oriented objects and specification of their interactions objects – UML diagrams are a design tool to illustrate the UML interactions between interactions Classes Classes and external entities Design Models Design Analysis models are used to build design Analysis models. models. Four design models required to build the Four product: product: – Data design – Architectural design – Interface design – Component / Procedural design Data Design Data Transform the model created during Transform analysis into the data structures that will be required to implement the software. be ERD and Data Dictionary are used to ERD build this model. build Architectural Design Architectural Objective is to develop a modular Objective program structure and represent the control relationships between modules. modules. DFDs are used for this design DFDs Interface Design Interface Describes how the software communicates Describes within itself, with other systems and with users. users. DFDs my be used to develop the interface. Component / Procedural Design Component After data & program structure have After been established, it become necessary to specify procedural detail without ambiguity without – Graphical design notation Flow-charts (draw sequence, ifthen, selection, repetition) then, – Program Design Language(PDL) = Program pseudocode Software Design Fundamentals Software Good design is not accomplished by Good chance chance Fundamental concepts provide Fundamental the framework for “getting it right” the Design Fundamentals Design Abstraction Refinement Modularity Control Hierarchy Information Hiding Design Fundamentals Design – Abstraction Levels of detail/language used to describe a problem Design Fundamentals (cont.) Design Refinement Top-down strategy Stepwise Refinement open reach for knob; walk to door; turn knob clockwise; open door; repeat until door opens walk through; Modular Design Modular Software is divided into separately Software named components (Modules) named Benefits Reduces complexity Facilitates change Easier implementation Control Hierarchy Control – Control Hierarchy also called Control Program Structure Program Organization of modules that Organization implies a hierarchy of control implies It does not represent procedural It aspects of software. aspects Structural Partitioning Structural Horizontal Partitioning Defines separate branches for each major Defines program function. program Reasons & Benefits to reduce module size to avoid duplication of a function in to more than one module more to provide more reusable modules to simplify implementation Vertical Partitioning Vertical Vertical Partitioning (factoring) Implies that control (decision making) should be distributed top-down in the program. Top level should perform control function and do little processing work. Lower level module performs all types of input /output, and computation tasks Change in the low level modules are less likely to cause side effects Information Hiding Information module • algorithm algorithm Controlled • data structure data IInterface • details of external interface details • resource allocation policy resource clients "secret" a specific design decision Why Information Hiding? Why Reduces the likelihood of “side effects” Limits the global impact of local design decisions Emphasizes communication through controlled interfaces Discourages the use of global data Leads to encapsulation—an attribute of high quality design Results in higher quality software The greatest benefit is when modifications are required (during testing & maintenance); less propagation of errors Functional Independence Functional “Design software so that each module addresses a specific sub-function of requirements and has a simple interface when viewed from other parts of the program structure” – Benefits Easier to develop Easier to maintain & test Measures of Independence Coupling Cohesion Coupling Coupling Coupling indicates the degree of Coupling interdependence between two modules modules Aim for low coupling by eliminating unnecessary relationships reducing the number of necessary reducing relationships relationships easing the “tightness” of necessary easing relationships relationships Principles of Coupling Principles Narrow is better than Broad Direct is better than Indirect Local is better than Remote Obvious is better than Obscure Flexible is better than Rigid Types of Coupling Types No Direct Coupling Stamp Coupling Data Coupling Low External Control Coupling Coupling Spectrum Content Common Coupling High Good A measure of the interdependence among software modules Data: Simple argument passing Data: Simple argument passing Stamp: : Data structure passing Stamp Data structure passing Control: : One module passes the element of control (flag) to another. Control One module passes the element of control (flag) to another. External: Modules are tied to environment external to software (device) External: Modules are tied to environment external to software (device) Common: : Modules have access to the same global data. Common Modules have access to the same global data. Content: : One module directly references the content of another Content One module directly references the content of another Advantages of Low Coupling Advantages The fewer connections between modules, the less chance of a defect in one causing a defect in another The risk of having to change other modules as a result of changing one module is reduced The need to know about the internals of other modules is reduced when maintaining the details of other modules. Some coupling is needed…! Cohesion Cohesion Is the measure of the strength of functional Is relatedness of elements within a module relatedness “Element” means an instruction, a group of instructions a data definition a call to another module We aim for strong cohesion: modules We whose elements are functionally related Measure of how well we have partitioned Measure the system the Types of Cohesion Types Coincidental Temporal Logical Low “Scatter­Brained” Communicational Functional Procedural Cohesion Spectrum Good High “Single-Minded” A measure of the relative functional strength of a software module Coincidental: : multiple, completely unrelated actions or components Coincidental multiple, completely unrelated actions or components Logical: : series of related actions or components (e.g. library of IO functions) Logical series of related actions or components (e.g. library of IO functions) Temporal: : series of actions related in time (e.g. initialisation modules) Temporal series of actions related in time (e.g. initialisation modules) Procedural: : series of actions sharing sequences of steps. Procedural series of actions sharing sequences of steps. Communicational: : procedural cohesion but on the same data. Communicational procedural cohesion but on the same data. Functional: : one action or function one action or function Functional Some Design Principles… Some The design process should not suffer from ‘tunnel vision.’ The design should be traceable to the analysis model. The design should not reinvent the wheel. The design should be structured to accommodate change. Design is not coding, coding is not design. What is Next…??? What Continue on Design UML Class & Sequence Diagrams UML User Interface Design ...
View Full Document

{[ snackBarMessage ]}

Ask a homework question - tutors are online