Overview

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. 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
• Examine the system as a whole

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

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)

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

Mapping Requirements to Software Architecture in Structured Design

• 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)
• Flow boundaries indicated
• DFD is mapped into program structure
• Control hierarchy defined
• Resultant structure refined using design measures and heuristics
• Architectural description refined and elaborated

Transform Mapping

• Review fundamental system model
• Review and refine data flow diagrams for the software
• Determine whether the DFD has transform or transaction characteristics
• Isolate the transform center by specifying incoming and outgoing flow boundaries
• Perform first level factoring
• Perform second level factoring
• Refine the first iteration architecture using design heuristics for improved software quality

Transaction Mapping

• Review fundamental system model
• Review and refine data flow diagrams for the software
• Determine whether the DFD has transform or transaction characteristics
• Identify the transaction center and flow characteristics along each action path
• Map the DFD to a program structure amenable to transaction processing
• Factor and refine the transaction structure and the structure of each action path
• 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