Home

Inside Software Factories

This interview with Steve Cook is hepful in trying to understand what's behind the hype about software factories and DSLs.

[a domain specific language] tends to look like boxes and arrows on a screen. It’s a graphical modelling language with metadata underneath; and very importantly, metadata that’s domain specific. So if your domain is that of a business process, then the metadata is recognisable XML that describes business processes with tags that will say ‘process’ or ‘activity’, or whatever. It will be customised to your job.
By Ehud Lamm at 2005-03-17 13:34 | DSL | Software Engineering | other blogs | 6025 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Sgt. Schultz

I say nothing.... no-THING.

;-)

By Marc Hamann at Thu, 2005-03-17 15:18 | login or register to post comments

Coining a term

"Metagrouch"!

;-)

By Anton van Straaten at Thu, 2005-03-17 15:47 | login or register to post comments

Oscar

Hey, I'm happy in my meta-less garbage can. ;-)

By Marc Hamann at Thu, 2005-03-17 16:07 | login or register to post comments

Software Factories

"This interview with Steve Cook is hepful in trying to understand what's behind the hype about software factories and DSLs."

Well, it didn't really hep me in understanding the hype.

First: why call it metadata and not just data? It IS data, just data you use at design time.

Second: isn't *everything* domain-specific?

Lots of buzz, no content that made me stop and read closely.

By Ulrich Hobelmann at Sun, 2005-03-20 17:44 | login or register to post comments

Domain-Specific Languages and the hype

the use of DSL's in graphical format (which makes them domain-specific modeling languages, or: DSM) has been around for many years already. Now that MS has decided to back DSM instead of MDA makes it a hype.

A domain-specific modeling language CAN give the benefit of working on a higher level of abstraction than code (UML for example is heavily based on coding concepts). In software engineering raising the abstraction level has always been the reason for successful shifts in productivity. Code generation is another part of DSM, I, and many with me, believe that code generation only makes sense when it is full and the result requires no more manual editing. This can be achieved with DSM. The reason is that with DSM both the modeling language and code generators are completely open to customization in order to make both meet the requirements that the problem domain imposes.

Coming back to the use of graphical elements in a DSM language: In many cases it makes sense to specify an application by using directly the concepts and rules of the problem domain. Take for example a MMI module for a mobile phone: It is mch easier to specify this by using graphical elements that depict "display", "send SMS", "list", "notification" etc. than having to do it with rectangles depicting classes, attributes and return values. The higher abstraction level and dedication to one problem domain ensure that less modeling is needed to define an app completely: There's one part of your productivity increase. The other part comes from the fully automatic code generation. This is not only valid in the desig stage but also in the maintenance phases.

Interesting information source about this: http://www.dsmforum.org

By martijniseger at Mon, 2005-03-21 11:33 | login or register to post comments