The document discusses architectural design, which involves identifying system subsystems and frameworks for communication. Key architectural decisions address important requirements and are documented. Architecture decisions are important to communicate rationale for changes and trace decisions to requirements. Architectural views represent different perspectives of a system through modules, processes, distribution, and development structure using the 4+1 model.

1. Architectural Design

2. Software architecture
• The design process for identifying the sub-
systems making up a system and the
framework for sub-system control and
communication is architectural design.
• The output of this design process is a
description of the software architecture.

3. Architectural design
• An early stage of the system design process.
• Represents the link between specification and design processes.
• Often carried out in parallel with some specification activities.
• It involves identifying major system components and their
communications.
Chapter 6 Architectural design 3

4. Architectural design decisions
• In software engineering
and software architecture design, architectural decisions(ADs) are
design decisions that address architecturally significant requirements,
they are perceived as hard to make and/or costly to change.
• We document the architecture decisions in Architecture decision
records or logs, is a technique for capturing important architectural
decisions along with their context and consequences.

5. Why are the architecture decisions important?
• Communicating the architectural change and the decision, we can
consider it as a way of thinking to summarize why we needed this
decision and why we decided this change to happen and chose this
option for it, and also it describes what will be the impact of this
change based on the decision has been taken. This is important to
another stakeholder, for example, business users, domain architects
or developers.
• It will provide a way of traceability of these decisions as we know why
we took them, what are the concerns and business requirements
related to these decisions, who are the contributors to these
decisions.
• The decisions logs, and records are used to keep track of these
decisions and how they are compliant with the standards we are
following.

6. How can we document the Architecture decision?

7. Architectural views
• A view is a representation of an entire system from the perspective of
a related set of concerns. It is used to describe the system from the
viewpoint of different stakeholders such as end-users, developers,
project managers, and testers.
• Each architectural model only shows one view or perspective of the
system.
• It might show how a system is decomposed into modules, how the run-time
processes interact or the different ways in which system components are
distributed across a network. For both design and documentation, you usually
need to present multiple views of the software architecture.
Chapter 6 Architectural design 7

8. 4+1 view Model
• The logical view or conceptual view − It describes the object model of the
design.
• The process view − It describes the activities of the system, captures the
concurrency and synchronization aspects of the design.
• The physical view − It describes the mapping of software onto hardware and
reflects its distributed aspect.
• The development view − It describes the static organization or structure of
the software in its development of environment.
• This view model can be extended by adding one more view called scenario
view or use case view for end-users or customers of software systems.

9. The following figure describes the software architecture using five concurrent views
(4+1) model.