Software Design
AITI GP
John Paul Vergara
What is Design?
Design is the activity of specifying a
solution to a problem
Contrast this against other software
engineering phases
Analysis: understanding and specifying the
problem (requirements)
Implementation: system construction
Goal of Software Design
To achieve sufficient agreement on
interface definition and internal structure
that implementation may proceed in
parallel teams.
Stages in SW Design
Architectural Design
Abstract Specification
Interface Design
Component Design
Detailed Design
*Reference: Sommerville, Chapter 12
Architectural Design
Identify Subsystems and Modules
Example: Program Submission System
Server
Teacher Interface
Student Interface
Architectural Design,
continued
Design information provided is minimal
System is simply decomposed into
interacting subsystems or modules
Making global and local decisions about
planned implementation based on
constraints, non-functional requirements
and available alternatives
Has general applicability
concern for architectural
design
Structure
Communication
Distribution
Persistence
Security
Error Handling
Recovery
Use or Reuse of
existing hardware and
software
configurations
Abstract Specification
Identify services and constraints per
subsystem
Example: Server
set up a class
set up a project
submit a program
Note: descriptions of services are
informal
Interface Design
Per subsystem, specify its interface
collection of available functions/methods for
use by other subsystems
Consistent with Encapsulation
Example: Server
function: set_up_class
parameters: catnum, section, list of
students (id#’s and names)
Interface Specification
Services per subsystem are formally
specified
Goal: provide unambiguous information
regarding extent of external interaction
 parameters/inputs, return values/outputs
Design and implementation details of the
subsystem are still hidden
Component Design
Within a subsystem
determine components
per component, identify services/interfaces
Understand interaction between
components at the level of the subsystem
OO Design: components are classes
Design models (using the UML, for
example) are most useful at this level
Detailed Design
Specify data structures and algorithms
(for methods) of the individual
components (classes)
Generally still implementationindependent
Although though in practice, specific
language features are used
Techniques: Pseudocode, flowcharts, others
Design Work Products
System Architecture
Application Programming Interfaces
Target Environment (addressing nonfunctional requirements)
Subsystem Model
Design Object Model - static model
representing structure of classes and
relationships with each other
Design Work Products
continued...
Design Object Interaction Diagrams graphically depict collaborations between
objects
Design State Models - represent dynamic
behavior of design classes and are done
for all classes that have strong state
dependent object behavior
Design Quality
Cohesion
Coupling
Understandability
Adaptability
*Reference: Section 12.3 of Sommerville
Cohesion
Extent of relationship between parts of a
component
High cohesion is desirable
Single logical t (or “theme”)
all parts should contribute to the function
Levels of cohesion (p. 218)
coincidental cohesion (weakest)
functional cohesion (strongest)
Coupling
Dependence between units of a
subsystems or components
High coupling generally undesirable
units fully depend on each other
sensitive to change
convenient/necessary only for small
components
Understandability
Cohesion and Coupling
understanding a component independently
Naming
reflects real-world intuition
Documentation
Complexity
algorithms
Adaptability
Sensitivity to change
are changes in design easy?
Loosely coupled components
Self-contained components
Object-Oriented
Design Notation
CS 123/CS 231
References
UML in a Nutshell
UML Distilled, by Martin Fowler
Chapters 3, 4, 6, and 8
Supplementary References:
Chapter 14 of Sommerville
Chapter 22 of Pressman
Component Design and
Detailed Design
Component Design
For each subsystem determine components,
and services/interface per component
OO Design: components are classes
Detailed Design
Determine attributes of classes and
relationships between the classes
Determine functionality of each class and
interactions between classes
Object-Oriented Modeling
UML: Unified Modeling Language
OO Modeling Standard
Booch, Jacobson, Rumbaugh
UML is used to visualize, specify, construct
and document the artifacts of a software
intensive system
Building Blocks of the UML
Things
the abstractions
Relationships
tie the “things” together
Diagrams
group interesting collections of things
UML Diagrams
What is depicted?
Class details and static relationships
System functionality
Object interaction
State transition within an object
Some UML Modeling
Techniques
Class Diagrams
Use Cases/Use Case Diagrams
Interaction Diagrams
Sequence Diagrams
Collaboration Diagrams
State Diagrams
Activity Diagram
Example:
Class Diagram
FFCounter
totalcash
totalorders
pc
PriceChecker
getPrice()
counters
5
FastFood
Restaurant
Example:
Use Case Diagram
LIBRARY SYSTEM
Facilitate Checkout
Librarian
Search for Book
Facilitate Return
Borrower
Example:
Interaction Diagram
Checkout
Screen
2: checkIfAvailable()
:Book
1: checkIfDelinquent()
3: borrowBook()
4: setBorrower()
:Borrower
Example:
State Diagram (Book)
start
Reserved
Borrowed
New
Librarian activates
book as available
Borrower returns book
Available
Object-Oriented Design
Models
Static Model : interested in the structure
Class Diagrams
Dynamic Model : interested in the
behavior
Use Cases, Interaction Diagrams, State
Diagrams, others
OO Static Model
Classes and Class Diagrams
Names (attributes and methods)
Visibility(private,public,protected)
Scope (abstract, concrete…)
Relationships
Dependency : change to one affects the
other
Association (includes aggregation and
composition) : structural relationship
describing connection between the objects
Relationships continued...
Generalization : inheritance
Realization : a classifier specifies a contract
that another classifier guarantees to carry out
(e.g., interfaces and classes that realize
them)
OO Dynamic Model
Goal: Represent
Object behavior
Object interaction
Traditional/Procedural Dynamic Modeling
Data Flow Diagrams (DFDs)
Problem: Processes separate from data
Need modeling notation that highlight tight
relationship between data & processes
DFD Example
(Inventory Management)
Delivery info
Accept and Post
Delivery
Transaction
Item Master
OO Counterpart:
Object Interaction
new (delivery info)
Encoder
:Transaction
post (item count)
:Item Master
Building an
OO Dynamic Model
Identify use cases
Describe each use case through an
interaction diagram
For state dependent objects, can provide
state diagrams
Derive implied methods (and attributes)
Define flow of control, sequence of
messages
What’s Next?
Need to understand the notation
Make sure it helps the software
development process
When to use the UML techniques
Primarily when specifying OO design
Formal means of communication across the
different software development stages