Don't forget to hit the ⭐ if you like this repo.
- Architectural Design and Detailed Design
- Architectural Design Decision
- Architectural View
- Architectural Pattern
By understanding the analogy between software architecture and house architecture, software engineers can better understand the importance of good software architecture and the principles of good design. Just as a well-designed house is functional, efficient, and comfortable, a well-designed software system is functional, efficient, and easy to use and maintain.
Segmented into 6 major activities:
1. Design the Support Services Architecture and Deployment Environment:
This activity involves designing the architecture of the support services that the software system will need, such as networking, web servers, databases, and other infrastructure components. It also involves designing the deployment environment, which includes the hardware, software, and network configurations needed to deploy the software system.
2. Design the Software Architecture:
This activity involves designing the overall structure of the software system, including the components, modules, and subsystems that make up the system. It also involves defining the relationships between these components and the interfaces that they expose to each other and to external systems.
3. Design the Use Case Realizations:
Design the Use Case Realizations:
This activity involves designing the detailed behavior of the software system in response to the various use cases that it needs to support. This includes designing the user interfaces, the flow of control between different parts of the system, and the specific algorithms and data structures used to implement the system's functionality.
4. Design the Database:
This activity involves designing the database schema and data model that the software system will use to store and retrieve data. It includes defining the tables, fields, relationships, and constraints that will be used in the database, as well as designing the queries and other data access mechanisms used by the system.
5. Design the System and User Interfaces:
This activity involves designing the overall user interface of the software system, including the layout, navigation, and visual design of the system. It also involves designing the specific interactions that users will have with the system, such as data entry and retrieval, and defining the usability and accessibility requirements of the system.
6. Design the System Security and Controls:
This activity involves designing the security and access controls for the software system, including authentication, authorization, encryption, and other mechanisms used to protect the system and its data from unauthorized access or modification. It also involves designing the audit and logging mechanisms used to track system activity and detect potential security breaches.
By following a disciplined approach to these design activities, software engineers can ensure that the software system they are building meets the needs of its users, is scalable and maintainable, and provides a secure and reliable platform for its intended use.
Design model contains exactly one design system that contains many design subsystems (also known as “package” that can also be introduced in the analysis)
Analysis and Design are Interrelated:
Analysis and design are closely related activities that are both essential to the software development process. Analysis involves understanding the problem domain, defining requirements, and identifying constraints and assumptions. Design involves creating a solution that meets the identified requirements and constraints.
Analysis Drives Design:
The analysis phase provides the foundation for the design phase. The analysis phase identifies the requirements and constraints that the system must meet, and the design phase creates a solution that meets those requirements and constraints.
Design is an Extension of Analysis:
Design is an extension of analysis, building on the information and knowledge gained during the analysis phase. The design phase takes the requirements and constraints identified during analysis and transforms them into a concrete solution that meets the needs of the stakeholders.
Models are Used in Both Analysis and Design:
Models are used in both analysis and design to represent the system being developed. In the analysis phase, models are used to represent the problem domain, requirements, and constraints. In the design phase, models are used to represent the solution being developed.
Iterative Process:
The software development process is often iterative, with feedback and refinement occurring between analysis and design. As the design progresses, it may become apparent that additional analysis is needed to refine the requirements and constraints of the system. Similarly, as the analysis progresses, new design solutions may be identified that better meet the needs of the stakeholders.
In summary, analysis and design are two closely related activities that are essential to the software development process. Analysis provides the foundation for design, with design building on the information and knowledge gained during analysis. Models are used in both analysis and design, and the software development process is often iterative, with feedback and refinement occurring between analysis and design.
Architectural design is a key activity in the software development process, which involves understanding how a software system should be organized and designing the overall structure of that system. The main goal of architectural design is to identify the main structural components of a system and the relationships between them. This is important because the structure of a software system can have a significant impact on its quality attributes, such as its maintainability, scalability, reliability, and performance.
Architectural design is the critical link between design and requirements engineering because it helps to bridge the gap between the high-level requirements of a system and the detailed design of its components. By defining the overall structure of a system, architectural design helps to ensure that the system meets the requirements and constraints specified by stakeholders, while also providing a framework for the detailed design of the system components.
The output of the architectural design process is an architectural model that describes how the system is organized as a set of communicating components. This model includes a description of the main architectural components of the system, their interfaces, and their interactions. It also includes information about the allocation of functionality to these components and how they will be implemented and deployed.
To design a software architecture, software engineers need to have a deep understanding of the problem domain, the stakeholders' needs, and the technical options available for implementing the system. They also need to consider the quality attributes that are important for the system and how the architecture can be designed to achieve them. This involves making trade-offs between different design options and evaluating the impact of design decisions on the overall system.
In summary, architectural design is a critical activity in the software development process that involves designing the overall structure of a software system. It helps to bridge the gap between requirements engineering and detailed design, and provides a framework for designing the system components. The output of the architectural design process is an architectural model that describes the organization of the system as a set of communicating components. To design an effective software architecture, software engineers need to have a deep understanding of the problem domain, stakeholders' needs, and technical options available for implementing the system.
Designing use case realizations involves creating a lower-level view of how a software system will support specific use cases. This process involves focusing on two main areas:
- Class interactions that support a particular use case, which involves designing how the different classes in the system will interact with each other to achieve the goals of the use case.
- Interactions among the software system, users, and external systems, which involves designing how the system will interact with its environment to support the use case.
Designing use case realizations typically requires multiple iterations, as software engineers refine and improve the design over time. They use UML design class diagrams and interaction diagrams, such as sequence diagrams, to document the design and ensure that it meets the requirements of the use case.
In summary, designing use case realizations involves creating a lower-level view of how a software system will support specific use cases. This involves designing how classes in the system will interact with each other, as well as how the system will interact with users and external systems. Software engineers typically use UML diagrams to document the design and refine it over time.
Architectural abstraction refers to the process of breaking down a software system into smaller components to better understand its structure and design. This process can be applied at different levels, such as the architecture of individual programs or the architecture of large enterprise systems.
Architecture in the small refers to the architecture of individual programs. This involves breaking down a program into smaller components or modules and understanding how they interact with each other to achieve the program's goals.
Architecture in the large refers to the architecture of complex enterprise systems that may include multiple programs, systems, and components. These enterprise systems are often distributed across different computers and may be owned and managed by different companies. Understanding the architecture of these systems involves analyzing how the different components interact with each other to achieve the system's overall goals.
In summary, architectural abstraction involves breaking down a software system into smaller components to better understand its structure and design. This process can be applied at different levels, such as the architecture of individual programs or the architecture of large enterprise systems. Understanding these architectures involves analyzing how the components interact with each other to achieve the system's goals.
Explicit architecture in software design has several advantages:
1. Stakeholder communication: An explicit architecture can serve as a focal point for communication among system stakeholders, helping to ensure that everyone involved in the project has a shared understanding of the system's structure and design.
2. System analysis: An explicit architecture makes it possible to analyze whether the system can meet its non-functional requirements, such as performance, scalability, and security. This analysis can help identify potential problems early in the design process, allowing them to be addressed before they become more costly to fix.
3. Large-scale reuse: An explicit architecture can be reusable across a range of systems. This means that designers can create product-line architectures that can be used across multiple products or systems, reducing design and development time and increasing efficiency.
4. Improved quality: Explicit architecture can help ensure that the system is designed to meet its functional and non-functional requirements. This can lead to higher quality software with fewer bugs, better performance, and greater user satisfaction.
5. Reduced costs: By providing a clear and explicit architecture, developers can avoid costly design mistakes and reduce the likelihood of system failures, leading to overall cost savings for the project.
When documenting software architectures, the most commonly used method is simple, informal block diagrams that show entities and relationships. However, these diagrams have been criticized for not providing enough information about the types of relationships between entities or the visible properties of entities in the architecture. To address this issue, designers can use architectural models that provide more detailed information about the system's components and how they interact with each other. The choice of representation depends on the requirements for model semantics, or the meaning and interpretation of the models used to describe the system's architecture.
Architectural models can be used in various ways, including:
• Facilitating communication: A high-level architectural view of a system is useful for communicating with stakeholders and project planning. It provides an abstract view of the system that stakeholders can easily understand and discuss without being overwhelmed by details.
• Documenting design: Architectural models are used to document an architecture that has been designed. The aim is to create a complete system model that shows the different components in a system, their interfaces, and their connections.
• Analysis and evaluation: Architectural models are used to analyze and evaluate the system's properties and behavior. This helps to ensure that the system meets its requirements and functions as intended.
• Performance prediction: Architectural models are used to predict the system's performance. This helps to ensure that the system performs adequately under expected workloads and identifies potential bottlenecks.
• Design exploration: Architectural models are used to explore alternative system designs. This helps to identify the most suitable design that meets the system's requirements and constraints.
• Code generation: Architectural models are used to generate code automatically. This reduces the time and effort required to develop and maintain software systems.
Architecture design decision refers to the process of making key choices during the design and development of a software or system architecture. These decisions have a significant impact on the overall structure and behavior of the system and can affect its quality attributes such as performance, scalability, maintainability, security, and usability.
Architectural design decisions involve evaluating trade-offs among various options based on factors such as requirements, constraints, technical feasibility, cost, and risks. These decisions are often documented in an architectural design document and communicated to stakeholders to ensure alignment and understanding.
Examples of architecture design decisions include choosing a programming language, selecting a database management system, deciding on the use of microservices or monolithic architecture, and determining the deployment model (on-premises or cloud-based).
Question : Is there a generic application architecture that can act as a template for the system that is being designed?
Yes, there are several generic application architecture templates that can be used as a starting point when designing a system. These templates are often referred to as architectural patterns, and they provide a set of proven solutions to common design problems. Some examples of widely used architectural patterns include:
-
Model-View-Controller (MVC) pattern: This pattern separates an application into three interconnected components: the model (data and business logic), the view (user interface), and the controller (handles user input and manages interactions between the model and the view).
-
Layered architecture pattern: This pattern separates an application into layers, where each layer is responsible for a specific set of tasks. Typically, there is a presentation layer (user interface), business logic layer, and data access layer.
= Service-oriented architecture (SOA) pattern: This pattern breaks an application down into smaller, modular services that communicate with each other through a network. Each service performs a specific task and can be developed, deployed, and scaled independently.
- Microservices architecture pattern: This pattern is similar to SOA but places a stronger emphasis on independently deployable and scalable services. Microservices are typically smaller in scope than SOA services and often communicate with each other through lightweight protocols like REST.
It's important to note that while these architectural patterns can be helpful in providing a starting point for system design, they are not one-size-fits-all solutions. The specific needs and requirements of the system being designed should always be taken into consideration, and the architecture should be tailored accordingly.
The distribution of a system across hardware cores or processors will depend on several factors, including the system requirements, the available hardware resources, and the design decisions made during the development process. In general, the distribution of a system across hardware cores or processors can be achieved through parallelization or through the use of distributed computing techniques.
Parallelization involves dividing a system's workload into smaller, independent tasks that can be executed concurrently across multiple cores or processors. This approach can improve system performance and scalability by reducing processing time and enabling the system to handle larger workloads. Parallelization can be achieved through techniques such as multithreading, multiprocessing, and vectorization.
Distributed computing techniques involve dividing a system's workload across multiple machines connected through a network. This approach can improve system reliability, fault tolerance, and scalability by enabling the system to handle larger workloads and providing redundancy in case of hardware failures. Distributed computing techniques can be achieved through approaches such as client-server architecture, peer-to-peer architecture, and message passing.
The choice between parallelization and distributed computing techniques will depend on the specific requirements of the system being developed. If the system requires high performance and is running on a single machine with multiple cores, parallelization may be the best approach. If the system requires high availability and redundancy, distributed computing techniques may be the better option. In many cases, a combination of both approaches may be used to achieve the desired system performance and reliability.
There are several architectural patterns or styles that can be used to design a software system, depending on the specific requirements and constraints of the system being developed. Here are some examples of commonly used patterns or styles:
-
Layered Architecture: This pattern separates the system into layers, where each layer is responsible for a specific set of tasks. Typically, there is a presentation layer (user interface), business logic layer, and data access layer.
-
Model-View-Controller (MVC): This pattern separates an application into three interconnected components: the model (data and business logic), the view (user interface), and the controller (handles user input and manages interactions between the model and the view).
-
Microservices Architecture: This pattern divides the system into smaller, independent services that can be developed, deployed, and scaled independently. Each service performs a specific task and communicates with other services through lightweight protocols like REST.
-
Event-Driven Architecture: This pattern is based on the idea that events trigger actions within the system. The system is designed to react to events and initiate actions in response to them.
-
Service-Oriented Architecture (SOA): This pattern breaks the system down into smaller, modular services that communicate with each other through a network. Each service performs a specific task and can be developed, deployed, and scaled independently.
-
Domain-Driven Design (DDD): This pattern focuses on the domain model of the system and aims to create a clear and well-defined understanding of the problem domain. The system is designed around the domain model, with each component representing a specific aspect of the domain.
These are just a few examples of architectural patterns or styles that can be used in software system design. The choice of pattern or style will depend on the specific requirements, constraints, and goals of the system being developed.
The strategy used to control the operation of components in a system will depend on the specific requirements and design decisions of the system. Here are some common strategies that can be used:
-
Centralized Control: This strategy involves a central component that controls the operation of all other components in the system. The central component can be responsible for coordinating communication between components, managing resources, and enforcing system-wide policies.
-
Distributed Control: This strategy involves distributing control across multiple components in the system. Each component may be responsible for managing its own resources, and communication between components may be peer-to-peer or through a messaging system.
-
Hierarchical Control: This strategy involves organizing components into a hierarchical structure, with higher-level components responsible for coordinating the operation of lower-level components. This approach can help to simplify system management and improve scalability.
-
Reactive Control: This strategy involves components reacting to events or changes in the system environment. The components may be designed to adapt to changing conditions and adjust their behavior accordingly.
-
Proactive Control: This strategy involves components proactively monitoring the system environment and taking action to prevent potential problems or errors. This approach can help to improve system reliability and reduce downtime.
The choice of strategy will depend on several factors, including the system requirements, the complexity of the system, and the desired level of control and flexibility. In many cases, a combination of strategies may be used to achieve the desired system behavior and performance.
The 4 + 1 View Model of Software Architecture comprises different perspectives that showcase the system's key features and functions.- The Logical view highlights the fundamental abstractions of the system as objects or object classes.
- The Process view illustrates how the system is composed of interconnected processes during runtime.
- The Development view presents how the software is divided and organized for development purposes.
- The Physical view depicts the hardware components of the system and how software components are distributed across processors.
Finally, the +1 element relates these different views using use cases or scenarios to provide a more comprehensive understanding of the system.
- Component diagram Models the dependencies between the software components that constitute the system
- Deployment diagram Models the physical computational nodes on which the software will be deployed, and the relationships between those nodes
<img src="
"
There is a one-to-one «trace» relationship between design subsystems and implementation subsystems.Design subsystems contain design classes but implementation subsystems contain components that package those classes.
- Used to model the top-level view of the system design in terms of components and dependencies among the components.
- Components can be linkable libraries, executables.
- Components can be identified based on influence from the system environment e.g. existing framework used for the software, connection to legacy system or external system, hardware driver used and also if the software used any web serviceavailable
- A provided interface is modeled using the lollipop notation
- A required interface is modeled using the socket notation
- Existing Framework The impact of the system's environment on its development and operation is significant, particularly when considering existing frameworks. These frameworks, which are pre-established systems or structures, can greatly influence the design and implementation of a new system. Therefore, understanding the existing frameworks in the system environment is crucial in developing a successful and effective system.
- Legacy System The system environment, specifically legacy systems, can have a significant impact on the development and operation of a new system. Legacy systems are older, established systems that may still be in use, and as such, they can impose constraints or requirements on the development of a new system. Therefore, it is important to consider legacy systems when designing and implementing a new system to ensure compatibility and integration with the existing system environment.
- External System The system environment can be influenced by external systems, which are systems that are outside of the scope of the system being developed. External systems can impact the design and functionality of the new system, as it may need to interact with these external systems to achieve its goals. Therefore, it is important to consider the presence and requirements of external systems when developing a new system to ensure effective communication and integration with these systems.
- Hardware Driver The system environment can be influenced by hardware drivers, which are software components that allow the operating system to communicate with hardware devices. Hardware drivers can impact the development and operation of a new system, as they may require specific software or hardware configurations. Therefore, it is important to consider hardware drivers when designing and implementing a new system to ensure compatibility and proper communication with the hardware devices in the system environment.
- Web Service The system environment can be influenced by web services, which are software systems that enable communication and exchange of data between different devices or applications over the internet. Web services can impact the development and operation of a new system, as it may need to interact with these services to perform certain tasks. Therefore, it is important to consider the presence and requirements of web services when developing a new system to ensure effective communication and integration with these services.
- Model: Data and business logic of the application. Responsible for managing data, processing business logic, and interacting with data sources such as databases, APIs, or external services. The Model is independent of the user interface and communicates with the View and Controller through well-defined interfaces.
- View: Responsible for rendering the user interface and presenting data to the user. Displays the data from the Model to the user and provides a way for the user to interact with the application. View receives input from the user and communicates it to the Controller for further processing.
- Controller: Controller acts as an intermediary between the Model and View. It receives input from the View, processes it, updates the Model, and communicates back to the View to update the user interface. Controller also handles user interactions, such as handling user input, validating data, and making decisions about how to update the Model and View.
- Presentation Layer: User Interface (UI) layer, responsible for rendering the user interface and handling user interactions
- Application Layer: Business Logic layer. Contains the core business logic and processing rules of the application. It encapsulates application-specific logic and orchestrates interactions between the Presentation Layer and the Data Layer. Contains business rules, domain-specific logic, and data validation.
- Domain Layer: Model layer, represents the core domain objects and business entities of the application. This Domain Layer is typically designed to be independent of the other layers and contains the domain models or entities, as well as interfaces for interacting with these models.
- Data Layer: Persistence Layer, layer is responsible for handling data storage and retrieval. Includes components such as databases, data access objects (DAOs), and ORMs (Object-Relational Mappers). The Data Layer is responsible for abstracting the underlying data storage and providing interfaces for the upper layers to interact with the data.
- Repository: Repository is responsible for providing a high-level abstraction over the data source, encapsulating the details of data storage and retrieval. Consists of a well-defined interface that allows the application to perform operations such as create, read, update, and delete (CRUD) on the data.
- Data Sources: Data Source represents the persistent storage where the data is stored, such as a database, API, or external service. Communicates with the Data Source to perform data operations.
- Domain Objects: Domain Objects represent the business entities or data models of the application. These are the objects that are manipulated by the Repository and used by the application to represent and manipulate data.
- Client: The client represents the user interface or front-end of the application, typically responsible for rendering the user interface, capturing user input, and sending requests to the server for processing. Clients can be various types of devices, such as desktop computers, mobile devices, or web browsers.
- Server: The server represents the back-end of the application. Responsible for processing requests from clients, managing data storage and retrieval, and performing business logic. Servers can be physical machines or virtual servers that run software applications and handle requests from clients.
- Communication Protocol: Defines the rules and conventions for communication between clients and servers. It includes protocols such as HTTP, TCP/IP, REST (Representational State Transfer), SOAP (Simple Object Access Protocol), and others. The communication protocol allows clients and servers to exchange data and requests in a standardized and interoperable manner.
- Source: The source is the component that provides the input data to the pipeline. It could be a data source such as a file, a database, or an external service, or it could be generated by the application itself.
- Filter: A filter is a component that performs a specific operation on the input data. Filters can perform tasks such as filtering out unwanted data, transforming data into a different format, validating data, or aggregating data. Filters are connected in a sequential manner, forming a processing pipeline, where the output of one filter is passed as input to the next filter.
- Sink: The sink is the component that receives the processed data from the last filter in the pipeline. It could be a data sink such as a file, a database, or an external service, or it could be consumed by the application itself.
- Connector: Connectors are the communication channels or interfaces that connect filters in the pipeline. They are responsible for passing data between filters and coordinating the flow of data through the pipeline. Connectors can be implemented in various ways, such as in-memory pipes, sockets, message queues, or other communication mechanisms.
Separates an application into three main components: Model, View, and Controller
Involves organizing the application into distinct layers or tiers based on their responsibilities and functionality. Each layer performs a specific set of tasks, and communication between layers follows a predefined set of rules, typically with higher layers depending on lower layers.
Also known as the Repository Design pattern. Provides an abstraction layer between the data access logic and the rest of the application. Commonly used in applications that need to interact with persistent data sources, such as databases, APIs, or external services, and aims to separate the data access logic from the business logic, promoting maintainability, testability, and modularity.
Divides an application into two main components: the client and the server. The client represents the user interface or front-end, while the server represents the back-end that processes requests, manages data, and performs business logic.
The Pipe and Filter Architecture pattern is a software architectural pattern that involves processing data through a series of interconnected components, called filters, in a sequential manner. Each filter performs a specific operation on the data and passes it to the next filter in the pipeline until the data has been processed through all the filters.
Please create an Issue for any improvements, suggestions or errors in the content.
You can also contact me using Linkedin for any other queries or feedback.