Chapter 8

Analysis in the Design Process

Outline

• Business Case• Step 1: Review Inputs• The Design Process– Iteration 1– Iteration 2– Iteration 3

• Summary

Analysis and Design

• Analysis is the process of breaking a complex entity into its constituent parts as a means of understanding it.

• The opposite of analysis is synthesis. • Analysis and design are therefore intertwined

activities. • Both are needed for system success: “I

believe” isn’t good enough.

Analysis and Design• During the design process, the activity of analysis can

refer to several aspects: – Studying the inputs to the design process to understand the

problem whose solution you are about to design, e.g. giving priority to architectural drivers. This type of analysis is performed in steps 1 and 2 of ADD.

– Studying the alternative design concepts that you identified to solve a design problem so as to select the most appropriate one. This activity is performed in step 4 of ADD.

– Ensuring the decisions made during the design process are appropriate. This is the type of analysis that you perform in step 7 of ADD.

Why Analyze

• Analysis and design are two sides of the same coin: – Design is (the process of) making decisions. – Analysis is (the process of) understanding the

consequences— in terms of cost, schedule, and quality—of those decisions.

• No sensible architect makes architectural decisions without attempting to understand their implications.

Why Analyze

• So when and why do we analyze during the design process?

• First, we analyze because we can. • Second, because it is a prudent way of

informing decisions and managing risk. • Third, analysis is the key to evaluation.

Analysis Techniques

Tactics-Based Analysis

• Architectural tactics have been presented thus far as design primitives.

• However, because these taxonomies cover the space of architectural design possibilities for each quality attribute, we can use them to guide analysis.

• Specifically, we can use them as guides for interviews or questionnaires.

• Such interviews can help you gain rapid insight into the architectural approaches taken (or not taken).

Tactics-Based Analysis

• Consider, for example, the tactics for availability:

Tactics-Based Analysis

• Each tactic is a design option for the architect who wants to design a highly available system.– They represent a taxonomy of the entire design

space for availability.– Hence they shed light on the decisions made, and

not made. • We simply turn each tactic into an interview

question.

Example Interview TemplateTactics Group

Tactics Question Supported? (Y/N)

Risk Design Decisions & Location

Rationale and Assumptions

Detect Faults

Does the system use ping/echo to detect a failure of a component or connection, or network congestion? |

Does the system use a component to monitor the state of health of other parts of the system. A system monitor can detect failure or congestion in the network or other shared resources, such as from a denial-of-service attack.

Does the system use a heartbeat--a periodic message exchange between a system monitor and a process--to detect a failure of a component or connection, or network congestion?

Does the system use a timestamp to detect incorrect sequences of events in distributed systems?

Example Interview TemplateTactics Group

Tactics Question Supported? (Y/N)

Risk Design Decisions & Location

Rationale and Assumptions

Recover from Faults (Preparation and Repair)

Does the system employ active redundancy (hot spare)?  In active redundancy all nodes in a protection group (a group of nodes where one or more nodes are “active,” with the remainder serving as redundant spares) receive and process identical inputs in parallel, allowing redundant spares to maintain synchronous state with the active node(s),

Does the system employ passive redundancy (warm spare)?In passive redundancy only the active members of the protection group process input traffic; one of their duties is to provide the redundant spare(s) with periodic state updates.

Conducting the Interview

• In an interview, we record whether or not each tactic is supported by the architecture.

• If we are analyzing an existing system we can additionally investigate:– whether there are any obvious risks in the use (or non-

use) of this tactic – the specific design decisions made to realize the tactic

and where in the code-base the realization is found – any rationale or assumptions made in the realization of

this tactic

Reflective Questions

• Similar to tactics-based interviews, some researchers have advocated the practice of asking reflective questions in the design process.

• The idea is that we think differently when we are problem-solving and when we are reflecting.

• For this reason there should be a separate “reflection” activity that challenges the decisions made, and challenges our biases.

Example Reflective Questions• What assumptions are made? Do the assumptions affect the design problem? Do

the assumptions affect the solution option? Is an assumption acceptable in a decision?

• What are the risks that certain events would happen? How do the risks cause design problems? How do the risks affect the viability of a solution? Is the risk of a decision acceptable? What can be done to mitigate the risks?

• What are the constraints imposed by the contexts? How do the constraints cause design problems? How do the constraints limit the solution options? Can any constraints be relaxed when making a decision?

• What are the contexts and the requirements of this system? What does this context mean? What are the design problems? Which are the important problems that need to be solved? What does this problem mean? What potential solutions can solve this problem? Are there other problems to follow up in this decision?

• What contexts can be compromised? Can a problem be framed differently? What are the solution options? Can a solution option be compromised? Are the pros and cons of each solution treated fairly? What is an optimal solution after tradeoff?

Scenario-Based Design Reviews

• Comprehensive scenario-based design reviews, such as the ATAM, have typically been conducted outside the design process.

• An ATAM review is a “milestone” review. – When an architect believed there was enough of an

architecture to analyze, an ATAM could be convened. – This might be when an architecture had been designed but

before (much) implementation had been completed. – More commonly, it occurred when an existing system was in

place and stakeholders wanted an objective evaluation of its risks.

Scenario-Based Design Reviews

• Having a distinct evaluation activity once the architecture is “done” is a poor fit with modern methods.

• Today, most software organizations practice some form of Agile/iterative development. – There is no distinct “architecture phase” in Agile

processes. – Rather, architecture and development are co-

created in a series of sprints.

Lightweight ATAM

• To better align with current development practices, a lightweight peer review method, based on the ATAM, has been created.

• A lightweight ATAM evaluation can be conducted in a half-day meeting.

• It can be carried out internally, using just project members.

Typical Lightweight ATAM Agenda

Architecture Description Languages

• If you have stringent quality requirements—e.g., latency, throughput, availability, safety, security—you might want to document design decisions in an architecture description language (ADL).

• ADLs lend themselves to formal, automated analysis.

• ADLs typically employ both graphical and textual notations to describe an architecture.

Architecture Description Languages

• The Unified Modeling Language (UML) is the most widely used notation for documenting architectures in industrial practice.

• Few projects endeavor to describe their architectures in any ADL.

• Some ADLs strive to be formal models that have decidable semantics. – they can be automatically checked for properties of

interest, e.g. performance, availability, and safety.

Summary

• Why do architects and programmers regularly commit to (implement) architectural decisions that have not been analyzed?

• If testing code is important, then “testing” the design decisions made is an order of magnitude more important.

• The real question is not whether to analyze, but how much to analyze and when.

• Analysis is inherent in doing good design, and it should be a continuous process.