View
227
Download
2
Tags:
Embed Size (px)
Citation preview
Chapter 14: Design Method ---data and architectural design
Design -- A multistep process in which representations of data structure, program structure, interface characteristics, and procedural detail are synthesized.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
2 December 25, 1997
Why Architecture?
The architecture is not the operational software. The architecture is not the operational software. Rather, it is a representation that enables a Rather, it is a representation that enables a software engineer to: software engineer to:
(1) analyze the effectiveness of the design in (1) analyze the effectiveness of the design in meeting its stated requirements, meeting its stated requirements,
(2) consider architectural alternatives at a stage (2) consider architectural alternatives at a stage when making design changes is still relatively easy, when making design changes is still relatively easy, and and
(3) reduce the risks associated with the (3) reduce the risks associated with the construction of the software.construction of the software.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
3 December 25, 1997
Why is Architecture Important?
Representations of software architecture are an enabler for communication between all parties (stakeholders) interested in the development of a computer-based system.
The architecture highlights early design decisions that will have a profound impact on all software engineering work that follows and, as important, on the ultimate success of the system as an operational entity.
Architecture “constitutes a relatively small, intellectually graspable model of how the system is structured and how its components work together” [BAS03].
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
4 December 25, 1997
Data Design
What is data design? Transform the information domain model
created during analysis into data structure required to implement the software
Well-designed data lead to better program structure and modularity, reduced procedural complexity
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
5 December 25, 1997
Data Design
At the architectural level … Design of one or more databases to support the
application architecture Design of methods for ‘mining’ the content of multiple
databases– navigate through existing databases in an attempt
to extract appropriate business-level information– Design of a data warehouse—a large, independent
database that has access to the data that are stored in databases that serve the set of applications required by a business
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
6 December 25, 1997
Data Design At the component level …
refine data objects and develop a set of data abstractions
implement data object attributes as one or more data structures
review data structures to ensure that appropriate relationships have been established
simplify data structures as required
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
7 December 25, 1997
Data Design Process
Define data structures identified during the requirements and specification phase. Often base decision on algorithm to be used.
Identify all program modules that must operate directly upon the data structure Constrain the scope of effect of data design
decisions Or, from OO perspective, define all
operations performed on the data structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
8 December 25, 1997
Principles of Data Design (Component Level)
A data dictionary should be established and used for both data and program design
Low-level data design decisions should be deferred until late in the design process
A library of useful data structures and the operations that may be applied to them should be developed. -- Reuse E.g., stacks, lists, arrays, queues
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
9 December 25, 1997
Principles of Data Design (cont.)
The representation of data structures should be known only to those modules that must make direct use of the data contained within the structure. Information hiding
The software design and programming languages should support the specification and realization of abstract data types.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
10 December 25, 1997
Architectural Styles
Data-centered architectures Data flow architectures Call and return architectures Object-oriented architectures Layered architectures
Each style describes a system category that encompasses: (1) a Each style describes a system category that encompasses: (1) a set of componentsset of components (e.g., a database, computational modules) (e.g., a database, computational modules) that perform a function required by a system, (2) a that perform a function required by a system, (2) a set of set of connectorsconnectors that enable “communication, coordination and that enable “communication, coordination and cooperation” among components, (3) cooperation” among components, (3) constraintsconstraints that define that define how components can be integrated to form the system, and (4) how components can be integrated to form the system, and (4) semantic modelssemantic models that enable a designer to understand the that enable a designer to understand the overall properties of a system by analyzing the known overall properties of a system by analyzing the known properties of its constituent parts. properties of its constituent parts.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
11 December 25, 1997
Data-Centered Architecture
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
12 December 25, 1997
Data Flow Architecture
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
13 December 25, 1997
Call and Return Architecture
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
14 December 25, 1997
Layered Architecture
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
15 December 25, 1997
Architectural Design Objective
develop a modular program structure and represent control relationships between modules
Data flow-oriented design (Structured design) amenable to a broad range of applications very useful when information is processed
sequentially, such as microprocessor control application; complex, numerical analysis procedure; etc.
two approaches (transform and transaction mapping)
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
16 December 25, 1997
Structured Design
objective: to derive a program architecture that is partitioned
approach: the DFD is mapped into a program
architecture the PSPEC and STD are used to
indicate the content of each module notation: structure chart
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
17 December 25, 1997
Architectural Design Process
Five-step Process the type of information flow is established flow boundary are indicated data flow diagram is mapped into program
structure control hierarchy is defined by factoring resultant structure is refined using design
measures heuristics
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
18 December 25, 1997
Architectural Design Process
(cont.)
Transform Flow
A Btransformcenter
incoming flow outgoing flows
C
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
19 December 25, 1997
Architectural Design Process
(cont.)
Transaction Flow
T
Transactioncenter
Transaction Action
paths
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
20 December 25, 1997
Transform Mapping
Allow data flow diagram(DFD) with transform flow characteristics to be mapped into a predefined template for program structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
21 December 25, 1997
Level 0 Safehome DFD
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
22 December 25, 1997
Level 1 Safehome DFD
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
23 December 25, 1997
Level 2 Safehome DFD - Monitor
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
24 December 25, 1997
Transform Mapping (cont)
Design steps Step 1. Review the fundamental system model. Step 2. Review and refine data flow diagrams
for the software. Step 3. Determine whether DFD has transform
or transaction flow characteristics. – in general---transform flow–special case---transaction flow
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
25 December 25, 1997
Level 3 DFD for Monitor Sensors
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
26 December 25, 1997
Transform Mapping (cont)
step 4. Isolate the transform center by specifying incoming and outgoing flow boundaries different designers may select slightly differently transform center can contain more than one
bubble. step 5. Perform “first-level factoring”
program structure represent a top-down distribution control.
factoring results in a program structure(top-level, middle-level, low-level)
number of modules limited to minimum.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
27 December 25, 1997
First Level Factoring
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
28 December 25, 1997
Transform Mapping (cont)
step 6. Perform “second-level factoring”– mapping individual transforms(bubbles) to
appropriate modules.– factoring accomplished by moving outwards
from transform center boundary.
step 7. Refine the first iteration program structure using design heuristics for improved software quality.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
29 December 25, 1997
Second Level Factoring
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
30 December 25, 1997
First-Cut Program Structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
31 December 25, 1997
Refined Program Structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
32 December 25, 1997
Transaction Mapping
A single data item triggers one or more information flows
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
33 December 25, 1997
Transaction Mapping Design
Step 1.Review the fundamental system model. Step 2.Review and refine DFD for the software Step 3.Determine whether the DFD has transform
or transaction flow characteristics Step 4. Identify the transaction center and flow
characteristics along each of the action paths– isolate incoming path and all action paths
– each action path evaluated for its flow characteristic.
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
34 December 25, 1997
Transaction Mapping (cont)
step 5. Map the DFD in a program structure amenable to transaction processing incoming branch
– bubbles along this path map to modules
dispatch branch– dispatcher module controls all subordinate
action modules– each action path mapped to corresponding
structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
35 December 25, 1997
Transaction Mapping
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
36 December 25, 1997
First Level Factoring
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
37 December 25, 1997
First-cut Program Structure
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
38 December 25, 1997
Transaction Mapping (cont)
step 6. Factor and refine the transaction structure and the structure of each action path
step 7. Refine the first iteration program structure using design heuristics for improved software quality
R. A. Volz -- Assistance - Haichen Liu, Brian Bolstad
39 December 25, 1997
Design Postprocessing
A processing narrative must be developed for each module
An interface description is provided for each module
Local and global data structures are defined All design restrictions/limitations are noted A design review is conducted “Optimization” is considered (if required and
justified)