Architectural Design

Architectural Design



Architectural Design

Chapter 9 - Architectural Design


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


Source: http://highered.mheducation.com/sites/dl/free/0073375977/673802/chapter09.doc

Web site to visit: http://highered.mheducation.com

Author of the text: indicated on the source document of the above text

If you are the author of the text above and you not agree to share your knowledge for teaching, research, scholarship (for fair use as indicated in the United States copyrigh low) please send us an e-mail and we will remove your text quickly. Fair use is a limitation and exception to the exclusive right granted by copyright law to the author of a creative work. In United States copyright law, fair use is a doctrine that permits limited use of copyrighted material without acquiring permission from the rights holders. Examples of fair use include commentary, search engines, criticism, news reporting, research, teaching, library archiving and scholarship. It provides for the legal, unlicensed citation or incorporation of copyrighted material in another author's work under a four-factor balancing test. (source: http://en.wikipedia.org/wiki/Fair_use)

The information of medicine and health contained in the site are of a general nature and purpose which is purely informative and for this reason may not replace in any case, the council of a doctor or a qualified entity legally to the profession.


Architectural Design


The texts are the property of their respective authors and we thank them for giving us the opportunity to share for free to students, teachers and users of the Web their texts will used only for illustrative educational and scientific purposes only.

All the information in our site are given for nonprofit educational purposes


Architectural Design



Topics and Home
Term of use, cookies e privacy


Architectural Design