Summarizers:
William Beachley: Responsible for Questions 1 and 2
Genevieve Hudak: Responsible for Questions 3 and 4
Rizwan Ansary: Responsible for Questions 5 and 6
DLC - Summary: Hw 13
1. Main Idea
a. Issues concerning software reuse: Autonomous information delivery with task
relevant and personalized components.
b. Deliver bits of code relevant to new design. Development of this type of
system is very difficult.
c. Reuse is a good idea, but this type of system is difficult to develop.
d. Neat system for encouraging reuse, similar to critic system. Developers may
be reluctant to use because of misunderstanding.
e. Software reuse, Not practical with users with diverse backgrounds. Task-at-hand
system which focuses on individual developer’s background.
f. Deliver information relevant to current programming task while excluding
non-relevant information.
g. Overcoming cognitive obstacles inherent in software reuse.
h. Consideration for developer’s past programming.
i. Promoting software reuse is difficult.
j. Increasing a developer’s awareness of existing code and it’s
functionality using implicit queries based on comments and code is promising
k. Overcoming the conceptual gap between situation model and system model by
delivering task relevant components at the right time.
l. Overcoming developer mistrust of components they don’t know.
m. Getting the most out of information rich spaces and overcoming resistance
to software reuse.
Key things touched upon in the main idea:
1. Overcoming Developer mistrust and resistance to software reuse.
2. The difficulty in developing a system like this.
3. Issues with overcoming the conceptual gap between situation model and system
model.
4. Delivering task relevant components at the right time while excluding non-relevant
components.
5. Issues with increasing developer awareness of existing code and functionality.
6. Task-specific and personalized information delivery.
2.1 Relevant to own work
a. Same concepts can be used when writing a paper.
b. Same concepts can be used when designing a website or creating a Flash animation.
c. CodeBroker would be more useful than my current methods of reuse.
d. Current repositories are very hard to use: no documentation and hard to search.
e. Emacs RCI feature is limited.
f. Took time to understand the importants of reuse and how to reuse.
g. Concepts like LSA and Interface Agents would be applicable to construction
prject control.
h. Code Broker would be very useful to a Java software engineer.
i. Some concepts might be useful to a Project Mangement System.
Key things:
1. Almost everyone found some way in which the concepts described in this article
related to their current research or jobs.
2. Current repositories are practically useless due to lack of documentation
and complex search capabilities.
3. Several people drew analogies to domains outside of software development
such as Construction Project Control, Paper Writing, Project Management Systems,
Website Design and Flash Creation.
4. Several people described limitation to current reuse tools such as Emacs
RCI, Code repositories and one person implied that he was not taught or trained
to reuse at his job as well as maybe he should have been.
2.2 Relevant to own interests
a. I archive all of my work which promotes reuse of concepts described in previous
papers, projects, etc.
b. Could CodeBroker be applied to Software Design as opposed to Implementation?
c. I archive all my Java Code for purposes of reuse.
d. Valuable in FPGA design.
e. Concepts would be valuable for future work in software development.
f. How is LSA used to extract relevant components?
g. Integration of Information Delivery with Information Access.
h. Software Development is difficult and computers should be used to augment
human capabilities.
i. Relevant to interest in Project Construction Control.
j. Interest in integration with a Project Management System.
Key things:
1. There seems to be a strong interest in reuse by the class. Many people stated
that they archive their code, papers, projects and other work in an organized
way to support reuse of past work.
2. Some questions came up such as how LSA was used to extract relevant components
and how the system could be extended or adapted to Project Management Systems,
Project Contruction Control, FPGA design and Software Design as opposed to Software
Imlementation?
3. Many expressed that the concepts in Code Broker are very valuable and they
would be interested in using a system like it at their work.
3. do you have ideas how the work in the paper could or should be further developed?
Most people thought of how the work in the paper could be further developed. Some suggestions included extending an archive to another domain such as cooking or teaching. Others wanted to see CodeBroker in action, and applied to a real-time situation where designers are under deadlines. They thought this would provide the most straightforward way of assessing CodeBroker’s value.
Others suggested further enhancing CodeBroker’s semantic capabilities such as looking for patterns (http://www.cetus-links.org/oo_patterns.html), more context recognition, perhaps by applying machine learning.
One person thought that CodeBroker’s structure made it resistant to change, while others thought the domain of reuse could be applied to many domains.
Another person was interested in learning more about information gathering from development sessions. Several people mentioned that learning from user feedback should be a more developed component of the system. Also enhancing user feedback could be an improvement.
4. have you used any reuse libraries
People who had used reuse libraries before primarily had used Java and C/C++ libraries. Others had used ones such as FORTRAN, Perl, XML, and ASP. Most people found that the most important part of a reuse library was its documentation. The documentation either makes the code usable or not.
Many people also mentioned that the way the library is structured plays a part in their ability to use and find code they want.
Everyone said they liked reusing code when they could. The Java library seems to be the best, and lots of people use the web.
One caveat many people addressed was that it becomes difficult to find what you are looking for if things are not named in a way that helps you find them. In other words, if you don’t know exactly what you are looking for, it can be hard to find anything.
Many people found reuse of code also useful in that they could take that code and then adapt it for their particular purpose.
Of the people that do not use a reuse library they either did not have a reuse library available to them, they used a particular EMACS feature, or they did not need to do much coding that would require using a library (at least they thought).
5. How does Codebroker infer the "task-at-hand"?
All the people gave pretty much the same response. However, some described it as a two step composite approach whereas others described it as an either/or choice between the two steps. Code broker infers task-at-hand by analyzing the comments that a prorammer writes before writing a method. It then looks at the method signature and subsequently applies semantic analysis to extract components from the library/repository that are relevant to the task-at-hand. Here also, a few people have mentioned library while others have preferred to use the word 'repository'.
Some people have further mentioned how the results can be refined for better relevance by manipulating discourse models and user models as well as by refining queries.
6. what are the trade-offs between
6.1. to let the systems infer the task-at-hand
As far as the advantages are concerned, this is what the people had to say:
- If the system is right, then the user is saved the trouble of looking for relevant reusable components.
- If the developer is unaware that some component in the library is useful to him, the system would still provide him witht great help by automatically picking the correct components.
- Even if the result set includes components other than the relevant one, the purpose is still achieved through that one component that the user has been shown.
- The system helps the developer discover unknown components with much more ease.
The advantages mentioned by everyone had similar shades of opinion.
Disadvantages:
- There was unanimity about one disadvantage of this system. If the Codebroker cannot give relevant results then it wastes the user's time and divides his focus by showing components that he never asked to see and does not find useful as well.
- Another disadvantage mentioned by Huda under 6.2 was that the system makes the same assumptions about different developers' knowledge about reusable components, whereas this knowledge would be different for different people.
6.2. versus that the users specifies the task at hand?
The advantages of the user specifying the task-at-hand are:
- It gives more control to the user in specifying what components they already know and which components are irrelevant to them. Most of the people agreed on this greater felxibility being an advantage.
- Nilo mentions that, "If the system is not complex and the software developer has been using the system for a long time, then all the components in the system are either well understood or vaguely known".
- The queries can be refined or reformulated by the user to find the unknown components.
The disadvantages mentioned are as follows:
- The user does not always know what he is searching for.
- The user does not always know that a reusable component relevant to the task-at-hand exists. i.e. the relevant component is in the L3-L4 area. It would further be difficult for the user to come up with queries to find components belonging to the unanticipated information area.
- The user might forget to search.
- It is hard and time consuming for a developer to learn about new components by searching and browsing the documentation.
|
![[spacer]](/schemes/blue/line.gif){kind=small}
