Designing and Building Software Federations

Transcription

1 Designing and Building Software Federations Jacky Estublier, Hervé Verjus, Pierre-Yves Cunin 220 Rue de la Chimie, BP 53 Grenoble Cedex 9. France Abstract. Commercial Off The Shelf tools (COTS) are now widely distributed, of good quality, relatively cheap and cover most of the application domains. It is thus a surprise to consider that it is uncommon to reuse COTS when building large applications. At least it is recognized that building a large application based on COTS is a tough issue. This paper seeks to show why COTS reuse is not a reality; we show why usual composition does not work, and what are the issues to solve in order to make effective (re)use of COTS when building new applications. We show the solutions we have applied, and we describe the early experience with our prototype. 1.0 Introduction The word component is used to talk about very different things. A general collection class is fairly different from an EJB component designed to provide application specific services, which is itself is very different from a COTS tool like Oracle or Excel. Building large applications using COTS raises a number of hard issues, the most fundamental one being the paradigm shift it requires. COTS qualification [17], adaptation, testing, vendor/customer relationships, new development process [14][16], cost and difficulty of integration [21][23] and so on. This paper does not address all of these issues, it focusses on the different aspects of federation support: the new task, methods and paradigms required for actually building an application based on previously selected COTS. A COTS tool (called simply tool in the following) has the following salient characteristics: It is a black box. Source code is not available, the tool cannot be modified. It is designed to be used stand alone, i.e. it does not require other tools. It interacts with its environment in different ways. Federations distinguish from usual CBSE approaches in that federations contain tools, not only classic components. Federations raise three major difficulties not found in classic component based approaches. Overlapping of tools knowledge and services. Non-deterministic apparent behavior of tools. Mismatch between the concepts as defined and implemented in the different tools. The following chapters expose the issues raised by the three points mentionned above, and show the solution we propose. 2.0 Managing the knowledge overlap It may be the case that the tools used in a given federation pertain to the same application domain : it is a domain specific federation. 2.1 Domain specific Federations When tools pertain to the same application domain, they all recognize roughly the same concepts and they are likely to share a large body of knowledge. Example: Suppose that a number of companies involved in transportation systems (busses, train, city public transportation, planes...) decide to create a federation in order to emit multi-modal tickets i.e. tickets valid for an itineraries using any of the transport means handled by a member of the federation. Each transport company has tools for the management of its own tickets. Each tool knows the same ticket, and is involved in a sub-set of its information (different sections or different aspects).

2 2.2 Managing the knowledge overlap The solution we propose consists in defining a set of high level common concepts that abstract and subsume most of the individual tools concepts (e.g., an abstract concept of ticket). We define the Common Universe () as the set of entities, instances of the common (abstract) concepts, shared by the federation tools. Each tool has a particular view of these concepts which may overlap with some (or all) others. Tools actions and reactions corresponding to an abstract concept constitute the real concept i.e. what is really done (outside the ) by the tools during execution. Each tool ask to be notified when a piece of information it (also) handles is changed in the. Conversely, when a common piece of information is changed in a tool (remember that most tools are interactive), the changes accordingly [7]. The is the main way tools synchronize. It provides a placewerethecommoninformationisstoredinaformat which allows each tool to synchronize (both ways) its local knowledge with the common one. Notifications are not only used to synchronize the tool local information with respect to the global one (in the ); it is also used to manage the global federation control. In this strategy each tool observes the and is free to react to changes it finds relevant, perhaps changing other parts of the ; which in turn. Nevertheless, in this approach, tools have the complete initiative to what, when and how to resynchronize; the knowledge overlap is managed only if each tool owning a shared information agrees in the resynchronization strategy. We call foundation, a and the tools that contribute to that evolution. We call application what the federation does; thus, so far we were talking about the application (A) and thus about the Application foundation (see Figure 1). For example, suppose a customer decides to cancel an itinirary the agency attending the customer deletes the ticket in the A. Each tool involved with this ticket will be notified and will cancel the itinerary portion for which it is responsible. The work is done without any need for tools to know each other. 2.3 Managing service overlap In a domain specific federation, some tools have similar functionalities, it is thus possible that two (or more) tools attempt to do the same thing simultaneously, which is likely to leads to inconsistent results. More generally, uncontrolled service overlap is a source of problems. The federation designer would often like to be able to control what each tool is allowed to do, for instance assigning each task to a single tool. In other word we would like to control the anarchy by limiting the capability of tools to act. Tool only know the A, thus their only action w.r.t. the federation consists in observing and changing the A. Each tool may be granted or denied any observation and/or change rights. By default observation rights are granted to anyone. Observation and change rights are part of our component model. The component model itself is part of the information defining the federation composition, internal control, working paradigm, as well as its current state. This information will be used by all tools in charge of the federation control, this why it is stored in a Control Common Universe (C). These tools, collectively constitute the Control foundation (see Figure 1). For example, the initiative control tool, one of the control foundation component, captures all notification and A change requests and, interpreting the C information, decides wether this is legal or not (see Figure 1). The federation designer can thus allocate specific responsibilities to specific tools, and rely on the foundation for the enforcement of this policy.. Application Entity types &instances Application Application Loc Initiative Control Federation components Figure 1: The Controlled initiative 3.0 Managing non-determinism Control Federation Entity types &instances Control Tools are deterministic, but humans, using their interactive interfaces, are not. Tools thus perform concurrently, have some initiative and behave in unpredictable ways; further, tools are free to react and change anything in the A at anytime. We can compare this strategy with a society (the Loc

3 federation) where each individual (the tools) observe the state of the world (A) and, based on its own understanding of what happens, its own goals and capabilities, decides to act, thus changing the state of the world. In this strategy there is no society explicit goal, no rule, no control. This is why we call this strategy the anarchy [3]. In many cases, tools reactions need to be coordinated, in order to react consistently. For instance, in our example, it is clear that changing a portion of an itinirary involves a coordinated reaction from all the companies involved in the whole travel plan. In this chapter we analyses the issues raised by the management of a federation. 3.1 control: handling goals support is a domain where issues related with non determinism have been addressed. Indeed in process technology, a (process) model describes the intended evolution of the real world; a process engine executes the process model changing the values within an universe in which are represented (as objects) the entities of the real world. technology takes provision for handling the discrepancies between the universe state and the real world state, to handle non-deterministic world evolution andsoon[1]. In our system, a process model describes the application behavior in term of the A evolution. This model can be seen as a formal representation of the application goal. 3.2 Paradigm control As seen above, in the anarchic paradigm, there is no rule, no right, and no control. Tools perform concurrently and A p plicatio n unpredictably ; and it is expected that their independent (re)action will lead to a consistent result; as in human society, this is unlikely. A change in the A involves usually more than a single tool, whose (re)actions may need to be coordinated to ensure consistency For example, suppose a customer decides to change the schedule of a fraction of an itinerary; the tool in charge of that portion will receive the notification and will react (changing its internal information if the change is OK, or reject it). Then the tool handling the next itinerary portion may react updating other information and so on. If one itinerary portion cannot be changed, the whole changes must be discarded. We define a Coordination and Consistency Control (CCC) tool, which receives the A change requests, computes which tools will be involved, define the consistency required (transaction control, temporal constraints, tool negotiation and so on); and then invoke the tools, enforcing the required consistency constraints. To do so, the CCC layer interprets a coordination model stored in a Control Common Universe (C). The C has also the knowledge of the components forming the federation (a component model). The CCC layer has the knowledge of the role, rights and duties of each component and enforces the coordination. Tools have no or little initiative. Following our society analogy, the CCC plays the role of a government that decides and enforce the actions of all the humans in the society, denying any initiative. This is why we call this paradigm the dictatorship [3]. Control A pp lication M odel & Instances A pp licatio n E n tity typ es & in stan c es A p p lic a tio n Federation E n tity typ es & in stan c es Control engine CCC In itiative con tro l Loc Loc Figure 2: Multi Paradigm Control In practice we need both paradigms, at the image of a society where some aspects are very closely controlled (as army) and other left to individual initiative (like art); see Figure 2. In our example, modifying an itinerary must be controlled, and deleting a ticket can be done in almost an anarchic style.

4 4.0 Managing meta-model mismatch So far we mada as if all tools understood the concepts in the A, our protocol (calling the A and receiving events), and as if the whole federation was running on the same machine. Many components being COTS, these hypotheses do not hold. In particular, COTS are usually not local and they are unlikely to adhere to our message server protocol, or to accept directly our method calls. This is especially true for generic tool federations. 4.1 Generic tool federations In a federation built from general tools, the main issue is the gap between the concepts handled by the application foundation (the A concepts) and those handled by the tools. For example, a bank federation can be built using Excel, Word, and RCS tools. The bank concepts are clients, accounts and so on, while the tool concepts are spreadsheets, documents and files. In the previous approaches tools are in fact abstract tools which have the nice property to satisfy all our requirements, which allows us to define a federation regardless of each tool details, localization, concept handled and so on. We have identified three main issues: Meta-model mismatch. Tool invocation and observation Compliance with role definition. 4.2 Meta-model mismatch: The Proxy Suppose our bank federation has the role ProductManager in charge of handling the bank products (as seen in the A). This role (among other things) manages the product when moved from a bank desktop to another; it has method "moveproduct (Product)" for doing so. Suppose that RCS is the real tool playing the ProductManager role. Obviously, there is a mismatch between the meta-model of the "ProductManager" role (which manages "products") and the meta-model of RCS (which manages files). The federation requires an RCS Proxy that receives the method calls "moveproduct (Product)" and translates it to "put (file)" where put is a command known by RCS and file is the full path name (including the machine) of the file containing the product. The proxy realizes the semantic translation from role concepts to the real tool concepts. The other way around, translating from the real tool to the federation concepts, is much more difficult, especialy when the tool concepts are low level with respect to the A ones. For instance, translating from the file concept to Product is untractable in the general case. This can be performed only if conventions are defined and/or if the proxy keeps persistent information for that purpose. COTS are often complex tools with a wide range of services; it is common that, in a federation, the same tool plays different roles. For simplicity, in the current protoype, a tool has a single wrapper and a single proxy, but the proxy can play diferent roles simultaneously (it implements all the role s interfaces). The proxy is also in charge of handling the remote communication with its associated tool, more exactly to its assotiated wrapper (see below) using the RMI protocol. Indeed, it is the control foundation that knows the actual location of proxy, wrappers and tools and that instantiate and register them with the RMI registry. 4.3 Tool invocation and observation: the wrapper. The wrapper is a piece of code, usually located on the same machine of the tool it wraps, which makes the interface between that tool and the foundation. A wrapper has two duties: In input, to receive the service requests coming from the proxy and to "pass" them to the component, and to send the result (if any) back to the proxy. In output, to observe the component and to inform the federation (its proxy) when a change in the component statemustbereflectedbyachangeinthea. It is the observation duty that makes the wrapper mandatory; for example if a file is checked-out from RCS, the corresponding product must take state edited, thus the wrapper must notify the federation (its proxy) when files are checked-out. Observation depends pretty much on the component technology, and may not be easy to implement. It should also be possible, in the future, to generate wrappers for some classes of COTS, like a COM or an EJB component. Such a topic is a research issue of its own and will the topic of a forthcoming document. A proxy is generic, in the sense it does not depend on a specific federation, it is the main difference between proxy and wrappers. 4.4 Consistency between real and abstract federation. Federations are expected to be designed in two steps. In the first one, the federation is designed at the abstract level. Concepts, goals, rights, controls, paradigms and properties are described during this phase, and checked by the federation design tools. In the second step, real tools are associated with the roles already defined.

5 Application M odel & Instances Application E ntity types & instances A pplication Federation E ntity types & instances Federation Engine CCC Initiative control Roles Proxies Network W rappers Real Tools Local Store Local Store Local Store Figure 3: Abstract federation and concrete tools. The real federation will satisfy the abstract definition characteristics only if the real tools behave as the role they implement. A proxy implements the role interface, it receives the notifications sent to the role and it calls the application A API. In all aspects the proxy should behave as the corresponding role. The federation design tools check the compliance between the proxy and the roles. This is done, statically, checking if the proxy implements the role interface, at. instantiation subscribing tools to events on their behalf and at execution time checking the rights and the paradigm used. By exception, tools behaving in the anarchic style may not use any proxy; it that case they can call A method and receive events (if allowed). 5.0 Federation design, implementation and control Although we do not have enough experience to provide methods and guidelines for designing and developing federations, we can mention a few important points. First of all, the identification of three different foundations have been found of primary importance. This separation of concerns not only simplifies and clarifies the different aspects, but also, the process and control foundations have the same and tools, no matter the federation; these foundations are reused for all federations. Only the models they use change and these models constitute, to a large extent, the federation design. We think this is fundamental because the federation design becomes explicit, unambiguous and directly executable. 5.1 The design paradigms Our approach for designing federations provides different dimensions (or paradigms) allowing a designer different choices. On the one hand these dimensions are unusual for a designer, on the other hand, their combination offers a very wide range of possibilities The interoperability paradigms The federation designer has a choice between control and initiative. Some tools can be very closely controlled, while others tools can behave freely either because they are harmless, because they are trusted, or because their initiative brings interesting behavior to the federation. Following our analogy, it is striking to notice that in modern societies, the compromise between control and

6 intuitive is eagerly discussed and constantly evolves dynamically; we expect the same will occur in complex federations The process supported paradigm From its origins in the 80s, the software process was understood as the glue between applications. It is only recently, in Enterprise Application Integration (EAI), that process driven tool integration was (re)identified and used at the industrial level. EAI experts emphasize the unprecedented facilities it provides for business analysis, flexibility in redefining and deploying solutions [2]. They insist: the semantic gap between the business view and that of IT is significantly reduced. But in EAI, the process controller directly drives the real tool, and the capabilities of (high end) process support tools for managing non-determinism seems not to be used so far. We extend the EAI process driven tool integration approach in two ways. First the process model is applied to the application A, which is a high level abstraction of the application to build, not of the tools concepts. This almost closes the semantic gap between the business view and the process, and significantly helps in analyzing and improving the process and thus the application itself. Second, we are using process support also to handle the inherent non-determinism introduced by interactive applications. We believe that this issue, often reported in research work but also in the EAI literature, has not been solved so far. We believe that process support, along with the interoperability paradigm dimension are partial answers to that serious issue The multi-model paradigm The A is a model of the application since its schema defines the concepts used by the application and defines the services the application provides. During execution, the entities in the A are modeling the current state of the application. It is widely accepted that a complex application is difficult to model in a single view. The multi-view approaches [24] [25] [26] [27], try to solve that problem focusing mainly on the requirement elicitation and description phases, the objective being to reduce the complexity of each model. This approach addresses the modeling level, not the execution one, and makes the implicit hypothesis that there is a single tool behind all views. In federations, we have different tools with different metamodels; the classical multi-view approach does not fit our needs. We would like to be able to model a federation using different complementary models, each referring to a different concern and thus a different meta-model. The fact that three s have been identified already means federations are described along three different model (process, application and control). Further, the CCC also provides support for solving the multi-model issue. Let us exemplify this point. Suppose that in our bank federation, the A does not contain anything about product management, only about product and desktop. Suppose the federation designer decides to add a product management model to its federation. To do so, he/she defines a role ProductManager and, for each action in the A involving directly or indirectly product management (like moving a product between desktops), the federation designer, through the CCC calls the ProductManager role. Since then, product management will be performed completely transparently with respect to the A, the process model and the other tools. With RCS as the ProductManager tool, the semantics of moveproduct is simply to create a revision of the file each time it is moved (for recovery purpose for example). The federation designer may think this too limited because, in the application, a product can also be a complex document (i.e., containing other documents). The federation designer thus may decide to use CVS instead. It is sufficient to associate the CVS proxy to the ProductManager role. If this bank also manages its software development the federation designer may decides to use ClearCase for all the products; it is sufficient to associate the ClearCase proxy with the ProductManager role; which is done in one mouse click with our role manager. Nothing else changes. Product management is said to be a model wether the model is explicit or not. With RCS, the model is completely hidden in the tool code, for ClearCase an explicit model exists; in very complex cases, the tool can even be a complete federation, with its different models. Thus that bank application can come with a set of product management strategies the customer (bank responsible) can select, or the bank can put its own existing product management tool. This is done without any impact on the application itself. This multi-model strategy allows to define many different (almost orthogonal) aspects, managed independently [12], bringing flexibility, extensibility and evolution facilities. 5.2 The process and control foundations The process and control foundations provide models (languages) for federation definition, the corresponding compilers, and the run-time to support these programs at execution. These foundations can be seen as an early

7 attempt to define a new generation of software engineering environments. In these environments, the programming language will no longer play the major role; most of the code is hidden inside the COTS forming the federation. The major task consists in (1) defining what will be the application, its concepts, its behavior and its characteristics, and (2) in mapping the abstract federation to the real tools. The control foundation proposes a set of tools whose mission is to facilitate federation design. The process paradigm is expressed in the Apel process modeling language (a set of graphical interfaces) [1]; the interoperability paradigm is handled by the right control tool, which is part of the component model, andbythe CCC design tool. Themulti-model paradigm is handled by the CCC design tool, which associate A event with roles and by the role design tool which associates roles with proxies. Currently, we no not provide any support for wrapper and proxy implementation; we only check that a proxy satisfies the requirements associated with the role(s) it is supposed to play. Ongoing and future work will focus on the control foundation development: the extension of federation design tools, and identification and checking of the inconsistencies occurring with an inconsistent use of the various design paradigms and various tools for monitoring and debugging, for controlled evolution and so on. 6.0 Related work This work is part of the large family of work around Component Based Software Engineering, but focuses on the concepts, methods and techniques to use in order to build a software application when components are COTS tools. COTS federations is a topic which received too little attention so far, at least with respect to its high potential payoff. COTS development process Many works have addressed the paradigm shift implied by COTS based SE, emphasizing the need of a new development process [14] [16], the new focus on vendor/customer relationships[15], the impact of not controlling the rate and content of changes, the impact of not owning the source code for critical applications [19] andsoon. Interoperability In our approach, Corba or RMI [5], events [6] [8], communication standards (XML and others)[5], as well as mediators, wrappers and other proxies[2]) are simply technology means, they are not concepts. EAI The Enterprise Application Integration (EAI) domain, addresses the same issue [2], they have explicitly identified the same problems. Unfortunately, in EAI, the level of abstraction is very low. In the solution they propose, most tools are communicating directly and only use adapters and wrappers to adapt as much as possible the communication. In the high end, they consider process (workflow) based approaches, but where the process controls directly the real tools. Component Based Software Engineering (CBSE) Our approach shares many concerns with classic CBSE. Roughly the issue is identical, building an application by composition of preexisting elements, but CBSE usually focus on component, not COTS. It is surprising to consider that this apparently tiny difference results on a very different kind of solution. However, a closer look shows that there are a number of similarities. CBSE emphasizes the way components are instantiated and connected through direct method calls; andmakesprovisionforthesocallednonfunctional properties (distribution, persistence, and so on). In practice, CBSE frameworks (EJB, CCM, COM+,.NET) generate a number of objects (stubs/skeletons and others) which transparently transfer the control to the framework which establishes the communication, instantiate components and so on. In our federation, wrappers observe the components and transfer the control to the foundation which establishes the communication, instantiate components and so on. Our CCC and initiative control can be seen as a generalization of the connector concept because they not only establish transparently a communication mean between N tools, but also provide a close control and property enforcement of that communication like global transaction, coordination, negotiation, including (thanks to proxy and wrapper) data translation, adaptation, formatting and distribution. Non-functional properties are also handled, but in different ways. Each tool is supposed to handle its own persistence, but the A is persistent, and proxy/wrappers can extend a tool with persistence, maybe using the A as persistent store. Transaction support is a major topic still under work; remember that the CCC supports transaction. Distribution is systematically provided. Automatic and dynamic instantiation and initialization of component, locally or remotely, is also provided. Extensions are planned to take care of other Non functional aspects like load balancing, migration, replication and so on. Fundamentally, our federation

8 framework provides the same kind of services than CBSE frameworks. Since the federation, voluntarily, ignores the direct communication between components, a CBSE framework can be used by some components for the direct communication. Thus federation do not seek to replace CBSE frameworks, they are complementary technologies; CBSE handling classic components using explicit communication; federations handling those components which ignore each other, providing implicit communication, overlap management and non deterministic behavior control. 7.0 Conclusion The classic way of building an application today simplistically consists in connecting a piece of code calling a method with the piece of code implementing that method. Instead, we consider pieces of code (tools) not calling anything, behaving in an autonomous and nondeterministic way and providing complex sets of services in different domains. Federating this kind of tool requires rather different paradigms, concepts and techniques. We think this work contributes essentially in the following ways. Abstract design paradigms Interoperability paradigm. At this level of tool complexity and autonomy, federations require the availability of a large pallet of interoperability paradigms, as illustrated by our society analogy. We believe that the departure from completely rigid control paradigms as used today, is of major importance. paradigm. The simple fact that we accept anarchy and initiative, requires new ways to handle nondeterministic behavior. We believe that process support can be a good solution, as well as an intuitive way, capable of closing the gap between the management and the IT view and the application. Multi-model paradigm. Large applications, naturally, have a large range of functions. There is a clear need to design such applications with different models dealing with different parts, not only different views, of the system to build. Our three foundations are already three different models, and our CCC model allows the designer to introduce new dimensions at any time. Linking abstract and concrete federations We believe that a major contribution of this work is to provide the designer with a high-level view and different design dimensions of the application to build. The second contribution is the ability we provide to link this abstract ideal federation with the real tools, in flexible, extensible and easy to evolve ways. Providing design and execution support The third contribution is to provide a complete set of tools for assisting the federation designer in the three abstract design dimensions presented above, the federation implementor, providing compilers and tools for generating code and specifying the links between abstract and concrete federation, and the federation administrator, providing run-time support and tools for monitoring, debugging and evolving the federation. The different models elaborated when designing a federation constitute a large part of the federation specification. These models are expressed using high level modeling tools and formalisms, they are automatically compiled and they are executable. We believe that the capability to support federation design at a high abstraction level and to make the specification executable is a major feature of our environment. We believe this work is a significant step towards the realization of future Software Engineering Environments, where applications will be built assembling many components of all nature, with strong and sometimes conflicting requirements regarding flexibility, evolution and control. References [1] J. Estublier, S. Dami, and M. Amiour. APEL: A graphical yet Executable Formalism for Modelling. Automated Software Engineering, ASE journal. Vol. 5, Issue 1, [2] Jeffrey C. Lutz. EAI Architecture Patterns. EAI Journal, March 2000, P [3] J. Estublier, P.Y. Cunin, N. Belkhatir, Architectures for Support System Interoperability. In Proceedings of the 5th International Conference on The Software, The International Software Association Press, Lisle, IL, June [4] B. Nuseibeh and A. Finkelstein. Viewpoints: A vehicle for method and tool integration. In Proc. of 5th Int l Workshop on CASE; IEEE CS Press, pages 50 60, Montreal, Canada, July [5] J.A.Miller,A.Sheth,K.J.KochutandX.Wang. CORBA-Based Run-Time Architectures for Workflow Management Systems. Journal of Database Management, Special Issue on Multidatabases, 7(1):16-27.

9 [6] D.S. Rosemblum and A. Wolf. A design Framework for Internet-Scale Event Observation and Notification. 6th ESEC. Zurich, Switzeland, September [7] D. Heimbigner. The Wall: a State Server Approach to Programming. ACM- SDE, December [8] OMG. CORBA services: Common Object Service Specification. July ftp://ftp.omg.org/pub/docs/ formal [9] G. Fox, K. Lantner, S. Marcom, A Software Development for COTS-based Information System Infrastructure, in Proceedings of the 5th International Symposium on Assessment of Software Tools, [10] G. Cugola, P.Y. Cunin, S. Dami, J. Estublier, A. Fuggetta, F. Pacull, M. Riviere, H. Verjus. Support for Software Federations. The Pie Platform. EWSPT, Kaprun, Autriche, February Pages LNCS 1780, Springer Verlag. [11] Jacky Estublier, Yves Ledru, Pierres-Yves Cunin. Architecture for process support systems. WICSA, First Working IFIP Conference on Software Architecture. San Antonio, 22, 26 February USA [12] Jacky Estublier, Mahfoud Amiour, Samir Dami. Building a federation of Support System. WACC Work, Activity Coordination and Cooperation; Siplan, Sigmod, Sigsoft conference; San Francisco 22, 26 February USA. [13] P.Y. Cunin. The PIE project: An Introduction. EWSPT, Kaprun, Autriche, February Pages LNCS 1780, Springer Verlag. [14] M. Morisio, C.B. Seaman, A.T. Parra, V.R. Basilli, S.E. Kraft, S.E. Condon. Investigating and Improving a COTS-Based Software Development. ICSE Limmerick, Ireland. [15]L.D.Balk,A.Kedia.PPT:A COTS Integration Case Study. ICSE 2000, Limmerick, Ireland.. [16] NASA/SEL, SEL COTS Study, phase 2. New proposed COTS, SEL , November [17] J.A. Kontio. A Case Study in Applying a Systematic Method for COTS Selection. Proc of the 18th Int Conf. on Software Engineering. March [18] D. Yakimovitch, J.M. Bieman, V.R. Basili. Software Architecture Classification for estimating the cost of COTS integration. Proc of the 21th Int. Conf. of Sotware Engineering, Los Angeles, May [19] D. Carney. Assembling Large Systems from COTS Componentns. Opportunities, Caution and Complexities. SEI Monograph on Use of Commercial Software in Government Systems. SEI, Pittsburgh, USA, June [20] PIE consortium. [21] A. W. Brown, K.C. Wallnau, Engineering of Component-Based System, 7-15, Component-Based Software Engineering: Selected Papers from the Software Engineering Institute (SEI), Los Alamitos, CA: IEEE Computer Society Press, [22] C. Abts, COTS Software Integration Cost Modeling Study, Technical Report, University of Southern California, Center for Software Engineering, Barry Boehm, Director, [23] C. Abts, B.W. Boehm, COTS/NDI Software Integration Cost Estimation & USC-CSE COTS Integration Cost Calculator V2.0 User Guide, revision 1.0, University of Southern California, Center for Software Engineering, September 1997, [24] I. Sommerville, G. Kotonya, S. Viller, P. Sawyer, Viewpoints, 4th. European Workshop on Technology (EWST 95), Noordwijkerhout (NL), 1995, PP [25] M. Verlage. Multi-view modeling of software processes. In B. Warboy, editor, Proc. of European Wokshop on Software Technology EWSPT3, volume 635 of LNCS, pages , Villard de Lans, France, February Springer-Verlag. [26] I. Z. Ben-Shaul and G. E. Kaiser. Federating - Centered Environments: the Oz Experience. ASE journal (Automated Software Engineering), Vol. 5, Issue 1, January 1998, Kluwer Academic Publishers. [27] J. Estublier and N. Belkhatir. A generalized multi view approach. In W. Shaeffer, editor, European Workshop on Software Technology (EWSPT4), LNCS 913, pages 179, 185, Leiden, The Netherlands, April Springer Verlag.