1. To reuse a software
CATCH ME IF YOU CAN component, you first need to
find it
1
2. IDEALIZED COMPONENT
LIFE-CYCLE [1]
Design phase Deployment phase Execution phase
Builde Reposito Assembler Run-time
r ry
A A
A
A Instance
B B
B
B Instance
C D
D
C Instance
D BC
BC
Instance
BC
5. THE NEED OF A COMPONENT
MARKET - I
“the software industry is weakly founded and one aspect of this
weakness is the absence of a software component sub-industry”.
Malcolm Douglas
McIlroy
5
6. THE NEED OF A COMPONENT
MARKET - II
“Imperfect technology in a working market is sustainable; perfect
technology without any market will vanish”
Clemens
Szyperski
6
11. USING THE WEB AS A REUSE
REPOSITORY [4]
Stack
+push(o:Object):vo
id
+pop(void):Object
Describe Describe Search Match
Compile Test
syntax Semantics the web signature
Stack stack1 = new Stack();
Stack1.push(“Lessie”);
assertTrue (((String)
stack1.pop().equals(“Lessie”));
11
13. SEARCH - II [5]
Search # Indexed files # Java files Retrieval algorithms
engine
Koders >1 million 600,000 Keyword and name matching of codes from large open
source hosters
Google Code >10 million 2.5 million Keyword matching of open source code with regex
support
Merobase >10 million 8 million Keyword and name matching, signature matching, and
interface-based and test-driven retrieval on open
source code, binary components, and Web services
Codase <1 million 300,000 Keyword matching of hosted open source codes
Searchcode 250,000 250,000 Keyword and topological matching on indexed open
source code ranked by CodeRank
Sourceforge >10 million 3.5 million Keyword and name matching in open source code and
search for technical Web pages 13
16. REFERENCES
[1] K.-K. Lau and Z. Wang. Software Component Models. IEEE
Transactions on Software Engineering 33(10):709-724, 2007.
[2] H. Mili, F. Mili, and A. Mili. Reusing software: Issues and research
directions. IEEE Transactions on Software Engineering, 21(6):528–
562, 1995.
[3] R. Prieto-D´ ıaz. Implementing faceted classification for soft- ware
reuse. Communications of the ACM, 34(5), 1991.
[4]Hummel, O., Janjic, W. & Atkinson, C., 2008. Code conjurer: Pulling
reusable software out of thin air. Software, IEEE, 25(5), pp.45–52.
[5] Hummel, O. & Atkinson, C. Using the web as a reuse repository. Reuse of Off-
the-Shelf Components, pp.298–311, 2006.
16
Editor's Notes
The differences between the various component models essentially revolve around the way they distribute functionality between components and allow them to be composed rather than on the organizational and procedural concepts used to develop systems. In other word, traditional component-technologies focus on the architectural aspects of software engineering rather than on the process of their development. So the only major process innovation offered by components it the notion of development by assembly, where system are developed by assembly existing parts rather than by traditional implementation techniques.
After 15 years of CBSE Symposium, is interesting to note that only several studies on reuse have been made. After all one could expect more, since component reuse is one of the core motivations of Component Based Software Development.
Since McIloroy’s NATO conference speech in 1968, the idea of reusing code in large scale has never left developers and researches. It was clear that in order to fulfill this wish, a software market was necessary. Most of the scientific articles related to component search and retrieval revolve around the McIloroy's idea: "the software industry is weakly founded and one aspect of this weakness is the absence of a software component sub-industry”.
This statement reinforces that components, such as other technologies, are useful only if there is a market that use them. Indeed it seems logical to invest in a market only if there is a return of that investment. With respect to the company’s boundaries, a market can be internal or external. An internal market, often called in-house, allows stakeholders within the company to adapt a component by modifying its source code (white-box components). Conversely stakeholders in the external market do not have access to the source code, so the component is reused without any modification (black-box components). Choosing between white-box and black-box components, certainly involves a tradeoff. However, benefits of using black-box components outrun those of using white-box ones.Services provided by a black-box component can only be assessed through its documentation or by analyzing its interfaces; extending those services can be done by wrapping that component in a new one. In this way, bug fixes and/or new release of the original component can be easily implemented. This is not true for a white-box components, since modifying the source code imply a separation from the original stream. -CONCLUSION – Nevertheless, even if a black-box component can be thought as silver-bullet[X] there are open questions, such as quality assurance, that need to be addressed.
Figure 1. depicts a component retrieval mechanism as described in [2]. When faced to a problem, the reuser understands it in its own way, and then formulates a query, which may be as simple as a set of key words or as complex as specifications in a formal language. In practice, this first process results in loss of information, since the reuser is not always capable of exactly understanding the problem, or encoding it in the query language. To be retrieved, the information about the components must be encoded. This process of classification (also known as indexing), which may be manual or automatic, results in loss of information. The search itself consists in comparing the query with the indexes and returning the components that match. In literature, several researches that study efficient ways to retrieve components may be found. These works focus on many aspects of the above model, as can be seen in the next sections he query. This information loss is the cause of all the effort in this area.
Software retrieval is far more than just text searching, because software has not only syntax, but has functionality as well. If for example you are looking for an answer to the question “Where is the highest mountain in the world?” within an article, you can easily determine if that information is there or not. Unfortunately it is not the same with software. Just looking at a piece of code you cannot say anything about how well does its job, or how much trust you can put on it. We need something more. Even though there has been an increased interested in software research and retrieval, the main problem is that is impossible to compare different strategies because each one has been developed and tested independently, with totally different methods and test collections. Moreover, most of the time the test collection are not publicly available, making it impossible to test the actual effectiveness of the evolution.
In this work, the author proposes the utilization of a facet-based scheme to classify software components (Figure 2). In this approach, a limited number of characteristics (facets) that a component may have are defined. Then, a set of possible keywords is associated to each facet. To describe a component, one or more keywords are chosen for each facet. In the example of Figure 2, there are four facets: Domain, Functionality, Component Model and Component Type. To describe the Account component, the “Financial” keyword was chosen for the first facet, “Data mining” and “Storage” for the second, and so on. In this way, it is possible to describe components according to their different characteristics, unlike the traditional hierarchical classifications, where a single node from a tree- based scheme is chosen.
The basic idea is to use the whole Web itself as the underlying repository, and to utilize standard search engines as the means of discovering appropriate software assets.
After 15 years of CBSE Symposium, is interesting to point out that only several studies on reuse have been made. After all one could expect more, since component reuse is one of the core motivations of CBSE.
People have been developing all these nice component models, but noone has a good idea how to map component descriptions to actual components. Or in other words, how can we formulate simple component searches and how can we map them to the components?2. How can we evaluate software (component) search approaches?3. How can we identify components in an object-oriented world? You might want to have a look to http://opensme.eu/publications for some initial results from Greece.4. What makes a component reusable?
![IDEALIZED COMPONENT
LIFE-CYCLE [1]
Design phase Deployment phase Execution phase
Builde Reposito Assembler Run-time
r ry
A A
A
A Instance
B B
B
B Instance
C D
D
C Instance
D BC
BC
Instance
BC](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)