Site MapHelpFeedbackChapter Summary
Chapter Summary
(See related pages)


Architectural design represents the structure of the data and program components required to build a computer-based system. A number of architectural "styles" exist. Architectural design begins with data design and proceeds to the derivation of one or more representations of the architectural structure of the system. The resulting architectural model encompasses both the data architecture and the program structure. Alternative architectural patterns are analyzed to determine the structure that is best suited to the customer's requirements. The architectural model is subjected to software quality review like all other design work products.

Software architecture is a representation that enables a software engineer to
  • Analyze the effectiveness of the design in meeting stated requirements
  • Consider architectural alternatives
  • Reduce the risk associated with the construction of the software
Importance of Architecture
  • Architecture highlights early design decisions that will have a profound impact on the ultimate success of the system as an operational entity
  • The architecture itself constitutes an intellectually managable model of how the system is structured and how its components work together
Data Warehouse Challenges for Data Architects
  • Subject orientation - data warehouse organized by business subjects rather than business processes or functions
  • Integration - data in the warehouse must exhibit consistent naming conventions, encoding structures, and physical attributes even when inconsistencies exist among application-oriented databases
  • Time variancy - unlike transaction-oriented databases where data may only be accurate for short time periods, the time horizon for a data warehouse may be several years
  • Nonvolatility - data remains in the data warehouse once added and old data may only be purged every few years if at all
Data Specification Principles
  • Systematic analysis principles applied to function and behavior should also be applied to data.
  • All data structures and the operations to be performed on each should be identified.
  • Data dictionary should be established and used to define both data and program design.
  • Low level design processes should be deferred until late in the design process.
  • Representations of data structure should be known only to those modules that must make direct use of the data contained within in the data structure.
  • A library of useful data structures and operations should be developed.
  • A software design and its implementation language should support the specification and realization of abstract data types.
Architectural Style Elements
  • Set of components
  • Set of connections that enable communication, coordination, and cooperation among components
  • Constraints defining how components can be integrated to form the system
  • Semantic models that enable designers to understand the overall system properties by analyzing properties of its constituent parts
Comparing Architectural Styles and Patterns
  • Both impose transformations on the design of an entire system
  • Scope of architectural pattern is less broad
  • Patterns impose rules on the architecture describing how the software will deliver some aspect of its functionality at the infrastructure level
Canonical Architectural Structures
  • Functional structure - components represent function or processing entities, connectors are interfaces that allow data access
  • Implementation structure - components are vehicles for packaging functionality (i.e., packages, classes, objects, functions, methods, etc.), connectors include data sharing, control transfer, associations, etc.
  • Concurrency structure - components are units of concurrency, connectors are execution or communications constraints
  • Physical structure - components are physical hardware that software is deployed on, connectors are the hardware interfaces
  • Developmental structure - components are work products and required information sources, connectors are the relationships among the work products
Architectural Styles
  • Data centered - data store (e.g., file or database) lies at the center of this architecture and is accessed frequently by other components that modify data
  • Data flow - input data is transformed by a series of computational or manipulative components into output data
  • Call and return - program structure decomposes function into control hierarchy with main program invokes several subprograms
  • Object-oriented - components of system encapsulate data and operations, communication between components is by message passing
  • Layered - several layers are defined, each accomplishing operations that progressively become closer to the machine instruction set
Architectural Design
  • Software to be developed must be put into context (i.e., model external entities and define interfaces)
  • Identify architectural archetypes (collection of abstractions that must be modeled if the system is to be constructed)
  • Specify structure of the system by defining and refining the software components needed to implement each archetype
  • Continue the process iteratively until a complete architectural structure has been derived
Representing the System in Context
  • Use the architectural context diagram to model the manner in which the system interacts with external entities
  • Systems that interoperate with the target system are represented as
    • Superordinate systems - using the target system as part of some higher level processing scheme
    • Subordinate systems - used by the target system to provide data or processing needed to complete the target system
    • Peer level systems - producing or consuming information needed by peers of the target system
    • Actors - people or devices that interact with the system to produce or consume information needed for requisite processing
  • Interfaces must be defined
  • All the data that flow into or out of the target system must be identified
Defining Archetypes
  • May be defined by examining the analysis classes defined in the analysis model
  • Determine the stable elements of the architecture that will need to be implemented when the system is built
Refining Architecture into Components
  • Process begins with an examination of the analysis classes for entities from the business domain that must be addressed in the software architecture
  • Infrastructure components needed to support the business functions
  • The interfaces depicted in the architecture context diagram may imply specialized components needed to process data that crosses the interfaces
  • Look for archetypes that are reoccur in several components and create new components that service each repeating design pattern
Architecture Design Assessment Questions
  • How is control managed within the architecture?
  • Does a distinct control hierarchy exist?
  • How do components transfer control within the system?
  • How is control shared among components?
  • What is the control topology?
  • Is control synchronized or asynchronous?
  • How are data communicated between components?
  • Is the flow of data continuous or sporadic?
  • What is the mode of data transfer?
  • Do data components exist? If so what is their role?
  • How do functional components interact with data components?
  • Are data components active or passive?
  • How do data and control interact within the system?
Architecture Trade-off Analysis Method
  1. Collect scenarios
  2. Elicit requirements, constraints, and environmental description
  3. Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view)
  4. Evaluate quality attributes independently (e.g., reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability)
  5. Identify sensitivity points for architecture (any attributes significantly affected by variation in the architecture)
  6. Critique candidate architectures (from step 3) using the sensitivity analysis (conducted in step 5)
Quantitative Design Analysis Techniques
  • Spectrum analysis - assesses an architecture using a goodness spectrum from best to worst design
  • Design selection analysis - architecture is assessed to determine how it compares to an ideal or best case system
  • Contribution analysis - identifies reasons why one set of design choices gets a lower score than another
Architectural Complexity (similar to coupling)
  • Sharing dependencies - represent dependence relationships among consumers who use the same resource or producers who produce for the same consumers
  • Flow dependencies - represent dependence relationships between producers and consumers of resources
  • Constrained dependencies - represent constraints on the relative flow among a set of components
Architectural Description Language (ADL)
  • Provides syntax and semantics for describing software architecture
  • Provides designers with ability to decompose components, combine components, and define interfaces
Mapping Requirements to Software Architecture in Structured Design (Used for developing a "call and return" architecture)
  1. Establish type of information flow (transform flow - overall data flow is sequential and flows along a small number of straight line paths; transaction flow - a single data item triggers information flow along one of many paths)
  2. Flow boundaries indicated
  3. DFD is mapped into program structure
  4. Control hierarchy defined
  5. Resultant structure refined using design measures and heuristics
  6. Architectural description refined and elaborated
Transform Mapping
  1. Review fundamental system model
  2. Review and refine data flow diagrams for the software
  3. Determine whether the DFD has transform or transaction characteristics
  4. Isolate the transform center by specifying incoming and outgoing flow boundaries
  5. Perform first level factoring
  6. Perform second level factoring
  7. Refine the first iteration architecture using design heuristics for improved software quality
Transaction Mapping
  1. Review fundamental system model
  2. Review and refine data flow diagrams for the software
  3. Determine whether the DFD has transform or transaction characteristics
  4. Identify the transaction center and flow characteristics along each action path
  5. Map the DFD to a program structure amenable to transaction processing
  6. Factor and refine the transaction structure and the structure of each action path
  7. Refine the first iteration architecture using design heuristics for improved software quality
Refining Architectural Design
  • Processing narrative developed for each module
  • Interface description provided for each module
  • Local and global data structures are defined
  • Design restrictions/limitations noted
  • Design reviews conducted
  • Refinement considered if required and justified

PressmanOnline Learning Center

Home > Chapter 10 > Chapter Summary