book

Software Architecture: Foundations, Theory, and Practice

Name: Software Architecture: Foundations, Theory, and Practice
ISBN: 9780470167748

by Richard N. Taylor, Nenad Medvidovic, Eric M. Dashofy

January 2009

Intermediate to advanced

750 pages

25h 44m

English

Wiley

Read now

Unlock full access

Copyright
About the Cover
THE ARCHITECT'S DREAM, THOMAS COLE, 1840
Credits
Preface
SOFTWARE ARCHITECTURETHE SCOPE OF THE BOOKAudiencesASSUMPTIONS AND BACKGROUNDHOW THE BOOK CAN BE USEDClassroom UsageUse by ProfessionalsTool SupportChapter SummariesChapter 1: The Big IdeaChapter 2: Architectures in Context: The Reorientation of Software EngineeringChapter 3: Basic ConceptsChapter 4: Designing ArchitecturesChapter 5: ConnectorsChapter 6: ModelingChapter 7: VisualizationChapter 8: AnalysisChapter 9: ImplementationChapter 10: Deployment and MobilityChapter 11: Applied Architectures and StylesChapter 12: Designing for Non-Functional PropertiesChapter 13: Security and TrustChapter 14: Architectural AdaptationChapter 15: Domain-Specific Software EngineeringChapter 16: StandardsChapter 17: People, Roles, and Teams
Acknowledgments
About the Authors
1. The Big Idea
1.1. THE POWER OF ANALOGY: THE ARCHITECTURE OF BUILDINGS1.1.1. Limitations of the Analogy1.1.2. So, What's the Big Idea?1.2. THE POWER AND NECESSITY OF BIG IDEAS: THE ARCHITECTURE OF THE WEB1.3. THE POWER OF ARCHITECTURE IN THE SMALL: ARCHITECTURE ON THE DESKTOP1.4. THE POWER OF ARCHITECTURE IN BUSINESS: PRODUCTIVITY AND PRODUCT LINES1.5. END MATTER1.6. REVIEW QUESTIONS1.7. EXERCISES1.8. FURTHER READING
2. Architectures in Context: The Reorientation of Software Engineering
2.1. FUNDAMENTAL UNDERSTANDINGS2.2. REQUIREMENTS2.3. DESIGN2.3.1. Design Techniques2.3.1.1. Object-Oriented Design2.3.1.2. Domain-Specific Software Architectures (DSSAs)2.4. IMPLEMENTATION2.4.1. Implementation Strategies2.5. ANALYSIS AND TESTING2.6. EVOLUTION AND MAINTENANCE2.7. PROCESSES2.7.1. The Turbine Visualization2.7.2. Example Process Depictions2.7.2.1. A Robust Domain-Specific Software Architecture-based Project2.7.2.2. Agile Development2.7.2.3. Other Processes and Process Models2.8. END MATTER2.9. REVIEW QUESTIONS2.10. EXERCISES2.11. FURTHER READING
3. Basic Concepts
3.1. TERMINOLOGY3.1.1. Architecture3.1.1.1. Prescriptive Architecture versus Descriptive Architecture3.1.1.2. Prescriptive and Descriptive Architectures in Action: An Example3.1.1.3. Architectural Degradation3.1.1.4. Architectural Perspectives3.1.2. Component3.1.3. Connector3.1.4. Configuration3.1.5. Architectural Style3.1.6. Architectural Pattern3.2. MODELS3.3. PROCESSES3.4. STAKEHOLDERS3.5. END MATTER3.6. REVIEW QUESTIONS3.7. EXERCISES3.8. FURTHER READING
4. Designing Architectures
4.1. THE DESIGN PROCESS4.2. ARCHITECTURAL CONCEPTION4.2.1. Fundamental Conceptual Tools4.2.1.1. Abstraction and the Simple Machines4.2.1.2. Choosing the Level and Terms of Discourse4.2.1.3. Separation of Concerns4.2.2. The Grand Tool: Refined Experience4.3. REFINED EXPERIENCE IN ACTION: STYLES AND ARCHITECTURAL PATTERNS4.3.1. Domain-Specific Software Architectures4.3.2. Architectural Patterns4.3.2.1. State-Logic-Display (aka. Three-Tier)4.3.2.2. Model-View-Controller (for Graphical User Interfaces)4.3.2.3. Sense-Compute-Control (aka. Sensor-Controller-Actuator)4.3.3. Introduction to Styles4.3.3.1. Peer-to-Peer4.3.4. Simple Styles4.3.4.1. Traditional Language-Influenced Styles4.3.4.2. Layered4.3.4.3. Dataflow Styles4.3.4.4. Shared State4.3.4.5. Interpreter4.3.4.6. Implicit Invocation4.3.4.7. Peer-to-Peer4.3.5. More Complex Styles4.3.5.1. C24.3.5.2. C2 Constraints4.3.5.3. Distributed Objects4.3.6. Discussion: Patterns and Styles4.3.6.1. The Freedom of Constraints4.3.6.2. Combination, Modification, and Creation of Styles and Patterns4.3.7. Design Recovery4.4. ARCHITECTURAL CONCEPTION IN ABSENCE OF EXPERIENCE: UNPRECEDENTED DESIGN4.4.1.4.4.1.1. Basic Strategy4.4.1.2. Detailed Strategies4.4.1.3. Controlling the Design Strategies4.5. PUTTING IT ALL TOGETHER: DESIGN PROCESSES REVISITED4.5.1. Insights from Requirements4.5.2. Insights from Implementation4.6. END MATTER4.7. REVIEW QUESTIONS4.8. EXERCISES4.9. FURTHER READING

5. Connectors
5.1. CONNECTORS IN ACTION: A MOTIVATING EXAMPLE5.2. CONNECTOR FOUNDATIONS5.3. CONNECTOR ROLES5.3.1.5.3.1.1. Communication5.3.1.2. Coordination5.3.1.3. Conversion5.3.1.4. Facilitation5.4. CONNECTOR TYPES AND THEIR VARIATION DIMENSIONS5.4.1. Procedure Call Connectors5.4.2. Event Connectors5.4.3. Data Access Connectors5.4.4. Linkage Connectors5.4.5. Stream Connectors5.4.6. Arbitrator Connectors5.4.7. Adaptor Connectors5.4.8. Distributor Connectors5.5. EXAMPLE CONNECTORS5.5.1. Event-Based Data Distribution Connectors5.5.2. Grid-Based Data Distribution Connectors5.5.3. Client-Server—Based Data Distribution Connectors5.5.4. P2P-Based Data Distribution Connectors5.6. USING THE CONNECTOR FRAMEWORK5.6.1. Selecting Appropriate Connectors5.6.2. Detecting Mismatches5.7. END MATTER5.8. REVIEW QUESTIONS5.9. EXERCISES5.10. FURTHER READING
6. Modeling
6.1. MODELING CONCEPTS6.1.1. Stakeholder-Driven Modeling6.1.2. Basic Architectural Concepts6.1.3. Elements of the Architectural Style6.1.4. Static and Dynamic Aspects6.1.5. Functional and Non-Functional Aspects6.2. AMBIGUITY, ACCURACY, AND PRECISION6.2.1. Ambiguity6.2.2. Accuracy and Precision6.3. COMPLEX MODELING: MIXED CONTENT AND MULTIPLE VIEWS6.3.1. Views and Viewpoints6.3.2. Consistency among Views6.4. EVALUATING MODELING TECHNIQUES6.5. SPECIFIC MODELING TECHNIQUES6.5.1. Generic Techniques6.5.1.1. Natural Language6.5.1.2. Lunar Lander in Natural Language6.5.1.3. Informal Graphical PowerPoint-style Modeling6.5.1.4. The Unified Modeling Language (and Its Cousins)6.5.2. Early Architecture Description Languages6.5.2.1. Darwin6.5.2.2. Rapide6.5.2.3. Wright6.5.3. Domain- and Style-Specific ADLs6.5.3.1. Koala6.5.3.2. Weaves6.5.3.3. The Architecture Analysis and Design Language (AADL)6.5.4. Extensible ADLs6.5.4.1. Acme6.5.4.2. The Architecture Description Markup Language (ADML)6.5.4.3. xADL: An Extensible XML-based Architecture Description Language6.6. WHEN SYSTEMS BECOME TOO COMPLEX TO MODEL6.7. END MATTER6.8. REVIEW QUESTIONS6.9. EXERCISES6.10. FURTHER READING
7. Visualization
7.1. VISUALIZATION CONCEPTS7.1.1. Canonical Visualizations7.1.2. Textual Visualizations7.1.3. Graphical Visualizations7.1.4. Hybrid Visualizations7.1.5. The Relationship between Visualizations and Views7.2. EVALUATING VISUALIZATIONS7.2.1.7.2.1.1. Fidelity7.2.1.2. Consistency7.2.1.3. Comprehensibility7.2.1.4. Dynamism7.2.1.5. View Coordination7.2.1.6. Aesthetics7.2.1.7. Extensibility7.2.2. Constructing a Visualization7.2.3. Coordinating Visualizations7.2.4. Beyond Design: Using Visualization Dynamically7.3. COMMON ISSUES IN VISUALIZATION7.3.1. Same Symbol, Different Meaning7.3.2. Differences without Meaning7.3.3. Decorations without Meaning7.3.4. Borrowed Symbol, Different Meaning7.4. EVALUATING VISUALIZATION TECHNIQUES7.5. TECHNIQUES7.5.1. Textual Visualizations7.5.2. Informal Graphical Editors7.5.3. UML: The Unified Modeling Language7.5.4. Rapide7.5.5. The Labeled Transition State Analyzer (LTSA)7.5.6. xADL 2.07.5.6.1. xADLite7.5.6.2. ArchEdit7.5.6.3. Archipelago7.5.6.4. MTAT7.6. END MATTER7.7. REVIEW QUESTIONS7.8. EXERCISES7.9. FURTHER READING
8. Analysis
8.1. ANALYSIS GOALS8.1.1. Completeness8.1.2. Consistency8.1.2.1. Name Inconsistency8.1.2.2. Interface Inconsistency8.1.2.3. Behavioral Inconsistency8.1.2.4. Interaction Inconsistency8.1.2.5. Refinement Inconsistency8.1.3. Compatibility8.1.4. Correctness8.2. SCOPE OF ANALYSIS8.2.1. Component- and Connector-Level Analysis8.2.2. Subsystem- and System-Level Analysis8.2.3. Data Exchanged in the System or Subsystem8.2.4. Architectures at Different Abstraction Levels8.2.5. Comparison of Two or More Architectures8.3. ARCHITECTURAL CONCERN BEING ANALYZED8.3.1.8.3.1.1. Structural Characteristics8.3.1.2. Behavioral Characteristics8.3.1.3. Interaction Characteristics8.3.1.4. Non-Functional Characteristics8.4. LEVEL OF FORMALITY OF ARCHITECTURAL MODELS8.4.1.8.4.1.1. Informal Models8.4.1.2. Semiformal Models8.4.1.3. Formal Models8.5. TYPE OF ANALYSIS8.5.1.8.5.1.1. Static Analysis8.5.1.2. Dynamic Analysis8.5.1.3. Scenario-Based Analysis8.6. LEVEL OF AUTOMATION8.6.1.8.6.1.1. Manual8.6.1.2. Partially Automated8.6.1.3. Fully Automated8.7. SYSTEM STAKEHOLDERS8.7.1.8.7.1.1. Architects8.7.1.2. Developers8.7.1.3. Managers8.7.1.4. Customers8.7.1.5. Vendors8.8. ANALYSIS TECHNIQUES8.8.1. Inspections and Reviews8.8.1.1. ATAM8.8.2. Model-Based Analysis8.8.2.1. Model-Based Analysis Enabled by ADLs8.8.2.2. Reliability Analysis8.8.3. Simulation-Based Analysis8.8.3.1. XTEAM8.9. END MATTER8.10. REVIEW QUESTIONS8.11. EXERCISES8.12. FURTHER READING
9. Implementation
9.1. CONCEPTS9.1.1. The Mapping Problem9.1.1.1. One-Way and Round-Trip Mapping9.1.2. Architecture Implementation Frameworks9.1.2.1. Same Style, Different Frameworks9.1.3. Evaluating Frameworks9.1.3.1. Platform Support9.1.3.2. Fidelity9.1.3.3. Matching Assumptions9.1.3.4. Efficiency9.1.3.5. Other Considerations9.1.4. Middleware, Component Models, and Application Frameworks9.1.4.1. How Middleware and Component Frameworks May Induce a Style9.1.4.2. Resolving Mismatches between Architectural Styles and Middleware9.1.4.3. Using Middleware to Implement Connectors9.1.5. Building a New Framework9.1.6. Concurrency9.1.7. Generative Technologies9.1.8. Ensuring Architecture-to-Implementation Consistency9.2. EXISTING FRAMEWORKS9.2.1. Frameworks for the Pipe-and-Filter Architectural Style9.2.1.1. The Standard I/O Framework9.2.1.2. The java.io Framework9.2.2. Frameworks for the C2 Architectural Style9.2.2.1. The Lightweight C2 Framework9.2.2.2. The Flexible C2 Framework9.2.2.3. Comparing the Lightweight and Flexible C2 Frameworks9.3. EXAMPLES9.3.1. Implementing Lunar Lander in the Pipe-and-Filter Style Using the java.io Framework9.3.1.1. Reflections on the Pipe-and-Filter Lunar Lander Implementation9.3.2. Implementing Lunar Lander in the C2-Style Using the Lightweight C2 Framework9.4. END MATTER9.5. REVIEW QUESTIONS9.6. EXERCISES9.7. FURTHER READING
10. Deployment and Mobility
10.1. OVERVIEW OF DEPLOYMENT AND MOBILITY CHALLENGES10.2. SOFTWARE ARCHITECTURE AND DEPLOYMENT10.2.1. Basic Concepts10.2.2. Deployment Activities10.2.2.1. Planning10.2.2.2. Modeling10.2.2.3. Analysis10.2.2.4. Implementation10.2.3. Tool Support10.3. SOFTWARE ARCHITECTURE AND MOBILITY10.3.1. Basic Concepts10.3.2. Mobility Paradigms10.3.2.1. Remote Evaluation10.3.2.2. Code-on-Demand10.3.2.3. Mobile Agent10.3.3. Challenges in Migrating Code10.4. END MATTER10.5. REVIEW QUESTIONS10.6. EXERCISES10.7. FURTHER READING
11. Applied Architectures and Styles
11.1. DISTRIBUTED AND NETWORKED ARCHITECTURES11.1.1. Limitations of the Distributed Systems Viewpoint11.2. ARCHITECTURES FOR NETWORK-BASED APPLICATIONS11.2.1. The REpresentational State Transfer Style (REST)11.2.1.1. Application Drivers11.2.1.2. Derivation of REST11.2.1.3. Summary11.2.2. Commercial Internet-Scale Applications11.2.2.1. Akamai11.2.2.2. Google11.3. DECENTRALIZED ARCHITECTURES11.3.1. Shared Resource Computation: The Grid World11.3.2. Peer-to-Peer Styles11.3.2.1. Hybrid Client-Server/Peer-to-Peer: Napster11.3.2.2. Pure Decentralized P2P: Gnutella11.3.2.3. Overlayed P2P: Skype11.3.2.4. Resource Trading P2P: BitTorrent11.3.3. Summary Notes on Latency and Agency11.4. SERVICE-ORIENTED ARCHITECTURES AND WEB SERVICES11.5. ARCHITECTURES FROM SPECIFIC DOMAINS11.5.1. Robotics11.5.1.1. Challenges11.5.1.2. Robotic Architectures11.5.2. Wireless Sensor Networks11.6. END MATTER11.7. REVIEW QUESTIONS11.8. EXERCISES11.9. FURTHER READING
12. Designing for Non-Functional Properties
12.1. EFFICIENCY12.1.1. Software Components and Efficiency12.1.1.1. Keep Components Small12.1.1.2. Keep Component Interfaces Simple and Compact12.1.1.3. Allow Multiple Interfaces to the Same Functionality12.1.1.4. Separate Processing Components from Data12.1.1.5. Separate Data from Meta-Data12.1.2. Software Connectors and Efficiency12.1.2.1. Carefully Select Connectors12.1.2.2. Use Broadcast Connectors with Caution12.1.2.3. Make Use of Asynchronous Interaction Whenever Possible12.1.2.4. Use Location Transparency Judiciously12.1.3. Architectural Configurations and Efficiency12.1.3.1. Keep Frequently Interacting Components Close12.1.3.2. Carefully Select and Place Connectors in the Architecture12.1.3.3. Consider the Efficiency Impact of Selected Architectural Styles and Patterns12.2. COMPLEXITY12.2.1. Software Components and Complexity12.2.1.1. Separate Concerns into Different Components12.2.1.2. Keep Only the Functionality Inside Components—Not Interaction12.2.1.3. Keep Components Cohesive12.2.1.4. Be Aware of the Impact of Off-the-Shelf Components on Complexity12.2.1.5. Insulate Processing Components from Changes in Data Format12.2.2. Software Connectors and Complexity12.2.2.1. Treat Connectors Explicitly12.2.2.2. Keep Only Interaction Facilities Inside Connectors12.2.2.3. Separate Interaction Concerns into Different Connectors12.2.2.4. Restrict Interactions Facilitated by Each Connector12.2.2.5. Be Aware of the Impact of Off-the-Shelf Connectors on Complexity12.2.3. Architectural Configurations and Complexity12.2.3.1. Eliminate Unnecessary Dependencies12.2.3.2. Manage All Dependencies Explicitly12.2.3.3. Use Hierarchical (De)Composition12.3. SCALABILITY AND HETEROGENEITY12.3.1. Software Components and Scalability12.3.1.1. Give Each Component a Single, Clearly Defined Purpose12.3.1.2. Give Each Component a Simple, Understandable Interface12.3.1.3. Do Not Burden Components with Interaction Responsibilities12.3.1.4. Avoid Unnecessary Heterogeneity12.3.1.5. Distribute the Data Sources12.3.1.6. Replicate Data When Necessary12.3.2. Software Connectors and Scalability12.3.2.1. Use Explicit Connectors12.3.2.2. Give Each Connector a Clearly Defined Responsibility12.3.2.3. Choose the Simplest Connector Suited for the Task12.3.2.4. Be Aware of Differences Between Direct and Indirect Dependencies12.3.2.5. Do Not Place Application Functionality Inside Connectors12.3.2.6. Leverage Explicit Connectors to Support Data Scalability12.3.3. Architectural Configurations and Scalability12.3.3.1. Avoid System Bottlenecks12.3.3.2. Make Use of Parallel Processing Capabilities12.3.3.3. Place the Data Sources Close to the Data Consumers12.3.3.4. Try to Make Distribution Transparent12.3.3.5. Use Appropriate Architectural Styles12.4. ADAPTABILITY12.4.1. Software Components and Adaptability12.4.1.1. Give Each Component a Single, Clearly Defined Purpose12.4.1.2. Minimize Component Interdependencies12.4.1.3. Avoid Burdening Components with Interaction Responsibilities12.4.1.4. Separate Processing from Data12.4.1.5. Separate Data from Meta-Data12.4.2. Software Connectors and Adaptability12.4.2.1. Give Each Connector a Clearly Defined Responsibility12.4.2.2. Make the Connectors Flexible12.4.2.3. Support Connector Composability12.4.2.4. Be Aware of Differences Between Direct and Indirect Dependencies12.4.3. Architectural Configurations and Adaptability12.4.3.1. Leverage Explicit Connectors12.4.3.2. Try to Make Distribution Transparent12.4.3.3. Use Appropriate Architectural Styles12.5. DEPENDABILITY12.5.1. Software Components and Dependability12.5.1.1. Carefully Control External Component Interdependencies12.5.1.2. Provide Reflection Capabilities in Components12.5.1.3. Provide Suitable Exception Handling Mechanisms12.5.1.4. Specify the Components' Key State Invariants12.5.2. Software Connectors and Dependability12.5.2.1. Employ Connectors that Strictly Control Component Dependencies12.5.2.2. Provide Appropriate Component Interaction Guarantees12.5.2.3. Support Dependability Techniques via Advanced Connectors12.5.3. Architectural Configurations and Dependability12.5.3.1. Avoid Single Points of Failure12.5.3.2. Provide Back-Ups of Critical Functionality and Data12.5.3.3. Support Nonintrusive System Health Monitoring12.5.3.4. Support Dynamic Adaptation12.6. END MATTER12.7. REVIEW QUESTIONS12.8. EXERCISES12.9. FURTHER READING
13. Security and Trust
13.1. SECURITY13.1.1.13.1.1.1. Confidentiality13.1.1.2. Integrity13.1.1.3. Availability13.2. DESIGN PRINCIPLES13.2.1.13.2.1.1. Principle of Least Privilege13.2.1.2. Principle of Fail-Safe Defaults13.2.1.3. Principle of Economy of Mechanism13.2.1.4. Principle of Complete Mediation13.2.1.5. Principle of Open Design13.2.1.6. Principle of Separation of Privilege13.2.1.7. Principle of Least Common Mechanism13.2.1.8. Principle of Psychological Acceptability13.2.1.9. Principle of Defense in Depth13.3. ARCHITECTURAL ACCESS CONTROL13.3.1. Access Control Models13.3.1.1. Classic Discretionary Access Control13.3.1.2. Role-Based Access Control13.3.1.3. Mandatory Access Control13.3.2. Connector-Centric Architectural Access Control13.3.2.1. Basic Concepts13.3.2.2. The Central Role of Architectural Connectors13.3.2.3. An Algorithm to Check Architectural Access Control13.3.2.4. Example: Secure Cooperation13.3.2.5. Example: Firefox13.4. TRUST MANAGEMENT13.4.1. Trust13.4.2. Trust Model13.4.3. Reputation-Based Systems13.4.3.1. eBay13.4.3.2. XREP13.4.4. Architectural Approach to Decentralized Trust Management13.4.4.1. Threats to Decentralized Systems13.4.4.2. Measures to Address Threats13.4.4.3. Separation of Internal Beliefs and Externally Reported Information13.4.4.4. Corresponding Guidelines to Incorporate into an Architectural Style13.4.4.5. Resultant Architectural Style13.4.4.6. PACE Architectural Style13.4.4.7. PACE-Induced Benefits13.4.4.8. Building a PACE-Based Trust-Enabled Decentralized File-Sharing Application13.5. END MATTER13.6. REVIEW QUESTIONS13.7. EXERCISES13.8. FURTHER READING
14. Architectural Adaptation
14.1. CONCEPTS OF ARCHITECTURE-CENTRIC ADAPTATION14.1.1. Sources and Motivations for Change14.1.2. Shearing Layers14.1.3. Structural Elements Subject to Change14.1.3.1. Components14.1.3.2. Connectors14.1.3.3. Configurations14.1.4. Change Agents and Context14.1.4.1. Motivations, Observations, and Analysis14.1.4.2. Timing14.1.4.3. Change Agents: Their Identity and Location14.1.4.4. Knowledge14.1.4.5. Degree of Freedom14.1.5. Architecture: The Central Abstraction14.2. A CONCEPTUAL FRAMEWORK FOR ARCHITECTURAL ADAPTATION14.3. TECHNIQUES FOR SUPPORTING ARCHITECTURE-CENTRIC CHANGE14.3.1. Basic Techniques Corresponding to Activities of the Conceptual Framework14.3.1.1. Techniques for Observing and Collecting State14.3.1.2. Techniques for Analyzing the Data and Planning a Change14.3.1.3. Techniques for Deploying Change Descriptions and Modifying the Architecture14.3.1.4. An Example: ArchStudio14.3.2. Architectures/Styles that Support Adaptation14.3.2.1. Interface-Focused Architectural Solutions14.3.2.2. (Strong) Architecture-Based Approaches14.3.3. The Special Problems of On-the-Fly and Autonomous Adaptation14.3.3.1. Determining the Conditions for When to Effect a Change14.3.3.2. Management of State14.3.3.3. Practical Tips14.3.3.4. Autonomous Change14.4. END MATTER14.5. REVIEW QUESTIONS14.6. EXERCISES14.7. FURTHER READING
15. Domain-Specific Software Engineering
15.1. DOMAIN-SPECIFIC SOFTWARE ENGINEERING IN A NUTSHELL15.1.1. Similar Problems, Similar Solutions15.1.2. Viewing DSSE Through the Prism of Domain, Business, and Technology15.2. DOMAIN-SPECIFIC SOFTWARE ARCHITECTURE15.2.1. Domain Knowledge15.2.1.1. Domain Dictionary15.2.1.2. Information Model15.2.1.3. Feature Model15.2.1.4. Operational Model15.2.2. Canonical Requirements15.2.3. Canonical Solution Strategies – Reference Architectures15.2.3.1. Developing a Reference Architecture15.2.4. Product Lines and Architecture15.2.5. Product-Line Concepts15.2.5.1. Business Product Lines15.2.5.2. Engineering Product Lines15.2.6. Specifying the Architecture of a Product Line15.2.6.1. Variants15.2.6.2. Selection15.2.7. Capturing Variations Over Time15.2.8. Using Product Lines as Tools for What-If Analysis15.2.9. Implementing Product Lines15.2.9.1. Product Lines and Source-Code Management Systems15.2.10. Unifying Product Architectures with Different Intellectual Heritage15.2.11. Organizational Issues in Creating and Managing Product Lines15.3. DSSAS, PRODUCT LINES, AND ARCHITECTURAL STYLES15.4. DSSE EXAMPLES15.4.1. Koala and Consumer Electronics15.4.1.1. Optional Required Interfaces15.4.2. Software-Defined Radios15.5. END MATTER15.6. REVIEW QUESTIONS15.7. EXERCISES15.8. FURTHER READING
16. Standards
16.1. WHAT ARE STANDARDS?16.1.1. Why Use Standards?16.1.2. Drawbacks of Standards16.1.3. When to Adopt16.2. SPECIFIC STANDARDS16.2.1. Conceptual Standards16.2.1.1. IEEE 147116.2.1.2. DoDAF: The Department of Defense Architecture Framework16.2.1.3. TOGAF: The Open Group Architecture Framework16.2.1.4. RM-ODP16.2.2. Notational Standards16.2.2.1. UML—The Unified Modeling Language16.2.3. SysML16.2.4. Standard Tools16.2.4.1. Standard UML Tools16.2.5. Telelogic System Architect16.3. PROCESS STANDARDS16.3.1. Rational Unified Process16.3.2. Model-Driven Architecture16.4. END MATTER16.5. REVIEW QUESTIONS16.6. EXERCISES16.7. FURTHER READING
17. People, Roles, and Teams
17.1. WHO ARE SOFTWARE ARCHITECTS?17.1.1. Architect as a Software Designer17.1.2. Architect as a Domain Expert17.1.3. Architect as a Software Technologist17.1.4. Architect as a Standards Compliance Expert17.1.5. Architect as a Software Engineering Economist17.1.6. Some Bad Habits17.2. WHAT DO SOFTWARE ARCHITECTS DO?17.2.1. Develop Project Strategy17.2.2. Design Systems17.2.3. Communicate with Stakeholders17.2.4. Lead17.3. HOW DO SOFTWARE ARCHITECTS WORK?17.3.1. Balance of Skills17.3.2. Allegiance to the Project17.3.3. Allegiance to the Organization17.3.4. Duration of Involvement17.3.5. Team Structure17.3.5.1. Flat Model17.3.5.2. Hierarchical Model17.3.5.3. Matrix Model17.4. HOW DO SOFTWARE ARCHITECTS RELATE TO OTHER STAKEHOLDERS?17.4.1. Architects and Engineers17.4.2. Architects and Managers17.4.3. Other Stakeholders17.5. REMAINING CHALLENGES17.6. END MATTER17.7. REVIEW QUESTIONS17.8. FURTHER READING
Bibliography

Content preview from Software Architecture: Foundations, Theory, and Practice

Chapter 12. Designing for Non-Functional Properties

Engineering software systems so that they satisfy all their myriad functional requirements is difficult. As we have seen so far, software architectures can help in that task through effective compositions of well-defined components and connectors, which have been verified to adhere to the necessary structural, behavioral, and interaction constraints. While satisfying functional requirements is essential, unfortunately it is not sufficient. Software developers must also provide for non-functional properties (NFPs) of software systems.

Definition. A non-functional property (NFP) of a software system is a constraint on the manner in which the system implements and delivers its functionality.

Important NFPs of software systems include security, reliability, availability, efficiency, scalability, and fault-tolerance. For example, in the case of the Lunar Lander system discussed throughout this book, the efficiency NFP may be characterized as the constraint that the system must respond to navigation commands within a specific, very short time span; the reliability NFP may be characterized as the constraint that the system may not be in a specified failure state longer than a specific time span.

Software engineering methodology lays stress on doing the correct things from the very beginning of the software development process in order to curb development and maintenance costs. In particular, the emergence of the study of software architecture ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Software Architecture in Practice, Third Edition

Publisher Resources

ISBN: 9780470167748Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages