Software Architecture Views and Structures

Description of Views:

In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views:

1. Logical
2. Development
3. Process
4. Physical
5. Scenario

Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures:

Views	Sub-View of	Description
Logical	None	Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture.
Development	None	It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective.
Process	None	It deals with the representation of the system’s dynamic aspects explaining the system process and the communication taking place between the various components of the system. The process view addresses the quality attributes of the system. UML diagrams are used in this type of view.
Physical	None	It presents the software w.r.t. the software engineer’s point of view. It is concerned with the topology of the software components on the physical and the physical connections between the components of the software. It is also known the deployment view of the system.
Scenario	None	It describes the activities conducted by the system via sets of use cases or scenarios.
Module	None	It documents the principle units of the system to be implemented.
Decomposition	Module	Focuses on ‘is-part-of’ relationship between the elements in the software and their properties. It represents the responsibilities spread across the modules and sub-modules of the system.
Uses	Module	Represents the ‘uses’ relationship between the components along with any dependencies that might exist between the components.
Layered	Uses	Represents a level of abstraction among the components of the system. It also represents the way these layers communicate with each other.
Generalization	Module	It is also known as the class view. It represents the inheritance relationship among the components of the system.
Component-and-Connector (C&C)	None	Represents the units of the system that execute.
Shared Data	Component-and-Connector (C&C)	Represents the process of data production and consumption.
Service-Oriented Architecture (SOA)	Component-and-Connector (C&C)	It represents the following: ·         Distribution of application across the system. ·         Interoperability of components developed in different languages and platforms. ·         Integration of external components and legacy systems.
Pipe-and-Filter	Component-and-Connector (C&C)	It represents the following: ·         Systems serially transforming data. ·         How the structure supports functional composition data analysis.
Allocation	None	Documents the relationship between the software, its development and execution environment.
Deployment	Allocation	Represents the mapping of the software onto the hardware elements.
Implementation	Allocation	Represents the mapping of the software onto the file structures.

Description of Structures:

Structures	Sub-Structure	Description
Logical	None	It primary objective is to support the functional requirements of the software provided in terms of services to is users. Architecture adopting the principles of object oriented programming i.e. encapsulation, inheritance and abstraction divides the system into key abstractions, derived mainly from the problem domain of the software in the form of objects or classes. The objective is to not only decompose the system for functional analysis to identify common mechanisms and design elements in the system.
Process	None	It focuses on the quality attributes of the system such as the performance, availability, concurrency and distribution of system’s integrity, fault-tolerance and abstraction from the logical view. It the abstraction levels created in this structure each address to a different set of concerns. At the highest level of abstraction, it can be viewed as a collection of independently executing logical networks of a process.
Development	None	Main focus is on the software module organization, libraries, subsystems and the units of development.
Physical	None	It takes into account all the quality attributes i.e. reliability, availability, performance, and scalability. The various elements are to be mapped onto various nodes and for this, a physical configuration is used.
Module	None	Elements in an architectural structure are in the form of modules to be implemented. Each of the modules possess its own set of functional responsibilities representing the system. Following are a set of questions answered by this structure: ·         What functional responsibility does the module primarily possess? ·         What other software elements a module has the permission to use? ·         What other Fully software are being actually used by the module?
Decomposition	Module	Highlights the process of extracting smaller modules from larger ones recursively.
Uses	Module	Units dealt with this structure are: ·         Modules ·         Resources or procedures on the module’s interfaces ·         Derived from uses relation
Layered	Uses	The uses relation are further structured into layers
Class	Module	This type of structure is also known as generalization.
Component-and-Connector	None	Elements in this type of structure are all runtime components and connectors i.e. units of computation and medium of communication among these components. The relation among the components defines how the components and the connectors are linked to each other. This structure helps identify the following: ·         Major executing components and the interaction among them. ·         Data shared among the components. ·         Parts of the system replicated. ·         Parts of the system capable to execute in parallel. ·         Possible changes in system’s structure during execution.
Process	Component-and-Connector	This structure is also known as the communicating processes structure. Threads or processes connected with each other via communication, synchronization or exclusion operations are the units involved in this type of structure.
Concurrency	Component-and-Connector	Components and connectors in the form of logical threads (a sequence of computations executable on separate physical threads) are the units for this type of structure.
Shared Data	Component-and-Connector	This type of structure is also known as a repository. Components and connectors responsible for creating, storing, accessing persisting data are the main part of this structure.
Client-Server	Component-and-Connector	Components consist of the client and the server whereas the connectors are a set of protocols and messages used for communication between the defined components.
Allocation	None	This type of structure is applicable only if the various elements of the software and the relation between them have the capacity to sustain in one or more external environments. Following aspects related to the software are identified via this structure: ·         The processes required for the software to execute on. ·         Files required storing each of the software elements during development, testing and system building. ·         The software elements assigned to the development teams.
Deployment	Allocation	Represents the process of how hardware-processing and communication elements are assigned with software. If the allocation is dynamic then the relation would be “allocated-to” and “migrate-to”.
Implementation	Allocation	Shows the mapping of the software elements on to the file structures. These software elements can usually be modules.
Work Assignment	Allocation	It is responsible for assigning the development teams with the process of implementing and integration of modules.

                  

Representations of architectural VIEWS by the STRUCTURES

Views	Module Structure	Decomposition Structure	Uses Structure	Class Structure	Layered Structure
4+1 View	Fully	Fully	Fully	Fully	Fully
Module	Fully	Fully	Nil	Partially	Nil
Decomposition	Partially	Fully	Nil	Partially	Partially
Uses	Partially	Partially	Fully	Fully	Nil
Layered	Partially	Nil	Partially	Nil	Fully
Generalization	Partially	Fully	Nil	Fully	Nil
Shared Data	Partially	Partially	Partially	Partially	Partially
Service-Oriented Architecture	Nil	Nil	Nil	Nil	Partially
Pipe-and-filter	Partially	Nil	Partially	Nil	Partially
Deployment	Nil	Partially	Nil	Partially	Partially
Implementation	Partially	Partially	Nil	Partially	Partially

Views	Component-and-Connector Structure	Shared Data Structure	Allocation Structure	Work Assignment Structure	Deployment Structure	Process Structure
4+1 View	Fully	Fully	Fully	Fully	Fully	Fully
Module	Partially	Nil	Partially	Nil	Nil	Partially
Decomposition	Partially	Nil	Nil	Nil	Nil	Nil
Uses	Nil	Nil	Nil	Nil	Nil	Nil
Layered	Nil	Nil	Nil	Nil	Nil	Nil
Generalization	Nil	Nil	Nil	Nil	Nil	Nil
Shared Data	Partially	Nil	Fully	Partially	Fully	Partially
Service-Oriented Architecture	Partially	Nil	Nil	Nil	Nil	Nil
Pipe-and-filter	Fully	Nil	Partially	Nil	Fully	Partially
Deployment	Nil	Partially	Partially	Nil	Fully	Nil
Implementation	Nil	Partially	Partially	Nil	Partially	Nil

Explanation:

	Module View	Component-and-Connector View	Allocation View
Module Structure	Structure is completely represented by module view as it lists all the components derived from the system and the relations between the components.	It partially represents the module structure as it discusses only the components communicating on the network whereas the module structure represents all the components of the system.	The module is partially represented by this view as it does not cover the relations among the components of the system derived via module structure.
Component-and-Connector Structure	It partially represents the structure as the structure is concerned with the components on the network and their communication process whereas this type of view discusses all the components and the relations among these components.	View is derived from the structure itself due to which it completely supports this type of structure.	It strongly represents the structure as it also represents the components that are to be on the network in distributed system.
Allocation Structure	This view represents all the components in the structure whereas the structure is only concerned with the components that are to be allocated.	It fully supports the structure as the components in the allocation structure require communicational means that can only be represented via this type of view.	View is derived from the structure itself due to which it completely supports this type of structure.

References:

• http://www.slideshare.net/pagsousa/documenting-software-architectures
•  http://www.ece.ubc.ca/~matei/EECE417/BASS/ch02lev1sec5.html
•   https://sites.google.com/site/softwarearchitectureinpractice/9-documenting-software-architecture/c-component-and-connector-c-c-views/b-service-oriented-architecture-soa-view
• http://slideplayer.com/slide/2834830/
•  https://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf