.
FRDCSA | internal codebases | Architect

Architect Architecture Diagram: GIF

Jump to: Project Description | Capabilities

Project Description

The architect is the next logical step of the radar/packager tool chain. radar is a tool for automatically finding software. packager is a tool for automatically packaging software. Now, architect is a tool for automatically applying software - that is, for planning on how the functionality of a given piece of software could be automatically applied to a certain problem domain. For instance, it seems fairly evident that we should have Q/A technology working with man pages (like the umich demonstration). architect would be challenged with recording or discovering this application and for semi-automatically applying it. So architect is obviously the fulfillment of the initial charge to "Cluster (radar), study (packager) and Apply (architect)".

Capabilities

• architect should support reasoning about releasing these files.
• architect should use game tree search and search out what should be developed based on all knowledge and estimation.
• architect can review unimplemented capabilities from internal codebases and locate coresponding external codebases to do the work.
• Looks like architect needs to be refactored.
• The part of cso or architect that determines how much has been accomplished or how functional the software is should use a high level language.
• architect should understand the relations between the software systems, formally.
• architect: http://citeseer.ist.psu.edu/directory.html
• http://search.cpan.org/recent very useful to radar, architect, etc. Give most recent perl packages per day, lots.
• architect the entire study system first - before starting writing any part of it.
• Create a standard set of things that happen whenever new functionality is requested, including pattern matching searches and feedback from implementation programs like code-monkey and architect.
• We need to have a place that indicates the most important software to package. This would be the architect system. Strange problems, arent' they, but we must move.
• Set up saving models for architect's functionality classifier.
• By connecting architect's automatic feature generation to its automatic functionality classifier, you could build some pretty interesting systems.
• architect should estimate the time it will take to complete certain tasks. For instance, manually classifying such and such, and then compare that to the expected benefits, etc.
• Develop new system for rolling interfaces to systems. It's not quite packager, but it seems related to architect.
• Perhaps it should determine whether all packages have been uploaded. This seems more like predator. Since architect is more responsible for capabilities matching and so forth. Takes lists of capabilities and tries to match them.
• We can use current problems, classifying them by type, in order to determine the limits of our existing systems and plan for solving these problems with architect.
• Keep some database of solutions. I guess this is what architect does? But we need something more general. Example, if I can't program, and need help getting started, a good thing to do is to rebuild the fweb stuff.
• architect - Ability to determine author based on writing style. Could this be as simple as a classification based on a training set?
• architect can have formal models of solutions, for instance, an "expert system", and can take inventory of the problems (from the database), and can even perhaps match attributes of the problems (in so much as we can model the problem relationships, or as can be extracted from the definition). However, the very indication of the importance of the problem will help to order them for expansion.
• Build a classifier for architect that concerns which software belongs in which system (or maybe in boss)
• Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
• Estimate which phrases belong to certain projects (I guess naive bayes sort of already does this, but we could employ nounphrase or maximum common substring, etc. Indeed many algorithms will have specific places of application and architect could work with perform and code-monkey to implement that.)
• Not only should kbfs know what file a given request matches too, but architect (or something) ought to know which functions or objects implement the described capabilities.
• diamond is (right now) really just a hack. architect should know which systems are serious and which aren't, and also know whether there are known successors that might one day become incorporated.
• boss/architect should support most of those metrics in the Schaums system. Could use pse for scheduling?
• Ultimately generix ought to maintain or use the entire dependency information. Would be of use to projects like architect as well.
• Use architect to generate systems for as many real wrold uses of our software - for instance - roommate management system, etc.
• WRite system that helps me figure out where functionality belongs. Just kidding, this is already part of I think architect, or maybe boss.
• architect should use quac for question answering over capabilities: how can I edit FSMs?
• architect should contain information on how to do things freely.
• Within architect, we must keep an ordering of sorts that applies to the systems. Because, now with sorcerer giving us access to a large number of systems, without having to Spider yet, we could conceivably generate large lists of items that need to be packaged, and get people involved with the packaging.
• new functionality s.t. all API are indexed, i.e. in architect
• Some features audience needs, before I forget: should model who knows what, and more specifically, who knows which agents are programs. Also, if there is no danger in admitting to being an agent, the agent should then work with the user to determine what are the weaknesses in the agents dialog. This feedback should be sent to developers, or architect.
• architect is a semi-automatic system, and as such, we can have it interact iwth users to determine goals/needs, etc.
• architect can be so kind as to search Debian packages, as well as online systems for the capabilities we need, using some kind of matching algorithms.
• If two systems are mentioned together, it could be the case that a relation for architect is present.
• Develop the ability to automatically infer plans based on statements. For instance in the above statement: <<radar architecture using Rational architect.>>>, it is clear to us that at least two tasks have been defined. Develop the radar architecture. and Download and install Rational architect
• Develop radar architecture using Rational architect.