Register your product to gain access to bonus material or receive a coupon.
Applied Software Architecture
- Published Nov 4, 1999 by Addison-Wesley Professional. Part of the Addison-Wesley Object Technology Series series.
Book
- This product currently is not for sale.
Description
- Copyright 2000
- Dimensions: 7-3/8x9-1/4
- Pages: 432
- Edition: 1st
- Book
- ISBN-10: 0-201-32571-3
- ISBN-13: 978-0-201-32571-3
"Designing a large software system is an extremely complicated undertaking that requires juggling differing perspectives and differing goals, and evaluating differing options. Applied Software Architecture is the best book yet that gives guidance as to how to sort out and organize the conflicting pressures and produce a successful design." -- Len Bass, author of Software Architecture in Practice.
Quality software architecture design has always been important, but in today's fast-paced, rapidly changing, and complex development environment, it is essential. A solid, well-thought-out design helps to manage complexity, to resolve trade-offs among conflicting requirements, and, in general, to bring quality software to market in a more timely fashion.
Applied Software Architecture provides practical guidelines and techniques for producing quality software designs. It gives an overview of software architecture basics and a detailed guide to architecture design tasks, focusing on four fundamental views of architecture--conceptual, module, execution, and code. Through four real-life case studies, this book reveals the insights and best practices of the most skilled software architects in designing software architecture. These case studies, written with the masters who created them, demonstrate how the book's concepts and techniques are embodied in state-of-the-art architecture design. You will learn how to:
- create designs flexible enough to incorporate tomorrow's technology;
- use architecture as the basis for meeting performance, modifiability, reliability, and safety requirements;
- determine priorities among conflicting requirements and arrive at a successful solution; and
- use software architecture to help integrate system components.
Anyone involved in software architecture will find this book a valuable compendium of best practices and an insightful look at the critical role of architecture in software development.
0201325713B07092001
Sample Content
Table of Contents
List of Figures.
List of Tables.
Preface.
Foreword.
I. SOFTWARE ARCHITECTURE.
1. Introduction.Putting Software Architecture in Context.
Software Architecture as a Design Plan.
Software Architecture as an Abstraction.
Software Architecture Terminology.
Where the Four Views Came From.
Loose Coupling Between Views.
Different Engineering Concerns Addressed by Different Views.
Using the Four Views.
Notation.
II. DESIGNING, DESCRIBING, AND USING SOFTWARE ARCHITECTURE.
2. IS2000: The Advanced Imaging Solution.System Overview.
Product Features.
System Interactions.
The Future of IS2000.
3. Global Analysis.Overview of Global Analysis Activities.
Analyze Factors.
Develop Strategies.
Analyze Organizational Factors.
Begin Developing Strategies.
Analyze Technological Factors.
Continue Developing Strategies.
Analyze Product Factors.
Continue Developing Strategies.
Global Analysis Summary.
4. Conceptual Architecture View.Design Activities for the Conceptual Architecture View.
Global Analysis.
Central Design Tasks.
Final Design Task: Resource Budgeting.
Design of Conceptual View for IS2000.
Global Analysis.
Central Design Tasks: Components, Connectors, and Configuration .
Final Design Task: Resource Budgeting.
Design Summary for IS2000 Conceptual View.
Summary of Conceptual Architecture View.
Traceability.
Uses for the Conceptual Architecture View.
5. Module Architecture View.Design Activities for the Module Architecture View.
Global Analysis.
Central Design Tasks.
Final Design Task: Interface Design.
Design of Module View for IS2000.
Global Analysis.
Central Design Tasks: Modularization and Layering.
Final Design Task: Interface Design.
Design Summary for IS2000 Module View.
Summary of Module Architecture View.
Traceability.
Uses for the Module Architecture View.
6. Execution Architecture View.Design Activities for the Execution Architecture View.
Global Analysis.
Central Design Tasks.
Final Design Task: Resource Allocation.
Design of Execution View for IS2000.
Global Analysis.
Central Design Tasks: Runtime Entities, Communication Paths, and Configuration.
Final Design Task: Resource Allocation.
Design Summary for IS2000 Execution View.
Summary of Execution Architecture View.
Traceability.
Uses for the Execution Architecture View.
7. Code Architecture View.Design Activities for the Code Architecture View.
Global Analysis.
Central Design Tasks.
Final Design Tasks.
Design of Code Architecture View for IS2000.
Global Analysis.
Central Design Tasks.
Final Design Tasks.
Design Summary for IS2000 Code Architecture View.
Summary of Code Architecture View.
Traceability.
Uses for the Code Architecture View.
III. SOFTWARE ARCHITECTURE BEST PRACTICE.
8. Safety Vision.Global Analysis.
Analyze Product Factors.
Analyze Technological Factors.
Analyze Organizational Factors.
Develop Strategies.
Conceptual Architecture View.
Components for Software Specification.
Connectors for Software Specification.
Conceptual Configuration.
Resource Budgeting.
Module Architecture View.
Application Software Layer.
PlatformSoftware Layer.
Execution Architecture View.
Processes.
Communication Paths.
Execution Configuration.
Code Architecture View.
Software Architecture Uses.
Software Process for Projects.
Testing of Projects.
Summary.
9. Healthy Vision.Global Analysis.
Analyze Product Factors.
Analyze Technological Factors.
Analyze Organizational Factor.
Develop Strategies.
Conceptual Architecture View.
Module Architecture View.
Decomposition of the Application Software.
Decomposition of the Platform Software.
Layering Structure.
Error Logging.
Execution Architecture View.
Defining Run-time Entities.
Communication Paths.
Conceptual and Module Views Revisited.
Execution Configuration.
Code Architecture View.
Development Environment.
Configuration Management and Build Strategies.
Software Architecture Uses.
Evaluation.
Schedule Planning.
Implementation.
Requirements Tracking.
Summary.
Software Architecture Concepts.
Experience.
Performance.
10. Central Vision.Global Analysis.
Product Factors.
Technological Factors.
Organizational Factors.
Strategies.
Conceptual Architecture View.
Module Architecture View.
Decomposition and Layering.
Decomposition.
Execution Architecture View.
Defining Runtime Entities.
Defining Communication Paths.
Defining the Execution Configuration.
Resource Allocation.
Code Architecture View.
Central Design Tasks.
Build Procedure and Configuration Management.
Software Architecture Uses.
Summary.
Software Architecture Concepts.
Experience.
11. Comm Vision.Global Analysis.
Product Factors.
Technological Factors.
Organizational Factors.
Develop Strategies.
Conceptual Architecture View Design.
Module Architecture View.
Decomposition.
SPU Interfaces and Inter-SPU Dependencies.
Layering Structure or Shell Model.
Execution Architecture View.
Defining Executables and Configurations.
Communication.
Recovery Suites and Recovery-Tolerant Communication.
Resource Allocation.
Code Architecture View.
Source Components.
Intermediate Components.
Software Architecture Uses.
Simulation and Code Generation.
Higher Productivity of Software Production.
Stepwise Production Testing of Shells.
Architecture Control Process.
Summary.
Software Architecture Concepts.
Experience.
IV. SOFTWARE ARCHITECTURE IN YOUR FUTURE.
12. The Role of the Software Architect.The Architect as a Key Technical Consultant.
The Architect Makes Decisions.
The Architect Coaches.
The Architect Coordinates.
The Architect Implements.
The Architect Advocates.
Software Architecture as a Career.
Glossary.Four Views Quick Reference.
Bibliography.
Index. 0201325713T04062001
Preface
Software architecture is a recently emerged technical field, but it's not a new activity; there have always been good designers who create good software architectures. However, now the consensus is that what these designers do is qualitatively different from other software engineering activities, and we've begun figuring out how they do it and how we can teach others to do it.
Software architecture is not just a new label for an old activity; software architects today face new challenges. They are asked to produce increasingly complex software. Using the latest technologies, but these technologies are changing faster than ever. And they are asked to produce better quality software with a shorter time-to-market. Instead of seeing the architecture as necessarily complicated by these staggering requirements, we need to realize that the architecture is our most powerful tool in meeting them.
This book is a practical guide to designing, describing, and applying software architecture. The book began as a study of software architecture in industry, specifically at our company--Siemens. The study told us how practitioners define software architecture, what problems they are trying to solve with it, and how and why they choose particular architectural solutions.
We examined how architects design systems so that today's technology can be replaced with tomorrow's. We saw how the experts abstracted the essential aspects of their real-time, safety-critical reliability and performance requirements so that they could make good architectural decisions consistently. We also saw how good architecture descriptions improved the development process, making it easier to develop high-quality software in a shorter time. We saw how managers' understanding of the architecture was critical in organizing and scheduling the project. We saw how developers depended on the architecture to define interfaces and boundaries between their component and others, and to target maintenance activities.
This book also grew from our experience with software architecture as we applied the principles and techniques we saw the experts use. The description techniques helped uncover architectural problems in existing systems. The design principles guided us in defining architectures for new systems and for proposing solutions to problems in existing systems.
Road MapPart I of this book provides important background information for understanding what we mean by software architecture, and how we structure the architecture design tasks. In Part II we define the architecture design tasks, and use a running example to show how they are applied to the design of a software architecture. The example system, IS2000, is an image acquisition and processing system. We don't provide its complete architecture design, but instead describe one of its subsystems in detail. The Additional Reading section at the end of each chapter in Parts I and II dives references to sources of more information on software architecture.
Part III contains detailed descriptions of four industrial systems. These systems come from our original industrial study and they represent the state-of-the-art in software architecture. Each chapter in Part III gives a broad overview of the software architecture of a case study; These studies don't have the same level of detail as IS2000. The four systems are
- Safety Vision--A half-million lines of code (LOC) instrumentation and control system for nuclear power plants
- Healthy Vision--A million LOC embedded patient monitoring system
- Central Vision--A half-million LOC centralized patient monitoring system
- Comm Vision--A multimillion LOC telecommunications system
The architects of these systems faced and solved some of the most difficult challenges confronting today's architects: designing large-scale, real-time, safety-critical, highly reliable systems.
In Part IV, we examine the software architect's role, describing what an architect must do beyond the software architecture design.
A Glossary and a Quick Reference to the architecture design tasks and artifacts are included at the end of the book. The four Quick Reference architecture views can also be found on the front and back endpapers.
We have selected the Unified Modeling Language (UML) to describe the software architecture, supplemented by tables or other notations when appropriate. We chose UML because it expresses well most of what we were trying to capture, and it is widely understood. Although the architecture notation is not the essential contribution of this book, we believe that a common notation and a common agreement about what is described will further the field of software architecture by improving our ability to communicate.
The main thing you'll learn from this book is a new way to tackle the problem of architecture design. You will learn what the issues are, when they should be addressed, and how they can be addressed. This book will increase your ability to recognize good solutions. Even if it does not change your eventual architectural solutions, it will help you arrive at those solutions more quickly.
Guide to the ReaderThere are a couple of different ways you can read this book. To get a general overview, we recommend you read Parts I and IV. For managers or others who are interested in understanding what software architecture is and how it is used, this is sufficient.
Project managers, system architects, software developers, testers, and those who want a better understanding of the four software architecture views should read, in addition, at least some of Part II. You can get this overview by reading Part II; you may skip the sections that cover the example system. Thus, read the first few pages of Part II, then the first and last sections of chapters 3 through 7. Skip Chapter 2 and Sections 3.2 through 3.7, 4.2, 5.2, 6.2, and 7.2.
After this overview, you will be well prepared to read the case studies. This is an option for students of software architecture or others who want to see the architecture of a range of applications. As you would expect, the case studies are all independent, so you can pick any or all to read. Read the introductory pages of Part III to find out more about the characteristics of each case study.
The final option is to read the whole book. This is, of course, what we recommend for software architects and all others who want a thorough understanding of software architecture. However, we don't expect you to digest Part III all at once, The case studies can be read over time, as the need or interest arises.
0201325713P04062001