Architecture Design

Architectural Drivers

An architecture is shaped by a collection of basic functional, quality and business requirements. These basic requirements (scenarios) are called architectural drivers. When the most important business goals of the system were translated to quality scenarios or use cases then those use cases that have the most impact on architecture are architectural drivers. Architecture design can begin with architectural drivers.
Identifying architectural drivers is not always a top-down process; sometimes to identify them we need to do more detailed investigations including creating a prototype.

Design Methods

  • Responsibility Driven Design
  • Attribute Driven Design (ADD)

Attribute Driven Design

  • ADD is a method of designing architectures based on quality attributes as input. This is done after we have the architectural drives.
  • ADD output are some of architectural views (not all can be driven from ADD)

Steps

  1. Choose the modules to decompose starting from the whole system. Here we need the requirements and constrains.
  2. Refine the module based on architectural drivers and requirements; Choose an architectural pattern that satisfies the drivers based on different tactics; Allocate functionality to modules from use cases and represent views; Decompose further and define interfaces of child modules and document them; Refine use cases and quality scenarios;
  3. Repeat
0779_001.jpg

Notes

  • ADD bases the decomposition on architectural drivers. We select drivers among all the requirements being the most important ones. This is the main difference between ADD and other design methods.

Design Tips

  • N-Square chart is useful to find out the relations between (sub)systems. It eventually helps reduce the number of connections.

After Design

  1. Once the first few levels of the architecture's module decomposition structure are known, those modules can be allocated to development teams. This view will either allocate modules to existing development units or define new ones.
  2. Create a base system and move on iteratively. The choice of which sub-systems to add when depends on the situation. They can be picked up depending on market value, time to market or complexity, etc.

The 3 step architecture process

This process is inherently iterative.

  1. Define architecture requirements or architectural use cases which are non-functional requirements for the application. Architectural requirements are usually the output of functional requirements. Some example of architectural requirements are performance, security, usability, reliability, scalability, ….
    1. Some constraints ( technology, business, time, development) may be imposed to the architecture for example using Java is a must.
    2. After defining architectural requirements, they should be prioritized.
  2. architecture design: Defining the structure and responsibilities of the components.
    1. Functional requirements > architecture requirements > architecture framework(pattern) > identify components > architecture views/document.
    2. The architecture framework can be chosen among: n-tier, messaging, pipe and filter, publish-subscriber, broker, process coordinator, …
    3. Once an overall architecture framework has been selected, based on one or more architecture patterns, the next task is to define the major components that will comprise the design, their interfaces, responsibilities, dependencies, …
    4. Some tips for component design: minimize dependencies, minimize calls between components, …
  3. validation: Testing the architecture can be done using either
    1. Scenarios: Are a set of question/answers that discuss architectural concerns and aim to highlight the consequences of the architectural decisions that are encapsulated in the design. For example for "Availability" quality attribute, the stimulus (question) is "what if email queue fails?" and the answer will be "restart". This type of question/answer can detect, to some extend, issues with the architecture in advance.
    2. Prototypes: Are typically used for two purposes: proof of concept and proof of technology
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License