Architectural design is concerned with understanding how software systems should be organized and designed, focusing on the overall structure of the system.
It is generally used to represent the entire architecture that is useful and meaningful to one or more stakeholders in the system.
They help stakeholders understand and communicate the architecture so that they can verify that the system addresses their concerns.
Architectural views or viewpoints are a set of representations of an architecture that cover stakeholders' issues. They also represent the functional and non-functional requirements of the application. These views collectively provide a comprehensive understanding of the system.
Three advantages of explicitly designing and documenting software architecture:
Stakeholder communication: The architecture is a high-level presentation of the system that may be used as a focus for discussion by a range of different stakeholders.
System analysis: Making the system architecture explicit at an early stage in system development requires some analysis. Architectural design decisions have a profound effect on whether or not the system can meet critical requirements such as performance, reliability, and maintainability.
Large-scale reuse: A model of a system architecture is a compact, manageable description of how a system is organized and how the components interoperate. The system architecture is often the same for systems with similar requirements and so can support large-scale software reuse.
Architecture Design:-
Architecture design is a creative process where you design a system organization that will satisfy the functional and non-functional requirements of a system. Because it is a creative process, the activities within the process depend on the type of system being developed, the background and experience of the system architect, and the specific requirements for the system.
During architecture design, decision questions need to be considered addressing:
Is there a generic application architecture that can act as a template for the system being designed?
How will the system be distributed across a number of cores or processors?
What architectural patterns or styles might be used?
What will be the fundamental approach used to structure the system?
How will the structural components in the system be decomposed into subcomponents?
What strategy will be used to control the operation of the components in the system?
What architectural organization is best for delivering the non-functional requirements of the system?
How will the architectural design be evaluated?
How should the architecture of the system be documented?
Because of the close relationship between non-functional requirements and software architecture, the particular architectural style and structure that you choose for a system should depend on the non-functional system requirements:
Performance: If performance is a critical requirement, the architecture should be designed to localize critical operations within a small number of components, with these components all deployed on the same computer rather than distributed across the network. This may mean using a few relatively large components rather than small, fine-grain components, which reduces the number of component communications. You may also consider run-time system organizations that allow the system to be replicated and executed on different processors.
Security: If security is a critical requirement, a layered structure for the architecture should be used, with the most critical assets protected in the innermost layers, with a high level of security validation applied to these layers.
Safety: If safety is a critical requirement, the architecture should be designed so that safety-related operations are all located in either a single component or in a small number of components. This reduces the costs and problems of safety validation and makes it possible to provide related protection systems that can safely shut down the system in the event of failure.
Availability: If availability is a critical requirement, the architecture should be designed to include redundant components so that it is possible to replace and update components without stopping the system. I describe two fault-tolerant system architectures for high-availability systems.
Maintainability: If maintainability is a critical requirement, the system architecture should be designed using fine-grain, self-contained components that may readily be changed. Producers of data should be separated from consumers, and shared data structures should be avoided.
Architectural View
An architectural view is generally used to represent the entire architecture that is useful and meaningful to one or more stakeholders in the system. It is a representation of the software system architecture that is relevant to one or more stakeholders.
Architectural views help stakeholders understand and communicate the architecture so that they can verify that the system will address their concerns.
Architectural views or viewpoints are a set of presentations of an architecture that cover stakeholder issues. They also represent functional and non-functional requirements of software applications.
4 + 1 Architectural View Model
The plus one refers to the scenario or use case view that completes the four standard views. The 4 + 1 model is a framework for organizing architectural views introduced, which contains five concurrent views to address various perspectives of the system.
These five architectural view models are:
Logical view
Development view
Process view
Physical view
Scenario or use case view
Now let us understand the 4+1 architectural view model in detail:
Logical View: It is concerned with functional requirements, presenting the high-level components or modules of the system and their interaction. It helps developers understand the system's logical structure and its functional decomposition. UML diagrams used in this view to represent logical view include class diagrams, sequence diagrams, and communication diagrams.
Development View: This view focuses on the organization and structure of the software system during the development process. It provides insights into how the software is structured for development, including the organization of the code, modules, libraries, and development tools. The development view helps developers understand the architecture and design decisions that impact the development and maintenance of the software.
Process View: This view primarily focuses on the dynamic aspect of the software system, illustrating how different components or modules interact at runtime. Representation of the system's processes, their interaction, and the flow of data between them are represented by the process view. This is helpful for understanding the performance, scalability, and resource utilization aspects of the system.
Physical View: This view focuses on mapping software components and modules to the hardware components of the system. It provides a representation of the physical distribution of software across different nodes or processors, considering factors such as performance, scalability, and physical constraints.
Use Case/Scenario View: This view complements the other four views and provides a representation of the system from the perspective of its end users and external actors. Use cases help to capture the functional requirements of the system by describing various scenarios or use cases in which the system interacts with its users or other systems.
Advantages of the 4+1 model:
Comprehensive representation: It provides a well-rounded and comprehensive view of the software architecture, addressing the concerns of different stakeholders.
Modularity: Each view can be developed and modified independently, promoting modularity and maintenance.
Flexibility: It allows for flexibility in addressing different concerns without cluttering a single view.
Communication: Enhances communication among stakeholders with different backgrounds and interests.
By using the 4+1 model, architecture can effectively communicate and manage the complexity of the software system throughout the development process.