Module 3– Architectural Views

Module-3 ARCHITECTURAL VIEWS

Syllabus
• Introduction
• Standard Definitions for views
• Structures and views
• Representing views- Available notations
• Standard views –
– 4+1 view of RUP,
– Siemens 4 views,
• SEI’s perspectives and views
• Case studies
 Introduction to Views
• Dictionary Meaning ~ manner of looking at something
• Why (multiple) view ?
– For better understanding and managing , multi dimensional view must be taken for any
complex entity , multiple parameters / specialties involved. ( bcos of its complex nature , it
can’t be described in 1 dimensional view )
• For example, In civil what are the views of a building…
– Room layout
– Front Elevation drawing
– 3D view of building / room
– Electrical diagram
– Plumbing diagram
– Security alarm diagram
– AC duct diagram etc…etc…
• Which of the above view is Architecture ?
– Not one but ALL of them ( sets of parts work together as a successful whole)
• In Software, What are views ? ………..
 Architectural Views

End user Development Programmers

Logical view & software
view
managers

Scenarios

Process View Physical View

Integrator System Engineer

4
 Definition of SW View
• As per IEEE definition,
– Software architecture descriptions are commonly
organized into views,
– Each view addresses a set of system concerns, following
the conventions of its viewpoint.
• Viewpoint - A position or direction
from which something is observed or considered;
• View – Details or full specification considered from that viewpoint
– (~ describes the notations, modeling and analysis techniques that express
the architecture in question from the perspective of a given set of
stakeholders )
– So, a view of a system is a representation of the system
from the perspective of a viewpoint.
 Examples of SW Views
• A view allows a user to examine a portion of a particular interest area.
• A Logical View ( top / overall / bird’s eye view)
– all functions,
– organizations,
• Implementation view
– Technology ( HW and networking)
– Module sequence
• Developmental view
– Front end
– Backend
– Database connectivity
• Process ( Deployment) View
– Modules and its functions,
– Their interactions
– Control points
– Non Functional Requirements
• Security View
– User Id / Password
– Graphical password
– Transactional password
• +++ other views
 Structures and Views
• Structures is a set of coherent elements and
the relations among them.
• View of a system is a representation of the
system from the perspective of a viewpoint.
• Structure is decided on views
 Categorization of Structures
1. Module Structures
2. Component and Connector Structures
3. Allocation Structures
 Module Architecture
• Elements are modules ( Accounts, Registration, Appt. booking,
Consulting)
• Modules are units of implementation
• Each module is built based on Codes
• Each module has a specific assigned functional responsibility
• Includes
– Decomposition – break large system to functionally working ,
understandable modules ( Accounts, Registration, Appt. booking,
Consulting)
– Uses – Each module is used by specific users following procedures ( Dr
Consultation, Registration etc..)
– Layered – Correct layered flow of use relations i.e functionalities( register
– book appt. -pay in accounts – go to Dr)
– Class – It is generalisation allowing to reuse / inherit from other objects
 1 Module Structures
• Elements: modules (units of implementation). Modules
are a code based way of considering the system
• Specifies:
– Functional responsibility of modules
– Other elements a module is allowed to use
– Generalization and specialization relations
• Run-time operation of software is not a concern from
this view ( modularity, modifiability, development, data
integrity, data hiding, reuse are consideed)
 1.1 Decomposition Structure

• Elements: modules in a hierarchy

• Relations: is a sub-module of , shares secret
with
• View:
– Contributes to system's modifiability, by ensuring
that likely changes fall within the scope of at most
a few small modules.
– Modularity, leading to pricing of modules
 1.2 Uses Structure
• Elements: modules, procedures, or resources
on the interfaces of modules
• Relations: uses: (e.g cash collection modules -
> Inpatient module; correct data of the CC
modules is used by IP module for admission)
• View :
– Allows testability, incremental development
 1.3 Layered Structure
• Is a subclass of uses structure
• Elements: layers: a coherent set of related
functionality
• Relations: uses (ideally layer n may only use the
services of layer n – 1), provides abstraction to

• View:
– Layers are often designed as abstractions (virtual
machines) that hide implementation specifics below from
the layers above, (notice how IP knows about payment but
does not get involved)
– Leads to data hiding
 1.4 Class Structure
• Elements: classes
• Relations: is an instance of ( cat is one instance of
a 4 legged animal class), inherits from, ( cat
inherits common properties of 4 legged animals)

• Function Example:
– Allows us to reason about reuse
– incremental addition of functionality ( incremental
development)
– Inheritance
 2 Component and Connector Structures

• Elements: run-time components (principal units of

computation) and connectors (communication vehicle
among components.)
• Specifies:
– Major executing components and how they interact
– Major shared data-stores
– Which part of system is replicated
– Flow of data through the system
– What parts can run in parallel
– How can system structure change as it executes
 2.1 Process Structure
• Elements: processes or threads
• Relations: attachment (that allow
communication, synchronization, and/or
exclusion operations)

• View:
– performance
– availability.
– Functionality and control
 2.2 Shared Data or Repository Structure

• Elements: data stores, data producers, and

data consumers
• Relations: data-flow ( data sharing)

• View:
– To ensure good performance and data integrity.
 2.3 Client-Server Structure
• Elements: clients and servers
• Relations: protocols and message passing
infrastructure( communication between
them).
• View:
– Separation of concerns (supporting modifiability,
change done at server sufficient to reflect in all
clients)
– Work load sharing / Load balancing (supporting
runtime performance)
 3 Allocation Structures
• Show the relationship between the software and the
elements in one or more external environment in which
software is created and executed.
• Specifies:
– The processor that executes each software element
– The file that stores each software element during
development
– Assignments of software to development team
• View :
– File location
– Job allocation
 3.1 Deployment Structure
• Shows how software is assigned to hardware
• Elements: software (usually a process from a
component and connector view), hardware entities,
and communication pathways
• Relations: is-allocated-to and migrates-to (for
dynamic allocations)

• View:
– Allows reasoning about performance, data integrity,
availability, and security.( all run time)
– To take care of during Installation ( like O:, M: etc)
 3.2 Implementation ( development)
Structure
• Shows how software elements (usually modules) are
mapped to the file structure(s) in the system's
development, integration, or configuration management
environments.
• Elements: any logical unit (e.g. module)
• Relations: implemented in

• View:
– management of development activities and build process
– Parent –child blocks
– Data integrity
– P: modules, Q: config files, S: common prog, T: Testing, O: site
ver
 3.3 Work Assignment Structure
• Assigns responsibility for implementing and integrating the
modules to the appropriate development teams
• Elements: any logical unit (e.g. module)
• Relations: is assigned to

• View:
– The architect will know the expertise required on each
team
– The means for factoring functional commonalities and
assigning them to a single team, rather than having them
implemented by everyone who needs them.
– Supportability
 Structure and View
Conclusions
• Each structure is useful on its own right but not all
structures are used in all projects.

• Structures are not independent and must be

considered wrt View
– e.g. relationship of modules with components (many to
many)
– Some structures may be the same in some systems
– Some structures may be combined (e.g. all component and
connector structures may be combined in a single
structure – tightly coupled)
 Representing Views
(Available notations)
• Traditionally views were used for conditions
– Graphical representation
– Tabular representation
• Other popular views
– 4+1 Rational Unified Process ( RUP)
– Siemen’s 4 view
 Graphical Design Notation
T F

Sequence If-then-else

T
F F
T
F T
T
F

Selection Repetition
29
 Tabular Design Notation
Rules
Conditions 1 2 3 4
Condition A T T F
Condition B F T
Condition C T T
Actions
Action X  
Action Y 
Action Z   

30

 Rational Unified Process (RUP) View
( Kruchten 4+1)
• 4 main views of a SW + 1 view tying them together
• 4 Main views
– Logical View
• Functional requirements
– Process View
• Concurrent and non concurrent functionalities
– Deployment View
• Run time components mapping to computing platform
– Implementation View ( development)
• Organisation of modules to prog.tools, data files etc..
• 1 connecting view
– Use case view
• Connecting functions to process to programs and data
 What is RUP?
The Rational Unified Process is a software engineering process,
which is an extension to Unified Modeling Language (UML) – a
guide to the effective use of the UML for modeling. It organizes
software projects in
terms of workflows and phases, each consisting of one or more
iterations, in the way that testing and validating design ideas as well
as decreasing risks is possible in the early steps of a lifecycle.
Rational Unified Process (RUP) is an agile software development
method, in which the life cycle of a project, or the development of
software, is divided into four phases. Various activities take place
during these phases: modelling, analysis and design,
implementation, testing and application.
 Problem
• Arch. documents over-emphasize an aspect of
development or do not address the concerns of
all stakeholders
• Various stakeholders of software system:
– end-users
– developers,
– system engineers,
– project managers
• Software engineers struggled to represent more
on one blueprint, and so arch. documents contain
complex diagrams
33
 Solution
• Using several concurrent views or perspectives, with different
notations each one addressing one specific set for concerns
• “4+1” view model presented to address large and challenging
architectures

34
4+1 View Model of Architecture

End user Development Programmers

Logical view & software
view
managers

Scenarios

Process View Physical View

Integrator System Engineer

35
 Logical View ( Functional view)
(Object-oriented Decomposition)
Viewer: End-user
considers: Functional requirements- What the system should
provide in terms of services to its users.
Notation: Object diag, class diag, seq diag, state diag, comn diag
Tool: Rational Rose

36
 Logical Architecture
The logical architecture primarily supports the functional
requirements—what the system should provide in terms of services
to its users. The system is decomposed into a set of key
abstractions, taken (mostly) from the problem domain, in the form
of objects or object classes. They exploit the principles of
abstraction, encapsulation, and inheritance. This decomposition is
not only for the sake of functional analysis, but also serves to
identify common mechanisms and design elements across the
various parts of the system.
A class diagram shows a set of classes and their logical
relationships: association, usage, composition, inheritance, and so
forth. Sets of related classes can be grouped into class categories.
Class templates focus on each individual class; they emphasize the
main class operations, and identify key object characteristics.
Notations – Logical view
Logical architecture example
 Process View
(The process decomposition)
viewer: Integrators
considers: Non - functional requirements
(concurrency, performance, scalability)
• Uses multiple levels of abstractions, a logical
network of processes at the highest level
• A process is a grouping of tasks that form an
executable unit
• Notation : Activity diag

40
 Process Architecture
The process architecture takes into account some non-functional requirements, such as performance
and
availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance,
and
how the main abstractions from the logical view fit within the process architecture—on which thread of
control is an operation for an object actually executed.
The process architecture can be described at several levels of abstraction, each level addressing
different
concerns. At the highest level, the process architecture can be viewed as a set of independently
executing
logical networks of communicating programs (called “processes”), distributed across a set of hardware
resources connected by a LAN or a WAN. Multiple logical networks may exist simultaneously, sharing
the
same physical resources. For example, independent logical networks may be used to support separation
of
the on-line operational system from the off-line system, as well as supporting the coexistence of
simulation
or test versions of the software.
A process is a grouping of tasks that form an executable unit.
Notation for process view
Process view Example
 Development View
(Subsystem decomposition)
Basis of a line of product
Viewer: Programmers and Software Managers
considers: software module organization
(Hierarchy of layers, software management, reuse, constraints
of tools)
Style: layered style
Notation: component dia, package dia.

44
 Development architecture

The development architecture focuses on the actual software

module organization on the software development
environment. The software is packaged in small chunks—
program libraries, or subsystems— that can be developed by
one or a small number of developers. The subsystems are
organized in a hierarchy of layers, each layer providing a
narrow and well-defined interface to the layers above it.
The development architecture of the system is represented by
module and subsystem diagrams, showing the ‘export’ and
‘import’ relationships. The complete development
architecture can only be described when all the elements of
the software have been identified. It is, however, possible to
list the rules that govern the development architecture:
partitioning, grouping, visibility.
Notations of development view
Example of development view
 Physical View ( deployment)
(Mapping the software to the Hardware)
Viewer: System Engineers
Considers: Non-functional req. regarding to underlying hardware
(Topology, Communication)
Notation: deployment diag

48
 Physical Architecture

The physical architecture takes into account primarily the

non-functional requirements of the system such as
availability, reliability (fault-tolerance), performance
(throughput), and scalability.
The software executes on a network of computers, or
processing nodes (or just nodes for short).
The various elements identified—networks, processes,
tasks, and objects—need to be mapped onto the various
nodes. Several different physical configurations will be
used: some for development and testing, others for the
deployment of the system for various sites or for different
customers.
The mapping of the software to the nodes therefore needs
to be highly flexible and have a minimal impact on the
source code itself.
Notations – Physical view
Physical view - example
 Scenarios
(Putting it all together)
Viewer: All users of other views and Evaluators.
Considers: System consistency, validity
Notation: object diag
Tool: Rational Rose
• Help illustrate and validate the document
• Help Architect during the architecture design

52
 Scenario example
Private Automatic Branch Exchange (PABX)
scenario for a local call—selection phase

53
 Correspondence between views
• Views are interconnected.
• Start with Logical view and Move to Development or Process
view and then finally go to Physical view.

54
 The Iterative process
• Not all software arch. need all views.
• A scenario-driven approach to develop the
system
• Documentation:
– Software architecture document
– Software design guidelines

55
 Remarks
• Methodology successfully used in
– Air Traffic Control
– Telecom
• Comprehensive: All other views are reducible
to one of the 4 views

56
 View Vs Notation
Scenario ( outside world view of system) Usecase diag

Logical ( Functional) Class diag,

Seq. diag.,
State Diag.,
Obj. diag.,
Comm. Diag.

Process ( Runtime) Activity

Development Component diag,

Package diag

Deployment ( Physical) Deployment diag

Siemens 4 Views
 Siemens 4 views (S4V)
• Developed at Siemens Corporate Research

• This is based on best architecture practices for industrial systems

• The four views are conceptual, execution, module and code architecture views.

• These four views separate different engineering concerns, thus reducing the
complexity of the architecture design task.

• These views are developed in the context of a recurring Global Analysis

activity.

• In Global Analysis, the architect

– identifies and analyzes key factors,
– explores the key architectural issues or challenges,
– develops design strategies for solving these issues.
 Global Analysis activities
• Factors that influence the architecture are organized
into three categories:
i. organizational
ii. technological
iii. product factors.
• These factors are analyzed in order to determine which
factors conflict, what are their relative priorities, how
flexible and stable is each factor, what is the impact of
a change in the factor, and what are strategies for
reducing that impact.
• From these factors the key architectural issues or
challenges are identified.
Workflow between Global Analysis and
Architecture View Design.
 View design
• The next step is to propose design strategies to
solve the issues, and to apply the design strategies
to one or more of the views.
• During design, the design decisions are evaluated,
particularly for conflicts and unexpected
interactions. This evaluation is ongoing. Thus
Global Analysis activities are interleaved with
view design activities, and the design activities of
each view are also interleaved.
 Periodic architecture evaluation

• Evaluation is part of the design process

• Periodic architecture evaluation is done in order to answer a

specific question, such as cost prediction, risk assessment, or
some specific comparison or tradeoff.

• This typically involves other stakeholders in addition to the

architect.

• Global Analysis provides inputs to this kind of architecture

evaluation, for example: business drivers, quality attributes,
architectural approaches, risks, tradeoffs, and architectural
approaches.
 Conceptual view
• The primary engineering concerns in this view
are to address how the system fulfills the
requirements.
• The central concern in this view
– functional requirements
• ( similar to scenario view of 4+1)
 Module view
• Modules are organized into two orthogonal structures
– decomposition
• The decomposition structure captures how the system is logically decomposed
into subsystems and modules.
– layers.
• A module can be assigned to a layer, which then constrains its dependencies on
other modules.
• The primary concerns of this view are
– to minimize dependencies between modules (max.cohesion),
– maximize reuse of modules,
– testability
• The central concern in this view
– Module decomposition, inheritance , data hiding, cohesion, coupling
etc..)
• ( similar to logical view of 4+1)
 Execution view
• This view describes the system’s structure in terms of its runtime
platform elements.
• Runtime properties of the system are
– Interoperability:
– Manageability:
– Reliability:
– Scalability:
– Performance:
– Security:
– Availability
– Replication
• The central concern in this view
– Run time parameters
• ( similar to process view of 4+1)
 Code view
• Concerned with the organization of the software
artifacts (source code) .
• The engineering concerns of this view is
supportability in terms of
– product versions and releases,
– minimize effort for product upgrades,
– minimize build time and
– support integration and testing.
• The central concern in this view
– Work assignment dor development, installation, support
• ( similar to Development and deployment view of 4+1)
Siemens 4 Views
 SEI views
• Simplified to 3 views ( structures)
– Module
• Similar to Scenario and module views of 4+1
– Component and connectors
• Similar to process view of 4+1 ( run time)
– Allocation
• Similar to development and deployment views of 4+1
 View comparison
Sl.No RUP 4 + 1 SEIMENS 4 SEI Focus

1 Scenario Conceptual -- User view of functionality

( part of
module view)
2 Logical Module Module Subsystems,
decomposition, layered
( Architect’s view of
functionality)
3 Process Execution Component Run time activities
and ( process, data sharing,
connector concurrency)
4 Development Code Allocation Work assignment,
cohesion, testability, reuse,

5 Deployment -- -- Site Installation, SW , HW

( part of code (part and Network components
view) allocation and supportability
view)
 Case study
• Library Management System
– RUP 4 + 1 view
– Siemens 4 view
– SEI view