Cover image for Software and systems architecture in action
Title:
Software and systems architecture in action
Personal Author:
Series:
Auerbach series on applied software engineering
Publication Information:
Boca Raton : Taylor & Francis, 2015.
Physical Description:
xv, 216 pages : illustrations ; 24 cm.
ISBN:
9781439849163
General Note:
"A CRC title."

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

Prefacep. xi
About the Authorp. xv
1 Architecture and Its Significancep. 1
1.1 Introductionp. 1
1.2 Rising Complexityp. 2
1.3 Constant Changep. 7
1.4 Distributed Developmentp. 9
1.5 Practice for Architecture-Centric Engineeringp. 12
1.6 Summaryp. 16
1.7 Questionsp. 17
Referencesp. 17
2 Stakeholders and Their Business Goalsp. 19
2.1 Introductionp. 19
2.2 Influence of Business Goals on the Architecturep. 20
2.3 Representing Business Goalsp. 23
2.4 Refining Business Goalsp. 26
2.5 Translating Engineering Objectives into Architectural Requirementsp. 27
2.6 Prioritizing Architectural Requirementsp. 33
2.7 Summaryp. 34
2.8 Questionsp. 36
Referencesp. 37
3 Establishing Broad Functional Understandingp. 39
3.1 Introductionp. 39
3.2 System Contextp. 40
3.3 System Use Casesp. 41
3.4 Domain Modelp. 45
3.5 An End-to-End Operational Viewp. 47
3.6 Constraintsp. 52
3.7 Summaryp. 54
3.8 Questionsp. 55
Referencesp. 55
4 Getting Ready for Designing the Architecturep. 57
4.1 Introductionp. 57
4.2 Architectural Driversp. 59
4.3 Patternsp. 61
4.3.1 Layered Viewp. 64
4.3.2 Data Flow Viewp. 67
4.3.3 Data-Centered Viewp. 69
4.3.4 Adaptation Viewp. 71
4.3.5 Language Extension Viewp. 72
4.3.6 User Interaction Viewp. 75
4.3.7 Component Interaction Viewp. 77
4.3.8 Distribution Viewp. 79
4.4 What Is a Tactic?p. 81
4.4.1 Tactics for Availabilityp. 82
4.4.2 Tactics for Interoperabilityp. 85
4.4.3 Tactics for Modifiabiliiyp. 87
4.4.4 Tactics for Performancep. 90
4.4.5 Tactics for Securityp. 92
4.4.6 Tactics for Testabilityp. 94
4.4.7 Tactics for Usabilityp. 95
4.5 Summaryp. 96
4.6 Questionsp. 97
Referencesp. 98
5 Creating the Architecturep. 101
5.1 Introductionp. 101
5.2 Architecture of the Building Automation Systemp. 103
5.2.1 Support for Adding New Field Devicesp. 106
5.2.2 Addressing Latency and Load Conditionsp. 110
5.2.3 Addressing International Language Supportp. 113
5.3 Architécture Trade-Offsp. 116
5.3.1 Revisiting Modifiability Driversp. 116
5.3.2 Revisiting Performance Driversp. 118
5.4 The Final Architecturep. 120
5.5 Summaryp. 120
5.6 Questionsp. 122
Referencesp. 127
6 Communicating the Architecturep. 129
6.1 Introductionp. 129
6.2 Views as a Basis for Documentationp. 130
6.3 Documenting a Viewp. 131
6.4 Building an Architecture Description Documentp. 132
6.5 Architecture Description for the Building Automation Systemp. 133
6.5.1 Section 1: Document Road Mapp. 133
6.5.1.1 Section 1.1: Description of the Architecture Documentationp. 133
6.5.1.2 Section 1.2: How Stakeholders Can Use the Documentationp. 134
6.5.2 Section 2: System Overviewp. 136
6.5.2.1 Section 24: Business Goalsp. 136
6.5.2.2 Section 2.2: System Contextp. 137
6.5.2.3 Section 2.3: Functionsp. 140
6.5.2.4 Section 2.4: Quality Attribute Requirementsp. 142
6.5.2.5 Section 2.5: Constraintsp. 143
6.5.2.6 Section 2.6: Architectural Driversp. 143
6.5.3 Section 3: View Templatep. 145
6.5.4 Section 4: Viewsp. 145
6.5.4.1 Section 4.1: Module Viewp. 145
6.5.4.2 Section 4.2: Component-and-Connector Viewp. 146
6.5.4.3 Section 4.3: Deployment Viewp. 155
6.5.5 Section 5: Mapping between Viewsp. 157
6.5.6 Section 6: Rationalep. 160
6.6 Conclusionsp. 160
6.7 Questionsp. 162
Referencesp. 162
7 Architecture and Detailed Designp. 163
7.1 Introductionp. 163
7.2 Defining Interfacesp. 164
7.3 Creating the Domain Object Modelp. 164
7.3 The Rule Managerp. 167
7.3.1 Addressing Architectural Responsibilitiesp. 169
7.3.2 Addressing Functional Responsibilitiesp. 174
7.4 Summaryp. 174
7.5 Questionp. 177
Referencesp. 177
8 Role of Architecture in Managing Structural Complexityp. 179
8.1 Introductionp. 179
8.2 Analyzing System Complexityp. 180
8.2.1 Partitioning a DSMp. 182
8.2.2 Partitioning Algorithmsp. 184
8.2.3 Tearing a DSMp. 186
8.3 Managing Structural Complexityp. 189
8.3.1 Testing the Hypothesisp. 190
8.4 Discussion and Conclusionsp. 196
8.5 Discussion Questionsp. 197
Referencesp. 198
Indexp. 201