DSL Tools, DIS Tool and the Future.
Hi,
I am creating a set of small targeted DSL's aimed at developing a consistent application architecture for our application. The final solution may look something like the Himalia tool.
The problem and question I have is about referenceing DSL's across DSL's, the DIS tool and the future.
Some basic background information:
I have the following set of DSL's:
UI
Configuration Tools
Serivces
Business Process
Data Access
Each of the DSL's are tailored to our specific development processes and each are seperate from each other. For instance the UI DSL enables us to build basic Pages and manage the navigation and knows nothing of the Data access model that is designed to enable us to model data interactions with different data sources.
Although each of DSL's are seperate from one another they all share a connection to an "Domain Objects" DSL. These entities are business entities that each layer must know about. For instance, a Customer Domian Object may be modelled, the UI DSL needs to know about it, the Business Processes need to know about it etc.
I understand that I can use the DIS Tool to reference the entities from another DSL Model but is it correct to say:
- Referenced elements can't be shown physically on the referencing diagram (so my Customer entity is not able to be displayed on the UI diagram)? I am making this assumption from the documentation in VSDSLIntegrationSerivce_UsersGuide.doc
I also understand that the DIS tool is not "supported".
So my questions are:
What does the future hold for DSL Tools, I am concerned that I can't see a public roadmap?
When can we expect another release?
Will cross DSL embeding be supported?
Is there an early access program? I have sold the management on the idea of DSL's as the start of a solution to our consistent approach and need for a clear model to enable rapid development.
Am I being silly and is it possible to solve my two issues with the DSL tools above.
For instance, would it be possible to reproduce my "Domain Objects" DSL in all my other DSL's and have the Reference via the DIS Tool point to the Domain Objects Model which maps to the same type of elements and shapes in each individual DSL? Would this enable me to text transform the models directly?
Kind Regards,
Paul Kinlan
[3193 byte] By [
Kinlan] at [2008-1-10]
Paul - some answers inline
What does the future hold for DSL Tools, I am concerned that I can't see a public roadmap?
DSL Tools has recently moved from Team Architect to the Visual Studio platform, together with some of the team that developed it. This has been announced in various places including on my blog.
We are still adjusting to the move and producing a roadmap that makes sense in the new context. Please be patient for a few more weeks. I'll begin by publicising what we're doing to support Visual Studio Team System codename 'Rosario'. For VS2008 (Beta 2 available), the main change is to move the runtime into every Visual Studio box, including the new VS2008 shell (redist of run time no longer required). We've also fixed bugs and improved the path editing experience in the Dsl Designer.
When can we expect another release?
See above: VS2008 and then VSTS codename 'Rosario'.
Will cross DSL embeding be supported?
Not in VS2008, without writing custom code against the raw Visual Studio APIs. And there are no plans to rev the DIS in its current form to work with VS2008 or beyond. I'll be able to answer this question for Rosario, and for releases of the VS2008 SDK following VS2008 RTM, when I publish the roadmap, but not quite yet.
Is there an early access program? I have sold the management on the idea of DSL's as the start of a solution to our consistent approach and need for a clear model to enable rapid development.
There's already a Beta 2 for VS2008 available, and a VS2008 SDK that works with that. DSL Tools is not yet available for Rosario CTP's.
Am I being silly and is it possible to solve my two issues with the DSL tools above. For instance, would it be possible to reproduce my "Domain Objects" DSL in all my other DSL's and have the Reference via the DIS Tool point to the Domain Objects Model which maps to the same type of elements and shapes in each individual DSL? Would this enable me to text transform the models directly?
You can write text templates that access more than one model already. Just include a directive for each model you want to access at the top of the template. If you have a way of identifying references to elements in another model, the simplest being a property that holds a string, then you can use that information in the text template to look up the referenced element in the other model.
I hope that helps,
Stuart
Hi Stuart,
Thanks for taking the time to respond.
I am strongly thinking about using your suggestion about referencing entities from another model in a string property until a better solution becomes available.
Definatly, if embedding DSL tools will be in 'Rosario' (I am making an assumption on the statement: "I'll be able to answer this question for Rosario" 
) or some other release in the future we can use an interim solution. But being able to reference and visualise external model elements would be a god send for us in the project we are about to start.
I have been toying with the idea that I could create a DSL to define our business entities, that will transform into another set of DSL Tools one for each layer that has the entities that we have defined. That way we could have seperate VS2008 shells that are very specific to seperate problems but also know completly about the Domain entities that have been defined prior to this tool. Has anyone tried this? It sounds like a bit of work (has anyone tried something similar?)
Kind Regards,
Paul Kinlan
VS2008 shell is very new, so I don't think anyone has tried what you are suggesting for real. However, one of the key tenets of the shell is that any VS package you create (including DSLs) can be hosted both in a separate shell which you can give to e.g. business analysts, and in Visual Studio itself. This supports the scenario where an business analyst, say, goes and creates a model without having to be immersed in the full development environment that VS offers, and then hand off that model to developers who can just open it in VS and go party.
