Preface

Software architecture is the centerpiece of modern system development. The goal of architecture-centric development is the effective, efficient, competitive development of software products. The activities of development are anchored in the architecture. The goal of this text is to provide both student and professional a comprehensive treatment of architecture-centric development, instructing how to develop products and serving as a reference for the panoply of techniques, modeling notations, standards, and methods comprising the approach.

The text is intended for upper-division undergraduate and graduate courses in software architecture, software design, component-based software engineering, and distributed systems; the text may also be used in introductory as well as advanced software engineering courses. The targeted courses can be of different lengths, from a single ten-week quarter, to a fifteen-week semester, to a two-semester sequence. Both the breadth and depth of topics covered will vary depending on the exact nature of the course. Specific recommendations for instructors are provided below.

With such an ambitious goal, the text is extensive and may be approached in different ways. In this preface we guide the reader in the use of the book. Hence we briefly present here:

  • The general view of software architecture taken by the book.

  • The scope of the book.

  • The intended audiences.

  • Our assumptions regarding the technical maturity/background of the professionals and students who will use the book.

  • Thoughts regarding selection of materials for use in the classroom, and by professionals, including systems engineers, software architects, and managers of software systems development.

  • How instruction in the material may be supported by tools.

  • A summary of each chapter.

SOFTWARE ARCHITECTURE

The text adopts a particular definition of software architecture: the set of principal design decisions governing a system. This definition is broad and stakeholder-centric. Nonetheless, a decidedly technical view of software architecture pervades the book. We believe that software architecture must help developers create real implemented systems. Software architecture without a tie to implementation, deployment, and long-term adaptation misses its potential by a wide mark and risks being irrelevant busywork; tolerated perhaps, but not treasured.

The comprehensive character of software architecture as presented in the text makes it, in our estimation, the central focus of software engineering. The text attempts to show architecture's critical role in software engineering, yet the text does not attempt to be a general software engineering reference. There are, for example, many important parts of software engineering not treated at all, such as source-code testing strategies, general project management, and development environments.

THE SCOPE OF THE BOOK

This book is characterized by breadth. Rather than focus on one method, notation, tool, or process, the book attempts to widely survey software development from an architectural perspective, putting many of these elements in context, comparing and contrasting them with one another. A reader should expect to gain a broad appreciation for the role of software architecture across the wide variety of activities that characterize the development of large, software-intensive systems.

Our assumption is that readers seek fundamental insights and knowledge to supplement their own experience, rather than canned solutions to specific problems (those, if they do exist, can most likely be found elsewhere). The text therefore focuses on overarching principles, general strategies, and broadly applicable techniques. It illustrates them with many specific examples from various domains. The text does not advocate a single approach and it is not a manual or advertisement for one—even the authors' own.

Audiences

The book attempts to address the needs of several audiences.

The instructor audience is supported by a detailed treatment of a broad spectrum of software architecture-related topics, from which different subsets can be selected for use in courses with specific foci. An instructor will be able to tailor the material provided in the book to both the length and the objective of a course. To date, the authors have used this text in five quarter-long (ten-week) courses and two semester-long (fifteen-week) courses, at both the undergraduate and graduate levels. The courses have focused on software engineering, software architecture, software design, software interoperability, and distributed systems. Both semester-long courses have used the entire text, while the quarter-long courses have relied on different selections of the chapters. The instructor using the text will be able to rely on a comprehensive set of lecture slides, solutions to end-of-chapter exercises, sample exams with solutions, and a tool suite that will be described below.

The student audience is supported with a presentation that is comprehensive, making relatively few assumptions about background knowledge and experience. We do assume that the student is generally familiar with the most basic elements of software engineering and programming. The order of the text and the way the material is presented makes the student the primary audience of the book—the other audiences will pick and choose material from various parts of the text.

The professional audience is supported with, for example, comprehensive treatment of the major modeling techniques, architectural description standards, and the way they are directly tied to the implementation of software products. Our perspective is not confined to some presumed ivory tower: The standards and notations include commercial, government, and research products. The text also attempts to provide, in the majority of chapters, specific guidance on how to achieve various goals, such as how to design to achieve specific system properties. References and examples draw from a wide range of industrial experience. Professionals should expect to encounter realistic and frank assessments of the techniques, notations, and tools with which they are already familiar, while also being exposed to projects and approaches that provide valuable insights but are nonetheless not well-known in practitioners' circles.

The systems engineer will find that this book's perspective, while still focused on software, has implications that are quite a bit broader. Insights in this book will enable better understanding of the unique issues involved in the development of large software systems. Many of the insights, however, are applicable to systems development in general. Insights, notations, and methods from the systems engineering and systems architecture community are not ignored, and this book explores overlap between systems and software engineering throughout.

The systems and/or software development manager will find substantial material here that addresses the way in which architecture-centric development can shape and improve processes and organizations, especially with regard to the development of product families.

ASSUMPTIONS AND BACKGROUND

Depending on the sections of the book used for reference or in class, the necessary background varies. As a whole, however, the book assumes familiarity with the basics of software development. This includes the core ideas of software development activities and processes, notions of requirements, design, programming, and analysis and testing. The level of maturity required is, in some sense, only what would be acquired in a single, quarter-or semester-long introduction to software development/engineering. Appreciation for the problems of large-scale development is very useful. Proficiency in any particular programming language, development environment, or modeling tool such as UML is not required.

Additional experience will likely make it possible for certain readers to develop a deeper understanding and appreciation of specific topics. For example, the implementation chapter will be of most value to those with substantive training and experience in programming. Similarly, appreciating the discussion of deployment or product lines demands some level of understanding of how commercial development and product-and-revenue focused businesses work. However, none of the chapters presuppose an extensive background in the area on which they focus.

HOW THE BOOK CAN BE USED

The text is designed to be used as a textbook in formal classroom settings, both at the undergraduate and graduate levels. It can also be used as a reference for systems engineers, software architects, managers, and programmers. Chapters 1 through 5 present the critical concepts of software architecture. Chapter 5 also bridges to the next section, the nuts and bolts of applying the concepts, which encompasses Chapters 6 through 10. 11 through 17 treat associated issues: topics that may be critical in one development context, but not in another.

Classroom Usage

There is adequate material in the book for a year-long class at the master's degree level. The presentation does not presuppose that this is the normative case however. The authors have used material from the book in quarter-long and semester-long courses, including, as a primary text, an undergraduate software engineering course and a graduate software engineering course. The book, in its preprint form, has also been used at several other universities, including Drexel University, Southern Methodist University, Seattle University, and the University of Zurich.

Clearly, material has to be chosen based upon the level of the instruction and the length of the class. Nonetheless, a few comments are in order. The concepts section—Chapters 1 through 5—is essential to use of the book. The material in the subsequent chapters depends on these core concepts. How long it will take to cover those initial chapters, however, will vary significantly. The first chapter, for instance, will be a very quick read for the experienced. Similarly, Chapter 2 will be relatively quick for those with experience in software engineering, but will take a bit longer in an undergraduate class that has minimal prerequisites. Chapter 4 is a long chapter, but it covers a single, critical topic: how to go about designing a system. This chapter may thus be a major focus over many class sessions, especially for those with little training or experience in design.

Selection of materials from Chapters 6 through 10 will depend upon the level of the class, the course objectives, and the length of the class. The authors recommend a shallow treatment of all of them over a deep look at any individual chapters, but this is up to the instructor.

Several suggested pathways through the book, depending on course type and length, are as follows:

If the book is used as a primary text for a software engineering course, the instructor may want to supplement it with material covering topics such as software testing, ∞ design patterns, software engineering economics, and project management. The book can also be used as a companion text in a software analysis and quality assurance course; the relevant chapters would be Chapters 8, 12, 13 and 14.

A key issue the instructor will have to deal with is use of the exercises. Each chapter has a number of exercises listed. Software architecture is not a topic like algebra where numerous simple questions can be posed and the answers given in the back of the book. Software architecture concerns itself with design, with complex systems, and with long-lived products. Hence it is difficult to pose exercises that fit nicely into the constraints of a modern college class. Many of the exercises included in the text could be assigned as mini-projects. The instructor will thus have to tailor the scope of the assignments and provide guidance to the students regarding the level of detail expected in the answers. Assessing the answers similarly will require thought and discretion.

Use by Professionals

The authors have tried to include substantial material to make the book a superior reference for the professional. A theme running through the entire book is software reuse and, more generally, reuse of corporate and domain knowledge. Similarly, there is explicit reliance in the presented techniques on the use of frameworks to help achieve rapid system implementation. A wide range of modeling notations is discussed, and a complete chapter on standards is included to provide a thoughtful basis for choosing a notation or approach for a project. Similarly, the discussion of designing for non-functional properties is targeted at providing proven techniques capable of addressing these difficult issues. Chapter 4 on designing similarly will be useful as a reference to the professional. Without being a handbook of field techniques, it nevertheless presents a wide range of architectural styles and design techniques, with the styles summarized individually and in a comparison table to aid the professional in choosing the right technique for the job at hand.

Tool Support

Use of the book in the classroom or by professionals in practice does not require the use of any particular tool or programming language. Clearly, however, the subject is designing and building applications—products—and that only happens effectively in the presence of good tools. The professional may be constrained by the choice of the modeling notation required in a particular development context. If AADL, for example, is mandated as the architecture description language for a project, then the die is cast.

For those contexts where external constraints do not dictate, the instructor or reader is encouraged to use technologies that not only help model an architecture, but build implementations based upon those models. If modeling alone is supported, then the value of a tool over a simple boxes-and-arrows drawing tool rests upon the value obtained from analyses that can be performed on the model. If building real products is the goal, then a tool suite that addresses the full range of developers' needs is required.

To this latter end we encourage the book's users to use the ArchStudio tool suite, as it has been developed for this purpose. The tool can benefit faculty, students, and even professionals using this text. The tool is free, is integrated with the Eclipse development environment, and has been used in the classroom and in industry. A community of developers and users has formed around this project, with dozens of projects around the world using and contributing. Further details can be found on the project's Web site: www.isr.uci.edu/projects/archstudio/.

Chapter Summaries

Chapter 1: The Big Idea

The chapter introduces software architecture through discussion of three primary examples of its application: in the very large (the architecture of the World Wide Web), in the very small (pipe-and-filter on the desktop), and in the product/in the many (the Philips/Koala architecture for consumer electronics).

Chapter 2: Architectures in Context: The Reorientation of Software Engineering

The role of software architecture in the major activities of software engineering is explored, including application conception, design, implementation, and analysis. An architecture-centric perspective on development is presented.

Chapter 3: Basic Concepts

Definitions of the key terms and concepts are presented. The definitions build from the examples in the preceding chapters and form the foundation for the subsequent chapters.

Chapter 4: Designing Architectures

The concepts of the preceding chapters are made productive in this one. This chapter presents, at length, techniques and approaches for designing applications from an architecture-centric perspective. The central focus is on the ways in which refined experience may be used to guide new developments.

Chapter 5: Connectors

Connectors play a distinguished role in architecture-centric development. They are also, perhaps, the most unfamiliar concept to those unskilled in the art of system design. This chapter reveals the breadth and depth of the concept, and includes an extensive guide to the numerous techniques available.

Chapter 6: Modeling

This chapter surveys an extensive range of modeling notations used for capturing the design decisions that make up architecture. Notations from research and practice are examined, and the distinctive aspects of each notation are called out. A consistent running example application is used throughout the chapter to demonstrate each notation.

Chapter 7: Visualization

This chapter draws a distinction between how architectures are modeled—the syntax and semantics of how design decisions are documented—from how they are visualized. Visualization encompasses both depiction—how design decisions are presented—and interaction—the "user interface" through which stakeholders interact with those depictions. Various visualization approaches are surveyed and compared, along with techniques for constructing and integrating new visualizations.

Chapter 8: Analysis

One of the primary benefits of software architecture is that it can enable early assessment of a given system, before significant resources are invested in the system's implementation and deployment. This chapter provides a broad overview of the various analysis techniques that can be applied at the architectural level, their strengths, and limitations.

Chapter 9: Implementation

This chapter describes the problem of moving from architectural design decisions to implementation artifacts. Special attention is paid to the use of architecture implementation frameworks, special-purpose middleware that bridges the gap between architectural styles and existing platform services. Two complete implemented applications in alternative frameworks are presented with commentary.

Chapter 10: Deployment and Mobility

This chapter addresses deployment and mobility, two related topics that have become important in contemporary distributed, embedded, and pervasive systems. The objective of the chapter is not to provide a complete treatment of these two topics, but rather to isolate and focus on their characteristics from an explicit software architectural perspective.

Chapter 11: Applied Architectures and Styles

Several examples from "the practice" are explored, showing how various of the ideas in the preceding chapters have been applied to solve deep and commercially important problems. The architectures of the World Wide Web, Napster, Gnutella, Skype, BitTorrent, robotics systems, Google, and Akamai are discussed. The pedagogical goal is showing how multiple simple architectural approaches can effectively be combined.

Chapter 12: Designing for Non-Functional Properties

This chapter selects a set of non-functional properties that are frequently required of large and complex software systems: efficiency, complexity, scalability, adaptability, and dependability. The role of software architecture in achieving the desired level of each property is discussed, and many specific architectural design guidelines are provided and discussed.

Chapter 13: Security and Trust

Architecture-based techniques are presented for coping with security and trust needs in application system design. After a general introduction to security issues, attention is focused on architecture-based access control and reputation-based trust systems.

Chapter 14: Architectural Adaptation

The theme of this chapter is use of an architectural model to guide long-term system adaptation. A comprehensive conceptual framework for adaptation is presented, followed by consideration of numerous specific techniques for effecting adaptation and for designing applications to be accommodating of post-release adaptation.

Chapter 15: Domain-Specific Software Engineering

Architecture-centric development is perhaps most valuable when applied in the context of a specific domain, where reuse of hard-won engineering knowledge and principles can substantially reduce the amount of effort, cost, and risk involved in system development. This chapter surveys a variety of techniques for applying architecture-centric development within a domain, and ends with an extensive treatment of product-line architectures.

Chapter 16: Standards

A practicing architect or system developer is faced with a panoply of de facto and de jure standards—IEEE 1471, UML, SysML, DoDAF, RM-ODP, and so on. The chapter opens with a discussion of standards, how they are created and evolved, and how they can add value to development efforts. The remainder of the chapter surveys the most influential standards and attempts to put them in perspective, identifying their strengths and weaknesses explicitly.

Chapter 17: People, Roles, and Teams

An effective architect may need to possess many different skills, beyond just being a good software designer. An architect is an integral part of a larger organization, and may be one of several architects working on a project. The context within which software architects operate, and therefore their job description, can get quite complex. This chapter overviews the various roles software architects may play in a project and, more broadly, an organization.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset