![[spacer]](/schemes/blue/line.gif){kind=small}
|
Andrew Skalet hw13 1. I think the main message of the paper is that promoting software reuse is difficult because programmers don't have sufficient knowledge of the existing components and their functionality. Primarily because programmers aren't aware of the existence of many components, a system (like CodeBroker) that can use the code and comments as an implicit query has much more promise than explicit browsing and searching to promote reuse. 2.1 This is very applicable to work I have done. When I came in as a new developer, I didn't really understand the importance of reuse and how to do it. Initially, I implemented too much by hand. It took some time working with more senior developers for me to understand the importance of using the reusable components, and even then I am sure I could have reused more. 2.2 This technology is very much in line with my interests. I think software development is a difficult task, especially on larger software systems. I also believe that since humans and computers have different strengths, computers should be used to augment human capabilities. Since this technology combines aspects of both interests, this paper is very stimulating to me. 3. I'd like to see CodeBroker in action, but I think that most of the improvement to the system would lie in increased context recognition (including semantics mapping) and increased learning from user feedback. In other words, CodeBroker could probably be improved quite a bit within the same overall framework by improving the machine learning in several aspects. Although users are different, I can imagine that if many users used the system over time it could learn from their usage and rejection of components to provide much better recommendations. Another small thing is that you could incorporate something like CodeBroker into a higher functionality development environment like Visual Studio .NET or the Eclipse platform. In this case you might be able to enhance the visual feedback to the programmer somewhat. 4. Yes. 4.2 I have used many reuse libraries, but I will use the JFC as an example, specifically Swing. I have found that the major strength of reusable libraries lies in their documentation. If the developers of the reusable components do not work in the same room with you, you need good documentation. The JFC does a very good job of this by providing detailed documentation on each class. Also very important is the tutorials the JFC has, which allow a developer to discover new classes and their uses easily, and connect classes with each other conceptually. 5. Codebroker infers the task at hand by analyzing the code currently written by the developer. I get the idea that most of the inference comes from comparing strings in the comments, and method signatures, with a database that maps previously implemented solutions to their semantics and components reused. 6. There are several tradeoffs between inference and explicit specification of the task. When the user specifies the task at hand, a formal specification will probably be necesary. Programmers can hardly translate an informal specification into a formal system, so this task will be very difficult for a computer. UML code generation is an example of a way for users to specify the task formally and convert it to running code, but at this point in time I think many programmers prefer to just write code rather than any other formal specification method. When the user searches and browses documentation, he or she is also specifying the task at hand, but the developer is very unlikely to find anything outside of L2. In other words, it is hard for a developer to learn about new components in this way. This is where infering the task is helpful. If the system can recognize the task, it may be able to save the developer quite a lot of work by guiding the program design through reuse. An advantage here is that the system does not have to make perfect suggestions. If the system suggests 3 different possible components and only 1 is useful to the developer, the goal is still mostly achieved, and the system can use the feedback to improve further suggestions. The toughest parts of this technique are to understand the code and comments well enough to make relevant suggestions, and to avoid suggesting solutions that the developer already knows very well. These problems are still difficult to solve in computer science, but worth attacking. |
