.
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

  • Broaden architect's related system functionality to have ways that it is related.
  • write a function that uses architect to do a choose from emacs between systems related to the system in the cwd directory
  • Integrate architect into the fweb2 system.
  • 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.
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • 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 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 - Ability to determine author based on writing style. Could this be as simple as a classification based on a training set?
  • 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.
  • 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?
  • architect should contain information on how to do things freely.
  • Use architect to generate systems for as many real wrold uses of our software - for instance - roommate management system, etc.
  • architect should use quac for question answering over capabilities: how can I edit FSMs?
  • 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.
  • Should break up books into functionality (like CCM) and then verify using our kbfs/architect requirements traceability mappings.
  • Build a classifier for architect that concerns which software belongs in which system (or maybe in boss)
  • 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.)
  • 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.
  • By connecting architect's automatic feature generation to its automatic functionality classifier, you could build some pretty interesting systems.
  • Set up saving models for architect's functionality classifier.
  • architect the entire study system first - before starting writing any part of it.
  • http://search.cpan.org/recent very useful to radar, architect, etc. Give most recent perl packages per day, lots.
  • architect: http://citeseer.ist.psu.edu/directory.html
  • 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 should understand the relations between the software systems, formally.
  • 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.
  • Looks like architect needs to be refactored.
  • architect can review unimplemented capabilities from internal codebases and locate coresponding external codebases to do the work.
  • 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.
  • Perhaps architect can use a programming specification language
  • cso/ architect packager should measure demand.
  • 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: <<<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
  • 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.


This page is part of the FWeb package.
Last updated Sat Oct 26 16:50:32 EDT 2019 .