Software Architecture: Foundations, Theory, and Practice

Software Architecture: Foundations, Theory, and Practice

Released
Publisher(s): Wiley
ISBN: None

Read it now on the O’Reilly learning platform with a 10-day free trial.

O’Reilly members get unlimited access to books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial

Book description

None

Table of contents

  1. Copyright
  2. About the Cover
    1. THE ARCHITECT'S DREAM, THOMAS COLE, 1840
  3. Credits
  4. Preface
    1. SOFTWARE ARCHITECTURE
    2. THE SCOPE OF THE BOOK
      1. Audiences
    3. ASSUMPTIONS AND BACKGROUND
    4. HOW THE BOOK CAN BE USED
      1. Classroom Usage
      2. Use by Professionals
      3. Tool Support
      4. Chapter Summaries
        1. Chapter 1: The Big Idea
        2. Chapter 2: Architectures in Context: The Reorientation of Software Engineering
        3. Chapter 3: Basic Concepts
        4. Chapter 4: Designing Architectures
        5. Chapter 5: Connectors
        6. Chapter 6: Modeling
        7. Chapter 7: Visualization
        8. Chapter 8: Analysis
        9. Chapter 9: Implementation
        10. Chapter 10: Deployment and Mobility
        11. Chapter 11: Applied Architectures and Styles
        12. Chapter 12: Designing for Non-Functional Properties
        13. Chapter 13: Security and Trust
        14. Chapter 14: Architectural Adaptation
        15. Chapter 15: Domain-Specific Software Engineering
        16. Chapter 16: Standards
        17. Chapter 17: People, Roles, and Teams
  5. Acknowledgments
  6. About the Authors
  7. 1. The Big Idea
    1. 1.1. THE POWER OF ANALOGY: THE ARCHITECTURE OF BUILDINGS
      1. 1.1.1. Limitations of the Analogy
      2. 1.1.2. So, What's the Big Idea?
    2. 1.2. THE POWER AND NECESSITY OF BIG IDEAS: THE ARCHITECTURE OF THE WEB
    3. 1.3. THE POWER OF ARCHITECTURE IN THE SMALL: ARCHITECTURE ON THE DESKTOP
    4. 1.4. THE POWER OF ARCHITECTURE IN BUSINESS: PRODUCTIVITY AND PRODUCT LINES
    5. 1.5. END MATTER
    6. 1.6. REVIEW QUESTIONS
    7. 1.7. EXERCISES
    8. 1.8. FURTHER READING
  8. 2. Architectures in Context: The Reorientation of Software Engineering
    1. 2.1. FUNDAMENTAL UNDERSTANDINGS
    2. 2.2. REQUIREMENTS
    3. 2.3. DESIGN
      1. 2.3.1. Design Techniques
        1. 2.3.1.1. Object-Oriented Design
        2. 2.3.1.2. Domain-Specific Software Architectures (DSSAs)
    4. 2.4. IMPLEMENTATION
      1. 2.4.1. Implementation Strategies
    5. 2.5. ANALYSIS AND TESTING
    6. 2.6. EVOLUTION AND MAINTENANCE
    7. 2.7. PROCESSES
      1. 2.7.1. The Turbine Visualization
      2. 2.7.2. Example Process Depictions
        1. 2.7.2.1. A Robust Domain-Specific Software Architecture-based Project
        2. 2.7.2.2. Agile Development
        3. 2.7.2.3. Other Processes and Process Models
    8. 2.8. END MATTER
    9. 2.9. REVIEW QUESTIONS
    10. 2.10. EXERCISES
    11. 2.11. FURTHER READING
  9. 3. Basic Concepts
    1. 3.1. TERMINOLOGY
      1. 3.1.1. Architecture
        1. 3.1.1.1. Prescriptive Architecture versus Descriptive Architecture
        2. 3.1.1.2. Prescriptive and Descriptive Architectures in Action: An Example
        3. 3.1.1.3. Architectural Degradation
        4. 3.1.1.4. Architectural Perspectives
      2. 3.1.2. Component
      3. 3.1.3. Connector
      4. 3.1.4. Configuration
      5. 3.1.5. Architectural Style
      6. 3.1.6. Architectural Pattern
    2. 3.2. MODELS
    3. 3.3. PROCESSES
    4. 3.4. STAKEHOLDERS
    5. 3.5. END MATTER
    6. 3.6. REVIEW QUESTIONS
    7. 3.7. EXERCISES
    8. 3.8. FURTHER READING
  10. 4. Designing Architectures
    1. 4.1. THE DESIGN PROCESS
    2. 4.2. ARCHITECTURAL CONCEPTION
      1. 4.2.1. Fundamental Conceptual Tools
        1. 4.2.1.1. Abstraction and the Simple Machines
        2. 4.2.1.2. Choosing the Level and Terms of Discourse
        3. 4.2.1.3. Separation of Concerns
      2. 4.2.2. The Grand Tool: Refined Experience
    3. 4.3. REFINED EXPERIENCE IN ACTION: STYLES AND ARCHITECTURAL PATTERNS
      1. 4.3.1. Domain-Specific Software Architectures
      2. 4.3.2. Architectural Patterns
        1. 4.3.2.1. State-Logic-Display (aka. Three-Tier)
        2. 4.3.2.2. Model-View-Controller (for Graphical User Interfaces)
        3. 4.3.2.3. Sense-Compute-Control (aka. Sensor-Controller-Actuator)
      3. 4.3.3. Introduction to Styles
        1. 4.3.3.1. Peer-to-Peer
      4. 4.3.4. Simple Styles
        1. 4.3.4.1. Traditional Language-Influenced Styles
        2. 4.3.4.2. Layered
        3. 4.3.4.3. Dataflow Styles
        4. 4.3.4.4. Shared State
        5. 4.3.4.5. Interpreter
        6. 4.3.4.6. Implicit Invocation
        7. 4.3.4.7. Peer-to-Peer
      5. 4.3.5. More Complex Styles
        1. 4.3.5.1. C2
        2. 4.3.5.2. C2 Constraints
        3. 4.3.5.3. Distributed Objects
      6. 4.3.6. Discussion: Patterns and Styles
        1. 4.3.6.1. The Freedom of Constraints
        2. 4.3.6.2. Combination, Modification, and Creation of Styles and Patterns
      7. 4.3.7. Design Recovery
    4. 4.4. ARCHITECTURAL CONCEPTION IN ABSENCE OF EXPERIENCE: UNPRECEDENTED DESIGN
      1. 4.4.1.
        1. 4.4.1.1. Basic Strategy
        2. 4.4.1.2. Detailed Strategies
        3. 4.4.1.3. Controlling the Design Strategies
    5. 4.5. PUTTING IT ALL TOGETHER: DESIGN PROCESSES REVISITED
      1. 4.5.1. Insights from Requirements
      2. 4.5.2. Insights from Implementation
    6. 4.6. END MATTER
    7. 4.7. REVIEW QUESTIONS
    8. 4.8. EXERCISES
    9. 4.9. FURTHER READING
  11. 5. Connectors
    1. 5.1. CONNECTORS IN ACTION: A MOTIVATING EXAMPLE
    2. 5.2. CONNECTOR FOUNDATIONS
    3. 5.3. CONNECTOR ROLES
      1. 5.3.1.
        1. 5.3.1.1. Communication
        2. 5.3.1.2. Coordination
        3. 5.3.1.3. Conversion
        4. 5.3.1.4. Facilitation
    4. 5.4. CONNECTOR TYPES AND THEIR VARIATION DIMENSIONS
      1. 5.4.1. Procedure Call Connectors
      2. 5.4.2. Event Connectors
      3. 5.4.3. Data Access Connectors
      4. 5.4.4. Linkage Connectors
      5. 5.4.5. Stream Connectors
      6. 5.4.6. Arbitrator Connectors
      7. 5.4.7. Adaptor Connectors
      8. 5.4.8. Distributor Connectors
    5. 5.5. EXAMPLE CONNECTORS
      1. 5.5.1. Event-Based Data Distribution Connectors
      2. 5.5.2. Grid-Based Data Distribution Connectors
      3. 5.5.3. Client-Server—Based Data Distribution Connectors
      4. 5.5.4. P2P-Based Data Distribution Connectors
    6. 5.6. USING THE CONNECTOR FRAMEWORK
      1. 5.6.1. Selecting Appropriate Connectors
      2. 5.6.2. Detecting Mismatches
    7. 5.7. END MATTER
    8. 5.8. REVIEW QUESTIONS
    9. 5.9. EXERCISES
    10. 5.10. FURTHER READING
  12. 6. Modeling
    1. 6.1. MODELING CONCEPTS
      1. 6.1.1. Stakeholder-Driven Modeling
      2. 6.1.2. Basic Architectural Concepts
      3. 6.1.3. Elements of the Architectural Style
      4. 6.1.4. Static and Dynamic Aspects
      5. 6.1.5. Functional and Non-Functional Aspects
    2. 6.2. AMBIGUITY, ACCURACY, AND PRECISION
      1. 6.2.1. Ambiguity
      2. 6.2.2. Accuracy and Precision
    3. 6.3. COMPLEX MODELING: MIXED CONTENT AND MULTIPLE VIEWS
      1. 6.3.1. Views and Viewpoints
      2. 6.3.2. Consistency among Views
    4. 6.4. EVALUATING MODELING TECHNIQUES
    5. 6.5. SPECIFIC MODELING TECHNIQUES
      1. 6.5.1. Generic Techniques
        1. 6.5.1.1. Natural Language
        2. 6.5.1.2. Lunar Lander in Natural Language
        3. 6.5.1.3. Informal Graphical PowerPoint-style Modeling
        4. 6.5.1.4. The Unified Modeling Language (and Its Cousins)
      2. 6.5.2. Early Architecture Description Languages
        1. 6.5.2.1. Darwin
        2. 6.5.2.2. Rapide
        3. 6.5.2.3. Wright
      3. 6.5.3. Domain- and Style-Specific ADLs
        1. 6.5.3.1. Koala
        2. 6.5.3.2. Weaves
        3. 6.5.3.3. The Architecture Analysis and Design Language (AADL)
      4. 6.5.4. Extensible ADLs
        1. 6.5.4.1. Acme
        2. 6.5.4.2. The Architecture Description Markup Language (ADML)
        3. 6.5.4.3. xADL: An Extensible XML-based Architecture Description Language
    6. 6.6. WHEN SYSTEMS BECOME TOO COMPLEX TO MODEL
    7. 6.7. END MATTER
    8. 6.8. REVIEW QUESTIONS
    9. 6.9. EXERCISES
    10. 6.10. FURTHER READING
  13. 7. Visualization
    1. 7.1. VISUALIZATION CONCEPTS
      1. 7.1.1. Canonical Visualizations
      2. 7.1.2. Textual Visualizations
      3. 7.1.3. Graphical Visualizations
      4. 7.1.4. Hybrid Visualizations
      5. 7.1.5. The Relationship between Visualizations and Views
    2. 7.2. EVALUATING VISUALIZATIONS
      1. 7.2.1.
        1. 7.2.1.1. Fidelity
        2. 7.2.1.2. Consistency
        3. 7.2.1.3. Comprehensibility
        4. 7.2.1.4. Dynamism
        5. 7.2.1.5. View Coordination
        6. 7.2.1.6. Aesthetics
        7. 7.2.1.7. Extensibility
      2. 7.2.2. Constructing a Visualization
      3. 7.2.3. Coordinating Visualizations
      4. 7.2.4. Beyond Design: Using Visualization Dynamically
    3. 7.3. COMMON ISSUES IN VISUALIZATION
      1. 7.3.1. Same Symbol, Different Meaning
      2. 7.3.2. Differences without Meaning
      3. 7.3.3. Decorations without Meaning
      4. 7.3.4. Borrowed Symbol, Different Meaning
    4. 7.4. EVALUATING VISUALIZATION TECHNIQUES
    5. 7.5. TECHNIQUES
      1. 7.5.1. Textual Visualizations
      2. 7.5.2. Informal Graphical Editors
      3. 7.5.3. UML: The Unified Modeling Language
      4. 7.5.4. Rapide
      5. 7.5.5. The Labeled Transition State Analyzer (LTSA)
      6. 7.5.6. xADL 2.0
        1. 7.5.6.1. xADLite
        2. 7.5.6.2. ArchEdit
        3. 7.5.6.3. Archipelago
        4. 7.5.6.4. MTAT
    6. 7.6. END MATTER
    7. 7.7. REVIEW QUESTIONS
    8. 7.8. EXERCISES
    9. 7.9. FURTHER READING
  14. 8. Analysis
    1. 8.1. ANALYSIS GOALS
      1. 8.1.1. Completeness
      2. 8.1.2. Consistency
        1. 8.1.2.1. Name Inconsistency
        2. 8.1.2.2. Interface Inconsistency
        3. 8.1.2.3. Behavioral Inconsistency
        4. 8.1.2.4. Interaction Inconsistency
        5. 8.1.2.5. Refinement Inconsistency
      3. 8.1.3. Compatibility
      4. 8.1.4. Correctness
    2. 8.2. SCOPE OF ANALYSIS
      1. 8.2.1. Component- and Connector-Level Analysis
      2. 8.2.2. Subsystem- and System-Level Analysis
      3. 8.2.3. Data Exchanged in the System or Subsystem
      4. 8.2.4. Architectures at Different Abstraction Levels
      5. 8.2.5. Comparison of Two or More Architectures
    3. 8.3. ARCHITECTURAL CONCERN BEING ANALYZED
      1. 8.3.1.
        1. 8.3.1.1. Structural Characteristics
        2. 8.3.1.2. Behavioral Characteristics
        3. 8.3.1.3. Interaction Characteristics
        4. 8.3.1.4. Non-Functional Characteristics
    4. 8.4. LEVEL OF FORMALITY OF ARCHITECTURAL MODELS
      1. 8.4.1.
        1. 8.4.1.1. Informal Models
        2. 8.4.1.2. Semiformal Models
        3. 8.4.1.3. Formal Models
    5. 8.5. TYPE OF ANALYSIS
      1. 8.5.1.
        1. 8.5.1.1. Static Analysis
        2. 8.5.1.2. Dynamic Analysis
        3. 8.5.1.3. Scenario-Based Analysis
    6. 8.6. LEVEL OF AUTOMATION
      1. 8.6.1.
        1. 8.6.1.1. Manual
        2. 8.6.1.2. Partially Automated
        3. 8.6.1.3. Fully Automated
    7. 8.7. SYSTEM STAKEHOLDERS
      1. 8.7.1.
        1. 8.7.1.1. Architects
        2. 8.7.1.2. Developers
        3. 8.7.1.3. Managers
        4. 8.7.1.4. Customers
        5. 8.7.1.5. Vendors
    8. 8.8. ANALYSIS TECHNIQUES
      1. 8.8.1. Inspections and Reviews
        1. 8.8.1.1. ATAM
      2. 8.8.2. Model-Based Analysis
        1. 8.8.2.1. Model-Based Analysis Enabled by ADLs
        2. 8.8.2.2. Reliability Analysis
      3. 8.8.3. Simulation-Based Analysis
        1. 8.8.3.1. XTEAM
    9. 8.9. END MATTER
    10. 8.10. REVIEW QUESTIONS
    11. 8.11. EXERCISES
    12. 8.12. FURTHER READING
  15. 9. Implementation
    1. 9.1. CONCEPTS
      1. 9.1.1. The Mapping Problem
        1. 9.1.1.1. One-Way and Round-Trip Mapping
      2. 9.1.2. Architecture Implementation Frameworks
        1. 9.1.2.1. Same Style, Different Frameworks
      3. 9.1.3. Evaluating Frameworks
        1. 9.1.3.1. Platform Support
        2. 9.1.3.2. Fidelity
        3. 9.1.3.3. Matching Assumptions
        4. 9.1.3.4. Efficiency
        5. 9.1.3.5. Other Considerations
      4. 9.1.4. Middleware, Component Models, and Application Frameworks
        1. 9.1.4.1. How Middleware and Component Frameworks May Induce a Style
        2. 9.1.4.2. Resolving Mismatches between Architectural Styles and Middleware
        3. 9.1.4.3. Using Middleware to Implement Connectors
      5. 9.1.5. Building a New Framework
      6. 9.1.6. Concurrency
      7. 9.1.7. Generative Technologies
      8. 9.1.8. Ensuring Architecture-to-Implementation Consistency
    2. 9.2. EXISTING FRAMEWORKS
      1. 9.2.1. Frameworks for the Pipe-and-Filter Architectural Style
        1. 9.2.1.1. The Standard I/O Framework
        2. 9.2.1.2. The java.io Framework
      2. 9.2.2. Frameworks for the C2 Architectural Style
        1. 9.2.2.1. The Lightweight C2 Framework
        2. 9.2.2.2. The Flexible C2 Framework
        3. 9.2.2.3. Comparing the Lightweight and Flexible C2 Frameworks
    3. 9.3. EXAMPLES
      1. 9.3.1. Implementing Lunar Lander in the Pipe-and-Filter Style Using the java.io Framework
        1. 9.3.1.1. Reflections on the Pipe-and-Filter Lunar Lander Implementation
      2. 9.3.2. Implementing Lunar Lander in the C2-Style Using the Lightweight C2 Framework
    4. 9.4. END MATTER
    5. 9.5. REVIEW QUESTIONS
    6. 9.6. EXERCISES
    7. 9.7. FURTHER READING
  16. 10. Deployment and Mobility
    1. 10.1. OVERVIEW OF DEPLOYMENT AND MOBILITY CHALLENGES
    2. 10.2. SOFTWARE ARCHITECTURE AND DEPLOYMENT
      1. 10.2.1. Basic Concepts
      2. 10.2.2. Deployment Activities
        1. 10.2.2.1. Planning
        2. 10.2.2.2. Modeling
        3. 10.2.2.3. Analysis
        4. 10.2.2.4. Implementation
      3. 10.2.3. Tool Support
    3. 10.3. SOFTWARE ARCHITECTURE AND MOBILITY
      1. 10.3.1. Basic Concepts
      2. 10.3.2. Mobility Paradigms
        1. 10.3.2.1. Remote Evaluation
        2. 10.3.2.2. Code-on-Demand
        3. 10.3.2.3. Mobile Agent
      3. 10.3.3. Challenges in Migrating Code
    4. 10.4. END MATTER
    5. 10.5. REVIEW QUESTIONS
    6. 10.6. EXERCISES
    7. 10.7. FURTHER READING
  17. 11. Applied Architectures and Styles
    1. 11.1. DISTRIBUTED AND NETWORKED ARCHITECTURES
      1. 11.1.1. Limitations of the Distributed Systems Viewpoint
    2. 11.2. ARCHITECTURES FOR NETWORK-BASED APPLICATIONS
      1. 11.2.1. The REpresentational State Transfer Style (REST)
        1. 11.2.1.1. Application Drivers
        2. 11.2.1.2. Derivation of REST
        3. 11.2.1.3. Summary
      2. 11.2.2. Commercial Internet-Scale Applications
        1. 11.2.2.1. Akamai
        2. 11.2.2.2. Google
    3. 11.3. DECENTRALIZED ARCHITECTURES
      1. 11.3.1. Shared Resource Computation: The Grid World
      2. 11.3.2. Peer-to-Peer Styles
        1. 11.3.2.1. Hybrid Client-Server/Peer-to-Peer: Napster
        2. 11.3.2.2. Pure Decentralized P2P: Gnutella
        3. 11.3.2.3. Overlayed P2P: Skype
        4. 11.3.2.4. Resource Trading P2P: BitTorrent
      3. 11.3.3. Summary Notes on Latency and Agency
    4. 11.4. SERVICE-ORIENTED ARCHITECTURES AND WEB SERVICES
    5. 11.5. ARCHITECTURES FROM SPECIFIC DOMAINS
      1. 11.5.1. Robotics
        1. 11.5.1.1. Challenges
        2. 11.5.1.2. Robotic Architectures
      2. 11.5.2. Wireless Sensor Networks
    6. 11.6. END MATTER
    7. 11.7. REVIEW QUESTIONS
    8. 11.8. EXERCISES
    9. 11.9. FURTHER READING
  18. 12. Designing for Non-Functional Properties
    1. 12.1. EFFICIENCY
      1. 12.1.1. Software Components and Efficiency
        1. 12.1.1.1. Keep Components Small
        2. 12.1.1.2. Keep Component Interfaces Simple and Compact
        3. 12.1.1.3. Allow Multiple Interfaces to the Same Functionality
        4. 12.1.1.4. Separate Processing Components from Data
        5. 12.1.1.5. Separate Data from Meta-Data
      2. 12.1.2. Software Connectors and Efficiency
        1. 12.1.2.1. Carefully Select Connectors
        2. 12.1.2.2. Use Broadcast Connectors with Caution
        3. 12.1.2.3. Make Use of Asynchronous Interaction Whenever Possible
        4. 12.1.2.4. Use Location Transparency Judiciously
      3. 12.1.3. Architectural Configurations and Efficiency
        1. 12.1.3.1. Keep Frequently Interacting Components Close
        2. 12.1.3.2. Carefully Select and Place Connectors in the Architecture
        3. 12.1.3.3. Consider the Efficiency Impact of Selected Architectural Styles and Patterns
    2. 12.2. COMPLEXITY
      1. 12.2.1. Software Components and Complexity
        1. 12.2.1.1. Separate Concerns into Different Components
        2. 12.2.1.2. Keep Only the Functionality Inside Components—Not Interaction
        3. 12.2.1.3. Keep Components Cohesive
        4. 12.2.1.4. Be Aware of the Impact of Off-the-Shelf Components on Complexity
        5. 12.2.1.5. Insulate Processing Components from Changes in Data Format
      2. 12.2.2. Software Connectors and Complexity
        1. 12.2.2.1. Treat Connectors Explicitly
        2. 12.2.2.2. Keep Only Interaction Facilities Inside Connectors
        3. 12.2.2.3. Separate Interaction Concerns into Different Connectors
        4. 12.2.2.4. Restrict Interactions Facilitated by Each Connector
        5. 12.2.2.5. Be Aware of the Impact of Off-the-Shelf Connectors on Complexity
      3. 12.2.3. Architectural Configurations and Complexity
        1. 12.2.3.1. Eliminate Unnecessary Dependencies
        2. 12.2.3.2. Manage All Dependencies Explicitly
        3. 12.2.3.3. Use Hierarchical (De)Composition
    3. 12.3. SCALABILITY AND HETEROGENEITY
      1. 12.3.1. Software Components and Scalability
        1. 12.3.1.1. Give Each Component a Single, Clearly Defined Purpose
        2. 12.3.1.2. Give Each Component a Simple, Understandable Interface
        3. 12.3.1.3. Do Not Burden Components with Interaction Responsibilities
        4. 12.3.1.4. Avoid Unnecessary Heterogeneity
        5. 12.3.1.5. Distribute the Data Sources
        6. 12.3.1.6. Replicate Data When Necessary
      2. 12.3.2. Software Connectors and Scalability
        1. 12.3.2.1. Use Explicit Connectors
        2. 12.3.2.2. Give Each Connector a Clearly Defined Responsibility
        3. 12.3.2.3. Choose the Simplest Connector Suited for the Task
        4. 12.3.2.4. Be Aware of Differences Between Direct and Indirect Dependencies
        5. 12.3.2.5. Do Not Place Application Functionality Inside Connectors
        6. 12.3.2.6. Leverage Explicit Connectors to Support Data Scalability
      3. 12.3.3. Architectural Configurations and Scalability
        1. 12.3.3.1. Avoid System Bottlenecks
        2. 12.3.3.2. Make Use of Parallel Processing Capabilities
        3. 12.3.3.3. Place the Data Sources Close to the Data Consumers
        4. 12.3.3.4. Try to Make Distribution Transparent
        5. 12.3.3.5. Use Appropriate Architectural Styles
    4. 12.4. ADAPTABILITY
      1. 12.4.1. Software Components and Adaptability
        1. 12.4.1.1. Give Each Component a Single, Clearly Defined Purpose
        2. 12.4.1.2. Minimize Component Interdependencies
        3. 12.4.1.3. Avoid Burdening Components with Interaction Responsibilities
        4. 12.4.1.4. Separate Processing from Data
        5. 12.4.1.5. Separate Data from Meta-Data
      2. 12.4.2. Software Connectors and Adaptability
        1. 12.4.2.1. Give Each Connector a Clearly Defined Responsibility
        2. 12.4.2.2. Make the Connectors Flexible
        3. 12.4.2.3. Support Connector Composability
        4. 12.4.2.4. Be Aware of Differences Between Direct and Indirect Dependencies
      3. 12.4.3. Architectural Configurations and Adaptability
        1. 12.4.3.1. Leverage Explicit Connectors
        2. 12.4.3.2. Try to Make Distribution Transparent
        3. 12.4.3.3. Use Appropriate Architectural Styles
    5. 12.5. DEPENDABILITY
      1. 12.5.1. Software Components and Dependability
        1. 12.5.1.1. Carefully Control External Component Interdependencies
        2. 12.5.1.2. Provide Reflection Capabilities in Components
        3. 12.5.1.3. Provide Suitable Exception Handling Mechanisms
        4. 12.5.1.4. Specify the Components' Key State Invariants
      2. 12.5.2. Software Connectors and Dependability
        1. 12.5.2.1. Employ Connectors that Strictly Control Component Dependencies
        2. 12.5.2.2. Provide Appropriate Component Interaction Guarantees
        3. 12.5.2.3. Support Dependability Techniques via Advanced Connectors
      3. 12.5.3. Architectural Configurations and Dependability
        1. 12.5.3.1. Avoid Single Points of Failure
        2. 12.5.3.2. Provide Back-Ups of Critical Functionality and Data
        3. 12.5.3.3. Support Nonintrusive System Health Monitoring
        4. 12.5.3.4. Support Dynamic Adaptation
    6. 12.6. END MATTER
    7. 12.7. REVIEW QUESTIONS
    8. 12.8. EXERCISES
    9. 12.9. FURTHER READING
  19. 13. Security and Trust
    1. 13.1. SECURITY
      1. 13.1.1.
        1. 13.1.1.1. Confidentiality
        2. 13.1.1.2. Integrity
        3. 13.1.1.3. Availability
    2. 13.2. DESIGN PRINCIPLES
      1. 13.2.1.
        1. 13.2.1.1. Principle of Least Privilege
        2. 13.2.1.2. Principle of Fail-Safe Defaults
        3. 13.2.1.3. Principle of Economy of Mechanism
        4. 13.2.1.4. Principle of Complete Mediation
        5. 13.2.1.5. Principle of Open Design
        6. 13.2.1.6. Principle of Separation of Privilege
        7. 13.2.1.7. Principle of Least Common Mechanism
        8. 13.2.1.8. Principle of Psychological Acceptability
        9. 13.2.1.9. Principle of Defense in Depth
    3. 13.3. ARCHITECTURAL ACCESS CONTROL
      1. 13.3.1. Access Control Models
        1. 13.3.1.1. Classic Discretionary Access Control
        2. 13.3.1.2. Role-Based Access Control
        3. 13.3.1.3. Mandatory Access Control
      2. 13.3.2. Connector-Centric Architectural Access Control
        1. 13.3.2.1. Basic Concepts
        2. 13.3.2.2. The Central Role of Architectural Connectors
        3. 13.3.2.3. An Algorithm to Check Architectural Access Control
        4. 13.3.2.4. Example: Secure Cooperation
        5. 13.3.2.5. Example: Firefox
    4. 13.4. TRUST MANAGEMENT
      1. 13.4.1. Trust
      2. 13.4.2. Trust Model
      3. 13.4.3. Reputation-Based Systems
        1. 13.4.3.1. eBay
        2. 13.4.3.2. XREP
      4. 13.4.4. Architectural Approach to Decentralized Trust Management
        1. 13.4.4.1. Threats to Decentralized Systems
        2. 13.4.4.2. Measures to Address Threats
        3. 13.4.4.3. Separation of Internal Beliefs and Externally Reported Information
        4. 13.4.4.4. Corresponding Guidelines to Incorporate into an Architectural Style
        5. 13.4.4.5. Resultant Architectural Style
        6. 13.4.4.6. PACE Architectural Style
        7. 13.4.4.7. PACE-Induced Benefits
        8. 13.4.4.8. Building a PACE-Based Trust-Enabled Decentralized File-Sharing Application
    5. 13.5. END MATTER
    6. 13.6. REVIEW QUESTIONS
    7. 13.7. EXERCISES
    8. 13.8. FURTHER READING
  20. 14. Architectural Adaptation
    1. 14.1. CONCEPTS OF ARCHITECTURE-CENTRIC ADAPTATION
      1. 14.1.1. Sources and Motivations for Change
      2. 14.1.2. Shearing Layers
      3. 14.1.3. Structural Elements Subject to Change
        1. 14.1.3.1. Components
        2. 14.1.3.2. Connectors
        3. 14.1.3.3. Configurations
      4. 14.1.4. Change Agents and Context
        1. 14.1.4.1. Motivations, Observations, and Analysis
        2. 14.1.4.2. Timing
        3. 14.1.4.3. Change Agents: Their Identity and Location
        4. 14.1.4.4. Knowledge
        5. 14.1.4.5. Degree of Freedom
      5. 14.1.5. Architecture: The Central Abstraction
    2. 14.2. A CONCEPTUAL FRAMEWORK FOR ARCHITECTURAL ADAPTATION
    3. 14.3. TECHNIQUES FOR SUPPORTING ARCHITECTURE-CENTRIC CHANGE
      1. 14.3.1. Basic Techniques Corresponding to Activities of the Conceptual Framework
        1. 14.3.1.1. Techniques for Observing and Collecting State
        2. 14.3.1.2. Techniques for Analyzing the Data and Planning a Change
        3. 14.3.1.3. Techniques for Deploying Change Descriptions and Modifying the Architecture
        4. 14.3.1.4. An Example: ArchStudio
      2. 14.3.2. Architectures/Styles that Support Adaptation
        1. 14.3.2.1. Interface-Focused Architectural Solutions
        2. 14.3.2.2. (Strong) Architecture-Based Approaches
      3. 14.3.3. The Special Problems of On-the-Fly and Autonomous Adaptation
        1. 14.3.3.1. Determining the Conditions for When to Effect a Change
        2. 14.3.3.2. Management of State
        3. 14.3.3.3. Practical Tips
        4. 14.3.3.4. Autonomous Change
    4. 14.4. END MATTER
    5. 14.5. REVIEW QUESTIONS
    6. 14.6. EXERCISES
    7. 14.7. FURTHER READING
  21. 15. Domain-Specific Software Engineering
    1. 15.1. DOMAIN-SPECIFIC SOFTWARE ENGINEERING IN A NUTSHELL
      1. 15.1.1. Similar Problems, Similar Solutions
      2. 15.1.2. Viewing DSSE Through the Prism of Domain, Business, and Technology
    2. 15.2. DOMAIN-SPECIFIC SOFTWARE ARCHITECTURE
      1. 15.2.1. Domain Knowledge
        1. 15.2.1.1. Domain Dictionary
        2. 15.2.1.2. Information Model
        3. 15.2.1.3. Feature Model
        4. 15.2.1.4. Operational Model
      2. 15.2.2. Canonical Requirements
      3. 15.2.3. Canonical Solution Strategies – Reference Architectures
        1. 15.2.3.1. Developing a Reference Architecture
      4. 15.2.4. Product Lines and Architecture
      5. 15.2.5. Product-Line Concepts
        1. 15.2.5.1. Business Product Lines
        2. 15.2.5.2. Engineering Product Lines
      6. 15.2.6. Specifying the Architecture of a Product Line
        1. 15.2.6.1. Variants
        2. 15.2.6.2. Selection
      7. 15.2.7. Capturing Variations Over Time
      8. 15.2.8. Using Product Lines as Tools for What-If Analysis
      9. 15.2.9. Implementing Product Lines
        1. 15.2.9.1. Product Lines and Source-Code Management Systems
      10. 15.2.10. Unifying Product Architectures with Different Intellectual Heritage
      11. 15.2.11. Organizational Issues in Creating and Managing Product Lines
    3. 15.3. DSSAS, PRODUCT LINES, AND ARCHITECTURAL STYLES
    4. 15.4. DSSE EXAMPLES
      1. 15.4.1. Koala and Consumer Electronics
        1. 15.4.1.1. Optional Required Interfaces
      2. 15.4.2. Software-Defined Radios
    5. 15.5. END MATTER
    6. 15.6. REVIEW QUESTIONS
    7. 15.7. EXERCISES
    8. 15.8. FURTHER READING
  22. 16. Standards
    1. 16.1. WHAT ARE STANDARDS?
      1. 16.1.1. Why Use Standards?
      2. 16.1.2. Drawbacks of Standards
      3. 16.1.3. When to Adopt
    2. 16.2. SPECIFIC STANDARDS
      1. 16.2.1. Conceptual Standards
        1. 16.2.1.1. IEEE 1471
        2. 16.2.1.2. DoDAF: The Department of Defense Architecture Framework
        3. 16.2.1.3. TOGAF: The Open Group Architecture Framework
        4. 16.2.1.4. RM-ODP
      2. 16.2.2. Notational Standards
        1. 16.2.2.1. UML—The Unified Modeling Language
      3. 16.2.3. SysML
      4. 16.2.4. Standard Tools
        1. 16.2.4.1. Standard UML Tools
      5. 16.2.5. Telelogic System Architect
    3. 16.3. PROCESS STANDARDS
      1. 16.3.1. Rational Unified Process
      2. 16.3.2. Model-Driven Architecture
    4. 16.4. END MATTER
    5. 16.5. REVIEW QUESTIONS
    6. 16.6. EXERCISES
    7. 16.7. FURTHER READING
  23. 17. People, Roles, and Teams
    1. 17.1. WHO ARE SOFTWARE ARCHITECTS?
      1. 17.1.1. Architect as a Software Designer
      2. 17.1.2. Architect as a Domain Expert
      3. 17.1.3. Architect as a Software Technologist
      4. 17.1.4. Architect as a Standards Compliance Expert
      5. 17.1.5. Architect as a Software Engineering Economist
      6. 17.1.6. Some Bad Habits
    2. 17.2. WHAT DO SOFTWARE ARCHITECTS DO?
      1. 17.2.1. Develop Project Strategy
      2. 17.2.2. Design Systems
      3. 17.2.3. Communicate with Stakeholders
      4. 17.2.4. Lead
    3. 17.3. HOW DO SOFTWARE ARCHITECTS WORK?
      1. 17.3.1. Balance of Skills
      2. 17.3.2. Allegiance to the Project
      3. 17.3.3. Allegiance to the Organization
      4. 17.3.4. Duration of Involvement
      5. 17.3.5. Team Structure
        1. 17.3.5.1. Flat Model
        2. 17.3.5.2. Hierarchical Model
        3. 17.3.5.3. Matrix Model
    4. 17.4. HOW DO SOFTWARE ARCHITECTS RELATE TO OTHER STAKEHOLDERS?
      1. 17.4.1. Architects and Engineers
      2. 17.4.2. Architects and Managers
      3. 17.4.3. Other Stakeholders
    5. 17.5. REMAINING CHALLENGES
    6. 17.6. END MATTER
    7. 17.7. REVIEW QUESTIONS
    8. 17.8. FURTHER READING
  24. Bibliography

Product information

  • Title: Software Architecture: Foundations, Theory, and Practice
  • Author(s):
  • Release date:
  • Publisher(s): Wiley
  • ISBN: None