CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Chapter 10
CS 8532: Advanced Software Engineering
Dr. Hisham Haddad
Class
will
start
momentarily.
Please Stand By …
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Architectural Design
Highlights of data design and
architectural styles
Chapter 10
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Mapping Analysis to Design
Component
design
DFD
ERD
Data
Dictionary
STD
interface
design
Architectural
Design
Data Design
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Data Design - 2
Data design steps (at component level):
- Refine data objects (from ERD 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 is 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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Data Design - 3
Few important data design principles:
- The systematic analysis principles applied to functions and
behavior should also be applied to data (upfront work on data
objects)
- All data structures and the operations to be performed on each
should be identified (define efficient operations)
- A data dictionary (classes) should be established and used to
define both data and program design (have more details in the
dictionary (data objects))
- Low-level data design decisions should be deferred until late in
the design process (abstraction in SRS, refinement during data
design, implementation details during component design)
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Data Design - 4
- The representation of data structure should be known only to
those modules that must make direct use of the data
(Information hiding and coupling)
- A library of useful data structures and their operations should be
developed (effective, robust, and reusable design)
- A software design and programming language should support
the specification and realization of abstract data types (know
supporting features of the implementation language)
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 software! It is a
representation that enables engineers 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
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Why an Architecture is Important?
- Representations of software architecture promote
communications between all stakeholders interested in the
system.
- The architecture highlights early design decisions that will have
a profound impact on subsequent work and the success of the
final operational system.
- The architecture represents “intellectually graspable model” of
how the software is structured and how components will work
together.
Note: architecture styles and patterns are applied software design.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Architectural Styles
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Taxonomy of Architectural Styles
An architectural style is the structural organization of components
in the architecture. It is characterized by
- type of components (data and processing elements)
- type of connectors (communications among components)
- constraints (restrictions and rules on data, process, and
interfaces among components)
- semantic models to help designers understand the properties of
a system.
Architectural styles represent families of software architectures.
Each style requires different design details.
Data-Centered, Data-Flow, Call-and-Return, Layered, and OO
are just few examples of architectures styles.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Data-Centered Architecture
Promotes independent components (integrateability)
Example:
Airline
reservation
system
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Data Flow Architecture
Data transformation (pipe and filter) model.
Input/output
formats are
required.
Example:
Engineering
or Scientific
applications
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Layered Architecture
Layer of components are defined for specific tasks
Example:
Client/Server
applications
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Architectural Design - 4
More refinement
(Instantiation of
Components)
SafeHome
Executive
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
sens
ens
or
sens
or
sens
or
sens
or
sens
or
or
ssens
or
s
ens
or
sensor
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Analyzing Architectural Designs - 2
- Architectural Complexity:
It is the degree of coupling (dependency) among architecture
elements (sharing, flow, constraints 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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Structured Design - 1
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Structured Design - 2
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Mapping Method
DFD
Transformation
Or
Transaction Mapping
Program
Architecture
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Flow Characteristics
Transform flow
boundary
Transaction flow
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transform Mapping Steps - 1
1) Review and refine data flow diagrams.
DFDs must be detailed in order to transform them into
components (each process on the DFD performs one task).
2) For each DFD, isolate its transform center (DFD process(es)
that transform inputs to outputs) from processes that handle
inputs and outputs (draw incoming and outgoing flow
boundaries).
3) Perform level-1 factoring to determine control modules
This results in a high-level structure where top-level modules
are control modules and low-level models are processing
modules.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transform Mapping Steps - 2
4) Perform level-2 factoring to determine control modules for
processes that handle inputs and outputs of the transform
center. This adds more components to the structure resulted in
step 3.
5) Repeat those steps for each DFD to compile the first-iteration
architecture.
8) Evaluate and refine the architecture as needed.
Note: mapping between processes on the DFD and modules on
the structure may not necessarily be one-to-one mapping.
A number of processes my be transformed into one module.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
DFD Transformation
DFD
Program
Architecture
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Architecture Partitioning - 1
Define separate branches of the module hierarchy for each major
function. Use control modules to coordinate communication
between functions
function 3
function 1
function 2
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Architecture Partitioning - 2
Define decision making and work modules. Decision making
modules should reside at the top of the architecture.
decision-makers
workers
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Factoring
direction of increasing
decision making
typical "decision
making" modules
typical "worker" modules
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Level 1 Factoring
main
program
controller
input
controller
processing
controller
output
controller
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Level 2 Factoring
main
D
C
control
B
A
A
B
C
mapping from the
flow boundary outward
D
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transform mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
h
i
j
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transaction Mapping Steps
1. Isolate the incoming flow path
2. Define each of the action paths
3. Define the reception, control, and dispatch modules
4. Assess the flow on each action path (transform or transaction)
5. Map processes of each action path individually to the
corresponding modules
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transaction Flow
incoming flow
action path
T
action path
action path
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
program structure
i
g
h
l
k
j
m
t
b
a
x2
n
d
e
x4
x3
f
g
l
x3.1
h
j
i
k
m
n
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Level 1 DFD
Error message
commands
operator
fixture
servos
status
read
operator
commands
fixture
determine
command
type
Valid
command
analyze
fixture
status
select report report
Fixture setting
display
screen
control robot
generate
send
control
value
assembly record
robot control
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Level 2 DFD - Isolate Flow Paths
error msg
command
produce
error msg
read
command
invalid command
command validate
command
fixture setting
status
format
setting
read
fixture
status
determine
setting raw setting
combined
status
determine
valid command type
robot control
read
record
record
calculate
output
values
send
control
value
start/stop
assembly
record
values
format
report
report
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Map The Flow Model
process
operator
commands
command
input
controller
read
command
validate
command
determine
type
produce
error
message
fixture
status
controller
report
generation
controller
send
control
value
each of the action paths must be expanded further
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Refine The Structure Chart
process
operator
commands
command
input
controller
read
command
validate
command
read
fixture
status
determine
type
produce
error
message
determine
setting
fixture
status
controller
format
setting
report
generation
controller
read
record
send
control
value
calculate
output
values
format
report
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Example Processing Narrative
noun-verb
parse
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
the robot control system.
Process operator command software reads operator commands from
the cell operator. An error message is displayed for invalid commands.
The command type is determined for valid commands and appropriate
action is taken. When fixture commands are encountered, fixture
status is analyzed and a fixture setting is output to the fixture servos.
When a report is selected, the assembly record file is read and a
report is generated and displayed on the operator display screen.
When robot control switches are selected, control values are sent to
the robot control system.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
Then what?
Once an architecture is derived,
- write process narrative for each module (tasks, data structures,
I/O, constraints/limitations (data types, format, timing, memory,
data value ranges, special data/cases boundaries processing).
- write interface description for each module and entity.
- describe local and global data structures the module needs
access to.
- conduct design reviews and refine it as needed.
Focus on smaller number of modules (with high cohesion and
low coupling) and simple data structures.
CS 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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 8532: Adv. Software Eng. – Spring 2009
Dr. Hisham Haddad
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!