Chapter 5

An Architecture-Centric Process

2

The Importance of Models

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

A model is a simplification of reality that helps us master a large, complex system that cannot be comprehended easily in its entirety.

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

ImplementationView

DeploymentView

Use-Case View

End UserFunctionality

Analysts/TestersBehavior

System IntegratorsPerformanceScalabilityThroughput

ProgrammersSoftware Management

System EngineeringSystem TopologyDelivery, InstallationCommunication

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

Model 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

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

Component-based development is about building quality systems that satisfy business needs quickly, preferably by using parts

rather than handcrafting every individual element.

30

A Definition of Component

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

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.

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.