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
Collect scenarios
Elicit requirements, constraints, and environmental description
Describe architectural styles/patterns chosen to address scenarios and requirements (module view, process view, data flow view)
Identify sensitivity points for architecture (any attributes significantly affected by variation in the architecture)
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)
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
