The Problem
When first developing web applications, choosing a tech stack can be overwhelming. Even choosing your first language to learn can feel like a monstrous task let alone deciding on all of the components of a production application and how to make all of the components talk together. In this post, I will propose an intelligent agent to help developers architect basic web applications. The ultimate system would take in business requirements and recommend architectural design patterns and specific technologies to implement. Though a worthwhile problem, the complexity of such a system would be in for a combinatorial explosion. For this initial proof-of-concept, we will assume the developer is out to build a web application that follows a straightforward Model-View-Controller (MVC) design pattern. It will also recommend a simplified version of all of the components involved. It will recommend a client-side language, a client-side framework, a back-end language, a back-end framework, and a database system. It will also describe how those components will interact and communicate.
A Solution
Overall, the agent will need to learn about all of the individual components in a web application, learn how all of the components relate, store these learned concepts and relationships for retrieval, gather requirements and constraints from the human user, and reason through its knowledge-base to come up with a solution. These major steps will be broken out into three subsystems and described below. This post will focus on some reasoning techniques I’ve studied recently, namely common sense reasoning and scripts.
Knowledge Acquisition and Storage System
The knowledge-base (KB) would be a semantic network of software development concepts defined as frames. This structured knowledge representation will provide the foundation for understanding. The initial state of the KB would be populated and heavily curated by expert software architects. This will give it a strong set of base cases for the searching and reasoning that will take place later. Through an automated natural language processing and web mining system, the agent would acquire more knowledge from online Q&A communities like Stack Overflow and Quora. It would also gather cases from technical documentation like might be found in README’s on GitHub.
Each of the major components to a web application will be represented by an action frame. By having a thematic role associated with each component, it will allow the agent to understand the relationships between the components and how they depend on each other. This will be especially useful when reasoning through the flow of data in the web application. This flow of data is how the components communicate. This flow of data and the functional relationships between the components will provide the basic building blocks for the scripts involved in the reasoning process.
In the particular domain of web application development, we can define a domain specific set of primitive actions. They could be derived from those predefined by the HTTP verbs (GET, POST, PUT, DELETE and so on) and standard database CRUD functions (create, read, update, and delete).
Some example action frames:
With these two frames, we can see how the data makes it from the database system to the view that the user will interact with. These frames can be used to define a script that enforces domain logic. Here, the view cannot talk directly with the model without going through the controller. The logic for this script is defined by the MVC design pattern. These frames, and the script that can be built with them, will aid the reasoning process. Once the agent has its initial semantic network built out, it can search the web for other examples that follow these same patterns, building on what it already knows.
There will also be an associated concept database with more traditional frames that define the different components of a web application in detail. This concept space, will contain languages and specific technologies. For example, it may contain ‘JavaScript’ which would be an instance of a ‘Programming Language’. Programming languages would have special relationships with other technologies like development frameworks. ‘jQuery’ could be an instance of a ‘Front-end Framework’ that is written in the ‘Programming Language’ ‘JavaScript’. This will aid the agent in understanding and reasoning through which components of the web application stack are compatible.
Interactive Conversation System
When a user comes looking for help building a web application, the agent will need to gather the information it needs from the user. This can be done through a natural language interface. If it were to be done through an online form, it could be cumbersome for the user because the form could be quite large and very sparse. The user will likely only provide a small amount of information about the system the user wants to build. From that small amount of information, the agent will need to reason through a proposed architecture.
The goal of the interactive agent will be to gather requirements from the user. These requirements will be used as constraints. These constraints will be used to satisfy the problem and also limit the search space.
Example questions the user could ask the agent:
“I’d like to use JavaScript as much as possible. Is there a tech stack where that is the only language I’d need to know? If so, what is it?”
“Can I used Python with MongoDB? How do I query MongoDB from Python?”
In the first example, the agent could start building out a semantic network of action frames for the proposed architecture. It will at least be able to set the front-end language and back-end language to ‘JavaScript’. It could then infer that all of the frameworks it suggests must support ‘JavaScript’.
Reasoning System
To reason through and recommend architectures from existing cases, the agent will use common sense reasoning and scripts. To come up with more unique and original architectures, the agent could use a combination of explanation-based learning and analogical reasoning (though this will not be discussed in this paper). Even though the agent would work just fine by using learning by recording cases and case-based reasoning for suggesting solutions based on existing examples, I would like to experiment with scripts as a way to infer what action frames are missing and what their values need to be.
Common Sense Reasoning
(Ashok Goel, 2016, https://www.udacity.com/course/knowledge-based-ai-cognitive-systems--ud409)
We’ve already talked through the frames and the foundations for understanding the agent will need. The next step is common sense reasoning. In the context of this agent, universal knowledge is unnecessary. It will just need to know and be able to reason through common web application scenarios. The principles of common sense reasoning still apply though. Reasoning will need to take place at several different moments during the agent’s journey. The first of which is when it learns from conversations on the web. The second is when it is trying to understand what the user is asking for. The third is when it decides on a solution to propose to the user.
If searching through Stack Overflow, it will need to identify concepts it already has stored and make inferences on new relationships it’s discovering. It may discover a post talking about JavaScript and front-end frameworks, two-concepts it is already familiar with. Someone may suggest a new framework, e.g. “you should check out React”. It can then identify ‘React’ as a new concept and store it as an instance of a ‘Front-end Framework’. In this case, even the knowledge acquisition step must apply logic and reasoning so the agent can learn. All of these concepts and their relationships exist to make the reasoning steps easier.
Scripts
The most critical part of this system is the agent’s ability to recommend architectures given a set of constraints. As I alluded to earlier, the concept of scripts could be exploited to do just this.
(Ashok Goel, 2016, https://www.udacity.com/course/knowledge-based-ai-cognitive-systems--ud409)
In the context of this agent, the ‘events’ are the actions that each component of the web application stack is responsible for. As was obvious in the action frames, each component is responsible for performing some action on data. It could be receiving data from some other component or maybe displaying data to the user. If a user of a web application performs an action, such as clicking a button, it will set off a series of events that may go from the view to the controller to the model and all the way back around again (in fact, the term ‘events’ is used by the web development community as well). To complete such a process, the data passes between all components of the web application’s tech stack. Since these actions cascade throughout all the components, it shows they are ‘causally’ connected. Because this is a real-world scenario, the web application acts as a scene in the world.
Looking at each proposed web application architecture as a script is a useful abstraction. For each valid architecture, such as MVC, a script would have to be created. It would need to be abstract enough to capture all common sequences of events that occur in a web application. So, if an instance of a script is causally coherent and all of the relationships of the underlying semantic network are satisfied, the web application architecture is valid. Said another way, if the data can flow from the user to the model and back again successfully, the proposed architecture would function properly making it safe to recommend as a solution.
Conclusion
To truly be useful, the agent would need to handle much more complex scenarios. There are many other architectural patterns that would need to be covered. There are also many more components to a web application than I discussed (you can get quite granular if you wanted to). What would be really exciting, but much more difficult to implement, is if this agent could architect an application given business requirements. The other components not discussed is how the agent would need to get creative if it does not have any existing cases that satisfy the needs of the user. Analogical reasoning could be helpful here as a way to come up with novel architectures. In general, it would be good to test the design proposed in this paper against one that uses case-based reasoning, explanation-based learning, and analogical reasoning. Regardless, if such a tool was built and worked well I know many young professionals would find it useful.
Works Cited
- "Commonsense reasoning." Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 19 August 2016. Web. 6 November 2016.
- "Create, read, update and delete." Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 27 October 2016. Web. 6 November 2016.
- "Frame (artificial intelligence)." Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 7 September 2016. Web. 2 October 2016.
- Goel, Ashok and David Joyner. Knowledge-Based AI: Cognitive Systems by Georgia Tech [Videos]. Udacity. https://www.udacity.com/course/knowledge-based-ai-cognitive-systems--ud409 Accessed 6 November 2016.
- Norvig, Peter and Stuart Russell. Artificial Intelligence: A Modern Approach. 3rd ed., Pearson, 2010.
- Poole, David and Alan Mackworth. Case-Based Reasoning. Cambridge University Press. artint.info/html/ArtInt_190.html. Accessed 2 October 2016.
- "Representational state transfer." Wikipedia: The Free Encyclopedia. Wikimedia Foundation, Inc. 31 October 2016. Web. 6 November 2016.
- Winston, Patrick. Artificial Intelligence. 3rd ed., Addison-Wesley Publishing Company, 1993.