Chapter 14: Design Method ---data and architectural design - PowerPoint PPT Presentation

Loading...

PPT – Chapter 14: Design Method ---data and architectural design PowerPoint presentation | free to download - id: 428a22-NjcwY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 14: Design Method ---data and architectural design

Description:

---data and architectural design Design -- A multistep process in which representations of data structure, program structure, interface characteristics, and ... – PowerPoint PPT presentation

Number of Views:792
Avg rating:3.0/5.0
Slides: 40
Provided by: liu141
Learn more at: http://www.atilim.edu.tr
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Chapter 14: Design Method ---data and architectural design


1
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.
2

Why Architecture?
The architecture is not the operational software.
Rather, it is a representation that enables a
software engineer to (1) analyze the
effectiveness of the design in meeting its stated
requirements, (2) consider architectural
alternatives at a stage when making design
changes is still relatively easy, and (3) reduce
the risks associated with the construction of the
software.

3

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

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 warehousea 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

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

Architectural Styles
Each style describes a system category that
encompasses (1) a set of components (e.g., a
database, computational modules) that perform a
function required by a system, (2) a set of
connectors that enable communication,
coordination and cooperation among components,
(3) constraints that define how components can be
integrated to form the system, and (4) semantic
models that enable a designer to understand the
overall properties of a system by analyzing the
known properties of its constituent parts.
  • Data-centered architectures
  • Data flow architectures
  • Call and return architectures
  • Object-oriented architectures
  • Layered architectures

11

Data-Centered Architecture

12

Data Flow Architecture

13

Call and Return Architecture

14

Layered Architecture

15
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)

16

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

17
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

18
Architectural Design Process

(cont.)
  • Transform Flow

outgoing flows
incoming flow
B
A
transform center
C
19
Architectural Design Process

(cont.)
  • Transaction Flow

Transaction
Action paths
T
Transaction center
20
Transform Mapping
  • Allow data flow diagram(DFD) with transform flow
    characteristics to be mapped into a predefined
    template for program structure

21
Level 0 Safehome DFD
22
Level 1 Safehome DFD
23
Level 2 Safehome DFD - Monitor
24
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

25
Level 3 DFD for Monitor Sensors
26
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.

27
First Level Factoring
28
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.

29
Second Level Factoring
30
First-Cut Program Structure
31
Refined Program Structure
32
Transaction Mapping
A single data item triggers one or more
information flows
33
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.

34
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

35
Transaction Mapping
36
First Level Factoring
37
First-cut Program Structure
38
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

39
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)

40
Summary - Data Architectural
  • Data design translates the data objects defined
    in the analysis model into data structure that
    reside with in the software
  • Architectural design use information flow
    characteristics described in the analysis model
    to derive program structure
  • DFD is mapped into program structure use two
    approaches transform and transaction mapping
About PowerShow.com