Student: Mathews Jovel Castro Id: 114409424

Essay I: Architectural Blueprints—The “4+1” View

Model of Software Architecture.

Autor: Philippe Kruchten

The software architecture consists of a set of patterns which constitute a frame of

reference for its guidance and construction. This allows the entire development area
to interact in the same line of work, as well as to fulfill all the requirements that the
software demands.

A model is a complete, basic and simplified description of the software architecture

that consists of multiple views from a particular perspective or point of view. The
view represents a complete system from the perspective of a set of issues related to
it. It is used to describe the system from the point of view of different stakeholders,
such as end users, developers, project managers and evaluators.

There are different models and proposed views that try to represent in a single view
all the requirements, restrictions and participants of the system to be developed,
however, is it possible to use a single model to holistically represent a system?

Sometimes, the software architecture encompasses its design sequels, addressing

issues ranging from software partitioning, engineering and data manipulation,
efficiency, organization and teamwork, and even does not even focus on meeting
customer needs

Philippe Kruchten, an engineer and professor of software engineering in British

Columbia, Vancouver, Canada, designed the 4 + 1 model to address what was
described above. The 4 + 1 view model or (4 + 1 view model) stands for software
architecture through five concurrent views. These views are: the logical, process,
development, physical view and a scenario or use case which is the corresponding
plus or “+1” of the model. According to the model, each view represents a set of
interests of different stakeholders or interested in the system.

The logical view is responsible for describing the structure and functionality of the
system. This view mainly illustrates the functional requirements, bone, what the
system must provide to its users in terms of services. The system also breaks down
into a series of key abstractions, which come mainly from the problem domain, and
are represented in the form of objects or classes of objects. The UML diagrams used
to represent said view are, class diagrams, Communication diagram, Sequence
Diagram.

The process view, as the name implies, explains the system processes and how
they communicate. This takes into account some non-functional requirements such
as performance and availability, as well as paying attention to concurrency and
distribution processes, integrity and fault tolerance.

The process view also allows you to define the control point at which some activity
corresponding to a class is executed in the logical view. In UML the Activity Diagram
is used to represent this view.
The development view, also known as the implementation view, illustrates the
system from the perspective of the programmer. It focuses on the actual organization
of software modules in the development environment and packages such software
into small parts (libraries) of programs or subprograms developed by one or more
developers. The subsystems are organized through well-defined layers in order to
support the upper layers.

This view is also responsible for administration, reuse and restrictions according to
the tools or programming language used. Package and component diagrams are
commonly used to represent this view.

The physical view is responsible for representing the physical distribution in which
the system will be implemented. It is related to the topology of software components
in the physical layer, as well as the physical connections between these
components. This view is also referred to as a deployment view.

This view is based on the non-functional requirements of the system such as

availability, reliability, performance, and scalability. The system runs on a network of
computers or nodes which consists of subnets, processes, tasks and previously
identified objects. The Deployment Diagram is the one commonly used to represent
this view.

The scenarios describe sequences of interactions between objects, and between

processes. They are used to identify and validate the architecture design. It is
illustrated using the use case diagram, which generates a fifth view.

Software designers organize their architecture decisions in these four views

described above, then they are illustrated in a reduced set of use cases or scenarios,
which constitute the last view. Architecture partially evolves from these scenarios.

Each view is composed of a set of elements, such as components, containers and

connectors. These components allow the patterns, restrictions and requirements
related to the architecture to be captured through a diagram, each with its own
particular notation.