Software architecture

"By analogy to building architecture, we propose the following model of software architecture:"

"In creating a software architecture, system considerations are seldom absent. For example, if you want an architecture to be high performance, you need to have some idea of the physical characteristics of the hardware platforms that it will run on (CPU speed, amount of memory, disk access speed) and the characteristics of any devices that the system interfaces with (traditional I/O devices, sensors, actuators), and you will also typically be concerned with the characteristics of the network (primarily bandwidth). If you want an architecture that is highly reliable, again you will be concerned with the hardware, in this case with its failure rates and the availability of redundant processing or network devices. On it goes. Considerations of hardware are seldom far from the mind of the architect. So, when you design a software architecture, you will probably need to think about the entire system-the hardware as well as the software. To do otherwise would be foolhardy. No engineer can be expected to make predictions about the characteristics of a system when only part of that system is specified."

"All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change."

"Software architecture is at the center of a frenzy of attention these days... We hold that documenting software architecture is primarily about documenting the relevant views, and then augmenting this information with relevant information that applies across views."

"Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is, however, little consensus in the research community on what is an ADL, what aspects of an architecture should be modeled in an ADL, and which of several possible ADLs is best suited for a particular problem. Furthermore, the distinction is rarely made between ADLs on one hand and formal specification, module interconnection, simulation, and programming languages on the other."

"The first phase of software architecture research, where the key concepts are components and connectors, has matured the technology to a level where industry adoption is wide-spread and few fundamental issues remain. The traditional view on software architecture suffers from a number of key problems that cannot be solved without changing our perspective on the notion of software architecture. These problems include the lack of first-class representation of design decisions, the fact that these design decisions are cross-cutting and intertwined, that these problems lead to high maintenance cost, because of which design rules and constraints are easily violated and obsolete design decisions are not removed. As a community, we need to take the next step and adopt the perspective that a software architecture is, fundamentally, a composition of architectural design decisions. These design decisions should be represented as first-class entities in the software architecture and it should, at least before system deployment, be possible to add, remove and change architectural design decisions against limited effort."

"As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system—the software architecture—presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms."

"The software architecture of a system supports the most critical requirements for the system. For example, if a system must be accessible from a wireless device, or if the business rules for a system change on a daily basis, then these requirements drastically affect the software architecture for the system. It is necessary for an organization to characterize software architectures and the level of qualities that their systems support to fully understand the implications of these systems on the overall enterprise architecture."

"Software architecture is still mostly considered a separate issue from programming languages. We contend that this is a serious issue for the software engineering of interactive systems."

"The goal for our software architecture is to provide the key mechanisms that are required to implement a wide variety of cross-layer adaptations described by our taxonomy. Our strategy for developing such an architecture is actually to create two architectures, a “conceptual” one, followed by a “concrete” one. In this step, we have first"

"Studies of software engineering projects show that a large number of usability related change requests are made after its deployment. Fixing usability problems during the later stages of development often proves to be costly, since many of the necessary changes require changes to the system that cannot be easily accommodated by its software architecture. These high costs prevent developers from meeting all the usability requirements, resulting in systems with less than optimal usability. The successful development of a usable software system therefore must include creating a software architecture that supports the right level of usability. Unfortunately, no documented evidence exists of architecture level assessment techniques focusing on usability. To support software architects in creating a software architecture that supports usability, we present a scenario based assessment technique that has been successfully applied in several cases. Explicit evaluation of usability during architectural design may reduce the risk of building a system that fails to meet its usability requirements and may prevent high costs incurring adaptive maintenance activities once the system has been implemented."

"Software architecture is a burgeoning field of research and practice within software engineering. Alternatively, to be more precise, the architecture of large, software intensive systems has been the subject of increasing interest for the past decade. What accounts for this surge of interest in a field that, until about 1990 was unheard of? To begin, the field did not spontaneously create itself in 1990. However, that time frame was when the term “software architecture” began to gain widespread acceptance and when the field first attracted substantial attention from both industry and the research community. The field was created out of necessity. Software systems were growing larger: systems of hundreds of thousands or even millions of lines of code were becoming commonplace. Clearly, Parnas, Brooks, Dijkstra and others in the 1960s through the 1980s-laid the foundations of the ideas underlying the field that is today called “software architecture” but what changed is that by the 1990s such large systems were becoming common."