DETECTING ARCHITECTURAL MISMATCHES DURING SYSTEMS COMPOSITION

Transcription

1 DETECTING ARCHITECTURAL MISMATCHES DURING SYSTEMS COMPOSITION by Cristina Gacek A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (Computer Science) December 1998 Copyright 1998 Cristina Gacek

2 To Beba, Cacho and Nauro ii

3 Acknowledgments The end of the tunnel is actually here! Now is the time to start the next stage, and I would like to do so by first recognizing the people that made the difference throughout my Ph.D. study years. First and foremost I must thank Nauro, my better half, for always being there, making it all possible and worthwhile. This whole process has brought us even closer. Both of our families deserve recognition for caring, cheering, and trying to understand the various stages involved. Barry Boehm, my advisor, has been a very special person to me. Not only has he supported me throughout the years, mentoring me when I needed, but he has also been a good friend. I deeply appreciate that. My committee members Dave Wile and Eb Rechtin must also be acknowledged. I must thank Dave for his deep involvement, actually bringing up new ideas and helping me evolve them, as well as for the occasional pub stops during various workshops. Dr. Rechtin was probably the most involved and knowledgeable outside committee member in history. He not only devoted his time to reading the material I gave him, but always had pertinent and intelligent comments to make. Tony Wasserman has been an inspiration to me. His eagerness to help and timely mentoring are admirable. Both he and Barry Boehm have taught me a lot about professional posture and inter-personal relations. I wish more people were like them. I will also have nice memories of Judy Kerner, Frank Belz and Andrew Landisman. They were always willing to hear my sorrows and had a friendly word of support. iii

4 Last but not least come my friends. Many have come and gone during my studies at USC, but they were all important. I will certainly miss our technical discussions, as well as the chats about politics, movies, various cultures, the weather, and anything imaginable. I will also miss our hiking events, climbing outings, workouts, going to the beach, phone conversations, and simply sitting in the sun to warm up a bit. I refuse to list their names here in fear of forgetting an important one, but I am sure they know who they are. iv

5 Table of Contents Part I: Introduction Introduction...2 Part II: Related Work Related Work COMPLEMENT Shaw and Clements Kazman, Clements, Abowd, and Bass Stiger and Gamble Abd-Allah Architecture Description Languages (ADLs) ACME Aesop C Darwin MetaH Rapide SADL UniCon Wright Part III: Contribution Approach Description Extending the AAA Model Styles Descriptions Revisiting Event-Based Blackboard Rule-Based Logic Programming Transactional Database-Centric Real-Time Closed-Loop Feedback Control Internet Distributed Entities Conceptual Features Descriptions Concurrency Distribution Dynamism Encapsulation Layering Supported Data Transfers Triggering Capability v

6 5.1.8 Backtracking Control Unit Component Priorities Preemption Reconfiguration Reentrance Response Times Styles Choices Distributed Processes Event-Based Main-Subroutine Pipe-and-Filter Transactional Database-Centric Blackboard Rule-Based Logic Programming Real-Time Closed-Loop Feedback Control Internet Distributed Entities Conceptual Features Table Revisited Conceptual Feature Space Architectural Mismatches Architectural Mismatches Examples Architectural Mismatches Table Modeling Styles and Their Features Basic Entities Model Modeling the Conceptual Features Complete Model of Styles Pipe and Filter Main/Subroutine Distributed Processes Event-Based Blackboard Database Centric Rule-Based Logic-Programming Real Time Closed Loop Feedback Control Internet Distributed Entities Modeling Composition and Mismatches Detection Compositional Mismatch Analysis Abstraction on Paper The AAA Model The AAA Tool Miscellaneous Part IV: Conclusion vi

7 9.0 Summary of Key Contributions Future Directions Part V: Bibliography and Appendices Bibliography Appendices Appendix A: Introduction to the ZSL Notation Appendix B: Abd-Allah s Z Model Appendix C: Our Z Model Appendix D: Time Related Classification of Systems and Operations Appendix E: AAA Mismatch Analysis Results for Real-Time vs. All Other Styles Appendix F: Acronyms vii

8 viii

9 List of Figures Figure 1: Extending the Base Entities to Style-Specific Entities...21 Figure 2: Mismatch #2 of Group Operation...23 Figure 3: Horizontal Composition Example...37 Figure 4: Data Flow Issues Axis...76 Figure 5: Control Flow Issues Axis...76 Figure 6: Organizational Issues Axis...76 Figure 7: AAA - Project Menu Figure 8: AAA - Project New Figure 9: AAA - Artifacts Menu Figure 11: AAA - NewName Figure 10: AAA - Styles List Figure 12: AAA - Style Figure 13: AAA - Subsystem Figure 14: AAA - Subsystem Backtracking Figure 15: AAA - Subsystem Component Priorities Figure 16: AAA - Subsystem Concurrency Figure 17: AAA - Subsystem Control Unit Figure 31: AAA - Tools Menu Figure 18: AAA - Subsystem Distribution Figure 19: AAA - Subsystem Dynamism Figure 20: AAA - Subsystem Encapsulation Figure 21: AAA - Subsystem Layering Figure 22: AAA - Subsystem Preemption Figure 23: AAA - Subsystem Reconfiguration Figure 24: AAA - Subsystem Reentrance Figure 25: AAA - Subsystem Response Time Figure 26: AAA - Subsystem Supported Data Transfers Figure 27: AAA - Subsystem Triggering Capability Figure 28: AAA - System Figure 29: AAA - System Subsystems Figure 30: AAA - System and Connections Figure 32: AAA - Mismatch Analysis Figure 33: AAA - Mismatch Analysis Results Figure 34: AAA - Mismatch Analysis Results List viii

10 ix

11 List of Tables Table 1: A Feature-Based Classification of Architectural Styles...14 Table 2: Temporal Features of Architectural Elements...16 Table 3: Static Features of Architectural Elements...17 Table 4: Four Instances in an Architectural Style Space...23 Table 5: Mismatches Related to the Conceptual Features...24 Table 6: Instances of Our Architectural Style Space...73 Table 7: Instances of Our Architectural Style Space (cont.)...74 Table 8: Architectural Mismatches...81 Table 9: Real-Time and Internet Distributed Entities Styles Features Table 10: RT and ID Systems Features Table 11: Mismatches Related to the Call Bridging Connector Table 12: Operation Invokes Table 13: Operation Followed_By Table 14: Operation Interrupted_By ix

12 Abstract The USC Architect s Automated Assistant (AAA) tool and method version 0.1 [Abd-Allah 1996] provides a capability for early detection of software architectural style mismatches among four architectural styles: Main-Subroutine, Pipe-and-Filter, Event- Based, and Distributed Processes. For these four styles, mismatch detection is based on a set of seven conceptual features distinguishing each style, and a set of bridging connectors characterizing compositions among the four styles. However, it was a significant open question whether these conceptual features and connectors were sufficient to characterize composition of other architectural styles. The work presented here formalizes some additional architectural styles-- namely Blackboard, Closed-Loop Feedback Control, Logic Programming, Real-Time, Rule-Based, Transactional Database, and Internet Distributed Entities styles--and extends the mismatch analysis capability to cover interactions of the original four styles with the new ones. The analysis results tested various hypotheses, such as the extensibility of the conceptual feature framework for mismatch detection, and the sufficiency of the original seven conceptual features to characterize the broader set of styles and their composition. In our work we found that the underlying conceptual feature framework could work to cover a broader range of styles and systems, with some extensions. However, the conceptual feature set and the underlying Z-language formal model were not sufficient to cover the full range of styles and systems interactions. We have developed extensions to the conceptual feature set and Z formal model to cover the full set of compositional interactions analyzed. Additionally, we pro- x

13 vide means for checking each and every mismatch at the model level, including the dynamic ones, as well as a fully operational tool. We also provide an initial discussion of a more formal basis for detecting and classifying architectural conceptual features, thus providing a formal framework for extending the models. xi

14 Part I: Introduction In the following section, we present a description of the problem which this work addresses, while discussing a few relevant concepts such as megaprogramming, software architectures, and software architectural styles. We also give a short introduction to Abd-Allah s dissertation work [Abd-Allah 1996] that was used as the starting point for this work, accompanied by brief comments on what this evolution effort entialed. 1

15 1.0 Introduction Megaprogramming [Boehm and Scherlis 1992], the practice of software construction in a component-oriented fashion heavily based on software components reuse, has long been recognized as an important solution for the software crisis [McIlroy 1969] [Radice and Phillips 1988]. It is a powerful means of not only reducing software development costs in the long run, but also reducing the risk of project failure, improving software quality, shortening development time, and greatly increasing the productivity of the individual software developer. One of the major elements that determine the success of an environment using megaprogramming is the actual reuse of available software components with a minimum amount of effort. This involves the software engineer determining the need for a component that is already available, effectively selecting the component that does actually fulfill his/her need, and appropriately using it. Some of the difficulties with past reuse attempts have been in determining the amount of effort it takes to produce reusable components, estimating the number of components to reuse, effectively selecting reusable components, and adapting components originally thought completely reusable to subtle differences in domain and/or architectural assumptions (about timing, synchronization, data forms, coordinate systems, environment models, etc.). Facets were used to simplify the process of selecting reusable components [Prieto-Diaz and Freeman 1987] [Gacek 1995], but still underlying assumptions were ignored. Handling, or rather detecting, the differences in underlying architectural assumptions is the focus of this work. 2

16 The Domain Specific Software Architecture (DSSA) approach was created with the intention of providing an effective megaprogramming environment, where all components contain the same underlying domain and architectural assumptions. A DSSA is a process and infrastructure that support the development of a Domain Model, Reference Requirements, and Reference Architecture for a family of applications within a particular problem domain. The expressed goal of a DSSA is to support the generation of applications within a particular domain (also known as a product-line) [Tracz 1994]. An architecture in a specific domain will identify the domain s conventions and shared assumptions, the required degree of generality (number of parameters that can change) and integrability (how a component fits within the context of the application). This approach can be very successful, but it is not always feasible considering its very large up front investment required for building the infrastructure. Nowadays, in order to be competitive, a developer s usage of Commercial off the Shelf (COTS), or Government off the Shelf (GOTS), packages has become a sine qua non, at times being an explicit requirement from the customer. The idea of simply plugging together various COTS packages and/or other existing parts results from the megaprogramming principles. What people tend to underestimate are the side effects resulting from the plugging or composition of these subsystems. Some COTS vendors tend to preach that because their tool follows a specific standard, say CORBA, all composition problems disappear. Well, it actually is not that simple. Side effects resulting from the composition of subsystems are not just the result of different assumptions in communication methods by various subsystems, but the result from differences in various sorts of 3

17 assumptions, such as the number of threads that are to execute concurrently, or even on the load imposed on certain resources. This problem is referred to as architectural mismatches [Garlan et al. 1995a][Abd-Allah 1996]. Some but not all of these architectural mismatches can be detected via domain architecture characteristics, such as mismatches in additional domain interface types (units, coordinate systems, frequencies), going beyond the general interface types in standards such as CORBA. Another significant source of architectural mismatches derives from mismatches among architectural styles or sets of architectural features. An architectural style defines a family of systems based on a common structural organization [Shaw and Garlan 1996]. It constrains both the design elements and the formal relationships among the design elements [Perry and Wolf 1992]. 1 Some of these constraints are common to various styles, for example having explicit data connectors to support data transfers between components is not a characteristic only present in the pipeand-filter style, but it also occurs in the distributed processes one. The absence of these constraints in other styles is just as important, e.g., the main-subroutine style does not have explicit data connectors, but rather uses shared variables for data transfers by definition. A set of these special constraints was defined by Abd-Allah, and called the set of conceptual features [Abd-Allah 1996]. 2 Different styles can then be characterized by 1. One can find various definitions of software architectures in the literature [Perry and Wolf 1992] [Shaw and Garlan 1996] [Tracz 1994]. The one used throughout this work we introduced in a previous paper [Gacek et al. 1995]. Namely, we consider an architecture to be a set of components, connectors, constraints imposed on the components, connectors, and their composition, and a supporting rationale. Such architectures should be presentable in various ways--different views supporting different needs. 2. Other classification efforts do exist, and are covered in the related work section (section 2.0 on page 10). 4

18 selecting different options for each conceptual feature. That is, a style is defined by a set of conceptual feature choices, where individually, each of those choices may also exist in some other style. Once a complete set of conceptual features is defined, 1 we will be able to use them to differentiate the various architectural styles and/or systems by concentrating on these abstract characteristics. Abd-Allah s work on conceptual features was based on the distributed processes, event-based, layered, main-subroutine, multithreaded, pipe-and-filter, and software bus styles. 2 Our work tested the hypothesis that his approach of using conceptual features for mismatch detection was extensible to cover a broader set of mismatches, and that his set of conceptual features is sufficient to characterize other styles, namely blackboard, closed-loop feedback control, logic programming, real-time, rulebased, transactional database, and internet distributed entities styles (see section 3.0). We also started working towards determining the various dimensions that could be used to describe orthogonality of the various conceptual features, thus providing a more formal description of the conceptual feature space (section 5.3). When actually building systems, people may or may not adhere to a pure architectural style, also the same style name may mean slightly different things to different people. For example, in some pipe-and-filter analyses, [Shaw and Garlan 1996] has found it useful to employ the concepts of colored pipes and parametrized filters. In cases where some variation of an existing style is used, a complete set of conceptual features should 1. It is not the aim of this work to generate a complete set of conceptual features, specially because there is no way of proving completeness here. 2. See section 2.5 on page 19 for a complete description of his work, as well as how it compares to the work presented here. 5

19 suffice for description. Clearly, if some completely new style comes along, using some revolutionary paradigm, the set of conceptual features needs to be revisited, and potentially extended. The use of COTS and GOTS packages brings a slightly different light into the problem. Hardly ever will a COTS vendor be willing to explicitly describe all the intrinsics of their package to the general public. In such cases, the use of conceptual features becomes a facilitator, since vendors may be willing to give out at least general information on these characteristics--they do describe the system and often help describe API s, without giving away secrets that could reduce the vendor s competitive advantage. When composing systems, many potential architectural mismatches can be detected by analyzing their various choices for conceptual features. Mismatches may occur because the subsystems have different choices for some particular feature. For example, one is multi-threaded and the other is not, creating the possibility of synchronization problems when accessing shared data (the single-threaded part assumes there is absolutely no risk of interference). Mismatches may also occur because the subsystems make the same choice for some particular feature. For example, if two subsystems are single-threaded, we may also run into synchronization problems when accessing some shared data, since both parts assume there can be no interference. It is extremely important to point out that different architectural styles may have different meanings to different people, as well as that occasionally there is a need to use a slightly adapted style (non-pure), especially when describing a previously existing system (either OTS or from a components library). Thus, by working at the conceptual 6

20 feature level for mismatch detection, we can cover a much wider range of systems composition than if we dealt with the problem in a style by style basis. The aim of this dissertation is to formally address software composition at the architectural level while detecting architectural mismatches. We chose to do so by addressing a number of open questions in the previous work by Abd-Allah in order to get a greater and more formal coverage of conceptual features, and their relations to architectural mismatches. We specifically looked into his hypotheses that architectural mismatches are derivable from conceptual features, that his 16 mismatches were a comprehensive set of mismatches that are detectable based on conceptual features, and that his conceptual feature set should suffice for mismatch detection. Succinctly, the problem examined is: What is a formal model for detecting potential architectural mismatches during the composition of software systems? Where must current formal models be further structured and extended to cover mismatches among wider ranges of architectural styles? In order to address the questions above, we needed to understand the complexities of systems composition and its potential side effects. It was also necessary to have a firm grasp on the characteristics of a wide range of architectural styles, and their relevance to composition. As a means of providing a model supporting the concepts uncovered, it was also essential to have a deep understanding of the formalism to be used, and provide some mechanism to analyzing given formal specifications. 7

21 As a result of our effort, we did show that Abd-Allah was correct in assuming that using conceptual features for mismatch detection was an extensible framework, though it did require a considerable amount of effort to do so. We also found that Abd- Allah s 16 mismatches were far from being a robust set of mismatches that are detectable based on conceptual features. Furthermore, his assumption that his conceptual feature set should suffice for mismatch detection was incorrect. While aiming to provide the proper support required to address our central problem, and strengthen Abd-Allah s initial work we had to considerably evolve his conceptual feature (section 5.0 on page 58) and mismatch sets (section 6.0 on page 78). Consequently, we had to perform major changes to the AAA formal model he provided (section 7.0 on page 93). Additionally, we incorporated in the model operations for explicitly detecting each and every one of the mismatches, including the dynamic ones (section 7.4). 1 One should note that this work not only provides a formal model to support architectural composition, but a fully operational tool is also provided to automate this compositional analysis (section 8.3 on page 155). 1. A more detailed description on how the AAA framework evolved is provided in section 3.1 on page 45. 8

22 Part II: Related Work Other researchers have been working on software architectures and their composition, architectural styles and their classification, and systems classification based on conceptual features. The following section describes some of their results, and discusses the deficiencies of these past efforts with respect to addressing the central question of this dissertation. It also includes some discussion on various ADLs and their approach to composition of heterogeneous systems. 9

23 2.0 Related Work There are several related works that should be discussed here. They cover topics such as real-time systems classification while considering a different set of conceptual features by the COMPLEMENT project (section 2.1), architectural styles and their classification by Shaw and Clements (section 2.2), architectural elements classification by Kazman and his colleagues (section 2.3), Stiger and Gamble s Z formal model of the blackboard style (section 2.4), and Abd-Allah s dissertation work on detecting architectural mismatches during systems composition, while focusing on the main-subroutine, pipe-and-filter, distributed processes, and event-based styles (section 2.5). Some architecture description languages (ADLs) and their supporting tools are also discussed (section 2.6). 2.1 COMPLEMENT The COMPLEMENT project focuses on technical aspects of developing realtime and embedded systems [Pyle et al. 1993]. In order to understand what particular features make real-time and embedded systems different from other systems, and what differentiates one kind of real-time and embedded system from another, they devised a domain specific system taxonomy (where the domain is simply real-time and embedded). Their taxonomy consists of sets of primary, secondary, and concrete features. Their primary features are: concurrent processing (many or few concurrent events); hardware interface (significant or not); timed reaction to events (hard or soft real-time 1 ); distribution (multiple or single site); and database (significant or not). Their secondary features 10

24 are: dependability (high or low); reconfigurability (on or off-line); usability--human/computer interface (intuitive or need training); certifiability (essential or not required); constraints--environmental aspects (significant or not); and evolution capability (evolutionary or not). Their concrete features are: target platform; type of external transducers; replication; contractual requirements; and application domain. The COMPLEMENT project uses their system taxonomy as a real-time and embedded systems classification facilitator, and not as the focus of compositional analysis. Still the features they use can give us some insight on characteristics we may need to consider for our compositional purposes. At first glance, their set of primary and concrete features should be a part of the issues considered for composition, whereas their secondary features, which are mainly quality attributes are not as relevant. A closer look at their primary features reveals that whereas having a significant hardware interface may change dramatically a system s performance (as opposed to one that has a more significant human interface), this characteristic is outside the scope of this work. All other primary features are very relevant for composition, and thus part of our conceptual features. 1 Most of their secondary features, being quality attributes could be considered here, but actually go beyond what this work is addressing. The only one that is useful to include is the one indicating whether a system is reconfigurable on or off-line. During 1. Hard real-time requirements are those that if the system reacts too late, it is considered to fail. On the other hand, soft real-time requirements are those that it is undesirable that the system reacts too late, but it is not considered a failure if it happens. 1. Note that in our case, timed reaction to events may take the values predictable, bounded, unbounded, and cyclic, as well as unconstrained. 11

25 composition, if one of the subsystems expects to be able to reconfigure on-line while the other does not, we might run into problems. From their set of concrete features, two do not apply here, namely contractual requirements and application domain. During composition, one would only consider an existing system to be reused if it was known to conform to the contractual requirements at hand, be them on programming language, standards or any other. As far as application domain goes, the only difference this could bring to a composition consideration is on the quality attributes originally required of the sub-system. As already mentioned above, on the discussion of the secondary features, quality attributes and their detection at the architecture level are very important, but go beyond the focus of this work. 2.2 Shaw and Clements Shaw and Clements present a classification of architectural styles based on a set of features focusing on control and data issues. They do this by describing feature categories, and defining how each of several styles handles them. They also provide a few rules of thumb to aid on style selection when implementing solutions to specific problem instances [Shaw and Clements 1997]. The architectural style classification they propose is based on: the kinds of components and connectors that are used; how control is shared, allocated, and transferred within the system; how data is communicated through the system; how data and control interact; and the type of reasoning that is compatible with the style. As control issues they address the topology, synchronicity, and the binding time. Data issues include topology, 12

26 continuity (how continuous is the flow of data throughout the system?), mode (how is data made available throughout the system?), and binding time. Control/data interaction issues elaborated are whether control and data flow topologies have similar shapes or not, and if these shapes are the same, whether control and data flow in the same or opposite directions. They present their results in terms of a table. Their full classification can be found on their paper. In table 1 one can find some examples of their classification that can already be compared with results obtained by Abd-Allah (section 2.5), and by the work described in this document (section 5.0 on page 58). The granularity level of the features considered by Shaw and Clements is lower than the one to be used by this work to classify systems. The information they convey for classification purposes is part of our underlying model, but it is not considered at the conceptual features (more abstract) level. Exceptions are the fact that the model described in this document does not include information on types of reasoning supported by the style, nor information on control or data binding time. Mode of data transfers is the only one of their features that shows as a conceptual feature in our work. The focus of their paper is to classify styles while standardizing the vocabulary and concepts each involves, and discriminate among styles showing their differences and similarities, supporting for the organization of advice on how to select a style for solving a 13

27 specific problem. Since it is not part of their focus, they do not address compositional issues. Main program/ subroutine Event systems Blackboard Components procedures, data processes memory, computations Connectors procedure calls implicit invocation direct access Control topology hierarchical arbitrary star Synchronicity sequential asynchronous, opportunistic asynchronous, opportunistic Control binding write, compile invocation, run write time Data topology arbitrary arbitrary star Continuity sporadic, low-volume sporadic, low-volume sporadic, low-volume Mode passed, shared broadcast passed Data binding time write, compile, run invocation, run write, compile, run Isomorphic control/data shapes Control/data flow directions Type of reasoning no no yes n/a n/a opposite hierarchical (local reasoning) nondeterminism --- Table 1: A Feature-Based Classification of Architectural Styles 2.3 Kazman, Clements, Abowd, and Bass In a recent work [Kazman et al. 1997], related to that of Shaw and Clements (section 2.2), Kazman and his colleagues try to support system composition in a manner very similar to the one used here. They use behavioral characteristics which they call fea- 14

28 tures to classify architectural elements (components and connectors), not architectural styles nor systems. The behavioral characteristics they considered useful are temporal and static ones. A temporal view of architectural elements describes the behavior of an element over time. The temporal characteristics they address are: times of control acceptance; times of data acceptance; times of control and data transmission; if forks occur; and whether the element retains state information. A static view of architectural elements summarizes their invariants. The static characteristics they address are: what the data and control scopes are; whether the element transforms data; binding time; if connecting to this element blocks the connecting element, does the element relinquish control; are ports in, out, or in/out; and how many elements can connect to each port, both at any one moment in time, and over the lifetime of the element. They give examples of architectural elements classifications. A subset of those can be found below; only those that would be relevant for main-subroutine and blackboard systems are introduced. By examining their temporal features (table 2), one can see that some of them were already part of the AAA model and the conceptual feature set (e.g., forks? ), others are included in our work (e.g., accepts control at other than t s? see section 5.0 on page 58). Their static features are a bit different (table 3), most of these are part of our model, but not all are part of the conceptual features set, the reason being that they are in a 15

29 lower level of detail than what we consider applicable for our conceptual features. Ports information, for example, is part of the model, but does not show up in the conceptual features set. Control scope and relinquishing control (we have it under response time as cyclic) do show at both our model and conceptual features level (section 5.0 on page 58). Information on whether data is transformed or not is not part of our model, nor our conceptual features set. Temporal Features Arch. Element Singleentry procedure Accepts control at other than t s? Transmits control at other than t e? never never always never not criterial Object never never always never not criterial not criterial not criterial Function never never always never always not criterial Procedure call Blackboard Forks? never never never Retains state? same thread same or different threads same thread never never always never always never never same thread always always not criterial Accepts data At t s? At other than t s? always Transmits data At t e? not criterial At other than t e? Table 2: Temporal Features of Architectural Elements always never same or different threads There are also some conceptual features that we have found extremely relevant for composition, that are not included in their set of features, some of them are whether there is backtracking allowed, whether components have priorities associated with them, 16

30 and whether there is preemption or not. These features were not part of the original AAA model, but have been added by this work (section 5.0 on page 58). Static Features Arch. Element Data scope Control scope Trans forms data? Binding time Blocks? Relin quish? Ports Associations Per conn Life time Singleentry procedure virtual address virtual address yes spec., execution not criterial yes 1 I; m O 1 n Object virtual address virtual address yes spec., execution not criterial yes n I; m O 1 n Function virtual address virtual address yes spec., execution not criterial yes 1 I; m O 1 n Procedure call virtual address virtual address no spec. yes yes I; O 1 1 Blackboard distributed distributed no spec., invocation, execution not criterial yes I; O 1 n Table 3: Static Features of Architectural Elements Kazman and his colleagues also discuss composition of architectural elements. They mention that when composing two elements some of their features must match, whereas others can be ignored. As features that must match they mention ports and their associations. As features that may be ignored they list state retention, data transformation, blocks, forks, and relinquish. They do not provide a formal discussion on the feature combinations of composing elements that are allowed or not, and the compositional discussion they provide is only of a one element plus another approach (i.e., they don t discuss problems at the system level). 17

31 The major difference between their classification and the one being offered here is that they are doing so at the element (component and connector) level, whereas we do it at the system level (percolating to the architectural element level in the model). This means that our classification is a little more abstract than theirs, hence probably more applicable at earlier stages than theirs. Also, they do not offer clear guidelines on how to use their set of features during system composition, nor do they allow for analysis of the composition of several elements together. Which means that as long as the elements agree on a one-to-one basis, they detect no problems. Well, here are a few examples of possible problems: A blocking data connector connecting control components A and B (3 elements). If control component B does not become (or is not) active after A sends some data, A will be in a deadlock situation. Two control components in the same thread sharing a blocking data connector (3 elements), creates a possibility of deadlock. A call to a cyclic (or non-control relinquishing) component, will leave the caller in a deadlock. Note that the last example also contradicts their assumption that whether an element relinquishes control or not is irrelevant for composition. Summarizing, they offer a very good classification framework for architectural elements, and weaker ways of detecting element to element mismatches. They do not provide a framework for composing system architectures, nor insights on possible architectural mismatches during the composition of systems. 18

32 2.4 Stiger and Gamble Stiger and Gamble present a formal model of a blackboard style [Stiger and Gamble 1997]. They use Z to specify the relevant elements such as components, connectors, and configurations. Just like the work by Abd-Allah (section 2.5), their Z specification is unable to handle dynamic information. Additionally they claim that the knowledge source component can be refined to any embedded architectural style allowing the blackboard architecture to pose as an integration architecture, but no proofs, examples or explanations on what was meant is provided. Even if this claim was to be proven correct, the approach could potentially avoid some architectural mismatches (the same kind covered by CORBA for example), but still mismatches related to backtracking, resource contention, and response time among others could occur. 2.5 Abd-Allah Abd-Allah s work on his dissertation and the Architect s Automated Assistant (AAA) [Abd-Allah 1996] tackled a portion of the problem this thesis is focusing on. He constructed a model and a prototype tool to detect potential architectural mismatches during systems composition, while focusing on the main-subroutine, pipe-and-filter, distributed processes, and event-based styles. He modeled styles and systems using Z [Spivey 1992]. His complete Z model can be found in appendix B. 19

33 Abd-Allah described some base elements that can be refined and combined in various ways in order to describe architectural styles and/or specific systems (see figure 1). These base elements are: 1. A port is typically associated with a control component, and is the latter s entry and exit points for data during data transfers. 2. A data component models data that is used to store state or is transferred across data connectors. 3. A control component models data that is executed by the underlying machine and which can initiate (and respond to) data and control transfers. It is assumed to have a single thread of control (from a hardware point of view, a control component has a single program counter). 4. An object is an encapsulation of a set of data components with a set of control components. Not only from a formal standpoint is an object fundamentally different from a data or control component (i.e. {X} is not the same type as X), but there are other reasons for this distinction, an object can include complex interconnections within itself, forming its own single-threaded minisystem (see the definition of system below) an object can be instantiated many times, each time introducing a new set of different data and control component copies 5. A data connector models the potential for two or more control components or objects to engage in data transfers amongst themselves. 6. A control connector models the potential for two or more control components to engage in control transfers (possibly with data) amongst themselves. 7. A trigger associates an action (a data or control transfer) with the reception of a data component by a control component or object. 8. A system is a non-empty set of interconnected control components or objects satisfying some unique purpose. 20

34 Thing Port Data Control Object Data Control Component Component Connector Connector Event queue Socket Data store Shared data Filter Process Procedure Object Pipe Call Spawn Circuit Pipe & Filter Style Lexical Compiler: Analyzer Syntax Parser Semantic Analyzer Code Generator Figure 1: Extending the Base Entities to Style-Specific Entities Abd-Allah also suggested the use of conceptual features as a higher level abstraction for describing architectural styles and/or systems characteristics (see also section 1.0). The conceptual features he used were: 1. Dynamism. Earlier we discussed how the topology of software can be dynamic, adding and removing concurrent threads as it executes. Some styles constrain the topology to be static (i.e. the number of concurrent threads remains constant), while other styles do not. A style is dynamic if and only if it allows non-blocking control connectors (spawns). 2. Supported data transfers. Of the styles we studied, all of them achieved data transfers through one (or more) of three mechanisms: explicit data connectors, an implicit global network of data connectors, or shared data variables. 21

35 3. Triggering capability. Hardware has interrupts, and software has triggers. Some styles allow the transfer of data (events) along explicit data connectors or a global network to cause certain actions, e.g. control transfers or additional data transfers. 4. Concurrency. Styles often constrain the number of concurrent threads that may execute within a system. A single-threaded system is limited to only one thread of control components linked by a chain of calls (blocking control connectors), while multi-threaded systems allow more than one thread to execute concurrently. Note that concurrency is not the same as dynamism. 5. Distribution. A style may or may not constrain the mapping of system entities to nodes. If the mapping is to more than one node, then the style s systems are naturally distributed. 6. Layering. Styles may or may not impose system layering constraints on its control components. The layers must be specified with respect to a connector, e.g. a set of layers linked by control connectors. 7. Encapsulation. As shown earlier, objects are fundamentally different from data control components. A style may choose to be object-oriented or not. How each of these features applies to each of the styles he discussed is shown in table 4. Conceptual features get propagated into the Z model as a set of constraints on the base elements that varies from style to style, depending on the choices made for each of the conceptual features. He then continued to show how the combination of the presence and/or absence of certain conceptual features on parts to be composed could potentially cause architectural mismatches, depending on the bridging connector 1 used between them. These are described in table Bridging connector is the term he uses to refer to the connector used to compose the parts together. We also use this term for the same purpose. 22

36 Pipe & Filter Main/ Subroutine Distributed Processes Event-Based Dynamism static static dynamic static Supported data transfers explicit data connectors shared data variables explicit data connectors implicit network, shared data variables Triggering capability no N/A no yes Concurrency multithreaded singlethreaded multithreaded singlethreaded Distribution unconstrained single node multiple nodes unconstrained Layering unconstrained unconstrained unconstrained unconstrained Encapsulation no no no yes Table 4: Four Instances in an Architectural Style Space An explanation of each mismatch is given below. 1. Two concurrent threads share data, with potential synchronization problems. 2. Two threads have data connectors to 2 different control components in a third thread (it is impossible for the third thread to execute in the two components simultaneously - see figure 2). thread 1 thread 2 thread 3 data connector call control component Figure 2: Mismatch #2 of Group Operation 23

37 Dynamism Data Transfers Triggered Concurrency Distribution Layering Encapsulation call 15 4 spawn data connector 10 2, shared data triggered call 12 5,7, triggered spawn ,7, triggered data transfer 12 5,7, shared machine 16 Table 5: Mismatches Related to the Conceptual Features 3. Two control components in the same thread share a blocking data connector, creating a possibility of deadlock. 4. A layering constraint is violated. 5. Different sets of recognized messages are used by two subsystems that permit triggers. 6. A spawn is made into a subsystem which originally forbade them. 7. An unrecognized trigger message is used. 8. A triggered spawn is made into a subsystem which originally forbade spawns. 9. A trigger refers to a subsystem which originally forbade triggering. 10. A data connector is made into a subsystem which originally forbade them. 11. A shared data relationship refers to a subsystem which originally forbade them. 12. A trigger refers to a subsystem which forbids explicit or implicit data connectors, hence the trigger may never occur. 24

38 13. A spawn is made into a subsystem which is not concurrent. 14. A triggered spawn is made into a subsystem which is not concurrent. 15. A remote connector is extended into or out of a non-distributed subsystem (i.e. a subsystem originally confined to a single node). 16. A node resource is overused (this is actually checked by summing across the subsystems usage of that particular resource). We found the framework he used for basing mismatches detection on conceptual feature choices to be useful for dealing with a broader set of styles and systems, as long as we extended it accordingly. His investigation of the above mentioned styles yielded him with a set of 7 conceptual features (see above) and 16 detectable mismatches. Our work based on a broader set of styles (section 4.0 on page 48) has proven his conceptual feature and detectable mismatches set to be quite insufficient (section 5.0 on page 58, and section 6.0 on page 78, respectively). In order to investigate other styles such as blackboard and real-time, we changed slightly his set of architectural base elements (e.g., trigger is not a base element anymore, but actually a relation between sets of events and sets of actions), and their characteristics on the underlying model (for example to include component priorities). As far as his set of conceptual features are concerned, his model had a considerable coverage for the styles he focused on, but certainly not for some other very commonly used styles such as real-time, and closed-loop feedback control for example. Characteristics such as being a system preemptive, reentrant, and containing component 25

39 priorities or not are completely absent from his model, even though they are extremely relevant for composition. Furthermore, he considered encapsulation one of his conceptual features, but never showed it had any relevance to architectural mismatches during composition. Additionally, he provided no clear guidelines for determining when to add new conceptual features (i.e., which characteristics are to be considered or not, and why). He provided no discussion on how the conceptual feature space was composed, ways of classifying it, and means of extending it. Issues that we do briefly discuss in section 5.3. His Z model did not make use of Z operations on schemas that do actually alter the schemas attributes contents. Consequently he was unable to provide for dynamic checks on certain constraints that would actually allow for the detection of dynamic mismatches. We have added the operations StartSystem, ActualControlTransfer, and Actual- DataTransfer that are able to do exactly that. Besides, his work only provided a very limited prototype, whereas we have built a working tool for mismatch detection. 2.6 Architecture Description Languages (ADLs) Here one can find a discussion of several ADLs and their supporting tools, while focusing on the problem of composition of heterogeneous systems. For a survey on ADLs and their supporting tools in general, please refer to the work by Medvidovic [Medvidovic 1997]. 26

40 It is important to note that the observations presented here are just a picture in time. The tool set related to each and every ADL is continuously evolving, as are some of the ADLs themselves (e.g.: ACME) ACME ACME is an architecture interchange language [Garlan et al. 1995b][Garlan et al. 1997]. Rather than being yet another ADL, it is an interchange mechanism, intended to support transformations of architectural specifications between heterogeneous ADLs. Consequently, ACME has no direct tool support, 1 but enables the use of support tools from various ADL suites. The approach consists of providing means of describing the structural (or topological) characteristics of architectures, along with annotations containing ADL-specific information. This strategy allows the sharing of common architectural information by various ADLs and their tools, as well as supports the specification of information not present in all ADLs. This is the essence of ACME. The language provides a fixed vocabulary (or ontology) for representing architectural structure. Additionally it provides an open semantic framework in which architectural structures can be annotated with ADL-specific properties. In this way ACME achieves the benefits of both an intersection and a union language: the shared structural core represents an intersection of the expressive capabili- 1. ACME has no direct tool support, but it does enforce some structural constraints, such as disallowing a connector to be attached to another connector, or the existence of a dangling port. 27

41 ties of most ADLs, while the use of annotations accommodates the union of ADL-specific concerns. [Garlan et al. 1997] In the context of this work, ACME could be applied in several ways: Specifications written in any arbitrary ADL and then translated into ACME could then be translated into the formalism used here, permitting its use as input for the analysis capability introduced here. This work could actually use ACME as its native modeling language, making heavy use of annotations for semantic needs not covered by ACME. Specifications written using the formalism introduced here could be translated into ACME, allowing for further analysis by other ADLs and their tools. We chose not to use ACME as the native modeling language simply because the extensions required would be so many that it would actually defeat the purpose of using a previously existing ADL. Importing descriptions to or form ACME could be addresses by future work Aesop Aesop is a tool kit designed to support the rapid development of style-aware software architecture design environments. A style specific environment is achieved by providing style-specific vocabulary of design elements (as subtypes of basic architectural classes), stylistic constraints as methods of these types, and a collection of external tools that perform architectural analyses that are relevant to that specific style [Garlan 1995]. 28

42 The Aesop tool kit includes a repository for architectural level design elements and patterns called the Software Shelf [Monroe and Garlan 1996]. The Software Shelf supports the classification, storage, and retrieval of architectural elements, namely components, connectors and configurations (or patterns). Design elements stored in this repository are classified by category (component, connector or pattern), style or set of styles for which it was created, and class within the style (i.e., type of component, connector, or pattern within the particular style). It is critical to note that Aesop focuses on homogeneous architectures, so environments are specialized by style, not allowing the use of more than one style at a time. Our work handles composition of both homogeneous and heterogeneous software systems architectures. It is also important to highlight that the reusable architectural elements provided by the Aesop Software Shelf are abstract or incomplete design fragments, to be further refined upon retrieval. Even though the primary focus of one of their works is to integrate software architecture, architectural styles, and software reuse [Monroe and Garlan 1996], it is not in the scope of the Aesop tool kit to try to accommodate the architecture of pre-existing software. Consequently, their focus is different from the one in our work. We can see one danger on trying to evolve the work in the Software Shelf to also cover pre-existing software, namely that hardly ever will one be able to find some OTS product whose architecture has been defined in one pure architectural style. Even when addressing OTS components, if we have the developer of the component being the 29

43 one specifying the architecture style used, his/her definition of the style might be different than that of the (re)user of the component.this would introduce some considerable complexity on Software Shelf s classification scheme, and consequently on the retrieval as well C2 C2 and its design environment (Argo) support the description of user interface systems using a message-based style, enabling the development of GUI architectures with interchangeable and reusable software components [Medvidovic et al. 1996]. The main focus of their work is on reuse of software components, and dynamic changes to run-time architectures for systems conforming to GUI architectures characteristics (this can actually be thought of as a specific style that is message-based, with concurrent component execution, communicating via message routing devices, while being layered and allowing for no shared address space). C2 provides for some type, constraint, and architectural style rule checking. It also has design critics that actively check for completeness, correctness and consistency, among others. Those critics provide feedback in a context sensitive manner during design, or by analyzing an architectural model after a design activity. The reuse focus of the C2 team differs significantly from ours. They support reuse by allowing for replacement of components in lower layers of the architecture, without impacting the upper layers, and while focusing on their specific style (GUI like archi- 30

44 tectures). That is all components share the same architectural characteristics, hence architectural mismatches are completely avoided Darwin Darwin allows distributed and parallel programs to be structured in terms of groups of process instances which communicate by message passing. In addition to expressing static structures, Darwin can be used to express structures which change dynamically as execution progresses. Darwin uses Π-calculus as its underlying semantic model. Darwin supports software composition through the description of generic software architectures which can be elaborated and instantiated to form specific executable architectures [Magee and Kramer 1996]. Components on the style supported by Darwin interact solely by accessing services. During system architecting, a component does not need to know the global names or locations of external services it will be interacting with. This allows for component specification, implementation, and testing independently of the rest of the system, which in turn allows for plug-and-play of various components conforming to the specific style supported. This is the extent to which megaprogramming is supported by Darwin, which is to say that they do not deal with heterogeneous software architectures, and hence deal with a very limited set of architectural mismatches during systems composition. 31

45 2.6.5 MetaH The MetaH architecture description language has been developed to provide specific guidance for designers of real-time avionics control software. The tools check a system description for schedulability and other properties and generate the glue code that handles real-time process dispatching, communication, and resource synchronization [Vestal 1997]. MetaH allows a specification of system components and connectors, and their attributes which are relevant to real-time, fault-tolerant, secure partitioning, and multi-processor facets of systems. Tools are available to perform a software/hardware binding, real-time schedulability analysis, reliability analysis, and safety/security analysis. A tool is available to generate the glue code needed to provide the scheduling, communication, event handling and fault containment behavior specified in MetaH. The tool set also includes a make facility to manage change propagation and automatically perform compilations and links as needed. Objects in a MetaH specification have separate interface and implementation definitions, where multiple alternative implementations can be defined for the same interface [MetaH 1996]. This is the only megaprogramming support provided by the tool set. As by the work of Abd-Allah (see section 2.5) we already know that the simple conformance to some specific interface does not prevent architectural mismatches from occurring. MetaH and its tool set provide very strong support for real-time systems, but none for composition of these with systems or parts using different underlying styles. 32

46 2.6.6 Rapide Rapide is an executable ADL intended to model the architectures of concurrent and distributed systems by defining and simulating their event-based behavior [Luckham and Vera 1995]. It allows one to specify systems behaviors in terms of partially ordered sets of events. Component computations are triggered by received events, and in turn trigger other computations by sending events to other components. The result of executing a Rapide model is a set of events that occurred during the execution together with causal and timing relationships between events [Rapide 1996]. The Rapide language framework is divided into 5 sub-languages, aiming to facilitate the reuse of parts of Rapide in other languages, as well as for easy language evolution [Rapide 1996]. These languages are: Types Language - describes interface types and function types, and supports deriving new interface type definitions by inheriting form pre-existing ones. Pattern Language - describes patterns of events with causality, independence, and/or timing relationships. Executable Language - contains control structures to describe behaviors of components. Architecture Language - describes the flow of events between components, by defining their synchronization and communication interconnections Connectors are not considered first class entities in Rapide. 33

47 Constraint Language - defines formal constraints on the behavior of components and architectures, where constraints are posets patterns that are either required or forbidden. The Rapide tool set permits simulation of architectural descriptions, animation of those simulations, and analysis to check for anomalous behavior. A Rapide model simulation results in a poset showing the causal history of events in the specific execution, independent activities, timing, and dataflow. Based on these, various kinds of analyses can be performed. Tools supported by Rapide are constraint checkers (analyzing for conformance to constraints described in the model 1 ), poset browsers (supporting event visualization, while providing for filtering of events for scalability purposes), and animation tools (graphically display the execution using real-time animation for ease of visualization of posets). Rapide s strengths lie on the use of its various analyses tools. The type of analyses they support are all based on improper event ordering and/or timing during some simulation. 2 Their literature shows a fairly detailed example on detecting deadlock for a dining philosophers architecture [Luckham 1996]. Rapide allows for the specification of an architecture to be done based on its interfaces, leaving the actual replacement of those by various components with their specific behavior for a later phase. Based on that, one can envision using various pre-existing components on any existing architecture, as long as they conform to the specified interface. 1. The constraint checker is not fully implemented yet [Luckham 1996]. 2. Note that some problems only occur occasionally within a single simulation scenario, because there is non-determinism allowed. 34

48 Since Rapide is biased towards event-based systems, composing parts via data connections follows naturally, whereas it does not provide for easy means of modeling control connections. It also provides no support for specifying certain system characteristics required for the work being proposed here, such as preemption and backtracking (to be discussed in part III) SADL The work on SADL by Moriconi, Qian, and Riemenschneider [Moriconi et al. 1995] relies on the assumption that large systems architectures are described by a hierarchy of related architectures. Where higher levels represent abstractions of lower ones, which may differ in number and kind of components and connectors. This hierarchy being informally described, thus leading to an error-prone refinement process. Based on these observations, they introduce a methodology for correct stepwise refinement of software architectures, by using instances of architectural refinement patterns that are correctness preserving and compositional. The use of this methodology should ultimately lead to fewer architectural design errors, and to extensive and systematic reuse of design knowledge and proofs. To prove the relative correctness between two architectures, they specify an interpretation mapping between them. An interpretation mapping is an association between formulas of the language of the abstract architecture and formulas of the language of the concrete one. An interpretation mapping is determined using a name and a style mapping. The name mapping simply associates the names of the objects in the 35

49 abstract architecture with those of the concrete one. Thus it needs to be specified for every given pair of architectures. The style mapping says how the constructs of an abstract-level style can be implemented in terms of the constructs of a concrete-level style. These tend to be complex, but need only be defined and proven once. After that the style mapping can be safely reused whenever necessary. The authors discuss two different forms of composition for architectures, vertical and horizontal composition. Vertical composition is used to chain together a sequence of correct architectures, allowing the conclusion that the most concrete architecture in a hierarchy is correct with respect to the most abstract architecture in the hierarchy. Horizontal composition is used to compose instances of refinement patterns to form one large composite refinement architecture. It is also used to compose existing architectures into larger architectures. They then suggest that if two abstract architectures share only components and lower-level architectures share only images of those components under the interpretation mapping, then they can be correctly composed. Subsequently, they show the example in figure 3, 1 as being an appropriate horizontal composition example. The composite system shown in figure 3 adheres to their composability criterion, but it could have problems, depending on intrinsic characteristics of both subsystems A and B. The problem is that they assume the linking architecture will take care of the integration problems, without considering the potential complexity of the issues involved. 1. Figure 4 in their paper. 36

50 A A B B Subsystem A Linking Architecture Subsystem B A B Composite System Figure 3: Horizontal Composition Example A deficiency in their paper is that they listed some architectural styles but never explained what they consider relevant characteristics, nor how the styles compare to each other. They actually refrain from considering issues like can components execute concurrently? or does the system allow for preemption? which are clearly very important when dealing with architectural composition. Their work s main focus is clearly on architecture refinement. Vertical composability follows naturally from there, but not horizontal. In horizontal composition, linking architecture was mentioned as a solution, we know this can be very complex, and they never hinted on how to deal with that complexity or the problems that may arise. Our work focuses on horizontal composition, more specifically, on detecting potential problems in possible linking architecture solutions. Consequently, it is a great complement to the Moriconi, Qian, and Riemenschneider body of work. 37

51 They actually do discuss what connects to what, and shared variables, but there is no way of representing concurrency, dynamism, termination, or preemption using SADL [Moriconi and Riemenschneider 1997]. So if there could be any potential problems on these areas, there would be problems on applying even vertical composition UniCon UniCon is an ADL whose primary focus is on supporting descriptions of architectures, localizing and codifying the ways components interact, and distinguishing among various packagings of components that require different forms of interaction [Shaw et al. 1995]. More specifically, the objectives of UniCon and its tool set include: (a) providing uniform access to a wide range of components and connectors (not restricted to a single style); (b) discriminating among various types of components and connectors, facilitating the checking for proper configurations; (c) supporting the use of analysis tools developed by others, and using different underlying representations; and (d) handling existing components as any other component. In UniCon components are specified by their type, property lists (attributevalue pairs), and interaction points (players) where connectors are to be hooked. Connectors are described by their type, property lists, and interaction points (roles) where they are supposed to interface with components [Zelesnik 1996]. System configurations are then defined by associating specific components players with specific connectors roles. Towards achieving objective (a), several types of pre-defined components and connectors are provided in a miscellaneous collection, from which the architect is to 38

52 choose the ones considered appropriate for the specific situation. Objective (b) is fulfilled by differentiating among the types of interaction points provided by all types of components (players) and connectors (roles), UniCon allows for the restriction of those combinations (i.e., not all player-role pairs are allowed during system composition) by means of implicit rules. These localized checks is the only means of mismatch detection currently provided by the UniCon tool set, there are no means of specifying global systems constraints. Mismatches that occur as side effects to the composition of certain components and connectors are not detected at all (e.g., the presence of potential for deadlock, or the existence of some high resource contention). Objective (c), supporting the use of analysis tools developed by others, and using different underlying representations has already been recognized as extremely important by the software architecture research community, hence the effort on ACME (see section 2.6.1). Note that the same property list approach that UniCon uses has also been adopted by ACME, and by the Architecture Capture Tool (ACT-1) currently under development at USC. Currently, UniCon supports for rate-monotonic analyses by another independent CMU tool, and there is on going work for translating to and from ACME. The way that UniCon handles pre-existing components (objective (d)) is by defining their interfaces according to UniCon terms. This means to say that during composition, the only mismatch checking that happens in this situation is once again on making sure that the specific role-player combination is an allowed one. 39

53 2.6.9 Wright Wright supports the specification and analysis of interactions between architectural components. Components and connectors are specified using a CSP based notation. Specifically, connectors are described by a protocol which specifies the behavior of the components which it connects [Allen and Garlan 1994]. They are described by their interface points (roles) which indicate what is expected of the components to participate in the interaction, and how that interaction actually takes place (glue). Components are described by their interface points (ports) and their behavior (computation), which indicates how the ports are associated to each other by the component s behavior. Once component and connector instances are declared, systems configurations are defined by associating pairs of specific component port to connector role. Some of Wright s main features are the precise description of architectural structures and their abstract behavior, the ability to define architectural styles, and a set of consistency and completeness checks for architectural descriptions [Allen and Garlan 1996]. Architectural structures are obtained by description of their components, connectors, and their configurations. Their abstract behavior is obtained by evaluating the computation part of components, along with the glue part of connectors. Architectural styles in Wright are described by the components and connectors that can be used in the style, along with a set of constraints specifying how these elements can be composed to build a system in that particular style [Monroe et al. 1997]. Hence, Wright allows for style-specific information checking, but does not provide any support for heterogeneous styles and checking for the consequent possible mismatches. 40

54 Wright provides various consistency and completeness checks [Allen and Garlan 1996]. Some of them are: port-computation consistency (ensuring that component descriptions are consistent); connector deadlock-free; roles deadlock-free; port-role compatibility (flagging invalid combinations); style constraints (making sure all predicates for that style hold); attachment completeness (any port/role that is unattached must be able to behave as a process that simply halts). 41

55 42

56 Part III: Contribution The following sections describe our approach to answering the central dissertation question. We first describe the overall approach to extending the AAA model taken. This is followed by a discussion of our results, which includes descriptions of the various styles covered, a discussion on relevant new conceptual features found, and details on the various architectural mismatches that we address. Subsequently, we present the ways in which the formal Z model has evolved, along with some of its fragments. Finally, we include details on how to use our results towards compositional analysis of systems. 42

57 43

58 3.0 Approach Description We chose to tackle the central dissertation problem by extending and generalizing the body of work started by Ahmed Abd-Allah [Abd-Allah 1996] (section 2.5). His model can distinguish between systems built using the distributed processes, event-based, layered, main-subroutine, multithreaded, pipe-and-filter, and software bus styles. This work evolves his original model to provide more complete style (and consequently systems, COTS and GOTS packages) coverage. Each style has a very particular set of characteristics. Hence, by studying various other styles we have determined where Abd-Allah s set of conceptual features needed to be extended, such that the model can be used to distinguish between a larger number of systems. 1 As a natural consequence of increasing the number of conceptual features, the model can also be used to detect an increased set of potential architectural mismatches during composition. We use the blackboard, closed-loop feedback control, logic programming, real-time, rule-based, transactional database, and internet distributed entities styles. Our initial approach was to investigate the blackboard style depth-first, by working on its description and modeling it in Z. 2 The blackboard style suggested the addition of a new conceptual feature, which forced us to revisit the previously defined styles. As a result of this modeling activity we were able to determine mismatches that could potentially occur while combining blackboard systems with other blackboard systems, or 1. The need to have the model reflect new conceptual features also implied a need to modify some attributes of base elements, as well as add new constraints on them in order to depict new styles. 2. We used a plain text form of Z called ZSL [Jia 1994]. ZSL has the advantage of coming with an automated type checker (ZTC) which was used to verify the syntactic correctness of the model s specification. For an introduction to ZSL see appendix A. 43

59 systems using any of the styles previously described by Abd-Allah. These mismatches included a subset of the ones described by Abd-Allah in table 5 on page 24, as well as some new ones. Thus, the hypothesis that the original seven conceptual features introduced by Abd-Allah would cover the full range of architectural style mismatches is false. Subsequently we examined each and every one of the styles using a breadthnext approach (section 4.0). The idea was to highlight the characteristics of each style that are the most relevant to composition. Based on these descriptions we were able to detect some new very important conceptual features, and clearly identify some of their relevance to detecting potential mismatches (section 5.1). This new set of conceptual features was then used as a basis for describing each and every one of the styles we chose to address (section 5.2). We also used the new set of conceptual features, to determine the dimensions relevant to the conceptual features space, thus providing orthogonality of the various concepts involved. We also provided guidelines on how to evolve the conceptual feature set based on the described space (section 5.3 on page 72). Later we determined an extensive set of architectural mismatches that may occur during systems composition, and can be determined based on the selections of conceptual features of the parts to be composed and the means used for composition (section 6.0). As a formal basis for the efforts whose results can be seen in sections , we also made an extensive Z-modeling effort, 1 yielding the results discussed in section 7.0, and presented in its entirety in appendix C. 44

60 The results from the activities above were then used as the basis for our tool for supporting the diagnosis of potential architectural mismatches during systems composition (section 8.3). Our model is more powerful than the tool engine built. The model can determine the existence of specific violating situations, but it also requires a very thorough description of all parts involved. The tool on the other hand requires a minimal effort to provide the input required to perform the analysis -- systems are described in terms of styles and/or features -- but as a penalty can only flag potential mismatches. Our judgement has been that the results of this work should be more valuable for early risk resolution, hence the chosen tool approach more valuable. 1 We have also applied the tool to an example, which is discussed in section 8.3. It is important to note that this description shows the temporal ordering of the work, not the actual sequencing of their description in this document. This document has been formatted for ease of reading. 3.1 Extending the AAA Model Before going into the details of our work, we will now revisit a few points made while discussing Abd-Allah s work (section 2.5 on page 19), that do clarify the exact evolution from Abd-Allah s AAA model. These are: 1. Our formal model described in the Z language, provides elements (with their attributes and constraints) that can be specialized, composed, and have constraints imposed on their conglomerates in order to describe architectural styles, software systems architectures, and their composition. Our model also provides means of detecting architectural mismatches during systems composition. 1. Although we encourage the use of the AAA tool, we also provided in section 8.0 guidelines on how to use our results at a high level on paper (section 8.1), and in a very detailed level with the model (section 8.2). 45

61 His set of architectural base elements changed a bit (e.g., triggers and objects are not base elements anymore, rather they are specializations and relations between existing underlying elements respectively). Also their characteristics changed considerably to reflect new conceptual features at the model level. All these changes are discussed in section 7.0. His set of conceptual features also evolved considerably (section 5.0). Additionally we explain how to represent each and every feature while modeling some specific style and/or system (section 7.2). We also provide some discussion on the space defined by our conceptual feature set, and guidelines on how to evolve it. (section 5.3). The original set of mismatches detected by his model did not only evolve to reflect the new conceptual features, but also includes other mismatches related to the features he originally introduced (e.g., considerations about the encapsulation characteristic). Additionally, we have also included explanations on the required preconditions, and the exact problems entailed in each and every one of the mismatches (section 6.0). We have added a specific Z operation to check for each and every one of the static mismatches we uncovered (section 7.4), and some Z operations to address the detection of dynamic mismatches (StartSystem, ActualDataTransfer, and ActualControlTransfer). We did consider the idea of replacing Z as the underlying formalism of this model by some pre-existing ADL. This would have the added benefit of directly allowing specifications (written in the chosen ADL) to be checked for architectural mismatches, as well as undergo whatever analyses provided by the chosen ADL and its tool set. We 46

62 decided against it since there is no single ADL that does provide everything we require. Using an ADL that allows us to add new characteristics was also infeasible, since the extensions would have been so many that they would actually defeat the purpose of using a pre-existing ADL. 47

63 48

64 4.0 Styles Descriptions This section includes descriptions of the various styles addressed by this work. It contains some comments on the event-based style first described by Abd-Allah (section 4.1), and descriptions of the various styles considered by this work---blackboard style (section 4.2), rule-based (section 4.3), logic programming (section 4.4), databasecentric (section 4.5), real-time (section 4.6), closed-loop feedback control (section 4.7), and internet distributed entities (section 4.8). 4.1 Revisiting Event-Based As described by Abd-Allah, event-based systems: were static (allowed for no spawns); had data transfers supported by shared variables; involved some triggering capabilities; were single-threaded; were unconstrained with respect to distribution and layering; and had encapsulation. This particular representation worked very well in his case, it clearly differentiated between event-based and distributed processes. Most people tend to think of event-based systems as deviating slightly from Abd-Allah s characterization. The usual definition differs from the one above in that event-based systems are thought of as being unconstrained with respect to dynamism and multi-threaded. Hence, this is the definition we will be using in the model from now on. Additionally, Abd-Allah restricted the triggering events to be only the receipt of certain messages, we do consider triggering events as being any of: data transfer control transfer 48

65 absolute time value reached deadline (sequence of time value, control transfer or data transfer, time value) sequences of any of the above Our interpretation of the event-based style also imposes no restrictions on the mechanisms available for sharing data, nor on whether there is encapsulation present or not. 4.2 Blackboard The blackboard model has been very well described in the literature [Nii 1986]. Below one can find the information that is relevant for our modeling purpose. In the blackboard model, there is a central data structure which contains representations of the solution space. The domain knowledge is partitioned into independent modules of knowledge that transform information from the solution space, with the goal of reaching a solution to the problem at hand. Which module of knowledge to apply is determined dynamically, one step at a time, resulting in the incremental generation of partial solutions. The choice of a knowledge module is based on the solution state (particularly, the latest additions and modifications to the data structure containing pieces of the solution) and on the existence of knowledge modules capable of improving the current state of the solution. The blackboard model is usually described as consisting of three major components: 49

66 The knowledge sources: separate and independent modules of problem-specific knowledge. The blackboard data structure: the problem solving state data are kept in a global database, the blackboard. This data are shared by all knowledge sources. Control: knowledge sources respond opportunistically to changes in the blackboard. The actual locus of control is implementation dependent, it can be in the knowledge sources, on the blackboard, in a separate module, or in some combination of the three. Knowledge sources produce changes to the blackboard that lead incrementally to a solution to the problem. No one source of knowledge can solve the problem by itself; the solution to the problem depends on the combined contributions of many specialists. The objective of each knowledge source is to contribute information that will lead to a solution to the problem. Cooperation is achieved by assuming that whatever information is needed is supplied by someone else. The knowledge sources and only the knowledge sources modify the blackboard. All modifications to the solution state are explicit and visible. Communication and interaction among the knowledge sources take place solely through the blackboard. The control unit does not write on the blackboard. Each knowledge source is responsible for knowing the conditions under which it can contribute to a solution. Each knowledge source has preconditions that indicate the condition on the blackboard which must exist before the body of the knowledge source is activated. 50

67 The purpose of the blackboard is to hold computational and solution-state data needed by and produced by the knowledge sources. Only the knowledge sources are allowed to make changes to the blackboard. Based on the latest changes to the information on the blackboard, a control module(s) selects and executes the next knowledge source(s). The solution is built one step at a time. The sequence of knowledge sources invocation is dynamic and opportunistic rather than fixed and pre-programmed. The knowledge sources respond opportunistically to changes in the blackboard. The control module(s) monitors the changes on the blackboard and decides what actions to take next. The control unit(s) dynamically chooses (decides) which knowledge source(s) to activate next based on the blackboard contents, the knowledge sources preconditions, and some control information (such as the history of changes to the information on the blackboard). Blackboard systems have backtracking to support their reasoning engine, they are non-reentrant and non-preemptive. 4.3 Rule-Based This description of the rule-based style is heavily founded in the concepts described in the literature [Hayes-Roth 1985] [Rich and Knight 1991] [Shaw and Garlan 1996], while focusing on the features that are relevant for composition. A rule-based system uses a repository of shared facts (working memory) as the only means of sharing information among its various rules (i.e., there are no data connectors). Here rules are our control components, and facts our shared data. 51

68 Rules have explicit preconditions that need to be matched by facts in order to permit their execution. The order in which the rules are introduced in the system determines their execution priorities. System execution follows a match-select-execute cycle, i.e., first the interpreter determines a match by checking the rules preconditions against the current facts in working memory, then among all those that had their preconditions fulfilled the one(s) with the highest priority is selected and executed. The execution of rules changes the problem solving state by changing the facts based on new knowledge. Rule-based systems may use both forward and backward chaining when trying to solve a problem. Since they do have backward chaining, they allow for backtracking. They are typically non-reentrant and non-preemptive. 4.4 Logic Programming This description of the logic programming style is heavily founded in the concepts described in the literature [Genesereth and Ginsberg 1985] [Clocksin and Mellish 1987] [Rich and Knight 1991], while focusing on the features that are relevant for composition. A logic programming system uses shared information on unification values as the only means of sharing information among its various rules (i.e., there are no data connectors). Here rules are our control components. Rules have head terms that need to be unified as a precondition to permit their execution. The order in which the rules are introduced in the system determines their execution priorities. System execution follows a unify-execute cycle, i.e., the interpreter tries 52

69 to unify the head term of the rule, and then, if any successful unification is found, execute it. While executing, rules may invoke (or call) other rules. If some chosen unification fails when executing the rule, then the system backtracks to try for other options. Systems use backward chaining when solving problems, no forward chaining occurs. Since logic programming systems have backward chaining, they allow for backtracking. They are typically non-reentrant and non-preemptive. 4.5 Transactional Database-Centric This description of the transactional database-centric style is heavily founded in the concepts described in the literature [Elmasri and Navathe 1989], while focusing on the features that seem to be relevant for composition. Transactional database-centric systems have a central repository (or database), of data that is shared among the various control components of the system. There is a database management system (DBMS), which handles concurrent accesses to data, recovery from error situations, and enforces integrity and security constraints. Thus, the DBMS takes care of maintaining data integrity. DBMSs typically support multiple users (and consequently are reentrant), and may have different locking data items granularity (field level, record level, disk block, whole file, or whole database). DBMSs may also allow for different priorities based on the query type. Databases may vary in various aspects: they may be distributed or not; they may be replicated or not; their structural organization may be relational, network, hierar- 53

70 chical, or object-oriented; as well as the semantics of the data they contain can be extremely diverse. Also, different databases may be managed by distinct DBMSs. Databases are persistent, kept on disk, hence data is not lost if, or when, the application terminates. Since exceptions may occur--such as transactions not being completed because of disk or computer failure, or transaction or system error--database-centric systems do provide support for rollback/recovery, in order to maintain data integrity, by avoiding data inconsistencies. The response time requirements for most database queries is typically bounded. 4.6 Real-Time This description of the real-time style is heavily founded in the concepts described in the literature [Stankovic 1988] [Ripps 1989] [Bihari and Gopinath 1992] [Kurki-Suonio 1993] [Gomaa 1993] [Fiddler 1994] [Shaw and Garlan 1996], while focusing on the features that are relevant for composition. Real-time systems are typically multi-threaded, having threads of tasks. Some of their inputs and events arrive asynchronously, and trigger various levels of response. Very often, as a response to some event, some (or all) of the active tasks must be preempted, so that more urgent tasks can execute. CPU is not the only potential source of contention, shared resources play a very big part as well. Response time for certain events and components must be predictable in all cases, 1 whether they are preempted or not. Tasks and resources are scheduled accordingly 54

71 by the scheduler, which may sit on top of the operating system, or be part of some modified version of it. Real-time systems usually have no support for backtracking, and are non-reentrant. 4.7 Closed-Loop Feedback Control This description of the closed-loop feedback control is heavily founded in the concepts described in the literature [Westphal 1995] [Shaw and Garlan 1996], while focusing on the features that are relevant for composition. Closed-loop feedback control systems have a cycle involving control and/or data connectors, and/or shared data. The execution cycle never terminates, unless some unpredicted error situation occurs, or the power is turned off. The system continuously monitors some controlled variables, and proceeds with behavioral adaptations as needed. The controlled variables are explicitly shared data. Closed-loop feedback control systems have a set of control components for processing manipulated variables, and producing effects on controlled variables. They also have a set of control components for measuring adjustments required by controlled variables, this set of control components is also known as the controller. Depending on their complexity, closed-loop feedback control systems may have one or more (monitor-adjust) cycles, and consequently one or more controllers. 1. Since work can only be done towards anticipated possibilities, in all cases here should be interpreted as in all foreseeable cases. 55

72 While the processing components are preemptive so they can quickly adjust to changes required, there is no backtracking or reentrance present. 4.8 Internet Distributed Entities The World Wide Web (WWW) is an information and communication system that merges the techniques of networked information and hypertext to make a powerful global information system. It allows the representation of any information accessible over the network as part of a seamless hypertext information space. The WWW is popularly used on the Internet with data communications operating according to a client/server model. Web clients (browsers) can access information available at web servers located anywhere in a common network. Java can be used in conjunction with the web, extending its basic framework. A Java-enabled browser interprets and displays information sent from the server, information which can include both hypertext and bytecodes. 1 Once an applet is downloaded, it runs on the client side. The applet may then continue interacting with the server (or even contact other servers) via CORBA IIOP [Orfali et al. 1997], RMI [Downing 1998], HTTP [December and Ginsburg 1995], or RPC and socket libraries [Stevens 1990]. We call here the internet distributed entities style that of applications running on the web on top of the Internet, while using Java. 2 Applications on this style are layered, following networking layers for data and control connections. 1. Bytecode is the machine-readable code that is created as the result of compiling a Java language source file. This is the code distributed across the network to run an applet. 2. Others have called this style the Internet Distributed Objects [Kogut and Creps 1998]. 56

73 An important characteristic to note on Java is that it eliminates most of the programming problems related to memory management by providing automatic or on the fly garbage collection. Internet distributed entities systems are then multi-threaded, dynamic and distributed.their response times are unbounded, and although many do not support backtracking, web-based agents do, hence the style is unconstrained with respect to backtracking. From its composing components, at least the server is reentrant. When developing web based applications many other issues arise such as how to split the load between the client and server, how is security to be handled, error detection and correction mechanisms. These issues will not be addressed here, they are addressed elsewhere in the literature [Orfali et al. 1996, Lee 1998, Curtis 1997]. 57

74 5.0 Conceptual Features By analyzing the informal descriptions of the various styles discussed in this work (see section 4.0), various characteristics were determined as being relevant to systems composition. This section introduces each one of them (section 5.1), then discusses the choices made by each of the styles for these various features (section 5.2), and finally discusses the conceptual feature space they determine, and how to evolve it (section 5.3). 5.1 Descriptions While studying systems composition, a considerable number of features (or characteristics) were determined to be extremely relevant for the mismatch detection process. Here is a description of each one of those features, along with some indication on why they are relevant for this work Concurrency Styles often constrain the number of concurrent threads that may execute within a system. A single-threaded system is limited to only one thread of control components linked by a chain of calls (blocking control connectors), while multi-threaded systems allow more than one thread to execute concurrently Note that some of these features (section section 5.1.7) had originally been introduced by Abd-Allah (see section 2.5). Some of the original definitions and possible values have been altered to reflect a wider range of characteristics (e.g., dynamism now includes threads termination and downloadable applets; supported data transfers include shared repositories; triggering events are not only single data transfers, but actually sequences of data and/or control transfers, and/or some specific time being reached). 2. Note that concurrency is not the same as dynamism. All dynamic systems are concurrent, but the converse is not true. 58

75 When categorizing a style or system as being concurrent or not, we are actually describing whether they are multi-threaded or not. We are not addressing multiprocessing nor multitasking characteristics. When a control component c1 in a single-threaded subsystem calls a control component c2 in a multi-threaded dynamic subsystem, problems may arise by c2 spawning c3, terminating and returning control to c1, whose subsystem assumes it is running alone, consequently creating synchronization problems on accessing shared data, and/or resource contention Distribution A style may or may not constrain the mapping of system entities to nodes. If the mapping is to more than one node, then the style s systems are naturally distributed. If one of the composing subsystems was originally confined to a single node, and the resulting composed system is distributed, problems arise because the subsystem originally non-distributed cannot handle delays and/or errors occurred due to some distributed communication event Dynamism We refer to a system as being dynamic if it allows for changes to its control topology while it is running. This includes the addition and termination of concurrent threads as it executes, as well as the downloading of applets. An example of the relevance of the dynamism feature during systems composition occurs when subsystems are being composed via spawns, and at least one of the 59

76 composing subsystems does not support the dynamic creation of threads. This may actually cause synchronization problems, as well as resources contention. For the purpose of this work, the variations that may occur from system to system concerning dynamism are that no dynamism is present, or any combination of: threads can be initiated; threads can be terminated; and there are applets that may be downloaded Encapsulation Encapsulation refers to the ability of providing users with a well-defined interface to a set of functions (or objects) in a way which hides their internal workings. This entails making (some) data and processing within control components private, which allows the internal implementation to be modified without requiring any change to the application that uses it. Any particular system may choose to contain encapsulation or not. An illustration of the kind of problems that may arise related to the encapsulation feature is the fact that composition could be expected to occur via some bridging shared data, but that data is private within its original subsystem Layering Layered systems are organized hierarchically, each layer providing a virtual machine to the layer immediately above and serving as a client to the layer immediately below. Connectors are defined by protocols that determine how layers interact, and interactions are only allowed between components within the same layer, or on adjacent ones. 60

77 Styles may or may not impose system layering constraints on its control components. The layers must be specified with respect to a connector, e.g. a set of layers linked by control connectors. Hence, systems may have no layering, or have layering with respect to either control or data connectors. During composition, the situation may be such that one of the composing subsystems originally included layering constraints either on control or data connectors, and composition is achieved by extending exactly that kind of connector to such a subsystem. The bridging connector may actually ignore these layering constraints, thus violating them Supported Data Transfers Of the styles we studied, all of them achieved data transfers through some combination of: shared data variables; explicit data connectors; and shared repositories. During composition via bridging shared data, if one of the composing subsystems had no shared data support, we may run into synchronization problems Triggering Capability Hardware has interrupts, and software has triggers. Triggers are mechanisms that initiate specific actions when certain events occur. Events can be sequences of basic events such as a control or data transfer, or some specific time being reached. Actions can be sequences of basic actions like a control or data transfer. Some of the styles visited have some triggering capabilities, while others have none. 61

78 During composition, if at least 2 of the composing subsystems have triggering, and there is at least one event that has more than one trigger associated with it, one from each of the composing subsystems (i.e, each of the composing subsystems had its own set of actions that should occur once the event happens), then it is not clear which set of actions should actually occur based on the composition, and if all it is not clear what the ordering should be Backtracking Backtracking is a scheme for solving a series of sub-problems each of which may have multiple possible solutions and where the solution chosen for one sub-problem may affect the possible solutions of later sub-problems. To solve the overall problem, we find a solution to the first sub-problem and then attempt to recursively solve the other subproblems based on this first solution. If we cannot, or we want all possible solutions, we backtrack and try the next possible solution to the first sub-problem and so on. Rollback is a database management system (DBMS) feature that reverses the current transaction out of the database, returning the database to its former state. This is done when some failure interrupts a half-completed transaction. Because of the similarities between the traditional definition of backtracking and the one of rollback, this work combines both under the single name backtracking. Therefore under our classification, systems (and styles) may exhibit backtracking characteristics or not. 62

79 During composition via a bridging spawn, the spawner may belong to a subsystem that has backtracking. This being the case, if the spawner backtracks after the spawn has occurred, there is no pre-existing way of backtracking the state changes caused by the spawned end Control Unit Some styles and/or systems have a central control unit which is responsible for arbitrating which components are to execute at any given point in time. That is, it dictates the execution ordering based on some pre-defined mechanism. Additionally, it is possible for systems to have distributed control units or none at all. Hence, for our classification purpose, systems (and styles) may contain a central control unit, distributed control units, or no control units. An illustration of the kind of problems that may arise related to the control unit feature is the fact that as a result of composition more than one central control unit may exist, all of which assume they have absolute control on execution sequencing Component Priorities Differing priorities for control components reflect the fact that some tasks results may be more urgent than others, or simply that previous knowledge shows that executing some control component before another yields better results. Many of the styles visited (see section 4.0 on page 48) grant differing priorities to their control components. Styles and systems may require that their components exhibit some prioritization or not. 63

80 An instance in which the component priorities may cause mismatches during composition is if one of the subsystems to be composed has a prioritized structure, since then it is not clear where a component with or without an associated priority fits in an overall separately prioritized structure Preemption We say we have preemption present when the scheduler can interrupt and suspend ( swap out ) a currently running task in order to start or continue running ( swap in ) another task. The tasks under preemptive multitasking can be written as though they were the only task and the scheduler decides when to swap them. The scheduler must ensure that when swapping tasks, sufficient state is saved and restored, and that tasks do not interfere. Styles and systems may require preemption to be present or not. If composition is to be achieved via a bridging call, and the caller is preemptive, while the callee is not, we may run into problems when preempting the caller, because the callee will not be preempted Reconfiguration 1 Upon some special conditions (or failures), some systems perform on-line reconfiguration, whereas others have it done off-line. Also, some systems have on-the-fly garbage collection, thus reconfiguring its memory space on-line. 1. This feature was not drawn from any of the specific styles visited, but it is a very relevant descriptor for systems undergoing composition. 64

81 For the purpose of this work, the variations that may occur from system to system concerning reconfiguration are that there may be on the fly garbage collection, and reconfiguration may be done either on line or it may require off line intervention. If at least one of the parts to be composed has on-line reconfiguration, while at least one other has reconfiguration off-line, then upon failure only part of the resulting system will automatically reconfigure Reentrance A reentrant code can have multiple simultaneous, interleaved, or nested invocations which will not interfere with each other. This is important for parallel processing, recursive functions or subroutines, and interrupt handling. It is usually easy to arrange for multiple invocations (e.g. calls to a subroutine) to share one copy of the code and any read-only data but, for the code to be re-entrant, each invocation must use its own copy of any modifiable data (or synchronized access to shared data). This is most often achieved using a stack and allocating local variables in a new stack frame for each invocation. Systems (and styles) may contain control components that are reentrant. When composition is to be achieved via some bridging call, and the callee is not reentrant, it may be the case that this call occurs once the callee is already running, in a way which contaminates the state information of the already-running invocation. 65

82 Response Times Some systems require that the response time for certain events be predictable, others expect some bounded response time, and others may even have no bound as far as response time is concerned. Some systems may contain cycles, in which case the overall response time for the system is unbounded, but each cycle may have a stricter response time requirement. For the purpose of this work, the variations that may occur from system to system concerning response times are that there may be some predictable, bounded, or unbounded response time requirements; or they may be cyclic (where by cyclic we mean it contains a cycle that will run indefinitely). An example of the relevance of the response time feature during systems composition occurs when there is a call to a cyclic subsystem, since it will never terminate 1 and consequently never return the control to the caller. 5.2 Styles Choices Now we need to revisit the previously described styles (section 4.0 on page 48) and determine how the various conceptual features apply to them. Note that styles may choose to be unconstrained with respect to some of the features, connoting that each particular system instance of that style has the freedom to implement such feature as suited It will never terminate under foreseen conditions, unexpected situations may cause it to terminate abnormally. 2. Here again, some of the styles had originally been described by Abd-Allah, but only reflected the conceptual features his work encompassed. These styles are being revisited here (section section 5.2.4) in order to reflect all relevant features, and in the case of the eventbased style also the changes discussed in section

83 5.2.1 Distributed Processes This style is multi-threaded and dynamic, allowing for spawns and termination of threads, but is unconstrained with respect to applets. Data is transferred via explicit data connectors, but it may also have shared data variables or shared repositories. Distributed processes systems are distributed over multiple physical processor nodes. They have no support for backtracking, and are unconstrained with respect to triggering. These systems typically have unbounded response time requirements, no differentiating priorities among their various control components, and no control unit. The distributed processes style is unconstrained with respect to layering, encapsulation, preemption, reentrance, and reconfiguration Event-Based This style is multi-threaded and unconstrained as far as the spawning and termination of threads, or the existence of applets is concerned. It has triggering capabilities steered by the event manager, which may be a central control unit or a set of distributed ones. Its control components have implicit priorities, determined by the order of basic actions to be taken upon specific event occurrences. Its systems instances typically have unbounded response time requirements, and no support for backtracking. The event-based style is unconstrained with respect to reentrance, its supported data transfers, distribution, layering, encapsulation, preemption, and reconfiguration. 67

84 5.2.3 Main-Subroutine The main-subroutine style is static, permitting no spawns, no terminates, and containing no applets. It contains shared data variables, but typically no explicit data connectors, nor shared repositories. It has no support for triggering, is single-threaded, and is non-distributed. Instance systems of the main-subroutine style usually do not support preemption or backtracking, have unbounded response time requirements, have no differentiating priorities among their various control components, and have no control unit. Main is nonreentrant, but other control components may be. This style is unconstrained with respect to layering, encapsulation, and reconfiguration Pipe-and-Filter The pipe-and-filter style is static and multi-threaded, all filters start executing when the system is started, and there are no spawns or terminates, but there may be applets. Data is transferred via explicit data connectors, the pipes. It has no support for triggering, preemption, backtracking or reentrance. Systems of the pipe-and-filter style have unbounded response time requirements, no differentiating priorities among their various control components, and no control unit. This style is unconstrained with respect to distribution, layering, encapsulation, and reconfiguration. 68

85 5.2.5 Transactional Database-Centric This style is unconstrained with respect to applets. There is data sharing via the shared repository, the database. It has triggering capabilities guided by its central control unit, the DBMS. It may have differentiating priorities among the various control components depending on the kind of query they perform, and there is support for backtracking in the form of rollback for the DBMS. Transactional database-centric systems are typically multi-threaded, and have response time requirements that are bounded. The DBMS is reentrant, whereas other control components are unconstrained in that respect. The transactional database-centric style is unconstrained with respect to the dynamic creation or termination of threads, the existence of data connectors, distribution, layering, encapsulation, preemption, and reconfiguration Blackboard The blackboard style may contain applets. The only means of data sharing and transferring is via the shared repository. It has triggering capabilities guided by its central control unit, the control unit. Its control components are prioritized, and there is support for backtracking. Blackboard systems have no support for preemption or reentrance. This style is unconstrained with respect to the dynamic creation or termination of threads, concurrency, distribution, layering, encapsulation, response time requirements, and reconfiguration. 69

86 5.2.7 Rule-Based The rule-based style may have applets. The only means of data sharing and transferring is via the shared repository of facts, the working memory. It has triggering capabilities guided by its central control unit, the interpreter. Its control components are prioritized, and there is support for backtracking. Rule-based systems have no support for preemption or reentrance. This style is unconstrained with respect to the dynamic creation or termination of threads, concurrency, distribution, layering, encapsulation, response time requirements, and reconfiguration Logic Programming The logic programming style may have applets. The only means of data sharing and transferring is via the shared repository of unification values. It has triggering capabilities guided by its central control unit, the interpreter. Its control components are prioritized, and there is support for backtracking. Logic programming systems have no support for preemption or reentrance. This style is unconstrained with respect to the dynamic creation or termination of threads, concurrency, distribution, layering, encapsulation, response time requirements, and reconfiguration Real-Time The real-time style is multi-threaded and dynamic, allowing for spawns and termination of threads, but no applets. It has triggering capabilities guided by its central 70

87 control unit, the scheduler. Its control components are prioritized, it has some predictable response time requirements, and no support for backtracking. Real-time systems are preemptive, yet non-reentrant. This style is unconstrained with respect to its supported data transfers, distribution, layering, encapsulation, and reconfiguration Closed-Loop Feedback Control This style uses no applets. It does have shared data variables: the controlled variables and possibly others. Triggering capabilities are present, and dealt with by the controller. Its systems may have one or more controller, that are their control units. At least the processing components are preemptive, and systems have response time unconstrained (while each monitoring cycle has response time cyclic). There is no backtracking present, nor any reentrance support. The closed-loop feedback control style is unconstrained with respect to the creation and termination of threads, the existence of data connectors or shared repositories, concurrency, distribution, layering, encapsulation, component priorities, and reconfiguration Internet Distributed Entities The internet distributed entities style is multi-threaded and dynamic, allowing for spawns and termination of threads, and also containing downloadable applets. It has explicit data connectors, and may have shared data variables and/or repositories. It has triggering capabilities, is distributed and layered with respect to control connectors. Its 71

88 response time requirements are unbounded, and there may be support for backtracking. At least the server is reentrant, there is on the fly garbage collection, and no control unit. This style is unconstrained with respect to encapsulation, preemption, component priorities, and whether there is on or off-line reconfiguration Conceptual Features Table Revisited The discussion above on the various conceptual features and the specific choices made by each style can be summarized as in table 6 and table 7, where represents entries that were defined by Abd-Allah s work (section 2.5), represents entries that were initially defined by Abd-Allah and later refined by this work, represents new entries defined and analyzed in this work, and represents entries that had their specific values changed by this work. Additionally, entries left blank mean unconstrained. 5.3 Conceptual Feature Space Our conceptual feature set (section 5.1) was built by focusing on the characteristics that seem relevant to systems composition. In order to understand the reasoning behind determining what is to be considered a conceptual feature or not, one must first comprehend the characteristics of the conceptual feature space. First and foremost it is important to keep in mind that we are dealing with architectural features of applications systems that are relevant to composition, not just any kind of feature. Those clearly eliminate functional and environmental characteristics [Prieto-Diaz and Freeman 1987] and go beyond signature matching [Zaremski and Wing 1993]. 72

89 Distributed Processes Event-Based Main/ Subroutine Pipe & Filter Database- Centric Concurrency multi-threaded multi-threaded single-threaded multi-threaded multi-threaded Distribution multiple nodes single node Dynamism threads static, no applets static Encapsulation Layering Supported data transfers explicit data connectors shared data variables explicit data connectors shared repository Triggering capability yes no no yes Backtracking no no no no yes (rollback) Control unit none none none central Component Priorities no implicit no no Preemption no no Reconfiguration Reentrance no (main); unconstrained(others) no yes Response Times unbounded unbounded unbounded unbounded bounded Table 6: Instances of Our Architectural Style Space 73

90 Blackboard Rule-Based Logic Programming Real-Time Closed-Loop Feedback Control Internet Distributed Entities Concurrency multi-threaded multi-threaded Distribution Dynamism threads, no applets no applets multiple nodes threads, downloaded Applets Encapsulation Layering Supported data transfers Triggering capability shared repository shared repository shared repository shared variables yes yes yes yes yes control data connectors yes Backtracking yes yes yes no no Control unit central central central central none Component Priorities yes yes yes yes Preemption no no no yes yes Reconfiguration on the fly garbage collection Reentrance no no no no no yes (server) Response Times predictable cyclic unbounded 74 Table 7: Instances of Our Architectural Style Space (cont.)

91 What we would like from a conceptual feature space is for it to have axes that portray orthogonality of concepts, as well as support the formal description and classification of features along them. Upon the establishment of a new style, one should then analyze it for its characteristics based on the conceptual feature space axes, to determine whether it has some feature not presently covered. We view the conceptual feature space as being defined by control and data flow issues as well as organizational ones, that are complementary but yet orthogonal. In other words, architectural features relevant to composition are those that depict how control and data are to flow through the various components and connectors, as well as specific organizational characteristics of systems. Consequently, we can discuss our conceptual feature set by their relevance on each of these axes. Some of the conceptual features are relevant to more than one of these dimensions, while others concentrate on a single one. When a new style surfaces, one should then analyze it for its control flow, data flow, and organizational characteristics, to see whether it has some feature not presently covered. With the conceptual feature set at hand, along with considerations on how each can affect control and/or data flow and/or organizational characteristics, we can then evaluate reusable parts for their features, and consequently classify them accordingly. By classifying our current features according to our feature space we can depict those that are related to data flow issues (figure 4), control flow issues (figure 5), and organizational issues (figure 6) Both data and control issues axes have the ordering represent the degree of state saving required, whereas the organizational issues one represents the amount of constraints imposed on systems by using each specific organizational scheme. 75

92 Concurrency Triggering Reentrance & Preemption & Reconfiguration Data Transfers Backtracking Data Issues Figure 4: Data Flow Issues Axis The control flow axis (figure 5) looks very busy still. One possible way of clustering the control related information is by degree of state saving and lines of control. By doing so, under degree of state saving we would have: triggering capability, reentrance, preemption, reconfiguration, and backtracking; and under lines of control we would have: concurrency, dynamism, control unit, components priorities, reentrance, and preemption. Note that response times does not fit into either of these clusters. Control Unit Concurrency Dynamism Component Priorities Triggering Response Time Reentrance Preemption & Reconfiguration Backtracking Control Issues Figure 5: Control Flow Issues Axis Encapsulation Layering Distribution Organizational Issues Figure 6: Organizational Issues Axis 76

93 This initial effort towards defining the conceptual feature space has some merit, laying out foundations to be further pursued in determining a more robust and formal underpinning. Still it requires further study in a few directions before reaching its full potential. Further consideration is needed in order to determine the optimum breakout for the control axis. We mentioned one possible way, but others do exist and may provide a more useful partition than the one mentioned above. Moreover, a considerable amount of work is required towards formally defining this space, as well as formally classifying its features. The organizational issues axis also needs further characterization, as can be seen via the complex interaction of encapsulation, layering, and distribution in architectures such as that of the Internet. We have also done some work towards time classification of systems and what results should be expected while performing various operations. This can be found in appendix D. 77

94 6.0 Architectural Mismatches Architectural mismatches are logical inconsistencies between constraints of different architectures being composed. Here we describe a few examples of the mismatches that could be potentially found while composing with systems in the styles covered by this work (section 6.1). Subsequently, we present the mismatches table containing a classification of the mismatches we consider relevant during systems composition, along with explanations of the preconditions required for each of these mismatches to occur, and the exact problem faced (section 6.2). 6.1 Architectural Mismatches Examples To elucidate what exactly we mean by architectural mismatches, we discuss here a few examples in a more in depth fashion. Consider the case when we wish to have various subsystems, or parts of them, residing in the same machine. It can be the case where these parts assume a different underlying platform, hence we cannot have the same machine satisfy both platform requirements. This is represented by our mismatch number 17, Erroneous assumption of same underlying platform. (see section 6.2). Another instance of architectural mismatch occurs while composing two (or more) subsystems each of which containing a central control unit, (e.g. two event-based subsystems, each contains its own (single) event manager). A problem arises because each of the central control units assumes it has absolute control on execution sequencing. This 78

95 mismatch is our number 21, More than one central control unit exists, all of them assuming they have absolute control on execution sequencing. (see section 6.2). When composing 2 subsystems that have triggering, it may be the case where there is at least one event that has more than one trigger associated with it, one from each of the composing subsystems (i.e, each of the composing subsystems had its own set of actions that should occur once the event happens). This situation causes problems because it is not clear which set of actions should actually occur based on the composition, and if all it is not clear what the ordering should be. Our mismatch number 12, There is a nondeterministic set of actions that could be caused by a trigger. represents exactly this situation (see section 6.2). 6.2 Architectural Mismatches Table Based on the newly established conceptual features (section 5.0) and the original mismatches table introduced by Abd-Allah (section 2.5 on page 19), we introduce our mismatches table (table 8). 1 On our table we did change some of the original mismatches discussed by Abd-Allah (his numbers 2, 3, 5, 8, and 12), we merged some, we made a few others more generic, and still others were subsumed by some of the new ones. Consequently, the mismatches uncovered by Abd-Allah constitute mismatches number 1 to 11, whereas all others were uncovered by our work.we also removed the bridging connectors triggered call, 1. Once again, represents features defined by Abd-Allah, represents features defined by Abd- Allah and evolved in this work, and represents new features defined and analyzed in this work. New mismatches defined in this work are represented by boldface numbers in table 8. 79

96 triggered spawn, and triggered data transfer, and added a single bridging connector called trigger. The items included there were just like the ones with the same kind of connectors without triggered, except for the triggering capabilities row in which case the mismatches themselves incorporate the triggered factor. Additionally we renamed his shared machine bridging connector to shared resources, making it a bit more generic. A listing of all mismatches is given below, along with explanations of the preconditions required for each of them to occur, and the exact problem faced. 1. Two concurrent threads share data, with potential synchronization problems. Precondition: Composing parts are to run concurrently (regardless on whether they were originally concurrent or not), and do share some data. Problem: Potential synchronization problems for concurrent threads while sharing data. 2. A layering constraint is violated. Precondition: Any of the composing subsystems originally included layering constraints either on control or data connectors, and composition is achieved by extending exactly that kind of connector to such a subsystem. Problem: Bridging connector may ignore these constraints, thus violating them. 3. Different sets of recognized events are used by two subsystems that permit triggers. Precondition: At least 2 of the composing subsystems permit triggers but have different sets of possible triggering events. 80

97 Call Spawn Data connector Shared data Trigger Shared resources Concurrency 15, 34 9, 15, , 34 9, 15, 34 Data transfers 7, 42 8, 42, Distribution Dynamism Encapsulation , 39 18, 19, 38, 39 Layering Triggering 3, 12 3, 12 3, 12 3, 12 3, 5, 6, 12 Backtracking , 29 Control unit 21, 46 21, 46 21, 46 21, 46 21, 46 Component Priorities Preemption , 36 Reconfiguration 33, , 37 Reentrance , 24, 25 Response Times 16, 31, 37, 40, 41 32, 40, 41 40, 41 40, 41 16, 31, 32, 37, 40, Regardless 13, 14 11, Table 8: Architectural Mismatches

98 Problem: A trigger may not be recognizable by some subsystem that should. 4. A (triggered) spawn is made into or out of a subsystem which originally forbade them. Precondition: Subsystems are being composed via (triggered) spawns, and at least one of the composing subsystems does not support the dynamic creation of threads. Problem: A (triggered) spawn is made into or out of a subsystem that originally forbade them. May cause synchronization problems, as well as resources contention. 5. An unrecognized triggering event is used. Precondition: A trigger is used as a bridging connector, but its generating event can never occur. Problem: The trigger will not cause the expected behavior, it will never fire the related actions. 6. A trigger refers to subsystems which originally forbade triggering. Precondition: All of the composing subsystems forbade triggering, and some of the composition is to be achieved via some bridging triggers. Problem: The trigger will go by ignored, there is no underlying mechanism available to handle the triggering. 7. A data connector is made into a subsystem which originally forbade them. Precondition: Some of the composition is to be achieved via bridging data connectors, and at least one of the composing subsystems did not originally support data connectors. 82

99 Problem: Unclear on how data is to be handled for sending or receiving. 8. A shared data relationship refers to a subsystem which originally forbade them. Precondition: Some of the composition is to be achieved via bridging shared data, and one of the composing subsystems had no shared data support. Problem: May cause synchronization problems. 9. A (triggered) spawn is made into or out of a subsystem which is not concurrent. Precondition: Some of the composition is to be achieved via bridging (triggered) spawns, and one of the composing subsystems does not support the execution of concurrent threads. Problem: May cause synchronization problems, as well as resources contention. 10. A remote connector is extended into or out of a non-distributed subsystem (i.e. a subsystem originally confined to a single node). Precondition: One of the subsystems was originally confined to a single node, and the resulting composed system is distributed. Problem: The subsystem(s) originally non-distributed cannot handle delays and/or errors occurred due to some distributed communication event. 11. A node resource is overused. Precondition: Resources required are greater than the ones available at a given node. Problem: Resource overusage such as memory and disk space. 83

100 12. There is a non-deterministic set of actions that could be caused by a trigger. Precondition: At least 2 of the composing subsystems have triggering, and there is at least one event that has more than one trigger associated with it, one from each of the composing subsystems (i.e, each of the composing subsystems had its own set of actions that should occur once the event happens). Problem: It is not clear which set of actions should actually occur based on the composition, and if all it is not clear what the ordering should be. 13. Data connectors connecting control components that are not always active may lead into deadlock. Precondition: We have a blocking bridging data connector and the receiving control component may be inactive when data is sent through the data connector, and it may never become active (again). Problem: Possibility of deadlock on the control component sending the data. 14. Data connectors connecting control components that are not always active. Precondition: We have a non-blocking and non-buffered bridging data connector and the receiving control component becomes active after the data was sent and lost. Problem: Possibility of loss of data. 15. Erroneous assumption of single-thread. Precondition: A control component c1 in a single-threaded subsystem calls a control component c2 in a multi-threaded dynamic subsystem. The problem may arise by c2 spawning 84

101 c3, terminating and returning control to c1, whose subsystem assumes it is running alone. OR there is a call from a multi-threaded to a single-threaded subsystem. OR there is a spawn from a (single or) multi-threaded subsystem to a single-threaded one, the spawnee assumes it is running alone. Problem: Synchronization problems on accessing shared data, and/or resource contention. 16. (Triggered) Call to a cyclic (non-terminating) subsystem/control component. Precondition: There is a bridging (triggered) call to a cyclic (and hence non-terminating) subsystem / control component. Problem: Control will never be returned to the caller. 17. Erroneous assumption of same underlying platform. Precondition: During composition we would like to have some subsystems running on a shared machine, but they actually assume different underlying platforms. Problem: Cannot force fit parts to a given platform. 18. (Triggered) Call to a private method. Precondition: There is a bridging (triggered) call to a private method. Problem: Method not accessible to the caller. 19. (Triggered) Spawn to a private method. Precondition: There is a bridging (triggered) spawn to a private method. Problem: Method not accessible to the spawner. 85

102 20. Sharing private data. Precondition: Composition is also to be achieved via some bridging shared data, but that data is private within its original subsystem. Problem: Data not accessible to all of the sharing entities being composed. 21. More than one central control unit exists. Precondition: More than one central control unit exists as a result of composition. Problem: All central control units assume they have absolute control on execution sequencing. 22. Sharing data with a reentrant component. Precondition: Composition is to be achieved via some bridging shared data, and at least one of the components to share it is reentrant. Problem: Sharing of data may occur with the incorrect invocation of a component. 23. A reentrant component is either sending or receiving a data transfer. Precondition: Composition is to be achieved via some bridging data connector, and at least one of the involved control components is reentrant. Problem: Potential incorrect assumption of which invocation of a component is either sending or receiving a data transfer. 24. (Triggered) Call to a non-reentrant component. Precondition: Composition is to be achieved via some bridging (triggered) call, and the callee is not reentrant. 86

103 Problem: Component may already be running. 25. (Triggered) Spawn to a non-reentrant component. Precondition: Composition is to be achieved via some bridging (triggered) spawn, and the spawnee is not reentrant Problem: Component may already be running. 26. Composition involves one or more prioritized parts. Precondition: One of the subsystems to be composed has a prioritized structure. Problem: Not clear where a component(s) with or without an associated priority fits in an overall separately prioritized structure. 27. A prioritized system sharing a machine with some other system. Precondition: A prioritized system sharing a machine with some other system. Problem: Unclear on how priorities compare across the various parts, which affects the way interrupts are to be applied. 28. (Triggered) Call or spawn from a subsystem that may later backtrack. Precondition: At least one of the callers or spawners of bridging connections belongs to a subsystem that has backtracking. Problem: While backtracking may cause undesired side effects on the called/spawned end. 87

104 29. Data being transferred from some component(s) that may later backtrack. Precondition: Composition is to be achieved via some bridging data connector, and the component to send data through such a connection belongs to a subsystem that has backtracking. Problem: Backtracking may cause undesired side effects on the overall composed system state. 30. Shared data being modified by a component(s) that may later backtrack. Precondition: At least one of the subsystems sharing bridging data has backtracking. Problem: Data being shared with some component(s) that may later backtrack, thus causing possible undesired side effects on the overall composed system state. 31. (Triggered) Call from a subsystem requiring some predictable response times to some component(s) not originally considered. Precondition: Composition is to be achieved via some bridging (triggered) call, and at least one of the calling parts requires predictable response times to some event(s). Problem: May have side effects on original predicted response times. 32. (Triggered) Spawn to or from a subsystem requiring some predictable response times that involves some component(s) not originally considered. Precondition: Composition is to be achieved via some bridging (triggered) spawn, and at least one of the parts involved requires predictable response times to some event(s). 88

105 Problem: May have side effects on original predicted response times. The original predicted response times not account for concurrently executing with these other components. 33. Only part of the resulting system automatically reconfigures upon failure. Precondition: At least one of the parts to be composed has on-line reconfiguration, and at least one has reconfiguration off-line. Problem: Only part of the resulting system automatically reconfigures upon failure. 34. Some components that were expected to synchronize have different synchronization mechanisms. Precondition: Composing parts are to run concurrently while synchronizing, and have different synchronization mechanisms. Problem: Synchronization between concurrent parts cannot properly take place. 35. (Triggered) Call to a component that should be preemptable and isn t. Precondition: Composition is to be achieved via a bridging (triggered) call, and the caller is preemptable, while the callee is not. Problem: Callee will not be preempted in situations when it should. 36. (Triggered) Spawn to a component that should be preemptable and isn t. Precondition: Composition is to be achieved via a bridging (triggered) spawn, and the spawner is preemptable, while the spawnee is not. Problem: Spawnee will not be preempted in situations when it should. 89

106 37. (Triggered) Call to a component that performs on the fly garbage collection. Precondition: Composition is to be achieved via a bridging (triggered) call, the callee performs on the fly garbage collection, while the caller has requirements for some predictable or bounded response times. Problem: Undesirable side effects on the overall predictable or bounded response times. 38. Incorrect assumption of which instantiation of an object is either sending or receiving a data transfer. Precondition: Composition is to be achieved via a bridging data connector, and at least one of the parts affected by such connection has encapsulation. Problem: Incorrect assumption of which instantiation of an object is either sending or receiving a data transfer. 39. Sharing data with the incorrect instantiation of an object. Precondition: Composition is to be achieved via some bridging shared data, and at least one of the parts involved has encapsulation. Problem: Sharing data with the incorrect instantiation of an object. 40. Time represented/compared using different granularities. Precondition: More than one of the composing parts has response time different than unbounded and cyclic unbounded. Additionally, they are distributed over machines that represent and/or compare time using different granularities. Problem: Communications concerning time cannot properly occur. 90

107 41. Absolute time values are off. Precondition: More than one of the composing parts has response time different than unbounded and cyclic unbounded. Additionally, they are distributed over machines that have their wall-clock time off. Problem: Communications concerning time cannot properly occur. 42. Sharing or transferring data with differing underlying representations. Precondition: Sharing or transferring data with differing underlying representations, including differences in data formats, units and coordinate systems. Problem: Communications concerning the specific data will not properly occur. 43. Resource contention. Precondition: Two or more parts are co-hosted, with at least one requiring some predictable response time, and the original analysis did not take into account some of the parts that are currently co-hosted. Problem: Predictable response time indirectly affected because there may be some resource contention not originally considered. 44. Potential database and/or DBMS heterogeneity problems may occur. Precondition: Two or more repositories are present. Problem: Our model does not support for checking the specifics here, but problems may arise on semantic heterogeneity, differing data items granularity, databases being distrib- 91

108 uted or not, databases being replicated or not, and/or databases having different structural organizations. 45. Inaccessible shared data. Precondition: Composition is being achieved by having an applet share data that is local to the client side. Problem: Applets have no access to the local file system of the client side (i.e., the applet cannot really access the data that is to be shared). 46. Distributed control units are present. Precondition: Two or more of the composing subsystems have distributed control units. Problem: Incorrect assumption that a problem is being solved elsewhere, by some other control unit. 92

109 93

110 7.0 Modeling Styles and Their Features This section contains all information relevant to the Z model, as well as the model itself. We start here by presenting the changes required by the base elements set and Abd-Allah s original model (section 7.1). 1 Subsequently we provide guidelines as on how to reflect systems and/or styles features by using the basic framework provided (section 7.2). As seen in section 7.3, we have spent some effort revisiting all of Abd-Allah s styles descriptions. This was required in order to reflect the changes to the base elements, as well as each of the styles full set of feature choices. 2 This section also contains the Z models of all styles we are addressing. The model for detecting mismatches and composing systems is introduced in section Basic Entities Model In order to reflect our judgment in the model it had to evolve considerably, many of the existing basic entities were modified, and numerous support additions occurred. Here we simply list the main ones. Their details can be found in appendix C on page 224. Basic support additions: 1. A full uninterrupted version of our model can be found in appendix C, and Abd-Allah s in appendix B 2. Abd-Allah s model of the event-based style was changed considerably more than the others. What we have done was to have the existence of an event manager propagate into the Z model. This actually allows for the detection of one more potential architecture compositional mismatch. 93

111 BasicAction: schema describing a single action as being either a control or a data transfer. BAtype: type indicating whether a basic action is a control or a data transfer. BasicEvent:schema describing a single event as being either a control or a data transfer, or some absolute time being reached. BEtype: type indicating whether a basic event is a control or a data transfer, or some absolute time being reached. CCtype: type for indicating what type a control component has CCNtype: type for indicating what type a control connector has RTimetype: type for indicating possible expected response times Reconfiguration_type: type for indicating the kinds of reconfiguration supported by systems check_basicevents: function that makes sure the basic events composing a given event (sequence) belong to either one of the given control or data transfer event sets or to some time checking event. check_basicactions: function that makes sure the basic actions composing a given action (sequence) belong to either one of the given control or data transfer action sets. gettriggeredcontrolcmp: function that returns all the triggered control components, regardless of the kind of action (actually, the parameters are a sequence of basic actions and the kind of control transfer we are looking for). 94

112 generates_basicactions: function that makes sure the basic actions composing a given action (sequence) are generated by the given control component. gettriggeredcalls: function for recursively retrieving all the triggered calls associated with a set of actions, each being a sequence of basic actions. gettriggeredspawns: function for recursively retrieving all the triggered spawns associated with a set of actions, each being a sequence of basic actions. SynchronizationMechanism: given set of synchronization mechanisms added Java as another possible implementation language New schemas and/or relations: Action: actual actions are sequences of basic actions Event: actual events are sequences of basic events DataTransfer: Z abbreviation definition for a data connector, the 2 control components it can transfer data between, and the various data components that can be sent in the specific situation. The effects of a data transfer are reflected in the schema ActualDataTransfer. ControlTransfer: Z abbreviation definition for a control connector and the 2 control components it can transfer control between. The effects of a control transfer are reflected in the schema ActualControlTransfer. Return: new kind of control connector to be paired with calls and spawns. Interrupt: new kind of control connector. Swap_In: new kind of control connector to be paired with interrupts. Terminate: new kind of control connector. 95

113 CallReturn: actually pairing calls with theirs respective returns. SpawnReturn: actually pairing spawns with their respective returns. InterruptSwapIn: actually pairing interrupts with theirs respective swap-ins. Time: schema for time representation. TimeGranularity: the type of granularity used for some time representation. Schemas removed: Object is no longer a schema, but a specialization of ControlComponent. Trigger is no longer a schema but a relation matching between Events (sequences of basic events) and Actions (sequences of basic actions). Changes to pre-existing schemas: under system: added the sets of running control components, inactive control components, and suspended control components. All of these are used by the operations ActualDataTransfer, ActualControlTransfer, and StartSystem: added repositories, control units, response_time, reconfiguration, backtracking, and synchronization mechanisms. These were required in order to represent various new features. under node: added wall_clock_time, time_representation, and resources. These additions allow us to check for a few other mismatches. under controlcomponent: 96

114 priority, applet, preemptive, response_time, reentrant, invocation. All of these were required for some features representations. Operations: StartSystem: starts the system as having all the initialcontrolcmps running, no control components suspended, and all others inactive. ActualDataTransfer: confirms that the actual data transfer can occur at that given point in time. ActualControlTransfer: Reflects the effects of control transfers within a system by updating the set of its running, inactive, or suspended control components. It also performs some checks for the mismatches that include dynamic characteristics. General fixes: Made sure that the directionality in data connectors corresponds to the characteristics of the ports they are attached to. Changed shared data under system so that now it is a set of all shared data, not just a single data component being shared. Made sure that the resources on each of the system s nodes are enough to support all parts that reside on them. 97

115 Clearly all additions, changes and removals impose some propagation effect on other existing entities specially in the form of new constraints. 1 Although those were not made explicit here they were incorporated in the model. 7.2 Modeling the Conceptual Features The various features we discussed in section 5.0 are reflected in the model of systems and styles by using the underlying framework that we have devised. We describe here how to model each one of them. For examples on these guidelines been applied see section 7.3. The items mentioned here are the main points, but as it can be seen in the model, each one of them implies many other restrictions that are represented via various entities constraints (see appendix C). Dynamism: threads initiating: system has spawns threads terminating: system has terminates downloaded applets: system has at least one control component that is an applet none: system has no spawns, terminates, or control component that is an applet Supported Data Transfers: shared data variables: system has shared data variables explicit data connectors: system has explicit data connectors shared repositories: system has shared repositories 1. For example, the union of set of running, inactive, and suspended control components that are part of a system yields this system s set of control components. Additionally, the set of running, inactive, and suspended control components of a system are disjoint. These sets evolve as the system is started, and control transfers occur. 98

116 none: system has no shared data variables, explicit data connectors, or shared repositories Triggering Capability: yes: system has triggers no: system has no triggers Concurrency: yes: system has spawns and/or more than one initial control component no: system has no spawns, nor more than one initial control component Distribution: single node: all system s parts reside on a single node multiple nodes: system s parts are distributed over more than one node Layering: data: system has dataconnector layers control: system has call or spawn layers none: system has no (call/spawn/dataconnector) layers Encapsulation: yes: system has objects no: system has no objects Backtracking: yes: system has backtracking TRUE no: system has backtracking FALSE Component Priorities: 99

117 yes: system has at least one control component with priority different than 0 no: system has no control component with priority different than 0 Control Unit central: system has single control unit distributed: system has more than one control unit none: system has no control unit Preemption: yes: there is at least one control component that is preemptive no: there is no control component that is preemptive Reconfiguration: on-line: system has reconfiguration = {online} off-line: system has reconfiguration = {offline} system may also have reconfiguration be a combination of (on or off line) and on the fly garbage collection Reentrance: yes: system has at least one control component with reentrant TRUE no: system has no control component with reentrant TRUE Response Times: predictable: system has response_time predictable bounded: system has response_time bounded unbounded: system has response_time unbounded cyclic: system has response_time cyclic 100

118 7.3 Complete Model of Styles Below we have included our model of the various styles we address, while reflecting their various features according to table 6 on page 73 and table 7 on page 74, and the guidelines provided above (section 7.2). While most of the styles initially described by Abd-Allah evolved only as to reflect the new set of features (and changes to the basic model entities) we are using, his event-based style description changed considerably. The Event Based style is now multithreaded and unconstrained with respect to dynamism, and the actual existence of the event manager is reflected in the model Pipe and Filter % Pipe & Filter Style global PF_DataStructure : P DataComponent; PF_Socket : P Port; PF_Pipe : P DataConnector; PF_Filter : P ControlComponent; PF_System : P System; axiom forall s : % No socket is used for both input and output s.iotype /= io_inout and % All data transfers are streamed s.streaming = TRUE; forall p : % Pipes always connect filters and not objects p.c1.type = other and p.c2.type = other and % Unidirectional p.directionality = forward and % Pipe connects two filters {p.c1, p.c2} subseteq PF_Filter and % Ports belong to the P/F style {p.p1, p.p2} subseteq PF_Socket and % p1 acts as sender, p2 acts as receiver p.p1.iotype = io_out and p.p2.iotype = io_in and % The sender socket is different than the receiver 101

119 p.p1 /= p.p2; forall f : % Ports belong to the P/F style f.ports subseteq PF_Socket and f.locals subseteq PF_DataStructure and % There are no applets among the filters. f.applet = FALSE and % No filter is preemptive. f.preemptive = FALSE and % Filters have no associated priorities. f.priority = 0 and % Filters are non-reentrant. f.reentrant = FALSE; forall s : s in MultiThreadedSystems and s.controlcomponents subseteq PF_Filter and s.dataconnectors subseteq PF_Pipe and s.globalobjs = {} and s.controlconnectors = {} and s.shareddata = {} and s.repositories = {} and s.triggers = {} and s.initialcontrolcmps = s.controlcomponents and s.initialdataconnectors = s.dataconnectors and s.response_time = unbounded and % PF systems have no backtracking. s.backtracking = FALSE and % PF systems have no control units s.controlunit = {} and % All pipe sockets connect filter sockets (forall p : exists f1, f2 : p.p1 in f1.ports and p.p2 in f2.ports) and % No two pipes connect the same sender and receiver (forall p1, p2 : ((p1.p1 = p2.p1 and p1.p2 = p2.p2) => p1 = p2)); end axiom Main/Subroutine % Main / Subroutine Style global MS_DataStructure : P DataComponent; MS_Procedure : P ControlComponent; MS_ProcedureCall : P Call; MS_System : P System; axiom forall p : p.ports = {} and 102

120 p.locals subseteq MS_DataStructure and % There are no applets among the procedures. p.applet = FALSE and % No procedure is preemptive. p.preemptive = FALSE and % Procedures have no associated priorities. p.priority = 0; forall pc : % Call connects two procedures {pc.c1, pc.c2} subseteq MS_Procedure and % Procedure calls cannot be queued pc.queuesize = 0; forall s : s.controlcomponents subseteq MS_Procedure and dom s.shareddata subseteq MS_DataStructure and s.repositories = {} and s.calls subseteq MS_ProcedureCall and % MS systems have only calls and returns as control connectors. (forall cn : ControlConnector cn in (cn.type = call or cn.type = return)) and s.dataconnectors = {} and s.triggers = {} and s.response_time = unbounded and % MS systems have no backtracking. s.backtracking = FALSE and % MS systems have no control units s.controlunit = {} and % MS systems have a single initial control component, main. # s.initialcontrolcmps = 1 and % All M/S systems have a single thread # (getmaxthreads(s)) = 1 and % System forms a connected, directed graph of calls starting from main (exists main : MS_Procedure; subroutines : P s.initialcontrolcmps = {main} and {main} setunion subroutines = s.controlcomponents and main notin subroutines and % Main is non-reentrant main.reentrant = FALSE and (forall call : call.c2 /= main) and cdgraph (main, subroutines) = {c1, c2 : MS_Procedure exists call : call.c1 = c2 and call.c2 = c2}) and % The system rests on one node # {n : Node (exists c : ControlComponent c in n in c.nodes) or (exists call : ControlConnector call in n in call.nodes)} = 1; end axiom 103

121 7.3.3 Distributed Processes % Distributed Processes Style global DP_DataStructure : P DataComponent; DP_Socket : P Port; DP_Process : P ControlComponent; DP_Circuit : P DataConnector; DP_ProcessCall : P Call; DP_ProcessSpawn : P Spawn; DP_System : P System; axiom forall s : s.iotype = io_inout; forall p : p.ports subseteq DP_Socket and p.locals subseteq DP_DataStructure and % There are no applets among the processes p.applet = FALSE and % Processes have no associated priorities. p.priority = 0; forall c : {c.p1, c.p2} subseteq DP_Socket and {c.c1, c.c2} subseteq DP_Process and % Bidirectional c.directionality = twoway; forall pc : % Call connects two processes {pc.c1, pc.c2} subseteq DP_Process and % Process calls cannot be queued pc.queuesize = 0; forall ps : % Spawn connects two processes {ps.c1, ps.c2} subseteq DP_Process and % Process spawn cannot be queued ps.queuesize = 0; forall s : s in MultiThreadedSystems and % The system rests on more than one node s in DistributedSystems and s.controlcomponents subseteq DP_Process and s.dataconnectors subseteq DP_Circuit and % DP systems have calls, spawns, returns, and possibly interrupts (& swapins), and terminates. s.calls subseteq DP_ProcessCall and s.spawns subseteq DP_ProcessSpawn and s.shareddata = {} and s.repositories = {} and s.response_time = unbounded and % DP systems have no backtracking. 104

122 s.backtracking = FALSE and % DP systems have no control units s.controlunit = {} and % All circuit sockets connect process sockets (forall c : exists p1, p2 : c.p1 in p1.ports and c.p2 in p2.ports) and % No two circuits connect the same pair of sockets (forall c1, c2 : c1 /= c2 => (not (c1.p1 = c2.p1 and c1.p2 = c2.p2)) and (not (c1.p1 = c2.p2 and c1.p2 = c2.p1))); end axiom Event-Based % Event-Based (implicit invocation) Style global EB_DataStructure : P DataComponent; EB_Procedure : P ControlComponent; EB_ProcedureCall : P Call; EB_ProcedureSpawn : P Spawn; EB_EventManager: P ControlComponent; EB_Event : P Event; EB_Action : P Action; EB_Trigger : P Trigger; EB_System : P System; axiom forall p : p.locals subseteq EB_DataStructure and p.ports = {} and % There are no applets among the procedures p.applet = FALSE and % Processes have no associated priorities. They are burried within the event manager and how it handles the triggering events. p.priority = 0; forall pc : % Call connects two procedures, or the event manager and a procedure, but no procedure can call the event manager {pc.c1, pc.c2} subseteq (EB_Procedure setunion EB_EventManager) and pc.c2 notin EB_EventManager and % Procedure calls cannot be queued pc.queuesize = 0; forall ps : % Spawn connects two procedures, or the event manager and a procedure, but no procedure can spawn the event manager {ps.c1, ps.c2} subseteq (EB_Procedure setunion EB_EventManager) and ps.c2 notin EB_EventManager and % Procedure spawns cannot be queued 105

123 ps.queuesize = 0; forall em : em.locals subseteq EB_DataStructure and % It is not an applet. em.applet = FALSE; forall t : % All triggers are composed of events and actions that belong to the system (exists e : EB_Event; a : ((e, a) = t and % The event manager is actually initiating all triggered actions (exists em : generates_basicactions(em, a) = TRUE))); forall s : s in MultiThreadedSystems and s.controlcomponents subseteq (EB_Procedure setunion EB_EventManager) and dom s.shareddata subseteq EB_DataStructure and % There can be one or more event managers # {em: EB_EventManager em in s.controlcomponents} >= 1 and % The event manager is always running. (forall em : EB_EventManager em in em in s.runningcontrolcmps) and % EB systems have calls, spawns, returns and possibly interrupts (& swapins), and terminates. s.calls subseteq EB_ProcedureCall and s.spawns subseteq EB_ProcedureSpawn and s.events subseteq EB_Event and s.actions subseteq EB_Action and s.triggers subseteq EB_Trigger and s.triggers /= {} and s.response_time = unbounded and % EB systems have no backtracking. s.backtracking = FALSE and % EB systems have their event managers as control units. s.controlunit = {em: EB_EventManager em in s.controlcomponents}; end axiom Blackboard % Blackboard Style global BB_DataStructure : P DataComponent; BB_Blackboard_Data : P DataComponent; BB_Ksource : P ControlComponent; BB_CtrlUnit : P ControlComponent; BB_Activation : P ControlConnector; BB_Terminate : P Terminate; BB_System : P System; axiom 106

124 forall bdata : bdata in BB_DataStructure; forall ksource : ksource.ports = {} and ksource.locals subseteq BB_DataStructure and % There are no applets among the knowledge sources. ksource.applet = FALSE and % No knowledge source is preemptive. ksource.preemptive = FALSE and % Knowledge sources have associated priorities. ksource.priority >= 0 and % Knowledge sources are non-reentrant. ksource.reentrant = FALSE; forall cunit : cunit.ports = {} and cunit.locals subseteq BB_DataStructure and % The control unit is not an applet. cunit.applet = FALSE and % It is not preemptive. cunit.preemptive = FALSE and % It is non-reentrant. cunit.reentrant = FALSE; forall a : % Activations are made from the control unit to the various knowledge sources only. a.c1 in BB_CtrlUnit and a.c2 in BB_Ksource and % Activations are either calls or spawns (a.type = call or a.type = spawn) and % Activations cannot be queued a.queuesize = 0; forall s : % There is exactly one blackboard repository # s.repositories = 1 and % There is exactly one control unit # {cunit : BB_CtrlUnit cunit in s.controlcomponents} = 1 and % There is at least one knowledge source # {ksource : BB_Ksource ksource in s.controlcomponents} >= 1 and % All knowledge sources have activations connecting to them (forall ksource : BB_Ksource ksource in (exists a : a.c2 = ksource)) and % All control connectors that happen within the system are activations, returns, and terminates. (s.calls setunion s.spawns) subseteq BB_Activation and s.terminates subseteq BB_Terminate and (forall cn : ControlConnector cn in cn.type = call or cn.type = spawn or cn.type = return or cn.type = terminate) and s.dataconnectors = {} and s.shareddata = {} and 107

125 s.triggers /= {} and % The control unit initiates all triggered actions. (forall t : Trigger t in (exists e : Event; a : ((e, a) = t and (exists cunit : generates_basicactions(cunit, a) = TRUE)))) and % BB systems have backtracking. s.backtracking = TRUE and % BB systems have a central control unit, the control unit. s.controlunit = {cunit : BB_CtrlUnit cunit in s.controlcomponents} and # {cunit: BB_CtrlUnit cunit in s.controlunit} = 1 and % There is only 1 initial control component, the control unit. # s.initialcontrolcmps = 1 and (exists cunit : BB_CtrlUnit; ksource : P s.initialcontrolcmps = {cunit} and % All control components are either knowledge sources or the control unit. {cunit} setunion ksource = s.controlcomponents and cunit notin ksource and % Nobody can call or spawn the control unit. not (exists call : call.c2 = cunit) and not (exists spawn : spawn.c2 = cunit) and % The system is a directed graph on a star configuration (dstar), where the center is the control unit, and the edges are system calls or spawns (activation calls or spawns to be more specific). dstar(cunit, ksource) = {c1, c2 : s.controlcomponents exists cn : s.controlconnectors (cn in s.calls or cn in cn.c1 = c1 and cn.c2 = c2}) and % All blackboard data is visible to the control unit via the repository, all control components that can see that data belong to the system (i.e., they are either any of its knowledge sources or its control unit), and all control components that belong to the system can see the data. (forall r : (forall bbdata : P DataComponent bbdata subseteq (exists cset : P ControlComponent; cunit : bbdata = r.data and cset = r.accessingcmps and cunit in cset and cset = s.controlcomponents))); end axiom Database Centric % Database Centric Style global DB_DataStructure : P DataComponent; DB_Data : P DataComponent; 108

126 DB_UsingComponent : P ControlComponent; DB_SupportComponent : P ControlComponent; DB_DBMS : P ControlComponent; DB_Request : P Call; DB_Check : P Spawn; DB_System : P System; axiom forall data : data in DB_DataStructure; forall u : u.locals subseteq DB_DataStructure; forall s : s.locals subseteq DB_DataStructure; forall d : d.locals subseteq DB_DataStructure and % The dbms is reentrant. d.reentrant = TRUE; forall r : % Requests are made from the using and support control components to the DBMS. r.c1 in (DB_UsingComponent setunion DB_SupportComponent) and r.c2 in DB_DBMS; forall c : % Checks are made from the DBMS to the support control components. c.c1 in DB_DBMS and c.c2 in DB_SupportComponent; forall s : s in MultiThreadedSystems and % There are one or more database repositories # s.repositories >= 1 and % There is exactly one dbms # {dbms : DB_DBMS dbms in s.controlcomponents} = 1 and % There is at least one using control component # {u_cmp : DB_UsingComponent u_cmp in s.controlcomponents} >= 1 and % All using control components have requests associated to them (forall u_cmp : DB_UsingComponent u_cmp in (exists r : r.c1 = u_cmp)) and % All supporting control components have checks connecting to them (forall s_cmp : DB_SupportComponent s_cmp in (exists c : c.c2 = s_cmp)) and % All control connectors that happen within the system are either checks, requests, their returns, and possibly interrupts (& swap-ins), and terminates. (s.calls setunion s.spawns) subseteq (DB_Check setunion DB_Request) and % There are no applets among the control components. (forall c : ControlComponent c in c.applet = FALSE) and s.shareddata = {} and s.triggers /= {} and % The DBMS initiates all triggered actions. (forall t : Trigger t in 109

127 (exists e : Event; a : ((e, a) = t and (exists dbms : generates_basicactions(dbms, a) = TRUE)))) and s.response_time = bounded and % DB systems have backtracking for rollback, maintaining data integrity and conscistency. s.backtracking = TRUE and % DB systems have a central control unit, the dbms. s.controlunit = {dbms : DB_DBMS dbms in s.controlcomponents} and # {dbms : DB_DBMS dbms in s.controlunit} = 1 and (exists dbms : DB_DBMS; u_cmps : P DB_UsingComponent; s_cmps : P % The DBMS is always running. dbms in s.runningcontrolcmps and % All control components are either the dbms, using components, or support components. {dbms} setunion u_cmps setunion s_cmps = s.controlcomponents and dbms notin (u_cmps setunion s_cmps) and % The system is an undirected graph on a star configuration (ustar), where the center is the dbms, and the edges are system calls or spawns (requestes or checks). (exists cmps : P ControlComponent (cmps subseteq ustar(cmps) = {c1, c2 : s.controlcomponents exists cn : s.controlconnectors (cn in s.calls or cn in ((cn.c1 = c1 and cn.c2 = c2) or (cn.c1 = c2 and cn.c2 = c1))})) and % All database data is visible to the dbms via the repository, all control components that can see that data belong to the system. (forall r : (forall dbdata : P DataComponent dbdata subseteq (exists cset : P ControlComponent; dbms : dbdata = r.data and cset = r.accessingcmps and r.persistent = TRUE and dbms in cset and cset subseteq s.controlcomponents))); end axiom Rule-Based % Rule-Based Style global RB_DataStructure : P DataComponent; RB_Fact : P DataComponent; RB_Rule : P ControlComponent; 110

128 RB_Interpreter : P ControlComponent; RB_Fire : P ControlConnector; RB_Terminate : P Terminate; RB_System : P System; axiom forall f : f in RB_DataStructure; forall r : r.ports = {} and r.locals = {} and % Rules are not applets. r.applet = FALSE and % Rules are non-preemptive. r.preemptive = FALSE and % Rules have associated priorities. r.priority >= 0 and % Rules are non-reentrant. r.reentrant = FALSE; forall i : i.ports = {} and i.locals = {} and % Interpreters are not applets. i.applet = FALSE and % Interpreters are non-preemptive. i.preemptive = FALSE and % Interpreters are non-reentrant. i.reentrant = FALSE; forall f : % The fireing of rules is made by the interpreter. f.c1 in RB_Interpreter and f.c2 in RB_Rule and % Rules fireing can be either calls or spawns. (f.type = call or f.type = spawn); forall t : % The termination of rules is made by the interpreter. t.c1 in RB_Interpreter and t.c2 in RB_Rule; forall s : % There is a single repository, the working memory. # s.repositories = 1 and % There is exactly one interpreter # {i : RB_Interpreter i in s.controlcomponents} = 1 and % There is at least one rule # {r : RB_Rule r in s.controlcomponents} >= 1 and % All rules have some fireing mechanism associated to them. (forall rule : RB_Rule rule in (exists f : f.c1 = rule)) and s.dataconnectors = {} and % All control connectors that happen within the system are either rules fireing, returning or terminating. (s.calls setunion s.spawns) subseteq RB_Fire and 111

129 s.terminates subseteq RB_Terminate and (forall cn : ControlConnector cn in cn.type = call or cn.type = spawn or cn.type = return or cn.type = terminate) and s.shareddata = {} and s.triggers /= {} and % The interpreter initiates all triggered actions. (forall t : Trigger t in (exists e : Event; a : ((e, a) = t and (exists interp : generates_basicactions(interp, a) = TRUE)))) and % RB systems have backtracking to support for backward chaining. s.backtracking = TRUE and % RB systems have a central control unit, the interpreter. s.controlunit = {i : RB_Interpreter i in s.controlcomponents} and # {i : RB_Interpreter i in s.controlunit} = 1 and % There is only 1 initial control component, the interpreter. # s.initialcontrolcmps = 1 and (exists interp : RB_Interpreter; rules : P s.initialcontrolcmps = {interp} and % All control components are either the interpreter or rules. {interp} setunion rules = s.controlcomponents and interp notin rules and % The system is a directed graph on a star configuration (dstar), where the center is the interpreter, and the edges are system calls or spawns (fires). dstar(interp, rules) = {c1, c2 : s.controlcomponents exists cn : s.controlconnectors (cn in s.calls or cn in cn.c1 = c1 and cn.c2 = c2}) and % All working memory data is visible to the interpreter via the repository, all control components that can see that data belong to the system, and all control components that belong to the system can see the data. (forall r : (forall fact : P DataComponent fact subseteq (exists cset : P ControlComponent; interp : fact = r.data and cset = r.accessingcmps and interp in cset and cset = s.controlcomponents))); end axiom Logic-Programming % Logic-Programming Style global LP_DataStructure : P DataComponent; 112

130 LP_UnificationValue : P DataComponent; LP_Rule : P ControlComponent; LP_Interpreter : P ControlComponent; LP_Invoke : P ControlConnector; LP_Terminate : P Terminate; LP_System : P System; axiom forall u : u in LP_DataStructure; forall r : r.ports = {} and r.locals = {} and % Rules are not applets. r.applet = FALSE and % Rules are non-preemptive. r.preemptive = FALSE and % Rules have associated priorities. r.priority >= 0 and % Rules are non-reentrant. r.reentrant = FALSE; forall i : i.ports = {} and i.locals = {} and % Interpreters are not applets. i.applet = FALSE and % Interpreters are non-preemptive. i.preemptive = FALSE and % Interpreters are non-reentrant. i.reentrant = FALSE; forall i : % The invocation of rules is made by the interpreter. i.c1 in LP_Interpreter and i.c2 in LP_Rule and % Rules invocation can be either calls or spawns. (i.type = call or i.type = spawn); forall t : % The termination of rules is made by the interpreter. t.c1 in LP_Interpreter and t.c2 in LP_Rule; forall s : % There is a single repository. # s.repositories = 1 and % There is exactly one interpreter # {i : LP_Interpreter i in s.controlcomponents} = 1 and % There is at least one rule # {r : LP_Rule r in s.controlcomponents} >= 1 and % All rules have some invocation mechanism associated to them. (forall rule : LP_Rule rule in (exists i : i.c1 = rule)) and s.dataconnectors = {} and % All control connectors that happen within the system are either rules invoca- 113

131 tions, returns, or terminations. (s.calls setunion s.spawns) subseteq LP_Invoke and s.terminates subseteq LP_Terminate and (forall cn : ControlConnector cn in cn.type = call or cn.type = spawn or cn.type = return or cn.type = terminate) and s.shareddata = {} and s.triggers /= {} and % The interpreter initiates all triggered actions. (forall t : Trigger t in (exists e : Event; a : ((e, a) = t and (exists interp : generates_basicactions(interp, a) = TRUE)))) and % LP systems have backtracking to support for backward chaining. s.backtracking = TRUE and % LP systems have a central control unit, the interpreter. s.controlunit = {i : LP_Interpreter i in s.controlcomponents} and # {i : LP_Interpreter i in s.controlunit} = 1 and % There is only 1 initial control component, the interpreter. # s.initialcontrolcmps = 1 and (exists interp : LP_Interpreter; rules : P s.initialcontrolcmps = {interp} and % All control components are either the interpreter or rules. {interp} setunion rules = s.controlcomponents and interp notin rules and % The system is a directed graph on a star configuration (dstar), where the center is the interpreter, and the edges are system calls or spawns (invocations). dstar(interp, rules) = {c1, c2 : s.controlcomponents exists cn : s.controlconnectors (cn in s.calls or cn in cn.c1 = c1 and cn.c2 = c2}) and % All unification values are visible to the interpreter via the repository, all control components that can see these values belong to the system, and all control components that belong to the system can see the values. (forall r : (forall unifval : P DataComponent unifval subseteq (exists cset : P ControlComponent; interp : unifval = r.data and cset = r.accessingcmps and interp in cset and cset = s.controlcomponents))); end axiom 114

132 7.3.9 Real Time % Real Time Style global RT_DataStructure : P DataComponent; RT_Task : P ControlComponent; RT_Scheduler : P ControlComponent; RT_Call : P Call; RT_Spawn : P Spawn; RT_Interrupt : P Interrupt; RT_Terminate : P Terminate; RT_System : P System; axiom forall t : t.locals subseteq RT_DataStructure and % Tasks are not applets. t.applet = FALSE and % Tasks are preemptive. t.preemptive = TRUE and % Tasks have associated priorities. t.priority >= 0 and % Tasks are non-reentrant. t.reentrant = FALSE; forall s : s.locals subseteq RT_DataStructure and % Schedulers are not applets. s.applet = FALSE and % Schedulers are non-preemptive. s.preemptive = FALSE and % Schedulers are non-reentrant. s.reentrant = FALSE; forall c : % The calls to tasks can be made by other tasks and/or the scheduler. (c.c1 in RT_Scheduler or c.c1 in RT_Task) and c.c2 in RT_Task; forall s : % The spawns of tasks can be made by other tasks and/or the scheduler. (s.c1 in RT_Scheduler or s.c1 in RT_Task) and s.c2 in RT_Task; forall i : % The interrupts of tasks can be made by the scheduler only. i.c1 in RT_Scheduler and i.c2 in RT_Task; forall t : % The termination of tasks is made by the scheduler. t.c1 in RT_Scheduler and t.c2 in RT_Task; forall s : s in MultiThreadedSystems and % There is exactly one scheduler 115

133 # {sc : RT_Scheduler sc in s.controlcomponents} = 1 and % There is at least one task # {t : RT_Task t in s.controlcomponents} >= 1 and dom s.shareddata subseteq RT_DataStructure and % All tasks have some invocation mechanism associated to them. (forall task : RT_Task task in ((exists c : c.c1 = task) or (exists sp : sp.c1 = task))) and % All control connectors that happen within the system are either tasks invocations, their returns, interruptions, their swap-ins or terminations. s.calls subseteq RT_Call and s.spawns subseteq RT_Spawn and s.interrupts subseteq RT_Interrupt and s.terminates subseteq RT_Terminate and s.triggers /= {} and % The scheduler initiates all triggered actions. (forall t : Trigger t in (exists e : Event; a : ((e, a) = t and (exists sc : generates_basicactions(sc, a) = TRUE)))) and s.response_time = predictable and % RT systems have no backtracking. s.backtracking = FALSE and % RT systems have a central control unit, the scheduler. s.controlunit = {sc : RT_Scheduler sc in s.controlcomponents} and # {sc : RT_Scheduler sc in s.controlunit} = 1 and (exists sched : RT_Scheduler; tasks : P % All control components are either the scheduler or tasks. {sched} setunion tasks = s.controlcomponents and sched notin tasks); end axiom Closed Loop Feedback Control % Closed Loop Feedback Control Style global CL_DataStructure : P DataComponent; CL_ControlledVar : P DataComponent; CL_ManipulatedVar : P DataComponent; CL_Process : P ControlComponent; CL_Controller : P ControlComponent; CL_System : P System; axiom forall v : DataComponent (v in CL_ControlledVar or v in v in CL_DataStructure; forall p : p.locals subseteq CL_DataStructure and 116

134 % There are no applets among the processes. p.applet = FALSE and % The processes are preemptive. p.preemptive = TRUE and % Processes are non-reentrant. p.reentrant = FALSE; forall c : c.locals subseteq CL_DataStructure and % There are no applets among the controllers. c.applet = FALSE and % Controllers are non-reentrant. c.reentrant = FALSE; forall s : % There are at least one controlled variable, one manipulated variable, one processing component, and one controlling component. (exists datacomp : P datacomp subseteq CL_DataStructure and # {cv : CL_ControlledVar cv in datacomp} >= 1 and # {mv : CL_ManipulatedVar mv in datacomp} >= 1) and # {p : CL_Process p in s.controlcomponents} >= 1 and # {c : CL_Controller c in s.controlcomponents} >= 1 and % All control components are either processing or controlling components. (exists proc : P CL_Process; contr : P proc setunion contr = s.controlcomponents) and % Controlled variables are explicitly shared data. Other data may also be shared. CL_ControlledVar subseteq dom s.shareddata and dom s.shareddata subseteq CL_DataStructure and % There is a cycle involving control and/or data connectors (uring (s.controlcomponents) = {c1, c2 : s.controlcomponents exists cn : s.controlconnectors (cn in s.calls or cn in cn.c1 = c1 and cn.c2 = c2} or uring (s.controlcomponents) = {c1, c2 : s.controlcomponents exists dcn : dcn.c1 = c1 and dcn.c2 = c2}) and s.triggers /= {} and % CLFC systems have no backtracking. s.backtracking = FALSE and % CLFC systems have control unit(s), their controllers. s.controlunit = {c: CL_Controller c in s.controlcomponents}; end axiom Internet Distributed Entities % Internet Distributed Entities Style global ID_DataStructure : P DataComponent; ID_ServerData : P DataComponent; 117

135 ID_ClientData : P DataComponent; ID_Socket : P Port; ID_WebServer : P ControlComponent; ID_ServerProcess : P ControlComponent; ID_WebBrowser : P ControlComponent; ID_Applet : P ControlComponent; ID_CORBAIIOPdata : P DataConnector; ID_RMIdata : P DataConnector; ID_HTTP : P DataConnector; ID_Circuit : P DataConnector; ID_CORBAIIOPcontrol : P ControlConnector; ID_RMIcontrol : P ControlConnector; ID_RPC : P ControlConnector; ID_System : P System; axiom forall sd : sd in ID_DataStructure; forall cd : cd in ID_DataStructure; forall s : s.iotype = io_inout; forall ws : ws.ports subseteq ID_Socket and ws.locals subseteq ID_ServerData and % There are no applets among the web servers. ws.applet = FALSE and % The web server is reentrant. ws.reentrant = TRUE; forall sp : sp.ports subseteq ID_Socket and sp.locals subseteq ID_ServerData; forall wb : wb.ports subseteq ID_Socket and wb.locals subseteq ID_ClientData and % There are no applets among the web browsers. wb.applet = FALSE; forall a : a.ports subseteq ID_Socket and a.locals subseteq ID_ClientData and % They are applets. a.applet = TRUE; forall dcn : DataConnector (dcn in ID_CORBAIIOPdata or dcn in ID_RMIdata or dcn in ID_HTTP or dcn in {dcn.p1, dcn.p2} subseteq DP_Socket and dcn.c1 in (ID_WebBrowser setunion ID_Applet) and dcn.c2 in (ID_WebServer setunion ID_ServerProcess) and % Bidirectional dcn.directionality = twoway; forall ccn : ControlConnector (ccn in ID_CORBAIIOPcontrol or ccn in ID_RMIcontrol or ccn in ccn.c1 in (ID_WebBrowser setunion ID_Applet) and 118

136 ccn.c2 in (ID_WebServer setunion ID_ServerProcess) and (ccn.type = call or ccn.type = spawn); forall s : s in MultiThreadedSystems and % The system rests on more than one node s in DistributedSystems and s.controlcomponents subseteq (ID_WebServer setunion ID_WebBrowser setunion ID_Applet setunion ID_ServerProcess) and s.dataconnectors subseteq (ID_CORBAIIOPdata setunion ID_RMIdata setunion ID_HTTP setunion ID_Circuit) and s.controlconnectors subseteq (ID_CORBAIIOPcontrol setunion ID_RMIcontrol setunion ID_RPC) and % All data connectors sockets connect control components sockets (forall cn : exists cm1, cm2 : cn.p1 in cm1.ports and cn.p2 in cm2.ports) and % No two data connectors connect the same pair of sockets (forall c1, c2 : c1 /= c2 => (not (c1.p1 = c2.p1 and c1.p2 = c2.p2)) and (not (c1.p1 = c2.p2 and c1.p2 = c2.p1))) and % There is exactly one web server. # {ws: ID_WebServer ws in s.controlcomponents} = 1 and % There are at least one web browser and one applet. # {wb: ID_WebBrowser wb in s.controlcomponents} >= 1 and # {a: ID_Applet a in s.controlcomponents} >= 1 and % Data connections are done via HTTP and at most one of: CORBA IIOP, RMI and socket libraries. # {dcn: ID_HTTP dcn in s.dataconnectors} >= 1 and (# {dcn: ID_CORBAIIOPdata dcn in s.dataconnectors} >= 1) <=> (# {dc: ID_RMIdata dc in s.dataconnectors} = 0 and # {dc: ID_Circuit dc in s.dataconnectors} = 0) and (# {dcn: ID_RMIdata dcn in s.dataconnectors} >= 1) <=> (# {dc: ID_CORBAIIOPdata dc in s.dataconnectors} = 0 and # {dc: ID_Circuit dc in s.dataconnectors} = 0) and (# {dcn: ID_Circuit dcn in s.dataconnectors} >= 1) <=> (# {dc: ID_CORBAIIOPdata dc in s.dataconnectors} = 0 and # {dc: ID_RMIdata dc in s.dataconnectors} = 0) and % Control connections are done via at most one of: CORBA IIOP, RMI and socket libraries. (# {ccn: ID_CORBAIIOPcontrol ccn in s.controlconnectors} >= 1) <=> (# {cc: ID_RMIcontrol cc in s.controlconnectors} = 0 and # {cc: ID_RPC cc in s.controlconnectors} = 0) and (# {ccn: ID_RMIcontrol ccn in s.controlconnectors} >= 1) <=> (# {cc: ID_CORBAIIOPcontrol cc in s.controlconnectors} = 0 and # {cc: ID_RPC cc in s.controlconnectors} = 0) and (# {ccn: ID_RPC ccn in s.controlconnectors} >= 1) <=> (# {cc: ID_CORBAIIOPcontrol cc in s.controlconnectors} = 0 and # {cc: ID_RMIcontrol cc in s.controlconnectors} = 0) and s.triggers /= {} and 119

137 tory r in s.repositories and dset = r.data and cset = d in (exists ws : ID_WebServer ws in sd.nodes subseteq ws.nodes)) and % The client data reside on the web browsers nodes. (forall cd : ID_ClientData cd in (dom s.shareddata setunion {d : DataComponent (exists ccmp : ControlComponent ccmp in d in ccmp.locals)} setunion {d : DataComponent (exists dset : P DataComponent; cset : P ControlComponent; r : Repository % System s initial^components are at least the web server and browser. # s.initialcontrolcmps >= 2 and (exists ws : ID_WebServer; wb : {ws, wb} subseteq s.initialcontrolcmps and ws /= wb) and % The server data resides on the web server node. (forall sd : ID_ServerData sd in (dom s.shareddata setunion {d : DataComponent (exists ccmp : ControlComponent ccmp in d in ccmp.locals)} setunion {d : DataComponent (exists dset : P DataComponent; cset : P ControlComponent; r : Reposi- r in s.repositories and dset = r.data and cset = d in cd.nodes subseteq {n : Node (exists wb : ID_WebBrowser wb in n in wb.nodes)}) and % Server processes run on the web server node. (forall sp : ID_ServerProcess sp in (exists ws : ID_WebServer ws in sp.nodes subseteq ws.nodes)) and % Applets run on the web browsers nodes. (forall a : ID_Applet a in a.nodes subseteq {n : Node (exists wb : ID_WebBrowser wb in n in wb.nodes)}) and % ID systems have call and/or spawn and/or data connector layers. # {layer : Layer layer in s.call_layers or layer in s.spawn_layers or layer in s.dataconnector_layers} >= 1 and s.response_time = unbounded and % ID systems have on the fly garbage collection. on_the_fly_garbage_collection in s.reconfiguration and % ID systems have no control units 120

138 s.controlunit = {}; end axiom 7.4 Modeling Composition and Mismatches Detection Another important addition done by this work is the fact that we provide an operation that explicitly checks for each and every mismatch we have addressed (section 6.0). 1 The model for such operation can be found below. 2 % Operation to check for potential mismatches global % Inputs include a set of (sub)systems and new bridging connectors. Output is the set of potential mismatches to be expected. check_for_mismatches : (P System & P Call & P Spawn & P SharedData & P Repository & P DataConnector & P Trigger & P (P ControlComponent & Node)) +-> P Mismatch; axiom forall subsystems : P System; bridgingcalls : P Call; bridgingspawns : P Spawn; extendedshareddata : P SharedData; extendedrepositories : P Repository; bridgingdataconnectors : P DataConnector; bridgingtriggers : P Trigger; bridgingsharedmachines : P (P ControlComponent & Node); mismatches : P check_for_mismatches(subsystems, bridgingcalls, bridgingspawns, extendedshareddata, extendedrepositories, bridgingdataconnectors, bridgingtriggers, bridgingsharedmachines) = mismatches <=> % Divide bridging triggers to simplify reasoning for each mismatch. (exists bridgtriggcalls : P Call; bridgtriggspawns : P Spawn; bridgtriggdataxfer : P bridgtriggcalls = gettriggeredcalls(ran bridgingtriggers) and bridgtriggspawns = gettriggeredspawns(ran bridgingtriggers) and % % Check for Mismatch 1: Two concurrent threads share data, with potential synchronization problems. 1. This covers all mismatches we identified. As new mismatches are identified they would have to be manually added here. 2. This Z snippet makes use of schemas and relations defined elsewhaere. For a complete specification of those, please refer to appendix C. 121

139 % Precondition: Composing parts are to run concurrently (regardless on whether they were originally concurrent or not), and do share some data. % Problem: Potential synchronization problems for concurrent threads while sharing data. % New parts share some data (i.e., the bridging connector is shared data). (extendedshareddata /= {} and % Composing parts may run concurrently ((bridgingspawns setunion bridgtriggspawns) /= {} or (exists s : System s in s in MultiThreadedSystems))) <=> M1 in mismatches and % % Check for Mismatch 2: A layering constraint is violated. % Precondition: Any of the composing subsystems originally included layering constraints either on control or data connectors, and composition is achieved by extending exactly that kind of connector to such a subsystem. % Problem: Bridging connector may ignore these constraints, thus violating them. % There are bridging (triggered) calls, and at least one of the subsystems involved originally had layering constraints on calls. (((bridgingcalls setunion bridgtriggcalls) /= {} and (exists s : System s in s.call_layers /= {} and (exists bc : Call bc in (bridgingcalls setunion bc.c1 in s.controlcomponents or bc.c2 in s.controlcomponents))) or % There are bridging (triggered) spawns, and at least one of the subsystems involved originally had layering constraints on spawns. ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists s : System s in s.spawn_layers /= {} and (exists bs : Spawn bs in (bridgingspawns setunion bs.c1 in s.controlcomponents or bs.c2 in s.controlcomponents))) or % There are bridging data connectors, and at least one of the subsystems involved originally had layering constraints with respect to data connectors. (bridgingdataconnectors /= {} and (exists s : System s in s.dataconnector_layers /= {} and (exists bd : DataConnector bd in bd.c1 in s.controlcomponents or bd.c2 in s.controlcomponents)))) <=> M2 in mismatches and % % Check for Mismatch 3: Different sets of recognized events are used by two subsystems that permit triggers. % Precondition: At least 2 of the composing subsystems permit triggers but have different sets of possible triggering events. 122

140 <=> % Problem: A trigger may not be recognizable by some subsystem that should. (exists s1, s2 : System s1 in subsystems and s2 in % Both subsystems have triggers s1.triggers /= {} and s2.triggers /= {} and % Their set of triggering events is different dom s1.triggers /= dom s2.triggers) <=> M3 in mismatches and % % Check for Mismatch 4: A (triggered) spawn is made into or out of a subsystem which originally forbade them. % Precondition: Subsystems are being composed via (triggered) spawns, and at least one of the composing subsystems does not support the dynamic creation of threads. % Problem: A (triggered) spawn is made into or out of a subsystem that originally forbade them. May cause synchronization problems, as well as resources contention. % There is a bridging (triggered) spawn into or out of a subsystem that forbade them. ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists sp : Spawn sp in (bridgingspawns setunion (exists s : System s in (sp.c1 in s.controlcomponents or sp.c2 in s.controlcomponents) and s.spawns = {}))) <=> M4 in mismatches and % % Check for Mismatch 5: An unrecognized triggering event is used. % Precondition: A trigger is used as a bridging connector, but its generating event can never occur. % Problem: The trigger will not cause the expected behavior, it will never fire the related actions. % There are bridging triggers, but at least one of them has a non-existent triggering event. (bridgingtriggers /= {} and (exists t : Trigger; e : Event; a : Action t in t = (e, a) and % The event cannot occur in any of the subsystems. (forall s : System s in check_basicevents(e, s.controltransfers, s.datatransfers) = FALSE))) M5 in mismatches and % % Check for Mismatch 6: A trigger refers to subsystems which originally forbade triggering. % Precondition: All of the composing subsystems forbade triggering, and some of the composition is to be achieved via some bridging triggers. % Problem: The trigger will go by ignored, there is no underlying mechanism available to handle the triggering. % There are bridging triggers, and none of the original parts supported trigger- 123

141 ing. (bridgingtriggers /= {} and (forall s : System s in s.triggers = {})) <=> M6 in mismatches and % % Check for Mismatch 7: A data connector is made into a subsystem which originally forbade them. % Precondition: Some of the composition is to be achieved via bridging data connectors, and at least one of the composing subsystems did not originally support data connectors. % Problem: Unclear on how data is to be handled for sending or receiving. % There are bridging data connectors, and at least one of them refers to a subsystem which originally forbade them. (bridgingdataconnectors /= {} and (exists dc : DataConnector dc in (exists s : System s in (dc.c1 in s.controlcomponents or dc.c2 in s.controlcomponents) and s.dataconnectors = {}))) <=> M7 in mismatches and % % Check for Mismatch 8: A shared data relationship refers to a subsystem which originally forbade them. % Precondition: Some of the composition is to be achieved via bridging shared data, and one of the composing subsystems had no shared data support. % Problem: May cause synchronization problems. % There are bridging shared data, and at least one of the parts involved did not support that. (extendedshareddata /= {} and (exists cc : ControlComponent {cc} in ran (exists s : System s in cc in s.controlcomponents and s.shareddata = {}))) <=> M8 in mismatches and % % Check for Mismatch 9: A (triggered) spawn is made into or out of a subsystem which is not concurrent. % Precondition: Some of the composition is to be achieved via bridging (triggered) spawns, and one of the composing subsystems does not support the execution of concurrent threads. % Problem: May cause synchronization problems, as well as resources contention. % There are bridging (triggered) spawns, and at least one of the parts involved originally had no concurrent threads. ((bridgingspawns /= {} or bridgtriggspawns /= {}) and (exists s : System s in # (getmaxthreads(s)) = 1 and (exists bs : Spawn bs in (bridgingspawns setunion bs.c1 in s.controlcomponents or 124

142 bs.c2 in s.controlcomponents))) <=> M9 in mismatches and % % Check for Mismatch 10: A remote connector is extended into or out of a non-distributed subsystem (i.e. a subsystem originally confined to a single node). % Precondition: One of the subsystems was originally confined to a single node, and the resulting composed system is distributed. % Problem: The subsystem(s) originally non-distributed cannot handle delays and/or errors occurred due to some distributed communication event. % There are bridging (triggered) calls spanning more than one node, and at least one of the subsystems involved originally was confined to a single node. (((bridgingcalls setunion bridgtriggcalls) /= {} and (exists s : System s in # s.nodes = 1 and (exists bc : Call bc in (bridgingcalls setunion (bc.c1 in s.controlcomponents or bc.c2 in s.controlcomponents) and bc.c1.nodes /= bc.c2.nodes))) or % There are bridging (triggered) spawns spanning more than one node, and at least one of the subsystems involved originally was confined to a single node. ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists s : System s in # s.nodes = 1 and (exists bs : Spawn bs in (bridgingspawns setunion (bs.c1 in s.controlcomponents or bs.c2 in s.controlcomponents) and bs.c1.nodes /= bs.c2.nodes))) or % There are bridging data connectors spanning more than one node, and at least one of the subsystems involved originally was confined to a single node. (bridgingdataconnectors /= {} and (exists s : System s in # s.nodes = 1 and (exists bd : DataConnector bd in (bd.c1 in s.controlcomponents or bd.c2 in s.controlcomponents) and bd.c1.nodes /= bd.c2.nodes))) or % There are bridging shared data between components that reside in different nodes, and at least one of the subsystems involved did not support distribution. (extendedshareddata /= {} and (exists s : System s in # s.nodes = 1 and (exists d : DataComponent; c1, c2 : ControlComponent; cset : P Control- Component ((d, cset) in extendedshareddata and c1 in cset and c2 in (c1 in s.controlcomponents or c2 in s.controlcomponents) and 125

143 c1.nodes /= c2.nodes)))) <=> M10 in mismatches and % % Check for Mismatch 11: A node resource is overused. % Precondition: Resources required are greater than the ones available at a given node. % Problem: Resource overusage such as memory and disk space. % The resources on one or more of the new system s nodes are not enough to support all parts that reside on it. (exists n: Node (exists s : System s in n in not (addresources ({r : Resources % Resources required by all its subsystems data components. (forall s : System s in subsystems and n in (exists d : DataComponent; c : ControlComponent; cset : P ControlComponent; dset : P DataComponent; rep : Repository (n in d.nodes and c in s.controlcomponents and cset subseteq (d in c.locals or (d, cset) in s.shareddata or (d in dset and rep in s.repositories and dset = rep.data and cset = rep.accessingcmps)) and r = d.resources))} setunion {r : Resources % Resources required by all its control components. (forall s : System s in subsystems and n in (exists c : ControlComponent n in c.nodes and c in r = c.resources))}) ResourceCompatible n.resources)) <=> M11 in mismatches and % % Check for Mismatch 12: There is a non-deterministic set of actions that could be caused by a trigger. % Precondition: At least 2 of the composing subsystems have triggering, and there is at least one event that has more than one trigger associated with it, one from each of the composing subsystems (i.e, each of the composing subsystems had its own set of actions that should occur once the event happens). % Problem: It is not clear which set of actions should actually occur based on the composition, and if all it is not clear what the ordering should be. (exists s1, s2 : System s1 in subsystems and s2 in s1.triggers /= {} and s2.triggers /= {} and (exists e : e in dom s1.triggers and 126

144 e in dom s2.triggers)) <=> M12 in mismatches and % % Check for Mismatch 13: Data connectors connecting control components that are not always active may lead into deadlock. % Precondition: We have a blocking bridging data connector and the receiving control component may be inactive when data is sent through the data connector, and it may never become active (again). % Problem: Possibility of deadlock on the control component sending the data. (bridgingdataconnectors /= {} and (exists bd : DataConnector; s : System s in subsystems and bd in (((bd.directionality = forward or bd.directionality = twoway) and bd.p1.blocking = TRUE) or ((bd.directionality = reverse or bd.directionality = twoway) and bd.p2.blocking = TRUE)) and s.initialcontrolcmps /= s.controlcomponents and (bd.c1 in s.controlcomponents or bd.c2 in s.controlcomponents))) <=> M13 in mismatches and % % Check for Mismatch 14: Data connectors connecting control components that are not always active. % Precondition: We have a non-blocking and non-buffered bridging data connector and the receiving control component becomes active after the data was sent and lost. % Problem: Possibility of loss of data. (bridgingdataconnectors /= {} and (exists bd : DataConnector; s : System s in subsystems and bd in (((bd.directionality = forward or bd.directionality = twoway) and bd.p1.blocking = FALSE) or ((bd.directionality = reverse or bd.directionality = twoway) and bd.p2.blocking = FALSE)) and bd.buffersize = 0 and s.initialcontrolcmps /= s.controlcomponents and (bd.c1 in s.controlcomponents or bd.c2 in s.controlcomponents))) <=> M14 in mismatches and % % Check for Mismatch 15: Erroneous assumption of single-thread. % Precondition: A control component c1 in a single-threaded subsystem calls a control component c2 in a multi-threaded dynamic subsystem. The problem may arise by c2 spawning c3, terminating and returning control to c1, whose subsystem assumes it is running alone. OR there is a call 127

145 from a multi-threaded to a single-threaded subsystem. OR there is a spawn from a (single or) multi-threaded subsystem to a single-threaded one, the spawnee assumes it is running alone. % Problem: Synchronization problems on accessing shared data, and/or resource contention. (((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; s1, s2 : System c in (bridgingcalls setunion bridgtriggcalls) and s1 in subsystems and s2 in # (getmaxthreads(s1)) = 1 and # (getmaxthreads(s2)) > 1 and c.c1 in s1.controlcomponents and c.c2 in s2.controlcomponents)) or (((bridgingspawns setunion bridgtriggspawns) /= {} and (exists sp : Spawn; s1, s2 : System sp in (bridgingspawns setunion bridgtriggspawns) and s1 in subsystems and s2 in # (getmaxthreads(s1)) > 1 and # (getmaxthreads(s2)) = 1 and sp.c1 in s1.controlcomponents and sp.c2 in s2.controlcomponents)))) <=> M15 in mismatches and % % Check for Mismatch 16: (Triggered) Call to a cyclic (non-terminating) subsystem/control component. % Precondition: There is a bridging (triggered) call to a cyclic (and hence nonterminating) subsystem / control component. % Problem: Control will never be returned to the caller. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; cm : ControlComponent c in (bridgingcalls setunion c.c2 = cm and (cm.response_time = cyclic or (exists s : System s in cm in s.controlcomponents and s.response_time = cyclic)))) <=> M16 in mismatches and % % Check for Mismatch 17: Erroneous assumption of same underlying platform. % Precondition: During composition we would like to have some subsystems running on a shared machine, but they actually assume different underlying platforms. % Problem: Cannot force fit parts to a given platform. (bridgingsharedmachines /= {} and (exists bm : (P ControlComponent & Node) bm in (exists c : ControlComponent; cset : P ControlComponent; n : Node c in cset and 128

146 (cset, n) = (forall nd : Node nd in not (nd.platform PlatformCompatible n.platform))))) <=> M17 in mismatches and % % Check for Mismatch 18: (Triggered) Call to a private method. % Precondition: There is a bridging (triggered) call to a private method. % Problem: Method not accessible to the caller. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; m : Method; o : Object c in (bridgingcalls setunion c.c2 = m and m.name in o.private_methods)) <=> M18 in mismatches and % % Check for Mismatch 19: (Triggered) Spawn to a private method. % Precondition: There is a bridging (triggered) spawn to a private method. % Problem: Method not accessible to the spawner. ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists s : Spawn; m : Method; o : Object s in (bridgingspawns setunion s.c2 = m and m.name in o.private_methods)) <=> M19 in mismatches and % % Check for Mismatch 20: Sharing private data. % Precondition: Composition is also to be achieved via some bridging shared data, but that data is private within its original subsystem. % Problem: Data not accessible to all of the sharing entities being composed. (extendedshareddata /= {} and (exists o : Object; d : DataComponent; cset : P ControlComponent (d, cset) in d in o.locals)) <=> M20 in mismatches and % % Check for Mismatch 21: More than one central control unit exists. % Precondition: More than one central control unit exists as a result of composition. % Problem: All central control units assume they have absolute control on execution sequencing. (exists s1, s2 : System s1 in subsystems and s2 in # {s1.controlunit} = 1 and # {s2.controlunit} = 1) <=> M21 in mismatches and % % Check for Mismatch 22: Sharing data with a reentrant component. % Precondition: Composition is to be achieved via some bridging shared data, and at least one of the components to share it is reentrant. % Problem: Sharing of data may occur with the incorrect invocation of a com- 129

147 ponent. (extendedshareddata /= {} and (exists d : DataComponent; cset : P ControlComponent; c : ControlComponent (d, cset) in c in cset and c.reentrant = TRUE)) <=> M22 in mismatches and % % Check for Mismatch 23: A reentrant component is either sending or receiving a data transfer. % Precondition: Composition is to be achieved via some bridging data connector, and at least one of the involved control components is reentrant. % Problem: Potential incorrect assumption of which invocation of a component is either sending or receiving a data transfer. (bridgingdataconnectors /= {} and (exists dc : DataConnector dc in dc.c1.reentrant = TRUE or dc.c2.reentrant = TRUE)) <=> M23 in mismatches and % % Check for Mismatch 24: (Triggered) Call to a non-reentrant component. % Precondition: Composition is to be achieved via some bridging (triggered) call, and the callee is not reentrant. % Problem: Component may already be running. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call c in (bridgingcalls setunion c.c2.reentrant = TRUE)) <=> M24 in mismatches and % % Check for Mismatch 25: (Triggered) Spawn to a non-reentrant component. % Precondition: Composition is to be achieved via some bridging (triggered) spawn, and the spawnee is not reentrant % Problem: Component may already be running. ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists s : Spawn s in (bridgingspawns setunion s.c2.reentrant = TRUE)) <=> M25 in mismatches and % % Check for Mismatch 26 Composition involves one or more prioritized parts. % Precondition: One of the subsystems to be composed has a prioritized structure. % Problem: Not clear where a component(s) with or without an associated priority fits in an overall separately prioritized structure. (exists s1, s2 : System; c : ControlComponent s1 in subsystems and s2 in s1 /= s2 and c in s1.controlcomponents and c.priority /= 0) <=> 130

148 M26 in mismatches and % % Check for Mismatch 27: A prioritized system sharing a machine with some other system. % Precondition: A prioritized system sharing a machine with some other system. % Problem: Unclear on how priorities compare across the various parts, which affects the way interrupts are to be applied. (bridgingsharedmachines /= {} and (exists c : ControlComponent c.priority /= (exists s1, s2 : System; c2 : ControlComponent; cset : P ControlComponent; n : Node s1 in subsystems and s2 in subsystems and (cset, n) in c in cset and c2 in cset and s1 /= s2 and c in s1.controlcomponents and c2 in s2.controlcomponents))) <=> M27 in mismatches and % % Check for Mismatch 28: (Triggered) Call or spawn from a subsystem that may later backtrack. % Precondition: At least one of the callers or spawners of bridging connections belongs to a subsystem that has backtracking. % Problem: While backtracking may cause undesired side effects on the called/spawned end. (((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; s : System s in subsystems and c in (bridgingcalls setunion c.c1 in s.controlcomponents and s.backtracking = TRUE)) or ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists sp : Spawn; s : System s in subsystems and sp in (bridgingspawns setunion sp.c1 in s.controlcomponents and s.backtracking = TRUE))) <=> M28 in mismatches and % % Check for Mismatch 29: Data being transferred from some component(s) that may later backtrack. % Precondition: Composition is to be achieved via some bridging data connector, and the component to send data through such a connection belongs to a subsystem that has backtracking. % Problem: Backtracking may cause undesired side effects on the overall composed system state. (bridgingdataconnectors /= {} and (exists dc : DataConnector; s : System 131

149 s in subsystems and dc in ((dc.directionality = forward or dc.directionality = twoway) and dc.c1 in s.controlcomponents and s.backtracking = TRUE) or ((dc.directionality = reverse or dc.directionality = twoway) and dc.c2 in s.controlcomponents and s.backtracking = TRUE))) <=> M29 in mismatches and % % Check for Mismatch 30: Sharing data with a component(s) that may later backtrack. % Precondition: At least one of the subsystems sharing bridging data has backtracking. % Problem: Backtracking may cause undesired side effects on the overall composed system state. (extendedshareddata /= {} and (exists d : DataComponent; cset : P ControlComponent; c : ControlComponent; s : System s in subsystems and (d, cset) in c in cset and c in s.controlcomponents and s.backtracking = TRUE)) <=> M30 in mismatches and % % Check for Mismatch 31: (Triggered) Call from a subsystem requiring some predictable response times to some component(s) not originally considered. % Precondition: Composition is to be achieved via some bridging (triggered) call, and at least one of the calling parts requires predictable response times to some event(s). % Problem: May have side effects on original predicted response times. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; s : System s in subsystems and c in (bridgingcalls setunion c.c1 in s.controlcomponents and s.response_time = predictable)) <=> M31 in mismatches and % % Check for Mismatch 32: (Triggered) Spawn to or from a subsystem requiring some predictable response times that involves some component(s) not originally considered. % Precondition: Composition is to be achieved via some bridging (triggered) spawn, and at least one of the parts involved requires predictable response times to some event(s). % Problem: May have side effects on original predicted response times. The original predicted response times did not account for concurrently executing with these other components. ((bridgingspawns setunion bridgtriggspawns) /= {} and 132

150 (exists sp : Spawn; s : System s in subsystems and sp in (bridgingspawns setunion (sp.c1 in s.controlcomponents or sp.c2 in s.controlcomponents) and s.response_time = predictable)) <=> M32 in mismatches and % % Check for Mismatch 33: Only part of the resulting system automatically reconfigures upon failure. % Precondition: At least one of the parts to be composed has on-line reconfiguration, and at least one has reconfiguration off-line. % Problem: Only part of the resulting system automatically reconfigures upon failure. (exists s1, s2 : System s1 in subsystems and s2 in online in s1.reconfiguration and offline in s2.reconfiguration) <=> M33 in mismatches and % % Check for Mismatch 34: Some components that were expected to synchronize have different synchronization mechanisms. % Precondition: Composing parts are to run concurrently while synchronizing, and have different synchronization mechanisms. % Problem: Synchronization between concurrent parts cannot properly take place. (exists s1, s2 : System s1 in subsystems and s2 in s1.synchronization /= s2.synchronization) <=> M34 in mismatches and % % Check for Mismatch 35: (Triggered) Call to a component that should be preemptable and isn t. % Precondition: Composition is to be achieved via a bridging (triggered) call, and the caller is preemptable, while the callee is not. % Problem: Callee will not be preempted in situations when it should. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; c1, c2 : ControlComponent c in (bridgingcalls setunion c.c1 = c1 and c.c2 = c2 and c1.preemptive = TRUE and c2.preemptive = FALSE)) <=> M35 in mismatches and % % Check for Mismatch 36: (Triggered) Spawn to a component that should be preemptable and isn t. % Precondition: Composition is to be achieved via a bridging (triggered) spawn, and the spawner is preemptable, while the spawnee is not. % Problem: Spawnee will not be preempted in situations when it should. 133

151 ((bridgingspawns setunion bridgtriggspawns) /= {} and (exists s : Spawn; c1, c2 : ControlComponent s in (bridgingspawns setunion s.c1 = c1 and s.c2 = c2 and c1.preemptive = TRUE and c2.preemptive = FALSE)) <=> M36 in mismatches and % % Check for Mismatch 37: (Triggered) Call to a component that performs on the fly garbage collection. % Precondition: Composition is to be achieved via a bridging (triggered) call, the callee performs on the fly garbage collection, while the caller has requirements for some predictable or bounded response times. % Problem: Undesirable side effects on the overall predictable or bounded response times. ((bridgingcalls setunion bridgtriggcalls) /= {} and (exists c : Call; s1, s2 : System s1 in subsystems and s2 in subsystems and c in (bridgingcalls setunion c.c1 in s1.controlcomponents and (s1.response_time = predictable or s1.response_time = bounded) and c.c2 in s2.controlcomponents and on_the_fly_garbage_collection in s2.reconfiguration)) <=> M37 in mismatches and % % Check for Mismatch 38: Incorrect assumption of which instantiation of an object is either sending or receiving a data transfer. % Precondition: Composition is to be achieved via a bridging data connector, and at least one of the parts affected by such connection has encapsulation. % Problem: Incorrect assumption of which instantiation of an object is either sending or receiving a data transfer. (bridgingdataconnectors /= {} and (exists dc : DataConnector dc in dc.c1.type = object or dc.c2.type = object)) <=> M38 in mismatches and % % Check for Mismatch 39: Sharing data with the incorrect instantiation of an object. % Precondition: Composition is to be achieved via some bridging shared data, and at least one of the parts involved has encapsulation. % Problem: Sharing data with the incorrect instantiation of an object. (extendedshareddata /= {} and (exists d : DataComponent; cset : P ControlComponent; c : ControlComponent (d, cset) in c in cset and c.type = object)) <=> 134

152 M39 in mismatches and % % Check for Mismatch 40: Time represented/compared using different granularities. % Precondition: More than one of the composing parts has response time different than unbounded and cyclic unbounded. Additionally, they are distributed over machines that represent and/or compare time using different granularities. % Problem: Communications concerning time cannot properly occur. (exists s1, s2 : System; n1, n2 : Node s1 in subsystems and s2 in subsystems and n1 in s1.nodes and n2 in (s1.response_time /= unbounded or s1.response_time /= cyclic) and n1.time_representation /= n2.time_representation) <=> M40 in mismatches and % % Check for Mismatch 41: Absolute time values are off. % Precondition: More than one of the composing parts has response time different than unbounded and cyclic unbounded. Additionally, they are distributed over machines that have their wall-clock time off. % Problem: Communications concerning time cannot properly occur. (exists s1, s2 : System; n1, n2 : Node s1 in subsystems and s2 in subsystems and n1 in s1.nodes and n2 in (s1.response_time /= unbounded or s1.response_time /= cyclic) and n1.wall_clock_time /= n2.wall_clock_time) <=> M41 in mismatches and % % Check for Mismatch 42: Sharing or transferring data with differing underlying representations. % Precondition: Sharing or transferring data with differing underlying representations, including differences in data formats, units and coordinate systems. % Problem: Communications concerning the specific data will not properly occur. (bridgingdataconnectors /= {} and (exists dc : DataConnector dc in dc.p1.dataformat /= dc.p2.dataformat)) <=> M42 in mismatches and % % Check for Mismatch 43: Resource contention. % Precondition: Two or more parts are co-hosted, with at least one requiring some predictable response time, and the original analysis did not take into account some of the parts that are currently co-hosted. 135

153 % Problem: Predictable response time indirectly affected because there may be some resource contention not originally considered. (bridgingsharedmachines /= {} and (exists bm : (P ControlComponent & Node); s1, s2 : System s1 in subsystems and s2 in subsystems and s1 /= s2 and bm in (exists c1, c2 : ControlComponent; cset : P ControlComponent; n : Node c1 in cset and c1 in s1.controlcomponents and c2 in cset and c2 in s2.controlcomponents and (cset, n) = c1.response_time = predictable))) <=> M43 in mismatches and % % Check for Mismatch 44: Potential database and/or DBMS heterogeneity problems may occur. % Precondition: Two or more repositories are present. % Problem: Our model does not support for checking the specifics here, but problems may arise on semantic heterogeneity, differing data items granularity, databases being distributed or not, databases being replicated or not, and/or databases having different structural organizations. % New parts share more than one repository. (exists s1, s2 : System s1 in subsystems and s2 in subsystems and s1 /= s1.repositories /= {} and s2.repositories /= {}) <=> M44 in mismatches and % % Check for Mismatch 45: Inaccessible shared data. % Precondition: Composition is being achieved by having an applet share data that is local to the client side. % Problem: Applets have no access to the local file system of the client side (i.e., the applet cannot really access the data that is to be shared). % There are bridging shared data, and at least one of the parts involved is an applet, and the data resides on the client. (extendedshareddata /= {} and (exists cc : ControlComponent; d : DataComponent; cset : P ControlComponent; s : System; ws : ID_WebServer s in subsystems and ws in s.controlcomponents and cc in s.controlcomponents and cc.applet = TRUE and cc in d.nodes setint ws.nodes = {} and (d, cset) in extendedshareddata)) <=> M45 in mismatches and % % Check for Mismatch 46: Distributed control units are present. 136

154 % Precondition: Two or more of the composing subsystems have distributed control units. % Problem: Incorrect assumption that a problem is being solved elsewhere, by some other control unit. (exists s1, s2 : System s1 in subsystems and s2 in # {s1.controlunit} > 1 and # {s2.controlunit} > 1) <=> M46 in mismatches); end axiom Therefore now the group operation (below) first checks for the existence of potential mismatches, and then actually generates the attributes for the new composed system. % Group operation for composition global % Inputs include a set of (sub)systems and new bridging connectors. Output is the resulting system. group : (P System & Name & P Call & P Spawn & P SharedData & P Repository & P DataConnector & P Trigger & P (P ControlComponent & Node) & Layers & Layers & Layers) +-> (Success & System); axiom forall subsystems : P System; newname : Name; newcalls : P Call; newspawns : P Spawn; extendedshareddata : P SharedData; extendedrepositories : P Repository; newdataconnectors : P DataConnector; newtriggers : P Trigger; newsharedmachines : P (P ControlComponent & Node); newcall_layers, newspawn_layers, newdataconnector_layers : Layers; success : Success; newsystem : group(subsystems, newname, newcalls, newspawns, extendedshareddata, extendedrepositories, newdataconnectors, newtriggers, newsharedmachines, newcall_layers, newspawn_layers, newdataconnector_layers) = (success, newsystem) <=> (exists potential_mismatches : P % Check for potential mismatches given the group characteristics potential_mismatches = check_for_mismatches(subsystems, newcalls, newspawns, extendedshareddata, extendedrepositories, newdataconnectors, 137

155 itory newtriggers, newsharedmachines) and % There are some detected potential mismatches, hence the grouping needs to be carefully done in an individual basis. potential_mismatches /= {} <=> success = FALSE and % There are no detected potential mismatches, thus the grouping can be done with no worries. potential_mismatches = {} <=> (success = TRUE and newsystem.name = newname and newsystem.controlunit = {x : ControlComponent exists s : System s in x in s.controlunit} and newsystem.initialcontrolcmps = {x : ControlComponent exists s : System s in x in s.initialcontrolcmps} and newsystem.globalobjs = {x : Object exists s : System s in x in s.globalobjs} and newsystem.controlcomponents = {x : ControlComponent exists s : System s in x in s.controlcomponents} and newsystem.classes = {x : Class exists s : System s in x in s.classes} and % Extended shareddata uses existing data but w/ larger sets of sharing components/objects (forall d : DataComponent; cset : P ControlComponent (d, cset) in (exists oldcset : P ControlComponent; s : s in subsystems and (d, oldcset) in s.shareddata and oldcset subseteq cset and cset subseteq getallcontrolcmps(newsystem.controlcomponents, newsystem.globalobjs) setunion getallobjs(newsystem.controlcomponents, newsystem.globalobjs))) and % Extended shared data overrides subsystems shared data newsystem.shareddata = {x : DataComponent & P ControlComponent exists s : System s in x in s.shareddata} += extendedshareddata and % Extended repositories uses existing data but w/ larger sets of sharing components/objects (forall dset : P DataComponent; cset : P ControlComponent; extrep : Repos- extrep in extendedrepositories and dset = extrep.data and 138

156 and and cset = (exists oldcset : P ControlComponent; s : System; rep : s in subsystems and rep in s.repositories and extrep.name = rep.name and dset = rep.data and oldcset = rep.accessingcmps and oldcset subseteq cset and cset subseteq getallcontrolcmps(newsystem.controlcomponents, newsystem.globalobjs) setunion getallobjs(newsystem.controlcomponents, newsystem.globalobjs))) and % Extended repositories overrides subsystems repositories newsystem.repositories = {x : Repository exists s : System s in x in s.repositories and x notin extendedrepositories} setunion extendedrepositories and % All components addressed in the new calls, spawns, and dataconnectors are members of the new system control components (this constraint is redundant) {c : ControlComponent (exists call : ControlConnector call in c = call.c1 or c = call.c2) or (exists spawn : ControlConnector spawn in c = spawn.c1 or c = spawn.c2) or (exists dc : DataConnector dc in c = dc.c1 or c = dc.c2)} subseteq newsystem.controlcomponents % All new data connectors span subsystems (forall d : DataConnector d in (exists s1, s2 : d.c1 in getallcontrolcmps(s1.controlcomponents,s1.globalobjs) and d.c2 in getallcontrolcmps(s2.controlcomponents,s2.globalobjs) and s1 /= s2)) and {x : DataConnector exists s : System s in x in s.dataconnectors} setint newdataconnectors = {} newsystem.dataconnectors = {x : DataConnector exists s : System s in x in s.dataconnectors} setunion newdataconnectors and % All new calls span subsystems (forall c : Call c in (exists s1, s2 : c.c1 in getallcontrolcmps(s1.controlcomponents,s1.globalobjs) and c.c2 in getallcontrolcmps(s2.controlcomponents,s2.globalobjs) and s1 /= s2)) and {x : ControlConnector exists s : System s in x in s.calls} setint newcalls = {} and 139

157 newsystem.calls = {x : ControlConnector exists s : System s in x in s.calls} setunion newcalls and % All new spawns span subsystems (forall sp : Spawn sp in (exists s1, s2 : sp.c1 in getallcontrolcmps(s1.controlcomponents,s1.globalobjs) and sp.c2 in getallcontrolcmps(s2.controlcomponents,s2.globalobjs) and s1 /= s2)) and {x : ControlConnector exists s : System s in x in s.spawns} setint newspawns = {} and newsystem.spawns = {x : ControlConnector exists s : System s in x in s.spawns} setunion newspawns and newsystem.recognizedmsgs = {x : DataComponent exists s : System s in x in s.recognizedmsgs} and newsystem.events = {x : Event exists s : System s in x in s.events} setunion dom newtriggers and newsystem.actions = {x : Action exists s : System s in x in s.actions} setunion ran newtriggers and newsystem.triggers = {x : Trigger exists s : System s in x in s.triggers} setunion newtriggers and % All layers drawn from the control components (forall layer : Layer layer in newcall_layers or layer in newspawn_layers or layer in first layer setunion second layer subseteq getallcontrolcmps(newsystem.controlcomponents, newsystem.globalobjs)) and newsystem.call_layers = {x : Layer exists s : System s in x in s.call_layers} setunion newcall_layers and newsystem.spawn_layers = {x : Layer exists s : System s in x in s.spawn_layers} setunion newspawn_layers and newsystem.dataconnector_layers = {x : Layer exists s : System s in subsystems 140

158 @ x in s.dataconnector_layers} setunion newdataconnector_layers and % Calls constrained to between layers or not constrained at all (forall call : ControlConnector call in ((exists layer : Layer layer in (call.c1 in first layer and call.c2 in second layer) or (call.c2 in first layer and call.c1 in second layer)) or (forall layer : Layer layer in {call.c1, call.c2} setint second layer = {}))) and % Spawns constrained to between layers or not constrained at all (forall spawn : ControlConnector spawn in ((exists layer : Layer layer in (spawn.c1 in first layer and spawn.c2 in second layer) or (spawn.c2 in first layer and spawn.c1 in second layer)) or (forall layer : Layer layer in {spawn.c1, spawn.c2} setint second layer = {}))) and % Dataconnectors constrained to between layers or not constrained at all (forall d : DataConnector d in ((exists layer : Layer layer in (d.c1 in first layer and d.c2 in second layer) or (d.c2 in first layer and d.c1 in second layer)) or (forall layer : Layer layer in {d.c1, d.c2} setint second layer = {}))) and newsystem.response_time = predictable <=> (exists s : System s in s.response_time = predictable) and newsystem.response_time = bounded <=> ((exists s : System s in s.response_time = bounded) and not ((exists s : System s in s.response_time = predictable))) and (forall s : s.response_time = unbounded) <=> (newsystem.response_time = unbounded or newsystem.response_time = cyclic) and % If the system is cyclic it means that some subset of its control components form a ring with respect to its control connectors. newsystem.response_time = cyclic <=> (exists c_set : P ControlComponent; cn_set : P ControlConnector c_set subset newsystem.controlcomponents and cn_set subset uring c_set = {a,b : ControlComponent exists cn : ControlConnector cn in cn.c1 = a and cn.c2 = b}) and newsystem.backtracking = TRUE <=> (exists s : System s in s.backtracking = TRUE) and 141

159 end axiom newsystem.backtracking = FALSE <=> not (exists s : System s in s.backtracking = TRUE) and #newsystem.reconfiguration = 1 or #newsystem.reconfiguration = 2 and #newsystem.reconfiguration = 2 <=> on_the_fly_garbage_collection in newsystem.reconfiguration and on_the_fly_garbage_collection in newsystem.reconfiguration <=> (exists s : System s in on_the_fly_garbage_collection in s.reconfiguration) and (online in newsystem.reconfiguration or offline in newsystem.reconfiguration) and online in newsystem.reconfiguration <=> (exists s : System s in online in s.reconfiguration) and newsystem.synchronization = {x : SynchronizationMechanism exists s : System s in x in s.synchronization} and newsystem.nodes = {x : Node exists s : System s in x in s.nodes} setunion ran newsharedmachines and newsystem.resources = addresources {x : Resources exists s : System s in x = s.resources})) 142

160 143

161 8.0 Compositional Mismatch Analysis There are various means of leveraging from this work to perform architectural mismatch analysis during systems composition. 1 One could simply use the abstractions created here, and do some quick high-level analysis of potential mismatches on paper (section 8.1), invest considerably on a modeling effort and obtain detailed precise information in specific mismatches (section 8.2), or use our AAA tool engine (section 8.3). 8.1 Abstraction on Paper Here we present a short and hypothetical example of how to use our results without access to our tool. The actual steps involved in applying our framework on paper are as follows: 1. Describe the various parts to be composed in terms of features (or pure styles, which in turn can be described in terms of features). - If dealing with descriptions using styles, then identify the specific choices by the relevant parts for each of the features that were left unconstrained for their respective styles. 2. Determine which kinds of connectors do occur during composition. There may be more than one. 1. This work, specially the sections covering architectural conceptual features, could also be used as a basis for defining. evaluating or classifying ADLs. Additionally one could use its resulting models to build a more powerful and detailed analysis tool. Discussions on these and other means of capitalizing on this work can be found in section

162 3. For each feature and given connector, traverse the mismatch table collecting the mismatch numbers that need to be analyzed. - For each of these mismatch numbers evaluate the specific mismatch to determine whether it is applicable on the specific situation (all of its preconditions are met) or not. We will now try to clarify what exactly is encompassed by the compositional mismatch analysis by presenting a small hypothetical example. 1. Describe the various parts to be composed in terms of features (or pure styles, which in turn can be described in terms of features). In this example we will assume that we are to compose two different subsystems. One in the real-time style (RT) and another in the internet distributed entities (ID) one. - If dealing with descriptions using styles, then identify the specific choices by the relevant parts for each of the features that were left unconstrained for their respective styles. Once their underlying styles have been stated one must check for their specific features choices (from the styles vs. features table), see table 9. The underlying styles of the systems to be composed did have some unconstrained features, hence we must determine what the specific choices were for the particular styles instances (see table 10). 144

163 Real-Time Internet Distributed Entities Dynamism threads, no applets threads, downloaded applets Supported Data Transfers unconstrained explicit data connectors Triggering Capability yes yes Concurrency multi-threaded multi-threaded Distribution unconstrained multiple nodes Layering unconstrained yes Encapsulation unconstrained unconstrained Preemption yes unconstrained Response Times predictable unbound Component Priorities yes unconstrained Backtracking no unconstrained Reentrance no yes (server) Reconfiguration unconstrained on the fly garbage collection Control Unit central none Table 9: Real-Time and Internet Distributed Entities Styles Features 2. Determine which kinds of connectors do occur during composition. There may be more than one. In this case the connector is a call from RT to ID, and they do not share a machine. 3. For each feature and given connector, traverse the mismatch table collecting the mismatch numbers that need to be analyzed. Since the connector used is a call, then we must check everything on the call column for applicability (table 11). 145

164 - For each of these mismatch numbers evaluate the specific mismatch to determine whether it is applicable on the specific situation (all of its preconditions are met) or not. RT Dynamism threads, no applets threads, downloaded applets Supported Data Transfers shared variables and explicit data connectors ID explicit data connectors Triggering Capability yes yes Concurrency multi-threaded multi-threaded Distribution single node multiple nodes Layering no yes Encapsulation yes yes Preemption yes no Response Times predictable unbound Component Priorities yes no Backtracking no no Reentrance no yes (server) Reconfiguration on-line on the fly garbage collection and off-line Control Unit central none Table 10: RT and ID Systems Features 2. A layering constraint is violated. Precondition: Any of the composing subsystems originally included layering constraints either on control or data connectors, and composition is achieved by extending exactly that kind of connector to such a subsystem. 146

165 Call Dynamism Supported Data Transfers Triggering Capability 3, 12 Concurrency 15, 34 Distribution 10 Layering 2 Encapsulation 18 Preemption 35 Response Times 16, 31, 37, 40, 41 Component Priorities 26 Backtracking 28 Reentrance 24 Reconfiguration 33, 37 Control Unit 21, 46 Regardless Table 11: Mismatches Related to the Call Bridging Connector ID had layering constraints on its control connectors, and composition is being achieved by a call from RT to ID. The specific call may be violating a layering constraint. This is a potential problem! Problem: Bridging connector may ignore these constraints, thus violating them. 3. Different sets of recognized events are used by two subsystems that permit triggers. Precondition: At least 2 of the composing subsystems permit triggers but have different sets of possible triggering events. 147

166 Both RT and ID have triggering capabilities. It may be the case where their sets of triggering events are different. This is a potential problem! Problem: A trigger may not be recognizable by some subsystem that should. 10. A remote connector is extended into or out of a non-distributed subsystem (i.e. a subsystem originally confined to a single node). Precondition: One of the subsystems was originally confined to a single node, and the resulting composed system is distributed. RT was originally confined to a single node, and the resulting composed system is distributed. This is a potential problem! Problem: The subsystem(s) originally non-distributed cannot handle delays and/or errors occurred due to some distributed communication event. 12. There is a non-deterministic set of actions that could be caused by a trigger. Precondition: At least 2 of the composing subsystems have triggering, and there is at least one event that has more than one trigger associated with it, one from each of the composing subsystems (i.e, each of the composing subsystems had its own set of actions that should occur once the event happens). Both RT and ID have triggering capabilities. It may be the case where there is at least one event that has more than one trigger associated with it. This is a potential problem! 148

167 Problem: It is not clear which set of actions should actually occur based on the composition, and if all it is not clear what the ordering should be. 15. Erroneous assumption of single-thread. Precondition: A control component c1 in a single-threaded subsystem calls a control component c2 in a multi-threaded dynamic subsystem. The problem may arise by c2 spawning c3, terminating and returning control to c1, whose subsystem assumes it is running alone. OR there is a call from a multi-threaded to a single-threaded subsystem. OR there is a spawn from a (single or) multi-threaded subsystem to a single-threaded one, the spawnee assumes it is running alone. Both RT and ID are multi-threaded. This is not a potential problem! Problem: Synchronization problems on accessing shared data, and/or resource contention. 16. (Triggered) Call to a cyclic (non-terminating) subsystem/control component. Precondition: There is a bridging (triggered) call to a cyclic (and hence non-terminating) subsystem / control component. ID is not cyclic. This is not a potential problem! Problem: Control will never be returned to the caller. 18. (Triggered) Call to a private method. Precondition: There is a bridging (triggered) call to a private method. 149

168 The bridging call may be to a private method within ID. This is a potential problem! Problem: Method not accessible to the caller. 21. More than one central control unit exists. Precondition: More than one central control unit exists as a result of composition. There is only one central control unit, that of RT. This is not a potential problem! Problem: All central control units assume they have absolute control on execution sequencing. 24. (Triggered) Call to a non-reentrant component. Precondition: Composition is to be achieved via some bridging (triggered) call, and the callee is not reentrant. ID is reentrant. This is not a potential problem! Problem: Component may already be running. 26. Composition involves one or more prioritized parts. Precondition: One of the subsystems to be composed has a prioritized structure. RT s components are prioritized. This is a potential problem! 150

169 Problem: Not clear where a component(s) with or without an associated priority fits in an overall separately prioritized structure. 28. (Triggered) Call or spawn from a subsystem that may later backtrack. Precondition: At least one of the callers or spawners of bridging connections belongs to a subsystem that has backtracking. Neither has backtracking. This is not a potential problem! Problem: While backtracking may cause undesired side effects on the called/spawned end. 31. (Triggered) Call from a subsystem requiring some predictable response times to some component(s) not originally considered. Precondition: Composition is to be achieved via some bridging (triggered) call, and at least one of the calling parts requires predictable response times to some event(s). RT requires predictable response times. This is a potential problem! Problem: May have side effects on original predicted response times. 33. Only part of the resulting system automatically reconfigures upon failure. Precondition: At least one of the parts to be composed has on-line reconfiguration, and at least one has reconfiguration off-line. RT reconfigures on-line, whereas ID off-line. This is a potential problem! 151

170 Problem: Only part of the resulting system automatically reconfigures upon failure. 34. Some components that were expected to synchronize have different synchronization mechanisms. Precondition: Composing parts are to run concurrently while synchronizing, and have different synchronization mechanisms. Some of RT s components may have to run concurrently with some ID components. It is unknown whether they are expected to synchronize or not. This is a potential problem! Problem: Synchronization between concurrent parts cannot properly take place. 35. (Triggered) Call to a component that should be preemptable and isn t. Precondition: Composition is to be achieved via a bridging (triggered) call, and the caller is preemptable, while the callee is not. RT has preemption, whereas ID does not. This is a potential problem! Problem: Callee will not be preempted in situations when it should. 37. (Triggered) Call to a component that performs on the fly garbage collection. Precondition: Composition is to be achieved via a bridging (triggered) call, the callee performs on the fly garbage collection, while the caller has requirements for some predictable or bounded response times. 152

171 ID performs on the fly garbage collection, and RT has predictable response time requirements. This is a potential problem! Problem: Undesirable side effects on the overall predictable or bounded response times. 40. Time represented/compared using different granularities. Precondition: More than one of the composing parts has response time different than unbound and cyclic unbound. Additionally, they are distributed over machines that represent and/or compare time using different granularities. ID has response time unbound. This is not a potential problem! Problem: Communications concerning time cannot properly occur. 41. Absolute time values are off. Precondition: More than one of the composing parts has response time different than unbound and cyclic unbound. Additionally, they are distributed over machines that have their wall-clock time off. ID has response time unbound. This is not a potential problem! Problem: Communications concerning time cannot properly occur. 47. Distributed control units are present. Precondition: Two or more of the composing subsystems have distributed control units. 153

172 RT has a central control unit, and ID has no control unit. This is not a potential problem! Problem: Incorrect assumption that a problem is being solved elsewhere, by some other control unit. 8.2 The AAA Model If detailed and precise results are required, analysis can be performed at the model level. The actual steps involved in applying our framework through the model are as follows: 1. Describe the various parts to be composed in terms of base elements using Z and the infrastructure we created. 2. Determine which kinds of connectors do occur during composition. There may be more than one. 3. For the expected resulting system, including each of the parts to be composed and the given connectors, manually trace the group and check_for_mismatches Z operations. This should be a very tedious, long and error prone operation, but yield very precise results. We will not furnish an example of performing this kind of analysis because of the unlikelihood of this being ever attempted elsewhere. 154

173 8.3 The AAA Tool We created a Java tool called AAA that performs mismatch analysis on high level descriptions of systems built by composition. These systems are described as a composition of subsystems with the corresponding bridging connectors. Subsystems can be described in terms of features and/or styles. The tool also allows users to define their own styles. To illustrate the tool usage, we will show here in detail how it would handle the composition of a subsystem based on the blackboard style with another based on the realtime one. Results of composing a subsystem based on the real-time style with subsystems based on all other styles are shown in appendix E. 1. The user must first create or open an existing project. This is achieved by selecting either the New or the Open options of the Project menu (figure 7). Figure 7: AAA - Project Menu Creating a project will create the file structure needed to store all the project related information, as well as an initial set of styles (the ones described in section 4.0). Opening a project will read all pre-existing project information from the available files. 155

174 For our example we will create a new project called RTwithOthers (figure 8). Figure 8: AAA - Project New 2. The user may then define new style(s) as needed. This is achieved by selecting the Style option in the Artifact menu (figure 9), and then clicking on New at the Style s List window (figure 10). Figure 9: AAA - Artifacts Menu the project (figure 11). The user is then asked to enter the new style name, that must be unique within Figure 11: AAA - NewName 156

175 Figure 10: AAA - Styles List Subsequently the user may set the appropriate values for the various features in the Style window. As seen on figure 12, the user is given the option of either saving or canceling this work. For modifying pre-existing files the user would select the style name from the given style s list (figure 10), click on Ok, and change the feature values just as described above. Our example will use no newly defined styles. 3. The user must then define the subsystems that are to be composed. This can be done based on features or on the styles defined. Subsystems definition follows the same pattern as that of the styles. The user selects Artifacts Subsystems, gets prompted with a list of subsystems, clicks on New, and enters a unique name. These actions result in the display of the subsystem window. 157

176 Figure 12: AAA - Style For our example we will create a subsystem based on each and every one of the styles provided. We shoe here the creation of RTsub, a subsystem based on the real-time style (figure 13). If defining subsystems based on a specific style, the styles choices for particular features are inherited. All features that were unconstrained for the style are shown as unknown for the subsystem. It is up to the user to reflect the specific choice made by the subsystem being described. All features left as unknown will be treated as taking any of the possible values during mismatch analysis. 158

177 Figure 13: AAA - Subsystem RTsub is based on the real-time style, so we define it accordingly by choosing real-time from the style s list provided in the pull-down menu. This automatically sets RTsub s features accordingly. Since we are not dealing with a specific subsystem, we will leave the unknown features unchanged (figure 14- figure 27). When defining subsystems based on features the user must then set each and every feature to reflect the specific situation. 159

178 Figure 14: AAA - Subsystem Backtracking 4. Next the systems to be analyzed for mismatches must be defined. This is actually achieved by selecting the subsystems that will be a part of the system, and bridging connectors used for composition. Once again the user selects Artifacts Systems, gets prompted with a list of systems, clicks on New, and enters a unique name. These actions result in the display of the system window. 160

179 Figure 15: AAA - Subsystem Component Priorities For our example we will create systems showing the composition of RTsub with all other subsystems, one at a time. We show here the creation of RTwithBB, a system that combines RTsub (based on the real-time style) with BBsub (based on the blackboard style) (figure 28). Once the system window comes up, the user must then select the relevant subsystems, in this case RTsub and BBsub (figure 29). 161

180 Figure 16: AAA - Subsystem Concurrency By doing so it creates a list of all pairs of chosen subsystems so that the user can define the bridging connectors between them (if any). For our example we will select all possible connections (figure 30). 5. Invoke the AAA engine to analyze for mismatches. This is done by selecting the AAA Mismatch Analysis option of the Tools menu (figure 31 on page 163), and then choosing the specific system to be analyzed from 162

181 Figure 17: AAA - Subsystem Control Unit the given list (figure 32 on page 177). This invokes the AAA mismatch analysis engine, that in turn will perform the analysis, save and display the results. For our example we will show the selection of RTwithBB. Figure 31: AAA - Tools Menu 6. Review the analysis results. 163

182 Figure 18: AAA - Subsystem Distribution Once the analysis has been performed, the results are saved and automatically displayed (figure 33). For obvious readability reasons we will actually include the contents of the mismatch analysis results here (they are shown as they appear in the file that is saved). AAA Mismatch Analysis Results System name: RTwithBB 164

183 Figure 19: AAA - Subsystem Dynamism Date: 9/3/98 Time: 12:49:57 Mismatches: Short description Two concurrent threads share data, with potential synchronization problems. Problem Potential synchronization problems for concurrent threads while sharing data. Violating subsystems RTsub and BBsub

184 Short description A layering constraint is violated. Problem Bridging connector may ignore existing layering constraints Violating subsystems RTsub (control layering unknown) and BBsub (control layering unknown) (on control layer) RTsub (data layering unknown) and BBsub (data layering unknown) (on data layer) Short description Different sets of recognized events are used by two subsystems that permit triggers. Problem A trigger may not be recognized by some subsystem that should. Violating subsystems RTsub, BBsub Figure 20: AAA - Subsystem Encapsulation 166

185 Figure 21: AAA - Subsystem Layering Short description A (triggered) spawn is made into or out of a subsystem which originally forbade them. Problem May cause synchronization problems, as well as resources contention. Violating subsystems RTsub and BBsub (threads initiating unknown) Short description An unrecognized triggering event is used. Problem 167

186 The trigger will not cause the expected behavior, it will never fire the related actions. Violating subsystems RTsub and BBsub BBsub and RTsub Short description A data connector is made into a subsystem which originally forbade them. Problem Unclear on how data is to be handled for sending or receiving. Violating subsystems RTsub and BBsub Figure 22: AAA - Subsystem Preemption 168

187 Figure 23: AAA - Subsystem Reconfiguration Short description A shared data relationship refers to a subsystem which originally forbade them. Problem May cause synchronization problems. Violating subsystems RTsub and BBsub Short description A (triggered) spawn is made into or out of a subsystem which is not concurrent. Problem 169

188 May cause synchronization problems, as well as resources contention. Violating subsystems RTsub and BBsub (concurrency unknown) Short description A node resource is overused. Problem Resource overusage such as memory and disk space. Violating subsystems RTsub, BBsub Figure 24: AAA - Subsystem Reentrance 170

189 Figure 25: AAA - Subsystem Response Time Short description There is a non-deterministic set of actions that could be caused by a trigger. Problem It is not clear which set of actions should actually occur based on the composition, and if all, it is not clear what the ordering should be. Violating subsystems RTsub, BBsub Short description Data connectors connecting control components that are not always active may lead 171

190 Figure 26: AAA - Subsystem Supported Data Transfers into deadlock. Problem Possibility of deadlock on the control component sending the data. Violating subsystems RTsub and BBsub Short description Data connectors connecting control components that are not always active. Problem Possibility of loss of data. 172

191 Violating subsystems RTsub and BBsub Short description Erroneous assumption of single threaded. Problem Synchronization problems on accessing shared data, and/or resource contention. Violating subsystems RTsub and BBsub (concurrency unknown) Figure 27: AAA - Subsystem Triggering Capability 173

192 Short description (Triggered) Call to a cyclic (non-terminating) subsystem. Problem Control will never return to the caller. Violating subsystems RTsub and BBsub (response time unknown) Short description Erroneous assumption of same underlying platform. Problem Cannot force fit parts to a given platform. Violating subsystems Figure 28: AAA - System 174

193 Figure 29: AAA - System Subsystems RTsub, BBsub Short description (Triggered) Call to a private method. Problem Method not accessible to the caller. Violating subsystems RTsub and BBsub (encapsulation unknown) BBsub and RTsub (encapsulation unknown) Short description (Triggered) Spawn to a private method. Problem 175

194 Method not accessible to the spawner. Violating subsystems RTsub and BBsub (encapsulation unknown) BBsub and RTsub (encapsulation unknown) Short description Sharing private data. Problem Data may not be accessible to all of the sharing entities being composed. Violating subsystems Figure 30: AAA - System and Connections 176

195 RTsub (encapsulation unknown) and BBsub (encapsulation unknown) Short description More than one central control unit exists. Problem All central control units assume they have absolute control on the execution sequencing. Violating subsystems RTsub, BBsub Short description (Triggered) Call to a non-reentrant component. Problem Component may already be running. Violating subsystems RTsub and BBsub BBsub and RTsub Short description Figure 32: AAA - Mismatch Analysis 177

196 (Triggered) Spawn to a non-reentrant component. Problem Component may already be running. Violating subsystems RTsub and BBsub BBsub and RTsub Figure 33: AAA - Mismatch Analysis Results Short description Composition involves one or more prioritized parts. Problem Not clear where a component(s) with or without an associated priority fits in an overall separately prioritized structure. 178