Attribute-driven design

Last updated

Attribute-driven design [1] [2] (also called ADD or Attribute-driven design method) is a methodology to create software architectures that takes into account the quality attributes of the software. It was previously known as the Architecture Based Design Method (or ABD), but due to trademark issues the name was changed to Attribute-driven design around 2001. [3]

Contents

The attribute-driven design method

In the book Software architecture in practice [4] the authors describe ADD as an iterative method that, at each iteration, helps the architect to do the following steps:

Required input

ADD can only be started successfully when the following resources are already available:

Of course, we cannot wait until all these requirements are finalized since this can take a while. The ADD process can start once a set of ASRs (architecturally significant requirements, which are the three resources listed above) are available.

Process steps

  1. Choose an element of the system to design
    • Select an element of the system that is not yet designed. In the first iteration this will be the system itself. Later on, a choice will need to be made between several elements. This choice can be based on personnel availability, input resources availability, risk mitigation, etc. In case you do not have any of these limitations, it is suggested to go for a breadth-first strategy.
  2. Identify the Architecturally Significant Requirements (ASR) for the chosen element
    • Identify the ASRs that are most important for this selected element. You should prioritize these requirements to make sure that your design reflects the most important ASRs.
  3. Generate a design solution for the chosen element
    • This step is the heart of ADD since the architecture will be created in this step. The architecture you create should reflect the selected ASRs. You can do this by making use of architectural patterns or tactics. Most of the times you will have to make a trade-off between several tactics and ASRs.
  4. Inventory remaining requirements and select the input for the next iteration
    • Take a look at the listed ASRs and see whether they are already fulfilled with the design you have at the moment. For each ASR you will have to check whether it is satisfied, delegated to one of the children, distributed among the children or whether it can not be satisfied. In the last case you will need to change your architecture.
  5. Repeat steps 1-4 until all the ASRs have been satisfied
    • Repeat!

Output

A set of sketches of architectural views, not a full-blown detailed architecture.

ADD 3.0

In recent years, ADD has been updated substantially to include platform-specific design, e.g. technology and framework choices via design concept catalogs, and to emphasize the making and documentation of architectural decisions. [5]

Related Research Articles

In software quality assurance, performance testing is in general a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

The rational unified process (RUP) is an iterative software development process framework created by the Rational Software Corporation, a division of IBM since 2003. RUP is not a single concrete prescriptive process, but rather an adaptable process framework, intended to be tailored by the development organizations and software project teams that will select the elements of the process that are appropriate for their needs. RUP is a specific implementation of the Unified Process.

In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.

In software development, agile practices include requirements discovery and solutions improvement through the collaborative effort of self-organizing and cross-functional teams with their customer(s)/end user(s), Popularized in the 2001 Manifesto for Agile Software Development, these values and principles were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.

In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"

<span class="mw-page-title-main">V-model</span> Graphic of a systems development lifecycle

The V-model is a graphical representation of a systems development lifecycle. It is used to produce rigorous development lifecycle models and project management models. The V-model falls into three broad categories, the German V-Modell, a general testing model, and the US government standard.

Extensibility is a software engineering and systems design principle that provides for future growth. Extensibility is a measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The principle provides for enhancements without impairing existing system functions.

In software engineering, architecture tradeoff analysis method (ATAM) is a risk-mitigation process used early in the software development life cycle.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

Coding best practices or programming best practices are a set of informal rules that many software developers in computer programming follow to improve software quality. Many computer programs remain in use for long periods of time, so any rules need to facilitate both initial development and subsequent maintenance and enhancement of source code by people other than the original authors.

The engineering design process, also known as the engineering method, is a common series of steps that engineers use in creating functional products and processes. The process is highly iterative - parts of the process often need to be repeated many times before another can be entered - though the part(s) that get iterated and the number of such cycles in any given project may vary.

Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.

In software engineering, a software development process is a process of planning and managing software development. It typically involves dividing software development work into smaller, parallel, or sequential steps or sub-processes to improve design and/or product management. It is also known as a software development life cycle (SDLC). The methodology may include the pre-definition of specific deliverables and artifacts that are created and completed by a project team to develop or maintain an application.

Leonard Joel (Len) Bass is an American software engineer, Emeritus professor and former researcher at the Software Engineering Institute (SEI), particularly known for his contributions on software architecture in practice.

<span class="mw-page-title-main">Arcadia (engineering)</span>

ARCADIA is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.

Architecturally significant requirements are those requirements that have a measurable effect on a computer system’s architecture. This can comprise both software and hardware requirements. They are a subset of requirements, the subset that affects the architecture of a system in measurably identifiable ways.

In software engineering and software architecture design, architectural decisions are design decisions that address architecturally significant requirements; they are perceived as hard to make and/or costly to change.

References

  1. ↑ Wojcik, Rob; Bachmann, Felix; Bass, Len; Clements, Paul C.; Merson, Paulo; Nord, Robert; Wood, William G. (November 2006). "Attribute-Driven Design (ADD), Version 2.0". SEI.
  2. ↑ "Attribute-Driven Design Method". SEI.
  3. ↑ Bachmann, Felix; Bass, Len (2001). "Introduction to the Attribute Driven Design Method". IEEE. pp. 745–746. CiteSeerX   10.1.1.97.5395 .
  4. ↑ Bass, Len; Clements, Paul; Kazman, Rick (2013). "Chapter 17". Software Architecture in Practice (third ed.). Pearson. ISBN   978-0-321-81573-6.
  5. ↑ Cervantes H., Kazman R., Designing software architectures, Addison Wesley, 2016.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.