Scribd
Upload
11 views

Software architecture views

Uploaded by

Teodora037
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
11 views

Software architecture views

Uploaded by

Teodora037
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Week 3: Software Architecture Views

This slide show introduces software architecture views.


An architecture view is defined in the ISO 42010 standard on
systems and software engineering - architecture description as a
“work product expressing the architecture of a system from the
perspective of specific system concerns.”
An important related concept are architecture viewpoints. They
are defined as a work product establishing the conventions for the
construction, interpretation and use of architectural views to
frame specific system concerns. An architecture viewpoint
governs an architecture view in the sense that the viewpoint
defines the kinds of models that can be used in the view.
Just as in build architecture where multiple plans of a building are
used to illustrate, model and plan the building. Architecture views
make complex systems understandable. The idea is to look only
at those aspects of the system that are relevant for a task at
hand. Architecture views should either support different
stakeholders or tasks or represent different aspects of
architectural modeling or abstraction levels.
Different views can also be used to model different abstraction
levels. The idea or analogy is to introduce a zoom factor for the
architecture models. That is, we want to achieve a refinement of
models in multiple levels. Consider the example of three levels of
models. At the highest level, there is an organizational or very
high level view which structures the organization in which the
architecture is created. Below that we can model a system or high
level view which model systems and system interconnections in
the organizations and to external systems. And the lowest level of
the architecture views we would model a component or low level
view which models components of one system as well as
functional and non functional aspects.
There are a number of existing view models, for example, the
Zachman-Framework is a framework for enterprise architecture

1
which provides a formal and highly structured way of viewing and
defining an enterprise.
RM-ODP the reference model for open distributed processing is a
reference model which provides a coordinating framework for the
standardization of open distributed processing.
The 4 + 1 view model is a popular view model for describing the
architecture of software intensive systems based on multiple
concurrent views.
The software engineering institutes (SEI) view types model
defines 3 view types, component and connector, module and
allocation which are associated each with a number of styles.
Finally, the Rozanski/Woods viewpoints and perspectives define 7
viewpoints combined with perspectives on them.
The 4 + 1 view model is a view model designed by Philippe
Kruchten for describing the architecture of software intensive
systems. The logical view is concerned with functionality that the
system provides. The development view illustrates a system from
a programmer's perspective - this view is also known as the
implementation view. The process view focuses on the runtime
behavior of the system. It deals with the dynamic aspects of the
system and explains the system processes and how they
communicate. The physical view depicts the system from the
operations point of view. It is concerned with how the components
of the system are deployed (hence it is also known as the
deployment view). The description of an architecture is illustrated
using a small set of use cases or scenarios. Scenarios are the plus
one view as the information they contain is redundant with the
information in the other views. It is important to focus on those
use cases and scenarios which are important enough to carry
architectural relevance(značajnost). So this additional view also helps
to decide what belongs into the architecture and what not.
Let's contrast this view model to the viewpoints and perspectives
by Rozanski and Woods. This model contains 6 core viewpoints
and an additional context viewpoint. They are refined by
2
orthogonal perspectives, not shown here, so this viewpoint model
is much more detailed than the 4 + 1 model.
The context viewpoint describes the relationships, dependencies,
and interactions between the system and its environment (the
people, systems, and external entities with which it interacts).
The functional viewpoint describes the system’s functional
elements, their responsibilities, interfaces, and primary
interactions.
The information viewpoint describes the way that the architecture
stores, manipulates, manages, and distributes information. Hence
these two viewpoints are similar to the logical view in 4 + 1, but
functional and information aspects are considered separately.
The concurrency viewpoint is similar to the process view in 4 + 1,
and it describes the concurrency structure of the system and
maps functional units to concurrency units to clearly identify the
parts of the system that can execute concurrently, and how this is
coordinated and controlled.
The development viewpoint is similar to the same named
viewpoint in 4 + 1, and it describes the architecture that supports
the software development process. Development views
communicate the aspects of the architecture of interest to those
stakeholders involved in building, testing, maintaining and
enhancing the system.
The deployment viewpoint describes the environment into which
the system will be deployed, including capturing the
dependencies the system has on its runtime environment.
The operational viewpoint describes how the system will be
operated, administered or supported when it is running in its
production environment. Those two views combined make up the
physical view in 4 + 1.
In summary, there are a number of popular architecture view
models which introduce multiple views to better manage the
complexity of software intensive systems.

3
4

You might also like