Architecture Integration Elements - CiteSeerX

0 downloads 0 Views 52KB Size Report
connectivity of solutions to proven integration strategies to move resolution from the architectural level to the ... All data that is sent into a translator element has a.
Architecture Integration Elements R. Keshav, R. Gamble, J. Payton, K. Frasier Department of Mathematical and Computer Sciences University of Tulsa 600 South College Avenue Tulsa, OK 74014 +1 918-631-2988 (voice) +1 918-631-3077 (fax) Contact Author: R. Gamble Email: [email protected] Technical Report UTULSA-MCS-16-99 May 1999

Abstract When reusing popular and well-tested systems, unexpected interoperability problems, which can be disastrous, are often encountered during implementation. It is clear from research and empirical studies that these problems can be detected at an architectural level of abstraction. The best approach to resolving these problems is a solution at the same architectural level. This abstract analysis makes resolving the interoperability problem a design decision instead of an implementation fix. However, it is not clear how to formulate an architecturally-based integration solution. In this paper we define integration elements that can resolve interoperability problems found by examining the architecture of the participating software components. We demonstrate, through the use of a taxonomy, that published integration strategies comprise these elements. By describing the strategies in this way, the taxonomy facilitates the transition from the design issues regarding interoperability to their implementation. The taxonomy and the elements are part of the Integrating Component Architectures Process (ICAP). Keywords: patterns, taxonomy, interoperability, integration, architecture, formal methods

1 Introduction Software reuse is one of the most important issues facing companies in today’s global marketplace. A primary obstacle to software component reusability is the lack of interoperability, e.g. communication and other interaction within an integrated environment. Reuse is feasible only if existing components can be easily adapted for interoperability, whether these components are from legacy systems, from new development, or from commercial off-the-shelf (COTS) products. Software developers have responded to the growing need for interoperability by implementing standards such as the Common Object Request Broker Architecture (CORBA). However, with the diversity of existing software components and the variety of integration solutions that are available, a significant amount of time and effort is required to resolve problems that arise during integration. Often software developers are most comfortable with building a system from scratch. Reusing components and integrating systems with COTS products or migrating systems to new 1

application environments is still new to many. When developers decide to reuse components interoperability problems often come as a surprise at implementation time because the components were assumed to be reusable and compatible. In addition, it can be a formidable task to discover the correct solution to interoperability problems since published descriptions of these solutions often overlap or they may be language dependent. Thus, extensive integration code fixes may be needed to overcome interoperability problems that in the worst case fail, and in the best case incur increases in development time and product cost. Fortunately, many of the interoperability problems can be predicted if the overall system is evaluated at the architectural level before implementation. Architectural analysis can detect potential conflicts and guide the developer towards the resolution of the problems. It can also reduce the cost and increase the stability of the system being integrated, as the use of ad hoc methods of integration during implementation are minimized. Hindering the detection and resolution of interoperability problems at the architectural level is the lack of a process that enhances software development lifecycles to directly address interoperability problems. For example, such a process could be placed within the elaboration phase of the Rational Unified Process [19]. Minimum requirements for a viable process are the following: -

a set of normalized architectural characteristics that deter interoperability and why a classification of conflict types among characteristics core functionality defined at the same abstract level that can resolve interoperability problems assessed through the architectural characteristics connectivity of solutions to proven integration strategies to move resolution from the architectural level to the implementation of the integrated system

One approach to overcoming these obstacles is to provide primitive dimensions of “fix-up” then back-up to the characteristics that cause the need for the “fix-up” [21]. In this regard, we define integration elements that are at the same abstraction level as component architecture descriptions. These definitions stem from architecture modeling [1, 2, 8, 23] and case study analysis [6, 10, 22]. Each element is a minimal model of integration functionality that is based on some model of incompatibility. Composing multiple elements forms an integration architecture. In addition, we present a taxonomy of common integration strategies, demonstrating how the core functionality of the integration elements is embodied by these strategies. We briefly discuss a process which incorporates the integration elements and taxonomy in evaluating interoperability problems at the architectural level of participating software components.

2 Architecture Integration Research Software architecture is a “set of architectural elements that have a particular form” [18]. Shaw and Garlan [20] define the abstractions of an architectural style as components (computational entities), connectors (the way components interact), system configuration, and constraints over that system. Buschmann et. al [4] describe similar architectural patterns in terms of the same abstraction. However, the patterns are expressed in a more flexible language. Garlan et al. [10] coined “architectural mismatches” to describe interoperability conflicts

2

observed in the construction of Aesop. The mismatches are traced back to the fundamental characteristics of the architectural styles of the interacting system. This case study established that knowledge of the software architecture may aid in identifying interoperability problems. We extend this premise to include that needed integration architectures can be defined as early as the design level at which architectural characteristics are known. Research grew from Garlan et al conclusion [10] that attempted to automate the style analysis to detect interoperabilty problems. Abd-Allah [1] constructed the AAA system to compare characteristic values to determine the existence of a mismatch. The characteristics were taken from a subset of the styles found in [20]. Sitaraman [22] developed IHArch 1.0 as an analysis tool that compared architectural style characteristics (also from [20]) of interoperating systems to predict conflicts and to offer potential solutions. Both IHArch and AAA used Aesop [10] as a case study, achieving the desired mismatches. However, extending the systems to include all styles, including heterogeneous architectures requires further research. The IHArch solutions were only text-based and required formalization at an architectural level of abstraction to better provide an implementation guideline. Other frameworks have been developed for integration that are limited to specific architectural style definitions (such as event systems in [13]). Our research focuses less on the overriding architectural style of the components under considerations (as this may not be known for COTS products or legacy systems) and more on the high level characteristics that contribute to interoperability.

3 Integration Elements To resolve interoperability problems, it is necessary to define what integration “looks like” from an architectural perspective. In this respect, one could think of integration at this level in the form of elements that act much like the computational components associated with an architectural style or pattern [4, 9]. These elements express the primary functional needs for an integration strategy to resolve interoperability problems. Elements can be stand-alone or embedded within computational components with added behavior that is not directly related to integration. 3.1

The Translator Integration Element

The basic function of a translator is to convert data and functions between component formats and perform simple semantic conversion. The translator does not need to know from where the data comes or to where it is sent. All data that is sent into a translator element has a corresponding output, i.e., it must be a total function. For example, a translator may change incremental data into discrete data by placing a delimiter on the receipt of the incremental data, which when reached is submitted as discrete output. It may translate data types, e.g., bags to sets. A translator can also modify parameters and names of function calls across architectural boundaries, as long as the modification is consistent. For instance, the function call from system 1 to system 2 may be foo(param1, param2). If system 2 can only accept the first parameter, the translator would pass foo(param1). Thus, a translator can have a local data store to support its mapping functionality. We can formally model an abstract class of translators. The purpose of this formal model is to 3

reduce the ambiguity in the definition of its basic functionality. A bi-directional translator, BiDirectTranslator, can be modeled as a state-based computational component using Object-Z [7] following the OSS technique [11], extended from [3]. Figure 1 only presents the object constants for all instances of the class. These constants demonstrate what valid information is inherited to describe a bi-directional translator as part of an integration architecture. The name of the class appears outside the box followed by the variable types. These types can be bound within subclasses or instances. The type declarations for the constants are above the midline and their constraints are below the midline. Comments are in italics to the right. Constraint numbers in the form of CX appear to the left for easy reference. For the full Translator model, including its state description and state transitions, please see [11]. BiDirectTranslator[TSTATE, set FORMAT1, set FORMAT2]

C1 C2 C3 C4

input : set FORMAT1 output : set FORMAT2 maps : FORMAT1 ¯ FORMAT2 states : set TSTATE start : TSTATE transitions : (STATE × set FORMAT1 × (FORMAT1 ¯ FORMAT2)) ↔ (STATE × set FORMAT2) start ∈ states input ⊆ dom maps output ⊆ ran maps ∀ s1, s2 :states; d1 : set FORMAT1; d2 : set FORMAT2 m : FORMAT1 ¯ FORMAT2 • ((s1, d1, m), (s2, d2)) ∈ transitions ⇒ d1 ⊆ inputs ∧ d2 ⊆ outputs ∧ m ⊆ maps

Valid input Valid output Translation function Allowed internal states The start state State transition requirements and results Declared start state is valid Valid input can be transformed Transformed output is valid A valid state transition uses valid states, input, and output, along with some prescribed transformation

Figure 1: BiDirectTranslator Class Constants At the top of Figure 1, the BiDirectTranslator has variable types TSTATE, set FORMAT1, and set FORMAT2 representing the generic user-defined types for this translator’s states and the sets of information in two particular formats, respectively. The input and output of this translator have distinct formats. The constant maps is a total bijective function that provides the mapping from the input format to the output format. By being total, every input has some respective output. By being bijective, its inverse is a total function. By being a function, instead of a relation, each mapping provides a single answer. If multiple answers are allowed (using a relation), a controller (see Section 3.2) would make the final decision. If the total function is not bijective, then directionality may be limited. The input and output information must be valid within the maps function (C2 & C3). The states constant holds the set of all possible states for the translator, while start is a valid starting state (C1). The transitions constant represents all possible state transitions, indicating what plays a role in changing the state. In this case, the current state, some portion of the input information and mapping information are used to transform the state and produce the output (C4). 3.2

The Controller Integration Element

A controller integration element coordinates and mediates the movement of information between components using predefined decision-making processes. The decisions include determining (1) which data is passed forward, (2) from which components to accept data, (3) to which components to send data, or (4) a combination of the above decisions. If decisions are made with 4

respect to components, then the controller needs to know the identity of those components. A local data store is allowed for decision making. The controller must maintain the information in its original incoming format. Format changes require a translator. The controller integration element can also be formally modeled as a state-based component. Variations and specializations of this model can be found in [11, 23]. Figure 2 describes the constants associated with the formal description for an integration architecture to embed a controller that makes decisions based on the components that provide input and except output. We call this type of controller a Coordinator. Coordinator [CSTATE, set DATA, CID] inports, outports : set CID alphabet : CID © set DATA strategies : set STRATEGY states : CSTATE ↔ set STRATEGY

C1 C2 C3 C4

start : CSTATE ↔ set STRATEGY transitions : ((CSTATE × set STRATEGY) × (CID © set DATA)) ↔ ((CSTATE × set STRATEGY) × (CID © set DATA)) start ∈ states dom alphabet ⊆ inports ∪ outports ran states ⊆ strategies ∀ s1, s2 : states; in, out : CID © set DATA;  ((s1, in), (s2, out)) ∈ transitions • dom in ⊆ inports ∧ dom out ⊆ outports ∧ dom in ∪ out ⊆ alphabet ∧ ∀ c : CID; dataset, allowed : set DATA  (c, dataset) ∈ in ∪ out ∧ (c, allowed) ∈ alphabet • dataset ⊆ allowed

Valid input and output ports Allowed data on ports Valid decision-making strategies Allowed internal states are associated with strategies The start state State transition requirements and results Start state is valid Data prescribed for all ports All states have valid strategies

Figure 2: Coordinator Class Constants In Figure 2, the Coordinator has user-defined variable types CSTATE, set DATA, and CID that represent the make-up of this controller state, the data type used as input and output, and the component identifiers needed for decision making, respectively. Because the connections in and out of the Coordinator must be associated with distinct components, the ports to these connections have explicit names as defined by inports and outports. The constant alphabet contains all valid data on the ports. Its domain must include at least the valid inports and outports defined (C2). Valid states are formed by a set of tuples which contain the local state information for this controller (CSTATE) and the possible decision making strategies for that state (set STRATEGY). Allowable strategies (C3) can vary on a per state basis. The start state must be a valid state (C1). The state transition of the Coordinator maps the current state (which encompasses the available strategies) along with some subset of the valid inports and the information on those ports to another state and the determined output information on chosen outports (C4). 3.3

The Extender Integration Element

An extender integration element adds new features and functionality to a component to adapt it to its behavior within the integrated system. An extender may also add functionality to the integrated system as a whole to enhance its overall capability. Depending on the application, knowledge of the components with which the extender interacts may or may not be necessary. In 5

some respects, one can think of an extender as embodying those behaviors not performed by a translator or controller. However, below we identify some specific roles that extenders play to integrate systems. • • • •

housing a new shared repository adding a call-back for effective communication between components that communicate opportunistically and components that use a direct call-and-return style hand-shaking or buffering information between two components in cases where more than translation and control are needed an addition in front of a server or a client to perform mundane tasks such as opening files and security checks

Further research may indicate that some of these roles be defined as separate integration elements. Because of the diverse behavior of extenders, each distinct behavior has to be modeled independently. While this is feasible, we do not present these various models within the paper. 3.4

Composite Integration Elements

Very often an appropriate strategy is a composition of integration elements of the same or distinct functions. For example, if multiple components with different data formats needed direct access to a newly formed shared data space, then an extender would hold the data, translators would neutralize the different data formats and a controller would mediate access to the repository. Such composite integration elements are called by concatenation of the terminal integration element used, i.e. Translator-Controller, Translator-Controller-Extender, Translator-Extender and Controller-Extender. As described above, an integration architecture that constructs a newly shared data space requires at least two translators, one or more controllers, and an extender. Thus, the composite integration element under which this integration falls is Translator-Controller-Extender.

4 A Taxonomy for Correspondence Identification The integration elements are modeled as computational components in the system architecture. Thus, they provide a baseline of observable, structural behaviors of a solution to resolve interoperability problems. In addition, it is common to have a solution that requires multiple integration elements of the same type doing different jobs. However, because the integration elements prescribe solutions at the abstract level of the system’s architecture, the developer must return to the original participating software systems to obtain and apply further information toward implementing the integration architecture. Even with this information, connectivity to published integration strategies would guide the developer toward more effective implementation of the necessary integration architecture. This connectivity is best defined by describing a taxonomy of integration strategies and demonstrating how they embed the functionality of the terminal and composite integration elements. Using literature on software component integration, e.g., [1, 5, 22], and design patterns, e.g., [4, 9, 14, 15], we form a partial integration taxonomy (Figure 3) that shows this relationship [12]. We highlight certain integration strategies and give more detail as to why their functionality places them in a particular taxonomy position. We use the term integration strategy to encompass integration processes, techniques, solutions, gateways, and patterns. We consider 6

an integration strategy for the taxonomy if it: 1. 2. 3. 4. 5.

states that it resolves an interoperability problem, states that it is related to an accepted integration strategy, describes one or more mechanisms to decouple or increase functionality, develops a new interface for a component, embodies functionality that is statically well-defined.

We define two typical integration strategies for each integration element where applicable. More information on strategy placement can be found in [12]. While the integration strategies placed in the taxonomy may resolve particular interoperability problems, they are not restricted to having additional functionality and implementation considerations outside of integration. Translator. A typical translator is a Bridge [9]. A Bridge converts data from one form to another without having to identify its clients, therefore allowing the systems to vary independently. The Bridge pattern is used in the design phase when one needs to prevent changes in the system from affecting the client. It is used to hide implementation details from the client. Other strategies that embed translators include the Adapter [9], Converter [14] and Filter [14]. Controller. A Façade [9] is a example of a controller. Unlike the Bridge, the Façade coordinates where a request is to be sent. A Façade decouples complex systems by providing a simple interface to a complex subsystem. This allows the developer to build a customized interface without worrying if it is compatible with all the underlying applications. Other strategies that embed controller functionality include architecture style controllers found in the Blackboard and Rule-based System Styles [23, 8] and avionics patterns such as Sequentially Composed, Dynamically Composed, Conditionally Composed, Selector, and Weighted [14]. Extender. At this point, we have not found any published strategies that contain only functionality extensions. Further research is needed to determine why extenders appear to be coupled with translator capabilities within integration case studies. Translator-Controller. The Mediator [9] uses both translator and controller functions. A Mediator promotes loose coupling by preventing objects from referring to each other explicitly. It is therefore multidirectional. The Mediator has an embedded component responsible for coordinating the interactions between a group of objects. Since the Mediator is often used as a centralized control unit, a translator performs data conversion where necessary. Other strategies that compose translators and controllers include the Database and Application Gateways [5] and the avionics Action Control pattern [14]. Translator-Controller-Extender. The functions defined for translator, controller and extender are all present in the Broker pattern [4, 15]. The Broker explicitly coordinates communication between interoperating applications using an embedded controller, referred to as the broker component. The Broker pattern includes Proxies [4, 15] that extends a system’s functionality by forwarding requests as well as transmitting results and exceptions between clients and servers. Some implementations of Brokers include a Bridge pattern [9] translate data between the systems. The Client-Server Broker [6], Guidance Comparator [14], and the Work Flow Manager [15] are other examples of a translator-controller-extender composite integration element.

7

Translator-Extender. The composite integration element translator-extender is part of the Wrapper pattern [15]. The Wrapper enables the developer to add new functionality to a legacy system that needs to work both independently and with another system. It is designed so that both old and new functionalities in the system remain transparent to the user. A Wrapper is often used during the transitional period between a new system and an old system, allowing developers to gradually introduce and test a new system. Other examples are Proxy [4, 9], Decorator [4, 9], Server Legacy Wrapper [6], Sequential Filter [14], Reducer [14], and Differencer [14]. Controller-Extender. We have not found any integration strategies that fall into this category.

8

Server Legacy Wrapper [6]

Database Gateway [5]

Guidance Comparator [14]

Sequential Filter [14] Decorator [4, 9]

Application Gateway [5] Mediator [9]

Reducer [14]

Broker [4, 15] Action Control [14]

Wrapper [15]

Work Flow Manager [15] Proxy [4, 9]

Differencer [14]

Client Server Broker [6]

TRANSLATOR-CONTROLLER

1..*

1..*

TRANSLATOR-CONTROLLER-EXTENDER

1..*

1..*

1..*

TRANSLATOR-EXTENDER

1..*

1..*

CONTROLLER

TRANSLATOR

Filter [14]

CONTROLLER-EXTENDER

1..*

1..*

EXTENDER

Weighted [14]

Facade [9]

Bridge [4, 9] Converters [14]

Selector [14]

Blackboard Controller [23]

Adapter [9] Rulebase Controller [23]

Sequentially Composed [14]

Conditionally Composed [14]

Dynamically Composed [14]

Figure 3: Taxonomy

9

5 Interoperability Analysis during System Development In this section, we briefly describe the Integrating Component Architectures Process (ICAP) for the early architectural analysis of integrated software components [17]. This process outlines how architecture interoperability analysis can proceed, when the integration elements form a result, and when that result is used within the taxonomy to eventually implement an integration architecture. Figure 4 illustrates the process using an example of five distinct software components to be integrated into a single system. In our example, a company has an in-house payroll system (IH) for which they are currently designing a custom retirement contribution package (E). They would like to integrate commercial tax software but must choose between two different products which are equivalent in cost and overall function (COTS A and COTS B). The entire system should be web based, so they are currently designing an appropriate GUI (SE). After forming the functional view of the integrated system, ideally they should determine answers to questions related to interoperability, e.g. • • • • • •

Is E’s design interoperable with IH such that the extension is direct? Given an assessment of potential interoperability problems and the complexity of their resolution, is COTS A a better choice than COTS B? Is SE’s design interoperable with all the systems that will be affected by the GUI? Can interoperability problems with COTS A or COTS B be resolved through design changes in E and/or SE? What overall system constraints inhibit interoperability? What are the best integration strategies to be use to solve the known interoperability problems?

The ICAP consists of three major steps whose titles are borrowed from database integration research [16]: pre-integration, correspondence identification and integration.

10

PRE-INTEGRATION Architectural characteristics of each component IH COTS A

COTS B

SE

E DETERMINE INTEGRATION CONFLICTS

Feedback for design changes

Conflicts found at the architectural level

Architectural characteristics are examined. Fundamental elements of interoperability are reported to form an integration solution at the architectural level.

DETERMINE CORE FUNCTIONALITY TO RESOLVE CONFLICTS

Integration Elements

CORRESPONDENCE IDENTIFICATION MATCH INTEGRATION ELEMENTS WITH SOLUTIONS IN THE TAXONOMY Possible solution s found in the taxonomy

Elements of the architectural integration solution point to categories of integration strategies and patterns for representation and implementation.

CHOOSE FINAL STRATEGY

Integration solution from the taxonomy

INTEGRATION

E IH

COTS A

SE

Actual implementation of the integration architecture.

Figure 4: Integrating Component Architectures Process Pre-integration: In this phase developers compare the architecture characteristics of the independent, participating software components and determine a high-level description of the potential conflicts. For example, if the data flow of IH in Figure 4 is shared, then designing E with passed data would incur unnecessary interoperability conflicts. Likewise, a COTS product that can obtain data from an external repository may be easier to integrate than one that requires all data to be passed to it functions directly. For those software components that are still in the developer stage, feedback on conflicts can provide guidance toward design changes for more compatibility. Unfortunately, manipulating code is not always an option. Therefore, a plan for integration must include external additions to the system components in the form of integration elements. For instance, assume that COTS B in Figure 4 requires passed data. A controller integration element can be used to choose and obtain the correct data from the repository in IH. Multiple translator integration elements would place the data in the correct form to and from COTS B and the repository. Correspondence Identity: Given a previously defined taxonomy of popular integration strategies 11

and patterns and the information from the pre-integration stage, the developer is now aware of which integration elements are needed to achieve interoperability and can use the taxonomy to identify strategies that contain the specified elements. Though, choices are narrowed, the developer may find that there are several applicable solutions. By bringing the systems, the conflicts and the solution to a common denominator it has not only made the process of finding a suitable strategy much simpler, but it will also increase reuse of both tested code and proven strategies. Returning to the data flow problem with COTS B, integration strategies, such as the Mediator, that embody translator-controller functionality would be chosen from the taxonomy. The choice might depend on implementation platform, available resources, and requirements such as performance and reliability. If COTS A had the ability to interface directly with the repository and use the shared data, it would be a better choice with respect to interoperability. Integration: This phase involves implementation, evaluation and testing of the system to determine if the chosen strategy is correct, meets the interoperability needs and adheres to performance requirements. Problems encountered or design changes performed during the system life cycle may require iteration through the ICAP. The ICAP facilitates fulfilling part of the Lifecycle Architecture requirements in the Rational Unified Process [19] by detecting interoperability problems at the architectural level, thereby evaluating certain risks, providing an implementation guideline for overcoming those risks, and establishing a stable integration architecture [17]. However, more is needed in the form of analysis techniques and tools that enable the automated use of this process.

6 Conclusion Interoperability problems can be predicted by examining the architectural descriptions of the software components involved. This analysis should also provide guidance toward resolving these conflicts at the same abstract architectural level. The result is an understanding of the design decisions that must be made to alleviate interoperability problems. It follows that such design information results in a more accurate and less costly implementation. There are many reliable, well-defined integration strategies, whose details may be in the form of patterns, processes and techniques that are scattered across the literature with little relationship information. For many, the definitions do not provide the developer with a foundation to select a strategy for its appropriateness in implementing a correct solution for the integrated architecture design. In this paper, we present integration elements that form the foundation for resolving interoperability problems that result from integrating architectural descriptions. Using literature on software component integration and design patterns, we form an integration taxonomy that shows the relationship between published integration strategies to the core functionality defined by the integration elements. The ICAP outlines how the elements and taxonomy can be used within the software development lifecycle.

12

7 References [1] [2] [3] [4]

[5] [6] [7]

[8] [9] [10]

[11]

[12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]

A. Abd-Allah, Composing Heterogeneous Software Architectures, Ph.D. Dissertation, Dept. CS, USC, August 1996. G. Abowd, R. Allen and D. Garlan. Formalizing Style to Understand Description of Software Architecture. ACM TOSEM, 4(4):319-364, 1995. R. Allen and D. Garlan. A Formal Basis for Architectural Connection, ACM TOSEM, 1997. F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons Ltd. New York, NY, 1996. M. Brodie and M. Stonebraker. Migrating Legacy Systems: Gateways, Interfaces & the Incremental Approach. Morgan Kaufmann,. San Francisco, CA, 1995. D. Cole. Integration Patterns for the Component Web. M.S. Thesis, Dept. MCS, University of Tulsa, 1997. R. Duke, P. King, G. Rose, and G. Smith. The Object-Z Specification Language: Version 1. Software Verification Research Center, The University of Queensland, Technical. Report 91-1, 1991. R. Gamble, P. Stiger, R. Plant. Rule-Based systems Formalized within a Software Architectural Style, Journal of Knowledge Based Systems, forthcoming 1999. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading MA 1995. D. Garlan, R. Allen, and J. Ockerbloom, Architectural mismatch or why it is so hard to build systems out of existing parts, Proceedings of the 17th International Conference on Software Engineering, 1995. K. Hasler, R.Gamble, K. Frasier, and P. Stiger. Exploiting inheritance in modeling architecture abstractions, position paper for 1st Working IFIP Conference on Software Architecture, 1999. R. Keshav and R. Gamble. Towards a Taxonomy of Architecture Integration Strategies, 3rd International Software Architecture Workshop, 1998. D. Luckham, J. Kenney, L. Augustin, J. Vera, D. Bryan, and W. Mann. Specification and Analysis of System Architecture using Rapide. IEEE TSE Vol. 21, No. 4, 1995. D. Lea. Design Patterns for Avionics Control Systems. SUNY Oswego & NY CASE Center, DSSA Adage Project ADAGE-OSW, 1994. D. Mularz. Pattern-based integration architectures. PloP, 1994. C. Parent and S. Spaccapietra, Issues and approaches of Database Integration. ACM 41(5): 166-178. (1998). J. Payton, R. Keshav, R. Gamble. System Development Using the Integrating Component Architectures Process. TR UTULSA-MCS-99-10, Dept. MCS, Univ. of Tulsa. 1999. D. Perry and A. Wolf. Foundations for the study of Software Architecture. SIGSOFT Software Engineering Notes, 17(4): 40-52, 1992. Rational Software. http://www.rational.com. M. Shaw and D. Garlan, Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, 1996. M. Shaw and M. Gentleman, Integration & Interoperability Working Group Report, 1st Working IFIP Conference on Software Architecture, 1999. R. Sitaraman. Integration of software systems at an abstract architectural level, M.S. 13

Thesis, Dept. MCS, University of Tulsa, 1997. [23] P.R. Stiger and R.F. Gamble, Blackboard Systems Formalized within a Software Architectural Style, Int’l Conference on Systems, Man, & Cybernetics, 1997.

14