There are several options that could be chosen regarding the architectural issue of how an ITS relates to the development environment used by students when writing their code. The first option is to build the ITS separately from the existing development environment. In this case, the student writes the code in the existing development environment and feeds the code to the ITS to get feedback and help. Proust (Johnson & Soloway, 1985) is one example of an ITS that uses this approach. The drawback of this approach is that the students must send their code to the ITS, every time they want feedback. After getting the feedback, the students must correct their code in the development environment and resend their code again to the ITS. This inconvenience may discourage the students from using the ITS.
The second option to build the ITS so that it provides the development
environment inside the ITS application itself. Then the students can write the code inside the ITS application directly and do not need to get their work from the development environment to get feedback.
This approach is better than the first one because the students are free from the hassle of sending their code to the ITS application. Some ITSs that use this approach for example are JITS (Sykes, 2007), J-LATTE (Holland, et al., 2009), and PHP ITS (Weragama & Reye, 2013). The problem with this approach is that more time and effort must be spent to develop the development environment itself. This development environment should also be able to find syntax errors that exist in the students’ code. In addition, the features provided in this new development environment may not be as rich as the ones provided in the existing development environment.
The third option that can be taken in developing the ITS is to integrate the ITS into the existing development environment. By using this approach, the student can use all the features provided by the existing development environment and the ITS can get syntax error information from the development environment. Then the ITS does not need to redo the work done by the compiler in the development environment.
Another advantage of the third approach (which is also true of the second approach) is that the ITS can observe the students’ work more easily. In this third approach, the ITS can capture the students’ code directly from the existing development environment editor, see the students’ actions as they try to solve the task, and if necessary modify the students’ code. The problem with this third approach is that it is only feasible if the development environment provides a mechanism for another piece of software to be integrated into it.
Fortunately, VS – the development environment that is used by the targeted student – provides mechanisms to allow new software to be integrated into it. This is called extending VS. For completeness, I briefly describe the three possible ways that can be used to extend VS, that is:
• Macros
Macros are the easiest way to extend VS. Using macros we can record and playback frequently-used sequences of actions. Macros are intended to be used as a tool to automate some tasks in VS instead of as a tool to create a new functionality in VS. Therefore it is not sensible to try to use Macros to implement an ITS.
• Add-ins
Creating an Add-in is another (historically older) way that can be chosen to extend VS. The code in an Add-in can access the Visual Studio object model and add new user interface elements to the IDE, such as tool windows, menu, option pages, etc. However there are some extensibility options that are not available through the automation object model or through standard VS IDE Services (Novak, 2008).
• Packages
The more modern way to extend VS is through Packages, also known as
VSPackages. Using a Package we can access all services, interfaces, and objects in the VS IDE. VSPackages are integrated to the Integrated Development Environment (IDE) and loaded as part of the IDE itself. Because of this deep integration, a VSPackage offers more power than an AddIn. Examples of extensions that can be done using VSPackages are: creating new menus, adding new commands, creating options pages, and integrating with the built-in tool windows such as the Error List and Properties windows. For these reasons, CSTutor was developed as a VSPackage.
Figure 4.6 (adapted from Novak (2008)) shows a high level view of the architecture of the extensibility platform in VS. The core IDE functions located in the bottom part of the Figure 4.6 can be controlled by Automation API and the Package API (Application Programming Interface). The Automation API, which is used by Macros and Add-ins, provides COM objects to use the IDE core services. On
the other hand the Package API, which is used by VSPackages, publishes the IDE core services in the form of hundreds of COM interfaces. The functionality offered by the Package API is much richer than the one in the automation API.
Both the Automation API and the Package API use COM objects. These objects can be used easily in the .Net world (through Add-ins or VSPackage) because of the .Net Interop Assemblies that exist in the VS SDK. On the top position of the Service access layer is the Managed Package Framework (MPF). MPF provides C# classes that can be used to provide the foundations of a VSPackage.
Figure 4.6 Visual Studio Extensibility Architecture Components.
The approach of integrating the ITS within the development environment has been previously used in PAT – an Add-in for MS Access (Risco & Reye, 2009). PAT is used to help students learn how to create forms and reports in MS Access. Because PAT is not used to help students learn to program, the approach of integrating CSTutor within a commonly-used, commercial programming development
environment (in this case VS) can be considered unique – something not found in any previous programming domain ITS.