Software Architecture

Software Application Architecture

• involves creating a structured solution that meets technical and operational requirements while optimizing quality attributes like performance, security, and manageability.

• It includes various decisions that significantly affect the quality, performance, maintainability, and overall success of the application.

Software Architecture

• Encompasses significant decisions about the organization of a software system, including the selection of structural elements, their interfaces, and the behaviors specified in their interactions.

• It also involves how these elements compose larger subsystems and the architectural style guiding the organization.

• Factors like functionality, usability, performance, constraints, trade-offs, and aesthetics are also part of software architecture.

Architecture

• Consists of software elements, their externally visible properties, and the relationships among them.

• It focuses on public interfaces while private implementation details are not considered architectural.

Architectural Design

• About organizing and structuring a system effectively.

• The chosen architecture influences the system's properties, including performance, security, and availability.

Why is Architecture Important?

Just like any complex structure, software needs a strong foundation to succeed.

Risks of Poor Architecture

• Overlooked Scenarios: Ignoring key scenarios can lead to unforeseen issues.

• Common Problems: Failing to design for typical problems can result in complications.

• Long-term Consequences: Not considering the long-term impact of key decisions can have serious repercussions.

Consequences of Poor Architecture

• Instability: The software may become unstable over time.

• Inadequate Support: It may fail to meet current or future business needs.

• Deployment Challenges: The application might be difficult to deploy or manage in a production environment.

The Architectural Landscape

1. User Empowerment

2. Market Maturity

3. Flexible Design

4. Future Trends

User Empowerment

• Design should prioritize flexibility and user experience.

• Incorporate personalization options without overwhelming users.

• Simplify key scenarios to make the application intuitive and easy to use.

Market Maturity

• Leverage existing platforms and technologies to enhance your application.

• Use higher-level frameworks to focus on unique value rather than reinventing the wheel.

• Apply proven design patterns to solve common problems efficiently.

Flexible Design

• Embrace loose coupling for better reuse and maintainability.

• Implement pluggable designs for extensibility after deployment.

• Utilize service-oriented architecture (SOA) to enable interoperability with other systems.

Future Trends

Anticipate future trends that could impact your architecture post-deployment, such as:

• Rich user interfaces and media

• Composition models (e.g., mashups)

• Increased network bandwidth and availability

• Growing mobile device usage

• Enhanced hardware performance

• Community and personal publishing models

• The rise of cloud computing and remote operations

Key Principles of Software Architecture

• Build to Change

• Model to Analyze and Reduce Risk

• Communication and Collaboration

• Identify Key Engineering Decisions

Build to Change

Design applications with the flexibility to adapt to future requirements and challenges rather than just aiming for long-term stability.

Model to Analyze and Reduce Risk

Use design tools and modeling systems like UML to capture requirements and architectural decisions, allowing for better risk assessment.

Communication and Collaboration

Utilize models and visualizations to effectively share your design with stakeholders and facilitate quick communication of any changes.

Identify Key Engineering Decisions

Recognize critical engineering decisions and common pitfalls, investing effort to make the right choices upfront to ensure a more adaptable design.

Whiteboard your Architecture

• If you cannot whiteboard the architecture then it suggests that it is not well understood.

• If you can provide a clear and concise whiteboard diagram, others will understand it and you can communicate details to them more easily

Architectural Views

When documenting software architecture, it's important to present different perspectives of the system. Krutchen's 4+1 View Model outlines four main views:

• Logical View:

  • Shows the main objects or classes in the system.

  • Links system requirements to these objects.

• Process View:

  • Displays how the system runs with interacting processes.

  • Helps evaluate performance and availability.

• Development View:

  • Breaks down the software for development.

  • Illustrates how components are assigned to developers or teams.

• Physical View:

  • Shows the hardware and how software is distributed across it.

  • Useful for planning system deployment.

Conceptual View

• Hofmeister et al. (2000) add a conceptual view, which provides a high-level overview of the system.

Architectural Patterns

• These are reusable solutions for common software design problems.

• They describe how to set up a system, when to use it, and the pros and cons.

Key Architectural Patterns

• MVC (Model-View-Controller): Separates data (Model), user interface (View), and user input (Controller).

• Layered Architecture: The software is built in layers, each depending on the one below it.

• Repository: Data is stored in a central place where all parts of the software can access it.

• Client-Server: One part of the software (client) requests services from another part (server).

• Pipe and Filter: Data flows through different stages of processing, each stage doing one specific task.

MVC (Model-View-Controller)

• The MVC pattern separates how data is handled from how it's presented and interacted with.

• Components:

  • Model: Manages the system data and operations related to that data.

  • View: Displays the data to the user and defines how it looks.

  • Controller: Handles user input (like clicks and key presses) and communicates it to both the Model and the View.

• When to Use:

  • When there are multiple ways to view and interact with data.

  • When future interaction and presentation needs are uncertain.

• Advantages:

  • Allows data and its presentation to change independently.

  • Supports showing the same data in different formats, with updates reflected in all views.

• Disadvantage:

  • Can add extra code and complexity, especially if the data handling is straightforward.

Layered Architecture

• This pattern organizes a system into layers, where each layer has related functions.

• How It Works:

  • Each layer provides services to the layer above it. The lowest layers handle core services that are commonly used throughout the system.

• When to Use:

  • When creating new features on top of existing systems.

  • When multiple teams are working on different layers of functionality.

  • When multi-level security is needed.

Advantages:

• Flexibility: Entire layers can be replaced as long as their interfaces remain the same.

• Redundancy: Each layer can have backup features (like authentication) to improve system reliability.

Disadvantages:

• Complexity: It can be hard to keep layers cleanly separated, leading to higher layers needing to interact directly with lower ones.

• Performance: There may be performance issues due to the multiple levels involved in processing service requests.

Repository Architecture

• This model is designed for applications where one component generates data that another component uses.

• When to Use:

  • When large amounts of information need to be stored for a long time.

  • In data-driven systems where adding data to the repository triggers actions or tools.

• Examples:

  • Command and control systems.

  • Management information systems.

  • Computer-Aided Design (CAD) systems.

  • Interactive development environments (IDEs) for software.

How It Works:

• In an IDE, various tools generate information and store it in a central repository, making it accessible to other tools.

Advantages:

• Independence: Components can operate independently without needing to know about each other.

• Consistent Updates: Changes made by one component can automatically update all other components.

• Centralized Data Management: All data can be managed in one place, simplifying tasks like backups.

Disadvantages:

• Single Point of Failure: If the repository fails, it can impact the entire system.

• Communication Bottlenecks: Organizing all communication through the repository may lead to inefficiencies.

• Distribution Challenges: It can be difficult to distribute the repository across multiple computers.

Client-Server Architecture

• This architecture organizes system functionality into services provided by separate servers. Clients access these servers to use the services.

How It Works:

• A client sends a request to a server and waits for a response. This architecture is commonly used when multiple locations need access to shared data.

Major Components:

1. Servers: Provide various services to clients.

   • Examples:

     • Print servers (printing services)

     • File servers (file management services)

     • Compile servers (program compilation services)

2. Clients: Applications that request services from servers. Multiple instances of a client program can run on different computers at the same time.

3. Network: Connects clients to servers, typically using Internet protocols. Most client-server systems are distributed.

Advantages:

• Distributed Servers: Servers can be spread across a network, improving accessibility.

• Shared Functionality: General services (like printing) can be made available to all clients without needing to implement them separately for each service.

Disadvantages:

• Single Point of Failure: Each server can fail or be attacked, affecting all clients that rely on it.

• Performance Variability: Performance can be unpredictable due to network issues.

• Management Challenges: Coordination can be difficult if servers are owned by different organizations.

Pipe and Filter Architecture:

• This architecture organizes data processing into discrete components called filters. Each filter performs a specific transformation on the data. The data flows through pipes from one filter to another.

How It Works:

• Each filter takes input data, processes it, and passes the output to the next filter through a pipe. This setup is often used in data processing applications, whether batch-based (processing large volumes of data at once) or transaction-based (processing data in real time).

Advantages:

• Simplicity: The architecture is easy to understand, making it straightforward to follow the data flow.

• Reusability: Filters can be reused in different processes, as they perform specific tasks.

• Workflow Compatibility: The structure aligns well with many business processes, which often involve sequential steps.

• Flexibility: New filters can be added easily to enhance functionality, and the system can operate either sequentially (one after another) or concurrently (simultaneously).

Disadvantages:

• Data Format Agreement: All filters must agree on a common data format for communication, which can complicate integration.

• Parsing Overhead: Each filter needs to convert (parse) its input data to the required format and then convert (unparse) its output, adding processing overhead.

• Compatibility Issues: Functional transformations using different data structures may not be reusable if they can't communicate effectively.