Chapter 10 Architectural Design - PowerPoint PPT Presentation

About This Presentation
Title:

Chapter 10 Architectural Design

Description:

Chapter 10 Architectural Design What is and Why Architecture? Data Design At the architectural level Design of one or more databases to support the application ... – PowerPoint PPT presentation

Number of Views:100
Avg rating:3.0/5.0
Slides: 47
Provided by: Roger303
Category:

less

Transcript and Presenter's Notes

Title: Chapter 10 Architectural Design


1
Chapter 10Architectural Design
2
What is and Why Architecture?
  • Software architecture is the structure of the
    systems, which comprises
  • software components,
  • properties of these components,
  • relationships among them
  • It is a representation that enables a software
    engineer to
  • analyze the effectiveness of the design in
    meeting its stated requirements,
  • consider architectural alternatives at a stage
    when making design changes is still relatively
    easy, and
  • reduce the risks associated with the construction
    of the software.

3
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

4
Data Design (cont.)
  • 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

5
Data Design PrinciplesComponent Level
1. The systematic analysis principles applied to
function and behavior should also be applied to
data. 2. All data structures and the operations
to be performed on each should be identified. 3.
A data dictionary should be established and used
to define both data and program design. 4. Low
level data design decisions should be deferred
until late in the design process. 5. The
representation of data structure should be known
only to those modules that must make direct use
of the data contained within the structure. 6.
A library of useful data structures and the
operations that may be applied to them should be
developed. 7. A software design and programming
language should support the specification and
realization of abstract data types.
6
Architectural Styles
  • Each style describes a system category that
  • encompasses
  • a set of components (e.g., a database,
    computational modules) that perform a function
    required by a system
  • a set of connectors that enable communication,
    coordination and cooperation among components
  • constraints that define how components can be
    integrated to form the system, and
  • semantic models that enable a designer to
    understand the overall properties of a system

7
Taxonomy of Architectural Styles
  • Data-centered architectures
  • Data flow architectures
  • Call and return architectures
  • Main program/subprogram architecture
  • Remote procedure call architecture
  • Object-oriented architectures
  • Layered architectures

8
Data-Centered Architecture
9
Data Flow Architecture
10
Call and Return Architecture
11
Layered Architecture
12
Architectural Patterns
  • Architecture pattern defines a specific approach
    for handling some behavioral characteristic of
    the system
  • Architecture pattern vs architecture style
  • Kitchen pattern vs central-hall colonial
  • Representative example patterns
  • Concurrencyapplications must handle multiple
    tasks in a manner that simulates parallelism
  • operating system process management pattern
  • task scheduler pattern

13
Architectural Patterns (cont.)
  • PersistenceData persists if it survives past the
    execution of the process that created it. Two
    patterns are common
  • a database management system pattern that applies
    the storage and retrieval capability of a DBMS to
    the application architecture
  • an application level persistence pattern that
    builds persistence features into the application
    architecture
  • Distribution the manner in which systems or
    components within systems communicate with one
    another in a distributed environment
  • A broker acts as a middle-man between the
    client component and a server component.

14
Architectural Design
  • Architectural design involves three main tasks
  • Represent the system in context
  • Define the external entities (other systems,
    devices, people) that the software interacts with
  • Use architectural context diagram (ACD)
  • Define archetypes
  • An archetype is an abstraction (similar to a
    class) that represents one element of system
    behavior
  • Four architectural archetypes should be
    identified
  • Node, Detector, indicator, controller
  • Use UML
  • Refine the architecture into components
  • The designer specifies the structure of the
    system by defining and refining software
    components that implement each archetype

15
Architectural Context
16
Archetypes
17
Component Structure
18
Refined Component Structure
19
Analyzing Architectural Design
  • How to assess different architectural designs to
    determine the most appropriate
  • 1. Collect scenarios.
  • 2. Elicit requirements, constraints, and
    environment description.
  • 3. Describe the architectural styles/patterns
    that have been chosen to address the scenarios
    and requirements
  • module view
  • process view
  • data flow view
  • 4. Evaluate quality attributes by considered
    each attribute in isolation, e.g., reliability,
    performance, security, maintainability
  • 5. Identify the sensitivity of quality
    attributes to various architectural attributes
    for a specific architectural style.
  • 6. Critique candidate architectures (developed
    in step 3) using the sensitivity analysis
    conducted in step 5.

20
An Architectural Design Method
customer requirements
architectural design
21
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

22
Deriving Program Architecture
Data flow diagram ? call and return architecture
23
Types of Information Flow
  • Transform flow
  • A sequence of paths that form a transition
    through which input data are transformed into
    output data

24
Types of Information Flow (cont.)
  • Transaction flow
  • A information flow that is triggered by a single
    data item, called transaction, along one of many
    paths

Transaction center
25
General Mapping Approach
  • Isolate incoming and outgoing flow boundaries
    for transaction flows, isolate the transaction
    center
  • Working from the boundary outward, map DFD
    transforms into corresponding modules
  • Add control modules as required
  • Refine the resultant program structure using
    effective modularity concepts

26
Transform Mapping
27
Transform Mapping (cont.)
  • Step 1. Review the fundamental system model
  • Step 2. Review and refine data flow diagrams
  • Step 3. Determine whether the DFD has transform
    or transaction flow characteristics
  • Step 4. Isolate the transform center
  • Step 5. Perform first-level factoring
  • Step 6. Perform second-level factoring
  • Step 7. Refine the first-iteration architecture

28
Transform Mapping -- Illustration
  • Step 1. Review the fundamental system model
  • Example SafeHome security function

Level 0 DFD
29
Transform Mapping Illustration (cont.)
Level 1 DFD
30
Transform Mapping Illustration (cont.)
  • Step 2. Review and refine data flow diagrams
  • Example Level 2 DFD for monitor sensors process

31
Transform Mapping Illustration (cont.)
  • Level 3 DFD for monitor sensors process

32
Transform Mapping Illustration (cont.)
  • Step 3. Determine whether the DFD has transform
    or transaction flow characteristics
  • Step 4. Isolate the transform center by
    specifying incoming and outgoing flow boundaries

33
Transform Mapping Illustration (cont.)
  • Step 5. Perform first-level factoring

34
Factoring
35
Transform Mapping Illustration (cont.)
  • Step 6. Perform second-level factoring

36
Transform Mapping Illustration (cont.)
37
Transform Mapping Illustration (cont.)
38
Transform Mapping Illustration (cont.)
  • Step 7. Refine the first-iteration architecture

39
Transaction Mapping
  • Step 1. Review the fundamental system model
  • Step 2. Review and refine data flow diagrams
  • Step 3. Determine whether the DFD has transform
    or transaction flow characteristics
  • Step 4. Identify the transaction center and flow
    characteristics along each action path
  • Step 5. Map the DFD in a program structure
    amenable to transaction processing
  • Step 6. Factor and refine transaction structure
    and the structure of each action path
  • Step 7. Refine the first-iteration architecture

40
Transaction Mapping (cont.)
41
Transaction Mapping Illustration (cont.)
  • The first three steps are the same as
    transform mapping
  • Step 1. Review the fundamental system model
  • Step 2. Review and refine data flow diagrams
  • Step 3. Determine whether the DFD has transform
    or transaction flow characteristics

42
Transaction Mapping Illustration (cont.)
  • Step 4. Identify the transaction center and flow
    characteristics along each action path
  • Example Level 2 DFD for user interaction
    subsystem

43
Transaction Mapping Illustration (cont.)
  • Step 5. Map the DFD in a program structure
    amenable to transaction processing
  • An incoming branch and a dispatch branch

44
Transaction Mapping Illustration (cont.)
  • Example user interaction subsystem

45
Transaction Mapping Illustration (cont.)
  • Step 6. Factor and refine transaction structure
    and the structure of each action path

46
Remarks on Refining Architecture Design
  • Optimal design doesnt work has questionable
    merit
  • Refinement at early stages of design is
    encouraged
  • Keep it simple
  • Simplicity often reflects both elegance and
    efficiency
  • Strive for the smallest number of components
    consistent with effective modularity and serving
    user requirements
Write a Comment
User Comments (0)
About PowerShow.com