Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Thursday, September 9, 2010

Ubiquitous Language or a Composition of Languages?

According to Wikipedia, "BDD focuses on obtaining a clear understanding of desired software behavior through discussion with stakeholders. It extends TDD by writing test cases in a natural language that non-programmers can read." Also, Dan North says that "BDD provides an Ubiquitous Language for Analysis" and then presents the Given-When-Then (GWT) triad.
Thinking on these definitions, I proposed the use of Business Process Modeling (BPM) artifacts for describing requirements in BDD. Things like Petri Nets and Statechart or Activity Diagrams are a "natural language" for many users, in special for those that interact with EIS.
I understand that GWT is an UL for System Requirements Elicitation. In fact,  I  think that ULs should behave as a composition of languages, something like (some language that can describe system requirements) + (the user's business language).
For EIS, I envision something like some BP notation with a textual language that is simultaneously understandable by users, parseable, and that we can write code that is the closest to the user's way of writing about their business, using expressions such as "Vectorial Calculus is_a_pre-requisite_of Linear Algebra" (Yes, that's what people call DSL - Domain Specific Language).
Ideally this textual language should go from the requirements to the code, letting the program's structures be described through the BPM notation.
I wrote all this text to say only this:
-UMLers would say "Activity Diagrams + OCL" is the answer, and I say, yes, that's an option, but OCL is not the right answer, it isn't natural!
So, we need to go further...

No comments:

Post a Comment