1. The Architecture Design Process

2. 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

3. 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.

4. 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.

5. 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.

6. Basic Steps of the Architecture Design Process
Understand the problem
Identify design elements and their relationships
Evaluate the architecture design
Transform the architecture design

7. 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.

8. 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;

9. 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.

10. 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.

11. 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.

12. Steps in Identifying Design Elements and Their Relationships
Define the system context
Identify the modules
Describe the components and connectors

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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.

20. 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

21. Modular Operators Splitting a design into two or more modules
Substituting one design module for another
Augmenting the system by adding a new module
Excluding a module from the system
Inverting a module to create new interfaces (design rules)
Porting a module to another system

22. 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