Software Architecture and Software Design

This paper discusses the work of the software architect by describing a software architect's concerns and the documents that a software architect should produce. It proposes a definition of software architecture and discusses archtectural design criteria based on the idea that every architecture is expected to meet a specified set of goals. We start with a discussion of the meaning of "architecture", then discuss the goals of an architect, proceed to what's needed to achieve those goals, describe ways of documenting architectural design decisions, and finally discuss how to determine how well the design goals have been met for any given architecture.

2004

ACM Sigsoft Software Engineering Notes, 1992

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 wellestablished 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.

Software Architecture is a sub discipline of Software Engineering. The term software architecture intuitively denotes 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 software architecture also denotes the set of practices used to select, define or design a software architecture. Finally, the term often denotes the documentation of a system's "software architecture". Documenting software architecture facilitates communication between stakeholders, captures early decisions about the high-level design, and allows reuse of design components between projects.

Software architecture research has emerged over the past decade, as the fundamental study of the overall structure of software systems, particularly the relations among subsystems and components. Building the foundation for software architecture is the main focus of this paper. The paper started with developing an intuition for software architecture by appealing to several well-established architectural disciplines. Considering this intuition, a model of software architecture is presented that comprises of three components: elements, form, and rationale. The paper provides a classification of software architectures which turn out to be the foundation for the establishment of marketplaces for software components. The basis of component marketplace lies in the framework of key properties of software architecture. We can understand the development and scenario of software architecture research by examining the research paradigms used to establish its results.

2016

Software components encapsulate processing functionality and/or data. Components may just manage data without processing, provide processing for external data, or combine both. Access to their functionality and data is restricted through well defined interfaces and usage contracts. All dependencies to the execution environment are explicitly defined. Software connectors are architectural building blocks that regulate the interactions between components. Connectors can be much more sophisticated than method calls and shared data access, for example streams, event buses, multicasts, and adaptors. The system's configuration is a set of specific associations between components and connectors and the architectural topology governs design rules about these associations. Architectures can exist at quite different levels of abstraction. For example, the World Wide Web is an component-based architecture although no single peace of software implements the whole architecture. The takeaway herein is, that components do not necessarily have to be exactly the objects that are provided by some object-oriented programming language. Neither does such a programming language provide a reasonable architecture-except for very narrow minded languages. More general purpose languages simple defer more design decisions into the software architecture. An architectural pattern is a set of decisions that are applicable to a recurring design problem and can be reused in many different architectures. In contrast, an architectural style is a named collection of architectural design decisions and constraints that provide the foundation for architectures. Based on experience and reasoning, they result hopefully in better architectures with respect to functional and non-functional objectives. An architectural style consists of a vocabulary of design elements, composition rules, and a semantic interpretation. The vocabulary is a set of high-level types that categorize components, connectors, and data elements into, for example, clients, servers, pipes, sensors, actors, and regulators. The composition rules are a collection of allowable structural patterns that provide essential invariants of the style, for

ACM Computing Surveys, 1995

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.

Advances in Science, Technology and Engineering Systems Journal, 2019

Software architecture and design is an important component in the software engineering field. This aspect of software engineering covers the functional and non-functional requirements of any system being proposed to be developed, while software architecture deals with non-functional requirements, software design entails the functional requirements. The objective of this paper is to critically analyze current topics in Software architecture and design. The method of analysis involved the use of inclusion and exclusion criteria of papers published in journals and conferences. These papers were accessed from digital libraries like ScienceDirect, and IEEE explore, with a quantitative approach of analysis been imbibed. From the analysis, the result showed that, of 35 papers used in analysis, 34.3% discussed stakeholders' involvement and decisions in software design. 17.1% for design quality, 20% examined software reuse while 11.4% discussed software evaluation and 8.6% of papers reviewed discussed software management, evolution and software development life cycle each which should be more focused as it is the fundamentals of software design and architecture. From the analysis derived, stakeholder's involvement and decision in software design is an integral part in software building for effective use. Thereby making researchers dwell more on the topic. The least discussed topics was due to the expectations of researchers. Expecting readers to have a fore knowledge of the fundamentals of design which includes software management, evolution and software development life cycle.