Chapter 14 Software Design

Published on February 2017 | Categories: Documents | Downloads: 43 | Comments: 0 | Views: 270
of 4
Download PDF   Embed   Report

Comments

Content

Chapter

14

Software Design
CHAPTER OVERVIEW AND COMMENTS
The objective of this chapter is to provide a systematic approach
for the derivation of the architectural design. Architectural
design encompasses both the data architecture and the program
structure layers of the design model. A general introduction to
software architecture is presented. Examples are presented to
illustrate the use of transform mapping and transaction
mapping as means of building the architectural model using
structured design approach. Architectural modeling of objectoriented systems appears later in the text. Students should be
reminded that quality reviews need to be conducted for the
architectural model work products.
14.1 Software Architecture
This section defines the term software architecture as a
framework made up of the system structures that comprise the
software components, their properties, and the relationships
among these components. The goal of the architectural model is
to allow the software engineer to view and evaluate the system
as a whole before moving to component design. Students
should be encouraged to build architectural models of their own
software development projects.
14.2 Data Design
This section describes data design as the process of creating a
model of the information represented at a high level of
abstraction (using the customer's view of data). Students should
be reminded that careful attention to data structure design is at
least as important as the effort devoted to algorithm design.
Students should make an effort to learn definitions for the terms
data modeling, data structure, database, and data warehouse.
Students should be encouraged to use the principles of
component level data design presented in this section.

14.3 Architectural Styles
A taxonomy of architectural styles (design patterns) is described
in this section. With the exception of object-oriented
architectures, the architecture modeling technique discussed in
this chapter is generally applicable to each of these architectural
styles. However, the derivation of the call and return
architecture is emphasizes. Students should be encouraged to
use the questions dealing with control and data issues as basis
for assessing the quality of the initial architectural framework
before doing more detailed analyses of the proposed software
architecture.
14.4 Analyzing Alternative Architectural Designs
This section provides students with an iterative method for
performing trade-off analyses of alternative architectural
designs for the same software system. Students should find
enough information in this section to be able to apply this
technique to their own architectural designs. The second
approach presented in this section applies pseudo quantitative
techniques as a means of assessing the quality of an
architectural design.
14.5 Mapping Requirements into Software Architecture
This section describes the general process of mapping
requirements into software architectures during the structured
design process. The technique described in this chapter is based
on analysis of the system data flow diagram. The key point to
get across to students is the difference between transform flow
and transaction flow. Transform flow is largely sequential and
has very little divergence along the action path. Transaction flow
can follow many action paths and the processing of a single data
item often triggers path selection.
14.6 Transform Mapping
The process of mapping a data flow diagram with transform
characteristics into a specific architectural style is illustrated in
this section. Students should be reminded to strive for DFD
bubbles that exhibit high cohesion. Students should be told that
both transform and transaction flows may occur in the same
DFD. Each subflow should be classified and mapped using the
appropriate technique (transform or transaction). Students may

need to see more than one example of transform mapping
before they attempt to do it on their own.
14.7 Transaction Mapping
The process of performing transaction mapping is presented as
being similar to transform mapping, but focusing on transaction
(not transform) centers. In transaction mapping, the first level
factoring results in the derivation of the control hierarchy. The
second level factoring distributes the low-level modules among
the appropriate controller.
14.8 Refining the Architectural Design
Refining the architectural model involves writing a fair amount
of documentation (e.g. process narratives, interface descriptions,
limitations, etc.) and reviewing work products for quality.
Student projects need to be subjected to the refinement process
before detailed design work is undertaken. It may be
worthwhile to have the students look over the design document
template from the SEPA web site to see where they need to go
next with their design work.

PROBLEMS AND POINTS TO PONDER

14.1

The concepts of styles and patterns occur for 
buildings and software at both macroscopic and 
microscopic levels. For example, overall styles 
(center­hall colonial, A­frame) can be found in 
a house. These represent macroscopic styles. 
Lower­level microscopic patterns (for a house) 
can be found in categories of wood molding, 
fireplace designs, windows, etc.

14.3

A data warehouse is a global repository for 
information gathered from many corporate 
sources.

14.5

Data centered architecture: airline reservation 
system; library catalog system; hotel booking 
system
Data flow architecture: any 
engineering/scientific application where 
computation is the major function
Call and return architecture: any I­P­O 
application
Object­oriented architectures: GUI­based 

applications; any OO application
Layered architecture: any application in which 
the application functions must be decoupled from
the underlying OS or network detail. Client 
server software is often layered. 
14.11 When transform mapping is used where transaction
mapping should be used, two problems arise: (1) 
the program structure tends to become top heavy 
with control modules—these should be eliminated;
(2) significant data coupling occurs because 
information associated with one of many 
"processing actions" must be passed to an 
outgoing path. 
Classic examples include:
­  many engineering analysis algorithms 
­  many process control applications 
­  some commercial applications
Look for a well­developed DFD and correct 
mapping to program structure. 

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close