Architectural Design in Software Systems

Architectural Design

• Architectural design is concerned with understanding how a software system should be organized and designing the overall structure.
• It's the critical link between design and requirements engineering, identifying main structural components and relationships between them.
• The output of the architectural design process is an architectural model; this describes how the system is organized as communicating components.

Agility and Architecture

• An early stage of agile processes is designing an overall system architecture.
• Refactoring the system architecture is typically expensive due to affecting many system components.

Architectural Abstraction

• Architecture in the small concerns individual programs, focusing on how a program is decomposed into components.
• Architecture in the large involves complex enterprise systems, including other systems, programs, and components, often distributed across multiple computers and companies.

Advantages of Explicit Architecture

• Stakeholder communication: Architecture serves as a discussion point for stakeholders.
• System analysis: Helps assess if a system meets non-functional requirements.
• Large-scale reuse: Architects can be reusable across various systems, allowing for product-line architectures.

Architectural Representations

• Informal block diagrams are frequently used to document software architectures, showing entities and relationships.
• However, these diagrams lack semantics and don't show the types of relationships or entity properties.
• Architectural model requirements depend on its specific usage.

Box and Line Diagrams

• Very abstract, omitting component relationships and external properties.
• Useful for communication with stakeholders and project planning.

Use of Architectural Models

• Facilitate discussions about system design by providing a high-level overview, enabling stakeholders to relate to and understand the system without excessive detail.
• Document the architecture, creating a complete system model displaying components, interfaces, and connections.

Architectural Design Decisions

• The architectural design processes vary based on the specific system type.
• Many decisions have impacts on non-functional system characteristics.
• Examples include decisions on generic applications, data distribution, or architectural patterns and styles.

Architecture Reuse

• Systems in similar domains often have similar architectures based on shared concepts.
• Application product lines are built around core architectures enabling specific customer requirements.
• System architectures can be designed around pre-existing patterns or styles, which capture the essence of an architecture and can be adapted.

Architecture and System Characteristics

• Performance: Optimize critical operations and minimize communication by using large components.
• Security: Use layered architectures to place critical assets in inner layers.
• Safety: Focus safety-critical features within certain subsystems.
• Availability: Ensure redundancy and fault tolerance via redundant components.
• Maintainability: Use interchangeable, replaceable components.

Architectural Views

• Understanding perspectives and notations for describing architectural models.
• Each model provides a specific view or perspective of the system, for example, demonstrating modular decomposition, run-time interactions, or network distributions.
• Multiple views are needed for comprehensive documentation and design. This is useful as a way to describe the systems architecture and multiple aspects.

4 + 1 View Model of Software Architecture

• A logical view emphasizing key abstractions as objects (or objects/classes).
• A process view illustrating how interacting processes (at run-time) compose the system.
• A development view detailing how software is decomposed for design.
• A physical view highlighting system hardware and component distribution across processors.
• Use cases or scenarios can be used to relate these aspects.

Representing Architectural Views

• While some propose UML for system architecture documentation, it is deemed insufficient due to its lack of relevant high-level abstractions.
• Architectural Description Languages are developed but not widely adopted.

Architectural Patterns

• Patterns represent, share, and reuse architectural knowledge.
• They offer stylized descriptions of successful design practices.
• They include insights into when they are and aren't applicable offering context on useful applications.
• Both tabular and graphical descriptions are used to represent the patterns.

The Model-View-Controller (MVC) Pattern

• Separates presentation/interaction from system data.
• Composed of Model, View, and Controller components interacting to manage data, presentation and user input.
• Figure 6.4 (within the text) visually demonstrates the architecture of a web-based application system using the MVC pattern.
• Useful when multiple views or interactions are needed, and future presentation/interaction approaches are unknown.

Web Application Architecture using MVC

• Illustrates a web application's structure using an MVC pattern with the involved components (controller, view, model).

Layered Architecture

• Models interfacing subsystems, with each layer (or machine) offering services—often useful for incremental development, with interface changes affecting only adjacent layers.
• The layered principle is sometimes not a suitable structure for systems.

Layered Architecture Pattern

• Organizes systems by functionality into layers, showing a layered structure where related functionality is arranged.
• Lower layers provide core services to higher layers (like Figure 6.6 and 6.7 in the text).
• Suitable in multi-team/multi-level security/incremental building.

Generic Layered Architecture

• Defines generic components of a layered architecture—typical components such as user interfaces, management of authentication and authorization, business logic, system utilities, and system support including the operating system and database.

The Architecture of the iLearn System

• A layered approach demonstrates the specific application components found within iLearn, including utility layer components.

Repository Architecture

• Subsystems need to share data (in two main ways). This is achieved via a central database or repository or each subsystem maintaining its own database and explicitly sharing data.
• This is an efficient data-sharing mechanism.

The Repository Pattern

• In this pattern, all data is managed in a central repository accessible to all components.
• It is recommended when large volumes of data need to be stored and accessed over time, or for action triggers (that are data-driven) in a system.

Repository Architecture for an IDE

• Illustrates how an integrated development environment (IDE) that uses a central repository stores and retrieves information among its various components.

Client-Server Architecture

• A model for distributed systems, where components handle tasks such as data transfer, specific services, user calls, and network connections.
• These models can be implemented on a single computer.

The Client-Server Pattern

• A system functionality is organized into services delivered by independent servers accessed by client components.
• Shows a potential example of a library organized as a client-server system.
• Provides a way of distributing functionality. This is helpful for data that is stored in a shared database from various locations.

A Client-Server Architecture for a Film Library

• Example visualizing a client-server system in a film library, demonstrating how multiple clients access centralized film catalogues, video stores, photos and web servers.

Pipe and Filter Architecture

• A model of functional transformations. Data transformation components process input to produce outputs.
• Suitable for data processing systems with sequential transformations.
• Not well-suited for interactive systems.

The Pipe and Filter Pattern

• Focuses on a data processing model based on discrete processing components as filters and data flowing through them.
• Describes a typical use in a data processing system utilizing a pipeline and filters.

Example of Pipe and Filter Architecture in a Payments System

• A diagram visually presenting a payments system's architecture using the pipe and filter model.

Application Architectures

• Application systems are created to meet specific needs.
• Businesses frequently share similar needs, leading to shared architectures.
• Generic application architectures provide flexible support through various configurations.

Use of Application Architectures

• Starting point for architectural design, acting as initial guidelines,
• A design checklist
• Organizing development team tasks
• Assessing components and reuse
• Defining application types

Examples of Application Types

• Data processing applications without explicit user intervention
• Transaction processing applications managing database updates
• Event processing applications interpreting events from the environment
• Language processing applications interpreting user intent using specialized languages

Application Type Examples

• Examples include e-commerce systems, reservation systems, and compilers/interpreters, amongst other language processing systems.

Transaction Processing Systems

• Systems processing user requests and updates on databases.
• A transaction is a coherent set of operations toward a goal, like booking a flight.
• Users send requests asynchronously; a transaction manager processes them.

The Structure of Transaction Processing Applications

• Illustrates a typical structure for a transaction processing system via a sequence of components.

The Software Architecture of an ATM System

• An architecture example for an ATM system visualizing how input, process, and output data flow.

Information Systems Architecture

• Information systems are layered, with typical components including user interfaces, communication, information retrieval, and databases.

Layered Information System Architecture

• A layout visualizing a typical layered architecture with specific roles for data flow within an information system.
• The layout in this case, shows how the information system layers are organized sequentially with database transaction layers.

The Architecture of the Mentcare System

• Example visualizing the structure of a medical/healthcare system.

Web-based Information Systems

• Web-based systems handle resource management using web browsers.
• E-commerce systems are an example of this, with functionalities like (shopping carts) to manage a number of items in a single payment transaction

Server Implementation

• Usually, these are multi-tier client-server implementations involving the webserver for communication, an application server, and a database server to control database transactions.

The Architecture of a Language Processing System

• Displays a graphical representation of a language processing system, illustrating the sequence of steps starting from source code to production of results.

Key Points

• A software architecture describes a system's organization.
• Decisions made during design can affect architecture and systems.
• Architectures help document the system from multiple views.
• Patterns are used for reusing existing system knowledge and practices.