Software Design CMSC 345, Version 1/11

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

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 Component Design public interfaces preconditions postconditions dependencies internal design 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) Data Structure Design OO class design Procedural & OO data structures (e.g., trees) Should “invariants” be part of the Component Design/public interfaces? Roache, E., Software Design: Requirements to Code CMSC 345, Version 1/11

Architectural Design Diagrams Different “flavors” of architectural design diagrams Willy-nilly Self-defined, loosely-defined Includes what needs to be communicated Highly dependent on its audience Deployment 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 A layout of the system’s network segments, zones, nodes, and connections Logical A layout of the system’s major conceptual components and their internal and external dependencies Technology 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.

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

Design Descriptions Graphical notations (e.g., UML) Display relationships between system components Program Description Languages (PDLs) Pseudocode 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 ... 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 Applies to both procedural and OO design Cohesive function Performs a single task Cohesive object 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 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 4) Procedural Cohesion 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 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 7) Functional Cohesion The output from one element in the component serves as input for some other element 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 Want components to be as independent as possible Component “changeability” Component reusability System maintainability System “debuggability” Other “X-ilities” We want weak (low) coupling CMSC 345, Version 1/11

Component Coupling (2) Applies to both functional and OO design No/little global data In general, nothing that causes one function to require knowledge of another’s implementation (encapsulation/information hiding) 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 Content Common Control One component directly modifies data or control flow of another Common Organizing data into a common store Control Control flags passed as parameters between components CMSC 345, Version 1/11

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

Procedural Design Process Data flow design Model the flow of data through the system using data flow diagrams (DFDs) Structural decomposition Model how functions are decomposed into sub-functions using structure (hierarchy) charts 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 Rectangle - data store Circles - user interactions with the system Arrows - show direction of data flow Keywords - and/or - used to link data flows CMSC 345, Version 1/11

Design Report Generator CMSC 345, Version 1/11

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

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

Starting Decomposition 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 Identify input transformations Transformations concerned with reading, validating, and formatting inputs. Group under the input function. Identify output transformations Transformations concerned with formatting and writing output. Group under the output function CMSC 345, Version 1/11

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

Expanded Structure Chart CMSC 345, Version 1/11

Final Structure Chart CMSC 345, Version 1/11

Detailed Design (Functional and OO) 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 Finally, produce detailed design descriptions (PDL/pseudocode) CMSC 345, Version 1/11

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

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