Software Architecture: Principles, Patterns, and Practices

Posted on Jan 21, 2025 in Software Engineering

ANSI/IEEE Standard 471-2000:
Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

Perry and Wolf: Software Architecture = { Elements, Form, Rationale }

History of Software Architecture

  • Agile Manifesto: In February 2001, 17 software developers met at the Snowbird resort in Utah to discuss lightweight development methods.
  • Agile is not incompatible with or somehow against software architecture; it has a different view.
  • Eleventh Principle: “Best architectures, requirements, and designs emerge from self-organizing teams.”
  • Agile was partially popularized in response to drawbacks of Big Design Up Front (BDUF) waterfall approaches that the initial emphasis on software architecture made popular.
  • Technical Debt: The work that needs to be done before implementation is truly considered “complete” even if the software is already functional (e.g., re-factoring, optimizing the design). It is an eventual consequence of maintaining software over time. There’s a rising interest in managing technical debt post-2005.

Software Architecture Review

  • Architecture is about structure and behavior.
  • All architecture is design, but not all design is architecture – Image 1
  • Multiple Goals: Reliability, scalability, maintainability, etc.
  • Multiple Stakeholders: Customer, management, developers, testers, customer support.
  • Architecture is not a phase. Integration with the development process is important.
  • Architecture involves unavoidable economic trade-offs, e.g., performance vs. maintainability.
  • Architecture leverages known solutions over intuition.
  • Design Styles: Service-Oriented Architecture (SOA).
  • Design Patterns: Model-View-Controller (MVC).

Role of a Software Architect

  • Craft the “right” architecture.
  • Define, document, and communicate it.
  • Ensure everyone is using it, and using it correctly.
  • Ensure management understands it (to the detail necessary).
  • Ensure that the architecture is not only the right one for the project but also for sustainment.
  • Manage risk identification and risk mitigation strategies associated with the architecture.

Functional Requirements

  • What a system is supposed to do.
  • Specific behaviors or functions.
  • Example: The system shall generate a PDF receipt after a sale.

Nonfunctional Requirements

  • How a system is supposed to be.
  • Criteria that can be used to judge the operation of a system.
  • Example: The system must handle 1000 simultaneous users.
  • Also Known As:
    • Quality Attributes
    • Qualities
    • Constraints
    • Non-behavioral Requirements

Types of Non-functional Requirements

  • Execution Qualities: Observable at runtime, e.g., security and usability.
  • Evolution Qualities: Embedded in the static structure of the software system, e.g., maintainability and scalability.

Nonfunctional Requirements Examples

  • Maintainability: The extent to which software is capable of being changed after deployment.
    • Fix remaining errors.
    • Address performance issues.
    • Changes in software requirements.
  • Compatibility: The extent to which software is capable of executing on different platforms.
  • Testability: The extent to which software is capable of being tested.
  • Traceability: The extent to which products of each phase can be traced back to products of previous phases.
  • Scalability: The extent to which the system is capable of growing after its initial deployment.
  • Reusability: The extent to which software is capable of being reused.
  • Performance: The extent to which the system meets its performance goals, such as throughput and response times.
  • Security: The extent to which the system is resistant to security threats.
  • Availability: The extent to which the system is capable of addressing system failure.

Image 2: In Word

Taxonomies

  • Taxonomies are schemes of classification that subdivide related categories of things.
  • Taxonomies vary in their detailedness and complexity.
  • Product-Oriented Attributes: Performance, usability, reliability, security.
  • Product-Family Attributes: Portability, modifiability, reusability.
  • Process-Oriented Attributes: Maintainability, testability, integrability.

Nonfunctional Requirement Problems

  • Nonfunctional requirements are informal.
  • They are hard to measure sometimes.

Metrics and Measures

  • Need to be able to both explicitly quantify requirements and to verify that solutions satisfy them.
  • What and how we measure will impact how design decisions take place, as architects and developers will optimize these metrics.
  • Metrics and measures are used interchangeably in practice, but let’s make the distinction clearer.
  • Metrics: Define what we measure, including the metric units used for the measurement values.
  • Measures: Are the method for how we determine the value.

Metric vs. Measure Example

  • Metric: Mean time between failures. Measure: Observe the number of failures over a period of time in a working system implementation.
  • Metric: Time to process 1,000 entries in seconds. Measure: Simulate processing of 1,000 entries and measure elapsed time.

Ways to Measure

  • By Testing:
    • Measure the actual system or subsystem, perhaps by using tools or third-party libraries to assist.
    • Performance Examples: Benchmark programs, track FPS.
    • Reliability Examples: Keep error logs, monitor outages.
  • By Simulation:
    • Have a program simulate important characteristics of the system.
    • Flexible, easy to modify, and lower cost compared to modifying the system.
    • Good for analyzing alternatives, i.e., “what-if” analysis.
    • Difficult to model small details, accuracy limitations.
  • By Analytical Modeling:
    • Compute measures using a mathematical description of the system.
    • Quick to perform.

Measure Comparison: The way we measure non-functional requirements involves trade-offs. Image 3

Metric Usefulness

  • It is measurable, specified with precision.

Reliability Metrics

Image 4

  • Probability of Failure on Demand (POFOD): Is the probability that the system will fail when service is requested.
  • Rate of Occurrence of Failure (ROCOF): Is the number of failures per unit of time.
  • Mean Time To Failure (MTTF): Average time to a non-repairable failure. Often used for hardware components.
  • Mean Time Between Failures (MTBF): Average time between repairable failures.
  • Mean Time To Repair (MTTR): Average time to resume operation after failure. Example: Less than 20 seconds shall be needed to restart the system after a failure 95% of the time.
  • Availability: Proportion of time that the system is available for use. Example: 0.999 availability if the system is up 99.9% of the time. Availability = uptime/total time = MTBF/(MTBF+MTTR).
  • Precision: Degree of precision for computations. Example: The precision of calculations shall be at least 1/10^6. MRI machines and Large Hadron Collider.

Performance Metrics

  • Response time, number of events processed/denied in some interval of time, throughput, capacity, usage ratio, jitter, loss of information, latency.
  • Examples:
    • The system shall be able to process 100 payment transactions per second in peak load.
    • Production of a simple report shall take less than 20 seconds for 95% of the cases.

Maintainability Metrics

  • Measures the ability to make changes quickly and cost-effectively. Example: Extension with new functionality, deleting unwanted capabilities.
  • Can be Measured in Terms of: Mean time to fix a defect, mean time to add new functionality, cyclomatic complexity.
  • Cyclomatic Complexity:
    • Number of linearly independent paths through a program’s source code.
    • Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command.
    • M (Complexity) = Edges − Nodes + 2 -> Image 5
  • Examples:
    • The cyclomatic complexity of code must not exceed 7.
    • No method in any object may exceed 200 lines of code.

Testability Metrics

  • Measures the ability to detect, isolate, and fix defects.
  • May lead to architectural requirements.
  • Examples:
    • The delivered system shall include unit tests that ensure 100% branch coverage.
    • Development must use regression tests allowing for full retesting in 12 hours.
  • Debugging:
    • Purposely add known defects to the application to determine the rate of detection. Also called fault seeding.
    • Estimated number of bugs in the system = (# of seeded bugs * # of discovered real bugs) / # of detected seeded bugs.

Portability Metrics

  • Measure the ability of the system to run under different computing environments.
  • Can be measured as # of targeted platforms, the proportion of platform-specific components, mean time to port to different OSs.
  • Examples:
    • No more than 5% of the system implementation shall be specific to the operating system.
    • Mean time to replace the current relational database should not exceed 2 hours.

Security Metrics

  • The extent to which the system is resistant to security threats.
  • Possible Metrics: Success rate in authentication, resistance to known attacks, percentage of successful attacks, encryption level.
  • Example: At least 99% of intrusions shall be detected within 10 seconds.

Robustness Metrics

  • Measure the ability to cope with the unexpected.
  • Examples:
    • Percentage of failures on invalid inputs.
    • The estimated loss of data in case of a disk crash shall be less than 0.01%.

Architectures Have Multiple Possible Views

  • Views are representations of the overall architecture that are meaningful to one or more stakeholders in the system.
  • View: A view is a representation of a whole system from the perspective of a related set of concerns.
  • Architecture Viewpoints:
    • A viewpoint defines the perspective from which a view is taken.
    • We could specify a viewpoint by a name, stakeholders, concern, and modeling technique.

Architecture Views vs. Viewpoints

  • A view is what you see | A viewpoint is where you are looking from – the vantage point or perspective that determines what you see.
  • Viewpoints are generic and can be stored in libraries for re-use | A view is always specific to the architecture for which it is created.
  • Every view has an associated viewpoint that describes it, at least implicitly.

Architecture Documentation Challenges

  • No universally accepted architecture documentation standard.
  • An architecture can be complex, and documenting it in a comprehensible manner is time-consuming and non-trivial.
  • An architecture has many possible views. Documenting all the potentially useful ones is time-consuming and expensive.
  • An architecture design often evolves; keeping the architecture documents current is often forgotten, especially with time and schedule pressures in a project.

Architecture Documentation Benefits

  • The project team (including stakeholders) and sustainment organization can learn, understand, and evaluate the architecture.
  • Useful for future enhancements/projects.

Architecture Documentation Considerations

  • Project complexity.
  • Project longevity.
  • Needs of stakeholders.
  • Need to spend documentation dollars wisely on high-value products.

4+1 Viewpoints

  • Scenario Viewpoint: Focused on use cases based on scenarios.
    • This is the plus one as it is redundant than others.
    • Serves 2 Main Purposes:
      • As a driver to discover architectural elements during architectural design.
      • As a validation and illustration role after this architecture design is complete.
    • Sometimes called “use case view”.
  • Physical Viewpoint: Focused on the mapping of software to hardware.
    • Useful for taking into account availability, reliability, performance, and scalability.
    • UML deployment diagrams, Image 6
  • Development Viewpoint: Focused on the organization of the software modules.
    • Non-functional requirements taken into account include maintainability, extensibility, modifiability, etc.
    • Image 7
  • Process Viewpoint: Focused on runtime behavior, process communication.
    • Non-functional requirements taken into account include maintainability, availability, performance, etc.
    • Image 8
  • Logical Viewpoint: Focused on functionality provided to end-users.
    • Supports functional requirements.

MVC (Model-View-Controller)

  • View: This is what the user sees and interacts with. These could be pages, charts, and diagrams. The user may use this to invoke an action from the controller.
  • Controller: Accepts action from the view, requests updates from models.
  • Model: Responsible for database updates and business logic.
  • Facts:
    • MVC came out of the Xerox PARC research lab into graphical user interfaces.
    • MVC is extremely popular within web development.
    • MVC is a design pattern.

Design Patterns

  • It is a general reusable solution to a commonly occurring problem in software design.
  • Design patterns allow us to apply known solutions to problems we already know how to solve.
  • Benefits:
    • Speeds up the development process by not re-inventing the wheel each time.
    • Improves code readability by using solutions others are familiar with through standard documentation.
  • History:
    • The “Design Patterns” book, published in 1994, took DP to the mainstream.
    • Covers 23 classics.
    • Authors are known as the “Gang of Four”.

Architectural Styles

  • A coarse-grained pattern that provides an abstract framework for a family of systems.
  • Client-Server Architecture:
    • The client initiates one or more requests, waits for a reply, and processes the reply.
    • The server receives requests, carries out the required processing, and sends back responses.
    • Benefits: Scalability.