Wikiquote

Software architecture

high level structures of a software system

Software architecture is a term for the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations. The term also denotes the set of practices used to select, define or design a software architecture.

Architecture of Interoperable Information Systems.
CONTENT : A - F, G - L, M - R, S - Z, See also, External links

Quotes

edit
Quotes are arranged alphabetically by author

A - F

edit
  • Generically, an architecture is the description of the set of components and the relationships between them. Simple enough. The trouble starts when you tack on an adjective: There are software architectures, hardware architectures, network architectures, system architectures, and enterprise architectures. People have their own preconceived notions and experiences about “architecture.”
    A software architecture describes the layout of the software modules and the connections and relationships among them. A hardware architecture can describe how the hardware components are organized. However, both these definitions can apply to a single computer, a single information system, or a family of information systems. Thus “architecture” can have a range of meanings, goals, and abstraction levels, depending on who’s speaking.
    An information system architecture typically encompasses an overview of the entire information system—including the software, hardware, and information architectures (the structure of the data that systems will use).In this sense, the information system architecture is a meta-architecture. An enterprise architecture is also a meta-architecture in that it comprises many information systems and their relationships (technical infrastructure). However, because it can also contain other views of an enterprise—including work, function, and information—it is at the highest level in the architecture pyramid. It is important to begin any architecture development effort with a clear definition of what you mean by “architecture.”
  • It is argued that software architecture is an effective tool to cut development cost and time and to increase the quality of a system.
    • Muhammad Ali Babar and Pekka Abrahamsson (2008). "Architecture-centric methods and agile approaches." Agile Processes in Software Engineering and Extreme Programming. Springer Berlin Heidelberg, 2008. 242-243.
  • Software architecture is an important field of study that is becoming more important and more talked about with every passing day. Nevertheless, to our knowledge, there exists little practical guidance on managing software architecture in a real software development organization, from both technical and managerial perspectives. This book has emerged from our belief that the coupling of a system's software architecture and its business and organizational context has not been well explored.
    Our experience with designing and analyzing large and complex software-intensive systems has led us to recognize the role of business and organization in the design of the system and in its ultimate success or failure. Systems are built to satisfy an organization's requirements (or assumed requirements in the case of shrink-wrapped products). These requirements dictate the system's performance, availability, security, compatibility with other systems, and the ability to accommodate change over its lifetime. The desire to satisfy these goals with software that has the requisite properties influences the design choices made by a software architect.
    • L. Bass, P. Clements, and R. Kazman (1998) Software Architecture in Practice, Addison Wesley Longman. Preface.
  • Releasing Linux versions has always been a matter of higher code quality, good software architecture, and technical interest for the platform.
  • Every software system needs to have a simple yet powerful organizational philosophy (think of it as the software equivalent of a sound bite that describes the system's architecture)... [A] step in [the] development process is to articulate this architectural framework, so that we might have a stable foundation upon which to evolve the system's function points.
    • Grady Booch (1991) Object-Oriented Design: with Applications. p. 320.
  • 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.
    • Grady Booch (2006) "On design" cited in: Frank Buschmann, ‎Kevlin Henney, ‎Douglas C. Schmidt (2007) Pattern-Oriented Software Architecture, On Patterns and Pattern Languages. p. 214.
  • 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.
    • Jan Bosch (2004) "Software architecture: The next step." Software architecture. Springer Berlin Heidelberg. p. 194-199. Abstarct.
  • 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.
    • Stéphane Chatty (2008) "Programs= Data+ Algorithms+ Architecture: Consequences for Interactive Software Engineering." Engineering Interactive Systems. Springer Berlin Heidelberg, 2008. 356-373.
  • 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
    • Soon Hyeok Choi (2008) A Software Architecture for Cross-layer Wireless Networks. p. 34.
  • 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.
    • Paul Clements et al. (2002) Documenting software architectures: views and beyond. Pearson Education.
  • 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.
    • Eelke Folmer, Jilles van Gurp & Jan Bosch (2004) "Software architecture analysis of usability." EHCI-DSVIS'04 Proceedings of the 2004 international conference on Engineering Human Computer Interaction and Interactive Systems. Springer-Verlag Berlin, Heidelberg. p. 38.

G - L

edit
  • 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.
  • 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.
    • Rick Kazman (1998) in: L. Bass, P. Clements, and R. Kazman (1998) Software Architecture in Practice, Addison Wesley Longman. Chapter 2.
  • 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.
    • Rick Kazman (2001) "Software architecture." in: Handbook of Software Engineering & Knowledge Engineering. Shi Kuo Chang ed. p. 47.
  • When software applications became larger and larger, people such as Shaw and Garlan coined the term software architecture. This notion of architecture deals with the key design principles underlying software artefacts. In the 1980s and 1990s, people became aware that the development of information technology (IT) should be done in conjunction with the development of the context in which it was used. This led to the identification of the so-called business/IT alignment problem. Solving the business/IT alignment problem requires enterprises to align human, organizational, informational, and technological aspects of systems. Quite early on, the term architecture was also introduced as a means to further alignment, and thus analyzes and solves business?IT alignment problems, Recently, the awareness emerged that alignment between business an IT is not enough, there are many more aspects in the enterprise in need of alignment. This has led to the use of the term architecture at the enterprise level: enterprise architecture.
    • Martin Op 't Land, Erik Proper (2009) Enterprise Architecture: Creating Value by Informed Governance. p. 26-27.
  • 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.

M - R

edit
  • The software architecture of a system or a family of systems has one of the most significant impacts on the quality of an organization's enterprise architecture. While the design of software systems concentrates on satisfying the functional requirements for a system, the design of the software architecture for systems concentrates on the nonfunctional or quality requirements for systems. These quality requirements are concerns at the enterprise level. The better an organization specifies and characterizes the software architecture for its systems, the better it can characterize and manage its enterprise architecture. By explicitly defining the systems software architectures, an organization will be better able to reflect the priorities and trade-offs that are important to the organization in the software that it builds.
    • James McGovern, Scott W. Ambler and M. E Stevens (2004) A Practical Guide to Enterprise Architecture. p. 35.
  • 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.
    • James McGovern, Scott W. Ambler and M. E Stevens (2004) A Practical Guide to Enterprise Architecture. p. 36.
  • Software architecture is becoming an important part of software design, which helps developers to handle the complexity of large systems.
    • Amparo Navasa, Miguel Angel Pérez, and Juan Manuel Murillo. "Aspect modelling at architecture design." Software Architecture. Springer Berlin Heidelberg, 2005. p. 41.
  • By analogy to building architecture, we propose the following model of software architecture:
Software Architecture = { Elements, Form, Rationale ]
That is, a software architecture is a set of architectural (or, if you will, design) elements that have a particular form.

S - Z

edit
  • Although software architecture is an important discipline for software development, it can and should be complemented by other approaches such as, Design Patterns and Aspect-Oriented Software Development (AOSD)
    • Juliana Saraiva, Sérgio Soares, and Fernando Castor. "Assessing the impact of aosd on layered software architectures." Software Architecture. Springer Berlin Heidelberg, 2010. p. 344.
  • software architecture involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components. Such a system may in turn be used as a (composite) element in a larger system design.
  • Software architecture is foundational to the development of large, practical software-intensive applications.
    • Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy (2009). Software architecture: foundations, theory, and practice. Wiley Publishing.
  • Software architecture is a relatively young discipline. There is as much confusion in it as there is excitement. In the literature one finds far too many perspectives, approaches, methodologies, frameworks, techniques and tricks.
    • ‎Varma Vasudeva (2009) Software Architecture: A Case Based Approach. p. 2.

See also

edit
edit
 
Wikipedia
Wikipedia has an article about:
 
Commons
Retrieved from "https://en.wikiquote.org/w/index.php?title=Software_architecture&oldid=1815033"