# Evaluation Report
## Summary of Evaluation
Overall, team 7 created two informative and insightful views for TeXstudio. Their views highlight the core functionalities of TeXstudio and facilitate our understanding of this complex system architecture. The scenarios provided by team 7 are also thoughtful, and these scenarios clearly illustrate the workflow of some core functionalities.

However, there is still some room for improvement for these views.

One noticeable weakness of the functional view is created by the claim that TexStudio's architecture style is MVC. Admittedly, most of the components of TexStudio can be classified as either Model, View, or Controller, but Qt Widgets cannot be classified as either Model, View, or Controller. Since Qt Widgets are important components for TexStudio, the failure to classify Qt Widgets as either Model, View or Controller casts doubts on the validity of the claim that TexStudio's architecture style is MVC. Since this claim is the foundation of the functional view, the claim's validity should be upheld. Therefore, team 7 could consider splitting Qt Widgets into different sub-components and move these sub-components to either Model, View or Controller. This change can potentially remove the noticeable weakness from the functional view.

For the informational view, it would be helpful to include some extra data flows in the existing diagram; these extra data flows should indicate what would happen if the system receives invalid inputs. Handling invalid input is also an important aspect of the information view.

Furthermore, it would be helpful to readers if the informational view could complement the workflow of the procedures mentioned in the functional view. Such complement can give readers a more holistic understanding of TexStudio's architecture.

## Functional View
* **General comment:**
The component diagram is consistent with the sequence diagram. These two diagrams complement each other and help us understand the functional responsibilities of each component. However, it would be better if they could specify which components belong to TexStudio and which components belong to Latex. Right now, these components are mixed together.
* ***Question:** What does the editor in the component diagram refer to, and why is the editor classified as a GUI (view)?*
* **Answer:** Editor refers to the editor view of TeXstudio. That name might be somewhat misleading, but the editor here is only the view that reflects the updated state of the system after the system processes user inputs.
* **Comment:** It is better to rename the entity as EditorView or simply system view, so that its functionality is clear.

* ***Question:** Does the persistence component refer to the persistence service from the OS?*
* **Answer:** persistence component refers to the persistence service from OS or remote servers
* **Comment:** it would be great if the team could clarify that the persistence component can refer to the persistence service from the OS or the persistence service from remote servers. The team did not make such clarification in the element catalog and the diagram. It would be better if the team can clarify this information in the element catalog or in the diagram.

* ***Question:** Since Qt is a dependency (analogous to JavaFX to JetUML), is it necessary to analyze it for architecture and include it in the functional view?*
* **Answer:** Qt is analyzed because it is important in the MVC structure. It is the connector that handles interaction between view and controller.
* **Comment:** connector is not a component for the MVC structure. Maybe there are other architecture styles that better fit the application's structure. Maybe the Qt widgets can be divided into sub-components that belong to either Model, View or Controller. The team could explore these two directions.

* ***Question:** How does the Qt widget interact with the controller?*
* **Answer:** The Qt widget receives events from the view and checks for the type of the event. It then passes different types of events to corresponding controllers.
* **Comment:** no comments
* ***Question:** Why is the Qt widget not a controller as it is able to put data into the model directly?*
* **Answer:** It can be a controller but it isn't always a controller. In most cases, it passes events to respective controllers. The only cases where it directly interacts with the model are inserting texts and selecting texts. Therefore, there are two ways to achieve MVC (Qt widget being the controller or Qt widget pass events to other controllers) in this project, but only the approach where Qt widget acts as a connector is presented in the component diagram.
* **Comment:** The answer clarified how MVC is achieved in different ways as well as the role of the Qt widget. It is a bit confusing that Qt widget is treated as a connector in the functional component diagram but still provides the function of controlling as it is connected to Editor data (model) with interface `update()`. It might be clearer if the team could replace Qt widget with two sub-components where one sub-component is a controller, and the other component is a connector.

* ***Question:** Is the Previewer part of the GUI (view)?*
* **Answer:** No, it appears only when we build and preview. It appears as a different window and doesn't provide any functionalities.
* **Comment:** The Previewer is part of the view in the MVC style but it's separated from the GUI (view) as it's only presented when Previewer is required by the user. The question was clearly answered, but it would be better if Previewer in element catalog is expanded with a bit more details such as what they answered to the question.

* ***Question:** User-defined macros will be handled by the script engine, but when the macro is defined in the latex file in the editor, does the macro also go through the parser?*
* **Answer:** It does not go through the parser. It follows the pipeline that reads and saves it. It goes to the script engine to be processed instead of going to the parser.

* ***Question:** What’s included in the Editor data component?*
* **Answer:**: The plain text received from the editor and the compiled macros from the script engine are all stored inside the editor data.
* **Comment:** no comments

* ***Question:** We know Latex heavily relies on external libraries, such as “\usepackage{amsmath}”. Which components are responsible for handling external libraries/dependencies?*
* **Answer:** They mentioned it’s part of the latex functionalities instead of TexStudio's and they didn’t think too much of it.
* **Comment:** The latex parser and script engine all seem like the original functional component of Latex (not TextStudio). It would be better if they make it clear which components are inherent to Latex and which components are specific to TexStudio.

## Scenarios
### Scenario 1
* ***Question:** This a follow up question to a question for the functional view. Previously we mentioned the macros are parsed by the script engine. Can you clarify what does Qt widget do? Does it directly send the input to the script engine? How does it know if a single key input is a script?*
* **Answer:** For each key typed, the Qt widgets will call the script engine to check if it’s a user-defined macro. And since the macros are defined in the beginning of the file, the script engine checks only for texts written before the clause “\begin{document}” for user macros. And the parser will parse the text afterwards.
* **Comment:** this explanation makes sense, but it's still a bit confusing as we still don't know what is the input from the Qt widget to the script parser. If it is just a key event, then, according to the diagram, the script engine does not have access to the plain text data, we would like team7 to clarify how does the script engine know this single key event is a script.

### Scenario 2
They demonstrated how TexStudio connects to a remote language tool to benefit from the grammar checking and other functions of the language tool.
* ***Question:** Is the language tool a built-in component for TexStudio?*
* **Answer:** No, it’s an additional feature that should be configured by the users themself.
* ***Question:** But in windows, TexStudio does provide grammar checks.*
* **Answer:** We are not sure about Windows, but by default, the Linux version does not have this feature.
* **Comment:** It’s a very nice demo, which gives us a better idea on how each input is handled by the TexStudio (or language tool, we are not so sure which log we were looking at). However, we don’t know where this language tool fits in the big picture. It would be better if the team could clarify the role of the tool in their AD.

## Information View
* ***Question:** How does the system handle excessive information latency? For example, if the plaintext input or TeX file input is large, how long does it take for the user to get something in the preview file*
* **Answer:** The preview format file needs to wait for TexStudio to finish parsing the whole input at once. There is no partially parsed information in the preview file. As a result, the larger the input is, the longer the latency to generate the preview file will be.

* ***Question:** According to the Gane Sarson Data Flow Diagram presented by Team 7, there are two data stores involved to hold temporary files produced in the process of generating preview for a plain text from the editor. The two data stores are local directories on the file system that texStudio is deployed on. Then we have a question regarding file key-matching on how the system handles the case when two .dvi files are of the same file name.*
* **Answer:** Team 7 mentioned that these data stores are created per editing file, and along with one key per existing file in the system. It is impossible to have identical file names in the same directory. The lifecycle of temporary files in D1, temp file store, gets deleted once process 3.0's compilation to DVI finishes. Moreover, the lifecycle of data stores lives with the plain text file that is currently being edited. According to team 7, the two data stores expire as the plain text is deleted or saved.

* ***Question:** Following the previous question, does D2 Preview File Store work in the same way as D1 in terms of the life cycles of files stored in D2?*
* **Answer:** Team 7 introduced D2 also as a directory on the file system which serves as a temporary storage. By the time the preview file is ready, the file would be stored and kept in the D2 directory, but it may expire with directory when the current working plain text file is closed. How files with identical names are handled here was not further explored by team 7.

**General Comment about Information View**
Information view is presented in a Gane Sarson Data Flow Diagram to describe the data flow among different proxies specifically for preview. It mainly focused on the transfer of data within and outside of the system and omitted the details on how these processes are invoked. We think this is a good level of abstraction, since this abstraction makes the view focus on addressing the data flow concern relevant to the information view. However, it would be better to complement functional view with the informational view and present the omitted details there.

Furthermore, the informational view does not address the concern where received inputs are not valid or are of poor quality. It would be better to add into the data flow diagram some extra data flow illustrating what happens if the inputs possess invalid information. For example, if the plain text does not respect the format of Latex, which process would detect the issue, and how will it handle it? If the text file input is corrupted, which process would detect the corrupted file, and how will the process handle it?

Lastly, team 7 does not provide a scenario for their informational view, and it would be better to provide one to help us understand the detail of data flows in the system.