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.

Wednesday, September 15, 2010

Proof of Concept for the BLDD Tool - Part III

If you are following this post thread, you may noticed that it is necessary to know BDD to understand our proposal. In order to make you spare your time and decide now if you want to follow our method, I will stop a bit and summarize the proposal.

Initially I will explain BDD very, very quickly, highlighting the points that are interesting to understand SLDD/BLDD. BDD is similar to Acceptance TDD (ATDD), and relies heavily in TDD. It bases the declaration of requirements in the triad Given-When-Then (GWT), using the generic form

Given some initial context,
When an event occurs,
Then ensure some outcome.

Some BDD tool will get the scenarios described as above and create a file with a structure similar to

@Given('some initial context')
# you write test code here that excites the code that treats the initial context
@When ('an event occurs')
# you write test code here that excites the code that treats the event
@Then('ensure some outcome')
# you write test code here that excites the code that treats the outcome

When you run your specification, if you forgot to implement some step, the tool will say that the tests didn't pass. If you implemented code that returns outcomes different of the expected, the tool will say that the tests didn't pass.

Simply, isn't it? But it works!

Your users can read the specifications and you write tests for everything, assuring that the system will produce the correct outcomes. If anything goes wrong, the tool will tell you. If changes need to be implemented, simply change the text and run the specifications, forcing errors to appear, thus indicating where the code need to be changed, facilitating your work and the effort estimation for implementing the changes.

The first time I saw BDD working (for a system developed by an associate), some two years ago, I felt impressed with its simplicity and efficiency. However, since that first time I felt uncomfortable with its text declarations... as an EIS researcher I couldn't imagine specifying a lot of complex business processes using pure text.

Our first decision at NSI was to develop a tool stack for BDD in Python, so that we could use BDD in our projects. Only in the beginning of this year we could find time to solve my discomfort with BDD's text declarations. The core idea is to provide executable documentation to EIS, in other words, the same way we "run" specifications in GWT, I would like to "run" a business process represented by a diagram. Moreover, given that a BP can have many different paths, I would like to run it step by step, with the user choosing which path to follow.

This proposal holds some similarities with Models@RunTime, however I think it is simpler, since the second seems to focus on creating self-adaptable systems, while our proposal here is directed to a "simpler" problem: making EIS development safer, simpler, faster, and cheaper (I am modest). Also we want to make our proposal usable by the common developer, without experience in Formal Methods and alike (thanks God this is a blog, can you imagine someone writing this in a scientific paper?).

When we started to discuss about this proposal, another discomfort of mine was related to the term Ubiquitous Language. I prefer to use the term Shared Language, or a language that may be a composition of other existent languages and results of an agreement between all project stakeholders, or at least between users and developers. For instance, the shared language can be a combination of some BP notation and Math notation for complex requirements, and BDD's GWT for the simpler ones.

For this specific proposal of using BPM, we call it Business Language Driven Development (BLDD). In order to avoid repetition, if you want to understand better this name discussion, please follow the posts with the Shared Language Driven Development (SLDD) labels. The original ideas are also described on our reports Filling the Gap between Business Process Modeling and Behavior Driven Development and Mapping Business Process Modeling constructs to Behavior Driven Development Ubiquitous Language.

For instance, a SLDD/BLDD tool that is based in Statechart Diagrams would generate entries more or less like this (we are still discussing how to do this exactly)

@SourceState('current state')
# excite the code that treats the exit of the current state
@Event ('event')
# excite the code that treats the event
@Transition('produces some outcome')
# excite the code that produces the expected outcome
@DestinationState('new state')
#excite the code that treats the entrance into a new state

With that in mind we can go further with the example we used in the previous posts. The next post in this thread will treat errors in the implementation of the business process.

No comments:

Post a Comment