Antoine Savelkoul

The end of 'Oslo' as a language workbench?

If you follow blogs of other Oslo enthusiastic, you couldn't have missed it. Oslo , the codename for Microsoft's new modeling platform, has been renamed to SQL Server Modeling.  Confirms this that the focus will shift to SQL Server instead of creating a modeling platform for DSLs and storing models?

This development is however something that comes as a disappointment to me. I was hoping for improvements to Oslo which should raise the speed of creating and deploying DSLs. Something I am missing is the possibility to modify language definitions without the need to redeploy your schemes and without losing your models. This is something essential when dealing with changes in DSLs, especially during prototyping. But if Microsoft is really moving their focus to SQL, it will not surprising me if these features will never be developed.

Some other news that is also interesting, but might also be confusing, is the use of SQL Server Modeling Services as underlying application model for Microsoft's cloud, Azure.
Using DSLs to model applications running within a cloud is something that is in line with my vision for years. If you really want to stimulate people to connect their online services running within a cloud, you should make it easy for them by raising the abstraction level of application development. I believe that DSLs will be the way to make this possible, but I also see that the language workbenches currently available would have to undergo a necessary transformation. I therefore really wonder how this will fit within the direction Microsoft is taking with the SQL Server Modeling Services.

However, I'm still interested in using the SQL Server Modeling Services (Hmm, the name ' Oslo ' still sounds a lot better) as platform for sharing models. For DSL prototyping however, I will use other tools. Hopefully Microsoft will at the end choose to change the name of there moddeling platform to something like the "Azure Modeling Services" ;).

To see what other people are writing about the rename:

• Gerben van Loon - “Oslo” renames to SQL Server Modeling"
• Keith Short - Codename “Oslo” Repository Becomes SQL Server Modeling Service
• Aali Alikoski - Oslo -> SQL Server Modeling

To read more about the name change, see this post and other blog posts of Douglas Purdy.

Event on Home Automation and Smart Living

Thursday I went - together with my brother (Martin) - to an event on Home Automation (Beurs Domotica & Slim Wonen). On this event a number of installers and manufacturers of home automation equipment were represented. We used this opportunity to do some market research.

Most significant to realize, and what we knew before going to the event, is that the companies at the event focus mostly on the higher segment of the home automation market. Examples are Philips with their Pronto, Siemens with KNX hardware and a lot of manufactures of touch screen units.

Software solutions

We were mainly interested in manufacturers of software solutions. We talked to some of them which gave us a good indication of where the home automation market stands today. Some of the most remarkable things were the user interfaces. Some of them were so messy that we didn't understand where all the buttons were meant for. Others were kept as generic as possible which made it difficult to distinguish features by importance and type. There were some more impressive ones, but they need to be configured by the installer. We think a lot of improvements are possible here.

Another significant thing is the support of systems of external parties. KNX is by far the most supported standard enabling manufacturer independent extendibility. Some companies will also support the X.10 which is popular in the lower segment of the market. Extensions to other systems like a/v equipment however are something that seems to have a lower priority. One system we saw had an integrated web radio, but this was limited to one party. If they supported DLNA, lots of other a/v applications would be possible as well.

The lower segment

Within the lower segment of the market we find manufacturers like KlikAan-KlikUit and Marmitek (X.10). They also offer software, but these are very limited in functionality and often support only their own systems or single protocol. Their equipment however is affordable for a much larger audience. An example of not manufacturer specific software is HomeSeer, which offers extensibility through APIs. An advantage of the HomeSeer software is that is has a large community of enthusiastic peopele developing add-ins for even the more affordable equipment. However, the average computer user would not have enough experience with finding and configuring these extensions. So, where the price is the barrier to a large audience within the higher segment of the market, the complexity is the barrier for the lower.

Significant players in the future

I believe that sooner or later home automation will become as common as the telephone and internet access. A growing market that is related to home automation is that of the Smart Metering. Within the near future utility companies will roll out many electricity, water and gas meters that send 'usage information' to a central system. Each meter will have its own data connection. This data connection will however have a lot more potential. This is something companies like Microsoft and Google also realize. These data connections might become a new gate for them to deliver information based services. Smart meters might also contain communication interfaces to home automation systems, so this might also be an opportunity to them to get access to this part of your house to without the need of a home server or internet connection. And so there are many other examples of existing multinationals that might extend their market this way.

Conclusion

Home automation is a living and growing market with enough space for innovations. Complete solutions can been found within the higher market segment. To make these complete solutions accessible to the lower segment of the market, home automation systems will have to become less complex and the need of custom development and configuration needs to be taken away. At this moment a lot of innovations comes from small start-ups, but it would not be inconceivable that large companies like Microsoft and Google will enter the market soon. 

Questionnaire DSL at PDC09

In my previous blog posts and papers I referred to my master's project. During this project I designed and build a prototype of a DSL for medical statements. My DSL is now used within Avanade Netherlands as a case study for other interns. Michael Wolbert and Bryan Sumter developed my DSL further by making a version of the DSL for Microsoft Oslo, which will be presented at the Microsoft PDC next week. Gerben van Loon wrote a blog post: "Questionnaire DSL with Microsoft "Oslo" overview" about it showing some of it's details that might be interesting to have a look at.

The master's thesis of my which is the root of this project will be hopefully made public soon.

First designs for the home automation DSLs

When writing this post I realized how many design choices I have already made while designing the first prototype. Too much to blog about, so I will only discuss a few design choices I have made. Firstly, I would like to start with describing the domain of the first DSLs.

The first DSLs will be used to define the capabilities of devices that will be controlled by the home automation system. Examples of devices are light switches, dimmers, energy meters and the TV. It should not only be understandable by the designers of the devices, but also by its users. A high level description of the basic functionalities of a television might look like:

The television has a power button that can be used to turn the television on and of. Furthermore, the volume can be set to a variable level or muted on and off without losing the previous sound level. The user can switch between the sources "HDMI", "VGA", "Composite in" and the build in tuner. The tuner has some pre-sets the user can choose from.

 A visualization might result in an image like below:

 

From this drawing we nearly have a language, we only need to formalize it. A pseudo description of the language might look like:

• A device type has a name
• A device type has zero or more device functions
• A device function has a name
• A device function should be one of the following types:
• On / off
• Variable
• Fixed choice
• Dynamic choice 
• A fixed choice should have one or more pre defined options
• A variable should have a minimum and maximum level

A second DSL is used to describe how the devices will talk with the home automation system. My first observation was that, each device will receive commands through a transmitter unit or another connection. For example the light switches will receive signals from a transmitter and the television via a serial connection. But by defining it this way, each device implementation will depend on a specific transmitter or connection while, for example with the wireless light switches I have used, the user has the choice to use an original manufacturer's transmitter or one of RFXCOM. So, the original design was not completely in line with my goal to have a manufacturer independent solution.

However, I came up with the idea to include communication protocols so that a manufacturer independent solution is possible. These communication protocols can be best compared with web services. The DSL for the communication protocol will have some resemblance with for example the Web Service Software Factory.

Some simplified examples of two communication protocols within my home automation system: 

Wireless light switches

Request:

Parameter	Type	Is address	Description
Home code	A .. P	Yes	Home code set on the device
Device code	1 .. 16	Yes	Device group and number
Value	on/off	No	On/off or dimming

 

TV Serial Control

Request:

Parameter	Type	Is address	Description
Set ID	1 .. 99	Yes	ID of the television
Command 1	j,k,m,x	No	First part of command code
Command 2	a .. z	No	second part of command code
Data	0-255	No	Value (on/of, level etc.)

 

Response:

Parameter	Type	Is address	Description
Command 2	a .. z	No	Second part of the command received
Set ID	1-99	Yes	ID of the television
Act code	OK, NC	No	Indicates if the command has been received and executed successfully
Data	0-255	No	New value

 

Parameters can have a "Is address" flag. This flag will be used to add configuration parameters when adding devices to the home automation system.

The last DSL I would like to discuss is the DSL used to assign the protocols to the devices. Within the image below we see how, by using the protocols, compatibility between devices can be modelled without creating direct dependencies.
 

One interesting scenario for this DSL is that it should be easy to work with multiple people on. There will be several ways on how the model will be created. People can assign self defined or existing protocols to devices they have defined, but might not interested in all the transmitters that are available or all devices that can be controlled by a specific transmitter. On the other hand, protocols might be designed to control specific type of devices. For the end user there is no difference between a light switch controlled using a wireless protocol or using Power Line Communication. So, how the model above will be created and visualized is still something to think about.

Some things that are not yet covered by the DSLs described in this blog post are:

• The translation of commands (protocol) to device functions
• The translation of commands to, for example, to a textual representation used for communication over a serial link

These will also be covered by the first DSL prototypes I am designing. As soon as I have built these prototypes I will make some parts of my project available for download.

For who is interested in other home automation DSLs too I can recommend the following interesting papers and blog posts of other people (thanks to Steven Kelly for providing some of the references):

• Online draft from Martin Fowler’s next book. His DSL is based on a state machine.
• Steven Kelly discussing the DSL of Martin Fowler
• The Making Of User-Interface Designer, A Proprietary DSM Tool and The Practice of Deploying DSM Report from a Japanese Appliance Maker Trenches by Laurent Safa.
• Chapter 7 of the Domain-Specific Modeling book from Steven Kelly and Juha-Pekka Tolvanen. See also the example on dsmforum.org.
• OSLO is running my house by Kris Horrocks.
• HAAIS DSL. You need a ACM account to download (unfortunately I don’t have such an account) and HAAIS DSL Presentation (free download). The domain of the DSL on page 25 has an overlap with the domain I described in this blog post.

Going embedded

From the embedded prototyping systems I considered, the Arduino is one of the cheapest and the most popular ones. The combination with the ethernet shield will make it the perfect addition for my home automation project. This weekend I received the one that I have ordered online.

 

The ATmega328 microcontroller used by the Arduino includes a serial connection, PWM outputs, I2C bus, analog inputs and more. This will make it ideal for connecting my LCD TV, RGB Led lighting, climate sensors and other equipment to the network. Running simple macros on the controller will in some cases take away the need of a home server being on 24/7. It seems that I'm not far away from generating my first code for embedded devices. :)

Automated home: Applying Interaction Design on DSLs

In my previous posts I have given an impression of the current situation (how the hardware is connected, which software I use). It is very tempting to dig into hardware and software details now, but during previous experiences with designing DSLs I learned that this will be the wrong way.

During my Master’s thesis a few years ago I did an investigation at one of Netherlands major insurance companies. During this investigation, I designed a number of DSLs for the domain of medical statements. I did this in cooperation with domain experts. The methods I used were very promising.

One of the methods I was inspired by is Interaction Design. A lot of papers and articles about designing DSLs will start with an analysis of the problem solution domain by discussing complete hardware designs and software architectures (including some of my own). However, I decided to have a look at the how medical statements were defined by medical advisors, evaluated by legal advisors and implemented by software developers. This resulted in a totally different design as I primarily had in mind. I also believe that the methods I used will create more efficient DSLs that will really decrease the time needed per project phase because it covers the most relevant business logic while representing the language of the business. Thereby, the created models can even be used to validate requirements with domain experts saving valuable time on writing documentation.

For my home automation system, I will apply these successful methods as well. With the only exception, that the group of volunteers who can act as domain experts will be smaller this time. The next step will be to form a list of personas that will have an important part in the process of designing and using this system.
The personas are:

• Residents of the automated home (e.g. a family with kids or elderly people)
• Owner or maintainer of the home automation system (normally the person in house who also configures the thermostat and television set)
• The installer of the home automation system (might be a small company or the owner self)
• Equipment manufacturers who want to make their equipment compatible with my home automation system
• Hobbyists who want to create their own hardware for the system
• Hobbyists who want to add existing (not by the manufacturer supported) hardware to the system
• Manufacturers, retailers and hobbyists who want to design their own user interfaces for the system

In short (when writing an article about my project, I will give more details);

• The average residents just like to have an overview of the system, e.g. knowing where which equipment is located. They will not design their own system but at most define some simple macros.
• The installer of the system wants to be able to configure the system, e.g. how everything will be connected. They will also need the possibility to make some adjustments to the user interface and define some more complex macros.
• Equipment manufacturers and hobbyists who want to make their hardware compatible with the system need to create a software add-in. They need to be able to define what the capabilities of the hardware are, how they can be configured and implement the communication protocols. In the case of hardware that still has to be developed, the communication protocols might be even in scope for the design.
• Finally, some manufacturers, retailers and hobbyists might give their own touch and feel to the system by designing their own user interfaces.

These are a number of personas I have identified so far. For the first phase of my project I would like to limit my scope to the device side because without having them connected, other parts like customizable user interfaces will be useless. In one of my next blog posts I will show an initial design of my first DSL.

Recommendation for reading:

• Alan Cooper. The Inmates Are Running the Asylum.

Automated home: The software

The hardware that I have selected offers the functionality that I will need for this project. Unfortunately, this is not the case for all the software that was provided with the selected hardware. PlugWise is the only one providing software with webinterfaces and some kind of webservices. The other software is simply not focused on extensions to other type of systems.

The table will give an overview of the solutions chosen for the first prototypes of my home automation system.

Device	Functionality of software	Missing functionality	Chosen alternative
Wireless switch units	Sending commands	High level API	Software based on the xPL project (RFXCOM service, .NET API etc.)
LCD TV	None. No software provided	Driver with API or something similar	Custom written API with the serial protocol implemented.
UPnP media players	Media server with indexing	API to control media renderers	Intel UPnP SDK or other (open source) UPnP API
PlugWise	Management, statistics, control and a kind of webservice	API	Custom written API to connect with webservice

The solutions that I haven chosen will raise the abstraction level and will make it easier to integrate them. In a next phase of my project, when the first DSL will be defined, I will give a more detailed look at the APIs.

Automated home: The hardware

In a series of blog posts about the domain of my home automation DSL I'd like to start by giving a first and high level description of the problem domain. I'm going to do this by explaining the current situation of my own home automation system.

Since, I have the intention to create a home automation system that will be suitable for a broad audience, the first step was to select - as much as possible - ready-to-use hardware available at DIY-shops, large retailers and the internet. The more expensive hardware has been selected for its multi-purpose.

Hardware includes:

·         A self configured Windows Home server running on an Intel Atom CPU. A Windows Home Server can be configured for a price as low as € 350,- when using for example an Asus EEE-Box.

·         Wireless switch units from KlikAan-KlikUit. (An introduction set with three receivers will cost less than € 20,-.)

·         RFXCOM transmitter. This will make it possible to control the wireless switch units from KlikAan-KlikUit and a lot of other manufacturers. The transmitter can be connected to a PC and costs around € 80,-.

·         LG 32 LH3000 LCD-TV, cost me less then € 450,-. It's serial port makes it possible to control the TV by software at a PC or embedded system.

·         Network media players by Philips supporting UPnP. These days prices of media players that can be connected to the TV and support UPnP start at around € 100,- (e.g. the Asus O!Play). Some high-end TVs already have these players on board.

·         Wireless energy meters from PlugWise. With +/- € 35,- each, they are a little bit pricy, but they are very reliable.

·         Other equipment like USB Device servers and USB to serial converters used to connect equipment to the home network.

·         A HTC-Touch Diamond II mobile phone which has very interesting specs like a high resolution touch screen and WIFI.

All by all still a big investment, but to begin with home automation, you do not have to buy it all at once.

The image below shows how everything is connected.

The different hardware will have its own way to communicate. There are several Standards and protocols involved like ZigBee, RS232 and UPnP. Manufacturers however also use their own protocols based on for example HTTP.

In the next blog post I will explain how devices will interact with each other via software. Other posts that will follow will be about scoping of the domain and sub domains, other already available DSLs and choice of modelling software.

Still busy with DSLs

After moving to the apartment of my girlfriend and my and doing some jobs to make it our place, I recently took a week off to work on some of my ideas. One of the projects I started is a DSL for home automation and smart metering.  The goal of the DSL will be to simplify the way of building add-ins to support several types of devices like wireless switch units, energy meters and a/v equipment. This while maintaining a manufacturer independent architecture of the home automation system.  Thus far the results are promising. Within the next months, I hope to explain a little bit more of the approach I´m taking in my home automation.

OOPSLA Paper online!

The paper “Building a framework to support Domain Specific Language evolution using Microsoft DSL Tools” Gerardo de Geest, Aali Alikoski and I wrote together for the OOPSLA DSM event of this year has been published on internet: http://www.dsmforum.org/events/DSM07/papers.html.

The paper describes some issues regarding the evolution of DSLs, some scenarios and a solution in the form of a method for automating the transformation of domain models to a newer version of a DSL. The method is the result of the investigation on language evolution Gerardo is doing for his Master’s degree.

Gerardo and Aali will give a presentation on the subject during the OOPSLA Workshop on Domain-Specific Modeling in Montréal the 21st of October.

Bottom-Up Approach = Reverse Engineering = Wrong decisions?

Some people already asked me when I will start with blogging. I really have to tell a lot, but usually cost me quite a lot time to make something clear to myself, and even more to others. But now I’m busy with my Master thesis, this is something I’m doing constantly. This made me to decided to make some time free and share some parts of it. So hopefully this post is just the beginning of a lot more posts that will follow the months from now. I’m known as someone who writes large pieces of text, so I hope they will be interested enough that some people will be read them and respond to them. I start some discussions so I enabled the possibility to respond on posts now.

For my Master thesis I’m doing an investigation on business-DSLs. For a proof-of-concept DSL I had to decide whenever to apply the bottom-up or top-down approach. These two approaches are quite often discussed by people who have to build DSLs. In short, when applying the bottom-up approach, you will identify variation points that will be captured by the DSL by looking at the code. With the top-down approach, these variation points will be identified by looking at the conceptual level. A lot of technically oriented people prefer the bottom-up approach, just to avoid complex or impossible model to code translations when reusing existing code and frameworks for generation purpose.

But how bottom-up is the bottom-up approach? Each structural element within code is the result of a design decision, whenever it is documented or not. I think it is nearly impossible to indentify variation points in a good way without thinking at a conceptual level, even for technology-DSLs. When you have to discover these concepts because they are not documented, the code is not self describing and you are not able to talk with the original designers, I think the process of coming to a DSL has more in common with reverse engineering. Every piece of known and applied conceptual knowledge might been seen as is a form of top-down thinking.

But what is wrong with reverse engineering? This can be best explained by looking at business DSLs. As part of my graduation project I’m building a DSL for an existing system. I made the choice to apply the top-down approach and not having a close look at the existing code before having defined the DSL. By talking to the domain expert I identified a number of customer needs which I would never have detected with the bottom-up approach. This because a lot of the domain experts knowledge and way of thinking couldn’t impossible recognized and restored to it’s original form from the code. This was the result of optimizations made by the functional designer and limitations of the architecture. By using the code as base for the DSL, not only these limitations in translation from concept to code will be introduced into the DSL, but also new during the translation from code to an unknown conceptual level.

During my investigation I even decided make some functionality from the domain experts wish list part of the DSL. An example of this is a multi select option lists on a webpage while the current architecture only supported single select. These additions can often be disabled by constrains on the DSL and enable in the future. I also decided to leave optimizations like reuse of definitions if it made the DSL more complex to understand while the profits were minimal.

My conclusion from my experiences till now is that a pure bottom-up approach will in most cases lead to DSLs that do not cover the target audience, even in the case of technology DSLs. Mistakes in the translation will be made in two ways, from conceptual level to code and back. My advice is to start from conceptual level and involve the target audience in an early stage of design, especially in the case of business-domains. This doesn’t mean you have to avoid compromises when the target architecture doesn’t support some structures, as long as you understand that they will influence the understandability of the DSL by the target audience. In the case of good software designs, the translation of models to exiting architectures and code should be not much more complex in the case of a top-down approach than with a bottom-up approach, especially when techniques like Domain-Driven Design have been applied on the original code. If the translation will seems to be impossible, this might be a sign that the original design doesn’t capture all the needs.

References:

• Steve Cook at al. Domain-Specific Development with Visual Studio DSL Tools. pages 46-48, 457. Addison-Wesley, 2007

Building a DSL for an existing Framework (Paper)

The whitepaper I’ve been talking about for months has now been published on MSDN. I wrote it together with Dennis Mulder. This paper describes an iterative approach for building DSLs by using the DSL Tools from Microsoft. The domain of web services is used as example.

See: http://msdn2.microsoft.com/en-us/library/bb381702(vs.80).aspx

Finally online! My new blog.

After having a look at DotNetNuke, I finally decided to use Community Server again. Since there are a lot things that have a higher priority, easy of use is more important for me than a whole set of features I will have no time for to explore.

The target audience for this new blog will be people with the same professional interests as me. This means you may expect a lot posts about, for example, model driven development.