1.  2004 by SEC Chapter 4 Software Design

2. 2  2004 by SEC Chapter 4 Software Design 4.1 Design Fundamentals 4.2 Design Method 4.3 Architecture Design 4.3.1 Architecture Patterns 4.4 Data Design 4.5 Interface Design 4.6 Procedural Design

3.  2004 by SEC 4.1 Design Fundamentals

4. 4  2004 by SEC Design Fundamentals l Design Step Procedures l Software Design vs. Requirement Analysis –Software design: requirements  a representation of software –requirement analysis: create a model to represent the requirements functional requirement information model functional model behavioral model data designdata structure architecture design procedure design relationship between structure components depict structure component ie. a procedural description of software nonfunctional requirement design constrain performance Cost … { {

5. 5  2004 by SEC Design Fundamentals (cont’d) l Common Characteristics –A mechanism for the translation of information domain representation into design representation –A notation for representing functional components and their interfaces –Heuristics for refinement and partitioning l Design Quality –Design is the place where quality is fostered in software engineering. –Design provides us with representations of software that can be assessed for quality.

6. 6  2004 by SEC Design Fundamentals (cont’d) l Fundamental Concepts –Abstraction l l procedural abstraction –a named sequence of instruction that has a specific function l data abstraction –a named collection of data that describes a data object –can refer to all the data by stating the name of the data abstraction –original abstraction data type is used as a template or generic data structure from which the data structure can be instructed. Level of abstraction Highest level. Low level. Lowest level Language used Problem-oriented terminology. Procedural-oriented terminology. Implementation-oriented terminology

7. 7  2004 by SEC Design Fundamentals (cont’d) –Refinement l A top-down design strategy l A hierarchy is developed by decomposing a statement of function ( a procedural abstraction) in a stepwise fashion until programming statements are reached. –Every refinement step implies some design decisions l A process of elaboration –begins with a statement of function (or description of data) without the internal working of the function (or internal structure of the data). –provides more and more details as each successive refinement occurs.

8. 8  2004 by SEC Design Fundamentals (cont’d) l Abstraction and refinement are complementary concepts. l Abstraction enables a designer to specify procedure and data, and even suppress low-level details. l Refinement on the other hand helps the designer revel low-level details as design progresses. l Both concepts aid the designer in creating a complete design model as the design evolves.

9. 9  2004 by SEC Design Fundamentals (cont’d) –Modularity l Modules: software is divided into separately named and addressable components, sometimes called modules. l Modules vs. Interfaces between modules –Avoid overmodularity & undermodularity; notice the relationship between modules (the number of interfaces will increase exponentially with the number of modules.) –trade-offs

10. 10  2004 by SEC Design Fundamentals (cont’d) optimal number of modules of modules cost of cost of software software number of modules moduleintegrationcost module development cost What is the right number of modules for a software design?

11. 11  2004 by SEC Design Fundamentals (cont’d) –Software architecture l It is the structure of program components, the manner in which these components interacts, and the structure of data used by the components. l It relates elements of a software solution to parts of a real-world problem.

12. 12  2004 by SEC Design Fundamentals (cont’d) –Control hierarchy (program structure) l The organization of program components & implies a hierarchy of control –Does not represent procedural aspects of software (iteration, condition, sequence) l Depth / width / fan-in / fan-out / superordinate / subordinate l Two characteristic of software architecture –Visibility: program components may be invoked or used as data by given component (indirectly) (e.g. M4 is visible to M1) –Connectivity: program components are directly invoked or used as data by given component (e.g. M2 is connected to M1) l A module that directly causes another module to begin execution is connected to it M1M2 M3M4

13. 13  2004 by SEC Design Fundamentals (cont’d) –Software procedure focuses on the processing details of each module individually (sequence, iteration, condition) l a procedural representation of software is layered –Information hiding l Modules should be specified and designed so that information (procedure & data) contained within a module are inaccessible to other modules that have no need for such information. l Hiding implies that effective modularity design can be achieved by defining a set of independent modules. l Hiding defines access constraints to both procedural detail within a module and local data structure used by the module. l Provides the greatest benefits when program modification are required.

14.  2004 by SEC 4.2 Design Method

15. 15  2004 by SEC Effective Modular Design l Effective Modular Design –A modular design reduces complexity, facilitates changes, results in an easier implementation. –Classification (based on temporal aspect) monolithic program module program object-oriented program code-and-fix sequential/ incremental/ parallel subroutines/ coroutines/ conroutines Without apparent interruption / Can be interrupted before completion / execute simultaneously with another module

16. 16  2004 by SEC Effective Modular Design (cont’d) –A typical control hierarchy may not be encountered when coroutines or conroutines are used –Functional independence (independent effective modules) l Effective modularity: function compartmentalized and interfaces simplified

17. 17  2004 by SEC Effective Modular Design (cont’d) –Cohesion: relative functional strength of a module l Types of Cohesion: –coincidental : tasks relate to each other loosely inside a module –logical : performing tasks related logically ( all output ) –temporal : all tasks executed with the same span of time –procedural : must be executed in a specific order –communicational : concentrate on one area of a data structure –sequential –functional High (good) low

18. 18  2004 by SEC Effective Modular Design (cont’d) –Coupling: interconnection among modules l depends on the interface complexity between modules, entry point or reference to a module, what data passes across the interface l Types of Coupling: –No direct coupling : module subordinate to different modules –Data coupling : data passed via argument list –Stamp coupling : data structure passed via argument list –control coupling : passes control data –external coupling : modules are tied to an external environment –common coupling : refer to a global data area –content coupling : l one module makes use of data or control information maintained within the boundary of another module. l branches are made into the middle of a module high (Good) low

19.  2004 by SEC 4.3 Architectural Design

20. 20  2004 by SEC Architectural Design l Program architecture, domain specific software architecture –Develop a modular program structure –Represent the control relationship between modules l Control hierarchy connecting modules –Define interface that enable data to flow throughout the program –System organization –DSSA (Domain-Specific Software Architecture) l Pipes & filters –I: a stream of inputs –O: a stream of outputs (1) program structure (2) domain-specific Software architecture

21. 21  2004 by SEC Architecture Patterns l Layered systems: –System organized hierarchically with each layer providing service to the layer above it l Rule-based system l Blackboard systems: a central data structure represents the current state of the computation, a collection of knowledge sources. System Basic Core Knowledge Base RBFact Rule & data element Rule interpreter Working Memory Input Outputselected rules/data Blackboard

22. 22  2004 by SEC 4.4 Data Design –Define data abstractions –Select an appropriate data structure to implement the abstraction –Using entity-relationship modeling depict relationship between objects data abstraction data structure data modeling

23.  2004 by SEC 4.5 Procedural Design

24. 24  2004 by SEC Procedural Design l Structure programming –logical constructs: sequence, conditional, iteration –to limit the procedural design to a small number of predictable operations l reduce program complexity l lead to more readable, testable code l Flow charts –Graphical representation for procedural design –Limitation l Introduce inefficiency when an escape from a set of nested loops or nested conditions is required l Additional complications of logical tests

25. 25  2004 by SEC Procedural Design (cont’d) l Program design language (PDL) –Structured English (pseudocode) l Uses the vocabulary of English l Overall syntax of a structure programming language –Difference between PDL and programming language l The use of narrative text embedded directly within PDL statements l PDL cannot be compiled but can be translated into a graphical structure l Why design language –can be embedded with source code –can be a derivative of the high order language. e.g. Ada PDL –easy to review –can be represented in great detail

26. 26  2004 by SEC PDL l Data structure –TYPE IS l eg. TYPE table IS INSTANCE OF symboltable l Abstract data type: data abstraction –Generic data structure (template) from which other data structures can be instantiated –e.g. TYPE table IS INSTANCE OF symboltable –Block structure BEGIN END

27. 27  2004 by SEC PDL (cont’d) –Conditional -IF THEN ELSE ENDIF –Iteration -REPEAT UNTIL ENDREP -DO WHILE ENDDO -DO FOR ENDFOR -CASE OF WHEN SELECT. DEFAULT: ENDCASE