SWE 621:

Software Modeling and Architectural Design

Lecture Notes on Software Design

Lecture 1 - Introduction to Software Design

Hassan Gomaa
Dept of Computer Science
George Mason University
Fairfax, VA
Copyright © 2011 Hassan Gomaa
All rights reserved. No part of this document may be reproduced in any form or
by any means, without the prior written permission of the author.
This electronic course material may not be distributed by e-mail or posted on any
other World Wide Web site without the prior written permission of the author.

Copyright © 2011 Hassan Gomaa 1

Introduction to Software Design

1. Section I

Hassan Gomaa

References: H. Gomaa, “Chapters 1,2-5 - Designing Concurrent,

Distributed, and Real-Time Applications with UML”, Addison
Wesleyy Object
j Technologygy Series,, 2000.
H. Gomaa, “Chapters 1-5 - H. Gomaa, “Software Modeling and
Design: UML, Use Cases, Patterns, and Software Architectures”,
Cambridge University Press, February 2011

Copyright © 2011 Hassan Gomaa

All rights reserved. No part of this document may be reproduced in any form or by any means,
without the prior written permission of the author.

Copyright © 2011 Hassan Gomaa 2

 Overview
• Follows general guidelines of Software Engineering Body
of Knowledge (SWEBOK) – Chapter 3 Software Design
• Published byy IEEE – 2004 Version
– Fundamentals of Software Design
– Software Design Process
– Software Design Concepts
– Software Design Notations and Methods

Copyright © 2011 Hassan Gomaa 3

Software Design

What is design?
noun: mentalt l plan,
l preliminary
li i sketch
k t h or outline
tli
verb: to conceive in the mind; to invent
What is software design?
As a product
Output of design process
As a process
Approach to doing design

Copyright © 2011 Hassan Gomaa 4

 Nature of Design

• Design
– Form of problem solving
• Design as “wicked problem”
– Unlike an algorithm
• There is no one “correct” solution
• Tradeoffs in design
g
– E.g., Structure vs. performance
– Centralized vs. distributed
– Sequential vs. concurrent

Copyright © 2011 Hassan Gomaa 5

Software Design Activities

• Architectural Design
– Structure system into components
– Define the interfaces between components
• Detailed Design
– Define internal logic
– Define internal data structures

Copyright © 2011 Hassan Gomaa 6

 Context of Software Design

Software Requirements Specification

Environmental Constraints
Design Constraints Software
Design
Process Architectural Design
Detailed Design
Design Decisions
Traces to Requirements

Copyright © 2011 Hassan Gomaa 7

Inputs To Software Design

Software requirements specification

Describes WHAT system shall do not HOW
External view of system to be developed
Environmental constraints
Hardware, language, system usage
Design constraints
Design
g method
Design notation

Copyright © 2011 Hassan Gomaa 8

 Outputs From Software Design

Architectural Design
Overall description of software structure
Textual and Graphical
Specification of software components and their interfaces
Modules, classes
Detailed Design of each component
Internal logic
I
Internall data
d structures
Design decisions made
Design rationale
Traces to requirements

Copyright © 2011 Hassan Gomaa 9

Software Design Process

Software
So twa e lifee cycle
cyc e (a.k.a.
(a. .a. software
so twa e process)
p ocess)
Phased approach to software development
Software life cycle (a.k.a. process) models
Waterfall – limitations of Waterfall Model
Incremental - evolutionary prototyping
Exploratory - throwaway prototyping
Spiral model – risk driven process model

Copyright © 2011 Hassan Gomaa 10

 Software Life Cycle

Waterfall Model

Requirements
Analysis &
Specification

Architectural
Design

Detailed
Design

Coding

U it
Unit
Testing
Integration
Testing

System &
Acceptance
Testing

Copyright © 2011 Hassan Gomaa 11

Software Life Cycle Model

Software Definition

Requirements Analysis and Specification

Analysis of user's problem
Specification of "what" system shall provide user
Architectural Design
Specification of "how" system shall be structured into
components
Specification of interfaces between components

Copyright © 2011 Hassan Gomaa 12

 Software Life Cycle Model
Software Construction

Detailed Design
Internal design of individual components
Design of logic and data structures
Coding
Map component design to code
Unit Testing
Test individual components

Copyright © 2011 Hassan Gomaa 13

Software Life Cycle Model

Software Integration and Test

Integration Testing
Gradually combine components and test combinations
System Testing
Test of entire system against software requirements
Acceptance Test
Test of entire system by user prior to acceptance

Copyright © 2011 Hassan Gomaa 14

 Software Life Cycle Model
Software Maintenance

Modification of software system after installation

and acceptance
Fix software errors
Improve performance
Address changes
g in user requirements
q
Often implies significant software redesign

Copyright © 2011 Hassan Gomaa 15

Limitations of Waterfall Model

Does not show iteration in software life cycle

Does not show overlap between phases
Software requirements are tested late in life cycle
Operational system available late in life cycle

Copyright © 2011 Hassan Gomaa 16

 Prototyping During Requirements Phase

Problem
Software requirements are tested late in life cycle
Solution
Use throw-away prototyping
Help ensure requirements are understood
Also first attempt at designing system
Design of key file and data structures
Design of user interface
Early design tradeoffs

Copyright © 2011 Hassan Gomaa 17

Impact of Throwaway Prototyping on Software Life Cycle

Requirements
Analysis &
Specification

Architectural
Design

Detailed
Design
Throwaway
Prototype Coding

U it
Unit
Testing
Integration
Testing

System
Testing

Copyright © 2011 Hassan Gomaa 18

 Throw-away Prototyping in Design

Objectives
T design
Test d i early
l
Experiment with alternative design decisions
Examples of prototyping in design
Algorithm design
Experiment with - speed, accuracy
Early performance analysis
Measure timing parameters
User interface

Copyright © 2011 Hassan Gomaa 19

Impact of Throwaway Prototyping on Architectural Design Phase

Requirements
Analysis &
Specification

Architectural
Design

Detailed
Design

Coding

U it
Unit
Throwaway Testing
Prototype
Integration
Testing

System
Testing

Copyright © 2011 Hassan Gomaa 20

 Incremental Development

Problem
O
Operational
ti l system
t available
il bl late
l t in
i life
lif cycle
l
Solution
Use incremental development
Also known as evolutionary prototyping
Objective
Subset of system working early
Gradually build on
Prototype evolves into production system

Copyright © 2011 Hassan Gomaa 21

Incremental Development Software Life Cycle

Requirements
Analysis &
p
Specification

Architectural
Design

Incremental
Component
Construction

Incremental
y
System
Integration

System &
Evolutionary Acceptance
Prototype Testing

Copyright © 2011 Hassan Gomaa 22

 Should Prototype Evolve into
Production System?

Tradeoff
Rapid development
Quality of product
Throw-away prototype
Speed, not quality is goal
Must not evolve into production system
Evolutionary prototype
Must emphasize quality
Maintainability is key issue

Copyright © 2011 Hassan Gomaa 23

Combined Throwaway Prototyping / Incremental Development

Software Life Cycle Model

Requirements
Analysis &
p
Specification

Architectural
Design

Incremental
Component
Throwaway Construction
Prototype
Incremental
y
System
Integration

System &
Evolutionary Acceptance
Prototype Testing

Copyright © 2011 Hassan Gomaa 24

 Spiral Process Model (SPM)

• SPM consists of four main activities that are repeated for

each cycle (Fig. 5.6):
– Defining objectives, alternatives and constraints
– Analyzing risks
– Developing and verifying product
– Spiral planning
• Number of cycles is project specific
• Risk driven process
– Analyze risks in second quadrant

Copyright © 2011 Hassan Gomaa 25

Figure 5.6 The spiral process model

1. Define objectives,
alternatives, and constraints 2. Analyze risks

4. Plan next cycle 3. Develop product

NB: This diagram does not use the UML notation

Copyright © 2011 Hassan Gomaa 26

 Unified Software Development Process
• Risk driven iterative process
– Also known as Rational Unified Process
• Workflow
– Sequence of activities that produces a result of observable value
• Workflows in Unified Process
– Requirements
• Product: Use case model.
– Analysis
• Product: Analysis model.
– Design
• Products: design model and deployment model.
model
– Implementation
• Product: software implementation
– Test.
• Products: Test cases and test results

Copyright © 2011 Hassan Gomaa 27

Unified Software Development Process

• Phase
– Time between two major milestones
• Phases in Unified Process
– Inception
• Seed idea is developed
– Elaboration.
• Software architecture is defined
– Construction.
• Software is built to the point at which it is ready for release
– Transition.
• Software is turned over to the user community.

Copyright © 2011 Hassan Gomaa 28

 Figure 3.5: Unified Software Development Process

Phases

Core Workflows Inception Elaboration Construction Transition

Requirements

Analysis

Design

Implementation

Test

iteration iteration --- --- --- --- --- iteration iteration

#1 #2 #n-1 #n

Iterations
Copyright © 2011 Hassan Gomaa 29

Software Design Concepts

• Objects and Classes

• Information Hiding
• Inheritance
• Concurrency
• Finite State Machines

Copyright © 2011 Hassan Gomaa 30

 Objects and Classes

• Objects represent “things” in real world

– Provide understandingg of real world
– Form basis for a computer solution
• An Object (object instance) is a single “thing”
– E.g., John’s car
– Mary’s account
• A Class (object class) is a collection of objects with the same
characteristics
– E.g., account, employee, car, customer
• Figure 2.2 UML notation for objects & classes
• Figure 3.1 Example of classes and objects

Copyright © 2011 Hassan Gomaa 31

Figure 2.2 UML notation for objects & classes

Class Class
Class
attributes attributes

operations

Class Class with attributes Class with attributes and operations

anotherObject
anObject :Class
:Class

Objects

Copyright © 2011 Hassan Gomaa 32

 Figure 3.1 Example of classes and objects
Class

Customer Account

Objects

anotherCustomer
aCustomer:Customer
:Customer

anAccount :Account

Copyright © 2011 Hassan Gomaa 33

Attributes
• Attribute
– Data value held by object in class
• Example of Attributes
– E.g., account number, balance
• Each object instance has specific value of attribute
– John’s account number is 1234
a y s account
– Mary’s accou t number
u be iss 5678
• Attribute name is unique within class
• Figure 3.2 Example of class with attributes

Copyright © 2011 Hassan Gomaa 34

 Figure 3.2 Example of class with attributes

Class with attributes

Account
accountNumber : Integer
balance : Real

Objects with values

anAccount: anotherAccount:
Account Account
accountNumber = 1234 accountNumber = 5678
balance = 525.36 balance = 1,897.44

Copyright © 2011 Hassan Gomaa 35

Classes and Operations

• Operation
– Is function or procedure that may be applied to objects in a class
– All objects in class have same operations
• Class has one or more operations
– Operations manipulate values of attributes maintained by object
• Operations may have
– Input parameters
– Output parameters
– Return value
• Signature of operation
– Operation
Operation’ss name
– Operation’s parameters
– Operation’s return value
• Interface of class
– Set of operations provided by class
• Figure 3.3 Class with attributes and operations
Copyright © 2011 Hassan Gomaa 36
 Figure 3.3 Class with attributes and operations

Account

accountNumber : Integer
balance : Real
readBalance () : Real
credit (amount : Real)
debit (amount : Real)
open (accountNumber : Integer)
close ()

Copyright © 2011 Hassan Gomaa 37

Information Hiding

Each object hides design decision

E.g.,
g , data structure
interface to I/O device
Information hiding object
Hides (encapsulates) information
Accessed by operations
Basis for Object-Oriented
j Design
g
Advantage
Objects are more self-contained
Results in more modifiable -> maintainable system

Copyright © 2011 Hassan Gomaa 38

 Example of Information Hiding

• Example of Stack
• Conventional approach
– Stack data structure is global
– Stack accessed by modules
– Module corresponds to procedure / function / subroutine
– Problem
– C
Change
a ge to stack
stac data st
structure
uctu e has
as global
g oba impact
pact
• Consider
– Array implementation (Fig. 3.4) changed to
– Linked list implementation (Fig. 3.6)
• Every module is impacted by change
Copyright © 2011 Hassan Gomaa 39

Figure 3.4 Example of Global Access to Data

Stack Implemented
As Array
Module Module
A B
PUSH POP

N MAX SIZE = N

X INDEX

Stack Array

Copyright © 2011 Hassan Gomaa 40

 Figure 3.6 Example of Global Access to Data

Stack Implemented
As Linked List

Module Push Pop Module

X
A B

Top

Bottom

Copyright © 2011 Hassan Gomaa 41

Example of Information Hiding

• Example of Stack
• Information hiding solution
– Hide stack data structure and internal linkage
– Specify operations on stack data structure
– Access to stack only via operations
• Consider
– Array implementation (Fig. 3.5) changed to
– Linked list implementation (Fig. 3.7)
• Change to stack only impacts Stack object

Copyright © 2011 Hassan Gomaa 42

 Figure 3.5 Example of Information Hiding

Push (X) Pop (X) Empty Full

MAX SIZE

Stack INDEX
X
Information
Hiding
Object

Stack Array

Copyright © 2011 Hassan Gomaa 43

Stack
Figure 3.7 Example of Information Hiding
Information
Hiding
Object

Push (X) Pop (X) Empty Full

# Entries Top

Max Size Bottom

Stack Linked List

Copyright © 2011 Hassan Gomaa 44

 Inheritance in Design
• Subclass inherits generalized properties from superclass
• Inheritance
– Allows sharing of properties between classes
• Property is Attribute or Operation
– Allows adaptation of parent class (superclass) to form
child class (subclass)
• Subclass inherits attributes & operations from superclass
– Mayy add
dd attributes
bu es
– May add operations
– May redefine operations

Copyright © 2011 Hassan Gomaa 45

Generalization / specialization hierarchy

«entity»
Account

accountNumber: Integer
balance: Real

«entity» «entity»
CheckingAccount SavingsAccount

lastDepositAmount: Real interest: Real

Copyright © 2011 Hassan Gomaa 46

 Sequential & Concurrent Problems

Sequential problems
Activities happen in strict sequence
E.g., compiler, payroll
Sequential solution = program
Concurrent problems
Many activities happen in parallel
E g multi-user
E.g., multi user interactive system,
system air traffic
control system
Sequential solution to concurrent problem increases
design complexity

Copyright © 2011 Hassan Gomaa 47

Concurrent and Real-Time Systems

• Concurrent System
– Consists of many activities (tasks) that execute in
parallel
• Real-Time system
– Concurrent system with timing deadlines
• Distributed application
– Concurrent system executing on geographically
distributed nodes

Copyright © 2011 Hassan Gomaa 48

 Concurrency

• Characteristics
C c e s cs ofo concurrent
co cu e task s
– A.k.a. (lightweight) process, thread
• Active object, concurrent object
– One sequential thread of execution
– Represents execution of
• Sequential program
• Sequential part of concurrent program
– Concurrent system
• Many tasks execute in parallel
• Tasks need to interact with each other

Copyright © 2011 Hassan Gomaa 49

Producer Task Consumer Task

Message Queue
Send Message Wait for Message

Asynchronous Message Communication between Concurrent Tasks

Copyright © 2011 Hassan Gomaa 50

 Finite State Machines
• Many information and real-time systems are state
dependent
– Action depends not only on input event
– Also depends on state of system
• Finite State Machine
– Finite number of states
– Only in one state at a time
• State
– A recognizable
g situation
– Exists over an interval of time
• Event
– A discrete signal that happens at a point in time
– Causes change of state

Copyright © 2011 Hassan Gomaa 51

Figure 10.4 Partial statechart

Brake Pressed
Initial Braking Initial Not Braking
Brake Released

Accel

Accelerating

Copyright © 2011 Hassan Gomaa 52

 Software Design Terminology
Design concept or principle
Fundamental idea that can be applied to designing a
system,
y e.g.,
g information hidingg
Design notation or representation
A means of describing a software design
Textual and Graphical, e.g., UML
Design strategy
Overall plan and direction for performing design
Design structuring criteria
Guidelines for decomposing a system into its parts

Copyright © 2011 Hassan Gomaa 53

Software Design Method

Systematic approach for creating a design

Design decisions to be made
Order in which to make them
Describes sequence of steps for producing a design
Based on set of design concepts
Employs design strategy(ies)
Provides design structuring criteria
Documents resulting design using design notation(s)

Copyright © 2011 Hassan Gomaa 54

 Example of Software Design Method
Structured Design
Design concept
Functional module
D i structuring
Design i criteria
i i
Module Cohesion criteria
Unity within module
Module Coupling criteria
Connectivity between modules
Design
g strategy
gy
Transaction Analysis and Transform Analysis
Design notation
Structure charts
Program Design Language (PDL)

Copyright © 2011 Hassan Gomaa 55

Design Strategies
Transform Analysis
• Structured Analysis
- Data flow diagram

Physical Logical Logical Physical

Input Input Output Output
Data Data Data Data
Read Process Write

• Structured Design Supervisor

- Structure Chart Module
Logical Logical
Input Output
Data Logical Logical Data
Input Output
Data Data

Input Central Output

Module Transform Module

Copyright © 2011 Hassan Gomaa 56

 Example of Software Design Method
COMET

Design concepts
Finite state machine, concurrent task, information hiding
Design structuring criteria
Object, subsystem and task structuring criteria
Design strategy
Develop analysis model, then map to design model
Design
g notation
UML (Unified Modeling Language)

Copyright © 2011 Hassan Gomaa 57

Example of Software Design Method

COMET
ClassWhole
View
Workstation
Status

Factory Operator
ClassPart1 ClassPart2
V1:
Operator
Request «user interface»
:Operator
Interface
V1.3:
Displayed Info
:FactoryOperator
V1.1: Workstation V1.2:
Status Workstation
Request Data

«entity»
:Workstation
Status
Server
Copyright © 2011 Hassan Gomaa 58
 Review
• Follows general guidelines of Software Engineering Body
of Knowledge (SWEBOK) – Chapter 3 Software Design
• Published byy IEEE – 2004 Version
– Fundamentals of Software Design
– Software Design Process
– Software Design Concepts
– Software Design Notations and Methods

Copyright © 2011 Hassan Gomaa 59