CSDP Preparation Course
Module III: Software Design
Specifications
The exam specific topics covered in this module are listed
below, and are the basis for the outline of its content
A. Software Design Concepts
B. Software Architecture
C. Software Design Quality Analysis and Evaluation
D. Software Design Notations and Documentation
E. Software Design Strategies and Methods
F. Human Factors in Software Design
G. Software and System Safety
Module III. Software Design
2
Objectives
After completing this module, you should be able to…
• To describe the efforts and thoughts behind software design
• To develop an understanding of the software design process
• To describe software design approaches
• To describe several software design techniques
• To contrast architectural design with detailed design
Module III. Software Design
3
Organization
The organization of information for each specification topic is as
follows:
• Topic Content Slides - detail the important issues concerning
each topic and support the module objectives
• Topic Reference Slides - detail the sources for the topical
content and provides additional references for review
• Topic Quiz Slides - allow students to prepare for the exam
Module III. Software Design
4
Introduction
• The main goal of the software engineering process is the
production of software that:
• Functions properly
• On time
• Within budget
• Meets end-users’ needs
• Software Design is a key piece of of this process
Module III. Software Design
5
A. Software Design Concepts
Definition of Software Design:
A problem solving process in which the designer applies
knowledge and experience to produce a
conceptualization that defines and describes a solution
to a problem
Software Design:
• Produces a description of the software’s internal
construction
• Describes the software’s architecture
• Bridges the gap between software requirements and
software code
Module III. Software Design
6
A. Software Design Concepts - 2
Software Design Description (SDD)
A Software Design Description (SDD) is a representation of
software created to facilitate analysis, planning,
implementation, and decision-making
An SDD is:
• Used as a medium for communicating software design
information
• Like a blueprint or model of the system
Module III. Software Design
7
A. Software Design Concepts - 3
•
•
•
The Problem with Software Design
Software requirements are frequently incomplete, incorrect, and
inconsistent
Requirements change over time during development
Is a "Wicked Problem”:
• Cannot be easily defined so that all stakeholders agree on the
problem to solve
• Require complex judgements about the level of abstraction at
which to define the problem
• Have no clear stopping rules
• Have better or worse solutions, not right and wrong ones
• Have no objective measure of success
• Require iteration-every trial counts
• Have no given alternative solutions-these must be discovered
• Often have strong moral, political or professional dimensions
Module III. Software Design
8
A. Software Design Concepts - 4
The Problem (cont.)
• Ill-Defined Problems:
• The problem it is not clear from the beginning on what
the problem is and thus, what a solution is
• Finding a solution requires in addition to find the real
problem
• Solving and specifying develop in parallel and drive each
other
• Solutions to Ill-Defined Problems:
• Often such that they still could be improved
• Up to the problem solver to decide when enough is
enough
Module III. Software Design
9
A. Software Design Concepts - 5
•
•
•
•
•
Key Definitions
Software Engineering: A discipline that encompasses the
process associated with software development, the methods
used to analyze, design and test computer software, the
management techniques associated with the control and
monitoring of software projects and the tools used to support
process, methods, and techniques
Analysis: A set of activities that attempt to understand and
model customer needs and constraints
Design: An activity that translates the requirements model
into a more detailed model that is the guide to
implementation of the software
Methodology: A codified set of procedures for some phase
of software engineering, such as analysis and design.
Abstraction: The level of technical detail of some
representation of a software system
Module III. Software Design
10
A. Software Design Concepts - 6
•
•
•
•
Key Definitions (cont.)
Preliminary Design: Creates representation of the data and
architecture
Detailed Design: A design activity that focuses on the
creation of an algorithm
Object-Oriented: An approach to software development that
makes use of a classification approach and packages data
and processing together
Prototyping: The creation of a model and the simulation of
all aspects of a product.
Formal Methods: A software engineering approach in which
specification and design are described using mathematicallybased formal notation
Module III. Software Design
11
A. Software Design Concepts - 7
The Design Process
Review - Definition of Design:
A problem solving process in which the designer applies
knowledge and experience to produce a conceptualization
that defines and describes a solution to a problem
Rational Unified Process (RUP)
Analysis & Design Workflow
Module III. Software Design
12
A. Software Design Concepts - 8
Activities Associated with the RUP Analysis & Design Discipline
Module III. Software Design
13
A. Software Design Concepts - 9
Artifacts Associated with the RUP Analysis & Design Discipline
Module III. Software Design
14
A. Software Design Concepts - 10
Software Design can be represented in many ways
Examples:
• Flow Charts
• Use-Case Realizations
• Data Flow Diagrams
• Pseudocode
• State Diagrams
• Activity Diagrams
• Subsystem Diagrams
• Text Documents
• Any combination of these
Module III. Software Design
15
A. Software Design Concepts - 11
Design Phases
Two Types of Design
1. Architecture
2. Detailed
Architecture Design
Specify components, their
interfaces, and their
interactions with other
components
Detailed Design
Specify the internal
structure and behavior of
each component
Module III. Software Design
16
A. Software Design Concepts - 12
Software Engineering Approaches
Several General Approaches to Software Engineering
• Top-Down
• Starts with the highest level of abstraction and recursively
fills in details of the subparts
• Bottom-Up
• Start with the lowest-level components and describe how
these work together to accomplish the system’s goals
• Opportunistic
• Some combination of the above two approaches
Module III. Software Design
17
A. References
[CD04] The Computer Dictionary http://www.computerdictionary.info,
2004
[CE96] CERN, “STING Software Engineering Glossary”,
http://www.apl.jhu.edu/Classes/Notes/Hausler/web/glossary.html,
1996
[DD88] Department of Defense, MIL-STD-2167A, 1998
[HR84] Rittel, H. J., and M. M. Webber (1984). "Planning problems are
wicked problems", In N. Cross (Ed.), Developments in Design
Methodology, Wiley, pp. 135-144.
[HR84] Rittel, H. J., and M. M. Webber (1984). Planning problems are
wicked problems, Wiley, 1984
[LB98] Bass, Len et al, p. 298, Software Architecture in Practice,
Addison-Wesley, Boston, 1998.
[RH97] Hubscher, Roland, “LBD Conceptual Design Problems”,
http://www.cc.gatech.edu/edutech/LBD/ill-defined-problems.html,
June 11, 1997
[RP03] Pressman, R.S. 2003, “Software Engineering Resources”,
http://www.rspa.com/spi/glossary.html
Module III. Software Design
18
A. References (cont.)
[RS04] IBM Rational Software, The Rational Unified Process
v2003.06.13, 2004
[SB97] Buckingham Shum, S., "Representing Hard-toFormalise, Contextualised, Multidisciplinary, Organisational
Knowledge“, 1997
[SD04] SmartDraw.com, http://www.smartdraw.com/tutorials,
2004
[SF03] SourceForge.net, http://cweb.sourceforge.net/cgibin/moin.cgi/ObjectFlow, 2003
Module III. Software Design
19
A. Quiz - 1
Which is a true statement regarding software design?
a) It produces a description of the software’s internal construction
b) It describes the software’s architecture
c) It bridges the gap between software requirements and software
code
1) a & c
2) b
3) a, b, & c
4) c
Module III. Software Design
20
A. Quiz - 2
The purpose of a Software Design Description is used to
document
a) requirements traceability
b) high-level design
c) low-level design
1) a & b
2) b & c
3) a, b, & c
4) b
Module III. Software Design
21
A. Quiz - 3
Detailed design
a) is also known as low-level design
b) specifies internal component structure
c) specifies component behavior
1) a & b
2) b & c
3) a & c
4) a, b, & c
Module III. Software Design
22
A. Quiz - 4
A.
B.
C.
D.
E.
Which of the following is not a valid design approach?
a) inside out
b) top-down
c) bottom-up
d) opportunistic
F. 1) a
G. 2) a & d
H. 3) b & d
I. 4) d
Module III. Software Design
23
A. Quiz - 5
Pseudocode is more appropriate for low-level design than
architectural design.
a.) True
b.) False
Module III. Software Design
24
A. Quiz - 6
Software design is most concerned with which of the following:
a.)
b.)
c.)
d.)
synthesizing a domain analysis into an implementation
defining components
describing a solution to some problem
the object-oriented architecture of the solution space
1.)
2.)
3.)
4.)
a
b
c
e
Module III. Software Design
25
B. Software Architecture
• Software architecture encompasses:
• Overall organization of the software system
• Selection of the structural elements and specification of
their
• Interfaces
• Behavior
• Composition of these elements into progressively larger
subsystems
• The architectural style
Module III. Software Design
26
B. Software Architecture - 2
Software architecture is also concerned with:
• Usage
• Functionality
• Performance
• Resilience
• Reuse
• Comprehensibility
• Economic and technology constraints and tradeoffs
• Aesthetics
Module III. Software Design
27
B. Software Architecture - 3
Architecture-Based Process
An example of an architecture-first approach:
1. Create the business case for the system
2. Analyze the requirements
3. Decide on a software architecture
4. Specify the architecture
5. Communicate the architecture
6. Evaluate the architecture
7. Implement the system based on the architecture
8. Ensure the implementation conforms to the architecture
Module III. Software Design
28
B. Software Architecture - 4
•
•
•
•
Introducing Model Driven Architecture
Relatively new approach to building software
Sponsored by the Object Management Group (OMG)
Based on a platform-independent model (PIM)
Described with Unified Modeling Language (UML)
Module III. Software Design
29
B. Software Architecture - 5
Model Driven Architecture (MDA)
Primary goals of MDA
• Portability
• Interoperability
• Reusability
Using these technologies:
Unified Modeling Language (UML)
Meta-Object Facility (MOF)
XML Meta-Data Interchange (XMI)
Common Warehouse Meta-model (CWM)
Module III. Software Design
30
B. Software Architecture - 6
MDA Overview
Model-Driven Architecture separates the specification of the
operation of a system from the details of the way that system
uses the capabilities of its platform.
MDA provides an approach for
• Specifying a system independently of the platform that
supports it
• Specifying platforms
• Choosing a particular platform for the system
• Transforming the system specification into one for a
particular platform
Module III. Software Design
31
B. Software Architecture - 7
Key Model Driven Architecture Concepts
System
Model
Model-Driven
Architecture
Viewpoint
View
Platform
Application
Platform Independence
Viewpoints
Computation Independent Model (CIM)
Platform Independent Model (PIM)
Platform Specific Model (PSM)
Platform Model
Model Transformation
Pervasive Services
Implementation
Module III. Software Design
32
B. Software Architecture - 8
Definition of System:
A collection of elements that are organized to work together
to accomplish some goal
Module III. Software Design
33
B. Software Architecture - 9
Model
• A model is a representation of a system
• Often a combination of drawings and text
• The text may be in terms of
• A modeling language
• Natural language
• Another Definition of model:
A collection of views where each view describes a system
from a particular perspective
Module III. Software Design
34
B. Software Architecture - 10
Model Driven
An approach to system and software specification that focuses
on the evolution of one or more models, where each model
describes some relevant aspect of the system
Benefits:
• Facilitates communication
• Reduces complexity
Module III. Software Design
35
B. Software Architecture - 11
Viewpoints & Views
Viewpoint
Technique for abstraction using a selected set of
architectural concepts and structuring rules
View
A perspective of a system from a point of view of a
viewpoint
MDA prescribes 3 types of viewpoints
• Computation independent
• Platform independent
• Platform specific
Module III. Software Design
36
B. Software Architecture - 12
Platform
A platform is a set of subsystems and technologies
Provides a coherent set of functionality through
• Interfaces
• Usage patterns
Any application supported by that platform can use without
concern for the details of how the functionality provided by
the platform is implemented
Examples:
• J2EE
• Microsoft Windows
• Linux
Module III. Software Design
37
B. Software Architecture - 13
Platform Independence
• Quality of a model
• Not specific for a particular platform
• Able to be implemented on any number of platforms, as
appropriate
CORBA
J2EE
A platform independent distributed messaging model could be
implemented, for example, on either CORBA or J2EE
Module III. Software Design
38
B. Software Architecture - 14
•
•
•
•
Computation Independent Model (CIM)
View of the system independent of the system structure
Also known as a domain model
• Terminology familiar to those in the application’s domain
Bridges the gap between domain experts and design experts
Facilitates clear specification of the problem domain
Brake
VS.
Landing Geer
Hydraulic Pump
Wheel
Main Geer
Module III. Software Design
Front Geer
39
B. Software Architecture - 15
•
•
•
•
Platform Independent Model (PIM)
More specific than a Computational Independent Model
Less specific that a Platform Dependent Model
Details of the implementation on a particular platform are
omitted
Could be implemented on multiple platforms
furnace
Temperature
VS.
On/Off
Module III. Software Design
40
B. Software Architecture - 16
Platform Specific Model (PSM)
• More specific than a Platform Independent Model
• Details of the implementation on a particular platform are
provided
• An implementation on a specific platform
Email
Server
Exchange
Web
Server
IIS
VS.
ISA
Firewall
Module III. Software Design
41
B. Software Architecture - 17
Model Transformation
Process by which one model is converted to another model in
the same system
Software examples:
Computation Independent Model to a Platform Independent
Model
Platform Independent Model to a Platform Specific Model
Analysis model to a design model
An implementation model to a deployment model
Module III. Software Design
42
B. Software Architecture - 18
MDA prescribes a series of model transformations
CIM to PIM to PSM
CIM
PIM
PSM
Use Cases
Analysis
Classes
Enterprise
Java Beans
Module III. Software Design
43
B. Software Architecture - 19
Manual vs. Automatic Transformations
• Manual transformations are the traditional approach
• Design decisions are made
• Design is implemented
• Low automation in most cases
• Component-based development is an improvement
• Canned, off-the-shelf middleware is common today
• IBM Websphere
• Microsoft .NET
• Application frameworks are also available
• Struts
• Java Server Faces
• Some tools available today can automate transformations
• Generate executable applications via the PIM
• E.g. Rational Rose Technical Developer, Telelogic TAU
Module III. Software Design
44
B. References
[LB98] Bass, Len et al, p. 298, Software Architecture in
Practice, Addison-Wesley, Boston, 1998.
[OG03] Object Management Group, Model Driven Architecture
Guide, v1.0.1, http://www.omg.org/mda, July 12, 2003
[RS04] IBM Corporation, 2004, The Rational Unified Process
v2003.06.13
Module III. Software Design
45
B. Quiz - 1
Architecture design deals with components and
a) their interfaces
b) class structures
c) their relationships
1) a
2) a & b
3) a & c
4) b & c
Module III. Software Design
46
B. Quiz - 2
Model Driven Architecture is an approach to specifying
architecture that uses:
a) Platform independent models
b) Platform specific models
c) Computation independent viewpoints
d) Model transformations
1)
2)
3)
4)
a&b
a, b, & d
d
all of the above
Module III. Software Design
47
B. Quiz – 3
A use case model is an example of a:
a) Computational independent model
b) Platform independent model
c) Platform specific model
1) a
2) b
3) c
Module III. Software Design
48
B. Quiz – 4
An architect is concerned about the system’s:
a.)
b.)
c.)
d.)
quality
usability
performance
maintainability
1.)
2.)
3.)
4.)
all of the above
a&d
b, c & d
c&d
Module III. Software Design
49
B. Quiz - 5
It is the responsibility of the architect to ensure the component
interfaces are used in the manner intended.
1.) True
2.) False
Module III. Software Design
50
C. Software Design Quality Analysis
& Evaluation
• Many methods to analyze design quality
• No single method, by itself, is sufficient
This module looks at quality programs in general and quality
design attributes in particular
Module III. Software Design
51
C. Software Design Quality Analysis
& Evaluation - 2
What is Quality?
• A measure of how good something is
• Very natural concept in traditional manufacturing
• Tolerance
• Capacity
• Strength
• Size
• Color
• Weight
• Not quite as natural for software
Module III. Software Design
52
C. Software Design Quality Analysis
& Evaluation - 3
Quality Concept
• Meaning of “quality” has evolved over time:
• Conforming to the specification
• Fitness for use
• 2 dimensional model
• “must have” vs.
• “nice to have”
Module III. Software Design
53
C. Software Design Quality Analysis
& Evaluation - 4
Total Quality Management
• Management strategy to embed quality awareness in all
processes
• Employs statistical methods
• Goal to do things right the first time instead of fixing later
• Metrics regarding failures are collected and analyzed
• Then the process that caused the failure is fixed
• Has roots in manufacturing
• But applicable to software development also
Module III. Software Design
54
C. Software Design Quality Analysis
& Evaluation - 5
Quality Management System
• Quality Management System (QMS) fathered by William
Deming
• Can be implemented with one of any number of quality
management programs
• Six Sigma
• ISO 9000 Series
• Total Quality Management (TQM)
• Malcolm Baldrige National Quality Award
• Recognizes high-quality U.S. companies
Module III. Software Design
55
C. Software Design Quality Analysis
& Evaluation – 6
Six Sigma
• Quality management program
• “Six Sigma” quality level goal
• Pioneered by Motorola
• Roughly fewer than 3.4 defects in one million
• Very difficult to achieve in practice
• Some market leaders have obtained six sigma
Module III. Software Design
56
C. Software Design Quality Analysis
& Evaluation - 7
ISO 9000 Series
• Another instance of a Quality Management System
• Guides the production of a product or service
• A series of standards:
• ISO 9000: Basic language for the entire ISO 9000 family
• ISO 9001: For organizations who design, develop, test,
install, and service their product
• ISO 9002: For organizations who test, install and service
a product
• ISO 9003: For organizations who test final products
• ISO 9004: Guidance for compliance and customer
satisfaction
Module III. Software Design
57
C. Software Design Quality Analysis
& Evaluation - 8
ISO 9000-3
• Software related, specifically for companies that
• Develop
• Supply
• Install
• Maintain
• End-to-end procedures to track products
• Guidelines for the application of ISO 9001 to the
development, supply, and maintenance of software
Module III. Software Design
58
C. Software Design Quality Analysis
& Evaluation - 9
Three Classifications of Quality
System quality attributes categories:
• Discernable by observing system execution
• E.g. performance, functionality, reliability
• Not discernable at runtime
• E.g. modifiability, portability, reusability
• Business qualities
• E.g. Time to market, marketability
Module III. Software Design
59
C. Software Design Quality Analysis & Evaluation
- 10
Quality attributes that are discernable at system runtime
Performance
Two Aspects of Performance:
1. Response time
2. Number of transactions per some time interval
Security
Measure of the system’s ability to resist unauthorized usage
Availability
Measure of the proportion of time a system is up and running
Functionality
Ability of the system to do the work for which it was intended
Usability
Extent to which a system is easy learn and use on an ongoing
basis
Module III. Software Design
60
C. Software Design Quality Analysis & Evaluation
- 11
Quality attributes that are not discernable at system runtime
Modifiability
Ability of the system to be enhanced and maintained over time
Portability
Ability of the system to run in different operating environments
Reusability
Ability of the system, or parts thereof, to be used to construct other
systems
Integrability
Ability of the various components of a system to be made to work
together
Testability
Ability to objectively measure the system against its requirements
Module III. Software Design
61
C. Software Design Quality Analysis & Evaluation
- 12
•
•
Business Qualities
Qualities that are related to business aspects
Time to Market
• Release before competition
• Release while demand for product exists
Marketability
• Cost
• Competition
• Target Market
Module III. Software Design
62
C. Software Design Quality Analysis & Evaluation
- 13
What is a Good Design?
•
•
•
•
•
•
•
Well Structured
Simple
Efficient
Adequate
Flexible
Practical
Implementable
Module III. Software Design
63
C. Software Design Quality Analysis & Evaluation
- 14
Design Quality
Techniques to assess design quality include:
• Design Verification
• Design Analysis
• Design Reviews
• Design Audit
• Informal Design Walkthrough
• Formal Design Inspection
Module III. Software Design
64
C. Software Design Quality Analysis
& Evaluation - 15
Design Inspections
•
•
•
•
•
Step-by-step review
Roles involved:
• Moderator
• Reviewer
• Author
• Scribe
Each step checked against a list of criteria such as
• Historical errors
• Programming standards
• Adherence to specifications
The developer is responsible for narrating the design
Design inspections should occur for
• Preliminary Design
• Detailed Design
• Implementation
Module III. Software Design
65
C. Software Design Quality Analysis
& Evaluation - 16
Design Walkthroughs
• Similar to inspections but:
• Developer does not narrate the design
• Team lead or architect leads the walkthrough
• Manual simulation of the system
• Intermediate results are recorded
• Good for simulating discussion
• Many errors are caught by the developer
Module III. Software Design
66
C. Software Design Quality Analysis
& Evaluation - 17
Quality Design Aspects
• Fan-Out
• The number of routines a given routine calls
• Information Hiding
• Abstraction technique that hides details behind and
interface
• Cohesion
• Cohesion refers to the degree to which a module’s
instructions are functionally related
• Coupling
• Level of dependency that exists between modules
Module III. Software Design
67
C. References
• [LB98] Bass, Len et al., Software Architecture in Practice,
Addison-Wesley, 1998
• [DP87] Parnas, D.L, and D. M. Weiss, Activity Design
Reviews: Principles and Practices, Journal of Systems and
Software, Vol. 7, 1987, pp. 259-265
• [IS96] IEEE Software, Keep It Simple, Vol. 13, No. 6,
December, 1996
• [PR04] Praxiom Research Group Limited,
http://praxiom.com/iso-9000-3b.htm
• [RP05] Pressman, Roger S., Software Engineering: A
Practitioner’s Approach, 6th Edition, McGraw-Hill, 2005
• [WA82] Adrion, W. Richards., Validation, Verification, and
Testing of Computer Software, ACM Computing Surveys, Vol
14, No. 2, June, 1982
Module III. Software Design
68
C. Quiz - 1
System performance attributes include the following:
a) Volume of transactions
b) Response time
c) Reliability of results
1)
2)
3)
4)
5)
a
b
c
a&b
all of the above
Module III. Software Design
69
C. Quiz - 2
A practical design should:
a)
b)
c)
d)
anticipate all future component uses
anticipate current and future requirements
provide the most cost-effective solution
specify the minimum number of components
1)
2)
3)
4)
5)
a
a&b
c
all of the above
none of the above
Module III. Software Design
70
C. Quiz - 3
Whether or not the software application is attractive to the target
audience is a valid quality attribute.
1.) True
2.) False
Module III. Software Design
71
C. Quiz - 4
Which of the following, if taken literally, is extremely difficult to
achieve:
a.)
b.)
c.)
d.)
Total Design Independence (TDI)
Six Sigma
Formal design inspection
Security
1.)
2.)
3.)
4.)
a
b
c
d
Module III. Software Design
72
C. Quiz - 5
Which can most readily be determined via a call tree?
a.)
b.)
c.)
d.)
Cyclomatic complexity
Cohesion
Coupling
Fan-Out
1.)
2.)
3.)
4.)
a
b
c
d
Module III. Software Design
73
D. Software Design Notations and
Documentation
• Structural Description Examples
• Class and object diagrams and their relationships
• CRC cards
• Entity-Relationship Diagrams (ERD) used to define
conceptual models of data
• Interface description language to deine the interfaces of
software components
• Structure charts to describe the calling structure of
programs
• Use case diagrams to model functional requirements
form the perspective of the user
Module III. Software Design
74
D. Software Design Notations and
Documentation - 2
Why We Model
• Top reasons for modeling software
• Provide the “blueprint” for our system
• Facilitate communication among project team members
• Assures architectural soundness
• Attributes of an appropriate modeling language
• Model elements
• Notation
Guidelines
• Guidelines
Model
Elements
Notation
Module III. Software Design
75
D. Software Design Notations and
Documentation - 3
Functional vs. Object Oriented
Two fundamental approaches to software design
• Functional
• Object-Oriented
Functional (a.k.a “Structured”) takes the approach that high
level functionality can be repeatedly broken down into
smaller and smaller functions in order to reduce complexity.
Object-Oriented takes the approach that functionality belongs
with “objects”, which are software elements that have identity
and whose state and behavior is self-contained.
Module III. Software Design
76
D. Software Design Notations and
Documentation - 4
Five Aspects of Structured Design
1. Form of the problem guides the form of the solution
2. Reduces complexity by organizing the system into a
hierarchy of “black boxes”
3. Uses graphical tools to render systems readily
understandable
4. Provides solution strategies based on a well-defined
problem statement
5. Provides criteria for evaluating the quality of the design
Module III. Software Design
77
D. Software Design Notations and
Documentation - 5
Four goals of Structured Design
1. Each black box should solve well-defined piece of the
problem
2. The system should be partitioned so that the function of
each black box is easy to understand
3. Partitioning should be done so that any connection between
black boxes is introduces only because of a connection
between pieces of the problem
4. Partitioning should assure that the connections between
black boxes are made as simple as possible
Module III. Software Design
78
D. Software Design Notations and
Documentation - 6
Key Structured Diagrams
Like any approach to software design, a structured approach
prescribes certain diagrams:
• Data Flow Diagram
• Shows the partitioning of the system into processes, data
sources, data sinks, and data stores
• Shows how data flows between these elements
• Structure Chart
• Shows the partitioning of a system into modules (black
boxes)
• Shows how modules communicate with each other
Module III. Software Design
79
D. Software Design Notations and
Documentation - 7
Data Flow Diagram Example
Data Source/Sink
Process
Data Flow
Data Store
Module III. Software Design
80
D. Software Design Notations and
Documentation - 8
Structure Chart Example
Module
Data
Call
Module III. Software Design
81
D. Software Design Notations and
Documentation - 9
Structured Transform: Process by which Data Flow Diagrams
(DFDs) are converted (transformed) into structure charts
• DFDs are considered the analysis artifact
• The resulting structure chart is the design artifact
Module III. Software Design
82
D. Software Design Notations and
Documentation - 10
Unified Modeling Language
What is it?
The Unified Modeling Language (UML) is a language for
specifying, visualizing, constructing, and documenting the
artifacts of software systems, as well as for business
modeling and other non-software systems. The UML
represents a collection of the best engineering practices that
have proven successful in the modeling of large and
complex systems.
-- OMG Unified Modeling Language Specification v1.5
Module III. Software Design
83
D. Software Design Notations and
Documentation – 11
•
•
•
•
•
•
•
•
History of the UML
In 1994 approximately 50 distinct, identifiable, objectoriented methods
Three popular methods:
• OOSE (Ivar Jacoboson)
• OMT-2 (James Rumbaugh)
• Booch 93 (Grady Booch)
Rational Software hires Rumbaugh to join Booch in 1994
Booch 93 and OMT-2 melded to create “Unified Method” 0.8
Jacobson joins Rational Software in 1995
Use cases merged into Unified Method to create UML 0.9
Rational partners with industry leaders in 1996 to respond to
OMG RFP
UML 1.0 accepted by OMG in 1996
Module III. Software Design
84
D. Software Design Notations and
Documentation - 12
The primary design goals of the UML:
• Provide users with a ready-to-use, expressive visual
modeling language to develop and exchange meaningful
models
• Furnish extensibility and specialization mechanisms to
extend the core concepts
• Support specifications that are independent of particular
programming languages and development processes
• Provide a formal basis for understanding the modeling
language
• Encourage the growth of the object tools market
• Support higher-level development concepts such as
components, collaborations, frameworks and patterns
• Integrate best practices
Module III. Software Design
85
D. Software Design Notations and
Documentation - 13
Scope of the UML
• In scope
• Model notation and semantics specification
• Extensibility mechanisms
• Model interchange mechanisms
• Common repository interface specification
• Out of scope
• Programming languages
• Tools
• Process
Module III. Software Design
86
D. Software Design Notations and
Documentation - 14
Primary Artifacts of the UML
• Use the ones appropriate for the task at hand
• Don’t have to use all artifacts
• No single view is sufficient
• Models can be expressed at different levels of detail
• The best models reflect reality
• Three categories of diagrams:
• Structure Diagrams
• Behavior Diagrams
• Implementation Diagrams
Module III. Software Design
87
D. Software Design Notations and
Documentation - 15
Diagrams in the UML
A diagram is the graphical presentation of a set of elements,
most often rendered as a connected graph of vertices
(things) and arcs (relationships) – Grady Booch
Static Diagrams
Dynamic Diagrams
•Use Case
•Statechart
•Class
•Activity
•Object
•Sequence
•Component
•Collaboration
•Deployment
Module III. Software Design
88
D. Software Design Notations and
Documentation - 16
Static
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Dynamic
Diagrams
Class
Diagrams
Use-Case
Diagrams
Models
Activity
Diagrams
Object
Diagrams
Component
Diagrams
Deployment
Diagrams
Courtesy IBM Rational Software
Module III. Software Design
89
D. Software Design Notations and
Documentation - 17
Class Diagram
Contains classes, interfaces, collaborations, and relationships
Models system vocabulary, collaborations, database schema
Module III. Software Design
90
D. Software Design Notations and
Documentation - 18
Object Diagram
Contains objects and links
Models objects structures and relationships
Module III. Software Design
91
D. Software Design Notations and
Documentation - 19
Use Case Diagram
Contains use cases, actors, and relationships
Models the context and requirements of a system
Inventory Reports
Inventory Maintenance
Manager
User Verification
<<include>>
Administrator
<<include>>
Store Clerk
Process Sale
User Maintenance
Module III. Software Design
92
D. Software Design Notations and
Documentation - 20
Sequence Diagram
Contains objects, links, and messages
Models flows of control by time ordering
: Store Clerk
: frmMain
: SalesTransaction
: LineItem
Related Product :
Product
: frmPayment
: Product
1: NewTransaction( )
steps 3 - 6
repeated for
each item
2: create
3: NewLineItem( )
4: create
5: addLineItem(LineItem)
6: f ind related product
7: FinishTransaction( )
8: create
9: enter payment info
10: completeTransaction( )
11: Product( )
12: adjustInventory(Integer)
repeated for
each item
Module III. Software Design
93
D. Software Design Notations and
Documentation - 21
Collaboration Diagrams
Contains objects, links, and messages
Models flows of control by logical organization
:
LineItem
6: find related product
Related Product
: Product
11: Product( )
4: create
:
frmMain
:
SalesTransaction
2: create
5: addLineItem(LineItem)
10: completeTransaction( )
12: adjustInventory(Integer)
8: create
:
frmPayment
1: NewTransaction( )
3: NewLineItem( )
7: FinishTransaction( )
:
Product
9: enter payment info
: Store Clerk
Module III. Software Design
94
D. Software Design Notations and
Documentation - 22
Statechart Diagram
Contains simple states, composite states, transitions
Models reactive objects
Module III. Software Design
95
D. Software Design Notations and
Documentation - 23
Activity Diagram
Contains action and activity states, transitions, and objects
Models a workflow or operation
Custom er : Custom er
...
S ales Cler k : Cler k
Billing S ystem
War ehouse
...
...
Product
Product
[Ordered]
[Selected]
...
...
...
In stock?
not v alid
y es
y es
Prov ide conf irmation
number
...
...
Ship
product
...
Product
[Shipped]
Module III. Software Design
96
D. Software Design Notations and
Documentation - 24
Component Diagram
Contains components, interfaces, and relationships
Models source code, executables, and physical
databases
OS
Services
Shipping
Service
LDAP
Customer
Validation
Register New
Customer
Customer
Database
Module III. Software Design
97
D. Software Design Notations and
Documentation - 25
Deployment Diagram
Contains nodes and relationships
Models details of various types of systems such as embedded,
client/server, distributed
Database
Server
Application
Server
LAN
LAN / WAN
Firewall
Windows
Client
Internet
Browser
Module III. Software Design
98
D. References
• [GB99] Grady Booch. The Unified Modeling Language User
Guide, Addison Wesley, Reading, MA, 1999
• [IE01] IEEE Computer Society, Guide to the Software
Engineering Body of Knowledge (SWEBOK), IEEE
Computer Society Press, Los Alamitos, CA 20001
• [MP80] Page-Jones, Meilir. The Practical Guide to
Structured Systems Design, Yourdon Press, NY, NY, 1980
• [OG03] Object Management Group (OMG), OMG Unified
Modeling Language Specification, v1.5, March 2003
Module III. Software Design
99
D. Quiz - 1
Which of these is not a stated reason for creating models:
a) Facilitate communication
b) Provide a blueprint for our system
c) Assures architectural soundness
d) Demonstrate progress
1. a
2. b
3. c
4. d
5. a & c
Module III. Software Design
100
D. Quiz - 2
A structured approach to software design is also known as:
a) Object-Oriented
b) Data-centric
c) Functional
d) Model-based
1. a
2. c
3. b & d
4. a & d
Module III. Software Design
101
D. Quiz - 3
A module is considered to be a(n):
a) Object
b) Program
c) Black-box
d) Component
1. a
2. b
3. c
4. c & d
Module III. Software Design
102
D. Quiz - 4
In a structured approach, a data flow diagram is transformed
into a:
a) Requirements
b) Design
c) Structure Chart
1. a
2. b
3. c
4. b & c
Module III. Software Design
103
D. Quiz - 5
Which of the follow is not true of the Unified Modeling
Language?
a) Defines a process for software specification
b) Facilitates the interchange of models
c) Specifies the interface to model repositories
1. a
2. a & c
3. b
4. all of the above are not true
Module III. Software Design
104
D. Quiz - 6
Identify which of the UML diagrams are static ("S") vs. dynamic
("D")
___ Activity
___ Class
___ Collaboration
___ Component
___ Deployment
___ Object
___ Sequence
___ Statechart
___ Use Case
Module III. Software Design
105
E. Software Design Strategies and Methods
• Design methods guide the software designer
• This section provides details on design
• Fundamentals
• Models
• Historical background
Module III. Software Design
106
E. Software Design Strategies and Methods - 2
•
•
•
•
•
Historical Perspective
Software design methodologies continue to evolve
Still a young, relatively immature science
Demands for new applications and major enhancements to
existing ones have grown dramatically
Successful projects have been the exception, not the norm
Problems due to inability to sufficiently:
• Translate complex problems to workable software
solutions
• Take end-user opinions and practical needs into account
• Take into account the organizational environment
• Accurately estimate the development time and cost, and
the operational costs
• Review the project progress with the customers in a
regular and consistent manner
• Anticipate performance/technology tradeoffs
Module III. Software Design
107
E. Software Design Strategies and Methods - 3
Historical Perspective (cont.)
• Late 60’s to early 70’s many important software engineering
concepts were introduced, including:
• Top-down design
• Stepwise refinement
• Modularity
• Structure programming
• These helped, but there was still a need for methodologies
that:
• Were more complete
• Were faster to use
• Were suitable for fourth-generation languages and
application generators
• Solved maintenance issues
• Were suitable for graphically-intensive applications
Module III. Software Design
108
E. Software Design Strategies and Methods - 4
Historical Methods
•
•
•
•
•
Flow charts
Program Design Languages (PDL)
Forms
Data structures
Data flow
Module III. Software Design
109
E. Software Design Strategies and Methods - 5
Object-Oriented Trend
• Object-oriented is a proven approach to the analysis and
design of large, complex computer systems
• Focuses on objects, their state and behavior
• As opposed to a functional decomposition approach
• CASE tools, 4th Generation Languages (4GLs), and design
languages supplement object-orientation, examples:
• Powerbuilder
• Visual Basic
• Unified Modeling Language
Module III. Software Design
110
E. Software Design Strategies and Methods - 6
More on Object-Oriented
• Origins in Smalltalk
• By Xerox Palo Alto Research Center (PARC)
• GUI-based IDE for O-O programming
• Why Object Oriented has caught on:
• Higher level focus (analysis/design vs. programming)
• Underlying support platforms are capable
• Proven for large, complex applications
• Domain-oriented trends of modern applications well
suited to object-orientation
Module III. Software Design
111
E. Software Design Strategies and Methods - 7
Beyond Waterfall
• The waterfall approaching to software development is not
appropriate for most projects
• Project on the road to failure frequently exhibit these
symptoms:
• Extended integration periods
• Late design breakage
• Late risk resolution
• Focus on documents and reviews
Requirements
Design
Implementation
Test
Module III. Software Design
112
E. Software Design Strategies and Methods - 8
Design Fundamentals
• Three aspects of all information systems:
• Data, structure, procedures
• Each of these are addressed during software design
• Data Design
• Architectural Design
• a.k.a. high-level or preliminary
• Procedural
• a.k.a low-level or detailed
Module III. Software Design
113
E. Software Design Strategies and Methods - 9
Design Fundamentals (cont.)
• Proven methods help designers by providing:
• A mechanism translating the physical problem to its
design representation
• A notation for representing functional components and
their interfaces
• Heuristics for refinement and partitioning
• Guidelines for quality assessment
• Fundamental concepts of software engineering:
• Stepwise refinement
• Architecture
• Program structure
• Data structure
• Modularity
• Abstraction
• Information hiding
Module III. Software Design
114
E. Software Design Strategies and Methods - 10
•
•
•
•
Fundamentals Defined
Stepwise Refinement
Abstraction
Software Architecture
Program Structure
Module III. Software Design
115
E. Software Design Strategies and Methods - 11
•
•
•
•
Fundamentals Defined (cont.)
Data Structure
Modularity
Software Procedure
Information Hiding
Module III. Software Design
116
E. References
• [RV95] Robert L. Vienneau and Roy Senn, A State of the Art
Report: Software Design Methods, Data & Analysis Center
for Software (DACS), March 1995
• [WR01] Walker Royce, Software Project Management, A
Unified Framework, Addison-Wesley, Boston, MA, 2001
Module III. Software Design
117
E. Quiz - 1
A functional decomposition approach to software design is
compatible with object-oriented techniques.
1) True
2) False
Module III. Software Design
118
E. Quiz - 2
Which lifecycle approach better handles requirements change?
a) Waterfall
b) Iterative
1) a
2) b
3) Not much difference
Module III. Software Design
119
E. Quiz - 3
The structure of a software system is addressed during
a) Data design
b) Architecture design
c) Detailed design
1) a
2) b
3) c
4) All, provided an iterative approach
Module III. Software Design
120
E. Quiz - 4
Stepwise refinement is a ________ approach.
a) Bottom-up
b) Top-down
c) Procedural
1) a & c
2) b & c
3) b
4) c
Module III. Software Design
121
E. Quiz - 5
Software procecure pertains to
a) the lifecycle model
b) the development process
c) software processing
d) subcontractor management
1) a
2) b
3) c
4) d
Module III. Software Design
122
F. Human Factors in Software Design
What is Human Factors Design?
• Specification of how users use a system
• Considers
• Working environment
• Background
• Ergonomics
• Cognitive capabilities
Module III. Software Design
123
F. Human Factors in Software Design
-2
User Interface Basics
• What is the User Interface?
• Menus
• Windows
• Keyboard
• Mouse
• Sounds
Module III. Software Design
124
F. Human Factors in Software Design
-3
UI Design Overview
• Interface must be match to the task
• Specific guidelines
• Menu design
• Icon labels
• Placement of screen elements
Module III. Software Design
125
F. Human Factors in Software Design
-4
User Interface Design
• Prototype User Interface
• Screen mock-ups
• Screen navigation
• Intended to obtain feedback
Module III. Software Design
126
F. Human Factors in Software Design
-5
•
•
•
•
Steps in defining the User Interface
Describe the characteristics of users
Define the navigation map
Detail the design of the user-interface elements
Design the user actions of the primary windows
Module III. Software Design
127
F. Human Factors in Software Design
-6
DoD Mil Std 1472
This standard establishes general human engineering criteria
for design and development of military systems, equipment
and facilities. Its purpose is to present human engineering
design criteria, principles and practices to be applied in the
design of systems, equipment and facilities so as to:
Achieve required performance by operator, control and
maintenance personnel
Minimize skill and personnel requirements and training time
Achieve required reliability of personnel-equipment
combinations
Foster design standardization within and among systems
Module III. Software Design
128
F. References
[CL94] Clayton Lewis and John Rieman, Task-Centered User
Interface Design: A Practical Introduction,
ftp://ftp.cs.colorado.edu/pub/cs/distribs/clewis/HCI-DesignBook, 1994
[DD89] DoD Military Standard 1472D Human Engineering
Design Criteria for Military Systems Equipment and
Facilities, March 14, 1989
[RS04] IBM Rational Software, The Rational Unified Process
v2003.06.13, 2004
Module III. Software Design
129
F. Quiz - 1
Human factors engineering is a subtopic of software
engineering.
a.) True
b.) False
Module III. Software Design
130
F. Quiz - 2
The user interface model traces to which other model?
a.)
b.)
c.)
d.)
Use case model
Business model
Implementation model
Deployment model
Module III. Software Design
131
F. Quiz - 3
The purpose of DoD Mil Std 1472 is to facilitate the
development of systems that:
a.) minimize the need for maintenance personnel
b.) minimize skill requirements for system usage
c.) achieve sufficient reliability of human-equipment
combinations
d.) standardize the approach to human factors implementation
1.)
2.)
3.)
4.)
all of the above
none of the above
b&c
b, c, & d
Module III. Software Design
132
F. Quiz - 4
Which type of system is has the least concern for human
factors:
a.)
b.)
c.)
d.)
a computer operating system
a batch process
a car radio
a voice activated dictation machine
1.)
2.)
3.)
4.)
a
b
c
d
Module III. Software Design
133
G. Software and System Safety
• Computers are pervasive
• Automobiles
• Consumer electronics
• Medical devices
• Avionics systems
• Weapon systems
• Virtually nothing manufactured in the U.S. today is not
impacted by computers
• Complexities are ever increasing
• Safety has been and will continue to be a very important
issue in software engineering
Module III. Software Design
134
G. Software and System Safety - 2
Types of Errors
•
•
•
•
•
Algorithmic faults
Computational faults
Documentation faults
Stress or overload faults
Capacity and boundary faults
Module III. Software Design
135
G. Software and System Safety - 3
•
•
•
•
•
More Types of Errors
Timing and coordination faults
Throughput and performance faults
Recovery faults
Hardware and system software faults
Standard and procedures faults
Module III. Software Design
136
G. Software and System Safety - 4
•
•
•
•
Hazard Identification
Easiest way to identify hazards is after the occurrence
Obviously the hazard should be avoided
The only valid method therefore is to develop a list of
potential hazards before the system is produced
Three techniques:
• Delphi
• Joint Application Design (JAD)
• Hazard and Operability Analysis
Module III. Software Design
137
G. Software and System Safety - 5
Analyzing Hazards
• The purpose of hazard analysis is to examin the system and
determine which components of the system may lead to a
mishap
• Two basic strategies:
• Inductive techniques, e.g. an event tree analysis and
failure modes and effects analysis
• Deductive techniques, e.g. fault tree analysis
Module III. Software Design
138
G. Software and System Safety - 6
•
•
•
•
•
Fault Tree Analysis
Starts with a particular undesirable event and provides an
approach for analyzing the causes of this event
Once the undesirable event has been chosen, it is used as
the top event of a fault tree diagram
The fault tree is a graphical representation of the various
combinations of events that lead to the undesired event
The system is then analyzed to determine all the likely ways
in which that undesired event could occur
The faults may be caused by component failures, human
failures, or any other events that could lead to the undesired
events
Module III. Software Design
139
G. Software and System Safety - 7
Event Tree Analysis
• Event tree analysis is to consider an initiating event in the
system and consider all the consequences of the occurrence
of that event, particularly those that lead to a mishap
• Fault tree analysis is backward looking and considers
knowledge of past problems
• Event tree analysis is forward looking and considers
potential future mishaps
Module III. Software Design
140
G. References
[PP92] Patrick R. Place and Xyo C. Kang, Safety-Critical
Software: Status Report and Annotated Bibliography,
CMU/SEI-92-TR-5, Carnegie Mellon, Pittsburgh, PA 1992
Module III. Software Design
141
G. Quiz - 1
It is easiest to identify hazards:
a.)
b.)
c.)
d.)
e.)
during the analysis phase
during design phase
during the construction phase
during the testing phase
post-deployment
1.)
2.)
3.)
4.)
5.)
a
b
c
d
e
Module III. Software Design
142
G. Quiz - 2
It is best to identify hazards:
a.)
b.)
c.)
d.)
e.)
during the analysis phase
during design phase
during the construction phase
during the testing phase
post-deployment
1.)
2.)
3.)
4.)
5.)
a
b
c
d
e
Module III. Software Design
143