NOTE: This project has been retired, and there will be no more updates. Other future projects may reuse some concepts presented here.

Introduction

The whole idea of the Data Model Widgets (DMW) started with one question.

Would it be possible to design data model outside the CA Gen, export such design to the CA Gen model, possibly continue work on the technical design, and finally generating from the CA Gen code in many supported languages targeting many supported databases?

After researching some possible methods and scenarios, developing and checking some concepts, the answer is yes. And we can do much more than that. It is time now to describe and formalize concepts and start building implementation plan delivering the DMW Solution.

A choice of word widget to describe something in the context of data model needs some explanation. In the software world, word widget means a generic type of software application comprising portable code intended for one or more different software platforms.So having a formal description of the data model, we are going to develop a variety of widgets describing how to access and modify databases derived from the defined data model. You can see widget as a piece of software logic written using the purpose created language that later can be translated to the variety of different programming languages by the willing providers.

Table of Contents

This concept requires a domain specific language of some sorts which will be helping capture data model design, used to write relatively compact pieces of logic describing how to access entity types using different access paths, acting on clearly defined inputs and presenting results in the clearly defined outputs.

This concept will be similar to the one used in the CA Gen for years. The overall idea is keeping the future language 100% compatibility with the subset of CA Gen Model what should allow exchange freely metadata between both environments. This is a part of the plan for the first stages of the project. The CA Gen offers the excellent collection of generators and they can be easily used to generate high-quality software targeting different software platforms. Ability to transfer model fragments to the CA Gen for the integration and generation opens a lot of new possibilities.

The similar mechanism can be used to extract from the CA Gen certain fragments of the design and move them to the external tools. Those tools could, for example, generate code using data model widget as a source to different exotic target software environments not covered by the CA Gen.

DMW Language

The DMW Language will be the main delivery vehicle in the proposed solution. It will allow capturing metadata about the data model and its possible uses.

The CA Gen Toolset offers some GUI based dialogs allowing to build a data model and develop action blocks accessing and transforming data stored in the derived database. All those efforts are on a purely logical level of abstraction without any references to the technical aspects of any possible future implementation. The technical design stage is clearly separated from the logical design and technical transformation is done at later development stages. Clean separation of concerns is one the most exciting features of the CA Gen.You can learn more about how it works visiting CA Gen Documentation website here.

Please see two snapshots below to demonstrate how development is done in the CA Gen. First shows graphical interface used to design data model. The second one shows how action blocks look like.

Both data model and action block diagram are a visual representation of the metadata from the CA Gen model. You need specialized software to have such metadata visualized this way.

Here is a snapshot of the how looks a similar data captured using DMW Language.

PACKAGE eu.jgen.notes.dmw.sample
import eu.jgen.notes.dmw.annot.YEntity
import eu.jgen.notes.dmw.annot.YNumber
import eu.jgen.notes.dmw.annot.YMixtext
import eu.jgen.notes.dmw.annot.YDate
import eu.jgen.notes.dmw.annot.YRelationship
import eu.jgen.notes.dmw.annot.AssociateTypes
import eu.jgen.notes.dmw.annot.DeletionRules


/*
 * An individual who is assigned to a DEPARTMENT, who 
 * may manage a DEPARTMENT or a DIVISION or a 
 * PROJECT, and who may work on a TEAM.
 */
@YEntity (tdName="EMPLOYEE", min=1, avg=100, max=1000)
DEFINE employee AS ENTITY {

         @YNumber (tdName="NUMBER",  optional=false,  length=6,  decimalPlaces=0)        
         ATTRIBUTE number: int 

         @YMixtext (tdName="NAME",  length=30, optional=false, varyingLength=false, caseSensitive=false)             
         ATTRIBUTE name: String 

         @YMixtext (tdName="ADDRESS_LINE_1",  length=30, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE address_line_1: String 

         @YMixtext (tdName="ADDRESS_LINE_2",  length=30, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE address_line_2: String 

         @YMixtext (tdName="ADDRESS_LINE_3",  length=30, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE address_line_3: String 

         @YMixtext (tdName="ADDRESS_LINE_4",  length=30, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE address_line_4: String 

         @YMixtext (tdName="ADDRESS_LINE_5",  length=30, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE address_line_5: String 

         /*
          * phone numbers set to text so that various forms of the 
          * phone number can be entered, along with appropriate 
          * commas, dashes, parentheses, etc.
          */
         @YMixtext (tdName="HOME_PHONE",  length=16, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE home_phone: String 

         @YMixtext (tdName="WORK_PHONE",  length=16, optional=false, varyingLength=false, caseSensitive=false)           
         ATTRIBUTE work_phone: String 

         /*
          * PAY TYPE identifies how often and what type of pay for 
          * this employee.  Permitted values are spaces (default), 
          * B = bimonthly, H=hourly, M=monthly, 
          * W=weekly,S=semimonthly.
          */
         @YMixtext (tdName="PAY_TYPE",  length=2, optional=false, varyingLength=false, caseSensitive=false)          
         ATTRIBUTE pay_type: String 

         @YNumber (tdName="PAY_RATE",  optional=false,  length=10,  decimalPlaces=2)         
         ATTRIBUTE pay_rate: double 

         @YMixtext (tdName="MAIL_STOP",  length=4, optional=false, varyingLength=false, caseSensitive=false)             
         ATTRIBUTE mail_stop: String 

         @YDate (tdName="SERVICE_DATE",  optional=false)             
         ATTRIBUTE service_date: int 

         @YMixtext (tdName="FULL_TIME_STATUS",  length=2, optional=false, varyingLength=false, caseSensitive=false)          
         ATTRIBUTE full_time_status: String 

         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disassociate, percentage=90, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  works_on  1:1    team INVERSE is_made_up_of
         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disassociate, percentage=5, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  leads  1:1    team INVERSE is_led_by
         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disassociate, percentage=3, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  manages  1:1    project INVERSE is_managed_by
         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disassociate, percentage=2, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  manages  1:1    division INVERSE is_managed_by
         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disassociate, percentage=90, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  manages  1:1    department INVERSE is_managed_by
         @YSource (transferable=true, type=AssociateTypes.Default, deletionRule=DeletionRules.Disallow, percentage=0, atLeast=1, onAverage=1, atMost=1) 
         RELATIONSHIP  is_assigned_to  1:1    department INVERSE controls

         IDENTIFIER empid (number)  
         }

The above fragment demonstrates how the DMW Language will look like. This is fragment defining employee entity type.As you can see the definition is a text and it is stored in the flat text file. You can open such file using any text editor on any computer and operating system platform.

The key difference between those two above approaches is that the DMW keeps all information in a readable text format and creates ad-hoc an in-memory fragment of the model using special software whenever such information you need to, for example, generate something by your utility. In the case of the CA Gen, you need the CA Gen Toolset or other dedicated software to see what in the model.

The DMW language is a typical example of the Domain Specific Languages (DSL) and developed using Xtext technology. The Xtext allows building sophisticated editors and developing many tools based on the underlying EMF technology.

DMW Capsule

In technical terms, the DMW Capsule is a bunch flat text files containing fragments of the model and zipped to allow easy movement between different development environments. At the logical level, the DMW Capsule represents a complete and internally consistent model that we can transfer between tools which are aware of the capsule contents and knows how to use such contents. We need to emphasize fact that contents of the capsule are entirely readable and editable using common tools like text editors. There are not hidden binary files require special software to read.The DMW Capsule has successfully verified status if passes rigorous consistency checks to detect possible imperfections. Technically, the capsule has to be successfully compiled without errors to achieve such status.

Architecture

Couple words of comments about overall architecture showing players and interactions between them. The following figure shows in a simplest possible way how it supposes to work.

Capsule

We already know what is a capsule. Capsule allows exchanging information between capsule aware players.

Capsule Development Tools

You may need some specialized software to create verifiable capsule and use it in a more sophisticated way. Here is a basic list of tools envisaged for the capsule.

DMW Compiler. This is a command line utility used to verify if model fragments in the capsule are internally consistent and such verified capsule can be sent to the other players. In case you cannot use dedicated editors to edit text files, you can check if newly developed or modified fragment compiles successfully using a dedicated compiler. The compiler produces diagnostic information helping find errors.
DMW API.This is for all willing to develop their own tools. This is the type of Java API and Java is a language of choice for entire development. Also, it makes sense to mention that the DMW Language is entirely built on the Eclipse platform and Eclipse is a natural and most suitable environment to develop tools based on this technology. It is also possible to run utilities using the DMW API outside Eclipse as stand-alone applications.
DMW Editors. The solution will come with two modern Eclipse-based editors offering an advanced feature like syntax highlighting, background validation, error markers, content assist, hyperlinking, quick fixes, outline view, automatic building, formatting, templates and much more. There are plans for two incarnations of the same editor. One is installed on the workstation and second is web-based.
Capsule Upload Utility. You need one for each Capsule Aware Development Environment. Such aware environment needs some DMW tools to interpret what is delivered in the capsule and how they are going to use such information.
Capsule Download Utility. You need one for each Capsule Aware Development Environment.You need some tools from the DMW toolbox like compiler helping you in building the consistent and verifiable capsule.

The basic list can be easily extending by adding utilities like generators and reporting functions.

Capsule Aware Development Environment

A good example of the capsule aware environment will be the CA Gen. Two command line utilities will be a part of basic tools allowing downloading and uploading DMW model fragments to the CA Gen model.

Capsule Unaware Development Environment

There is another type of players. Those are potential development environments mining for software components to reduce development costs. Would be beneficial for all to create infrastructure allowing to choose from some sort of template catalog of precooked components that can be used by willing parties to customize and implement in the desired target architecture? Hopefully, the DMW will open a playground for creating such environment for many to exchange a variety of services for the benefit of all.

Development Plan

Development of the DMW will be divided into a number of stages. Each stage will have clearly listed objectives. The DMW Language will grow in complexity and scope gradually by extending its semantics step-by-step. The DMW Toolbox will be updated successively in parallel with the DMW Language absorbing a new functionality.

Stage 1. We are going to start DMW Language with functionality allowing define the data model first. The DMW Toolbox will include the following items:

Parser and validation modules for the DMW Language
DMW API
DMW Editor Plug-in for the Eclipse-based IDE’s
Stand-alone command based DMW Compiler
Capsule Download Utility for the CA Gen
Capsule Upload Utility for the CA Gen

Stage 2. The DMW Language will grow by adding the following statements and features:

SET Statement
MOVE Statement
EXIT STATE Statement
COMMAND IS
Expressions

Stage 3. The DMW Language will support additional statements and features:

IF Statement
CASE OF Statement
FOR Statement
FOR EACH Statement
Unit testing
Debugging
Web-based version of the editor

Stage 4. The DMW Language will support additional statements and features:

READ Statement
READ EACH Statement
UPDATE Statement
DELETE Statement
ASSOCIATE Statement
DISASSOCIATE Statement
TRANSFER Statement

Stage 5 and more... adding object-oriented features

CURRENT STATUS: Retired