One of the significant challenges in building software architecture lies in the comprehensive consideration of all requirements, including functional and quality attributes. An equally critical task is prioritizing these requirements, as balancing them can become a complex juggling act. Quality attributes, such as reliability, scalability, performance, and maintainability, play a vital role in shaping the architecture of a system. Ensuring no vital requirement is overlooked is paramount, as this can adversely impact the product. The Attribute-Driven Design (ADD) methodology addresses these challenges by using quality attribute requirements to guide the design, ensuring a comprehensive and balanced approach. This article will explore the ADD methodology, providing practical examples and insights into its application and effectiveness in overcoming software architecture design challenges.
Attribute-Driven Design (ADD)
Attribute-driven design (ADD) is a software architecture methodology that focuses on incorporating and prioritizing quality attributes alongside functional requirements, constraints, and concerns during the design process. They are then used as drivers to guide the design decisions and trade-offs throughout the architecture development process. It aims to strike a balance between different attributes, ensuring that the resulting software architecture meets the desired quality goals while still fulfilling functional requirements.
The ADD method follows a recursive decomposition process, where the system or system elements are decomposed into smaller parts. At each stage of decomposition, architectural tactics and patterns are selected to satisfy the driving quality attribute requirements. By prioritizing the fulfillment of quality attribute requirements, ADD enables architects to design architectures that are adaptable, scalable, and easy to maintain.
The Process of ADD: From Identifying Software Architecture Drivers to Verifying the Architecture
To effectively commence the Attribute-Driven Design process, we must first have comprehensively identified all necessary information and requirements that will drive the development of our software architecture. This crucial initial phase necessitates a meticulous analysis and comprehension of the requirements and constraints to which the software architecture must comply to get its suitable shape. Therefore, employing a variety of methodologies can be beneficial in identifying and documenting these inputs, which I’ll expound upon in detail in upcoming articles.
Figure 1: Attribute-Driven Design – Workflow Diagram
Step 1: Review Inputs
In the initial phase of the Architecture Design Process (ADD), it is important to ensure that we have documented and understood all the necessary requirements. This is applicable to both new projects (greenfield) and existing projects (brownfield). Therefore, it is crucial to review the following important inputs:
- Design purpose: The design purpose refers to the specific goal or objective of the design activities, such as early estimation, system increment refinement, or prototype generation for risk mitigation.
- Primary functional requirements: Are the essential operations, tasks, or activities a system must perform to fulfill its intended purpose or functionality. This understanding helps in defining the necessary components of the system.
- Quality attribute scenarios and prioritization: A quality scenario describes how the system must react to a specific event in a specific context. A quality attribute can consist of multiple quality scenarios. They help to capture and understand how different stakeholders expect a software system to perform under certain conditions. A fully quality attribute scenario consists of six elements to make sure that it is testable, measurable, and concrete. Concrete scenarios provide clear and specific requirements that can be objectively assessed, ensuring reliable evaluation of the desired quality attributes in software systems. After identifying the quality attribute scenarios, we need to prioritize them by importance, considering both technical risk and business value. This is crucial because not all quality attributes and their scenarios can be included in a software architecture – some might conflict with each other. For example, in a banking system, prioritizing security might take precedence over usability. These priorities play a significant role in shaping the design process and decision-making. Ranking these helps architects design the best system, balancing these attributes based on their priority. In this step, we can employ various techniques, such as the Quality Attribute Workshop, ATAM Methodology, Utility Tree, and Priority Matrix, which I will elucidate in future articles.
- Constraints: Software architecture constraints are limitations and restrictions that architects must follow when creating a software architecture. These limitations can affect how the architecture is designed and built. For example, they might limit the choice of technologies, require data regulation compliance, or consider budget and time limits. Even though these constraints can impact the design negatively, architects must still make decisions within these boundaries.
- Architectural Concerns: All other important aspects that are not covered by the typical requirements, such as functional and non-functional requirements. However, these aspects still belong to the architecture design process and must be considered when making design decisions. There are different categories of software architecture concerns. They can be grouped as follows:
- General concerns: These considerations are important when designing the overall architecture. Examples include setting up the infrastructure and organizing system modules based on functionalities or development teams.
- Specific concerns: In this category, detailed aspects within the system are defined based on the general considerations. Examples include handling error messages, configurations, and logging.
- Internal requirements: These requirements are not explicitly mentioned in the functional and non-functional requirements. They are derived from factors like customer demands, laws, or practical considerations. It is crucial to consider internal requirements as they can speed up deployment and the development process.
- Issues: These aspects arise from analyses and architecture evaluations, and they need to be addressed to mitigate potential risks.
Step 2: Establish Iteration Goal by Selecting Drivers
After reviewing inputs, we set a goal for each iteration. These can be based on pre-defined inputs and priorities, such as aiming to achieve a functional requirement or a quality attribute scenario.
Step 3:Choose One or More Elements of the System to Refine
Next, we identify elements of the system that need refining to meet the iteration goals. This could also include system elements from previous iterations. For example, in a new project (greenfield), the whole system could be chosen and divided into components. In existing projects (brownfield), several system elements can be combined.
Step 4: Choose One or More Design Concepts That Satisfy the Selected Drivers
Based on the identified architectural drivers, architects choose design concepts that align with the desired quality attribute requirements to fulfill the iteration goals. These design concepts can include architectural patterns, tactics, or strategies that have proven to be effective in addressing similar architectural drivers in the past. The goal is to select design concepts that best satisfy the driving quality attribute requirements. Choosing appropriate design concepts is challenging and requires searching for alternative design concepts and analyzing them. This involves comparing different solution approaches to choose the most suitable design concepts.
Step 5: Instantiate Architectural Elements, Allocate Responsibilities, and Define Interfaces
The design concepts selected in the fourth step do not immediately provide a solution to the problem. They need to be specified in relation to the existing inputs, clarifying how these design concepts can be implemented within the current architecture. This could involve configurations, or the decomposition of system components based on a design concept while considering functional or non-functional requirements. Furthermore, it is necessary to explain the responsibilities performed by these instantiated elements and the roles they play in the system.
Moreover, architectural elements often need to communicate with each other, so interfaces need to be defined to describe their relationships.
Step 6: Sketch Views and Record Design Decisions
During steps four and five of the architecture design process, we made one or more design decisions and likely outline some informal and incomplete architecture views. It is crucial to formally document these decisions with justifications to ensure understanding among stakeholders. Furthermore, this documentation becomes critical when other architects need to make changes to the architecture at a later stage. Therefore, architects should clearly explain why they made these decisions.
Formally documenting design decisions and architecture sketches is not a part of the architecture design process per se, but it must be completed in this step. We need to formally outline the informal, incomplete, or missing views and document the relevant design decisions along with their justifications in a clear and understandable manner.
Step 7: Perform Analysis of Current Design and Review Iteration Goal and Achievement of Design Purpose
The decisions made during the architecture design process are not only crucial for meeting the quality requirements but can also carry risks, such as significant costs for later rework. Hence, we need to analyze these design decisions either during the design process or at the end of each iteration to identify and address any potential issues early on.
Architects can perform this analysis alone or collaborate with others. Working with other architects offers the benefit of diverse perspectives, leading to a more thorough evaluation of design decisions. Considering these various viewpoints helps identify potential weaknesses, enabling proactive improvement measures for the design.
To track and manage iteration inputs during the design process effectively, we can use a Kanban board. This tool visually presents the ADD methodology inputs using columns for pending, ongoing, and completed tasks, simplifying the monitoring, and tracking of the design process.
We repeat these seven steps until we achieve the design goal or additional iterations become impractical due to factors such as time or resource limitations. Prioritizing tasks is vital to this process, ensuring we address high-priority issues first. Adhering to these practices allows architects to enhance efficiency and keep on track towards achieving their design objectives.
Wrap-up and Implications
The Attribute-Driven Design (ADD) methodology provides a holistic strategy for systematically and recursively designing software architecture, driven by the most crucial quality attributes. It balances critical quality attributes such as reliability, scalability, and performance based on their technical and business significance. Quality attribute scenarios make these attributes concrete, ensuring they are measurable and testable. Furthermore, ADD enforces a continuous trade-off analysis among stakeholders and documents all relevant information, including functional and non-functional requirements, scenarios, architectural concerns, and constraints. Moreover, it ensures all these inputs are considered and balanced when making design decisions. It also documents significant design decisions, which facilitates scalability and easier maintenance of the system. Through the iterative analysis of design decisions, ADD mitigates architectural risks early.
Curious about the applicability of Attribute-Driven Design to your projects? Find the answers in the upcoming second part of this series. Stay tuned for insights that will guide your decision-making.
Want to dive deeper into these solution strategies and stay ahead of the curve? Subscribe to our newsletter now and receive expert insights and actionable tips tailored for each challenge. Don’t miss out on the knowledge that can empower your Software architecture Design journey. Subscribe today! 📩🔐🚀