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 :

<dml
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns="http://www.nourysolutions.com/salamanca/DML"
  xsi:schemaLocation="http://www.nourysolutions.com/salamanca/DML ../Models/dml.xsd"
>
  <serializable name="string">
    <native type="string"/>
    <sql dbtype="VARCHAR"/>
  </serializable>
  <serializable name="Boolean">
    <native type="bool" nullable="false">
      <conversion language="C#">Convert.ToBoolean({0})</conversion>
    </native>
    <sql dbtype="BOOLEAN">
      <conversion language="C#">Convert.ToByte({0})</conversion>
    </sql>
  </serializable>
  <serializable name="Chars">
    <native type="string"/>
    <sql dbtype="CHAR"/>
  </serializable>
  <serializable name="long">
    <native type="long" nullable="false"/>
    <sql dbtype="BIGINT"/>
  </serializable>
  <serializable name="Date">
    <native type="System.DateTime" nullable="false"/>
    <sql dbtype="DATE"/>
  </serializable>

  <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>
  </enum>

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

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

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.