# EDOM - Project Increment 2


## Possible modifications to the Xtext-generated grammar ##

In this project there was a mandatory modification to the Xtext-generated grammar, related to the use attributes of the type **Date**:

- **String to Date and Date to String Conversion:** The Xtext file generated for the Requirements DSL does not come with a conversion from String to Date, or Date to String. The auto-genmerated file even comes with a comment suggesting to create an *IValueConverter* method to convert the Date to String, and vice-versa. Considering this, it was created the **RequirementsDSLValueConverter** class, containing two methods:
	- **toString**, with the objective of converting Date objects to a String, following a yyyy-mm-dd format;
	- **toValue**. with the objective of converting a String following the format yyyy-mm-dd into a Date object;

Other modifications could be applied, in order to simplify the preview of a model of this specific project: i.e., the **Requirement** contains a **Version**, which is represented by **3 values: major, minor and service.** All this values are int values, and are **meant to be read *major.minor.service*-** considering this, it could be made a **modification** to ensure that, inside a **Requirement** instance, the **Version** would be represented following a *major.minor.service* structure instead of the current representation. However, this was not implemented but it is a change that can be made pretty quickly and is being thought of.


## Requirements DSL Formatting ##

The formatting of this DSL project needed to be slightly adjusted - although there was already a formatting for the **Model** and the **Requirements Group** entities from the Xtext-generated project, there were none for the **Requirement**, **Comment** and **Version** entities - this being stated, it was needed to add a formatting to the entities that did not had one, and the auto-generated formatting needed to be reviewed in order to achieve what was the objective of this formatting.

The formatting of the different entities had the objective of facilitating the preview of a **Requirements Model**.

The applied formatting consists of, to a certain entity, guarantee that all its attributes are aligned and separated by a new line. If a certain attribute is an instance of another entity, then the formatting should ensure that occurs a new indent, and from there it should be presented the presentation of said entity.

For example, applying the formatting to this dsl

```
Model{title GorgeousFood groups{ RequirementsGroup "User Requirements" {description "A group of user-related requirements of the Gorgeous Foods App" id rg0000000 requirements {Requirement{title "Req01" description "Teste" type FUNCTIONAL priority MEDIUM author "RuiBarbosa" created "2019-06-09" id rq0000000 state NEW resolution INVALID version Version { major 1 minor 1 service 1 } comments{Comment{ subject "test" body "it's a test" author"Mario" created"2010-03-03" }}}}}}}
```

should return the following result

```
Model{
	title GorgeousFood
	groups{
		RequirementsGroup "User Requirements" {
			description "A group of user-related requirements of the Gorgeous Foods App"
			id rg0000000
			requirements {
				Requirement{
					title "Req01"
					description "Teste"
					type FUNCTIONAL
					priority MEDIUM
					author "RuiBarbosa"
					created "2019-06-09"
					id rq0000000
					state NEW
					resolution INVALID
					version Version { major 1 minor 1 service 1 }
					comments{
						Comment{
							subject "test"
							body "it's a test"
							author"Mario"
							created"2010-03-03"
						}
					}
				}
			}
		}
	}
}
```

## Requirements DSL Unit Tests ##

The Unit Test on this project consist of ensuring that the model created representing the DSL follows the syntax of the previously referenced DSL.

If the syntax of the presented model is well written, the test will pass; if not, the test will fail.

The Unit Test are quite simple, but straight to the point. Considering this, the unit tests are considered sufficient to the project.


## Solution Analysis ##

The created mwe2 workflow consists of reaching a set of objectives. The objectives were:

 - Reading a DSL file into memory;
 - Applying validations to the model;
 - Applying the formatter;
 - Saving the DSL file;
 - Generating a graphical diagram of the DSL file.

The new workflow consists of two main components, each one responsible of handling a different set of objectives:

 - A component that imports, valides and saves a model from a file;
 - A component that generates a Requirement Diagram from the previously loaded dsl file.

The first component is based on the solutions used on the first increment of this project (primarly the SaveModel and the GenerateDot solutions).

The second component is based, once again, on the Generate Dot - this component imports the loaded dsl file and generates a diagram according to the model.

Although there are some differences between this approach and the one used on the first increment of this project, the main differences focus on the simplicity and modularity of using mwe2 workflows - the mwe2 workflow is easy to build using externally developed classes, what makes this solution more modular and extremely more simple to analyse and understand.