Software Architecture: Principles and Design

Software Architecture

• Software architecture is the organization of a software system into subsystems and components.
• These components and their relationships to each other and the environment should be guided by design and evolution principles.
• Software architecture can be represented using block diagrams showing entities and relationships.
• Architectural design is an early stage to design, it can be carried out in parallel with some specification activities and represents the link between specification and design processes.
• An early stage of agile processes is changing the architecture, which is expensive because it affects many components in the system.
• Architecture has a fundamental influence on non-functional system properties, such as response time, reliability, availability, security, usability, maintainability, and resilience

Advantages of Explicit Architecture

• Stakeholders can use the architecture for communication because they can understand an abstract view of the system without being confused by details.
• System analysis checks whether the system can meet its non-functional requirements.
• Large-scale reuse means the architecture may be reusable across a range of systems.
• Systems in the same domain often have similar architectures that reflect domain concepts.
• An architecture can be designed around architectural patterns or styles.
• Documenting an architecture shows the different components in a system, their interfaces, and their connections.

Software Design Abstraction

• At the architectural level, your concern should be on large-scale architectural components or subsystems.
• You don't have to decide how an architectural element or component is to be implemented.
• A designer needs to design the component interface and leave the implementation to a later stage.
• Decomposition involves analyzing large-scale components and representing them as a set of finer-grain components.

Software Components

• A component is an element that implements a coherent set of functionality or features
• Components can be a collection of one or more services that may be used by other components.

Architectural Design Issues

• Nonfunctional product characteristics can determine whether your product will be a success.
• Product lifetime means that if you anticipate a long product lifetime, you will need to create regular product revisions.
• Software reuse means you can save time and effort if you can reuse large components from other products.
• Number of users can change very quickly, so you need to design your architecture so that your system can be scaled up and down.
• Software compatibility is important to maintain compatibility with other software so that users can adopt your product.

Architecture and System Characteristics

• Maintainability means using fine-grain, self-contained, replaceable components.
• Performance means to localise critical operations and minimise communications.
• Security means use a layered architecture with critical assets in the inner layers.
• Safety means to localise safety-critical features in a small number of sub-systems.
• Availability includes redundant components and mechanisms for fault tolerance.

Security vs Usability

• Security is designing the system protection as a series of layers, which an attacker has to penetrate to reach assets.
• Layers might include authentication layers and encryption layers.
• A layered approach to security affects the usability of the software, like the need to remember passwords.

Architectural Design Decisions

• Determine if there is a generic architecture that can be used and appropriate architectural patterns or styles.
• Consider what architectural design is best for delivering the non-functional requirements
• Decide how the system will be distributed across hardware
• Choose what approach to use to structure the system and what control strategy should be used?
• Determine how the architecture should be documented

Control Styles

• Control styles are concerned with the control flow between subsystems.
• Centralised control involves one subsystem with overall responsibility for control, it starts and stops other subsystems.
• Event-based control means that each subsystem can respond to externally generated events from other subsystems or the system's environment.

Architectural patterns

• An architectural pattern is a description of good design practice, which has been tried and tested in different environments.
• Patterns represent a means of representing, sharing, and reusing knowledge.
• Patterns may be represented using graphical and tabular descriptions.

Layered Architecture

• A layered architecture organises the system into a set of layers, each providing a set of services to the layer above.
• Each layer is an area of concern and considered separately from other layers.
• The components are independent within each layer and do not overlap in functionality.
• Layered architecture supports the incremental development of sub-systems in different layers.
• When a layer interface changes, only the adjacent layer is affected.
• Entire layers can be replaced, assuming that the interface is maintained.
• Redundant facilities (e.g., authentication) can be provided in each layer to increase dependability.

The Layered Architecture Pattern

• This pattern organises the system into layers with related functionality associated with each layer.
• Lower-level layers represent core services that are likely to be used throughout the system.
• Replacing entire layers is allowed as long as the interface is maintained.
• Redundant facilities can be provided in each layer to increase the dependability of the system.
• A high-level layer may have to interact directly with lower-level layers rather than through the layer immediately below it.
• Performance can be a problem because of multiple levels of interpretation of a service request as processed at each layer.

Cross-Cutting Concerns

• Cross-cutting concerns are concerns that affect the whole system.
• Cross-cutting concerns affect all layers in the system.
• Security is a cross-cutting concern, so protection from attacks is required at each layer.
• Distributing security across the layers makes your system is more resilient to attacks and software failure.
• The existence of cross-cutting concerns is the reason why modifying a system after it has been designed to improve its security is often difficult.

Generic Layered Architecture for Web-Based Application

• This contains a browser-based or mobile user interface, where HTML forms are used to collect user input.
• Authentication and UI management contains a user interface management layer that may include components for user authentication and web page generation.
• Application-specific functionality contains an 'application' layer that provides functionality of the application.
• Basic shared services is a shared services layer, which includes components that provide services used by the application layer components.
• Database and transaction management is a database layer that provides services to manage transactions.

iLearn architectural design principles

• Replaceability means users can replace applications in the system with alternatives.
• Extensibility means users or system administrators can create their own versions of the system.
• Age-appropriate means alternate user interfaces should be supported so that age-appropriate interfaces for students at different levels can be created.
• Programmability means users can easily create their own applications by linking existing applications in the system.
• Minimum work means users who do not wish to change the system should not have to do extra work.

Model-View-Controller (MVC) Architecture

• Contains 3 logical components:
  • The Controller component manages user interaction.
  • The Model component includes business logic and data.
  • The View component defines and manages how the data is presented to user.

The Model-View-Controller (MVC) Pattern

• Separates presentation and interaction from the system data.
• The system is structured into three logical components that interact with each other.
• The Model component manages the system data and associated operations on that data.
• The View component defines and manages how the data is presented to the user.
• The Controller component manages user interaction and passes these interactions to the View and the Model.
• This pattern is used when data in a shared database has to be accessed from a range of locations.
• It supports presentation of the same data in different ways with changes made in one representation shown in all of them.

Repository Architecture

• Subsystems exchange data.
• Shared data is held in a central database or repository and may be accessed by all sub-systems.
• Each sub-system maintains its own database and passes data explicitly to other sub-systems.
• The repository model is commonly used for sharing large amounts of data, making it efficient.

The Repository Pattern

• Management of system data is in a central repository that is accessible to all system components.
• You should use this pattern when there are large volumes of information generated requiring archiving.
• Components can be independent and do not need to know of the existence of other components.

Client-Server Architecture

• A type of distributed architecture in which clients access shared services.
• In client-server architecture. the user interface can be implemented on the client computer.
• Functionality is distributed between the client and one or more server computers.

The Client-Server Pattern

• Server can be distributed across a network, enabling general functionality available to all clients.

Client-Server Communication

• Client-server communication normally uses the HTTP protocol.
• The client sends a message to the server that includes an instruction with the identifier of a resource.
• HTTP is a text-only protocol, the two ways this is represented are with XML and JSON.

Multi-Tier Client-Server Architecture

• The web server is responsible for all user communications
• The application server is responsible for implementing application-specific logic and information storage requests
• The database server moves information to and from the database and handles transaction management.

Transaction Processing Systems

• Process user requests for information from or to update a database.
• A transaction is any coherent sequence of operations that satisfies a goal.
• Users make asynchronous requests for service, which are then processed by a transaction manager.

Pipe and Filter Architecture

• Functional transformations process their inputs to produce outputs.
• Transformations can be called a pipe and filter model.
• When transformations are sequential, this is a batch sequential model, which is extensively used in data processing systems.

The Pipe And Filter Pattern

• Used in data processing applications where inputs are processed in separate stages to generate related outputs.
• This supports transformation reuse, it can be implemented as either a sequential or concurrent system.
• The format for data transfer must to be agreed upon between communicating transformations.

Service-Oriented Architecture

• Services are stateless components, which means that they can be replicated and can migrate from one computer to another.
• A service gateway is a single access point and acts as a proxy for multiple services.
• It enables transformations, routing, and common processing across all the services.
• Clients do not need to know what communication protocol is being used.
• SOA is easier to scale if demand increases and is resilient to failure.

Issues In Architectural Choice

• The type of data and updates should be from a shared database that provides locking and transaction management.
• If system components will be regularly changed or replaced, isolating these components as separate services simplifies those changes.
• To run a system on the cloud, it is best to implement it as a service-oriented architecture because scaling the system is simpler.

Technology Choices

• Relational databases, such as MySQL, are suitable for transaction management.
• NoSQL databases, such as MongoDB, are more flexible for data analysis.
• To ensure performance, you may need a completely different decomposition architecture in different versions.
• You can use dedicated in-house servers or design your system to run on a public cloud like Amazon, Google, or Microsoft.