1. Unit 3 – Architectural ViewsBy
Prof. Dr. Chandramouli

2. Unit 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

3. Introduction to Views Which of the above view is Architecture ?
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 ? ………..

4. Architectural Views Logical view Development view Scenarios
End user
Logical view
Development view
Programmers
& software managers
Scenarios
Process View
Physical View
The architecture in fact partially evolved from these scenarios as well as
The model is rather generic, and other notations and tools can be used, other design methods can be used especially for the logical and process decompositions
For each view, the architects can pick a certain architectural style
Similar views in UML
Use case view> - Encompass the use cases that describe the behavior of the system as seen by its end users, analysts, and testers
Design view - Encompass the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution
Process view - Encompass the threads and processes that form the system's concurrency and synchronization mechanisms
Implementation view - Encompass the components and files that are used to assemble and release the physical system
Deployment view - Encompass the nodes that form the system's hardware topology on which the system executes
System Engineer
Integrator

6. 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.

7. 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

8. Architecture 1 M
Views 1
Viewpoints M

10. 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

11. Categorization of Structures
Module Structures
Component and Connector Structures
Allocation Structures

13. 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

14. 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)

15. 1.1 Decomposition Structure
Elements: modules in a hierarchy ( AR, AP -> GL)
Relations: is a sub-module of ( AR func sub-module of GL) , shares secret with ( credit period i.e business rules - shared by AR with GL)
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

16. Uses Structure
Elements: modules, procedures, or resources on the interfaces of modules
Relations: uses: one unit ,IP, uses another,Fin, if the correctness of the first, Fin, requires the presence of a correct version (not a stub of) of the second.
(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

17. 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

18. 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

20. 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

21. 2.1 Process Structure Elements: processes or threads
Relations: attachment (that allow communication, synchronization, and/or exclusion operations)
View:
performance
availability.
Functionality and control

22. 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.

23. 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)

25. 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

26. 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)

27. 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

28. 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

29. 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)

30. 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

31. Graphical Design NotationF
Sequence
If-then-else T F F T T F T F
Selection
Repetition

32. Tabular Design Notation
Rules
Conditions 1 2 3 4
Condition A T F
Condition B
Condition C
Actions
Action X 
Action Y
Action Z 

33. 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

34. 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

35. 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

36. 4+1 View Model of Architecture
End user
Logical view
Development view
Programmers
& software managers
Scenarios
Process View
Physical View
The architecture in fact partially evolved from these scenarios as well as
The model is rather generic, and other notations and tools can be used, other design methods can be used especially for the logical and process decompositions
For each view, the architects can pick a certain architectural style
Similar views in UML
Use case view> - Encompass the use cases that describe the behavior of the system as seen by its end users, analysts, and testers
Design view - Encompass the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution
Process view - Encompass the threads and processes that form the system's concurrency and synchronization mechanisms
Implementation view - Encompass the components and files that are used to assemble and release the physical system
Deployment view - Encompass the nodes that form the system's hardware topology on which the system executes
System Engineer
Integrator

37. 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

38. 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

39. 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.

40. 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

41. Scenarios Help illustrate and validate the document
(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

42. Scenario example

43. Correspondence between views
Views are interconnected.
Start with Logical view (Req. Doc) and Move to Development or Process view and then finally go to Physical view.

44. 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

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

46. 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

47. Siemens 4 Views

48. 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.

49. 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.

50. Workflow between Global Analysis and Architecture View Design.

51. 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.

52. 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.

53. 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)

54. 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)

55. 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)

56. 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)

57. Siemens 4 Views

58. 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

59. View comparison Sl.No RUP 4 + 1 SEIMENS 4 SEI Focus 1 Scenario
Conceptual --
( part of module view)
User view of functionality 2
Logical
Module
Subsystems, decomposition, layered ( Architect’s view of functionality) 3
Process
Execution
Component and connector
Run time activities ( process, data sharing, concurrency) 4
Development
Code
Allocation
Work assignment, cohesion, testability, reuse, 5
Deployment
( part of code view)
(part allocation view)
Site Installation, SW , HW and Network components and supportability

60. Case study Library Management System RUP 4 + 1 view Siemens 4 view
SEI view

61. 2m Question Bank Define View. Define viewpoint.
What is the difference between view and viewpoint?
List the various views in software architecture
Why multiple views are required in defining SW Architecture ?
How SW architecture is connected to view and viewpoint ?
Explain logical view with an example. Who uses this view ?
Explain Process ( Deployment) view with an example. Who uses this view ?
Explain Development ( Implementation) view with an example. Who uses this view ?
Explain physical view with an example. Who uses this view ?
Explain usecase view ( scenario). Why is this view important ?
Define Structure
How is structure different from views ?
List the categories of structure
Define module structure
Define component and connector structure
What do you understand by Allocation structure ?
List the views as per 4+1 RUP
List the views as per Seimens
List the views as per SEI

62. 16m Question Bank
Define and explain the importance of various views in a SWA
Define structure. List and explain various structures considered in SWA
Explain with a neat diagram Kruchten’s 4+1 RUP view
Explain with a neat diagram Siemens 4 view
Explain with a neat diagram SEI view
Case study on following views
RUP 4+1
Siemens 4
SEI