The Architecture Design Process

Architecture Design

Focuses on the decomposition of a system into components and the interaction between those components to satisfy functional and non functional requirements

A software system can be viewed as a hierarchy of design decisions (design rules or contracts)

Each level of the hierarchy has a set of design rules that connects the components at that level

The Architectural View

The first phase is the predesign phase – concerned with understanding the enterprise context in which the application will exist.

The second phase is the domain analysis phase – where requirements are analyzed and structured with respect to the problem domain.

The Architectural View (Cont’d)

The third phase is the schematic design phase – where solution models identify modules of the system and design rules that establish the boundaries between the modules are established.

The fourth phase is the design development phase – where the architecture is refined and possibly multiple variations are created.

When Are the Architecture Design Activities Done?

They can be practiced during any phase of the development process.

However, to be of greatest benefit they should be done as early as possible.

These activities can be viewed as a linear set of steps that can be repeated whenever missing information or hidden assumptions are identified.

Basic Steps of the Architecture Design Process

1. Understand the problem

2. Identify design elements and their relationships

3. Evaluate the architecture design

4. Transform the architecture design

System Quality Attributes

The architecture essentially defines "externally visible" properties also known as system quality attributes for the whole software project, we are referring to such properties as its provided services, performance characteristics, fault handling, shared resource usage, and so on.

Evaluation of an architecture's properties is critical to successful system development. However, reasoning about a system's intended architecture must be recognized as distinct from reasoning about its realized architecture. As design and eventually implementation of an architecture proceed, faithfulness to the principles of the intended architecture is not always easy to achieve.

Run-Time Quality Attributes

Performance refers to the responsiveness of the system, the 'time’ required to respond to stimuli (events) or the number of events processed in some interval of time.

Performance qualities are often expressed by the number of transactions per unit time or by the amount of time it takes a transaction with the system to complete.

Since communication usually takes longer than computation, performance is often a function of how much communication and interaction there is between the components of the system-clearly an architectural issue.

Security is a measure of the system's ability to resist unauthorized attempts at usage and denial of service while still providing its services to legitimate users.

It is categorized in terms of the types of threats that might be made to system;

Run-Time Quality Attributes (Cont’d)

Availability measures the proportion of time the system is up and running. It is measured by the length of time between

failures as well as by how quickly the system is able to resume operation in the event of failure. The steady state availability of a system is the proportion of time that the system is functioning correctly and is typically seen as follows:

time to failure/(time to failure + time to repair) Availability comes from both "time to failure" and

"time to repair"; both are addressed through architectural means.

Understanding the Problem

Without a clear understanding of the problem, it is not possible to create an effective solution

When making a design decision, ask yourself what problem the design decision solves.

If the answer is a technical or implementation problem, ask the question again until you reach a problem that is part of the original business problem.

If you can’t get there, it’s probably not the right design decision.

Identifying Design Elements and Their Relationships Establish a baseline decomposition that initially

splits the system based on functional requirements.

The architecture of a software application is often represented as a set of interconnected modules or subsystems, often called, components.

The functional decomposition can be modeled using blocks and arrows or by using UML package diagrams that show dependency associations.

Steps in Identifying Design Elements and Their Relationships

1. Define the system context

2. Identify the modules

3. Describe the components and connectors

Defining System Context

The system context describes the application from an external perspective.

It helps in identifying the external interfaces to the system.

The input to defining the system context is the initial requirements list.

Defining the system context is related to understanding the problem domain that the system addresses.

An initial model of the enterprise context of the system can be created by diagramming the existing business processes, artifacts, people, and existing systems.

Defining System Context (Cont’d) The new application should fit within this

context. A use case diagram is a common way to depict

the system context. The diagram can be augmented to include

business-level objects (documents, records, reports) that are part of the domain.

The goal of the model is to communicate the purpose and scope of the system; it should be intuitive and understandable by even the least technical stakeholders.

Identifying Modules

Modules are discrete units of software. Instantiations of these modules are

commonly called components and connectors.

A modular architecture is an application or system that is composed of two or more modules, each of which can be modified internally without affecting the other.

Identifying Modules (Cont’d)

To achieve a low level of coupling between modules, the interface (connector) between the modules must be stable and static.

These interfaces are the result of establishing design rules, e.g., A common data format like XML Document Type

Definition (DTD). A procedural interface such as a set of Java

classes. A wire-level protocol like HTTP and HTML.

Describing Components and Connectors

Components typically refer to the runtime instance of some unit of software.

Connectors can refer to a unit of software or some communications mechanism (like UNIX pipes)

Many of the quality attributes of the system are embodied in the components and their connectors.

Evaluating the Architecture

This step is determining whether the architecture satisfies the requirements of the system.

Both qualitative and quantitative measures are used to evaluate the quality attributes required of the system.

If the it fails to meet these quality attributes, the architecture must be redesigned.

Evaluating the Architecture (Cont’d) In order to evaluate an architecture design, the

quality attribute requirements must be clearly articulated.

They must be articulated as specific quality attributes and their acceptable values.

For example, a modifiability requirement may be reified as a scenario called a change case which might describe that a change is possible without requiring rework of more than one module.

Transforming the Architecture

If the architectural design does not full satisfy its quality attribute requirements, then it must be changed until it does.

A design is transformed by applying design operators, styles, or patterns.

There are two types of design operators: Those that affect the modular architecture Those that affect the component

architecture

Modular Operators

1. Splitting a design into two or more modules

2. Substituting one design module for another

3. Augmenting the system by adding a new module

4. Excluding a module from the system5. Inverting a module to create new

interfaces (design rules)6. Porting a module to another system

Design Operators

Decomposition of a system into components Replication of components to improve reliability Compression of two or more components into a

single component to improve performance Abstraction of a component to improve

modifiability and adaptability Resource sharing, or the sharing of a single

component instance with other components to improve integrability (the ability to integrate applications and systems), portability and modifiability