Chapter 9 - Architectural Design

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

• Software representations are an a communications enabler so communications among stakeholders
• 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 a intellectually graspable model of how the system is structured and how its components work together

 

Architectural Descriptions

• Set of work products that reflect different stakeholder system viewpoints
• Views are representations of a whole system from the perspective of a related set of stakeholder concerns
• Viewpoints are specifications of conventions for constructing and using a view

 

Architectural Decision Template

• Used to document each major architectural decision for later review by stakeholders who want to understand the proposed architectural description

• Design issue
• Resolution
• Category
• Assumptions
• Constraints
• Alternatives
• Argument
• Implications
• Related decisions
• Related concerns
• Work products
• Notes

 

Architectural Genres

• Artificial intelligence
• Commercial and non-profit
• Communications
• Content authoring
• Devices
• Entertainment and sports
• Financial
• Games
• Government
• Industrial
• Legal
• Medical
• Military
• Operating systems
• Platforms
• Scientific
• Tools
• Transportation
• Utilities

 

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 (clients) 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 (remote subprograms may be distributed across networks)
• 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 Patterns

• Address an application specific problem within a specific context under a set of limitations and constraints
• Propose architectural solution that can serve as the basis for an architectural design

Assessing Architecture Alternatives

• Control 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?

• Data questions

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

 

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

• Archetype is a class or pattern that represents a core abstraction critical to the design of an architecture for a core system
• Archetypes are the abstract building blocks of an architectural design
• 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 but have no business connection to the application domain
• 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
• UML component diagrams are used to represent the overall architectural structure

 

Describing System Instantiations

• Refines the high-level architectural design once the overall system structure is apparent and the major software components have been identified
• Architecture is applied to a specific problem with intent of demonstrating that the structure and components are appropriate

 

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)
• Evaluate quality attributes independently (e.g. reliability, performance, security, maintainability, flexibility, testability, portability, reusability, interoperability)
• 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)

 

Architectural Complexity

• Similar to coupling, dependencies driven by system information/control flow
• 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)

• Provide syntax and semantics for describing software architecture
• Provide designers with ability to decompose components, combine components, and define interfaces

 

Transform Mapping

• Review fundamental system model
• Review and refine data flow diagrams for the software
• Determine whether the DFD has transform or transaction (branching flow) 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
• Perform first-level factoring (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

• Remember that an optimal design that does not work has questionable merit
• Designers should be concerned with developing a software architectural representation that meets the functional and performance requirements  as measured by design measures and heuristics
• Software architectural design refinement should occur in the early design phases
• Design refinement should strive for the smallest number of components consistent with effective modularity and the least complex data structure