As software systems become larger and more complex, a relevant part of code shifts from the application domain to the management of the system's run-time architecture (e.g., substituting components and connectors for run-time automated tuning). We propose a novel design approach for component-based systems supporting architectural management in a systematic and conceptually clean way and allowing for the transparent addition of architectural management functionality to existing systems. The approach builds on the concept of reflection, extending it to the programming-in-the-large level, thus yielding architectural reflection (AR). This paper focuses on one aspect of AR, namely the monitoring and dynamic modification of the system's overall control structure (strategic reflection), which allows the behaviour of a system to be monitored and adjusted without modifying the system itself.
Abstract. Architectural reflection is the computation performed by a software system about its own software architecture. Building on previous research and on practical experience in industrial projects, in this paper we expand the approach and show a practical (albeit very simple) example of application of architectural reflection. The example shows how one can express, thanks to reflection, both functional and non-functional requirements in terms of object-oriented concepts, and how a clean separation of concerns between application domain level and architectural level activities can be enforced.
Realizing a shift of software engineering towards a component-based approach to software development requires the development of higher level programming systems supporting the development of systems from components. This paper presents a novel approach to the design of large software systems where a program-in-thelarge describing the system's architecture is executed at run-time to rule over the assembly and dynamic cooperation of components. This approach has several advantages following from a clean separation of concerns between programming-in-the-small and programming-in-the-large issues in instantiated systems. 1: IntroductionFor thirty years software engineering has pursued a paradigm shift from line-based to component-based software development [8]. Component software requires high levels of reusability and interoperability, and brings forth a higher level of programming, namely the assembly of independently developed and reusable components into systems, termed programming-in-the-large (PIL) [3] as opposed to programming-in-the-small (PIS, i.e., the development of individual components). While objectoriented technology provides a sound basis for the development of both fine-and coarse-grained reusable components [5], we still lack adequate notations and tools for programming-in-the-large. Such notations should let system designers specify the "plan of how components fit together and cooperate" [6], i.e., the software architecture of the system [13].In current approaches to component software, software architectures are implicit, i.e., architectural decisions such as those related to the overall system's topology and global control structures are implemented in the components' code, which has several drawbacks. For example, components are less reusable and harder to integrate due to the architectural assumptions they embed [4].Based on these considerations, we propose a new approach to programming-in-the-large which is centred around two main ideas: the program-in-the-large of a system should describe the system's architecture; and it should be executed at run-time as an independent (higherlevel) program with respect to the components' programs. We term this approach Dynamic Architectural Programming-in-the-Large (DAPIL). This paper presents this vision. Section 2 provides the rationale for DAPIL by stating the implicit architecture problem underlying current approaches to component-based development. In section 3, we present a sample syntax and semantics for a programming language for DAPIL and in section 4 we sketch the component and system model underlying them. Section 5 discusses how our approach accommodates addressing dynamic architectures in a reflective way. Section 6 points out at some benefits of the proposed approach and section 7 draws some conclusion and presents future work. 2: The implicit architecture problemDesigning software architectures is a complex activity where very high-level decisions are taken affecting all the functioning of a system. For example, a phrase such as a "l...
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
hi@scite.ai
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.