Software Architecture: A Case Based Approach

Table of contents

1. Copyright
   1. Dedication
2.  
3. Foreword
4. Preface
   1. About Case Study Methodology
   2. How Did Each Case Study Come Up?
   3. Organization of the Book
   4. About Fact-Tree
5. Acknowledgements
6. About the Author
7. 1. Software Architecture Primer
   1. The Discipline of Software Architecture
      1. The Rise and Fall of Netscape (or the Browser War 1994–1999)
      2. The Growing Demands on Software Development
   2. What Is Software Architecture?
   3. The Importance of Software Architecture
   4. Role of a Software Architect
   5. Some Important Terms Used in Software Architecture
      1. Component
         1. Component-Based Development (CBD)
         2. Component-Based Software Engineering (CBSE)
         3. Commercial Off-the-Shelf (COTS) Systems
      2. Relation
      3. Model
      4. Framework
      5. Architectural View
      6. Viewpoint
   6. Software Architecture Concepts
      1. Types of Architectures
         1. Enterprise Architecture
         2. Systems architecture
         3. Software Architecture
         4. Technical Architecture
         5. Data Architecture
         6. Reference Architecture
         7. Product Line Architecture
      2. Architectural Drivers
      3. Software Architecture Frameworks
         1. The Zachman Framework
      4. The Open Group Architecture Framework (TOGAF[2])
         1. Phase A: Architecture Vision
         2. Phase B: Business Architecture
         3. Phase C: Information System Architecture
         4. Phase D: Technology Architecture
         5. Phase E: Opportunities and Solutions
         6. Phase F: Migration Planning
         7. Phase G: Implementation Governance
         8. Phase H: Architecture Change Management
      5. Reference Model for Open Distributed Processing (RM-ODP)
         1. The 4+1 View Model
         2. Viewpoint Languages: Notations
         3. Rational Unified Process (RUP)
         4. Architectural Styles or Architectural Patterns
      6. Pipes and Filters
      7. Blackboard
      8. Layered Abstract Machines
      9. N-Tier Architectures
      10. Distributed Peer-to-Peer Systems
      11. Anti-patterns
   7. Software Architecture as a Problem-Solving Activity
      1. Polya’s How to Solve It—A Problem-Solving Guide
      2. Systems Thinking Approach to Problem Solving
         1. Systems Principles
         2. Systems Methodology of Problem Solving
   8. Notes
   9. Further Reading
8. 2. Where Is the Architecture? Story of a Sick Health Insurance Application
   1. Background
   2. Postmortem
   3. Why Is Software Architecture Important?
      1. Communication
   4. Role of Architecture in Software Development
      1. Understanding the Domain Requirements
      2. Developing (Selecting) the Architecture
      3. Representing and Communicating the Architecture
      4. Analysing or Evaluating the Architecture
   5. The Use Case Analysis
      1. Objectives of Use Case Analysis
      2. Use Case Analysis Activity
   6. The Technical Process of Designing Architectures
      1. Architectural Requirements
      2. System Structuring or Designing the Architecture
      3. Architecture Review and Validation
      4. Iterations
   7. Case Analysis
      1. Understanding Domain Requirements and Architectural Requirements
         1. Use Case: Enroll Insured
         2. Use Case: Get Insured
         3. Use Case: Check Eligibility
         4. Use Case: Change Insured
         5. Use Case: Calculate Premium
         6. Use Case: Pay Online
         7. Use Case: Manage Insured
         8. Use Case: Issue Letters
         9. Use Case: Generate Reports
         10. Use Case: Manage Billing and Accounts
         11. Use Case: Manage Users
         12. Use Case: Login
      2. Structure Various Sub-systems to Come Up with Initial Architecture
      3. Identifying Domain Expert
         1. Role of a Client
         2. Role of MidAlliance
   8. Conclusions
   9. Best Practices and Key Lessons from the Case Study
   10. Further Reading
9. 3. Refining and Re-factoring Architecture—Story of McCombbs Call Centre
   1. Background
   2. Postmortem
   3. Software Architecture Goals and Drivers
   4. Software Architecture Patterns and Anti-patterns
      1. MVC Architecture
      2. Anti-patterns
      3. Re-factoring
   5. Performance-Oriented Design
      1. Performance Objectives
      2. Performance Improvement
      3. Understanding Architecture
      4. Identifying Key Scenarios
      5. Identifying Problem Areas or Bottlenecks
         1. Asking questions
         2. Performance modelling
         3. Using architecture anti-patterns
         4. Performance review of the system
      6. Refining the System
   6. Case Analysis
      1. Step 1: 4 + 1 View Model of the Proposed Architecture
         1. Use case view
         2. Logical view
         3. Process view
         4. Implementation view
         5. Deployment view
      2. Step 2: Prepare for the Evaluation
      3. Step 3: Execute the Evaluation
         1. Evaluating performance
      4. Step 4: Reflect the Evaluation
   7. Conclusions
   8. Best Practices and Key Lessons from the Case Study
   9. Notes
   10. Further Reading
10. 4. Architecture Evaluation—Developing a Futuristic Travel Search Engine
    1. Background
       1. What Is Architectural Evaluation?
       2. Why Should Architecture Be Evaluated and Reviewed?
       3. When to Evaluate and Review?
       4. Who Should Evaluate and Review?
       5. What Should Be Reviewed?
       6. How to Review Architectures?
    2. Postmortem
       1. Techniques for Evaluation and Review
       2. A Review Method for Architectural Description and Architecting Process
          1. The review method
          2. Scenario-based Review Methods
    3. Case Analysis
       1. Which Method to Use?
       2. Software Architecture Analysis Method
          1. Prerequisites and inputs
          2. Steps in the evaluation process
          3. Step 1—Develop scenarios
          4. Step 2—Describe architecture(s)
          5. Step 3—Classify and prioritize scenarios
          6. Step 4—Individually evaluate indirect scenarios
          7. Step 5—Assess scenario interaction
          8. Step 6—Create an overall evaluation
          9. Increasing the effectiveness of your review
          10. Generate a quality attribute utility tree
          11. Use quality attribute taxonomies
          12. Identify risks, sensitivity points and trade-offs
    4. Conclusions
    5. Best Practices and Key Lessons from the Case Study
    6. Further Reading
11. 5. Moving from Software Architecture to Software Design—Building a Mobile Trading System
    1. Background
       1. What Is Design?
       2. Design Notations
    2. Postmortem
       1. The Design Process
       2. Moving from Architecture to Design
       3. Step 1: Defining System Context
       4. Step 2: Identifying the Modules
       5. Step 3: Describing the Components and Connectors
       6. Characteristics of a Good Design
    3. Case Analysis
       1. Use Case Specification
       2. Sequence Diagrams
       3. Class Diagrams
    4. Conclusions
    5. Best Practices and Key Lessons from the Case Study
    6. Further Reading
12. 6. Component-based Development: Portal of Universal Bank
    1. Background
       1. Why Component-based Development?
       2. Origin of CBD
          1. Commercial-off-the-Shelf Components
          2. Open Systems
       3. Some Examples of Cost of ‘From the Scratch’ Development
          1. Netscape browser rewrite
          2. Microsoft Vista (earlier code named as Longhorn)
          3. Firefox browser
    2. Postmortem
    3. The Component-based Development Approach
       1. How Different is the CBD Approach?
       2. Developer (Producer) and Consumer Perspectives on CBD
       3. Why CBD—Cost and Use
    4. Success Factors of CBD
    5. Challenges to Adopting CBD
       1. Inconsistent Component Integration
       2. Component Mismatches
          1. How to avoid mismatches
          2. What to do in case of a mismatch
          3. Techniques for repairing mismatched interfaces
    6. Conclusions
    7. Best Practices and Key Lessons from the Case Study
    8. Further Reading
13. 7. Emerging Trends in Software Architecture
    1. Software Architecture Discipline—Past, Present and Future
       1. Next-Generation Systems
    2. Reusability and Reusable Services
       1. Reuse Maturity Levels Needed in an Organization
       2. Software as a Service
          1. Need for frequent updates
          2. Provide secured environment
          3. Drive for reduced total cost of operation
    3. Service-Oriented Architecture
       1. Challenges in Implementing SOA
       2. Web Services
       3. SOA and Web Services
       4. Grid Computing
          1. Service-Oriented Grids
       5. Enterprise Service Bus
       6. Business Trends
    4. Dimensions of Future Software Architecture
       1. Codification and Socialization
       2. Handling Quality Attributes
       3. Architectural Automation
       4. Architectural Responsibility
       5. Accidental versus Intentional Architects
       6. Domain Versatility and Adaptability
       7. Technology Dependency
       8. Inter-disciplinary Architecture
    5. Critical Software Architecture Elements
       1. Criticality of Serviceability
       2. Criticality of Adaptability
       3. Criticality of Productivity
       4. Software Service Lines or Service Line Architectures
    6. Conclusions
    7. Further Reading
14. References