Available via license: CC BY 4.0
Content may be subject to copyright.
A preview of the PDF is not available
Only the Architecture You Need
Abstract
Arguably the prime focal point of a software system’s engineering is its architecture. A system’s architecture is the set of principal design decisions made during its development and evolution. All too often, however, the architecture—and every system has an architecture—is left latent. Such disregard arises from many factors; some would go so far as to say that an explicit focus on architecture is unnecessary. This chapter explores different contexts in which software development occurs and, with respect to those contexts, discusses what kind of attention to architecture is needed, why it is needed, how it may be approached, and benefits that may be achieved through such attention. The objective is to highlight the degrees of architectural rigor and effort that are commensurate with the needs of diverse projects.
... user code is called by the framework. Taylor [33] sees a framework as a programmatic bridge between concepts (such as "window" or "image") and lowerlevel implementations. Frameworks can map architectural styles into implementation and-or provide a foundation for an architecture. ...
Game engines help developers create video games and avoid duplication of code and effort, like frameworks for traditional software systems. In this paper, we explore game engines along three perspectives: literature, code, and human. First, we explore and summarise the academic literature on game engines. Second, we compare the characteristics of the 282 most popular engines and the 282 most popular frameworks in GitHub. Finally, we survey 124 engine developers about their experience with the development of their engines. We report that: (1) Game engines are not well-studied in software-engineering research with few studies having engines as object of research. (2) Game engines are slightly larger in terms of size and complexity and less popular and engaging than traditional frameworks. Their programming languages differ greatly from frameworks. Engine projects have shorter histories with less releases. (3) Developers perceive game engines as different from traditional frameworks and claim that engines need special treatments. Generally, they build game engines to (a) better control the environment and source code, (b) learn about game engines, and (c) develop specific games. We conclude that game engines are different from traditional frameworks although this difference is too small to force special treatments.
Game engines help developers create video games and avoid duplication of code and effort, like frameworks for traditional software systems. In this paper, we explore open-source game engines along three perspectives: literature, code, and human. First, we explore and summarize the academic literature on game engines. Second, we compare the characteristics of the 282 most popular engines and the 282 most popular frameworks in GitHub. Finally, we survey 124 engine developers about their experience with the development of their engines. We report that: (1) Game engines are not well-studied in software-engineering research with few studies having engines as object of research. (2) Open-source game engines are slightly larger in terms of size and complexity and less popular and engaging than traditional frameworks. Their programming languages differ greatly from frameworks. Engine projects have shorter histories with less releases. (3) Developers perceive game engines as different from traditional frameworks. Generally, they build game engines to (a) better control the environment and source code, (b) learn about game engines, and (c) develop specific games. We conclude that open-source game engines have differences compared to traditional open-source frameworks although this differences do not demand special treatments.
Software systems of today are frequently composed of prefabricated, heterogeneous components that provide complex functionality and engage in complex interactions. Existing research on component based development has mostly focused on component structure, interfaces, and functionality. Recently, software architecture has emerged as an area that also places significant importance on component interactions, embodied in the notion of software connectors. However, the current level of understanding and support for connectors has been insufficient. This has resulted in their inconsistent treatment and a notable lack of understanding of what the fundamental building blocks of software interaction are and how they can be composed into more complex interactions. The paper attempts to address this problem. It presents a comprehensive classification framework and taxonomy of software connectors. The taxonomy is obtained through an extensive analysis of existing component interactions. The taxonomy is used both to understand existing software connectors and to suggest new, unprecedented connectors. We demonstrate the use of the taxonomy on the architecture of a large, existing system
The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia application. The modern Web architecture emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems. In this article we introduce the Representational State Transfer (REST) architectural style, developed as an abstract model of the Web architecture and used to guide our redesign and definition of the Hypertext Transfer Protocol and Uniform Resource Identifiers. We describe the software engineering principles guiding REST and the interaction constraints chosen to retain those principles, contrasting them to the constraints of other architectural styles. We then compare the abstract model to the currently deployed Web architecture in order to elicit mismatches between the existing protocols and the applications they are intended to support.
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).
Decentralized systems are systems-of-systems whose services are governed by two or more separate organizations under distinct spheres of authority. Coordinated evolution of the various elements of a decentralized system may be difficult, if not impossible, as individual organizations evolve their service offerings in response to organization- and service-specific pressures, including market demand, technology, competitive and cooperative interests, and funding. Consequently, decentralized services offer unique challenges for evolution and adaptation that reach well beyond any one single organizational boundary. However, client-driven service customization and tailoring is a powerful tool for meeting conflicting, independent client demands in an environment where disorderly and uneven service evolution predominates. To this end, we contribute an architectural style, COmputAtional State Transfer (COAST), designed to provide extensive, safe, and secure client-directed customization of decentralized services. COAST combines mechanisms from software architecture, cryptography, security, and programming languages, granting application architects flexible provisioning of their core services and assets while protecting those services and assets from attack and misuse.
Design is relevant to all software engineering activities and is the central integrating activity that ties the others together. Thus, it is essential that software engineering education provide solid and in-depth instruction in design. While there is a good deal of current activity directed toward improving education in programming methods, we see little directed toward improving education in programming methods, we see little directed toward design education. Development of software engineering curricula offers an opportunity to place design in its proper perspective.
The purpose of this paper is to build the foundation for software architecture. Wefirstdevelop 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 importantarchitecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our ...
Computational state transfer: an architectural style for decentralized systems
- M M Gorlick
Gorlick, M.M.: Computational state transfer: an architectural style for decentralized systems.
Ph.D. Dissertation. Department of Informatics, University of California, Irvine (2016). http://
isr.uci.edu/sites/isr.uci.edu/files/techreports/UCI-ISR-16-3.pdf