Software Architecture - 4
Documenting Software Architectures Effectively
Table of contents
- Requirements for Architecture
- Architecture Life Cycle
- Economic Analysis Methods
- Active Reviews
- Attribute Driven Design
- Architecture Reuse
- Domain-Specific Architecture
Requirements for Architecture
Functional requirements define what the system should do or its functions and features. They include:
Functional requirements shape the high-level design and modules of the system architecture.
Non-functional requirements define how well the system should perform or behave. They include:
Performance (speed, scalability, throughput)
Usability (interface design)
Non-functional requirements constrain architectural decisions and choices.
Constraints and Assumptions
Technical constraints (hardware, software, platforms)
Resource constraints (time, cost, people)
Environmental constraints (operating conditions)
Assumptions about the system scope, users, and usage scenarios also influence the architecture.
Architecture Life Cycle
Architecture Design in SDLC
In the Software Development Life Cycle, architecture design typically happens in the following phases:
Functional and non-functional requirements are gathered from stakeholders.
Initial high-level architectural decisions are made based on requirements.
System scope, constraints and assumptions are documented.
Detailed architectural design is done including:
Module decomposition into subsystems and components
Component allocation to tiers or layers
Interface design between components
Selection of architectural patterns and styles
Low-level design of components is done.
The architecture is implemented by:
Developing individual components
Integrating components through their interfaces
Configuring and deploying infrastructure to support the architecture
Unit testing of individual components
Integration testing of groups of components
System testing of the whole architecture:
The system is deployed onto the target environment based on the defined architecture.
Deployment details like server configurations, network settings, etc. are finalized.
The architecture evolves over time through:
Adding new features
Improving performance and scalability
Replacing obsolete components
Changes are made through iterative cycles of:
Implementation of changes
The architecture is continuously evaluated and improved.
Evolutionary prototyping model
In this model, an initial architecture is designed and implemented. Then it evolves through iterations by:
Making necessary changes to the architecture
This allows for continuous improvement of the architecture based on user feedback.
Analysis and Evaluation Methods
The architecture is evaluated using methods like:
Experts inspect and evaluate the architecture design against requirements and quality attributes.
The architecture design is presented and explained to stakeholders who provide feedback.
The architecture life cycle is iterative and evolutionary in nature. The initial architecture is designed based on requirements and then evolves through prototyping, evaluation and refinement. The architecture continues to change and improve as the system evolves over time.
Economic Analysis Methods
Cost Benefit Analysis Method (CBAM)
This method compares the costs and benefits of different architectural alternatives.
Steps in CBAM:
Identify architectural alternatives
Identify costs and benefits for each alternative
Quantify costs and benefits in monetary terms
Calculate the net present value (NPV) for each alternative
Select the alternative with the highest NPV
CBAM helps choose the alternative with the best return on investment.
Cost Benefit Analysis (CBA) evaluates alternatives based on their costs and benefits. CBA would identify things like:
Development and implementation costs of different architectural options
Expected income or productivity gains from each option
Overall return on investment of each alternative
CBA helps choose the architectural option with the highest net present value.
Architecture Tradeoff Analysis Method (ATAM)
ATAM evaluates architectural design based on:
Quality attribute requirements
The ATAM process:
Identify stakeholders and quality attributes
Present architectural approaches
Evaluate architectural approaches against quality attributes
Generate and evaluate risk items
Develop revised architecture based on findings
ATAM helps improve the architecture by identifying risks, trade-offs and mismatches with respect to quality attribute requirements.
Architecture Tradeoff Analysis Method (ATAM) evaluates architectures based on quality attributes and trade-offs. ATAM would identify things like:
How well each architectural approach meets quality requirements like performance, security, modifiability, etc.
Trade-offs between quality attributes, for example, improved security may reduce performance.
Risks in the architecture that could impact quality attributes.
ATAM helps improve the architecture by finding ways to better meet quality requirements and manage trade-offs and risks.
Active reviews involve stakeholders actively participating in evaluating and improving the architecture.
Active Reviews for Intermediate Design (ARID)
ARID is a method for reviewing architecture during the design phase. It involves:
Identify reviewers, materials, goals and criteria
Present the architectural overview and design rationale
Explain the details of the architecture and answer questions
Pose hypothetical scenarios to evaluate how well the architecture meets its goals
Example scenario: "What if there is a 10x increase in the number of users?"
Issues List Reviewers document issues, concerns, risks and suggestions
Discuss and negotiate resolutions for issues
Document action items and next steps
Implement changes and revisit unresolved issues
For example, during the hypothetical scenarios in an e-commerce site ARID, a scenario about a 10x increase in users uncovered that the architecture did not scale well. This led to identifying an issue around scalability and suggesting changes like using a distributed cache to improve it.
Attribute Driven Design
Attribute Driven Design (ADD) is an architectural design process that focuses on quality attributes.
The steps in ADD are:
Attribute Identification Identify quality attributes that are important for the system.
Prioritize attributes based on stakeholder needs.
Architecture Synthesis Generate architectural candidates that satisfy the attributes.
Analysis and Evaluation
Analyze and evaluate candidates against attributes.
Select the final architecture based on analysis.
Attributes can be classified as:
Functional: Reliability, performance, security
Non-functional: Usability, maintainability, portability
Attribute-driven design decisions
Design decisions are made to satisfy attributes, like:
Data distribution to improve performance
Caching to improve response time
Module decomposition to improve maintainability
Exception handling to improve reliability
Here are some examples of design decisions that target specific quality attributes in attribute-driven design:
Caching frequently used data
Partitioning data across multiple servers
Using in-memory databases
Implementing retry mechanisms
Adding redundancy through failover systems
Handling exceptions gracefully
Creating modular, loosely coupled components
Abstracting low-level details into libraries and frameworks
Implementing design patterns for code reuse
Performing input validation
Encrypting sensitive data
Using access control lists to restrict access
Providing meaningful error messages
Using familiar UI metaphors and navigation
Supporting undo/redo actions
Reusing existing architectures can provide many benefits.
Benefits of architecture reuse
Faster development time
Reduced development costs
Methods of architecture reuse
Component reuse: Reusing existing architectural components to build a new system.
Reference model reuse: Reusing an existing architectural model or framework as a template.
Challenges of architecture reuse
Matching requirements: Existing architectures may not match new requirements perfectly.
Integration issues: Integrating reused components into a new system can be difficult.
Incompatible styles: The style of the reused architecture may be different.
Outdated technology: The reused architecture may use outdated technologies.
Domain-specific architecture focuses on the architectural needs of a particular domain.
A domain-specific architecture:
Addresses the core abstractions and constraints of a domain
Reuses architectural knowledge within that domain
Is optimized for a specific type of system
Examples of domains:
Business information systems
Benefits and Challenges
Faster development time
Architectures optimized for the domain
Limited reusability outside the domain
Requires domain knowledge
Design patterns for specific domains
User interface patterns for desktop, web and mobile applications
Distribution patterns for real-time and embedded systems
Integration patterns for enterprise information systems
Here are some examples of design patterns for domain-specific architectures:
Polling - Constantly check for new data at fixed intervals
Interrupt-driven - Use hardware interrupts to trigger event handlers
Preemptive multitasking - Allow tasks to preempt each other to meet deadlines
Event-driven - Trigger actions in response to external events
Cooperative multitasking - Tasks voluntarily relinquish control
Producer-consumer - For asynchronous data flow between components
Model-view-controller - Separate data, UI and logic
Fragment - Reusable UI components
Service locator - Locate and share services across app components
Order processing - Handle order creation, validation and fulfillment
Catalog management- Manage product listings and attributes
Shopping cart - Maintain state of customer purchases
These patterns provide domain-specific solutions that address the needs of real-time systems, mobile apps, e-commerce systems and other domains. They reuse architectural knowledge within a particular domain.
Did you find this article valuable?
Support Vishesh Raghuvanshi by becoming a sponsor. Any amount is appreciated!