Unit 3 – Architectural Views By Prof. Dr. Chandramouli

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

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

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

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

Architecture 1 M Views 1 Viewpoints M

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 Module Structures Component and Connector Structures 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 ( 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

1.2 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

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 F Sequence If-then-else T F F T T F T F Selection Repetition

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

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

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

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

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

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

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

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.

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

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

Scenario example

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.

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

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

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

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

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

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