1. An Architecture-Centric Process
Chapter 5
An Architecture-Centric Process

2. The Importance of Models
A model is a simplification of reality that helps us master a large,
complex system that cannot be comprehended easily in its entirety.
Models help developer to understand and shape both the problem and the solution.
The choice of models and techniques have an effect on the way we think about problem and shape the solution.
The model is a map not territory
However, best models are the ones that stick very close to reality.
We need multiple models to address different concerns.
Models are complete, consistent representations of the system to be built.

3. Architecture
Given a task of describing a system so that designers, programmers, users and managers would be able to:
Understand what the system does
Understand how the system works
Work on one piece of the system
Extend the system
Reuse part of the system to build another one.
Then, given a limited amount of space for this task
What we would end up with is a description of architecture of the system
Architecture is what remains when we cannot take away any more things
And still understand the system and explain how it works.

4. The Importance of Architecture
Architecture ended up taking the form of an unmaintained document of a few diagrams made of boxes and arrows reflecting imprecise semantics that could be interpreted only by its authors.
Having poor architecture:
As systems evolve and grow to accommodate new requirements, things break and system do not scale up.
Thus, systems are not very resilient in response to changes.
Not having an architecture, or using a poor one, is a major technical risk for software projects.
Poor architecture can lead to project failures.

5. Architecture Today
As systems evolve rapidly, we need to achieve large-scale reuse across families of systems.
We build systems from ready-made components.
We need conceptual tools to manage a system.
To adopt an architecture focus, three things are required:
An understanding of the purpose
An architectural representation
An architectural process

6. Architecture Today (cont.)
An understanding of the purpose
Why is architecture important?
What benefits can we gain from it?
How can we exploit it?
An architectural representation
To make the concept of architecture less fuzzy, we need to agree on a way to represent it
Hence, it becomes something concrete that can be communicated, reviewed, commented on and improved systematically.
An architectural process
How do we create and validate an architecture that satisfies the needs of a project?
Who does it?
What are the artifacts and the quality attributes of this task?

7. Definition of Architecture
RUP defines “architecture” as follows:
Architecture encompasses significant descriptions about:
The organization of a software system
The selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaboration among those elements
The composition of these elements into progressively larger subsystems
The architectural style that guides this organization, these elements and their interfaces, their collaborations and their composition.

8. Definition of Architecture (cont.)
Software architecture
concerned with structure and behavior as well as context: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and trade-offs, and aesthetics.
Architecture is a part of design:
It is about making decisions about how the system will be built. (But it is not all of design, it stops at the major elements.)
Architecture is about structure and about organization,
but it is not limited to structure, it also deals with behavior.
Architecture fits into the system in two concepts:
Operational context: its end users
Development context: the organization that develops the system

9. Architecture Representation
Many different parties are interested in architecture:
System analyst
uses it to organize and articulate the requirements and to understand the technological constraints and risks.
End users or customers
use it to visualize at a high level what they are buying.
Software project manager
uses it to organize the team and plan the development.
Designers
use it to understand the underlying principles and locate the boundaries of their own design.
Other development organizations
use it to understand how to interface with it.
Architects,
use it to reason about evolution or reuse.

10. Architecture Representation (cont.)
Various stakeholders have different concerns and are interested in different aspects of the architecture.
We must have an architectural representation to allow the stakeholders to communicate, discuss, and reason about the architecture.
Hence, a complete architecture is a multidimensional things. Architecture is not flat.

11. Multiple Views
For a building, different types of blueprints are used to represent different aspects of the architecture:
These include:
Floor plans
Elevations
Electrical cabling
Water pipes, central heating, and ventilation
The look of the building in its environment (in sketches).
These blueprints are not independent of each other Rather, they must be carefully coordinated.

12. Multiple Views (cont.)
In the architecture of a software-intensive system, we can envisage various blueprints of various purposes:
To address the logical organization of the system
To organize the functionality of the system
To address the concurrency aspects
To describe the physical distribution of the software on the underlying platform
Etc.
These are what we call architectural views.

13. The 4+1 view model of architecture
Logical View
Process View
Implementation
View
Deployment
Use-Case View
End User
Functionality
Analysts/Testers
Behavior
System Integrators
Performance
Scalability
Throughput
Programmers
Software Management
System Engineering
System Topology
Delivery, Installation
Communication

14. Logical View
This view of architecture addresses functional requirements of the system.
Easily speaking, it addresses what the system should do for its end users.
It is an abstraction of the design model and identifies major design packages, subsystem, and classes.

15. Implementation View
It describes the organization of static software modules in development environment.
It addresses the issues of ease of development, management of software assets, reuse, subcontracting, and off-the-shelf components.
(source code, data files, components, executables, and other accompanying artifacts)

16. Process View
It addresses the concurrent aspects of the system at runtime.
It addresses issues such as concurrency and parallelism, system start-up and shutdown, fault tolerance, and object distribution.
It deals with issues such as deadlock, response time, throughput, and isolation of functions and faults.
It is concerned with scalability.

17. Deployment View
It shows how various executables and other runtime components are mapped to the underlying platforms.
It is where the software engineering meets system engineering.
It addresses issues such as deployment, installation, and performance.

18. Use-Case View It plays a special role with regard to the architecture.
It contains a few key scenarios or use cases.
Initially, these scenarios are used to drive the discovery and design of the architecture in inception and elaborations phases.
Later they will be used to validate different views.
These few scenarios act to illustrate in software architecture document how the other views work.

19. Models and Views
We create different models to address different needs.
Models are complete representations of the system
An architectural view focuses only on what is architecturally significant.
If we do not make this distinction, there is no clear way to distinguish “design” form “architecture.”
Not all design is architecture.
An architecturally significant element has a wide impact on structure of the system and on its performance, robustness, evolvability, and scalability.
It is an element that is important for understanding the system.

20. Architecturally Significant Elements
Major classes, in particular those classes modeling major business entities
Architectural mechanisms that give behavior to these classes, such as persistency mechanisms and communication mechanisms
Patterns and frameworks
Layers and subsystems
Interfaces
Major processes, or threads of control

21. Relationship between Models and Views
Architecture View
Design model
Logical view
Design model*
Process view
Implementation model
Implementation view
Deployment model
Deployment view
Use-case model
Use-case view
* Or a process model for a complex system

22. Architecture is More Than a Blueprint
To validate the architecture and to assess its qualities in terms of feasibility, performance, flexibility, and robustness, we must build it.
Building the architecture, validating it, and then baselining it are primary objectives of elaboration phase.
The most important artifact associated with the architecture is an architectural prototype
It implements the most important design decisions sufficiently to validate them – (to test and measure them)

23. An Architecture-Centric Process
RUP defines two primary artifacts related to architecture:
Software Architecture Description (SAD)
Which describes the architectural views relevant to the project.
Architectural prototype
Which serves to validate the architecture and serves as the baseline for the rest of the development.
These two key artifacts are the root of three others:
Design guidelines are shaped by some of the architectural choices made and reflect the use of patterns and idioms.
Product structure in the development environment is based on the implementation view.
Team structure is based on the structure of implementation view.

24. RUP Roles A Role: Software Architect is responsible for architecture.
Architects are not only ones concerned with architecture.
Most team members are involved in the definition and implementation of architecture, especially in elaboration phase:
Designers
focus on architecturally significant classes and mechanisms rather than on the details of the classes.
Integrators
integrate major software components to verify the interfaces.
Integrators focus mainly on removing interaction risks related to major off-the-shelf or reused components.
Testers
test the architectural prototype for performance and robustness.

25. The Purpose of Architecture
Intellectual Control
Reuse
Basis for Development

26. Intellectual Control
A complex system is more than the sum of its parts.
It must provide rules about how to grow the system without having its complexity multiply beyond human understanding.
We want control of architecture to design and build system that are continuously integrated as “one” without leading to difficult “integration phases”.
Architecture establishes a means of effective communication and understanding throughout the project by establishing a common set of references and a common vocabulary for discussing design issues.

27. Reuse Architecture provides an effective basis for large-scale reuse.
By articulating major components and critical interfaces between them, an architecture allows reason about reuse.
It assists both internal reuse and external reuse.
Architecture also facilitates reuse on a larger scale:
Reuse of architecture itself in the context of a line of products that addresses varying functionality in a common domain.
Architects will understand the limits of scalability, identify the generic parts, and define the variation points.

28. Basis for Development
Architecture provides a basis for project management.
Planning and staffing are organized along the lines of major components: layers and subsystems.
Development is partitioned across a set of small teams;
each of which is responsible for one or several parts of the system.
Architecture and work done during elaboration phase provide basis for further development including:
Design guidelines, principles, styles, patterns, and mechanism to reuse.

29. Component-Based Development
Component-based development is about building quality systems
that satisfy business needs quickly, preferably by using parts
rather than handcrafting every individual element.
A definition of component must be broad enough to address conventional components (such as COM/DCOM, CORBA, and JavaBean components) as well as alternative ones (Web pages, database tables, and executables using proprietary communication).
It shouldn’t be so broad as the encompass every possible artifact of a well-structured architecture.

30. A Definition of Component
A component is a nontrivial, nearly independent, and replaceable part of a
system that fulfills a clear function in the context of a well-defined architecture.
Runtime components
The things that are delivered, installed, and run, such as executables, processes, and DLLs.
Development components, as seen from the development organization point of view.
Implementation subsystems that have high internal cohesion and low external coupling and are reusable by other developers.
Business components
Cohesive sets of runtime components that fulfill a large chunk of business-level functionality and are units of sale, release, or upgrade.

31. Other Architectural Concepts
Architectural Style
Architectural Mechanism
Architectural Pattern

32. Summary
System architecture is used in the RUP as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development.
Architecture is a complex concept that is best represented by multiple, coordinated architectural views.
An architectural view is an abstraction of a model that focuses on its structure and its essential elements.