Given that the usual activities of our group is heavily dependant on Model Transformations, be it from UML or any other model description language, it has become of extreme need the existence of a library to reduce the overhead of developing tools that relies on such operations.
This project is thus an attempt to provide the infrastructure and functionality needed by our future projects on performing model transformation routines. In software engineering terms, this kind of project is often called a Software Development Kit, since its target is not the end-user, but the developer himself. Hence, the name: UnB Dependability Analysis Software Development Kit (UnB-DAK, for short).
For building and dependency management we use Gradle (https://gradle.org/), which merges the better worlds from ant
and maven
, on a simple functional, typed, scripting language based on Groovy.
So, to starters, it is recommended the installation of gradle on both the machine and eclipse (or IntelliJ), although the machine one is not necessary since the project already comes with a command line tool gradlew
(or gradlew.bat
, for windows users) that carries all the gradle engine and its functionality.
To import the project for development under Eclipse, here are some basic steps:
- Clone the project;
- Run
./gradlew eclipse clean build
from the command line (always on the project folder). This is necessary since the.classpath
and.project
files are NOT on version control; - Open the eclipse and install the gradle plugin (http://marketplace.eclipse.org/content/gradle-integration-eclipse-44);
- Import the project to workspace using the
Gradle Project
option and then:browse to the folder -> click the Build Model button -> Finish!
To build the project, open the command line tool, head to the project folder and type:
./gradlew clean build
To distribute the library, we need to put together all the dependencies on a single .jar. To do that, simply type from the command line:
./gradlew clean fatJar
where the .jar will be put under /build/libs/
. With the "fatJar" in hands, one can import it to the tool he/she is developing, and be able to consume our APIs. In future versions we plan to put it under maven management so people can import it more easily, through dependency management software (such as maven, ivy, and of course, gradle).
We have adopted the Git Flow versioning pattern (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow/), which is basically a branch naming standardization. This makes for a nice versioning tree and is a must when development happens with different versions and contributors at the same time.
We then recommend the use of Source Tree (https://www.sourcetreeapp.com/) as a versioning management tool. Its interface is quite straight forward and has a great conflict management. After you clone the project using the Source Tree, please make sure to click on the top rigth-corner button Git Flow and then ok, which will set your project to use the versioning convention we have adopted here.
And be aware, commits to master
should only be done when a STABLE version of the project is reached.
src/main/java
: holds the project modules and APIs. The package naming convention is not set yet, so we are open to suggestions. There is already one API that kind of teaches how we should proceed. You can find it at:br.unb.cic.les.dependability.transformations.from_uml.IOD2PRISM.java
;src/main/resources
: holds the usual resources one would use at runtime; it can be a uml metamodel, or project configuration flags, or anything else (it will grow with time);src/test/java
: here should be put classes to test the APIs created atsrc/main/java
(also, Gradle already looks at this folder for unit tests with JUnit). There is one already that shows how to use the API mentioned above; it is in:transformations.from_uml.IOD2PRISM_Test.java
src/test/resources
: resources that the tests need to be able to run the tests.
Obs: note that src/test/
files will NOT be added to the final .jar.
Dependability@cic.