Architectural Design and MVC Patterns

Architectural Design

• Architectural design focuses on understanding and organizing software systems.
• It bridges the gap between design and requirements by identifying major components and their relationships.
• The end result is an architectural model which displays the system's organization as interconnected components.

Agility and Architecture

• Agile processes typically begin with an overall systems architecture design early on.
• System architecture refactoring is costly due to wide-reaching component effects.

Architectural Abstraction

• Architecture in the small pertains to individual program structures.
• This level is concerned with how a program breaks down into components.
• Architecture in the large focuses on large enterprise systems, encompassing other systems, programs, and components.
• These distributed systems might span across several computers and organizations.

Advantages of Explicit Architecture

• Facilitates communication among stakeholders.
• Enables system analysis for satisfying non-functional requirements.
• Enables large-scale reuse across multiple systems through potentially reusable architectural models.

Architectural Representations

• Block diagrams, representing entities and relationships, are common documentation tools.
• These diagrams often lack semantics, omitting relationship types and entity properties.

Box and Line Diagrams

• These diagrams are highly abstract and don't show the nature of component relationships or visible properties of subsystems.
• Useful for communication with stakeholders and project planning.

Use of Architectural Models

• High-level system views are valuable for discussion with stakeholders and project planning.
• High-level diagrams avoid detailed complexities, allowing stakeholders to understand the system better.
• Models allow for efficient documentation of existing designs.

Architectural Design Decisions

• Architectural design is a creative process adapting to the system type.
• Common decisions span all design approaches and influence non-functional characteristics (e.g., performance, security).
• Key decisions include: generic application template, hardware distribution, architectural styles, system structuring, operation control strategies, component decomposition, and documentation standards.

Architecture Reuse

• Similar architectures tend to emerge within the same domain due to similar domain concepts.
• Application product lines are built around core architectures with varied implementations satisfying specific requirements.
• Architectural patterns or styles can be adapted and instantiated for different systems.

Architecture and System Characteristics

• Performance: Minimize communications by focusing on larger, fewer components.
• Security: Use a layered architecture with critical assets in inner layers.
• Safety: Localize safety-critical elements in fewer subsystems.
• Availability: Implement redundant components and fault tolerance.
• Maintainability: Utilize replaceable, fine-grained components.

Architectural Views

• Diverse perspectives are necessary for a comprehensive system architecture design.
• Specific notations must be chosen for describing architectural models.
• A single architectural model only shows one view or perspective of the system.

4 + 1 View Model

• A logical view shows fundamental system objects/classes.
• The process view shows runtime interactions.
• A development view displays the development decomposition structure.
• A physical view displays hardware and component distribution.
• Use cases/scenarios form the additional '1' aspect.

Representing Architectural Views

• UML is a contested notation for system architecture description due to insufficient abstractions for high-level systems.
• Several architectural description languages (ADLs) are available but not widely adopted.

Architectural Patterns

• Patterns provide methods for representation, sharing, and reuse of knowledge.
• Architectural patterns are stylized descriptions of good design practices, proven effective in different environments.
• Patterns include information on when they're appropriate and when they're unsuitable.
• Graphical and tabular representations of patterns are commonly used.

Model-View-Controller (MVC) Pattern

• MVC separates presentation (View), interaction (Controller), and data (Model).
• It comprises three components that interact: Model, View, and Controller.
• The pattern is suitable when multiple views of the same data are needed.
• It promotes flexibility in representations with separate data and view changes.
• Can have increased code complexity in simpler cases.

Web Application Architecture using MVC

• A typical web application displays data in different ways.
• Controllers process HTTP requests, manage logic, and validate data input.
• A View renders the requested data to the user.
• Models handle the application's internal data.
• The Controller, View, and Model interact to manage actions, updating and rendering data.

Layered Architecture

• Layered architecture describes interactions between subsystems.
• Systems are partitioned into layers with each layer providing services to the one above, ultimately producing a layered structure.
• It facilitates the incremental development of sub-systems within their dedicated layers.
• Changes in one layer typically affect only neighboring layers.

Layered Architecture Pattern

• In this pattern, systems are divided into layers, each with its specific functions.
• The lower layers provide foundational services to the higher layers.
• This is common in multi-level security contexts and implementations spreading over distinct teams.
• Maintains clean separation of interactions between layers.
• Potential for overhead and performance issues arises from multiple levels of processing.

Generic Layered Architecture

• A common structure for many systems.
• User interface, user management, core application logic, and system utilities make up the levels within this framework.

The iLearn System Architecture

• This system architecture shows the layered approach with its primary components, including services for configuration, application management, and user identity.

Repository Architecture

• Systems requiring extensive data sharing benefit from central repositories.
• Sub-systems can access a central repository to reduce the need for direct data exchanges.
• Large-scale data sharing, where many sub-systems require simultaneous access to large amounts of data.

Repository Pattern

• Centralized data management helps data consistency.
• Standalone components can interact without needing direct knowledge of other components.
• Failure in the repository affects the entire system's functionality.

A Repository Architecture for an IDE

• This particular architecture diagram depicts a software environment (IDE) example where components interface around a central repository, sharing design data.

Client-Server Architecture

• This model of distribution shows how data and processes are located across components, though it can be implemented on a standalone computer.
• Servers provide specific services (e.g., printing or data management), while clients call on these services.
• Efficient for distributed data access and services over a network.

Client-Server Pattern

• Functionality is segmented into server-provided services accessed by clients.
• The architecture is adaptable for distributed data use with replicated servers for load balancing.

Pipe and Filter Architecture

• This approach processes data through transformations, each component taking and manipulating the data stream.
• The steps can be sequential for batch systems or concurrent for more complex ones.

Pipe and Filter Pattern

• Easy to understand due to the transformation-based processing model.
• Data communication needs to be standardized because incompatibility can emerge during the process.

An Example of the Pipe and Filter Architecture

• Data flows through steps that follow a sequential order for processing payments through the financial system.

Application Architectures

• Application systems are specifically structured to meet organizational needs.
• Many business requirements are similar, so architecture often resembles that of similar organizations.

Use of Application Architectures

• Provides a conceptual starting point for architectural design and detailed plans.
• Serves as a reference point to organize a development team and a check list of requirements.

Examples of Application Types

• Data processing: Batch processing without user interaction.
• Transaction processing: Centralized operations (often involving databases) and user interaction for updating information (e.g., online banking).
• Event processing: Systems reacting to events through a series of instructions, often asynchronous.
• Language processing: System that transforms one language into another, or interprets user commands.

Application Type Examples

• Transaction processing: E-commerce, reservation systems.
• Language processing: Compilers, command interpreters.

Transaction Processing Systems

• Transaction processing systems process requests for a database or updates to the database.
• A transaction is commonly defined as a coherent set of operations linked by a shared goal (like confirming a flight booking).
• Transaction managers are responsible for handling the user requests.

The Structure of Transaction Processing Applications

• A typical structure displays input/output processing, application logic, transaction management, and database interaction.

ATM System Architecture

• ATMs follow a sequential processing pattern, taking user input, performing transactions on the database, and outputting results to the user.

Information Systems Architecture

• Information systems provide a generic, often layered, architecture.
• These transaction-based systems often interact with databases.

Web-based Information Systems

• Information systems are often implemented as web-based applications, using a web browser as the user interface.
• E-commerce is a prime example of such a system.

Server Implementation

• Multi-tier client-server models are common in web applications, with each tier performing distinct roles (web server, application server, database server).

The Architecture of a Language Processing System

• A language processing system typically organizes its structure into various steps.
• This sequence transforms source instructions into executable operations and outputs the results in a desired format.

Key Points

• Architectures describe system organization.
• Architectural decisions cover system type, distribution, and architectural style selection.
• Multiple views (conceptual, logical, process, development) support documentation efforts.
• Architectural patterns facilitate knowledge reuse.