.
FRDCSA | internal codebases | Architect
Homepage

[Project image]
Architect

Architecture Diagram: GIF

Jump to: Project Description | Parent 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)".

How does architect work? Well, it is a rather large problem domain, but as usual we only intend to make headway towards the problem - only enough headway that leads us to either a better solution on our own or until we find a research solution.

But, here is some thinking. Based on functionality, etc, as well as theorem proving capabilities, architect can plot out potential applications and generate NL summaries of these applications. The user can then initiate new focused studies or review existing plans, much like the corresponding methods in radar.

When a plan is approved architect creates plans to assemble the necessary components for the newly envisioned system. It thus naturally interfaces with functionality of boss in creating and managing new projects.

Capabilities

  • Develop radar architecture using Rational architect.
  • architect should contain information on how to do things freely.
  • Looks like architect needs to be refactored.
  • architect is a semi-automatic system, and as such, we can have it interact iwth users to determine goals/needs, etc.
  • architect should use game tree search and search out what should be developed based on all knowledge and estimation.
  • architect should understand the relations between the software systems, formally.
  • http://search.cpan.org/recent very useful to radar, architect, etc. Give most recent perl packages per day, lots.
  • 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 can review unimplemented capabilities from internal codebases and locate coresponding external codebases to do the work.
  • Broaden architect's related system functionality to have ways that it is related.
  • Build a classifier for architect that concerns which software belongs in which system (or maybe in boss)
  • 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.
  • 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.
  • Set up saving models for architect's functionality classifier.
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • Use architect to generate systems for as many real wrold uses of our software - for instance - roommate management system, etc.
  • By connecting architect's automatic feature generation to its automatic functionality classifier, you could build some pretty interesting systems.
  • boss/architect should support most of those metrics in the Schaums system. Could use pse for scheduling?
  • cso/ architect packager should measure demand.
  • 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.
  • 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.
  • architect should use quac for question answering over capabilities: how can I edit FSMs?
  • architect: http://citeseer.ist.psu.edu/directory.html
  • write a function that uses architect to do a choose from emacs between systems related to the system in the cwd directory
  • new functionality s.t. all API are indexed, i.e. in 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.
  • Integrate architect into the fweb2 system.
  • 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.
  • Develop the ability to automatically infer plans based on statements. For instance in the above statement: <<<Develop 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
  • architect - Ability to determine author based on writing style. Could this be as simple as a classification based on a training set?
  • 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.
  • 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
  • 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.)
  • architect should support reasoning about releasing these files.
  • 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.
  • Perhaps architect can use a programming specification language
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • If two systems are mentioned together, it could be the case that a relation for architect is present.
  • 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.
  • architect the entire study system first - before starting writing any part of it.


This page is part of the FWeb package.
Last updated Sat Jan 16 13:32:06 EST 2021 .