chapter 14: design method --- data and architectural design design -- a multistep process in which...

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.


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].


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


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


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


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


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


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.


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.



Data-Centered Architecture



Data Flow Architecture



Call and Return Architecture



Layered Architecture



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)



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



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




(cont.)

Transform Flow

A Btransformcenter

incoming flow outgoing flows

C




(cont.)

Transaction Flow

T

Transactioncenter

Transaction Action

paths



Transform Mapping

Allow data flow diagram(DFD) with transform flow characteristics to be mapped into a predefined template for program structure



Level 0 Safehome DFD



Level 1 Safehome DFD



Level 2 Safehome DFD - Monitor



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



Level 3 DFD for Monitor Sensors




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.



First Level Factoring




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.



Second Level Factoring



First-Cut Program Structure



Refined Program Structure



Transaction Mapping

A single data item triggers one or more information flows



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.



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



Transaction Mapping



First Level Factoring



First-cut Program Structure



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



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)

chapter 14: design method --- data and architectural design design -- a multistep process in which...

Documents

data design process

data design decisions

data structure n

data structure slide

data objects

data dictionary

architectural design

set of data abstractions