Database-centric architecture

About: Database-centric architecture is a(n) research topic. Over the lifetime, 1799 publication(s) have been published within this topic receiving 48836 citation(s).

Software Architecture in Practice

Abstract: From the Book: Our goals for the first edition were threefold. First, we wanted to show through authentic case studies actual examples of software architectures solving real-world problems. Second, we wanted to establish and show the strong connection between an architecture and an organization's business goals. And third, we wanted to explain the importance of software architecture in achieving the quality goals for a system. Our goals for this second edition are the same, but the passage of time since the writing of the first edition has brought new developments in the field and new understanding of the important underpinnings of software architecture. We reflect the new developments with new case studies and the new understanding both through new chapters and through additions to and elaboration of the existing chapters. Architecture analysis, design, reconstruction, and documentation have all had major developments since the first edition. Architecture analysis has developed into a mature field with industrial-strength methods. This is reflected by a new chapter about the architecture tradeoff analysis method (ATAM). The ATAM has been adopted by industrial organizations as a technique for evaluating their software architectures. Architecture design has also had major developments since the first edition. The capturing of quality requirements, the achievement of those requirements through small-scale and large-scale architectural approaches (tactics and patterns, respectively), and a design method that reflects knowledge of how to achieve qualities are all captured in various chapters. Three new chapters treat understanding quality requirements, achieving qualities, and theattribute driven design (ADD) method, respectively. Architecture reconstruction or reverse engineering is an essential activity for capturing undocumented architectures. It can be used as a portion of a design project, an analysis project, or to provide input into a decision process to determine what to use as a basis for reconstructing an existing system. In the first edition, we briefly mentioned a tool set (Dali) and its uses in the re-engineering context; in in this edition the topic merits its own chapter. Documenting software architectures is another topic that has matured considerably in the recent past. When the first edition was published, the Unified Modeling Language (UML) was just arriving on the scene. Now it is firmly entrenched, a reality reflected by all-new diagrams. But more important, an understanding of what kind of information to capture about an architecture, beyond what notation to use, has emerged. A new chapter covers architecture documentation. The understanding of the application of software architecture to enable organizations to efficiently produce a variety of systems based on a single architecture is summarized in a totally rewritten chapter on software product lines. The chapter reinforces the link between architecture and an organization's business goals, as product lines, based around a software architecture, can enable order-of-magnitude improvements in cost, quality, and time to market. In addition to the architectural developments, the technology for constructing distributed and Web-based systems has become prominent in today's economy. We reflect this trend by updating the World Wide Web chapter, by using Web-based examples for the ATAM chapter and the chapter on building systems from components, by replacing the CORBA case study with one on Enterprise JavaBeans (EJB), and by introducing a case study on a wireless EJB system designed to support wearable computers for maintenance technicians. Finally, we have added a chapter that looks more closely at the financial aspects of architectures. There we introduce a method--the CBAM--for basing architectural decisions on economic criteria, in addition to the technical criteria that we had focused on previously. As in the first edition, we use the architecture business cycle as a unifying motif and all of the case studies are described in terms of the quality goals that motivated the system design and how the architecture for the system achieves those quality goals. In this edition, as in the first, we were very aware that our primary audience is practitioners, so we focus on presenting material that has been found useful in many industrial applications, as well as what we expect practice to be in the near future. We hope that you enjoy reading it at least as much as we enjoyed writing it. 0321154959P12162002

Foundations for the study of software architecture

Abstract: The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements --- that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work.

Architectures for netcentric computing systems

Abstract: An execution architecture, a development architecture and an operations architecture for a netcentric computing system. The execution architecture contains common, run-time services required when an application executes in the netcentric computing system. The development architecture is the production environment for one or several systems development projects as well as for maintenance efforts. The purpose of the development environment is to support the tasks involved in the analysis, design, construction, and maintenance of business systems, as well as the associated management processes. It is important to note that the environment should adequately support all the development tasks, not just the code/compile/test/debug cycle. The operations architecture is a combination of tools and support services required to keep a production system up and running efficiently.

Software Architecture: Foundations, Theory, and Practice

Abstract: Software architecture has become a centerpiece subject for software engineers, both researchers and practitioners alike. At the heart of every software system is its software architecture, i.e., "the set of principal design decisions about the system". Architecture permeates all major facets of a software system, for principal design decisions may potentially be made at any time during a system's lifetime, and potentially by any stakeholder. Such decisions encompass structural concerns, such as the system's high-level building blocks---components, connectors, and configurations; the system's deployment; the system's non-functional properties; and the system's evolution patterns, including runtime adaptation. Software architectures found particularly useful for families of systems---product lines---are often codified into architectural patterns, architectural styles, and reusable, parameterized reference architectures. This tutorial affords the participant an extensive treatment of the field of software architecture, its foundation, principles, and elements, including those mentioned above. Additionally, the tutorial introduces the participants to the state-of-the-art as well as the state-of-the-practice in software architecture, and looks at emerging and likely future trends in this field. The discussion is illustrated with numerous real-world examples. One example given prominent treatment is the architecture of the World Wide Web and its underlying architectural style, REpresentational State Transfer (REST).

Rainbow: architecture-based self-adaptation with reusable infrastructure

Abstract: While attractive in principle, architecture-based self-adaptation raises a number of research and engineering challenges. First, the ability to handle a wide variety of systems must be addressed. Second, the need to reduce costs in adding external control to a system must be addressed. Our rainbow framework attempts to address both problems. By adopting an architecture-based approach, it provides reusable infrastructure together with mechanisms for specializing that infrastructure to the needs of specific systems. The specialization mechanisms let the developer of self-adaptation capabilities choose what aspects of the system to model and monitor, what conditions should trigger adaptation, and how to adapt the system.