Software Design CMSC 345 Version 111 What is

  • Slides: 28
Download presentation
Software Design CMSC 345, Version 1/11

Software Design CMSC 345, Version 1/11

What is Design? Design Where requirements are transformed into implementation descriptions n It is

What is Design? Design Where requirements are transformed into implementation descriptions n It is a creative process n There is no design “cookbook” n It is learned by experience and the study of existing systems n CMSC 345, Version 1/11

Design Tasks Architectural Design • High level design • Includes technology • Includes hardware,

Design Tasks Architectural Design • High level design • Includes technology • Includes hardware, deployment, operations, etc. • Usually started early in the process • No one “correct” architectural design • May be hybrids of several architecture types Roache, E. , Software Design: Requirements to Code CMSC 345, Version 1/11 Component Design • public interfaces • preconditions • postconditions • dependencies • internal design Data Structure Design • OO • class design • Procedural & OO • data structures (e. g. , trees) Algorithm Design • Implementation algorithms Data Design • Persistent data storage description • Could be a file or a database • file structure • DB relationships • Data (fields) • names • descriptions • types • other (e. g. , string size)

Architectural Design Diagrams n Different “flavors” of architectural design diagrams ¨ Willy-nilly n n

Architectural Design Diagrams n Different “flavors” of architectural design diagrams ¨ Willy-nilly n n n ¨ Deployment n ¨ n A layout of the system’s major conceptual components and their internal and external dependencies Technology n ¨ A layout of the system’s network segments, zones, nodes, and connections Logical n ¨ A “bird’s-eye-view” of the major hardware components of the system, the software that is installed on them, and (sometimes) their internal and external dependencies Network n ¨ Self-defined, loosely-defined Includes what needs to be communicated Highly dependent on its audience A layout of the system’s major hardware and software technologies and their internal and external dependencies Other Models may be ¨ ¨ Static – shows structure only Dynamic – shows structure and control and/or data flow Roache, E. , Software Design: Requirements to Code CMSC 345, Version 1/11

Copyright® 2007 Computer Systems Odessa corp. All rights reserved. CMSC 345, Version 1/11

Copyright® 2007 Computer Systems Odessa corp. All rights reserved. CMSC 345, Version 1/11

Copyright® 2007 Computer Systems Odessa corp. All rights reserved. CMSC 345, Version 1/11

Copyright® 2007 Computer Systems Odessa corp. All rights reserved. CMSC 345, Version 1/11

Design Descriptions n Graphical notations (e. g. , UML) ¨ Display relationships between system

Design Descriptions n Graphical notations (e. g. , UML) ¨ Display relationships between system components n Program Description Languages (PDLs) ¨ Pseudocode n Informal text ¨ For anything that can’t be described formally (e. g. , design rationale, choice of software) CMSC 345, Version 1/11

Design Quality What is “good” design? No general agreement, but. . . n n

Design Quality What is “good” design? No general agreement, but. . . n n n Should correctly implement the specification (verification) Must be understandable Must be able to adapt to modification or addition of new functionality ¨ High component cohesion ¨ Low component coupling ¨ Cohesion and coupling concepts apply to every level of design (e. g. , architecture, classes, functions) CMSC 345, Version 1/11

Component Cohesion A measure of the closeness of the relationships between the component’s components

Component Cohesion A measure of the closeness of the relationships between the component’s components n Applies to both procedural and OO design ¨ Cohesive function n ¨ Cohesive object n n Performs a single task A single entity and all of its operations We want strong (high) cohesion CMSC 345, Version 1/11

Cohesion Levels 7 levels of cohesion (Constantine & Yourdan), weakest to strongest: 1) Coincidental

Cohesion Levels 7 levels of cohesion (Constantine & Yourdan), weakest to strongest: 1) Coincidental Cohesion ¨ The parts of a component are not related, but simply bundled into a single component 2) Logical Association ¨ Components that perform similar functions such as input, error handling, and so on are put together in a single component CMSC 345, Version 1/11

Cohesion Levels 3) Temporal Association ¨ All of the components that are activated at

Cohesion Levels 3) Temporal Association ¨ All of the components that are activated at a single time, such as start up or shut down, are brought together 4) Procedural Cohesion ¨ The elements in a component make up a single control sequence n a function that checks file permissions and then opens the file 5) Communicational Cohesion ¨ All of the elements of a component operate on the same data CMSC 345, Version 1/11

Cohesion Levels 6) Sequential Cohesion ¨ The output from one element in the component

Cohesion Levels 6) Sequential Cohesion ¨ The output from one element in the component serves as input for some other element n A function that reads data from a file, processes the data, then prints the results 7) Functional Cohesion ¨ Each part of the component is necessary for the execution of a single task CMSC 345, Version 1/11

Component Coupling (1) A measure of the strength of the interconnections between components n

Component Coupling (1) A measure of the strength of the interconnections between components n Want components to be as independent as possible ¨ Component “changeability” ¨ Component reusability ¨ System maintainability ¨ System “debuggability” ¨ Other “X-ilities” n We want weak (low) coupling CMSC 345, Version 1/11

Component Coupling (2) Applies to both functional and OO design n Functional ¨ No/little

Component Coupling (2) Applies to both functional and OO design n Functional ¨ No/little global data ¨ In general, nothing that causes one function to require knowledge of another’s implementation (encapsulation/information hiding) n OO ¨ Minimize public interfaces ¨ Include accessors and mutators for all “accessible” attributes ¨ Inheritance by nature causes coupling between base and derived classes. ¨ Multiple inheritance greatly increases coupling. CMSC 345, Version 1/11

Coupling Types n Content ¨ One component directly modifies data or control flow of

Coupling Types n Content ¨ One component directly modifies data or control flow of another n Common ¨ Organizing n data into a common store Control ¨ Control flags passed as parameters between components CMSC 345, Version 1/11

Types of Coupling (2) n Stamp ¨ Data n structures passed Data ¨ Only

Types of Coupling (2) n Stamp ¨ Data n structures passed Data ¨ Only primitive data passed CMSC 345, Version 1/11

Procedural Design Process n Data flow design ¨ Model the flow of data through

Procedural Design Process n Data flow design ¨ Model the flow of data through the system using data flow diagrams (DFDs) n Structural decomposition ¨ Model how functions are decomposed into subfunctions using structure (hierarchy) charts n Detailed design ¨ The entities in the design and their interfaces are described in detail. These may be recorded in a data dictionary and the design expressed using a program description language (PDL). CMSC 345, Version 1/11

DFD Notation Rounded rectangle - function or transform n Rectangle - data store n

DFD Notation Rounded rectangle - function or transform n Rectangle - data store n Circles - user interactions with the system n Arrows - show direction of data flow n Keywords - and/or - used to link data flows n CMSC 345, Version 1/11

Design Report Generator CMSC 345, Version 1/11

Design Report Generator CMSC 345, Version 1/11

Structural Decomposition Results in a model that shows function calls n Functions should be

Structural Decomposition Results in a model that shows function calls n Functions should be highly cohesive and loosely coupled n In essence, a data flow diagram is converted into a structure chart (structural decomposition diagram). n CMSC 345, Version 1/11

Decomposition Guidelines For most applications, the top-level structure chart has three functions, namely input,

Decomposition Guidelines For most applications, the top-level structure chart has three functions, namely input, process, and output. n Data validation functions should be subordinate to an input function. n Coordination and control should be the responsibility of functions near the top of the hierarchy. n CMSC 345, Version 1/11

Starting Decomposition n Identify system processing transformations ¨ Transformations in the DFD that are

Starting Decomposition n Identify system processing transformations ¨ Transformations in the DFD that are concerned with processing rather than input/output activities. Group under a single function in the structure chart n Identify input transformations ¨ Transformations concerned with reading, validating, and formatting inputs. Group under the input function. n Identify output transformations ¨ Transformations concerned with formatting and writing output. Group under the output function CMSC 345, Version 1/11

Initial Structure Chart CMSC 345, Version 1/11 Sommerville, Ian, Software Engineering

Initial Structure Chart CMSC 345, Version 1/11 Sommerville, Ian, Software Engineering

Expanded Structure Chart CMSC 345, Version 1/11

Expanded Structure Chart CMSC 345, Version 1/11

Final Structure Chart CMSC 345, Version 1/11

Final Structure Chart CMSC 345, Version 1/11

Detailed Design (Functional and OO) n Produces a short design specification of each function/method

Detailed Design (Functional and OO) n Produces a short design specification of each function/method ¨ Logical description ¨ Inputs and outputs ¨ Preconditions and postconditions ¨ Invariants Can be managed using a data dictionary n Finally, produce detailed design descriptions (PDL/pseudocode) n CMSC 345, Version 1/11

Data Dictionary Entries CMSC 345, Version 1/11 Sommerville, Ian, Software Engineering

Data Dictionary Entries CMSC 345, Version 1/11 Sommerville, Ian, Software Engineering

References Constantine, Larry and Edward Yourdan, Structured Design: Fundamentals of a Discipline of Computer

References Constantine, Larry and Edward Yourdan, Structured Design: Fundamentals of a Discipline of Computer Program and System Design. Prentice-Hall, 1979. n Sommerville, Ian, Software Engineering. 6 th ed, Addison Wesley, 2000. n Roache, Eddie, Software Design: Requirements to Code, CMSC 345 speaker slides, version 1. 5, fall 2007. n CMSC 345, Version 1/11