{"id":17,"date":"2023-07-08T17:47:53","date_gmt":"2023-07-08T15:47:53","guid":{"rendered":"http:\/\/www.janradeck.de\/wp_dsl\/?p=17"},"modified":"2023-07-25T12:56:05","modified_gmt":"2023-07-25T10:56:05","slug":"remoteadaptergenerator","status":"publish","type":"post","link":"https:\/\/www.janradeck.de\/wp_dsl\/de\/2023\/07\/08\/remoteadaptergenerator\/","title":{"rendered":"RemoteAdapterGenerator"},"content":{"rendered":"\n

This is a simple project that I did in JetBrains MPS. Since I very much like working with MPS, I’ve written this blog post to document it. I hope that it may find it useful if you’re starting with MPS.<\/p>\n\n\n\n

I have tried to include as many illustrations as possible.<\/p>\n\n\n\n

Motivation<\/h2>\n\n\n\n

While developing 2D algorithms, I found the debugging to be a real pain. It’s easier to see a curve on a display than to make sense from a (lengthy) set of coordinates.<\/p>\n\n\n\n

Requirements<\/h2>\n\n\n\n

Functional requirements<\/h3>\n\n\n\n

A set of methods, constructed from the primitive commands that the display offers, eg. “drawPath”, “clearDisplay”.<\/p>\n\n\n\n

Quality requirements<\/h3>\n\n\n\n

To be able to draw curves while in the debugger. The display needs to be updated even if the application under test is stopped.<\/p>\n\n\n\n

Communication only needs to be one way: From the application under test to the display.<\/p>\n\n\n\n

The number of calls to the draw method will be small. Therefore performance is not an issue.<\/p>\n\n\n\n

Solution<\/h2>\n\n\n\n

Create a stand-alone process with a JSVG canvas. This will guarantee that the display will be updated even if the application under test is stopped.<\/p>\n\n\n\n

Use HTTP to connect the application under test to the display. This is simple to write and simple to test (e.g. via a web browser). The connection can be established “on demand”.<\/p>\n\n\n\n

Solution design<\/h2>\n\n\n\n
\"\"
Client and server and their components<\/figcaption><\/figure>\n\n\n\n

The client issues remote commands, sends them via HTTP to the server, where they are translated into draw commands. The remote commands and the corresponding command handlers would be defined using a DSL.<\/p>\n\n\n\n

If you open the following URL in your browser<\/p>\n\n\n\n

http:\/\/localhost:8000\/draw?message%3DHello%20World%21%26path%3DM%20100%2C100%20L%20100%2C200%20200%2C200%20200%2C%20100%20z%26style%3Dfill%3Anone%3Bstroke%3A%23000000<\/p>\n\n\n\n

the server will display this image:<\/p>\n\n\n\n

\"\"
The server displaying an SVG path<\/figcaption><\/figure>\n\n\n\n

To generate the query, I’ve used a simple online tool to URL-encode the parameters.<\/p>\n\n\n\n

The development process in detail<\/h2>\n\n\n\n

Step 1: Hand-writing a prototype solution<\/h3>\n\n\n\n
\"\"
Hand-writing a prototype solution<\/figcaption><\/figure>\n\n\n\n

A prototype client and server were written by hand, using an IDE.<\/p>\n\n\n\n

Step 2: Creating the concepts in MPS<\/h3>\n\n\n\n
\"\"
Creating the concepts in MPS<\/figcaption><\/figure>\n\n\n\n

Step 3: Transferring the JAR files to MPS<\/h3>\n\n\n\n
\"\"
Transferring the JAR files to MPS<\/figcaption><\/figure>\n\n\n\n

The code generated by MPS would refer to classes and methods from the hand-written solution. Therefore JAR files, containing this part of the prototype application need to be imported into MPS.<\/p>\n\n\n\n

Step 4: Creating templates in MPS<\/h3>\n\n\n\n
\"\"
Creating templates in MPS<\/figcaption><\/figure>\n\n\n\n

Now that the classes and methods are available in MPS, the templates are created. The hand-written code is used as a basis for this step.<\/p>\n\n\n\n

Step 5: Creating the model<\/h3>\n\n\n\n
\"\"
Creating the model<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

\"\"
The first lines of the model: Defining (global) constants and a first command<\/figcaption><\/figure>\n\n\n\n
\"\"
Defining a command that references a global constant<\/figcaption><\/figure>\n\n\n\n

<\/p>\n\n\n\n

In the definition of this command a global constant, styleBlue, is referenced.<\/p>\n\n\n\n

\"\"
Defining a command with a local constant.<\/figcaption><\/figure>\n\n\n\n

In the definition of this command a local constant, styleGreen, is defined and referenced.<\/p>\n\n\n\n

<\/p>\n\n\n\n

Step 6: Generating the source code<\/h3>\n\n\n\n
\"\"
Generating the source code from the model<\/figcaption><\/figure>\n\n\n\n

Client Business Logic (generated)<\/h4>\n\n\n\n

The following code is generated for the three client commands shown above. The code uses an abstraction layer QueryGenerator to specify the URI, add parameters and execute the query.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Server Business Logic (generated)<\/h2>\n\n\n\n

The first block defines the global constants and registers the Request Handler classes.<\/p>\n\n\n\n

\"\"
Server code: Defining global constants and adding the RequestHandler classes<\/figcaption><\/figure>\n\n\n\n
\"\"
Server code: A RequestHandler that references a global constant.<\/figcaption><\/figure>\n\n\n\n
\"\"
Server code: RequestHandlers that defines a local constant.<\/figcaption><\/figure>\n\n\n\n

Implementation details<\/h2>\n\n\n\n

Structure aspect<\/h3>\n\n\n\n
\"\"
Simplified class hierarchy<\/figcaption><\/figure>\n\n\n\n
\"\"
Class diagram for StringValue, etc.<\/figcaption><\/figure>\n\n\n\n

I have introduced the Interface StringValueTraits<\/em>. The scope of StringParameters makes them unique, if they are unique for the ClientMethod. StringConstants, on the other hand, can clash between different instances of CommandListVersion. Therefore the version of the CommandListVersion is appended to the declarationName.<\/p>\n\n\n\n

References and reference constraints<\/h4>\n\n\n\n

I want to define (client) methods with (string) parameters. In these method definitions I want to call draw methods and provide these method calls with values. A value may be<\/p>\n\n\n\n