Search

Quality concerns, often referred to as nonfunctional requirements, service-level agreements, quality attributes, performance constraints, or architecturally significant requirements, describe system-level attributes such as security, performance, reliability, and maintainability. In conjunction with functional requirements, these quality concerns drive and constrain a system's architectural design and often introduce significant trade-offs that must be carefully considered and balanced. The dependencies that exist between requirements and architecture have been referred to as the twin peaks of requirements and architecture. The guest editors of this special issue describe this unique situation.

In this paper, software architects can develop domain specific languages that express the desired architecture during the definition process and use them to describe systems based on the architecture.

Every software system has architecture. The architecture strongly influences the software system's properties, including maintainability and runtime properties such as performance and reliability. By describing the architecture in models, we can make the architecture explicit. Developers typically use software architecture models at design time to capture the significant decisions about a software system's organization and to describe and establish a common understanding about the system's abstract properties. In the MADAM (mobility- and adaptation-enabling middleware) project, we aim to facilitate adaptive application development for mobile computing. We follow an architecture-centric approach where we represent architecture models at runtime to allow generic middleware components to reason about and control adaptation.

Does agile development need architecture? Does architecture need agile development? These two questions are debated time and again, frequently with great passion but quite often more polarized than open minded. In this edition of the column, the authors try to offer a more evenhanded perspective on this debate. Instead of posing and discussing culturally biased assumptions, they consider a more open and neutral question: what is the relationship between architecture and process?

For the past two years, the author has been working to create a handbook of software architecture (www.booch.com/architecture) and will continue to work on it for another two to three years. The handbook’s primary goal is to codify the architecture of 100 interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and permits comparisons across domains and architectural styles. In this ongoing column, Booch will share some of his experiences as he continues his research.

In other industries, the idea of build corporate culture by establishing a common level of "best practice" is widely known and used. The architecture concept directly supports this goal for our industry and can help us improve problem areas dominated by organizational and social issues, such as health care organizations, educational systems, and so on. Our proposed reference model for architecture specification and development is organized around a set of aspects that structure concepts and rules; these, in turn, specify a conceptual architecture. We have added principles and guidelines to the concepts and rules to give a more complete picture of the architecture and to provide a place to store and communicate successfully applied design patterns and other knowledge related to the architecture. Adding architectural elements is a step toward a more constructive type of architecture representation. Our current research is focused on further refining these concepts and developing a formal specification of the architecture reference model. We are continuing to test our ideas in case studies, such as applying our model to the OSCA architecture and the application machine concept. We are also developing a prototype architecture editor, and we are testing different tools to learn more about integrating them into a real infrastructure and to learn what typical services an infrastructure must provide.

There is complexity, and then there is organized complexity. Pure complexity is chaotic; organized complexity is full of patterns. Naming these patterns and respecting their intention is the essence of architecture.

This article deals with the comparison between building architecture and software architecture. In software, cost estimation is extremely immature, and more accurate estimates can be obtained only by each iteration.

This paper present the architecture of a software intensive system. An architecture is just a collective hunch, a shared hallucination, an assertion by a set of stakeholders about the nature of their observable world, be it a world that is or a world as they wish it to be. An architecture therefore serves as a means of anchoring an extended set of stakeholders to a common vision of that world, a vision around which they may rally, to which they are led, and for which they work collectively to make manifest. When I say that an architecture is a shared hallucination, I mean that an architecture-as-artifact is a naming of the mutually agreed-upon set of design decisions that shape a software-intensive system. While an architecture is just an abstraction of reality, an architecture-as-artifact is a declaration of that shared reality. In this way, that shared hallucination represents a common vision among a set of stakeholders as observed simultaneously through several different points of view and represented by a set of interlocking models.