1. Software Design
CMSC 345, Version 1/11

2. 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

3. 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

4. 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

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

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

7. 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

8. 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

9. 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

10. 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

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

12. 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

13. 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

14. 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

15. 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

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

17. 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

18. 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

19. Design Report Generator
CMSC 345, Version 1/11

20. 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

21. 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

22. 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

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

24. Expanded Structure Chart
CMSC 345, Version 1/11

25. Final Structure Chart
CMSC 345, Version 1/11

26. 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

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

28. 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