The road to Salamanca

To content | To menu | To search

Tag - Software Factory

Entries feed - Comments feed

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.

Monday, August 4 2008

Getting on the tracks

So, if Salamanca is a software factory, what is the product line associated with it? The answer is simple : business applications.

Alright, I think I can be more specific than this. In our context

a business application is a software that handles business specific data while implementing parts of business specific processes (which we will call activities) and enforcing business specific rules.

There are a few things we can infer from this definition :Hotel Du Nord

  • to handle business specific data, we will deal with a database backend ; more often than not a real like Sql Server or Oracle, but also possibly a web service or even a simple file (XML, CSV...). For instance, a hotel room booking application would be built upon a proper database, with structured data such as the rooms, their rates, their vacancies...
  • the data lifecycle has to be integrated into well defined activities. At all times, from the state that we know the system is in, there are only a few well known actions that can be taken. Without this concept, an application like Excel would fit into our definition. For instance, a basic activity involving a hotel room and a customer would be : book, then check in, then check out.
  • rules must be enforced at all times. Some of them are specific only to some piece of data, some others can be also specific to  a specific activity. For instance, a booking date in the system cannot be anterior to the date the hotel was built : this is a general rule. But for new reservations, the same booking date has to be in the future : this is a rule that applies to the same data, but that is specific to the activity called "book a room in the hotel".

Our vision with Salamanca is to be able to design a business application in terms of data, activities and rules and be able to generate a complete and functional (if not user-friendly) software.

But we also want to leave the developer at the center of our factory. There are many libraries and tools (think of code generators) out there in the field that work very well, provided you respect their predicates (data structure, software architecture...). But in real life, you almost always have to adapt your code to business specific conditions : already existing databases, specific procedures, architecture... Applications built with Salamanca must be open to adaptations by developers. Think only of the : would you use a software exclusively designed by automated tools ? I know I would not.

Through the concept of activities, which I will elaborate on more in another post, we also created a new way to clearly separate the concerns of presentation from the core application, which we found to be very promising so far. Once created the core of your business application (data handling, activities and rules), you could develop your HMI layer in any (.NET related) technology you like : Windows Forms, Windows Presentation Foundation, ASP .NET... Or in all of them. Or, maybe wiser, you could develop part of your application as an ASP .NET application, and part of it as a Windows Forms application (on Windows TabletPC or Windows Mobile for instance), while reusing the same set of core libraries with your business specific data, activities and rules.

I really hope I made you want to know more about it. In future posts, I will talk about our libraries, our models and our tools. Stay tuned !

Tuesday, July 29 2008

A first glimpse of Salamanca

Welcome to the team blog of Salamanca!

Salamanca is a business applications software factory. The goal is to enable developers to create business oriented applications in a more efficient, reliable and coherent way through a specific set of libraries, models and tools. To make it short, we define a business application as a software that handles business specific data (you can think of it as a low scale enterprise application). Salamanca is designed to help managing the whole life cycle of business data : storage, display, edition, validation, processing... More on that later.

Salamanca is an open-source project, hosted on CodePlex. Its name is a reference to The Salamanca, the first commercially successful locomotive built in 1812.

We are delighted to have you on board, and we hope we will have a pleasant trip together ;-)