Enterprise Information Systems Patterns - Part X

EIS Patterns, Business Processes, and Workflow Engines
Every EIS is based on business processes, and it can be said that workflows are the computational realization of these processes. Therefore it is necessary to provide some workflow engine to EIS Patterns.

Basically, there are two types of workflow engines:
a) Associated to an application development platform: such as the ones found in Web application development environments, like Zope, or associated to databases, such as Oracle, or as part of Groupware environments. In this case, applications are developed "inside" the environment, using the engine's API.
b) Implemented as Libraries: using some programming language, a library of objects representing the workflow features is implemented, such as the State Machine as Python Decorators, or Ruby's AASM. In this case, you must use the libraries' objects to implement your engine.

Enters Fluidity & Extreme Fluidity
Fluidity was developed as a type (b) workflow engine, however, Extreme Fluidity turns it into a third type of workflow engine:
c) Inoculated & Expelled: using the dynamic nature of the underlying programming language, provide a way of making objects workflow-aware, and symmetrically, a way of turning these objects back to their initial structure when desired.
Why this? Because type (a) engines forces you to use a given environment to develop your applications, while type (b) forces you to use specific objects to implement workflows, most of times creating a mixed code with application specific and workflow specific statements.
With Extreme Fluidity (or xFluidity for short) it is possible to insert the code necessary to make your workflow run inside your business objects. In other words, they become workflow-aware objects, while keeping your programming style, standards, and patterns. In order to understand how this happens, let's check how Fluidity can be used when xFluidity is associated to it (the complete source code can be found here).
First, it is necessary to declare a template State Machine:

    class LoanProcess(StateMachine):
        state('requested')
        state('request_created')
        state('request_analyzed')
        state('refusal_letter_sent')
        state('loan_created')
        state('value_transfered')
        initial_state = 'requested'
        transition(from_='requested', event='create_loan_request', to='request_created')
        transition(from_='request_created', event='analyst_select_request', to='request_analyzed')
        transition(from_='request_analyzed', event='loan_refused', to='refusal_letter_sent')
        transition(from_='request_analyzed', event='loan_accepted', to='loan_created')
        transition(from_='loan_created', event='time_to_transfer_value', to='value_transfered')

Using xFluidity, the template is injected in another object - in this case a Process:

    def setUp(self):
        self.process = Process()
        template = LoanProcess()
        configurator = StateMachineConfigurator(template)
        configurator.configure(self.process)

Magically, the process object starts to respond to the state machine's events:

    def it_makes_the_process_respond_to_the_example_state_machine_events(self):
        self.process |should| respond_to('create_loan_request')
        self.process |should| respond_to('analyst_select_request')
        self.process |should| respond_to('loan_refused')
        self.process |should| respond_to('loan_accepted')
        self.process |should| respond_to('time_to_transfer_value')

As expected, the engine avoids the firing of transitions at wrong situations:

    def it_runs_the_example_acceptance_path(self):
        self.process.create_loan_request()
        self.process.current_state() |should| equal_to('request_created')
        # the line below means that if the process tries to fire loan_refused
        # when at 'request_created' state, an exception is generated
        self.process.loan_refused |should| throw(InvalidTransition)
        self.process.analyst_select_request()
        self.process.current_state() |should| equal_to('request_analyzed')
        #loan accepted
        self.process.loan_accepted()
        self.process.current_state() |should| equal_to('loan_created')
        self.process.time_to_transfer_value()
        self.process.current_state() |should| equal_to('value_transfered')

In that way, it is possible to use a workflow engine in your own development environment and using your own models. Fluidity also provides guards and state actions, not shown here for the sake of simplicity.

A Note on Workflow Notations
Fluidity is a state-based engine, which on those days of fancy business process notations may appear a bit old-fashioned. However, state machines represent a well known and easy to understand notation. EIS Patterns' Process and Movements objects are being developed in a way that they don't need to know which notation is in use, at least at the unit level - meaning that some code specific to a given notation may be used to "glue" elements at the application level.

Conclusion
Currently Fluidity and xFluidity are works in progress, including the expelling capabilities and some details on implementation of guards. When these features become fully functional, a Petri Net based engine will be developed. A clear limitation of Fluidity is that it only works for Python objects, but the necessity of developing in a given programming language is a limitation of all workflow engines, although some provide XML-like APIs.

Assorted Thoughts on Agilism X Traditionalism - Part IV

Some days ago I bumped again into an "old" internal discussion by email on the Agile 2009's talk "Lets stop calling it 'agile' ", which summary I copy below:
"
Agile development has grown a lot since its rebeleous 2001 start. In fact, it has grown to be the mainstream way of developing software. The time has come to drop the word "agile." Agile development is just modern practices in software development. There is no need to explicitly mark practices as Agile. There is no need anymore for opposing camps. Keeping the word Agile and things like "the Agile conference" is holding the development of modern SW development practices back. This session will be in debate form to discuss the above mentioned motion.
"
Some can find this radical. When I first read it one year ago, I also thought the same. However, reading it now I can clear understand the proposal, and it made me remember of my way through software processes.

During my undergraduation course I had contact with Yourdon's Structured Analysis as well as Object Oriented Analysis & Design, by that time (1990-1994), the first was mainstream and the second a new proposal which needed to be improved. However, the second one attracted me more, given that I wanted to use Object Oriented concepts the most, since my first contacts with C++ in 1991 I was already convinced that OO was a better way of programming.

First Experiences
Outside the classroom, my first professional contact with "analysis" occurred in 1993, when I took part of a Management Information System (MIS) development in Clipper and Structured Analysis and Design. On those days of waterfall cycles, someone did the analysis and design and I implemented the system. As expected, after deploying it, users asked for changes almost every week. Firstly I  implemented them and once a week updated the modeling artifacts, for maintenance purposes . Yes, first I changed the programs, because my users were eager to get the software running with the changes, and them, when had time, updated the models. Looking back I see how natural is the idea of using models only to understand the problem, and updating them when needed.

In early 1994 I inverted positions, acting as the analyst for another MIS, using Structured Analysis and a classical waterfall cycle. The implementation was successful until at least its deployment, later in the year. After that, I lost contact with it.

In the second semester of 1994 I entered a bigger Enterprise Information System project, with circa 15 developers and two consulting companies working on it. It was very uncommon environment, using IDEF artifacts for modeling, C++ for programming, and Sybase. Transformation from functional models to C++ methods were done during interesting CRC Cards sessions, and class diagrams were derived from Entity-Relationship Diagrams. Object-relational mapping was done according a set of very basic rules, created internally by the team. The only problem we had was the fact that some process models were prepared almost one year before we started to touch them. However, we had a very good business analyst (he was an Industrial Engineer) who re-checked all business process with the clients before they enter the programming phase. Therefore I can say that the process was interesting, however, the "waterfall way" of doing things created a lot of rework.

Before I forget, effort estimating in all cases was done by "expert opinion",  people didn't believe in Cocomo's use of constants and in Function Points counting - which needs a lot of things already defined to have a chance of being "accurate".  I could only remember my Software Engineering classes and started to see them as something closer to Alice in Wonderland than to an Engineering discipline.

Enters Object Modeling Technique (OMT)
However, it was only in 1995 that I had the first chance of using professionally an OO method in the whole process, specifically, I used the OMT method. OMT was interesting because it used a mixture of class and state diagrams with Data Flow Diagrams (DFD's) to describe its Functional Model. OMT was a product of its time: OO languages were becoming mainstream, but Structured Analysis was still the mainstream process paradigm.

Our Environment in 1995
In this year I moved back to my hometown, aiming to take part of the creation of the first big and public university in the region. We were a two men team, in partial time, working at the Math Laboratory - from where the Computer Science Laboratory would emerge years after. The mission was to develop a library management system to be used by the three campus' libraries. The university was new and many, many information systems were necessary. Library Management Systems where really expensive by that time, thus the university's president asked us to create the system.


Our Process in 1995
We decided to use a mixture of Prototyping Life Cycle with OMT's artifacts to build the system, since we had very few knowledge in the problem area (libraries). For more complex operations, we would use CRC cards to define how classes would interact. We decided to use Delphi 1.0, which allowed us to create nice GUI as well as use Pascal, instead of Visual Basic (which I hated). Moreover, my colleague was developing an object-relational mapping library in Pascal for his Master's Thesis, which gave us a cleaner and powerful way of doing Object-Relational Mapping (ORM). We resisted the temptation to use Delphi's components for direct access to the database for the sake of really using object orientation for coding business logic.


Firstly we drafted a list of high level requirements - separated in modules, and then we asked the librarian to prioritize them. Then we started to follow a process that we built on top of our experiences in previous systems:
1) Get the next priority.
2) Detail its requirements.
3) Create a prototypical GUI and a draft database to reflect the requirements.
4) Re-check requirements during GUI presentation to the user.
5) Model stuff in OMT.
6) When appropriate, use CRC cards to define classes' responsibilities and collaborators.
7) Write code ignoring the database*.
8) Write ORM and database code.
9) Present the implementation to the user.
10) If the user was happy with the results:
a) we deployed the new module and went back to 1)
else
b) we looped back to 5) if modeling was needed, 6) if changes in classes were likely to occur, even without new modeling, or 7) if only changes in algorithms were needed.


* We used an ancestor technique of what is called today "test doubles". In our case, collections of objects with typical values were created "by hand", so that we could test the algorithms. When we put the algorithms to work properly, we then implemented the persistence code, and finally we took way these "fake objects". Sometimes I developed algorithms and my colleague put things to work with the database, since he was the ORM library developer. We didn't want to waste time with persistence problems while we were trying to solve users' problems. Persistence was a pure technical question, not a main development concern.

Effort estimation was done before each of these "proto"-iterations, by experience, because I kept the same opinion regarding effort metrics. The project was really successful, we both left the university in the end of 1996, however it was used for years, until the university bought a new system, with external support from a development company.

I used this process more or less unchanged until 2000, when I had access to my first UML Case Tool, and started reading about the Unified Process and Eriksson-Penker's business modeling extensions for UML. I knew UML since 1997, however, by that time, and until 1999, I had only one project, which used OMT already, and I had no reasons to change from it to UML. I used UP variations until 2006/2007, sometimes without the expected output. And all times not fully implemented, since I thought many things were too bureaucratic to be used.


The main thing I learned from these days was that you must mix techniques and even create new ones to make the development process work for your environment, and not the opposite. Hardly you will find a process that fits exactly to your environment, team, culture, and problem. I've seen a lot of people eager to follow some guru or certification, and when things go wrong they blame themselves for not being able to do exactly "what must be done." They should blame themselves for not being able to adapt the process to their environment.


Another thing I can clear identify now is that some recent Agile techniques are modern versions of old programming tricks, those kind of hints shared during the coffee break, and that never appeared in the "software engineering" books.


Going back to the "drop the word agile"
I think my intimate history in dealing with development process is the same of a lot of others developers. In early 1990's, there were a lot of different Object Oriented notations and processes, all seeking to solve the same problems, in slightly different ways. Hybrid methods such as OMT (and its DFDs) were told to be the ideal solution for a world in transition. And for me they seemed to be.

Then came UML and UP, both bringing some standardization to the software development world. Finally, Model Driven Engineering (MDE) and Model Driven Development (MDD) could realize their full potential. And they did, given that I think their potential has finished. At least, the potential to be innovative in research terms, and to answer to constant changes in practice terms.

I agree with the phrase "Agile development is just modern practices in software development." Yes, one should try to list a single innovation that came from the MDD world in the last few years. Every "new" MDD technique that I saw recently, either was repetition, either was "extreme cases", hardly useful.

Many people still resist to Test Driven Development (TDD), for instance, because they can't understand how tests can be used for design. There is a common misunderstanding that design is related only to blueprints, thus, design = modeling in software development. What about Stress Analysis, mostly based on Math and Physics, instead of drawings... so design is not only about blueprints, and, actually, if you can rely on Math to do the design, it is more likely that your design will work. As I said before, coding is closer to Math than modeling.

For a developer to understand how TDD can drive design, he/she must practice it. You can draft a model to understand the problem in the beginning, however, given that you are going to interact with tests - which are code - and the code that answer to them, you are going to evolve the design as the need for testing evolves. An tests evolve as the implementation of requirements evolves. The problem is that many decision makers are those that "don't program anymore", so will "never" be convinced, unless some programmer show to them how things work.

There is also an economic and cultural reason for people not recognizing agilism as the "modern" software engineering: agile techniques mostly were - and still are - nurtured by individuals and communities of developers, in opposition to big consultancy companies. Because of this, Agile techniques will take longer to enter the EIS world. People will repeat to the exhaustion "Why big companies like A or B don't use a lot of Agile if it is so good?", and will answer to themselves "because it doesn't scale!". Isn't because you don't need expensive tools and related consultancy to adopt them? Isn't because of culture? Isn't because a lot of people who stopped programming after becoming project managers are afraid of seeing part of their daily activities labeled "waste", thus endangering their jobs?

I witnessed similar reactions in the early 1990's regarding Object Orientation, and if the "legacy guys" were right, I would be saying stuff like "Structured Analysis rules!".

So, drop the word Agile!

Proof of Concept for the BLDD Tool - Part VI

We have released a compilation of the posts with some more explanations on our proposal for the Business Language Driven Development (BLDD) draft, the technical report can be found here.

There is a lot of work to do on top of BLDD, such as:
- Defining in more detail the use of a companion textual Domain Specific Language (DSL). Probably with support of a Rule Engine.
- Implement an usable tool, we are investigating an extension of Drools for this purpose. Drools seems to be a good choice because it is BPMN compatible, implements a Rule Engine, and an Eclipse plugin. And, of course, it is open source.
- Implement BLDD on top of an ERP, our choice is ERP5, for the reasons listed on the first post of this series. This case study should show the applicability of the proposal.

You can find more "future work" in the report. We are open to collaboration and discussion.

Proof of Concept for the BLDD Tool - Part V

Last week I bumped into what I think is one of the firsts academic papers on BDD to be published in a scientific journal. We have published three technical reports in arxiv.org, but they weren't peer reviewed: Filling the Gap between Business Process Modeling and Behavior Driven Development, Mapping Business Process Modeling constructs to Behavior Driven Development Ubiquitous Language and  A Tool Stack for BDD in Python.

This paper is on applying Model Driven Development (MDD) techniques to BDD, following the principles presented in the Agile for MDD white paper. The authors use Foundational UML (fUML), which defines a basic virtual machine for UML, to create bUML, a tool to support BDD activities that automatically updates the project status.

Our approach holds some differences in relation to theirs:
1) Although the examples in the paper are too "recursive" (given-when-then is used to describe the creation of stories and scenarios) to check details of their proposal, it is obvious that they follow MDD, in fact, at some point they say "The generated code intends to be complete, with no placeholders for the developer to fill out." We do the opposite: we leave placeholders to be filled out.
However, I still need to see some more practical example to affirm this.
2) Our proposed tool is meant to run step by step, I saw no reference to this kind of feature in bUML's description.
3) They use OCL as the basis for textual modeling, we propose to use a more natural should language. We envision the use of (some) should-dsl to insert and describe conditions (logical, acceptance) for the tests. OCL is a standard, however, should-dsl is closer to the user's language.

I need some more time to check bUML - I couldn't find the software or real world examples.  What I can say now is that they follow MDD, we follow Agile, so our proposals differ in the way we intend to implement and use the tools.

Proof of Concept for the BLDD Tool - Part IV

One way of making a tool prove its utility is using it in scenarios where things go wrong. Figure 1 shows what happens if the code implemented is not in compliance with the requirements. The user will see a message saying that the scenario didn't pass.

Figure 1: Error generated by code not compliant to requirements

In the message in Figure 1, the error was generated because the last step was not implemented correctly: the message "9 sales awaiting to be sent" was not generated by the system, therefore, the developer must check the code and correct it. In that way it is possible to immediately identify where the system must be improved to work as expected, which is very useful when it is still in development, or when changes are needed.

Imagine that the "9 sales awaiting to be sent" message represents an improvement to this business process. I insert it on my specifications and run the simulation, so that I can identify exactly the point where the system must be modified to become compliant to the requirements. This is exactly what BDD proposes, the difference here is that we are joining a graphical representation to it and giving the user the option of running the business process step by step and see how the system is behaving.

In other words, the user can check a live process and the live system that answers to this given process. If anything goes wrong, the tool will identify what and where, making corrections easier.

It is important to note that this is a proof of concept, my idea was to launch it quickly so that more people can discuss and contribute to both the method and the tool. Besides Woped, we used Cucumber, which in turn uses BDD's Ubiquitous Language (Given-When-Then), however, as I said in this thread's previous post, we may define an UL for every BP representation and make the underlying text mirror the representation. That's our next step.

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.

Proof of Concept for the BLDD Tool - Part II

One thing in BDD that always bothered me is the fact that things like parallel threads are not clearly represented, you simply use ANDs in the Then clauses and that's it. This kind of situation became even more clear to me when we mapped UML Statechart Diagrams' constructs to BDD's Given-When-Then, or GWT for short (you can find this report here).

Some agilists will complain that I am trying to introduce unnecessary complexity into BDD, however, EIS are complex in general, and many times they need to implement concurrency and other sophisticated constructs. Therefore, our tests MUST verify these conditions. Given that instead of filling forms we want to use executable documentation, we must prepare our testing toolset to deal with the intrinsic system complexity, of course, having the Keep It as Simple as Possible (KISP) principle in mind.

Continuing the example that was started on the previous post, we now reached an AND-Split, making the tests automatically fill the form with the Credit Card data, and driving the validation process to a stop at the AND-Split, waiting for the user to click on it. When the user clicks on it, we see the screen on Figure 1, which shows the equivalent GWT construct for our AND-Split, being the "Wait for confirmation..." part equivalent to the upper flow of the split.

Figure 1: The equivalent GWT construct for the AND-Split

As the user clicks OK, two subsets of tests excite in parallel two different parts of the system: the one that tests the sending of an email (the lower flow of the split, not shown here since there is no user interaction in it) and the inventory-checking procedure, of which equivalent in GWT is presented by Figure 2. After the user clicks OK, the process will go forward, reaching an OR-Join, as shown in Figure 3.

Figure 2: Excitation of inventory-checking procedure

Figure 3: An OR-Join is reached

Since we are using BDD tools for implementing our proof of concept, we were forced to provide hand-written GWT constructs, however, we envision the definition of specific languages for each BP representation.  For instance, for Statechart Diagrams we can use State-Event-Action tags to map from the graphical representation to tests.

It is important to note that we don't propose to substitute GWT constructs, but to complement them, because simpler requirements can be described without the need of BP models. In other words, we envision tools that can deal with different languages, that's why the name for our general proposal is not BLDD, but SLDD - Shared Language Driven Development.

Proof of Concept for the BLDD Tool - Part I

Executable Documentation is a vital element for achieving end to end testing and thus real code quality (instead of "quality by annotation"). Understanding that BPM is an important tool for EIS development, I proposed Business Language Driven Development (BLDD) as an extension to BDD (to understand this better, including a discussion on names for this technique, please follow the links of my previous posts).

The core idea is to use some Business Process (BP) Modeling tool to run, step by step, a given process representation and, at each step, excite the associated automated tests, making the system to pop-up accordingly as the user clicks on the representation. It is the same thing we see when we use tools such as Selenium, however, in that case, we would run the tests step by step and, instead of using textual descriptions of the requirements (like in BDD), we use a BP Model.

We know that there isn't a real standard for Business Process Modeling, in fact there are various, such as UML Models, Petri Nets, BPML, derivations of these etc. We also know that many EIS are based on Workflow Engines, and each of these engines has particularities. Therefore I decided to open two fronts:

1) Use a generic BP representation: the choice was Petri Nets, because I can derive others representations from them, such as Statechart and Activity Diagrams, and also there is the "Token Game", which is the simulation of the BP execution.
2) Use some workflow engine to work on top of it. The obvious choice for us was working with ERP5, an open source ERP (FOS-ERP), based on Zope, which in turn uses a state-based Wf engine, DCWorkflow. ERP5 was an obvious choice because (i) we are partners of this project since 2002, (ii) it is open, so we have access to all its code, (iii) we like state-based workflows.


I will focus now on (1) and will be back to (2) some weeks from now.

The first step for achieving (1) was to implement a proof of concept, using some Petri Nets open source tool that would be able to run Token Games, so that we could animate our model. During last August, Rodrigo Manhães, one of my associated researchers, prepared a proof of concept based on Woped.

Using an example PN, he created a very basic application, without taking care of the application logic or GUI - the goal is to show our proposal, not discuss BPM or GUI. The screenshot in Figure 1 shows the moment when the user reaches an OR-Split and must choose which path to follow in the workflow.

Figure 1: An user reaches an OR-Split in the example process

The OR-Split in Figure 1 is implemented as a list box. Appropriate tests excite this code, as shown in Figure 2.

Figure 2: The equivalent test run for the OR-Split

Remember that tests "are by example", therefore, the user doesn't interact with the real system, instead, he/she is a spectator of the tests, launching them by choosing which path to follow in the PN. After checking if the system is implemented the way he/she expected, the user closes the GUI and then choose the path equivalent to Credit Card, making the test code to run this option, which, in turn, makes the form in Figure 3 to pop. Meanwhile in Woped, the user can see a message that shows which scenario was chosen, including the Given-When-Then equivalent instructions (Figure 4).

 Figure 3: Credit Card data form

 Figure 4: Message with equivalent GWT.

When the user clicks in OK, the flow goes to the next step, an AND-Split (Figure 5) and the tests responsible for filling the form will run, as shown in Figure 6.

 Figure 5: The process enters an AND-Split

Figure 6: Running the test for filling Credit Card data

Although we had to implement specific logic for each of the PN structures (I will start discussing this on the next post of this series), the next steps for verifying the consistency between the BP model and the system are similar.

The goal of this post was to show our basic idea: make the user run the business process and see immediately how the system is behaving. If there isn't correspondence between requirements and code (originated by process change or code wrongly implemented), errors will appear, automatically indicating where the system is not compliant to the requirements described by the model. Error situations will be shown in the next posts.

Deciding on the names for BDD extentions

On a previous post I talked about our proposal of extending Behavior Driven Development (BDD) to use other languages than then "classic" Given-When-Then (GWT), in special, but not limited to, Business Process Modeling (BPM) artifacts, such as Petri Nets, Statechart or Activity Diagrams. Today we decided at NSI to use two terms to refer to our proposal:

a) When referring to the idea of using a composition of languages, previously agreed by all stakeholders, we are going to call it Shared Language Driven Development (SLDD).
b) The specific case of using BPM + domain specific language (DSL) as an input for the BDD machinery is called Business Language Driven Development (BLDD).

In other words, SLDD is the general proposal and BLDD is the proposal for EIS. You can also interpret like this: SLDD is a generalization of BDD, and BLDD is an extension to BDD that uses BPM.

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...

BPDD | BLDD| CLDD | SLDD, Dynamic Business Process Composition, The Future of ERP, REST, and Here We go!

The economic dynamism has been pushing a lot enterprise systems development. Some business processes must be altered and/or re-composed frequently to meet changing business conditions. Dynamic Business Process (or Service) Composition represents a set of techniques that try to provide the basis for achieving this dynamism.
Also, some say the future of ERP is to become process integration frameworks. Instead of integrated modules, ERPs would provide the means for quickly integrating disparate business processes living in different systems - in fact, this is an old Supply Chain Management need, far away from be quickly (and cheaply) fulfilled in real world applications.

Many proposals are based on the use of Intelligent Agents, Ontologies and other automated decision making supportive methods. Agents and ontologies can be very, very useful for filtrating, among hundreds or thousands of options, the few dozen that may interest to a given organization. Ontologies are very, very useful for helping finding the points of integration for these process. However, I still think that in the end, it will be a human-decision-maker and a human-programmer who will choose the best combination of processes and implement their integration respectively.

Experience says that even if the leading-edge organizations can reach the Nirvana of totally automated dynamic composition of business process, we are going to find most of smaller organizations striving to do this "manually".

Therefore, I think there is still room (and a lot of it) for developing supportive techniques for "semi-automated" Business Process Composition (BPC). And I believe our proposal of having a Business Process extension of BDD (we are deciding which name to use - BPDD, BLDD, CLDD, or SLDD - see my previous post) associated to tools like Restfulie may offer a powerful method to implement executable documentation for business applications that demand integration of disparate applications and their business processes.

I can envision a business analyst building a graphical representation of the macro-process, using a shared development language - understandable by all stakeholders (see my previous post),  and, after implemented the automated tests, checking the live application running as he/she follows (clicks) on the different paths of a workflow representation. As the macro-process changes, the tool will visually identify where and what to change accordingly so that the system becomes business compliant again. That would be a way of building a "next-generation ERP" or "next-generation Enterprise Information Systems" through a combination of visually manipulating BP representations and Test Driven Development (TDD).

Well, that was one more teaser to the matters I want to discuss here, I will go back to it latter.

Business Process Driven Development - BPDD

At NSI we are working on adding Business Process (BP) representations to Behavior Driven Development (BDD). I mean, substituting the "classic" Given-When-Then (GWT) by some BP graphical representation, such as Petri Nets or UML Statechart Diagrams.

The core idea, already working as a proof of concept using  Woped, is to allow a final user to run a business process in a step by step way and then see the living system pop up as he/she clicks on the activity elements, such as edges in a Petri Net. In that way we provide executable documentation using BP graphical representations, delivering BDD to the realm of Enterprise Information Systems.

Initially, we thought of calling this extension to BDD "Business Process Driven Development" (BPDD), however, we realized that a lot of related but different methods use this name with many different meanings. Then I thought of other names, and leave to my readers the choice of the best one:


a)Common Language Driven Development (CLDD)
The use of common language for users and developers (yes, another name for UL...)
b)Business Language Driven Development (BLDD)
The use of the user's business language as a common language.
c)Shared Language Driven Development (SLDD)
The use of a shared language, resulting of an agreement between users and developers.


(b) is interesting because keep our focus on business systems. However, I think we can use the concept of UL for scientific systems, for instance. So "business" may not map well for these systems.
(c) is interesting because it shows that users and developers agreed to use a shared language.
Yes, I know that UL's definition may cover all that, but I don't want to call ULDD!

We prepared two technical reports and posted them at Arxiv.org, please check them and help us to find a nice name to this BDD extension:
a) Filling the Gap between Business Process Modeling and Behavior Driven Development
b) Mapping Business Process Modeling constructs to Behavior Driven Development Ubiquitous Language

PS: in fact I believe that the Ubiquitous Language (UL) is not a single language, but a composition of languages. For instance, we can mix mathematical formulas and plain text into a process representation so that this representation is the closest possible to the "real thing". In other words, since there are languages such as should-dsl, we could also have things like math-dsl, or logistics-dsl, used externally and internally.
I will go back to this later on...