Introduction to Software

Design

UA.DETI.PDS - 2022/23
José Luis Oliveira
Resources & Credits
v Object-Oriented Analysis and Design
with Applications
Grady Booch, Robert A. Maksimchuk,
Michael W. Engle, Bobbi J. Young,
Jim Conallen, Kelli A. Houston
Addison-Wesley Professional; 3rd edition

v Programming in the Large with Design Patterns

Eddie Burris
Pretty Print Press

2
Design

"You can use an eraser on the

drafting table or a sledgehammer
on the construction site.“
--Frank Lloyd Wright

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

4
What is Software Design?

v Design bridges the gap

– between knowing what is

needed (software
requirements specification)

– to entering the code that

makes it work (the
construction phase).

5
What is Software Design?
v Design is needed at several different levels of detail in a
system:

– system

– subsystems or packages: user interface, data storage,

application-level classes, graphics . . .

– classes within packages, class relationships, interface of

each class, public methods

– attributes, private methods, inner classes . . .

– source code implementing methods

6
Design Occurs at Different Levels

7
Importance of Software Design
v The design process can be made more systematic and
predictable through the application of methods, techniques
and patterns, all applied according to principles and heuristics.

8
Importance of Managing Complexity
v Poorly designed programs are difficult to understand
and modify.
v The larger the program, the more pronounced are the
consequences of poor design.

Cost of adding
the ith feature to a
well-designed and
poorly designed
program

9
Two Types of Complexity in Software
v Essential complexities
– complexities that are inherent in the problem.
v Accidental/incidental complexities
– complexities that are artifacts of the solution.

v The total amount of complexity in a software solution is:

– Essential Complexities + Accidental complexities

v The primary purpose of design is to control complexity

– Goal: manage essential complexity while avoiding the
introduction of additional accidental complexities

10
Dealing with Software Complexity
v Modularity – subdivide the solution into smaller easier to
manage components. (divide and conquer)
v Abstraction – use abstractions to suppress details in
places where they are unnecessary.
v Information Hiding – hide details and complexity behind
simple interfaces
v Inheritance – general components may be reused to
define more specific elements.
v Composition – reuse of other components to build a new
solution

11
Design is a wicked problem
v A wicked problem is one that can only be clearly
defined by solving it.

"TEX would have been a complete failure if I had merely specified it

and not participated fully in its initial implementation. The process of
implementation constantly led me to unanticipated questions and
to new insights about how the original specifications could be
improved."

Donald Knuth

12
Characteristics of Software Design
v Non-deterministic
– No two designers or design processes are likely to produce the
same output.
v Heuristic
– Design techniques tend to rely on heuristics and rules-of-thumb
rather than repeatable processes.
v 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
A Generic Design Process
v Understand the problem (software requirements).
v Construct a “black-box” model of solution (system
specification).
– System specifications are typically represented with use cases
(especially when doing OOD).
v Look for existing solutions (e.g., architecture and design
patterns) that cover some or all of the software design
problems identified.
v Consider building prototypes
v Document and review design
v Iterate over solution (Refactor)
– Evolve the design until it meets functional requirements and
maximizes non-functional requirements

14
Inputs to the design process
v User requirements and system specification
– including any constraints on design and implementation options

v Domain knowledge
– For example, if it’s a healthcare application the designer will
need some knowledge of healthcare terms and concepts.

v Implementation knowledge
– capabilities and limitations of eventual execution environment

15
Desirable Internal Design Characteristics
v Minimal complexity – Keep it simple. Maybe you don’t need high levels of
generality.
v Loose coupling – minimize dependencies between modules
v Ease of maintenance – Your code will be read more often then it is written.
v Extensibility – Design for today but with an eye toward the future. Note, this
characteristic can be in conflict with “minimize complexity”. Engineering is
about balancing conflicting objectives.
v Reusability – reuse is a hallmark of a mature engineering discipline
v Portability – works or can easily be made to work in other environments
v High fan-in on a few utility-type modules and low-to-medium fan-out on all
modules. High fan-out is typically associated with high complexity.
v Leanness – when in doubt, leave it out. The cost of adding another line of
code is much more than the few minutes it takes to type.
v Stratification – Layered. Even if the whole system doesn’t follow the layered
architecture style, individual components can.
v Standard techniques – sometimes it’s good to be a conformist! Boring is good.
Production code is not the place to try out experimental techniques.

16
Software Design methods

Software
Requirements Design

17
Patterns
v A design pattern is a reusable solution to a commonly
occurring design problem
v Design patterns are adapted for the unique
characteristics of the problem
v Just as there are levels of design, there are levels of
design patterns:
– Architecture Styles/Patterns
– Design Patterns
– Programming Idioms

21
What next? O-O Software Design
v There’s no a methodology to get the best object-oriented
design, but there are principles, patterns, heuristics.

22