Domain Language: What is the best way to express?

Question

One of my client sent me a requirement document and while reading that document there was a flash came in my mind. I started rewriting that big document similar like below. Do you think, an automated tool can generate a data model and rules by running through this. Say, if any client communicate their requirement in this approach, it will make every one to understand the domain better.

I understand that since I know what is blog and comment and post I am able to relate it easily here. However, if one chop down all the technical terms of their business in this manner, will it not be easy to make every one on the same page?

• Model:
  • blog has a date
  • blog has a content
  • blog has a author
  • blog has many comments
  • content may have images
  • content may have links
  • comment has a blog
  • comment has a name
  • comment has an email
  • comment may have an url
  • comment has a date
• Rules:
  • blog cannot be empty
  • blog may be published or drafted
  • blog should have a author
  • blog cannot be deleted when comment is present
  • blog cannot have comments after 20 days

Edit:

What I am really trying to come up here is -- once you get a requirement document and if you create a document that is mentioned here you will be able to figure out what the client is exactly looking for.

And, the other advantage is that you can use this document for further enhancements and development of the project. Or even a client can directly edit this document by hand since he now learnt how we are looking his requirements (I mean our language).

Now to some degree this statements can be interpreted in different way.

For example, I could have some tool that will analyze the statements and come up with information like if any model changes, rule changes are made it into this document.

Edit:

I am currently trying to follow this approach in a complex model like Order Management, I will update here what ever I learnt. Meanwhile, if you anyone is interested in here they can also involve with me.

Answer 1

For easy cases like these, perhaps.

In general, I would say no. If it were really as simple as this, it would have been done by now and programming as a profession would be over. Executive admins and SMEs would be developing enterprise systems.

I think code generation can give a lift, as long as you write the code generator yourself and understand it thoroughly. But in general I'm skeptical. I think hard problems are a lot more complex than your example.

The case that you're describing would appear to be in the sweet spot of Grails or Ruby on Rails or something analogous from Microsoft.

Answer 2

For example, Ruby on Rails provides this kind of domain specific language. See migrations and ActiveRecord validations.

It provides some simple parts of your system, but anything complex must be still coded "by hand".

Answer 3

given that all cases are as simple as that it is possible defining your language either as internal DSL using a higher level programming language, e.g. ruby or scala, or as external dsl using code generators e.g. Xtext, MPS, or yacc and bison.

However, when the result should be general purpose, a agree with duffymo, the generators or abstractions can become very complex.

Answer 4

Now You are taking wrong approach. Requirements should be understandable for both groups (devs and clients) and should have one instance. So when requirements changes only one you must change only one palace/pice/information. Not several docs. Also any dev may wont to ask a question to client so he will have to show spec (if app is complex) and this must be client spec. (I said When not If).

Maybe Agile approach will fit. Use small storys instead of docs. Story should cover one piece of functionality. Benefits are that programmers and clients talk in the same languages (storys should use clients domain language), and clients can assign level of importance to each one.

PS I'm quite shure that this spec will change :) blog cannot have comments after 20 days

PSPS business logic (your rules) are complex far beyond your simple example, so possibility to contact with clients at any time (no mails! phone or VoIP) is really important

PSPSPS do you know ORM ?? http://en.wikipedia.org/wiki/Object-relational_mapping

Answer 5

See Behaviour Driven Development, might get you some ideas about DSLs for specs. Actuallly I am working on my masters thesis, which will combine DDD, DSLs, BDD and MDSD to do practically what you are aiming at.

Answer 6

I understand your desire to have a more automated approach to keeping requirement in-sync with code. UML is a well-established tool for modeling systems, and lots of code generation tools for this and similar languages exist. However, from those that have used them, I've only heard horror stories.

The problem with requirements documents in general is that most stakeholders do not think of a system as a set of exact, formal rules. I've always had to translate high-level requirements into lower-level ones to make them of any use to us programmers, and that takes a lot of time, research, meetings, and a dash of assumptions. I don't think we'll ever be able to bridge that gap in an automated way. Maybe we're doomed and should just be happy with whatever vague design documents that get passed over to us.