1. Chapter 1: Software design

2. Software Design
"You can use an eraser on the drafting table or a sledgehammer on the construction site.“
--Frank Lloyd Wright

3. Why software design is important?
It is one of the most challenging activities of s/w development
There is a high payoff associated with good design (or high penalty with bad design)

4. What is software design?
Design bridges that gap between knowing what is needed (software requirements specification) to entering the code that makes it work (the construction phase).
Design is both a verb and a noun.

5. What is software design? (cont...)
Software engineers apply their knowledge of the problem domain and implementation technologies in order to translate system specifications into plans for the technical implementation of the software.
The resulting design expresses the overall structure and organization of the planned implementation

6. Design Model Divided into four (4) elements:
Component Level Design: transforms structural elements of the software architecture into a procedural description of software components
Interface Design: describes how the software communicates with systems that interoperate with it and with humans that use it
Architectural Design: defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system
Data/Class Design: transforms analysis classes into design classes along with the data structures required to implement the software

7. Design Model

8. Why Design is Hard?
Design is difficult because design is an abstraction of the solution which has yet to be created

9. Design is a wicked problem
Used to describe problems in social planning but engineers have recognized it aptly describes some of the problems they face as well
A wicked problem is one that can only be clearly defined by solving it
Need two solutions. The first to define the problem, and the second to solve it in the most efficient way.

10. Design is a Universal Activity
Any product that is an aggregate of more primitive elements, can benefit from the activity of design

11. Design Occurs at Different Levels

12. Characteristics of Software Design
Non-deterministic – A deterministic process is one that produces the same output given the same inputs. Design is non-deterministic. No two designers or design processes are likely to produce the same output.
Heuristic – because design is non-deterministic design techniques tend to rely on heuristics and rules-of-thumb rather than repeatable processes.
Emergent – the final design evolves from experience and feedback. Design is an iterative and incremental process where a complex system arises out of relatively simple interactions.

13. The Evolution of Designs
Design as a single step in the software life cycle is somewhat idealized.
More often the design process is iterative and incremental.
Designs tend to evolve over time based on experience with their implementation.

14. The Benefits of Good Design
Good design reduces software complexity which makes the software easier to understand and modify
It enables reuse. Good design makes it easier to reuse code
Complexity is the root cause of other problems such as security. A program that is difficult to understand is more likely to be vulnerable to exploits than one that is simpler.

15. A Generic Design Process
Understand the problem (software requirements).
Construct a “black-box” model of solution (system specification). System specifications are typically represented with use cases (especially when doing OOD).
Look for existing solutions (e.g. architecture and design patterns) that cover some or all of the software design problems identified.
Design not complete? Consider using one or more design techniques to discover missing design elements
Noun-verb analysis, CRC Cards, step-wise refinement, etc.
Take final analysis model and pronounce a first-draft design (solution) model
Consider building prototypes
Document and review design
Iterate over solution (Refactor) (Evolve the design until it meets functional requirements and maximizes non-functional requirements)

16. Inputs to the design process
User requirements and system specification (including any constraints on design and implementation options)
Domain knowledge (For example, if it’s a healthcare application the designer will need some knowledge of healthcare terms and concepts.)
Implementation knowledge (capabilities and limitations of eventual execution environment)

17. Attributes of a design
Static structure of system (components and their relationships)
Interactions between components
System data and its structure (database scheme)
Physical packaging and distribution of components
Algorithms

18. General Software Design Principles
Modularization
Coupling
Cohesion
Abstraction

19. Modularization
The goal of design is to partition the system into modules:-
High cohesion within modules, and
Loose coupling between modules
Modularity reduces the total complexity a programmer has to deal with at any one time assuming:
Functions are assigned to modules in away that groups similar functions together (Separation of Concerns), and
There are small, simple, well-defined interfaces between modules (information hiding)

20. Modularization: Trade-Offs
What is the "right" number of modules
for a specific software design?
module development cost
cost of
software
module
integration
cost
optimal number
number of modules
of modules

21. Coupling
Coupling is the measure of dependency between modules. A dependency exists between two modules if a change in one could require a change in the other.
The degree of coupling between modules is determined by:
The number of interfaces between modules (quantity), and
Complexity of each interface (determined by the type of communication) (quality)

22. Coupling: Types of Coupling
Content coupling (also known as Pathological coupling)
Common coupling
Control coupling
Stamp coupling
Data coupling

23. Coupling: Content Coupling
One module directly references the contents of another
One module modifies the local data or instructions of another
One module refers to local data in another
One branches to a local label of another

24. Coupling: Common Coupling
Two or more modules connected via global data.
One module writes/updates global data that another module reads

25. Coupling: Control Coupling
One module determines the control flow path of another. Example:
print(milesTraveled, displayMetricValues)
. . .
public void print(int miles, bool displayMetric) { if (displayMetric) {
System.out.println(. . .);
else { . . .} }

26. Coupling: Stamp Coupling
Passing a composite data structure to a module that uses only part of it. Example: passing a record with three fields to a module that only needs the first two fields.

27. Coupling: Coupling between CSS and JavaScript
A well-designed web app modularizes around:
HTML files which specify data and semantics
CSS rules which specify the look and formatting of HTML data
JavaScript which defines behavior/interactivity of page
Assume you have the following HTML and CSS definitions.

28. Coupling: Coupling between CSS and JavaScript
<!doctype html>
<html>
<head>
<script type="text/javascript" src="base.js"></script>
<link rel="stylesheet" href="default.css">
</head>
<body>
<button onclick="highlight2()">Highlight</button>
<button onclick="normal2()">Normal</button>
<h1 id="title" class="NormalClass">CSS <--> JavaScript Coupling</h1>
</body>
</html>
HTML
.NormalClass {
color:inherit;
font-style:normal; }
CSS
Output

29. Cohesion
Cohesion is a measure of how strongly related the functions or responsibilities of a module are.
A module has high cohesion if all of its elements are working towards the same goal.

30. Cohesion and Coupling
The best designs have high cohesion (also called strong cohesion) within a module and low coupling (also called weak coupling) between modules.

31. Abstraction Abstraction is a concept used to manage complexity
An abstraction is a generalization of something too complex to be dealt with in its entirety
Abstraction is for humans not computers

32. Software Design Strategies
Structured Design
Object Oriented Design