CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Chapter 10
Architectural Design
Highlights of data design and
architectural styles
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Mapping Structured Analysis to Design
Component
design
DFD
ERD
Data
Dictionary
STD
interface
design
Architectural
Design
Data Design
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Mapping OO Analysis to 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 – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Data Design - 1
Data design is defining data structures and their relationships.
Data Modeling
(SRS)
Data
Structures
Component level
Databases
Application level
Data
Warehouses
Business/Domain
level
Data warehouse: Large and independent database that has access to
data stored in databases that serve a set of applications required by a
specific business domain (Data Mining area).
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Data Design - 2
Data design steps (at component level):
- Refine data objects (from ERD or Analysis Classes of SRS) and
develop a set of data abstractions (user’s view of data objects).
(e.g., attributes of student data object)
- Implement data object attributes as one or more data structures
(this influenced by attributes, their relationships, and their use in
the program).
(e.g., student_record: name, ID, Address, Phone#)
- Review data structures to ensure that appropriate relationships
have been established.
(e.g., student_record and class_list)
- Simplify data structures as needed.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Software Architecture
- Data Design: Represents the data component of the architecture
- Architectural Design: Represents the structure of software
components and their interactions (i.e., high-level organization
of components and how they work together).
- The architecture is not the operational! It is a representation that
enables a software engineer to:
1) analyze the design effectiveness for meeting system requirements
2) consider architectural alternatives early on so that design changes
can be made at low cost
3) reduce the risks associated with building the operational software.
4) facilitates ease of implementation
5) facilitates future updates
6) promote communications between all stakeholders
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Styles (1)
The architecture is a representation of the structure of
components and their interactions. That is, how components
(processing elements or modules) are organized (arranged)
and how they interact with each other.
An architecture (architectural style) has four elements:
- Components: processing elements that transform inputs to
outputs, and data components.
- Connectors: the “glue” or interfaces that hold the processing
elements together.
- Constraints: rules of how components interact with each other.
- Semantic models: information for understanding the system.
(Think of house architecture regardless of it style)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Styles (2)
An architectural style is a pattern of structural organization of
components in the architecture.
Each style requires different design details.
Examples:
Data-Centered
Data-Flow
Call-and-Return
Layered
OO
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Data-Centered Architecture
Promotes independent components (integrateability)
Example:
Airline
reservation
system
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Data Flow Architecture
Data transformation (pipe and filter) model.
Input/output
formats are
required.
Example:
Engineering
or Scientific
applications
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Call and Return Architecture
Promotes modular design (easy to modify and scale)
Can be:
- Main/Sub
architecture
- RPC
architecture
- OO
architecture
Example:
Any I-P-O
application
(survey
processing)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Layered Architecture
Layer of components are defined for specific tasks
Example:
Client/Server
applications
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Patterns
An architectural pattern represents a repeated aspect of the style.
The architectural style may include a number of patterns.
Examples:
• Concurrency: Applications must handle multiple tasks in a manner
that simulates parallelism (e.g.,OS process management pattern
and task scheduler pattern)
• Persistence: Data persists if it survives past the execution of the
process that created it. (e.g., DBMS storage and retrieval
capability pattern and application level persistence pattern that
builds persistence features into the application architecture)
• Distribution: Communicates among systems (or components of a
system) in a distributed environment (e.g., a broker that acts as a
“middle-man” between the client and a server)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Design - 1
1. The software
must be placed
into context.
That is, the design
should define
external entities
(other systems,
devices, people)
that the software
interacts with and
the nature of
the interaction.
Safehome
Product
control
panel
homeowner
See page 267 for roles.
Internet-based
system
target system:
Security Function
uses
surveillance
function
peers
uses
uses
sensors
sensors
(figure 10.6, page 268)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Design - 2
Controller
2. Define architectural
“archetypes”
Communicates
with
- An archetype is an abstraction
(abstract class) that represents
one element of system behavior.
- They are derived from the
analysis model.
- They require further refinement.
Node
(figure 10.7, page 269)
Detector
Indicator
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Design - 3
3. Define and refine software components that implement each
archetype. (figure 10.8, page 270)
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y
GUI
Surveillance
Int ernet
Int erface
Control
panel
processing
detector
management
alarm
processing
Home
management
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Architectural Design - 4
More refinement
(Instantiation of
Components)
SafeHome
Execut ive
External
Communication
Management
(Refinement of
SafeHome
Example)
Security
GUI
Internet
Interface
(figure 10.9,
page 271)
Control
panel
processing
Keypad
processing
detector
management
scheduler
CPdisplay
functions
alarm
processing
phone
communication
alarm
ssensor
ensor
sens
or
sensor
ens
or
sens
or
ssensor
sensor
sensor
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Analyzing Architectural Designs - 1
Methods for evaluating alternative architectural design:
- Architecture Trade-off Analysis Method (ATAM):
It is six steps approach developed by SEI
It is qualitative approach.
It is elimination process. A set of steps is applied to alternative
architectures to assess design trade-offs, and identify “sensitive
points” to quality attributes. See page 272 for analysis steps.
- Quantitative Guidance for Architectural Design: (not in the book)
Evolving research area that focus on defining quantitative
techniques for assessing quality attributes of an architecture
(design dimensions: such as performance, reliability, security,
maintainability, flexibility, testability, portability, interoperability,
reusability, etc…).
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Analyzing Architectural Designs - 2
- Architectural Complexity:
It is the degree of coupling (dependency) among architecture
elements (sharing, flow, constrained (control flow)
dependencies)
Architectural Description Language (ADL):
ADLs provide syntax and semantic description of the design
(diagrammatic and textual)
Example ADL tools: Rapide, UniCon, ACME, Aesop, UML, …
Please see Software Tools Box, page 275.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
10.6: Structured Design (self-reading)
Issue: There is no one particular approach for mapping
requirements to design. Common approaches are Structured
Design and OO Design.
Structured (data-flow) design is a method for deriving
Call-and-Return architecture from data flow diagrams. (i.e.,
using information flow for mapping requirements to design).
Objective: to derive a top-down architecture that is partitioned
and modular.
Approach:
- the DFD is mapped into a program architecture (modules)
- the PSPEC and STD are used to indicate the content of each
module (component level design, Ch-12)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Structured Design (self-reading)
Derivation methods:
- Transform Mapping: It is based on flow of data items between
processes on the DFD.
- Transaction Mapping: It is based on transaction flow between
processes. A transaction is a data item that triggers data flow
along different paths (think of a menu system).
Notation:
Structure chart
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Mapping Method (self-reading)
DFD
Transformation
Or
Transaction Mapping
Program
Architecture
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Design and Quality issues*
The quality of the design determines the success and quality of
the system to be built.
A quality system is that performs required tasks within specified
constraints.
Unlike physical products, software design does not have physical
properties that can be assessed against established measures
(length, weight, height, thickness, etc…)
A software design is assessed based on quality factors (called
“ilities”) including reliability, efficiency, maintainability, usability.
* Source: Software Engineering, 2nd ed., by David Budgen
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Reliability Factor
Reliability is related to the behaviour of the system.
The designer tries to ensure that the system is
- complete: does it handle all combinations of events and states?
- consistent: is the system behavior as expected and is it
repeatable?
- robust: a failure in one component should not “hung” the entire
system (ensure graceful termination in case of a failure)
In safety-critical systems, this factors is Dominant. Multiple
versions of the system (designed by different teams) may be
used (auto-pilot system)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Efficiency Factor
Efficiency is related to resource allocation (CPU time, memory,
disk space, network access, etc…)
The designer tries to predict the system needs of each identified
resource.
Some resources are more important than others for a particular
system.
Efficiency is difficult to deal with since it is based the designer's
projection of resource needs from the design.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Maintainability Factor
Maintainability is related to the life time of the system, which
relates to its cost.
The designer tries to structure the system such that future
modifications are easy to conduct.
Other elements that affect maintainability include names (variables
and procedures), documentation standards, presentation forms,
etc…
Implementation (coding) also affects maintainability (Inline
comments, documentation, headers, coding style, etc…)
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Usability Factor
Usability is related to user interface design.
The designer tries to ensure that interfaces
-
are easy to use and navigate
provide the user with control
reduce “user memory load”
are consistent
A “bad” interface makes a “good” system look “bad” from user
perspective.
Other factors such as testability, portability, and reusability have
special purposes in specific systems.
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Quality Attributes of Design
Other quality factors are assessed by identifying quality attributes
in the design, such as simplicity, modularity, coupling, cohesion,
information hiding, accuracy, consistency, completeness, etc…
For a given system and for a specific purpose (operations, update,
transfer, etc…), quality attributes must be identified for each
quality factors. (see examples next slides).
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Example - 1
Quality factors and attributes for a real-time control system.
Quality Factor
Purpose
Reliability
Quality Attributes
Accuracy
Completeness
Operation
Efficiency
Consistency
…
Storage Organization
Revision
Maintainability
CPU Utilization, …
Modularity
Testability
Structuredness …
...
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Example - 2
Quality factors and attributes for a compiler software.
Purpose
Operation
Quality Factor
Reliability
Completeness
Usability
Consistency
Maintainability
Accessibility
Revision
Legibility
Testability
Transfer
Quality Attributes
Accuracy
Modularity
Portability
Structuredness
Reusability
Machine Independence
...
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Suggested Problems
Consider working the following problems from chapter 10,
textbook, page 290:
10.1, 10.3, 10.4, 10.5, and 10.6.
NO submission is required. Work them for yourself!
CS 3610: Software Engineering – Spring 2009
Dr. Hisham Haddad – CSIS Dept.
Last Slide
End of Chapter 10