While model-driven software development methodologies are still connected to non-agile approaches like the waterfall model, we aim to enable developers to use model-based evolutionary prototyping within agile software development techniques facilitating fast product increments through constant re nement. To reach this goal, we take advantage of the yEd diagram editor for creating, storing and updating graphical domain-speci c models. With a de ned transformation process carried out by a specially developed pair of Ruby tools, we rapidly generate working implementations from these models based on Ruby on Rails, a widely adopted solution for web application design. Our toolchain at hand, we demonstrate all steps required to provide executable browserbased applications from our descriptive domain models managed in yEd and suggest an agile software development approach.
Modeling in general and Domain-Speci c Modeling (DSM) are typically carried out within an approach-speci c model management environment, like Eclipse [1], Epsilon [5] or Gemoc [3]. In contrast, this contribution advocates to employ the diagram editor yEd (yworks.com) for managing DSM artifacts, in particular for model storage and update. By allowing users to develop models with a well-known tool, we can realize a light-weight modeling approach for occasional modelers as well as domain experts and in contrast to heavy-weight modeling with, e.g., Eclipse. yEd models for browser-based information systems are transformed through a well-de ned transformation chain into working Ruby on Rails (short Rails) implementations. Applications of yEd for modeling by computer and domain experts have been discussed already within software development [6] and ontologies [4], whereas [7], [2] and [10] deal with model-driven development of web based respectively mobile applications.
Our transformation chain involves two specially developed Ruby tools called Tibet and Tor. Tibet parses the domain-speci c yEd models and creates an inmemory representation used by Tor to render the required Rails code artifacts. This process includes several re nement steps programmatically de ned in the Ruby language and nishes with an executable application. We thus use Ruby as our transformation language. We aim to support developers implementing evolutionary prototyping within agile software development approaches supported by fast, model-based product increments, which can be easily customized.
This contribution builds upon preceding work covering conceptual data models [8] and model-driven design with yEd [9]. It presents a work still in progress, yet deployable. In Sect. 2 we explain some selected aspects of our DSM language mainly based on ER and EER concepts complemented with UML class diagram features. In Sect. 3 we discuss the transformation into a working implementation and suggest a possible agile software development approach based on our toolchain. Section 4 concludes the paper. 2
Before introducing our graphical DSM language, we take a brief look at yEd,
a customizable general-purpose diagram editor serving as a front end for our
model management. yEd provides a comfortable user interface that developers
can utilize to specify requirements in the form of graphical domain-speci c
models stored as XML-based GraphML (Graph Markup Language) text les. Fig. 1
shows a yEd screenshot depicting six noteworthy parts. The window in part (
Figure 2 shows an excerpt of our custom yEd palette for our DSM
language, for which we give an exemplary explanation. The upper part (
Attributes are modeled utilizing oval nodes as displayed in the middle part (
We use our language to specify an example application, a basic content
management system. The following description provides a short summary of some
selected aspects of the example model displayed in part (
For the content management system to work, we model some basic concepts like Site (a), Page (b) and NavigationEntry (c) as entity types with corresponding attributes and associations. In our scenario, the entity type Site may aggregate multiple Page instances and vice versa. Amongst others, the Page type holds a title (d) and a content (e) attribute connected via attribution edges decorated with semantic annotations (to be utilized in the transformation).
The content attribute is drawn with a dashed line making it optional, while the annotation r on the lower left side de nes, that it will be represented via a rich text editor when rendered on the user interface views. The re exive composite association as de ned for the NavigationEntry (f) type allows to represent a potential hierarchy of navigation entries, which may be aligned on the user interface views by position information stored via the GridPositionElement (g) enumeration type. During transformation, additional attributes are augmented to store name constants and language speci c translations. Our example also shows the inclusion of a module called UserMultipleOwned (h) by Page, Site and NavigationEntry inheriting required associations to the User entity type provided in another model le. Finally, (j) depicts a so-called supply relation between Page and Comment de ning, that if a Page instance is shown on the user interface views, the end user is able to create a comment. 3
The complete transformation chain consists of four main steps as depicted in
Fig. 3. Firstly, we use yEd to create and manage a descriptive domain-speci c
model based on our custom palette (
The Tibet API component provides an interface allowing developers to access
model information as done in the third step. Here we use our second specially
developed Ruby tool called Tor implementing the necessary transformation logic to
generate code modules by using speci c templates. These modules are integrated
unobtrusively into the derived Rails application instance and are complemented
by additional static modules shipped with Tor (
Tor outputs the application data model components consisting of roughly two parts. Firstly, so-called migration les are derived containing schema information in a domain-speci c language in order to initialize the database back end, in our case a Postgres SQL database. Secondly, Tor renders corresponding model classes based on the Rails ORM (Object-Relational Mapping) library implementing the active record architectural pattern. Tor also generates model validation and model access control layers as well as modules for re ection capabilities.
The application view components are also constructed from multiple generated les. On the one hand, Tor renders default HTML les, on the other hand, it builds JavaScript based front end views utilizing the React framework (reactjs.org) in conjunction with the jQuery (jquery.com) and Bootstrap (getbootstrap.com) libraries providing extended DOM (Document Object Model) manipulation features, user interface controls and layout mechanisms. As Tor builds JavaScript modules using the modern ECMAScript 2015 language speci cation (ecma-international.org/ecma-262/6.0), we use another open-source tool called Webpack (webpack.js.org) in conjunction with Node.js (nodejs.org) to transcompile the code and make it fully compatible with all modern browsers.
Additionally, Tor outputs application controller components connecting the model and view layers by rendering controller actions. These actions are mapped to corresponding HTTP request methods through extra generated routing de nition les forming the application service endpoints. The data exchange between the browser-based front end and the Rails application back end is mainly realized with the widely-adopted JSON (JavaScript Object Notation) format.
Our toolchain at hand, we suggest a development process based on agile and rapid methods utilizing evolutionary and incremental prototyping. We are in the process of applying this approach to a larger case study covering the design and generation of a browser application for the individual creation of report templates and report instances for various documentation use cases. Dependent on the overall project size, we break our system into smaller parts individually developed through multiple iterations. Each iteration starts with the creation of a data model in yEd and the generation of a rst prototype derived by our toolchain. We then verify our requirements based on the prototype. We are able to adjust or extend the model, if required, and repeat the generation process until our expectations are met. Individual aspects, which cannot be expressed in our modeling language, are added unobtrusively with the help of various customization techniques. Our prototype evolves in each iteration until it is stable and ready for being part of our system. This structured process centers on the created model and is repeated until all increments of our system are captured.
The presented toolchain enables developers to perform simple and direct transformations from domain-speci c models to executable applications. yEd as a light-weight diagram editor is freely available running on all major platforms. The latter also applies to Ruby, a widely-adopted and actively maintained open source programming language o ering an easy and intuitive access harnessed by Rails, an established web application framework used by major platforms like GitLab and Airbnb. The depicted development process liberates developers from repetitive routine coding work and enables them to perform application re nement through model re nement. The domain-speci c models identify central application concepts and represent a stable documentation. Our generation process facilitates fast iterations, which can be immediately validated by all relevant stakeholders. Thus, developers can take advantage of running evolving prototypes, which users can immediately interact with leading to early accepted increments and reducing the risk of project failure. Finally, if modularized properly, models and their increments are reusable in other projects. 4
We have demonstrated how we use yEd to create, store and update domainspeci c models and how a toolchain is capable of generating browser-based client-server applications based on Ruby on Rails by applying corresponding transformations on those models. Our underlying DSM language targets web information systems and o ers a rich collection of modeling features borrowed from (Extended) Entity-Relationship modeling and UML class diagram concepts. We have also suggested a feasible agile development approach we are using in our case studies.
As of now, our approach is limited to structural design. While some language features induce special application behavior, currently behavior cannot be modeled explicitly, but is projected in future tool versions. As already mentioned, we are in the process of planning and performing a larger project covering the design and generation of a browser application for the individual creation of report templates and report instances. The idea arose mainly from the need of exible checklist based reporting for FSC (Forest Stewardship Council) audits and home inspection reports as recommended by InterNACHI (International Association of Certi ed Home Inspectors). Last but not least, applicability and practicability of our approach will be further validated and improved through middle- and large-sized case studies.