Building Component directories by classification with concept lattice 16/06/2008 1 Marianne Huchard, Christelle Urtado et Sylvain Vauttier Académie de

Building Component directories by classification with concept lattice

16/06/20081

Marianne Huchard, Christelle Urtado et Sylvain Vauttier

Académie de MontpellierU 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

sous la direction de

parNour Alhouda ABOUD

Spécialité : Professionnelle et Recherche unifiée en Informatique

Laboratoire d'Informatique de Robotiqueet de Micro-électronique de Montpellier

Plan

IntroductionObjectiveBackgrounds

Component Based Developments (CBD)Formal Concept Analysis (FCA)Retrieval measures

Specification for building our component directoryFunctionality signatures latticesInterface latticeComponent types lattice

Other related worksAnalysis CriteriaComparisonDiscussion

ContributionsProposed ExtensionPrototype ImplementationExperiments and Results

Future worksConclusion

16/06/20082

Component-Based DevelopmentCBD aims to compose system from prebuilt software unit the system aims to be developed as a composite of subparts rather than the one entity

16/06/20083 Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

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 compatible provided interface of another component.

Introduction

Required interface

Provided interface

ProductEntry

StatisticsChildOrder

CustomerCreation

Bill

ProductConsultation

Consultation Update

Creation

SilverCustomerDBPrieto-Diaz and Freeman “To reuse a software component, you first have to find it”

16/06/20084

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

Component compatibilty

Interface compatibility

Functionality signaturecompatibility

Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

Objective

16/06/20085

CustomerCreationcreate(CI,bI):SCBill

getTotal():Float

ProductEntryinsert (amount,productName)

delete (amount, productName)

ProductConsultationgetPrice (productName):FloatgetDetails (productName):Product

StatisticsgetDiscount():Float

?

Is there a component in the repository that has an interface compatible with ChildOrder’s CustomerCreation interface ?

ChildOrder

Consultationfind(name):GC[ ]

find(regDate):GC[ ]

Updateupdate (C, name):GCupdate (C, address):GC

Creationcreate(PI):GC

GoldCustomerDB

Consultationfind(name):C[ ]

find(regDate):C[ ]

Updateupdate (C, name):Cupdate (C, address):C

Creationcreate(PI,bI,Co):C

CustomerDB

Consultationfind(name):SC[ ]

find(regDate):SC[ ]

Updateupdate (C, name):SCupdate (C, address):SC

Creationcreate(CI,bI):SC

SilverCustomerDB

Extract from the component repositoryAutomatic search of a compatible component

Objective


16/06/20086

Consultationfind(name):GC[ ]

find(regDate):GC[ ]

Updateupdate (C, name):GCupdate (C, address):GC

Creationcreate(PI):GC

GoldCustomerDB

Consultationfind(name):C[ ]

find(regDate):C[ ]

Updateupdate (C, name):Cupdate (C, address):C

Creationcreate(PI,bI,Co):C

CustomerDB

Consultationfind(name):SC[ ]

find(regDate):SC[ ]

Updateupdate (C, name):SCupdate (C, address):SC

Creationcreate(CI,bI):SC

SilverCustomerDB

CustomerCreationcreate(CI,bI):SC

ChildOrder

BillgetTotal():Float

ProductEntryinsert (amount,productName)

delete (amount, productName)

ProductConsultationgetPrice (productName):FloatgetDetails (productName):Product

StatisticsgetDiscount():Float

Is there a component in the repository that has an interface substitutable to SilverCustomerDB’s Creation interface ?

Automatic component substitution Extract from the component repository

Objective


Component-Based DevelopmentThe cornerstone e for any CBD is software component model which 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

7 21/04/23

Backgrounds

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.

Introduction Backgrounds Directory Building Specification Related works Contributions Conclusion

Fractal ADL• XML files respecting a DTD• A file contains a definition• A definition is a description of a component.

InterfacesSub components (composite component)Links between sub componentsImplementation (primitive component)Controllers

Attributs, controllers16/06/2008

8

BackgroundsFormal 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 dependenciesWhat is a concept ?

21/04/23

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 carsSo 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.


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).

Formal Concept Analysis

16/06/2008

composite

even odd prime square

1

2

3

4

5

6

7

8

9

10

9Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

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

916/06/2008

10 Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion 21/04/23

Backgrounds

Retrieval measuresPrecision & recall

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

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.

16/06/2008


Specification for building our component directory

Functionality signature compatibility in object-oriented programming

Functionality signatures and component interface specification

Lattice of functionality signaturesEncoding the functionality signature binary context

The concept Lattice

Using the functionality signature lattice

Interface lattice

Lattice of component types

Usage of the lattice of component types

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.

16/06/2008


Specification for building our component directory

Functionality signature compatibility in object-oriented programming

Class A

Method M (X x)Y

Class B

Method M (X1 x)Y1

It is possible to override method signatures inSubclasses (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 typeX1 is super class for the class X and Y1 is a subclass of the class Y.


X1

X

Y

Y1

Argument types must be generalized Return type must be specialized.

Information (I)

PersonalInformation (PI)

ChildInformation (CI)

Customer (C)

ForeignCustomer (FC)SilverCustomer (SC)

GoldCustomer (GC)

Void

Product (P)

ChildrenBook AdultBook

EducationalBookBankIdentity (BI)

Country (Co)CreditCartNumber

(CCN

IN parameter type specialization / generalizationOUT parameter type specialization / generalizationIN parameter addition / suppression

All possible variations

Founded on data type sub-typing in an online bookstore application

16/06/2008

13 21/04/23Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion

Case study

ChildOrder

I4 I8

PupilOrder

I3 I10

AdultOrder1

I1 I6

AdultOrder2

I1 I7

SilverOrder

I2 I6

SilverAdultOrder

I2 I9

CustomerDB

I1 I7

SilverAdultDB

I2 I9

GoldDB

I5 I6

(a) components external definitions

I1

I2

I3

I4

I5

create(Information, bankIdentity, country) : Customermodify(Information) : Customer

create(PersonalInformation, bankIdentity, creditCardNumber) : SilverCustomermodify(PersonalInformation, bankIdentity) : SilverCustomer

create(PersonalInformation, bankIdentity, creditCardNumber) : GoldCustomermodify(PersonalInformation, bankIdentity, creditCardNumber) : GoldCustomer

create(ChildInformation, bankIdentity) : SilverCustomermodify(ChildInformation) : void

create(PersonalInformation) : GoldCustomermodify(PersonalInformation) : GoldCustomer

I6

I7

I8

I9

I10

add(Product): voidremove(Product): void

add(AdultBook) : voidremove(Product) : void

add(ChildrenBook) : voidremove(ChildrenBook) : void

add(AdultBook) : voidremove(AdultBook) : void

add(EducationalBook) : voidremove(EducationalBook) : void

(b) Interfaces types definitions

Example of an online bookstore application

16/06/2008


create(Information) create(Information)

create(Information,bankIdentity)

create(Information,bankIdentity,creditCardNumber)

create(Information,bankIdentity)

create(Information,bankIdentity,creditCardNumber)

create(Information)

create(PersonalInformation)

create(ChildInformation)

create(PersonalInformation)

create(ChildInformation)

create():Customer create():Customer

create():SilverCustomer

create():GoldCustomer

create():SilverCustomer

create():GoldCustomer

(c) Compatibility rules for IN parameter: parameter addition or suppression

(b) Compatibility rules for OUT parameter

create(Information)

create():Void create():Void

(a) Compatibility rules for IN parameterS


16/06/2008


Specification for building our component directoryLattice of functionality signatures

Encoding the functionality signature binary context

IN parameter types OUT parameter types

I PI CI BI CCN Co C SC GC

create(PI): GC create(CI, BI): SC create(PI, BI, CCN): SC

create(I, BI, Co):C create(PI, BI, CCN): GC

object = functionality signatures / Attributes = parameter typesEncoding the functionality signature binary context

STEP 1 : Encode the signatures

16/06/2008



Encoding the functionality signature binary context

IN parameter types OUT parameter types

I PI CI BI CCN Co C SC GC

create(PI): GC create(CI, BI): SC

create(PI, BI, CCN): SC

create(I, BI, Co):C

create(PI, BI, CCN): GC

object = functionality signatures / Attributes = parameter typesEncoding the functionality signature binary context

STEP 2 : Infer new encodingsusing compatibility rules on required functionnalities

I < PI I is a valid IN parameter type

GC > SC GC is a valid OUT parameter type

STEP 1 : Encode the signatures

16/06/2008



The concept LatticeLattice of functionality signatures calculated by GaLicia lattice builder

[ http://www.iro.umontreal.ca/~galicia/ ]

create(I,BI):SC

create(I,BI):GC

create(CI,BI):SC

16/06/2008




replaces create(I,BI):SC

create(I,BI):GC

create(I,BI):GC xxx create(CI,BI):SC xxxIf is a valid connection, so is

create(CI,BI):SC

New functionality signatures

16/06/2008



replaces replacescreate(I,BI):SC

create(I,BI):GC

xxxcreate(CI,BI):SC create(I,BI):GC xxxIf is a valid connection, so is

create(CI,BI):SC


16/06/2008



replaces

replacescreate(I,BI):SC

create(I,BI):GC

connects to

Create(CI,BI):SCcreate(I,BI):GCis a valid connection.

create(CI,BI):SC


16/06/2008



replaces

replacescreate(I,BI):SC

create(I,BI):GC

connects to

Create(CI,BI):SCcreate(I,BI):GCis a valid connection.

create(CI,BI):SC


16/06/2008



In the same way we deal with all of modify, add and remove functionality signatures

16/06/2008


Interface latticeSpecification for building our component directory

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 encodingsusing compatibility rules between the concepts in the functionality signatures lattices

16/06/2008


Specification for building our component directoryInterface lattice

replaces

replaces

connects to

If

Interface10 xxx Interface6 xxx

is a valid connection, so is

is a valid connection, so is

xxxInterface10xxxInterface6

is a valid connection.Interface6 Interface10

If

New Intefaces (Signature sets)

16/06/2008


Specification for building our component directoryLattice 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 encodingsusing compatibility rules between the concepts in the interfaces lattice

16/06/2008


Specification for building our component directoryLattice of component types

New component types

16/06/2008


Specification for building our component directoryUsage of the lattice of component types

Emergence of new component typesThe 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

Reingeneering and building generic architectures

The conection between SilverAdultDBof server type (conceptC3) and GoldDB of client type(conept C20) is a valid connection

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 abstractionThe 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.

16/06/2008


Related worksWe 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 CriteriaThe 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).

16/06/2008

29 21/04/23

DC CM WR PTE SC P&R

FAMixed

Facets, classification schemeyes

No Prototype, experiments on library system

Closenessmeasurement

recall was reduced 50% , precision improved 100 %.

SRSCRBSFunctional Keywords, lattice structure yes

prototype implements compilers software library

Matching of the search argument against a specificationnode in the lattice

perfect precision and less than perfect recall

KBRSSRBCMixed Facet, (C&C) scheme yes

CKBR-P, experiments on travel and airline agent components

Query keywords are matched against the informationin both database and XML files

Differs according to the examples but they show the effectiveness of this approach

CRSCBPFunctional Profile clustering yes

___________ similarity valuebetween user's keywords and component, function identifier

___________________

CCMSRSCMixed

Folksonomy, cooperative classification yes

Maracat ,a mechanism to search and retrieval components ___________________

do not improve therecall, but promises significant improvements in precision

ICRSCMixed

terms of characteristics, Genetic algorithm yes

experiments on the optimal value of threshold

matching threshold value between the encoded required characteristics and the classifier ___________________

CBCR FunctionalKeywords, Formal Concept analysis yes

Prototype and experiments on Unix call system

They used incremental queries by a set of significant key words ___________________

SBASRCCR Mixed plus semanticallyrepresentation

natural language processing, domain knowledgetechnologies

yes__________ Conceptual graph matching by akin index augment retrieval recall and precision

Our approach Functional Formal concept analysis, three types of concept lattices

NoPrototype and experiment on multi

examples in order to find components compatibility and new

types of components

___________________ ___________________

Related worksComparison table

Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion16/06/2008

30 21/04/23

Related worksDiscution


•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.

16/06/2008


ContributionsProposed Extension

Question 1:Does our implementation work when we have more than one output parameter?Answer:

void Customer Statistics Customer, StatisticsCreate():void Create(): Customer Create(): Statistics Create():Customer,Statistics

Relation table describe vary output parameter of create function

16/06/2008



replaces replaces

The same principles can be applied when multiple out-parameters are used in a functionality signature

lattice L for the create functionalities (output types)

16/06/2008



The same principles can be applied when multiple out-parameters are used in a functionality signature

lattice LCreate for the create functionalities (output types)

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

void Customer StatisticsCreate():void Create(): Customer Create(): Statistics

Create():Customer, Statistics Relation table describe vary individual output parameter of create function

16/06/2008

(c) Exception type addition or suppression(a) X=Create raises, Compatibility rules for exception type specialization

X=CustomerException

X=SilverCustomerException

X=NoException

X=CustomerException,MemoryException

X=NoException

X=CustomerExceptionX=CustomerException

X=NoException

(b) Subtype relation

X=CustomerException

X=SilverCustomerException

X=Exception X=Exception

X=NoException

Exception

CustomerException MemoryException

GoldCustomerException

SilverCustomerException

NoException


Introduction Objective Backgrounds Directory Building Specification Related works Contributions Conclusion 21/04/2334

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=CustomerException,MemoryException

16/06/2008



replaces replaces

we found that we can extend our approach to include the raised exception within the functionality

16/06/2008

Components directory

Component

Source code files

Type hierarchy used by component

Advanced Fractal ADL to describe component

Components directory hierarchy file

Extracted informations

Advanced Fractal ADL to describe component

Components directory

hierarchy file

Generate context describing the signatures of the create ,modify, add ,remove functionality through its parameters types

Step1 input

Generate xml concept file for the create , modify, add ,remove functionalities lattice by calling Galicia , this xml contain new functionality signature

Generate Signatures lattices L for the create , modify, add ,remove functionalities by calling Galicia

Step1 output

Step1 input

Step1 output

Generate Context RIntSigCar encoding required interfaces using signature generalizations.Rows: interfaces. Columns: canonical signatures and concepts from step1xml files

Generate Interface lattice LI using the functionality signature lattice. by calling Galicia

Step2 input

Step2 output

Step1 input

Step2 output

Step3 input

Generate Lattice of component types using the interface concept lattice.

Generate xml concept file for the create, modify, add ,remove functionalities lattice by calling Galicia, this xml contain new canonical interfaces

Generate Lattice LC of component types using the interface lattice

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)

Component compatibility

Interface compatibility

Functionality signaturecompatibility

(b)Step1

(c)Step2

(d)Step3

(a)Initial step

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

ContributionsPrototype Implementation

16/06/2008 36


ContributionsExperments and results

ResultsPropose a definition for component compatibilityOrganize software components using FCA according to their compatibility

Main difficulty = find the appropriate encodingProvide a browsable component organization to support component search

efficientmeaningful for human software architects

Discover new abstract component specifications abstract concepts in the latticere-engineering information

LimitationsOn large numbers of components huge lattices not readable for a human

ExperimentsWe 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

16/06/2008


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.

16/06/2008


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)

16/06/2008

40 21/04/23

References[1] Christelle Urtado Gabriela Arévalo Nicolas Desnos Marianne Huchard and Sylvain Vauttier. Fca-basedservice 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 ECOOPWorkshops, pages 117129, 2006.[4] http://www.iro.umontreal.ca/ galicia/.[5] Stohr Edward Kim Yongbeom. Software reuse:survey and research directions. Journal of ManagementInformation 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 renementbased system. IEEETransaction on Software Engineering, 23(7):445460, 1997.[10] Vitharana Padmal; Zahedi Fatemeh M.; Jain Hemant. Knowledge-based repository scheme for storingand retrieving business components: a theoretical design and an empirical analysis. IEEE Transactionson 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.AlmeidaSilvio 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 softwarecomponents. 2006.[15] Christian Lindig. Concept-based component retrieval. In J. K(o)hler, F. Giunchiglia, C. Green, andC. Walther, editors, Working Notes of the IJCAI-95 Workshop: Formal Approaches to the Reuse ofPlans, Proofs, and Programs, pages 2125, 1995.[16] Haining Yao and Letha Etzkorn. Towards a semantic-based approach for software reusable componentclassication and retrieval. 2004.[17] F. Gudermann A. Puder, S. Markwitz. Service trading using conceptual structures. InternationalConference 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 DATABASE 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 reuselibrary 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 LongmanPublishing Co., Inc., Boston, MA, USA, 2002.[22] Salah Sadou Chouki Tibermacine, Regis Fleurquin. On-demand quality-oriented assistance incomponent-based software evolution. 2006.

16/06/2008

Documents

Building Component directories by classification with concept lattice 16/06/2008 1 Marianne Huchard, Christelle Urtado et Sylvain Vauttier Académie de