The road to Salamanca

To content | To menu | To search

Wednesday, October 29 2008

To Salamanca via Oslo ?

Now that our libraries are functional enough, it is high time we started getting into the modeling part of our software factory. The first step is to define proper syntaxes for our s : the Salamanca Domain Model Language (SDML) and the Salamanca Activity Model Language (SAML).

In fact, as a proof of concept, we have already tried to define a syntax for our SDML. Based on XML, it would describe the Domain in terms of types, enumerations, domain elements and associations. Here is an example written in this SDML :

xsi:schemaLocation=" ../Models/dml.xsd"
<serializable name="string">
<native type="string"/>
<sql dbtype="VARCHAR"/>
<serializable name="Boolean">
<native type="bool" nullable="false">
<conversion language="C#">Convert.ToBoolean({0})</conversion>
<sql dbtype="BOOLEAN">
<conversion language="C#">Convert.ToByte({0})</conversion>
<serializable name="Chars">
<native type="string"/>
<sql dbtype="CHAR"/>
<serializable name="long">
<native type="long" nullable="false"/>
<sql dbtype="BIGINT"/>
<serializable name="Date">
<native type="System.DateTime" nullable="false"/>
<sql dbtype="DATE"/>

<enum name="RegionType">
<base name="Chars" size="3" />
<value name="Department" code="DEP">D├ępartement</value>
<value name="State" code="STA">State</value>
<value name="Land" code="LAN">Land</value>

<domain name="Region" shortName="Regions">
<attribute name="Id" visibility="none" required="true">
<type name="long"/>
<attribute name="Name" required="true">
<type name="string" size="63" />
<attribute name="Type" required="true">
<type name="RegionType" />
<key attributes="Id"/>
<domain name="City" shortName="Cities">
<attribute name="Id" visibility="none" required="true">
<type name="long"/>
<attribute name="Name" required="true">
<type name="string" size="63" />
<attribute name="HasPostalOffice">
<type name="Boolean" />
<key attributes="Id"/>

<assoc name="RegionCities" association="composition">
<end name="Region" target="Region" multiplicity="1"/>
<end name="Cities" target="City" multiplicity="*"/>

Based on this syntax, we would perform numerous transformations (with ) to generate Visual Studio solutions, projects, source files (SQL, C#), resources and even graphical representation of the domain (by driving the excellent Graphviz). But we found several drawbacks to this method :

  • XSLT code is tedious to write and hard to debug.
  • a DSL modification need the manual refactoring of many, hard to maintain files.

And indeed, our code soon became so complex that we had to leave some things out of the generation process, like the implementation of the many to many relationships...

So I started lately to delve into the Visual Studio DSL Tools, armed with my courage, my computer and the appropriate reference. And it looks very promising, though somewhat limited for our grand vision. As Daniel Cazzulino wrote :

The DSL Tools is basically the first step in the road to realizing the full SF vision outlined in The Book. Hence, if you try to build a real-world factory just using DSLs, you will find it fairly incomplete and not supporting typical scenarios such as providing an initial solution structure where you will put your DSLs, etc. The missing features, though, are most probably those that will come (or become unnecessary) as the full vision is implemented. In the meantime, it feels lacking.

Anyway, the first impressions are excellent, and it feels like time invested in designing our DSLs around these tools will be far from being wasted time.

This is how I felt this morning, when I discovered that Microsoft is just starting to communicate about a new product, that they label as a modeling platform, and that is codenamed Oslo. Hear Bill Gates about it :

It's actually taking the kind of models that you're seeing arising in specific domains, like software management in System Center, or your data design over in SQL, or your process activities over in BizTalk and saying, we need to take all these domains and be able to put them into one model space. In fact, we need to let people create their own domains that aren't just isolated, but that exist in this one modeling space. And that's what Oslo is about.

I could not agree more. Salamanca needs to have domain models and activity models in the same modeling space, simply because a business activity is by essence bound to manipulate business objects : a SAML model is linked to a SDML model.

Good Morning, Oslo

So it looks a lot like Oslo could be the best way to go to Salamanca. That is sure going to be a long journey, but very likely to be an interesting one. For now, I am sticking to my DSL Tools.

Wednesday, August 20 2008

Visiting Salamanca

Fundamentally, Salamanca is designed around three sets of libraries :Architecture

  1. Data Access is the easiest to explain in a few words : think of it as (yet) an (other) (ORM) library. Why another ? We believe that there is not nor will ever be a perfect solution for this problem ; call us "ORM limitations acceptors". Our belief is that an ORM solution has to be designed to fulfill a specific set of issues under a specific set of constraints (which definitely sounds like a product line to me). After all, if you want to go around and around in circles without going anywhere, you are more likely to win the race with a formula one car. If you want to drive home, you will be better off with a standard commercial car : it has been designed for average roads, and priced accordingly. This library will help us handle business specific data in a (DAL).
  2. Data Activities is a library that helps define the business data lifecycle into a specific layer. The latter is a which lies at the core of our architecture : it manages business data, drives the HMI, and as such acts as a perfect (?) .
  3. Data Rules is a validation framework. It will be used to implement our business rules in our activities transitions and our data.

These libraries represent the fundamental abstractions around which our applications will be built. Best practices can be documented around their use, that can be written with our own (DSLs). We have defined two DSLs so far :

  1. SDML (Salamanca Domain Modeling Language) : this language will help us structure our data in order to implement our DAL. But more than that, it will help us create reusable states for our activities, or reusable component for data edition (user controls in Windows Forms for instance). Its representation is very close to a UML Class Diagram.
  2. SAML (Salamanca Activities Modeling Language) : this will help us define our activities. Activities reuse concepts defined in a SDML model. Its representation is inspired by the (BPMN).

Implementing an application with our libraries once the models are properly defined should be quite straightforward. So straightforward that we will be gain a lot by creating two tools that will greatly enhance our productivity :

  1. A Modeler : a graphical tool that will help us visually model our application and serialize it in SDML and SAML formats.
  2. A Generator : a tool that will implement our best practices and take our model as input, in SDML and SAML formats, and generate our C# code. Though it is imaginable to generate a whole functioning application, the developer will have the possibility to customize the generated code to make it more usable, or implement parts that could not be modeled. Usually, developers will ... develop a usable HMI on top of the generated code.

As for now, the libraries are quite in an advanced state, the DSLs definition is in progress and the tools are part of our to do list.