Chapter Three

Envisioning Architecture

1
 The Architecture Business Cycle
The architecture business cycle refers to the iterative process
of creating, evolving, and managing software architecture
throughout its lifecycle.
It involves several key stages:
 Requirements Gathering: Understand the project’s
objectives, functional requirements, and non-functional
requirements to establish a solid foundation for
architecture design.
 Architecture Design: Create a high-level design that
addresses the project’s requirements, including selecting
suitable architectural styles, components, and interfaces.

2
 The Architecture Business Cycle
 Implementation: Develop the software solution based on the
architectural design, ensuring that the chosen technologies and
frameworks align with the defined architecture.
 Testing and Validation: Conduct thorough testing to ensure
the software meets the defined requirements and adheres to
the architectural principles.
 Deployment and Operation: Deploy the software into the
production environment, monitor its performance, and address
any issues that arise during operation.
 Maintenance and Evolution: Continuously maintain and
improve the software architecture as new requirements
emerge or technologies evolve, ensuring long-term viability.
3
 What is Software Architecture?
Software architecture forms the basis of any software project
and serves as an extensive framework for building,
implementing, and maintaining software systems.
It functions as the blueprints for the system and the
development project.
The software architecture of a system represents the design
decisions related to overall system structure and behavior.
Architecture helps stakeholders understand and analyze how
the system will achieve essential qualities such as
modifiability, availability, and security.

4
 Cont…
 Key Principles of Software Architecture: Developers must follow
several key concepts to produce an efficient software architecture:
 Modularity: The software system must be divided into different
stand-alone blocks or parts. Such a modular strategy encourages
reusability, thus making both development and maintenance easier.
 Separation of Concerns: is a principle used in programming to
separate an application into units, with minimal overlapping between
the functions of the individual units. The division of this group
decreases the reliance on the system and its maintenance ability.
 Abstraction: Abstracting involves masking complex implementation
details with easy-to-use front ends. It helps that a developer doesn't
get bogged in specifics and instead can focus on big-picture items.

5
 Cont…
Decomposability: Complicated systems or issues should be
divided into smaller, easily manageable units. As a result,
development tests and maintenance become easier.
Flexibility: Therefore, the architecture must be versatile and
consider future developments. Therefore, adding or
subtracting items or changing specifications should easily
avoid a big disruption during work processes.

6
 Types of Software Architecture Patterns
different types of software architecture patterns could help
development teams build successful products.
Understanding a few characteristics of the most popular
architectures and design patterns should make it easier for teams
to reach their goals.
 Model-View-Controller Pattern (MVC)- The three
interdependent components of MVC are Model (data and
business logic), View (presentation and user interface), and
Controller (handling user input). This is a common strategy
adopted by many web and desktop applications.
 Layered Architecture: The program is split into numerous
layers with different responsibilities. Some layers include the
display, business logic, and data access layers.
7
 Cont…
 Microservices: The microservices design facilitates the
division of a system into several small and independent
services. They can also develop, run, and scale them
independently. This is a good strategy for large and complex
applications.
 Event-Driven Architecture: It links message and event
components here in this case. The actor model is appropriate
for reactive real-time processes, distributed systems, and
event processing for nonfunctional requirements.
 Component-Based Architecture: This approach enables
one to develop reusable components with different
functionalities within the same software. It will help you
create flexible plans that are easy to understand.
8
 Software Architecture Challenges
Although software architecture has many advantages, it
also has its share of difficulties:
Complexity: The more complex the architecture of
software systems becomes, the harder it is to design and
maintain them. However, it's important to keep a simple
and modular architecture for fear of overloading.
Changing Requirements: Software architectures must be
adaptive to the evolving requirements of users and
businesses. This calls for combining rigidity with elasticity.
Security issues: Lack of proper architectural design can
lead to vulnerabilities and security breaches. Security
should be considered at all levels of the architecture.
9
 Cont…
Scalability issues: However, not all architectural designs have
such qualities. However, assuming that all architectural designs
may be easy to scale is difficult. Therefore, it is necessary to
ensure that the architecture can change to suit the application's
needs. Consequently, modifications should accompany the
architectural framework to facilitate the application's needs.
Cost considerations: Certain system operational cost decisions
can also be influenced by some of the architecture choices. The
balance between price and performance must be struck.
Documentation and Communication: Good documentation
of the architectures and effective communication between the
development team ensures that everyone understands and
follows the architectures properly.
10
 Architectural structures and views
A view is a representation of a coherent set of
architectural elements, as written by and read by
system stakeholders.
It consists of a representation of a set of elements
and the relations among them. A structure is the set
of elements itself, as they exist in software or
hardware.

11
 4+1 Architectural View Model
4+1 architectural view model is a model for describing
the architecture of software-intensive systems, based on
the use of multiple, concurrent views.
 Views are used to describe the system from the viewpoints of
different stakeholder, such as end users, developers and project
managers
 Suitable for large and challenging architectures
It was created by Philippe Kruchten.
It is very important to mention that 4+1 was released
two years before the first introduction of UML but the
4+1 approach stills plays a relevance today and is UML
friendly, even on its latest version (2.5.1).
12
 4+1 Architectural View Model
 The views of the 4+1 model are:

 Logical View: Shows the components of the system as well as their

interactions. It can be modelled using class, object, state machine and
sequence diagrams.
 Process View: Captures the concurrency and synchronization aspects of
the design. This view can be modelled with UML´s activity diagrams.
13
 4+1 Architectural View Model
Physical View: Describes the mapping of the
software onto the hardware. Deployment diagrams
are used to model this view.
Development View: Describes the organization of
the software in its development environment. This
view can be modelled with UML´s component and
package diagrams.
Use Case View: It is illustrated by selected use
cases or scenarios. It contains diagrams describing
what the system does from a black box perspective.
14 This view contains use case diagrams.
 The Architecture Business Cycle
Benefits of 4+1:
 Better organization with better separation of concern
 The 4+1 maps stakeholders to the information they
need, without requiring specific notations.
 Drawbacks:
 4+1 was created in 1995, where software development
was very different than today, there was no need for
more than 2 or 3 views. Nowadays, there are many
complex systems which can´t be represented correctly
with 4+1.

15
 4+1 View cont’d
 Logical
 Focus: Functional requirements of the system
 Viewer: End-user
 UML-Diagram: Class diagrams, sequence diagrams

 Development (implementation)
 Focus: Software module organization (Static organization of the software in its
development environment )
 Viewer: Programmers and project managers
 UML-Diagram : Component diagram, Package diagrams

 Process
 Focus: Runtime behavior of the system, such as the system processes and
communication, concurrency, performance and scalability(Non-functional
requirements)
 Viewer: integrator(s)
16  UML-Diagram : Activity diagrams.
 4+1 View cont’d
Physical (Deployment)
Focus: Non functional requirements for hardware(looking at
the system topology, deployment and communication)
Viewer: System Engineers
UML-Diagram : Deployment diagrams

 Use case view(Scenarios)

Focus: Use cases for illustrating and validating the
architecture
Viewer: evaluators and all stakeholders of other views
UML-Diagram : Use case diagrams
17
 ADLs
Architectural description languages – ADLs
are design languages used to describe a
system that possess design language properties
like:
Composition
Abstraction
Reusability
Configuration
Heterogeneity
Analysis
18
 ADLs cont’d
 Programming language structures are inadequate for describing
architectural elements.
 Furthermore, they provide no way to model a strict separation of
concerns between architectural-level design issues and detail
design issues.
 Languages in general serve the purpose of describing complex
relationships among primitive elements and element combinations
 Having identified semantic constructs it makes sense to define a
language around them
 Common architectural description elements include:
 (Pure) computation (processing elements) – simple input/output relations with
no retained state
 Memory (data elements) – shared collections of persistent structured data
 Manager – manage state and closely related operations
 Controller – governs the sequence of operations
19  Link – transmit information between elements