1 / 40

Building Component directories by classification with concept lattice

Académie de Montpellier U n i v e r s i t é Mo n t p e l l i e r I I Sciences et Techniques du Languedoc. Spécialité : Professionnelle et Recherche unifiée en Informatique. Laboratoire d'Informatique de Robotique et de Micro-électronique de Montpellier.

gari
Télécharger la présentation

Building Component directories by classification with concept lattice

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Académie de Montpellier U n i v e r s i t é Mo n t p e l l i e r I I Sciences et Techniques du Languedoc Spécialité : Professionnelle et Recherche unifiée en Informatique Laboratoire d'Informatique de Robotique et de Micro-électronique de Montpellier Building Component directories by classification with concept lattice sous la direction de Marianne Huchard, ChristelleUrtado et Sylvain Vauttier par Nour Alhouda ABOUD

  2. Plan Introduction Objective Backgrounds Component Based Developments (CBD) Formal Concept Analysis (FCA) Retrieval measures Specification for building our component directory Functionality signatures lattices Interface lattice Component types lattice Other related works Analysis Criteria Comparison Discussion Contributions Proposed Extension Prototype Implementation Experiments and Results Future works Conclusion

  3. Introduction Component-Based Development • Components expose interfaces: • the description of services they implement: their capacities. • the description of services they need to find in their neighborhood: their needs. • An interface required by a component is connected to a compatibleprovided interface of another component. Provided interface Required interface CBD aims to compose system from prebuilt software unit the system aims to be developed as a composite of subparts rather than the one entity Consultation Update SilverCustomerDB Prieto-Diaz and Freeman “To reuse a software component, you first have to find it” Creation CustomerCreation Bill ChildOrder Statistics ProductEntry ProductConsultation • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  4. Component compatibilty Interface compatibility Functionality signature compatibility Objective • The goal of this thesis is to provide a completely automated process in order to build effective component directories that index components by the services they offer thus enabling to rapidly access them. • This indexation speeds up both automatic component connection and substitution. • In order to achieve such goal, we will study an approach for component's classification in a yellow-page component directory which supports efficient search for components that are compatible or substitutable to a given component as well as we will provide a prototype implements the complete process for this approach. This approach relies on Formal Concept Analysis (FCA). • Problem decomposition • Introduction ObjectiveBackgrounds Directory Building Specification Related works Contributions Conclusion

  5. Objective Automatic search of a compatible component Extract from the component repository Consultation find(name):GC[ ] find(regDate):GC[ ] Update update (C, name):GC update (C, address):GC ? GoldCustomerDB CustomerCreation create(CI,bI):SC Creation create(PI):GC Bill getTotal():Float ChildOrder Statistics getDiscount():Float Consultation find(name):SC[ ] find(regDate):SC[ ] Update update (C, name):SC update (C, address):SC ProductEntry insert (amount,productName) delete (amount, productName) ProductConsultation getPrice (productName):Float getDetails (productName):Product SilverCustomerDB Is there a component in the repository that has an interface compatiblewith ChildOrder’s CustomerCreation interface ? Creation create(CI,bI):SC Consultation find(name):C[ ] find(regDate):C[ ] Update update (C, name):C update (C, address):C CustomerDB Creation create(PI,bI,Co):C • Introduction ObjectiveBackgrounds Directory Building Specification Related works Contributions Conclusion

  6. Consultation find(name):SC[ ] find(regDate):SC[ ] Update update (C, name):SC update (C, address):SC SilverCustomerDB CustomerCreation create(CI,bI):SC Creation create(CI,bI):SC Bill getTotal():Float ChildOrder Statistics getDiscount():Float ProductEntry insert (amount,productName) delete (amount, productName) ProductConsultation getPrice (productName):Float getDetails (productName):Product Objective Automatic component substitution Extract from the component repository Consultation find(name):GC[ ] find(regDate):GC[ ] Update update (C, name):GC update (C, address):GC GoldCustomerDB Creation create(PI):GC Consultation find(name):C[ ] find(regDate):C[ ] Update update (C, name):C update (C, address):C CustomerDB Creation create(PI,bI,Co):C Is there a component in the repository that has an interface substitutableto SilverCustomerDB’s Creation interface ? • Introduction ObjectiveBackgrounds Directory Building Specification Related works Contributions Conclusion

  7. Backgrounds Component-Based Development • Fractal Component Model • Interfaces are the only interaction points between components that express dependencies between components in terms of required/client and provided/server interfaces. • Bindings are communication channels between components interfaces that can be primitive, i.e. local to an address space or composite, i.e. made of components and bindings for distribution or security purposes. • A component in Fractal Model is the composition of a membrane and a content. • The membrane exercises an arbitrary reflexive control over its content (including interception of messages, modification of message parameters, etc.). A membrane is composed of a set of controllers that may or may not export control interfaces accessible from outside the considered component. The cornerstone e for any CBD is software component modelwhich define: Define component ,how to construct them ,how to assembly ,compose, deployed component, Component model are divide currently to: components are objects in OOP Components are architectural unites like EJB and ADL Fractal ADL • XML files respecting a DTD • A file contains a definition • A definition is a description of a component. Interfaces Sub components (composite component) Links between sub components Implementation (primitive component) Controllers Attributs, controllers 25/08/2014 • Introduction Backgrounds Directory Building Specification Related works Contributions Conclusion

  8. Backgrounds Formal Concept Analysis is ... a mathematical term of the philosophical understanding of concept ... a human-centered method to structure and analyze data ... a method to visualize data and its inherent structures, implications and dependencies What is a concept ? • Let's examine an example, the concept “car”: What drives us to call an object a “car” ? • ● Every object having certain attributes is called “car”: • a car has tires, a car has a motor, a car has the purpose of transportation, a car has seats ... etc. • ● All objects having these attributes are called “cars”: • Mercedes, Nissans, Toyotas are cars • So the concept is constituted by two parts : O is a set of objects, A is a set of attributes and R is a ceratin relation between them. Formal Concept Analysis In FCA, a formal context is a triple K = (O,A,R) where O and A are sets (objects and attributes respectively) and R is a binary relation, i.e., R  O×A. Example: K = ({1, 2, 3, 4, 5, 6,7,8,9,10}, {composite, even, odd, prime, square}, R). A formal concept C is a pair of corresponding sets (E, I) such that: E = {e O|i I, (e, i)  R} is called extent (covered objects), I = {i  A|  e  E, (e, i)  R} is called intent (shared features). For example, ({3,5,7}, {odd,prime}) is a formal concept because objects 3, 5 and 7 exactly share attributes odd and prime (and vice-versa). On the opposite, ({5,7}, {odd, prime}) is not a formal concept. Furthermore, the set of all formal concepts C constitutes a lattice L when provided with the following specialization order based on intent / extent inclusion: (E1, I1) ≤L (E2, I2) <==> E1  E2 (or equivalently I2  I1). 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  9. Backgrounds Binary relation of K = (O,A,R) Where O={1, 2, 3, 4, 5, 6,7,8,9,10} and A= {composite, even, odd, prime, square} A concept lattice for objects consisting of the integers from 1 to 10,and attributes composite, square, even,odd and prime. The lattice is drawn by Galicia 9 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  10. Backgrounds Formal Concept Analysis Galicia Galicia project’s main goal is to bridge the gap between theoretical advances in FCA and tool availability. Galicia is a Java based tool for lattice manipulation which follows the complete life-cycle of a lattice. More than just a lattice tool, it is an open platform which provides the necessary services for quick development and test of new lattices algorithms Retrieval measures Precision & recall Recall is defined as the number of relevant components retrieved by a search divided by the total number of existing relevant components (which should have been retrieved). Precision is measured by computing the ratio between the number of relevant (i.e. correct) components retrieved and the total number of components retrieved. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  11. Specification for building our component directory The studied approach consists of three main steps functionality signatures compatibility, interfaces compatibility, component compatibility (three main lattice categories): functionality signatures lattice, interface lattice, component type’s lattice. • Functionality signature compatibility in object-oriented programming • Functionality signatures and component interface specification • Lattice of functionality signatures • Encoding the functionality signature binarycontext • The concept Lattice • Using the functionality signature lattice • Interface lattice • Lattice of component types • Usage of the lattice of component types 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  12. Specification for building our component directory • Functionality signature compatibility in object-oriented programming Class A Method M (X x)Y It is possible to override method signatures in Subclasses (B) from a superclasses (A) thanks to specialization rules. Method M (X1 x)Y1 In the subclass must have contravariant argument types and a covariant return type X1 is super class for the class X and Y1 is a subclass of the class Y. X1 Y Class B Method M (X1 x)Y1 X Y1 Return type must be specialized. Argument types must be generalized • Functionality signatures and component interface specification Founded on data type sub-typing in an online bookstore application Void Product (P) ChildrenBook AdultBook EducationalBook Information (I) PersonalInformation (PI) ChildInformation (CI) Customer(C) ForeignCustomer (FC) SilverCustomer (SC) GoldCustomer (GC) BankIdentity (BI) Country (Co) CreditCartNumber (CCN All possible variations • IN parameter type specialization / generalization • OUT parameter type specialization / generalization • IN parameter addition / suppression 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  13. I4 I3 I1 I1 I2 I8 I10 I6 I7 I6 SilverOrder ChildOrder PupilOrder AdultOrder1 AdultOrder2 I1 I2 I5 I7 I9 I6 I2 I9 SilverAdultOrder CustomerDB GoldDB SilverAdultDB I1 I2 I3 I4 I5 create(Information, bankIdentity, country) : Customer modify(Information) : Customer create(PersonalInformation, bankIdentity, creditCardNumber) : SilverCustomer modify(PersonalInformation, bankIdentity) : SilverCustomer create(PersonalInformation, bankIdentity, creditCardNumber) : GoldCustomer modify(PersonalInformation, bankIdentity, creditCardNumber) : GoldCustomer create(ChildInformation, bankIdentity) : SilverCustomer modify(ChildInformation) : void create(PersonalInformation) : GoldCustomer modify(PersonalInformation) : GoldCustomer I6 I7 I8 I9 I10 add(Product): void remove(Product): void add(AdultBook) : void remove(Product) : void add(ChildrenBook) : void remove(ChildrenBook) : void add(AdultBook) : void remove(AdultBook) : void add(EducationalBook) : void remove(EducationalBook) : void • Case study Example of an online bookstore application (a) componentsexternaldefinitions (b) Interfaces types definitions 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  14. create(Information) create(Information) create(Information) create(Information,bankIdentity) create(PersonalInformation) create(Information,bankIdentity) create(PersonalInformation) create(Information,bankIdentity, creditCardNumber) create(Information,bankIdentity, creditCardNumber) create(ChildInformation) create(ChildInformation) (c) Compatibility rules for IN parameter: parameter addition or suppression create():Customer create():Customer create():SilverCustomer create():SilverCustomer create():GoldCustomer create():GoldCustomer (b) Compatibility rules for OUT parameter • Functionality signatures and component interface specification create(Information) (a) Compatibility rules for IN parameterS create():Void create():Void 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  15. Specification for building our component directory • Lattice of functionality signatures • Encoding the functionality signature binarycontext STEP 1 : Encode the signatures object = functionality signatures / Attributes = parameter types Encoding the functionality signature binary context 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  16. Specification for building our component directory • Lattice of functionality signatures • Encoding the functionality signature binarycontext STEP 1 : Encode the signatures object = functionality signatures / Attributes = parameter types Encoding the functionality signature binary context STEP 2 : Infer new encodings using compatibility rules on required functionnalities I < PI  I is a valid IN parameter type GC > SC  GC is a valid OUT parameter type 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  17. Specification for building our component directory • Lattice of functionality signatures • The concept Lattice Lattice of functionality signatures calculated by GaLicia lattice builder [ http://www.iro.umontreal.ca/~galicia/ ] create(I,BI):GC create(I,BI):SC create(CI,BI):SC 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  18. replaces create(I,BI):GC xxx create(CI,BI):SC xxx Specification for building our component directory • Lattice of functionality signatures • Using the functionality signature lattice New functionality signatures create(I,BI):GC create(I,BI):SC create(CI,BI):SC If is a valid connection, so is 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  19. replaces create(CI,BI):SC xxx create(I,BI):GC xxx Specification for building our component directory • Lattice of functionality signatures • Using the functionality signature lattice create(I,BI):GC replaces create(I,BI):SC create(CI,BI):SC If is a valid connection, so is 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  20. replaces create(I,BI):GC Create(CI,BI):SC Specification for building our component directory • Lattice of functionality signatures • Using the functionality signature lattice create(I,BI):GC replaces create(I,BI):SC create(CI,BI):SC connects to is a valid connection. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  21. replaces create(I,BI):GC Create(CI,BI):SC Specification for building our component directory • Lattice of functionality signatures • Using the functionality signature lattice create(I,BI):GC replaces create(I,BI):SC create(CI,BI):SC connects to is a valid connection. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  22. Specification for building our component directory • Lattice of functionality signatures • In the same way we deal with all of modify, add and remove functionality signatures 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  23. Specification for building our component directory • Interface lattice STEP 1 : Encode the interfaces object = component’s interfaces/ Attributes = concept of functionality signatures generated by Galicia Encoding the interfaces binary context STEP 2 : Infer new encodings using compatibility rules between the concepts in the functionality signatures lattices 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  24. replaces xxx xxx Interface10 xxx Interface6 xxx Specification for building our component directory • Interface lattice If New Intefaces (Signature sets) replaces connects to Interface6 is a valid connection, so is Interface10 is a valid connection, so is If Interface6 Interface10 is a valid connection. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  25. Specification for building our component directory • Lattice of component types STEP 1 : Encode the components object = component types/ Attributes = concept of interfaces lattice generated by Galicia. Interface identification (in column heads) combines the two interface orientations (noted req: and pro:) with each canonical interface name Encoding the component types binary context STEP 2 : Infer new encodings using compatibility rules between the concepts in the interfaceslattice 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  26. Specification for building our component directory • Lattice of component types New component types 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  27. Specification for building our component directory • Usage of the lattice of component types • Emergence of new component types The concept with un empty reduced extent represents new component type we can got it interfaces as in case of required interfaces, we consider the more specific types as ordered in the interface lattice. In case of provided interfaces, we consider the more general types.. • Substitution and connection The conection between SilverAdultDBof server type (conceptC3) and GoldDB of client type(conept C20) is a valid connection • Reingeneering and building generic architectures The discovery of new abstract component types in the classification can be interpreted as reengineering the set of existing components, and can help design more generic architectures. • Architecture abstraction The component lattice shows both specialization relationships among existing component types and newly discovered abstract component types. This can in turn serve as the basis for whole architecture classification. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  28. Relatedworks • We find that there are other approaches in the context of components classification and retrieval, we’ll try to make a comparison between them according to the common criteria described below. The last row of the comparison table represents our approach which is going to be explained clearly in the next chapter. • Analysis Criteria • The related works will be analyzed and compared according to the following criteria: • DC: this criteria represents the way to Describe Component’s functionality in the classification, like if the approaches used functional aspects (source code) to describe the component or non-functional aspects (the environment which the component run on, the code language, the price and the platforms…), also there are mixed ways which use both of functional and non-functional description. • CM: Classification Methods, which differs according to the represented approach; it can be facet classification, folksonomy or formal concept analysis. • WR: With Retrieval criteria refers if the classification approach includes a way to retrieve the components or not. • PTE: this checks if the approach proposes a tool, a prototype and also if there are experiments or no. • SC: Similarity Computation, there are different ways to calculate the similarity between the component description and the query description in component retrieval like conceptual graph similarity [2], the comparison between the bit that encodes the query and the ones for classifier and check if it is greater than the defined threshold [10]. • P&R: Precision and Recall measures in component retrieval, some approaches make experiments to calculate it, or calculate the effect of the approaches over it (increases it or decrease it). 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  29. Relatedworks Comparison table 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  30. Relatedworks Discution • FA: there was no detail about the matching between the query and the component description else that they identified by a closeness measurement. • CRSCBP: in this approach they didn’t make clear experiments, they said that the user enters keywords in the query then these keywords were matched with the component, function identifiers. They didn’t propose a clear way to manipulate the query, • They depend on the hierarchy structure to improve the efficiency in retrieval. • CCMSRSC: This approach is interesting as it provides a way in their prototype Maracatu to rank the search results according to the number of times the tags searched appear on the database (XML file) associated with the components, also at the client side, must be identified before tagging or performing a search that give a kind of security. • ICRSC: the retrieval method is a little bit restricted because the user has to determine the desired values of the component characteristics then he sets the matching threshold value, so the system returns the closest match classifier and will return the components that correspond to this classifier. The recall and precision vary according to the threshold and they make experiment to find the optimal threshold that retrieves a not empty set of related components. • CBCR: there was no experiments to calculate the recall and precision for this approach, but in our opinion it’s clear that the recall will be high because the possibility to refine the query by using significant keywords. • SBASRCCR:they mentioned that they are going to make experiments on a component repository by human experts. • Our approach: our approach doesn’t have a components retrieval method yet but it will be extended to have a one and also to represent the queries. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  31. Contributions Proposed Extension Question 1: Does our implementation work when we have more than one output parameter? Answer: Relation table describe vary output parameter of create function 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  32. replaces Contributions Proposed Extension replaces lattice L for the create functionalities (output types) The same principles can be applied when multiple out-parameters are used in a functionality signature 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  33. Contributions Proposed Extension If we chose to calculate the relation table as functionality signatures are the object and the individual output types, are attributes, it will not give us the same results and it can't be included within our approach Relation table describe vary individual output parameter of create function lattice LCreate for the create functionalities (output types) The same principles can be applied when multiple out-parameters are used in a functionality signature 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  34. X=CustomerException X=CustomerException,MemoryException X=SilverCustomerException X=NoException CustomerException MemoryException SilverCustomerException GoldCustomerException Contributions Proposed Extension Question 2: Can we extend our approach to contain the raised exceptions specialization, addition and suppression in order to classify the functionality signatures? Answer: X=Exception X=Exception X=CustomerException,MemoryException X=CustomerException X=CustomerException X=CustomerException (b) Subtype relation X=SilverCustomerException X=NoException Exception X=NoException X=NoException (c) Exception type addition or suppression (a) X=Createraises, Compatibility rules for exception type specialization NoException 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  35. replaces Contributions Proposed Extension replaces we found that we can extend our approach to include the raised exception within the functionality 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  36. Contributions Step1 input Step1 output Interface compatibility Component compatibility Step1 input Step2 output Prototype Implementation Propose a definition for component compatibility Organize software components using FCA according to their compatibility Provide a browsable component organization to support component search Discover new abstract component specifications (abstract concepts in the lattice, re-engineering information) Step2 input Step3 input Components directory hierarchy file Advanced Fractal ADL to describe component Step1 input Components directory Generate Lattice of component types using the interface concept lattice. Generate Context RIntSigCar encoding required interfaces using signature generalizations. Rows: interfaces. Columns: canonical signatures and concepts from step1xml files Generate context describing the signatures of the create ,modify, add ,remove functionality through its parameters types Component Generate Signatures lattices L for the create , modify, add ,remove functionalities by calling Galicia Generate Lattice LC of component types using the interface lattice Advanced Fractal ADL to describe component Type hierarchy used by component Source code files Step1 output Extracted informations Generate Interface lattice LI using the functionality signature lattice. by calling Galicia Step2 output Generate xml concept file for the create , modify, add ,remove functionalities lattice by calling Galicia , this xml contain new functionality signature Components directory hierarchy file Generate Advanced Fractal ADL file for each component by parsing the source code files, also here we suppose that we have a program that generate a xml file hierarchy for the directory from the xml hierarchy files in each component Generate xml concept file for the create, modify, add ,remove functionalities lattice by calling Galicia, this xml contain new canonical interfaces Functionality signature compatibility (a)Initial step (b)Step1 (c)Step2 (d)Step3

  37. Contributions Experments and results • Results • Propose a definition for component compatibility • Organize software components using FCA according to their compatibility • Main difficulty = find the appropriate encoding • Provide a browsable component organization to support component search • efficient • meaningful for human software architects • Discover new abstract component specifications abstract concepts in the lattice • re-engineering information • Limitations • On large numbers of components  huge lattices not readable for a human • Experiments • We always get new functionality signature, new interfaces and new component types. • Each category of lattice we can find signature compatibility, interface compatibility and components type compatibility 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  38. Future Works • Extend our prototype to contain the raised exceptions specialization, addition and suppression in order to classify the functionality signatures. • Extend the component description to contain both functional and non functional aspects for component description also we aim to classify component according to quality criteria's. • We find that all the related work in this domain focuses on component retrieval and how to enhance retrieval measurement like recall and precision. we aim to improve our approach and integrate a component retrieval method which takes into account retrieval measurement. • On the implementation level, we can enrich our component directory by creating the source code files corresponding to the new component types that appear in the component types lattice. • We would like to extend directory by classifying other components type like ( SOFA, CORBA/CCM, RAPID, EJB components) and we will try to create one unified component description file which will replace our extended fractal ADL le , thus we can provide components compatibility from a function point of view (components provide similar services regardless their type). • In our work , we supposed that there is a mechanism that creates the data types hierarchy le on the directory level, it will be interesting to implement this mechanism by using algorithms for matching techniques covering linguistic similarity, structural similarity, semantic similarity, constraints, etc. 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  39. Conclusion • The goal of the thesis, as it was described has been reached. • An approach for building effective component directories using FCA for components classification has been implemented. • Components compatibility from components connection and substitution was decomposed into functionality signatures compatibility, interfaces compatibility and components compatibility, each part was represented in a type of lattice (functionality signatures lattices, interface lattice, components types lattice) 25/08/2014 • Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

  40. References • [1] Christelle Urtado Gabriela Arévalo Nicolas Desnos Marianne Huchard and Sylvain Vauttier. Fca-based • service classication to dynamically build ecient software component. submitted edition, 2007. • [2] Zheng Wang Kung-Kiu Lau. Software component models. IEEE Trans. Software Eng, 2007. • [3] Thierry Coupaye and Jean-Bernard Stefani. Fractal component-based software engineering. In ECOOP • Workshops, pages 117129, 2006. • [4] http://www.iro.umontreal.ca/ galicia/. • [5] Stohr Edward Kim Yongbeom. Software reuse:survey and research directions. Journal of Management • Information Systems, 14(4):113147, 1998. • [6] P. Prieto-Diaz, R.Freeman. Classifying software for reusability. IEEE Software, 1987. • [7] http://en.wikipedia.org/wiki/Faceted_classication/. • [8] Bohdan S. Wynar. Introduction to cataloging and classication. Englewood Colo, 1992. • [9] Mittermeir Roland T Mili Rym, Mili Ali. Storing and retrieving software components: a renement • based system. IEEETransaction on Software Engineering, 23(7):445460, 1997. • [10] Vitharana Padmal; Zahedi Fatemeh M.; Jain Hemant. Knowledge-based repository scheme for storing • and retrieving business components: a theoretical design and an empirical analysis. IEEE Transactions • on Software Engineering, 29(7):649664, 2003. • [11] Hong S.B.Kapsu Kim. Classifying and retrieving software components based on proles. 1997. • [12] Taciana A. Vanderlei Frederico A. Durão Alexandre C.Martins Vinicius C.Garcia Eduardo S.Almeida • Silvio R. de L.Meira. A cooperative classication mechanism for search and retrieval software components. • 2007. • [13] https://done.dev.java.net/. • [14] Papadopoulos G.A Andreou A.S., Vogiatzis D.G. Intelligent classication and retrieval of software • components. 2006. • [15] Christian Lindig. Concept-based component retrieval. In J. K(o)hler, F. Giunchiglia, C. Green, and • C. Walther, editors, Working Notes of the IJCAI-95 Workshop: Formal Approaches to the Reuse of • Plans, Proofs, and Programs, pages 2125, 1995. • [16] Haining Yao and Letha Etzkorn. Towards a semantic-based approach for software reusable component • classication and retrieval. 2004. • [17] F. Gudermann A. Puder, S. Markwitz. Service trading using conceptual structures. International • Conference on Conceptual Structures, 1995. • [18] B. Ibrahim M. R. Girardi. Using english to retrieve software. Journal of System and Software, 1995. • [19] Veda C Sugumaran, Vijayan; Storey. A semantic-based approach to component retrieval. The DATA • BASE for Advances in Information Systems, 34(3):824, 2003. • [20] Ostertag Eduardo Hendler James Prieto-Díaz Rubén Braun Christine. Computing similarity in a reuse • library system:an ai-based approach. ACM Transaction on Software Engineering and Methodology, • 1(3):205228, 1992. • [21] Clemens Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley Longman • Publishing Co., Inc., Boston, MA, USA, 2002. • [22] Salah Sadou Chouki Tibermacine, Regis Fleurquin. On-demand quality-oriented assistance in • component-based software evolution. 2006. 25/08/2014

More Related