Architectural Design and Models Quiz

Architectural Design

• Architectural design is the process of understanding how a software system should be organized and designing its overall structure.
• It's a critical link between design and requirements engineering, identifying key components and their relationships.
• The output is an architectural model, describing how components interact.

Topics Covered

• Architectural design decisions
• Architectural views
• Architectural patterns
• Application architectures

Agility and Architecture

• Agile processes typically involve designing an overall systems architecture early on.
• Refactoring the system architecture is usually costly due to its impact on numerous components.

Architectural Abstraction

• Architecture in the small focuses on individual programs, detailing their decomposition into components.
• Architecture in the large considers complex enterprise systems, often distributed across multiple computers and organizations.

Advantages of Explicit Architecture

• Stakeholder Communication: Architecture acts as a common discussion point for stakeholders.
• System Analysis: Facilitates analysis of non-functional requirements (e.g., performance, security).
• Large-Scale Reuse: Allows reuse of architecture across various systems, promoting product line development.

Architectural Representations

• Simple block diagrams are the most used method to document software architectures.
• However, these lack semantics and don't show the comprehensive relationships and properties.
• Architectural model requirements depend on their specific usage.

Box and Line Diagrams

• Highly abstract, not displaying component properties or relationships between sub-systems.
• Useful for communication and project planning.

Use of Architectural Models

• Facilitating Discussion: High-level models help stakeholders understand the system without intricate details.
• Documentation: Enables complete system models showcasing components, interfaces, and connections.

Architectural Design Decisions

• The process is creative and varies depending on the system being developed.
• Many common decisions impact non-functional characteristics (e.g., performance, security).

Example Architectural Design Decisions

• Generic application architecture as template?
• System distribution on hardware?
• Key architectural patterns or styles?
• Fundamental approach to system structure?
• Strategy for component interaction?
• Sub-component decomposition?
• Architectural organization for non-functional needs?
• System architecture documentation method?

Architecture Reuse

• Systems in the same domain often share similar architectures based on domain concepts.
• Application product lines utilize core architectures with variations to satisfy customer needs.
• Architectural patterns/styles encapsulate architectural essence, enabling instantiation in different systems.

Architecture and System Characteristics

• Performance: Localize critical operations, minimize communications.
• Security: Layered architecture with critical assets in inner layers.
• Safety: Safety-critical features in isolated sub-systems.
• Availability: Include redundant components and fault tolerance.
• Maintainability: Use fine-grained, replaceable components.

Architectural Views

• Identify useful views/perspectives for design and documentation.
• Specify notations for describing architectural models.
• A single architectural model only provides one perspective of the system.

4 + 1 View Model

• Logical View: Key system abstractions (objects/classes).
• Process View: Real-time interactions of system processes.
• Development View: Software decomposition for development.
• Physical View: System hardware and component distribution across processors.
• Supplementary Use Case Views: Provide context and scenarios.

Representing Architectural Views

• UML is not generally suitable for high-level system descriptions.
• Architectural description languages (ADLs) are available but not widely used.

Architectural Patterns

• Patterns represent, share, and reuse knowledge of good design practices.
• Stylized descriptions of tried and tested design patterns in various environments.
• Include criteria for their applicability and limitations.
• Can be represented using tables and diagrams.

Model-View-Controller (MVC) Pattern

• Separates presentation, interaction, and system data into logical components (Model, View, Controller).
• Model manages data; View defines presentation; Controller handles user interactions.
• Useful when various view options and interactive modes are required.
• Can lead to additional complexity when data model and interactions are not complex.

Web Application Architecture with MVC

• Controller processes HTTP requests, validates data, and updates model.
• View generates dynamic web pages based on model data.
• Model encapsulates application logic and interacts with database, managing business logic.

Layered Architecture

• Represents interfacing of sub-systems, decomposing system into layers with each providing services to higher layers.
• Promotes incremental development as interface changes affect only adjacent layers.
• Might be overly artificial for some systems

Layered Architecture Pattern

• Organizes the system into layers with related functional components.
• Lower layers provide core services to higher layers.
• Useful for multi-team development and security concerns.
• Potential for complex interactions due to interdependencies.

Generic Layered Architecture

• Template for common layers across systems.
• Example layers: user interface, authentication, business logic, system utilities, system support.

Architecture of the iLearn System

• Example of a layered application system
• Breakdown of services in layered structure
• Services within each layer.

Repository Architecture

• Subsystems share data through a central repository or database.
• Each subsystem can access and update data within the common repository.
• Efficient for significant data sharing within the system.

Repository Pattern

• Centralized data management in a system.
• Data interaction occurs only through the repository; components do not interact directly.
• Single point of data access and management promotes consistency.
• Potential for performance bottleneck if repository is a single point of failure.

A Repository Architecture for an IDE

• Example demonstrating the use of a central repository in an integrated development environment (IDE).
• The repository organizes design information accessible to different tools.

Client-Server Architecture

• Distributes data and processing operations in a distributed system.
• Consists of independent servers providing services (e.g., printing, data management).
• Clients access these services running on a network.

Client-Server Pattern

• Distributes system function across multiple servers
• Common for applications with a wide range of potential users or loads
• Single point of failure for each service

A client-server architecture for a film library

• Illustrative client-server architecture example for a film library.
• Multiple clients interact with different servers (catalog, video, picture, and web) over the Internet for data retrieval and management functions.

Pipe and Filter Architecture

• Linear processing of data, where components perform specific transformations.
• Transformations are applied sequentially via a pipe-like structure.
• Suitable for batch-processing or tasks needing ordered stage-by-stage processing.
• Inappropriate for interactive systems requiring immediate responses.

Pipe and Filter Pattern

• Simple system organization for processing data in stages.
• Reusable transformations; data flows through components linearly.
• Data transfer format needs to be unified between components.

Example of the Pipe and Filter Architecture in Payments

• Illustrative diagram depicting data flow within a payment system.
• Payments are processed through a pipeline-like structure with individual components responsible for handling particular stages (e.g., identifying payments, calculating dues).

Application Architectures

• Application systems are designed to fulfill business needs.
• Common architectures can be built from reusable components.
• Generative architecture approach for creating a system that matches the business requirements

Use of Application Architectures

• Starting Point for Design: Provides a framework or baseline for initial design decisions.
• Design Checklist: Provides guidelines and considerations for developing applications.
• Development Team Organization: Facilitates project breakdown amongst team members.
• Component Assessment for Reuse: Provides components to be reused or modified
• Vocabulary for Application Types: Common language for describing differences between applications.

Examples of Application Types

• Data Processing: Processes data in batches without explicit user intervention.
• Transaction Processing: Processes user requests to update data in a database.
• Event Processing: Processes events from the system's environment.
• Language Processing: Processes requests in a formal language.

Application Type Examples

• Transaction Processing Systems: Including e-commerce, reservations.
• Language Processing Systems: Compilers, interpreters.

Transaction Processing Systems

• Process user requests to access and update database information.
• Transactions are a coherent sequence of operations that achieves a specific goal.
• User interactions are asynchronous; handled by a transaction manager.

Structure of Transaction Processing Applications

• Typical sequence involved in a transaction system
• I/O processing, application logic, transaction manager, database.

Software Architecture of an ATM System

• Example demonstrating different steps of the design implementation.
• The system has three parts: the front end (Input), the processing section (Process), and the back end (Output)
• Input is from the ATM; the processing section queries the database, updates data and displays information on the front end (outputs) to the ATM customer.

Information Systems Architecture

• Most common structure for transaction based systems, using a layered architecture approach.
• Includes user interface, communications, information retrieval, and system database.

Layered Information System Architecture

• Layered architecture to organize data handling in an information system.
• Interfaces between layers that can be modified separately.

The Mentcare System Architecture

• Detailed architecture example demonstrating layers commonly found in a hospital or care management system.
• Includes web browser interaction, authentication, patient information access, import/export, reporting, and transaction processing.

Web-Based Information Systems

• Typical architecture for modern web applications.
• User interfaces implemented using web technologies, often employing layered architectures.
• Functionality for e-commerce, online resource management, with elements such as shopping carts and order processing.

Server Implementation

• Multi-tier client-server architecture is common in web-based systems.
• Web servers handle communications, using user-interface web browsers.
• Application servers handle application logic and data interactions
• Database servers manage data transactions.

Architecture of a Language Processing System

• System that converts source code to machine code
• Stages in the process: translation, semantic analysis, code generation, and execution.

Key Points

• Software architecture describes a system's organization.
• Architectural design decisions span application type, distribution, and architectural style.
• Standardized documentation methods for documenting systems through multiple perspectives (e.g., conceptual, logical, process, development).
• Architectural patterns facilitate reuse of knowledge, ensuring efficient development efforts.
• Models of application designs support validation, understanding, and comparison.
• Transaction processing is common in many information systems, allowing access and modification of data by multiple users.
• Language processing systems convert different language instructions into instructions for a machine