Available:*
Library | Item Barcode | Call Number | Material Type | Item Category 1 | Status |
---|---|---|---|---|---|
Searching... | 30000010341622 | QA76.9.A73 S29 2015 | Open Access Book | Book | Searching... |
On Order
Summary
Summary
Modern-day projects require software and systems engineers to work together in realizing architectures of large and complex software-intensive systems. To date, the two have used their own tools and methods to deal with similar issues when it comes to the requirements, design, testing, maintenance, and evolution of these architectures.
Software and Systems Architecture in Action explores practices that can be helpful in the development of architectures of large-scale systems in which software is a major component. Examining the synergies that exist between the disciplines of software and systems engineering, it presents concepts, techniques, and methods for creating and documenting architectures.
The book describes an approach to architecture design that is driven from systemic quality attributes determined from both the business and technical goals of the system, rather than just its functional requirements. This architecture-centric design approach utilizes analytically derived patterns and tactics for quality attributes that inform the architect's design choices and help shape the architecture of a given system.
The book includes coverage of techniques used to assess the impact of architecture-centric design on the structural complexity of a system. After reading the book, you will understand how to create architectures of systems and assess their ability to meet the business goals of your organization.
Ideal for anyone involved with large and complex software-intensive systems, the book details powerful methods for engaging the software and systems engineers on your team. The book is also suitable for use in undergraduate and graduate-level courses on software and systems architecture as it exposes students to the concepts and techniques used to create and manage architectures of software-intensive systems.
Author Notes
Raghvinder (Raghu) Sangwan is an associate professor of software engineering at Pennsylvania State University. His work involves design and development of software systems, their architecture, and automatic and semiautomatic approaches to assess their design and code quality. He has published several papers in these areas. Prior to joining the Pennsylvania State University, Raghu was a software architect at Siemens, where he worked on large-scale systems in the domains of health care, automation, transportation, and mining; many of these systems were developed by teams geographically distributed around the world. This experience resulted in his coauthoring the Global Software Development Handbook and co-organizing the first International Conference on Global Software Engineering (ICGSE 2006), sponsored by the Institute for Electrical and Electronics Engineers (IEEE). He also holds a visiting scientist appointment at the Software Engineering Institute at Carnegie Mellon University. He received his PhD in computer and information sciences from Temple University and is a senior member of IEEE and the Association for Computing Machinery (ACM).
Table of Contents
Preface | p. xi |
About the Author | p. xv |
1 Architecture and Its Significance | p. 1 |
1.1 Introduction | p. 1 |
1.2 Rising Complexity | p. 2 |
1.3 Constant Change | p. 7 |
1.4 Distributed Development | p. 9 |
1.5 Practice for Architecture-Centric Engineering | p. 12 |
1.6 Summary | p. 16 |
1.7 Questions | p. 17 |
References | p. 17 |
2 Stakeholders and Their Business Goals | p. 19 |
2.1 Introduction | p. 19 |
2.2 Influence of Business Goals on the Architecture | p. 20 |
2.3 Representing Business Goals | p. 23 |
2.4 Refining Business Goals | p. 26 |
2.5 Translating Engineering Objectives into Architectural Requirements | p. 27 |
2.6 Prioritizing Architectural Requirements | p. 33 |
2.7 Summary | p. 34 |
2.8 Questions | p. 36 |
References | p. 37 |
3 Establishing Broad Functional Understanding | p. 39 |
3.1 Introduction | p. 39 |
3.2 System Context | p. 40 |
3.3 System Use Cases | p. 41 |
3.4 Domain Model | p. 45 |
3.5 An End-to-End Operational View | p. 47 |
3.6 Constraints | p. 52 |
3.7 Summary | p. 54 |
3.8 Questions | p. 55 |
References | p. 55 |
4 Getting Ready for Designing the Architecture | p. 57 |
4.1 Introduction | p. 57 |
4.2 Architectural Drivers | p. 59 |
4.3 Patterns | p. 61 |
4.3.1 Layered View | p. 64 |
4.3.2 Data Flow View | p. 67 |
4.3.3 Data-Centered View | p. 69 |
4.3.4 Adaptation View | p. 71 |
4.3.5 Language Extension View | p. 72 |
4.3.6 User Interaction View | p. 75 |
4.3.7 Component Interaction View | p. 77 |
4.3.8 Distribution View | p. 79 |
4.4 What Is a Tactic? | p. 81 |
4.4.1 Tactics for Availability | p. 82 |
4.4.2 Tactics for Interoperability | p. 85 |
4.4.3 Tactics for Modifiabiliiy | p. 87 |
4.4.4 Tactics for Performance | p. 90 |
4.4.5 Tactics for Security | p. 92 |
4.4.6 Tactics for Testability | p. 94 |
4.4.7 Tactics for Usability | p. 95 |
4.5 Summary | p. 96 |
4.6 Questions | p. 97 |
References | p. 98 |
5 Creating the Architecture | p. 101 |
5.1 Introduction | p. 101 |
5.2 Architecture of the Building Automation System | p. 103 |
5.2.1 Support for Adding New Field Devices | p. 106 |
5.2.2 Addressing Latency and Load Conditions | p. 110 |
5.2.3 Addressing International Language Support | p. 113 |
5.3 Architécture Trade-Offs | p. 116 |
5.3.1 Revisiting Modifiability Drivers | p. 116 |
5.3.2 Revisiting Performance Drivers | p. 118 |
5.4 The Final Architecture | p. 120 |
5.5 Summary | p. 120 |
5.6 Questions | p. 122 |
References | p. 127 |
6 Communicating the Architecture | p. 129 |
6.1 Introduction | p. 129 |
6.2 Views as a Basis for Documentation | p. 130 |
6.3 Documenting a View | p. 131 |
6.4 Building an Architecture Description Document | p. 132 |
6.5 Architecture Description for the Building Automation System | p. 133 |
6.5.1 Section 1: Document Road Map | p. 133 |
6.5.1.1 Section 1.1: Description of the Architecture Documentation | p. 133 |
6.5.1.2 Section 1.2: How Stakeholders Can Use the Documentation | p. 134 |
6.5.2 Section 2: System Overview | p. 136 |
6.5.2.1 Section 24: Business Goals | p. 136 |
6.5.2.2 Section 2.2: System Context | p. 137 |
6.5.2.3 Section 2.3: Functions | p. 140 |
6.5.2.4 Section 2.4: Quality Attribute Requirements | p. 142 |
6.5.2.5 Section 2.5: Constraints | p. 143 |
6.5.2.6 Section 2.6: Architectural Drivers | p. 143 |
6.5.3 Section 3: View Template | p. 145 |
6.5.4 Section 4: Views | p. 145 |
6.5.4.1 Section 4.1: Module View | p. 145 |
6.5.4.2 Section 4.2: Component-and-Connector View | p. 146 |
6.5.4.3 Section 4.3: Deployment View | p. 155 |
6.5.5 Section 5: Mapping between Views | p. 157 |
6.5.6 Section 6: Rationale | p. 160 |
6.6 Conclusions | p. 160 |
6.7 Questions | p. 162 |
References | p. 162 |
7 Architecture and Detailed Design | p. 163 |
7.1 Introduction | p. 163 |
7.2 Defining Interfaces | p. 164 |
7.3 Creating the Domain Object Model | p. 164 |
7.3 The Rule Manager | p. 167 |
7.3.1 Addressing Architectural Responsibilities | p. 169 |
7.3.2 Addressing Functional Responsibilities | p. 174 |
7.4 Summary | p. 174 |
7.5 Question | p. 177 |
References | p. 177 |
8 Role of Architecture in Managing Structural Complexity | p. 179 |
8.1 Introduction | p. 179 |
8.2 Analyzing System Complexity | p. 180 |
8.2.1 Partitioning a DSM | p. 182 |
8.2.2 Partitioning Algorithms | p. 184 |
8.2.3 Tearing a DSM | p. 186 |
8.3 Managing Structural Complexity | p. 189 |
8.3.1 Testing the Hypothesis | p. 190 |
8.4 Discussion and Conclusions | p. 196 |
8.5 Discussion Questions | p. 197 |
References | p. 198 |
Index | p. 201 |