CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 9
Design Engineering
Highlights of Software Design
Concepts and Principles
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
What is Software Design?
Design is a technical activity during which customer requirements
are transformed into architectural elements (blue print for the
software to be built).
- It answers the “how” question: How to realize the requirements?
- It is iterative (refinement) process
- Its representation can be assessed for quality (FTRs,
Walkthroughs, informal meetings, etc…)
- It is the basis for system flexibility, extensibility, portability,
and reusability
- It consists of process (sequence of steps) and a model
(presentations of design elements)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Software Design Challenges
- Complexity: complexity factors,
> nature of the system (having many states during execution)
> complexity is arbitrary as it is dependent on the design
rather than the problem
- Conformity: must conform to standards forced by other
elements such as HW, existing software, external entities
- Invisibility: being invisible,
> limits our ability to form a visual links with software system
> limits our ability to conceptualize its characteristics
- Changeability: Software tends to have constant need for
changes.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
The Big Picture - Process & Model
modeling
Specs
Design
Process
Design’s
decisions
Prototype
Design
Model
(SDD)
Constraints
(resources,
organizational,
reuse, experience,
etc..)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OOA and OOD - 1
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Class
Modeling
Object
Relationship
Modeling
Object
Behavior
Modeling
OO Analysis
OO Design
Implementation
OO Testing
Deployment
Sub-System
Design
Message
Design
Class
Design
Responsibilities
Design
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OOA and OOD - 2
Another mapping view:
Analysis Model
Classes
Design Model
Objects
Attributes
Data Structures
Methods
Algorithms
Relationships
Messaging
Behavior
Control
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Mapping OO Analysis to OO Design
Attributes
Operations
Collaborators
Class
Model
Object
Relationships
Use
Cases
Responsibilities
Design
Message
Design
Class/Object Design
Object
Behavior
Model
Subsystem Design
Design Patterns
(domain Objects)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OOD Layers - 1
- Design Patterns: Deals with reusable designs (domain
objects).
(repeated (reusable) classes and objects that found to solve
specific design problems, e.g., user login and authentication,
integrated circuit, car air-condition system, shopping cart,
etc…)
- Subsystem Design: Deals with subsystems that form the
overall system architecture.
(detailed design of self-contained and highly-independent
groups of classes that define specific requirements (major
functions of the system))
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OOD Layers - 2
- Class/Object Design: Deals with relationships among classes
that define each subsystem.
(detailed design of inheritance hierarchies for subsystems)
- Message Design: Deals with internal and external interface
design.
(detailed design of messages exchanged among objects and
interactions between system objects and external entities)
- Responsibilities Design: Deals with data structures and
algorithm design.
(internal detailed design of each class - its attributes and
operations)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Concepts
Essential design concepts include:
-
Abstraction: data, procedure, control
Refinement: elaboration of detail for all abstractions
Modularity: compartmentalization of data and function
Software Architecture: overall structure of software components
Data Structures: logical relationships among data elements
Information Hiding: controlled interfaces/access
Functional Independence: high cohesion and low coupling
Refactoring: reorganization technique that simplifies the design
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Abstraction
Mutli-level details of the software design. Each level is a
refinement of the previous level (data and procedures).
At the highest level --> general description of the system
At the lowest level --> creating source code
Door Data
Manufacturer
Model number
Material type
Swing direction
Color
Weight
etc…
Door Procedures
Open Door
Close Door
Lock Door
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Refinement
Stepwise top-down elaboration of abstractions to reveal their
detailed as design progresses.
Refinement prevents omissions of details and facilitates design
review.
Refinement complements abstraction.
Walk to door;
Reach for knob;
Open door;
Walk through;
Close door;
repeat until door opens
turn knob clockwise;
if knob doesn't turn, then
take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Modularity - 1
easier to build, easier to change, easier to fix ...
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Modularity - 2
Dividing the system into manageable functional components.
A modular design is easier to build, to change, and to fix.
Effective modular design is depended on the design method.
Guidelines for design method evaluation include:
-
Modular decomposability (support for sub-problems)
Modular compensability (allow reuse)
modular understandability (can a module stand on its own?)
Modular continuity (change impact contained to individual
modules, not the entire system)
- Modular protection (error impact is contained within the module
where it occurred)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Modularity - 3
What is the right number of modules for a specific design?
module development cost
cost of
software
module
integration
cost
number of modules
desired number of modules
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Software Architecture
“The overall structure of the software and the ways in which that
structure provides conceptual integrity for a system.” [SHA95a]
Organization (structure) of components representing elements of
the software and their interactions (Ch-10).
Properties of an architectural design include:
- Structural properties (components and interactions)
- Extra-structural properties (performance/reliability/security…)
- Families of related systems (reusable architectural building
blocks - reusable subsystems and patterns)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Data Structures
Data structure is a representation of the logical relationship
among data elements of a data object.
The logical relationship dictates the data structure complexity.
- scalar structure: one data item structure
- sequential (linear) structures: vectors (arrays) of data items
- multi-dimension (non-linear) structure: array of data items
The implementation view is the organization of data items in the
computer memory during software execution.
- contiguous storage
- linked storage (linked lists)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Information Hiding - 1
It calls for hiding maximum information (procedures and data)
from other modules to provide controlled access.
Module
Controlled Interface
• algorithm
• data structure
clients
"secrets"
specific design
decisions
• details of external interface
• resource allocation policy
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Information Hiding - 2
Some benefits:
-
Reduces the likelihood of “side effects”
Limits the global impact of local design decisions
Emphasizes communication through controlled interfaces
Discourages the use of global data
Leads to encapsulation - an attribute of high quality design
Results in higher quality software
Facilitates maintainability
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Functional Independence
Functional independence is the outcome of abstraction,
modularity, and information hiding.
An independent function is one that performs (implements) a welldefined function (sub-function) of the software with high
cohesion and low coupling.
Cohesion measures the degree to which a module performs one
and only one function/task with little interactions with other
modules.
Coupling measures the degree to which a module is connected to
(dependents on) other modules in the system.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Refactoring
Fowler [FOW99] defines Refactoring in the following manner:
"Refactoring is the process of changing a software system in
such a way that it does not alter the external behavior of the
code [design] yet improves its internal structure.”
During refactoring, the design is examined for :
- Redundancy
- Unused design elements
- Inefficient or unnecessary algorithms
- Poorly constructed or inappropriate data structures
- Any other design failure that can be corrected to yield a better
design.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
OO Design Concepts
• Design classes
– Entity classes
– Boundary classes
– Controller classes
• Inheritance: All responsibilities of a superclass is immediately
inherited by all subclasses
• Messages: Stimulate some behavior to occur in the receiving
object
• Polymorphism: A characteristic that greatly reduces the effort
required to extend the design
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Classes
• Analysis classes are refined during design to become entity
classes.
• Boundary classes are developed during design to create the
interface (e.g., interactive screen or printed reports) that the
user sees and interacts with as the software is used.
- Boundary classes are designed with the responsibility of managing
the way entity objects are represented to users.
• Controller classes are designed to manage
- The creation or update of entity objects;
- The instantiation of boundary objects as they obtain information
from entity objects;
- Complex communication between sets of objects;
- Validation of data communicated between objects or between the
user and the application.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Inheritance
Design options:
- The class can be designed and built from scratch. That is,
inheritance is not used.
- The class hierarchy can be searched to determine if a class
higher in the hierarchy (a superclass) contains most of the
required attributes and operations. The new class inherits from
the superclass and additions may then be added, as required.
- The class hierarchy can be restructured so that the required
attributes and operations can be inherited by the new class.
- Characteristics of an existing class can be overridden and
different versions of attributes or operations are implemented
for the new class.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Messages
:
:SenderObject
message (<parameters>)
:
:ReceiverObject
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Polymorphism
Conventional approach …
case of graphtype:
if graphtype = linegraph then DrawLineGraph (data);
if graphtype = piechart then DrawPieChart (data);
if graphtype = histogram then DrawHisto (data);
if graphtype = kiviat then DrawKiviat (data);
end case;
With polymorphism, all of the graphs become subclasses of a
general class called graph. Using overloading, each subclass
defines an operation called draw. An object can send a draw
message to any one of the objects instantiated from any one of
the subclasses. The receiving object invokes its own draw
operation to create the appropriate graph.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Model Elements - 1
• Data design element
– Data model  data structures (at component level)
– Data model  database architecture (at application level)
– Data model  data warehouse (at business level)
– Data structures influence the software architectural
• Architectural design element (floor plan)
An architecture is derived from:
– Application domain
– Analysis model (classes, their relationships, collaborations
and behaviors)
– Patterns and “architectural styles” (Chapter 10)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Model Elements - 2
• Component design element
It’s the design of internal data and algorithms details of classes.
(Chapter 11)
• Interface design element
It is the design of interactions with the system, including:
– the user interface (GUI elements) (Chapter 12)
– external interfaces to other systems, devices, networks, …
– internal interfaces between various design components.
• Deployment design element
It’s the design of the physical environment where the system
will be hosted and supported (networks, servers, users,
locations, etc…) (see figure 9.7, page 247)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Patterns
Design Pattern Template (handout and slides are posted)
Pattern name: Describes the essence of the pattern in a expressive name
Intent: describes the pattern and what it does
Also-known-as: lists any synonyms for the pattern
Motivation: provides an example of the problem
Applicability: notes specific design situations in which the pattern is
applicable
Structure: describes the classes that are required to implement the pattern
Participants: describes the responsibilities of the classes that are required to
implement the pattern
Collaborations: describes how the participants collaborate to carry out their
responsibilities
Consequences: describes the “design forces” that affect the pattern and the
potential trade-offs that must be considered when the pattern is
implemented
Related patterns: cross-references related design patterns.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Frameworks
• A framework is NOT an architectural pattern, but
implementation-specific reusable “code skeleton with a
collection of “plug points” (also called hooks and slots) that
allows designers/developers to adapt it to a specific domain of
applications. They are applied without changes.
• Gamma et al note that:
– Design patterns are more abstract than frameworks.
– Design patterns are smaller architectural elements than
frameworks.
– Design patterns are less specialized than frameworks.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design and Quality
What makes a good design?
• The design must implement all explicit requirements of the
analysis model, and must accommodate all implicit
requirements desired by the customer.
• The design must be a readable and understandable “guide” for
the construction team (development and testing people).
• The design should provide a complete picture of the software.
That is, modeling the data, functional, and behavioral from
implementation perspective.
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Principles - 1
Software design consists of a process and a model.
- The design process should not suffer from ‘tunnel vision’
(explore your options)
- The design should be traceable to the analysis model
(addressing all customer requirements,explicit and implicit)
- The design should not reinvent the wheel
(use existing solution structures - design patterns)
- The design should mimic the structure of the problem
(completeness, quality assessment, testing, etc…)
- The design should exhibit uniformity in style and format
(i.e., it appears to be done by one person!)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Design Principles - 2
- The design should exhibit well defined interfaces for
components and external entities (ease of integration)
- The design should be structured to accommodate change (ease
of re-organization and additions) and to degrade gently
(graceful termination of software)
- Design is not coding, coding is not design (abstraction levels)
- The design should be assessed for quality as it is being
created, not after the fact.
- The design should be reviewed to minimize conceptual errors
(that is, semantic errors rather than syntax)
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Consider working the following problems from the end of
chapter 9, page 251, for practice purpose:
9.1, 9.2, 9.3, 9.5, 9.7, 9.8, 9.9, 9.10, and 9.11
No submission is required. Think about these problems and
work them for yourself!
CS 3610: Software Engineering – Fall 2009
Dr. Hisham Haddad – CSIS Dept.
Last Slide
End of Chapter 9