Recent developments of Large Language Models (LLMs) show great potential in many areas, including software architecture. Although there is some work on applying LLMs during architecture design, using LLMs for adaptation of the architecture of a collective adaptive system at runtime has not yet been explored enough. In this paper, we explore two approaches for how LLMs can serve for architecture adaptation of collective adaptive systems based on autonomic component ensembles. The first approach employs an LLM during runtime as a part of the adaptation manager; the other one asks the LLM to generate it (in Python), which is then used for the ensemble formation (resolution) at runtime. The prompts for both approaches are automatically generated from an architectural specification, which includes constraints for the architecture. Based on experimental observations of two use cases, we show that LLMs are quite capable in online prompting in particular. Even without being explicitly provided with an adaptation strategy, an LLM can come up with an efficient heuristic for ensemble resolution and realize it. We show that the limiting factor for using LLMs this way is not time complexity (as would be the case when solving the problem as constraint optimization), but the “laziness” of LLMs when prompted with a larger problem instance, as also recently reported in other works. In addition, we map how the correctness of the LLM’s solution scales with different forms of prompting and problem size, which captures the effect of the LLMs’ laziness under different conditions.

Abstract Ensemble-based component systems have been used for many years to develop collective adaptive systems (CAS). The DEECo component model offers a framework for modeling and implementing ensemble-based component systems. Being expressive enough and having semantics specifically tailored towards dynamically evolving systems, DEECo has proven to be fairly powerful in modeling complex and dynamic architectures. We see great potential in employing large language models (LLMs) to simplify creating and refining the DEECo architectures. Since this constitutes a large research scope, in this paper, we focus on initial experiments to demonstrate how well generic LLMs (two OpenAI models executed remotely and four open-source models executed locally) understand the advanced concepts of ensemble-based CAS embodied in DEECo. We do so by systematically asking six questions about specific details of three DEECo applications that differ in the way they are specified. Our results indicate that LLMs can indeed understand ensemble-based architectures and show how this is influenced by the specification means. In particular, using external DSL, which is very self-explanatory, gave good results out of the box. Specifications embedded in existing programming languages needed a prior explanation of how to interpret them.

Abstract Smart system applications (SSAs)—a heterogeneous landscape of applications of Internet of things, cyber-physical systems, and smart sensing systems—are composed of autonomous yet inherently cooperating components. An important problem in this area is how to hoist the cooperation of software components forming dynamic groups—ensembles—at the architectural level of an SSA. This is hard since ensembles can overlap, be nested, and be dynamically formed and dismantled based on several criteria. A related problem is how to combine component and ensemble specification with a well-established language supported on multiple platforms. To target these problems, we propose a specification and implementation language Trait-based COmponent Ensemble Language (TCOEL) based on Scala internal DSL, to describe both the architecture and formation of dynamic ensembles of components and their functional internals. To raise the level of expressivity, we introduce the concept of domain-specific extensions (traits) to the TCOEL core to reflect different paradigms’ concerns—such as movement in a 2D map, state-space modeling of physical processes, and statistical reasoning about uncertainty. This allows for configuring TCOEL for the needs of a specific SSA use case and, at the same time, facilitates reuse. To evaluate TCOEL, we show how it can be beneficially used in addressing the coordination of agents in a RoboCup Rescue Simulation application.

The dynamic nature of complex Cyber-Physical Systems puts extra requirements on their functionalities: they not only need to be dependable, but also able to adapt to changing situations in their environment. When developing such systems, however, it is often impossible to explicitly design for all potential situations up front and provide corresponding strategies. Situations that come out of this “envelope of adaptability” can lead to problems that end up by applying an emergency fail-safe strategy to avoid complete system failure. The existing approaches to self-adaptation cannot typically cope with such situations better—while they are adaptive (and can apply learning) in choosing a strategy, they still rely on a pre-defined set of strategies not flexible enough to deal with those situations adequately. To alleviate this problem, we propose the concept of meta-adaptation strategies, which extends the limits of adaptability of a system by constructing new strategies at runtime to reflect the changes in the environment. Though the approach is generally applicable to most approaches to self-adaptation, we demonstrate our approach on IRM-SA—a design method and associated runtime model for self-adaptive distributed systems based on component ensembles. We exemplify the meta-adaptation strategies concept by providing three concrete meta-adaptation strategies and show its feasibility on an emergency coordination case study.

Textual use-cases have been traditionally used in the initial stages of the software development process to describe software functionality from the user's perspective. Their advantage is that they can be easily understood by stakeholders and domain experts. However, since use-cases typically rely on natural language, they cannot be directly subject to a formal verification. In this article, we present a method (called Formal Verification of Annotated Use-Case Models, FOAM) for formal verification of use-cases. This method features simple user-definable annotations, which are inserted into a use-case to make its semantics more suitable for verification. Subsequently, a model-checking tool is employed to verify temporal invariants associated with the annotations. This way, FOAM allows harnessing the benefits of model checking while still keeping the use-cases understandable for non-experts.

Cyber-physical systems (CPS) are systems of cooperating autonomous components which closely interact with and control the physical environment. Being distributed and typically based on periodic activities, CPS have to cope with the problem that data capturing a distributed state of the system and its environment are inherently inaccurate (they represent belief on the state). In particular, this poses a problem when dependability is being pursued. In this paper we address this issue by modeling belief at the architecture level. In particular, we enhance the architecture by models describing belief inaccuracy over time. We exploit these models to quantify at runtime the impact of belief staleness on its inaccuracy. We then use this quantification to drive architectural adaptation with the aim to increase dependability of the running CPS system.

Abstract Component-based development is a well-established methodology of software development. Nevertheless, some of the benefits that the component based development offers are often neglected. One of them is modeling and subsequent analysis of component behavior, which can help establish correctness guarantees, such as absence of composition errors and safety of component updates. We believe that application of component behavior modeling in practice is limited due to huge differences between the behavior modeling languages (e.g., process algebras) and the common implementation languages (e.g., Java). As a result, many concepts of the implementation languages are either very different or completely missing in the behavior modeling languages. As an example, even though behavior modeling languages are practical for modeling and analysis of various message-based protocols, they are not well suited for modeling current component applications, where thread-based parallelism, lock-based synchronization, and nested method calls are the essential building blocks. With this in mind, we propose a new behavior modeling language for software components, Threaded Behavior Protocols (TBP). At the model level, TBP provides developers with the concepts known from the implementation languages and essential to most component applications. In addition, the theoretical framework of TBP provides a notion of correctness based on absence of communication errors and a refinement relation to verify correctness of hierarchical components. The main asset of TBP formalism is that it links together the notion of threads as used in imperative object oriented languages and the notion of refinement. For instance, this allows reasoning about hierarchical components composed of primitive components implemented in Java without the need of bridging abstractions and simplifications enforced by the modeling languages.

SUMMARY This paper has been motivated by experience gained with specification and code generation of control elements for a software component platform and general‐purpose programming language like Java and C. The problem to be addressed is two‐fold: first, several domain‐specific languages (DSL) are to be employed to express different element concerns (architecture, deployment context, code pattern) and second, porting to another general‐purpose language should avoid modification of the specification and related code generation process as much as possible. In both respects, the classical template‐based code generation technique proved to be inflexible, requiring the code generator to be blurred with ad hoc encoded DSL facets. The paper addresses the problem by introducing the concept of interoperable DSL family. Each member of the family is built around its core language, which can be further specialized by embedding into a target programming language. Interoperability of these DSLs is achieved at the level of abstract syntax trees (ASTs) with help of queries. As a proof of the concept, we have implemented the queries via the AST transformation rules of the Stratego/XT framework. In the evaluation, we provide a comparison with the original template‐based implementation, which clearly indicates the DSL family and AST transformation benefits. We also provide examples of application areas where the concept of interoperable DSL family can be employed (and also indicate how this can be accomplished). Copyright © 2012 John Wiley & Sons, Ltd.

Abstract To allow efficient and user‐friendly development of a component‐based application, component systems have to provide a rather complex development infrastructure, including a tool for component composition, component repository, and a run‐time infrastructure. In this paper, we present and evaluate benefits of using meta‐modeling during the process of defining a component system and also during creation of the development and run‐time infrastructures. Most of the presented arguments are based on a broad practical experience with designing the component systems SOFA and SOFA 2; the former designed in a classical ad hoc ‘manual’ way, whereas the latter with the help of meta‐modeling. Copyright © 2010 John Wiley & Sons, Ltd.

Component-based development has become a recognized technique for building large scale distributed applications. Although the maturity of this technique, there appears to be quite a significant gap between (a) component systems that are rich in advanced features (e.g., component nesting, software connectors, versioning, dynamic architectures), but which have typically only poor or even no runtime support, and (b) component systems with a solid runtime support, but which typically possess only a limited set of the advanced features. In our opinion, this is mainly due to the difficulties that arise when trying to give proper semantics to the features and reify them in development tools and an runtime platform. In this paper, we describe the implementation of the runtime environment for the SOFA 2.0 component model. In particular, we focus on the runtime support of the advanced features mentioned above. The described issues and the solution are not specific only to SOFA 2.0, but they are general and applicable to any other component system aiming at addressing such features.

Component-based software engineering is a powerful paradigm for building large applications. However, our experience with building application of components is that the existing advanced component models (such as those offering component nesting, behavior specification and checking, dynamic reconfiguration to some extent, etc.) are subject to a lot of limitations and issues which prevent them from being accepted more widely (by industry in particular). We claim that these issues are specifically related to (a) the lack of support for dynamic reconfigurations of hierarchical architectures, (b) poor support for modeling and extendibility of the control part of a component, and (c) the lack of support for different communication styles applied in inter-component communication. In this paper, we show how these problems can be addressed and present an advanced component system SOFA 2.0 as a proof of the concept. This system is based on its predecessor SOFA, but it incorporates a number of enhancements and improvements

Although there exist several software model checkers that check the code against properties specified e.g. via a temporal logic and assertions, or just verifying low-level properties (like unhandled exceptions), none of them supports checking of software components against a high-level behavior specification. We present our approach to model checking of software components implemented in Java against a high-level specification of their behavior defined via behavior protocols, which employs the Java PathFinder model checker and the protocol checker. The property checked by the Java PathFinder (JPF) tool (correctness of particular method call sequences) is validated via its cooperation with the protocol checker. We show that just the publisher/listener pattern claimed to be the key flexibility support of JPF (even though proved very useful for our purpose) was not enough to achieve this kind of checking

Abstract Dynamic evolution inherently involves dynamic update and the issue of its atomicity. We show how this issue can be addressed in a similar manner to a communication failure via an extension to behavior protocols. First, we discuss the problem of defining a composition operator for behavior protocols so as to be able to reflect communication failures. Classical architecture description languages (ADLs) supporting behavior description, such as Wright and TRACTA, use a CSP‐like parallel composition, which inherently yields only ‘successful traces’ ignoring non‐accepted communication attempts. We show that component composition can produce several different types of behavior errors: bad activity, no activity, and divergence. The key idea behind bad activity is that real programs typically have an asymmetry of roles during event exchange: the caller is considered to be the initiator of the call while the callee has only a passive role. This contrasts with most formal systems, which treat communication symmetrically. We propose a new composition operator, ‘consent’, which reflects these types of errors by producing erroneous traces. By using the consent operator it can be statically determined whether the atomicity of a dynamic update of a component is implicitly guaranteed by the behavior of its current environment. Copyright © 2005 John Wiley & Sons, Ltd.

Reuse is one of the key benefits of components. It inherently means that the functionality of a component may be employed only partially. This triggers the issue whether all of the component's interfaces have to be really bound to the other components in its current environment (missing binding problem). Assuming each of the components is equipped by its behavior protocol (F. Plasil et al., 2002), we show that missing bindings can be statically identified via verification tools, in particular by employing the concept of bad activity error introduced in (J. Adamek et al., 2004).

In this paper, we propose a means to enhance an architecture description language with a description of component behavior. A notation used for this purpose should be able to express the "interplay" on the component's interfaces and reflect step-by-step refinement of the component's specification during its design. In addition, the notation should be easy to comprehend and allow for formal reasoning about the correctness of the specification refinement and also about the correctness of an implementation in terms of whether it adheres to the specification. Targeting all these requirements together, the paper proposes employing behavior protocols which are based on a notation similar to regular expressions. As proof of the concept, the behavior protocols are used in the SOFA architecture description language at three levels: interface, frame, and architecture. Key achievements of this paper include the definitions of bounded component behavior and protocol conformance relation. Using these concepts, the designer can verify the adherence of a component's implementation to its specification at runtime, while the correctness of refining the specification can be verified at design time.

To support rapid software evolution, it is desirable to construct software systems from reusable components. In this approach, the architecture of a system is described as a collection of components along with the interactions among these components. Whereas the main system functional blocks are components, the properties of the system also strongly depend on the character of the component interactions. This fact gave birth to the “connector” concept which is an abstraction capturing the nature of these interactions. The problem tackled in this paper is that even though the notion of connectors originates in the earliest papers on software architectures [20, 15], connectors are currently far from being a typical first class entity in the contemporary component-based systems. By articulating the “deployment anomaly”, the paper identifies the role connectors should play when the distribution and deployment of a component-based application is considered. Further, we introduce a connector model reflected at all the key stages of an application’s development: ADL specification, deployment, and implementation.

In this paper, the authors share their experiences gathered during the design and implementation of the CORBA Persistent Object Service. There are two problems related to a design and implementation of the Persistence Service: first, OMG intentionally leaves the functionality core of the Persistence Service unspecified; second, OMG encourages reuse of other Object Services without being specific enough in this respect. The paper identifies the key design issues implied both by the intentional lack of OMG specification and the limits of the implementation environment characteristics. At the same time, the paper discusses the benefits and drawbacks of reusing other Object Services, particularly the Relationship and Externalization Services, to support the Persistence Service. Surprisingly, the key lesson learned is that a direct reuse of these Object Services is impossible.