This example will introduce us to all the basic jPDL nodes used in common situations for modeling real world scenarios. That’s why this article will cover the following topics:

• Introduction to the recruiting example
• Analyzing the example requirements
• Modeling a formal description
• Adding technical details to our formal description
• Running our processes

The idea of this article is to show you a real process implementation. We will try to cover every technical aspect involved in development in order to clarify not only your doubts about modeling, but also about the framework behavior.

How is this example structured?

In this article, we will see a real case where a company has some requirements to improve an already existing, but not automated process.

The current process is being handled without a software solution, practically we need to see how the process works everyday to find out the requirements for our implementation. The textual/oral description of the process will be our first input, and we will use it to discover and formalize our business process definition.

Once we have a clear view about the situation that we are modeling, we will draw the process using GPD, and analyze the most important points of the modeling phase. Once we have a valid jPDL process artifact, we will need to analyze what steps are required for the process to be able to run in an execution environment. So, we will add all the technical details in order to allow our process to run.

At last, we will see how the process behaves at runtime, how we can improve the described process, how we can adapt the current process to future changes, and so on.

Key points that you need to remember

In these kind of examples, you need to be focused on the translation that occurs from the business domain to the technical domain. You need to carefully analyze how the business requirements are transformed to a formal model description that can be optimized.

Another key point here, is how this formal description of our business scenario needs to be configured (by adding technical details) in order to run and guide the organization throughout its processes.

I also want you to focus on the semantics of each node used to model our process. If you don’t know the exact meaning of the provided nodes, you will probably end up describing your scenario with the wrong words.

You also need to be able to distinguish between a business analyst model, which doesn’t know about the jPDL language semantics and a formal jPDL process definition. At the same time, you have to be able to do the translations needed between these two worlds. If you have business analysts trained in jPDL, you will not have to do these kind of translations and your life will be easier. Understanding the nodes’ semantics will help you to teach the business analysts the correct meaning of jPDL processes.

Analyzing business requirements

Here we will describe the requirements that need to be covered by the recruiting team inside an IT company. These requirements will be the first input to be analyzed in order to discover the business process behind them.

These requirements are expressed in a natural language, just plain English. We will get these requirements by talking to our clients—in this case, we will talk to the manager of an IT company called MyIT Inc. in order to find out what is going on in the recruiting process of the company.

In most cases, this will be a business analyst’s job, but you need to be aware of the different situations that the business scenario can present as a developer. This is very important, because if you don’t understand how the real situation is sub-divided into different behavioral patterns, you will not be able to find the best way to model it.

You will also start to see how iterative this approach is. This means that you will first view a big picture about what is going on in the company, and then in order to formalize this business knowledge, you will start adding details to represent the real situation in an accurate way.

Business requirements

In this section, we will see a transcription about our talk with the MyIT Inc. manager. However, we first need to know the company’s background and, specifically, how it is currently working. Just a few details to understand the context of our talk with the company manager would be sufficient.

The recruiting department of the MyIT Inc. is currently managed without any information system. They just use some simple forms that the candidates will have to fill in at different stages during the interviews. They don’t have the recruiting process formalized in any way, just an abstract description in their heads about how and what tasks they need to complete in order to hire a new employee when needed.

In this case, the MyIT Inc. manager tells us the following functional requirements about the recruiting process that is currently used in the company:

We have a lot of demanding projects, that’s why we need to hire new employees on a regular basis. We already have a common way to handle these requests detected by project leaders who need to incorporate new members into their teams.

When a project leader notices that he needs a new team member, he/she will generate a request to the human resources department of the company. In this request, he/she will specify the main characteristics needed by the new team member and the job position description.

When someone in the human resources team sees the request, they will start looking for candidates to fulfill the request. This team has two ways of looking for new candidates:

• By publishing the job position request in IT magazines
• By searching the resume database that is available to the company

When a possible candidate is found through these methods, a set of interviews will begin. The interviews are divided into four stages that the candidate needs to go through in order to be hired.

These stages will contain the following activities that need to be performed in the prescribed order:

• Initial interview: The human resources team coordinates an initial interview with each possible candidate found. In this interview, a basic questionnaire about the candidate’s previous jobs and some personal data is collected.
• Technical interview: During the technical interview stage, each candidate is evaluated only with the technical aspects required for this particular project. That is why a project member will conduct this interview.
• Medical checkups: Some physical and psychological examinations need to be done in order to know that the candidate is healthy and capable to do the required job. This stage will include multiple checkups which the company needs to determine if the candidate is apt for the required task.
• Final acceptance: In this last phase the candidate will meet the project manager. The project manager is in charge of the final resolution. He will decide if the candidate is the correct one for that job position. If the outcome of this interview is successful, the candidate is hired and all the information needed for that candidate to start working is created.

If a candidate reaches the last phase and is successfully accepted, we need to inform the recruiting team that all the other candidate’s interviews need to be aborted, because the job position is already fulfilled.

At this point, we need to analyze and evaluate the manager’s requirements and find a graphical way to express these stages in order to hire a new employee. Our first approach needs to be simple and we need to validate it with the MyIT Inc. manager. Let’s see the first draft of our process:

With this image, we were able to describe the recruiting process. This is our first approach that obviously can be validated with the MyIT Inc. manager. This is our first draft that tells us how our process will appear and it’s the first step in order to define which activities will be included in our model and which will not. In real implementations, these graphs can be made with Microsoft Visio, DIA (Open Source project), or just by hand. The main idea of the first approach is to first have a description that can be validated and understood by every MyIT Inc. employee.

This image is only a translation of the requirements that we hear from the manager using common sense and trying to represent how the situation looks in real life. In this case, we can say that the manager of the MyIT Inc. can be considered as the stakeholder and the Subject Matter Expert (SME), who know how things happen inside the company.

Once the graph is validated and understood by the stakeholder, we can use our formal language jPDL to create a formal model about this discovered process.

The idea at this point, is to create a jPDL process definition and discard the old graph. From now on we will continue with the jPDL graphic representation of the process. Here you can explain to the manager that all the new changes that affect your process will go directly to the jPDL defined process.

Until now our artifact has suffered the following transformations:

The final artifact (the jPDL process definition) will let us begin the implementation of all the technical details needed by the process in order to run in an execution environment.

So, let’s analyze how the jPDL representation will look for this first approach in the following figure:

At this point we don’t add any technical details, we just draw the process. One key point to bear in mind in this phase is that we need to understand which node we will use to represent each activity in our process definition.

Remember that each node provided by jPDL has its own semantics and meanings. You also need to remember that this graph needs to be understood by the manager, so you will use it in the activity name business language. For this first approach we use state nodes to represent that each activity will happen outside the process execution. In other words, we need to inform the process when each activity ends. This will mean that the next activity in the chain will be executed. From the process perspective, it only needs to wait until the human beings in the company do their tasks.