A fresh look at programming-in-the-large

Abstract

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

Architectural Reflection Realising Software Architectures via Reflective Activities

“…In [5,4] we defined architectural reflection as the computation performed by a system about its own software architecture. An architectural reflective system is structured into two levels called architectural levels: an architectural base-level and an architectural meta-level.…”

Kaleidoscope

“…Such issues depend on specific application domain requirements and must be defined by the domain engineer without having to know the internal structure of the individual components (images and projectors). In other words, images and projectors are aware neither of the static structure nor of the dynamic behaviour of the system; this peculiarity can be summarised by saying that the components have "no implicit architecture" (Cazzola, et al, 1998a).…”

Real-time programming-in-the-large. The case of monitoring and control systems

“…In [6], [7], [9], and [8] we extended that notion by identifying four aspects of software architecture: components;…”