search

discipl / flinteditor-mps

GNU General Public License v3.0
2 stars 3 forks source link

Validate module overview #221

Closed cblazo closed 2 years ago

cblazo commented 2 years ago

Based on the sequence diagrams and https://dslfoundry.com/mps-technology-stack-project-concepts-and-openapi-relations-explained-visually/, I created a abstract module overview of the Flint IDE. Did I miss any modules in the software?

image

image

TristanAlbers commented 2 years ago

@cblazo

Feedback Model 1

DSLFoundry

Though im not familiar with this specific model and have some questions about it we should use it an quote The DSLFoundry as an authority on this matter. Some parts i don't quite follow on the DSLFoundry's part is the SModel, OPENAPI and Generated Code part. An SModel is an MPS model defined in "Java code". This is part of the OPENAPI library. Furthermore OPENAPI (and thus SModel) may seem like Java code but are actually DSL themselves. They need to be converted to Java code (I figure this happens when you build the project) before they can be used. Besides this the 'Generated Code' part having only a link to structure is a bit misleading since everything inside MPS (Behaviour, Structure, Constraints) is converted to plain Java for use. These are my observations, im interested to know more about this because it might be a matter of interpretation of the model.

Flint specific

The transformers, services and clients are different from behaviours like LawSource_Behaviour and Act_Behaviour but are still placed inside the 'behaviour' folder since it adds functionality to the Language behaviour. I would suggest placing them inside the 'behaviour' block.

Futhermore i don't think we have clearly defined clients inside the Flint Language on the MPS side. At least i am not able to find any files named 'Client'.

Lastly i don't see anything that mentions the more low level languages used to assist Flint. We ofcourse have the Flint Language for interpretations but also the LawSource Language for source and the Flint.plugin model for extra editor functionalities. I don't know if this is intended or not.

Feedback Model 2

PublicationParserSelector

This directly interfaces with ParserService to gather the parsers.

Editor

I believe this can be removed. The only block without a link would be ParserService which should be linked to PublicationParserSelector as stated above.

FileChooser

FileChooser is linked to DocumentStructureService instead of VersionBehaviour. (FileChooser is a part of VersionBehaviour so the current link is also technically correct)

BaseNsxTextlineClient

NsxTransformingClient has a reference to BaseNsxTextlineClient and makes calls to it but does not extend it. Maybe position BaseNsxTextlineClient a bit more to the right to show this distinction.

cblazo commented 2 years ago

Thanks. Regarding model 2, I made the changes you suggested. For model 1 I am not sure how it should look. I think we can indeed leave the leftmost elements out, and just zoom in on the Flint plugin. Could you help me make improved diagrams that helps us look ~2 levels into the black box of the Flint plugin?

I got this far: 1) Flint plugin contents: However, it's unclear to me what each language and solution means (besides Flint and LawSource) image

2) Language components: The colors do not mean anything but help readers connect them with the ones in the view of (3) image

3) A zoomed in view of the Editor file of LawSource. What components do the editors and behaviours of the other Languages (especially Flint) look like? image

TristanAlbers commented 2 years ago

  1. It looks complete, i'll look a bit more into the dependencies of each language/solution so you can also see which language/solution uses the other ones. I'll draft an example diagram of what i mean. Im also curious what the specific use of this model should be. I assume an complete overview of all the languages/solutions in the Plugin right?

  2. This is correct, you could even change the "Service, Clients, Transformers" into a single block named "Custom Behaviour Code" and it would be applicable to every MPS language

  3. I'll draw up an example model of Act_Editor in the same style and come back to you to check.

cblazo commented 2 years ago
  1. The goal is to show and explain the 'modules' of which the complete Flint plugin consists. If it is relatively easy to add dependencies/connections, that would be nice, but it is less important.

A relevant question for the report is: What is the role of each module?

TristanAlbers commented 2 years ago

Regarding diagram 1, Something like this? Contains all languages and solutions with their respective links to eachother.

Untitled Diagram drawio (1)

TristanAlbers commented 2 years ago

@cblazo Regarding point 3 i opted to first make a sequence diagram to more clearly see which classes/functions are called by the editor resulting in the diagram below. Is this something i should continue with or are the individual classes with connecting lines enough? Also, this diagram only shows what happens when the editor is openend. Depending on what actions a user takes in the editor a multitude of flows can be executed. I'll leave the decision up to you for futher steps.

image

cblazo commented 2 years ago
  1. This looks amazing and can go directly into our report, could you provide some descriptions of each element?
  2. The sequence diagrams and component diagrams are a great resource for communicating with technical stakeholders. So this would be great for documentation, but has less priority than (1).
TristanAlbers commented 2 years ago

Descriptions

Solutions

Languages