CONTENTS

7
GLOBAL CONTEXT..........................................................................................................................7
9
GENERAL INTRODUCTION............................................................................................................9
1

INTRODUCTION........................................................................................................................9

ORGANIZATION PROFILE......................................................................................................9

SERVICES AND WORKING AREAS............................................................................................................9

3

PROJECT MOTIVATION.........................................................................................................11

3.1

IN:TIME MOTIVATION............................................................................................................11

3.2

STUDENT MOTIVATION.............................................................................................................11

PROJECT DESCRIPTION.......................................................................................................11

PROJECT METHOGOLOGIY................................................................................................14

5.1

MODEL-DRIVEN DEVELOPMENT.............................................................................................14

5.2

AGILE MODEL-DRIVEN DEVELOPMENT METHODOLOGY......................................................15

CONCLUSION...........................................................................................................................18

CHAPTER II : PROJECT SCOPE AND REQUIREMENTS........................................................................19

1

INTRODUCTION......................................................................................................................19

1.1

ENTERPRISE CONTENT MANAGEMENT (ECM) OVERVIEW..................................................19

1.1.1

Alfresco Overview................................................................................................................20

1.1.2

Alfresco Architecture............................................................................................................20

1.1.3

xxx........................................................................................................................................21

1.1.3.1

Alfresco content repository..............................................................................................21

1.1.3.2

Content models................................................................................................................21

1.1.3.3

Content type.....................................................................................................................22

1.1.3.4

Workflow models.............................................................................................................22

1.1.3.5

Process definition.............................................................................................................22

1.1.3.6

Task type..........................................................................................................................22

1.2

BUSINESS PROCESS MANAGEMENT (BPM) OVERVIEW.........................................................23

1.2.1

Definition..............................................................................................................................23

1.2.2

BPM Actors...........................................................................................................................23

1.2.3

BPM Implementation Engine................................................................................................24

1.2.4

Business Process Modeling...................................................................................................25

1.2.4.1

Standard Business Process Modeling Techniques............................................................25

1.2.4.2

ITS Modeler Modeling Techniques..................................................................................25

1.2.5

Change Management.............................................................................................................25

1.2.5.1

Common Change Management Needs.............................................................................25

1.2.5.2

ITS Modeler Change Management Needs........................................................................26

SOLUTION ESSENTIAL REQUIREMENTS.........................................................................26

RELATED WORK.....................................................................................................................28

CANDIDATE ARCHITECTURE.............................................................................................29

CONCLUSION...........................................................................................................................30

CHAPTER III: BACKGROUND - DEVELOPMENT TOOLS & DOMAIN SPECIFIC

LANGUAGES.....................................................................................................................................32
1

INTRODUCTION......................................................................................................................32

SOFTWARE DEVELOPMENT TOOLS..................................................................................32

2.1

DEVELOPMENT TOOLS CLASSIFICATION:...............................................................................32

2.1.1

Command-line vs GUI Tool..................................................................................................33

2.1.2

General-purpose vs. Domain-Specific Tool.......................................................................33

2.2
3

DEVELOPMENT TOOLS CONSIDERATIONS STANDARDS..........................................................34

DOMAIN SPECIFIC LANGUAGES........................................................................................35

3.1

INTRODUCTION TO DSL...........................................................................................................36

3.1.1

Definition..............................................................................................................................36

3.1.2

DSL Categories.....................................................................................................................36

3.1.3

DSL components...................................................................................................................37

3.2
4

DSL AND MDD.........................................................................................................................37

CONCLUSION...........................................................................................................................38

CHAPTER IV : SOLUTION APPROACH......................................................................................39

1

INTRODUCTION......................................................................................................................39

SOLUTION OVERVIEW..........................................................................................................39

DSL DESIGN..............................................................................................................................40

3.1

DOMAIN ANALYSIS....................................................................................................................41

3.2

THE CONTENT DSL..................................................................................................................42

3.2.1

The Content Model...............................................................................................................42

3.2.2

The Content Meta-Model......................................................................................................43

3.2.3

The content DSL syntax........................................................................................................44

3.3

THE BUSINESS PROCESS DEFINITION DSL.............................................................................46

3.3.1

The Business Process Definitions Model.............................................................................46

3.3.2

The Business Process Definition Meta-Model.....................................................................47

3.3.3

The Business Process Definition DSL syntax......................................................................48

3.4

THE FORM DSL........................................................................................................................50

3.4.1

The Form model....................................................................................................................50

3.4.2

The form meta-Model...........................................................................................................50

3.4.3

The form DSL syntax............................................................................................................51

EDITOR DESIGN AND IMPLEMENTATION.......................................................................53

4.1

EDITOR OVERVIEW...................................................................................................................53

4.1.1

Visual Programming Language.............................................................................................53

4.1.2

Web based development tool.................................................................................................53

4.1.3

Integrated development environment....................................................................................54

4.2

EDITOR DESIGN........................................................................................................................54

4.2.1

Content Management Use Case.............................................................................................55

4.2.2

Workflow Management Use Case.........................................................................................57

4.2.3

ITS Modeler navigation diagram...........................................................................................61

4.2.4

The ITS Modeler Mockups...................................................................................................62

4.2.4.1

The content Modeler Mockups.........................................................................................62

4.2.4.2

The workflow Modeler Mockups.....................................................................................63

4.3

EDITOR IMPLEMENTATION.......................................................................................................64

4.3.1

Technical choices..................................................................................................................64

4.3.2

Editor architecture.................................................................................................................64

4.3.2.1

The Modeler workbench..................................................................................................65

4.3.2.2

The Modeler Global Handler:..........................................................................................66

4.3.2.3

The Modeler workspace Handler.....................................................................................66

4.3.2.4

The Modeler Explorer Handler........................................................................................66

4.3.3

User Interface Design Patterns..............................................................................................67

4.3.4

ITS Modeler Screen Captures...............................................................................................70

EXECUTION ENGINE DESIGN AND IMPLEMENTATION..............................................71

5.1

EXECUTION ENGINE OVERVIEW..............................................................................................71

5.2

ITS MODELER EXECUTION ENGINE ARCHITECTURE............................................................71

5.2.1

Validation Component...........................................................................................................74

5.2.2

Generation Components........................................................................................................74

5.2.3

Translation Component.........................................................................................................76

5.2.4

Deployment Component.......................................................................................................77

5.3

ITS MODELER EXECUTION ENGINE BEHAVIOR DETAILS......................................................77

5.4

IMEE IMPLEMENTATION DETAILS...........................................................................................79

5.4.1

Project development: Maven Alfresco SDK..........................................................................79

5.4.2

Alfresco Web Scripts and Web Script Framework.................................................................79

5.4.3

Implementation Design patterns............................................................................................80

5.4.4

IMEE extensibility features...................................................................................................82

THE ITS MODELER MOBILE TOOLBOX...........................................................................84

6.1

INTRODUCTION.........................................................................................................................84

6.2

CROSS-PLATFORM FRAMEWORK BENCHMARKING................................................................84

6.3

THE APPCELERATORS TITANIUM FRAMEWORK....................................................................85

6.3.1

Titanium framework overview..............................................................................................85

6.3.2

The Alloy MVC framework..................................................................................................85

6.4

THE ITS MODELER MOBILE TOOLBOX IMPLEMENTATION DETAILS....................................86

6.4.1

IMMT Architecture...............................................................................................................86

6.4.2

IMMT Integration and Behavior...........................................................................................88

CONCLUSION...........................................................................................................................88

CHAPTER VI : RESULT VALIDATION.........................................................................................90

1

INTRODUCTION......................................................................................................................90

ITS MODELER ACHIEVEMENT LEVEL.............................................................................90

ITS MODELER IMPACT MEASUREMENT.........................................................................90

CONCLUSION...........................................................................................................................92

CHAPTER VII : GENERAL CONCLUSION & PERSPECTIVES..............................................93

BIBLIOGRAPHY..............................................................................................................................94

Figure 1: IN:TIMEs working areas.....................................................................10

Figure 2: Sequential BPMS Implementation Methodology.........................................12
Figure 3: Parallel BPMS Implementation Methodology.............................................13
Figure 4: ITS Modeler overview........................................................................14
Figure 5: ITS Modeler project methodology lifecycle..............................................16
Figure 6: project scheduling overview...............................................................17
Figure 7: Project introduction & Envisioning Iteration............................................17
Figure 8: Development Iteration details.............................................................17
Figure 9: Alfresco ECM Overview[6]...................................................................20
Figure 10: Alfresco ECM Architecture[7].............................................................21
Figure 11: Alfresco storage mechanism vs Relational Storage....................................22
Figure 12: The Workflow Model and the Process Definition [10].................................23
Figure 13: BPM Actors...................................................................................24
Figure 14: Activiti BPM Engine.........................................................................24
Figure 15: ITS Modeler Candidate Architecture.....................................................29
Figure 16: DSL ingredients..............................................................................37
Figure 17: The ITS Modeler Overview.................................................................39
Figure 18: Modeler DSL design.........................................................................41
Figure 19: Alfresco workflow requirements.........................................................41
Figure 20: Content Model...............................................................................42
Figure 21: Content DSL Meta-Model...................................................................43
Figure 22: Content DSL Concrete Syntax.............................................................45
Figure 23: The Workflow Model........................................................................46
Figure 24: The Workflow Meta-Model.................................................................47
Figure 25: The Workflow DSL Concrete Syntax......................................................49
Figure 26: The Form Model.............................................................................50
Figure 27: The Form Meta-Model......................................................................51
Figure 28: The Form DSL Concrete Syntax...........................................................52
Figure 29: The Content Management Use Case diagram...........................................55
Figure 30: The Workflow Management Use Case Diagram.........................................57
Figure 31: The ITS Modeler navigation diagram.....................................................61
Figure 32: The content Modeler Mockups Initial view.............................................62
Figure 33: The content Modeler Mockups Edit view................................................62

Figure 34: The workflow Modeler Mockups Intial view............................................63

Figure 35: The workflow Modeler Mockups Edit View..............................................63
Figure 36: The ITS Modeler Editor Architecture.....................................................65
Figure 37: The ITS Modeler Execution Engine architecture.......................................73
Figure 38: The Validation Component package diagram...........................................74
Figure 39: The Generation component package diagram.........................................75
Figure 40: The Translation component package diagram..........................................76
Figure 41: The Deployment component package diagramme.....................................77
Figure 42: The Content Model generation sequence diagram....................................78
Figure 43: Alfresco Web Scripts Types [23]..........................................................80
Figure 44: Alfresco Web Script Framework Architecture [24]....................................80
Figure 45: Facade Design Pattern Implementation.................................................81
Figure 46: Dependency injection in the Execution Engine........................................81
Figure 47: The Content Model creation Process....................................................82
Figure 48: IMEE External Extensibility feature......................................................83
Figure 49: Titanium Architecture [24]................................................................85
Figure 50: Alloy Framework Elements................................................................86
Figure 51: The ITS Modeler Mobile ToolBox Architecture..........................................87

CHAPTER 0

GLOBAL CONTEXT

The amount of data available within the grasp of companies is constantly growing; the rise
of exponential amounts of unstructured information in all forms, calls for a content
management solution.
ECM or Enterprise content management aim to preserve and make sense of the companys
internal data, it manages the whole life cycle of their contents, from the capture to the
archiving, through a set of extensions related to document and workflow management for
collaboration.
Business process management (BPM), as the name indicates, falls under the management
branch of ECMs. BPM aims to make the companies workflow more effective, more efficient
and more capable of adapting to an ever-changing, highly competitive environment.
This presents a very promising prospect for companies, allowing them a better grasp of
their content and giving them a competitive advantage. Yet, it doesnt come without its
fair share of complexity.
Despite the current abstraction efforts, implementing workflows still a difficult expensive
endeavor in terms of money, resources and time. It relies on the collaboration of different
entities: technical, non-technical.
This becomes exceedingly more challenging when we consider different target
environments, such as the web or the mobile. Companies may have been able to avoid
considering these environments in the past, but with the growing popularity and
accessibility of mobile devices, it no longer is the case.
This presents the global context of our project; entitled Design and Implementation of a
Multi-platform Business Process and Content Modeler. IN:TIME Solutions feels that it will
be important to establish a next-gen Business Process development practices and
methodologies. One way to improve the productivity, the maintainability and the overall
quality of ECM/BPM solutions would be to build a web based visual programming tool.
On one hand, this tool will abstract the deep complexity faced by developers when
implementing business processes and in the other hand, it will eliminate the dependency

between business user and technical user: Business users will go far beyond the designing
of processes and become able of implementing it.
Not only that, it will allow the possibility to automatically generate a mobile version of the
Business Processes, reducing what was a very lengthy complex process to a click of a
button.
This report is laid out in 5 sections, in which I will detail my solution from inception to
validation, as follows is a brief description of each chapter:
In the first chapter I will present the host organization and the motivation behind the
project.
In the second chapter I will discuss the scope of the project and detail the requirements.
In the third chapter I examine will software development tools concepts and their
relationship with Domain Specific Languages (DSL) as it is the background of the proposed
approach.
In the fourth chapter I will provide an overview of the solution, followed by a detailed
presentation of the overall sub-elements.
In the fifth chapter, I will conclude with an evaluation of the designed Modeler compared
to the expressed requirements.
Finally I will present the conclusions that can be drawn from this project and the
perspectives that might be sketched through this solution.

CHAPTER I

GENERAL INTRODUCTION

1 INTRODUCTION
Its obviously important to present the story and the philosophy behind this project, and
thus, defining its scope and position in the company strategy.
The project context is described through this chapter from the way IN:TIME present it to
the how, me as an intern, adopt it and define the methodology used to implement it.
Defining those essentials elements will give an overview of a non-standard implementation
approach of a Multiplatform Business Process and Content Modeler.

2 ORGANIZATION PROFILE
IN:TIME Solutions is an international software supplier, partly owned by the Saudi Arabian
Future Horizons for Investment Group (FHI) and on the shores of Lac Tunis, Jeddah and
Riyadh at the Saudi Arabia.
As its name suggests, IN:TIME Solution company deliver in time solutions beyond the high
expectations. IN:TIME purpose is to help its customers run their businesses more efficiently
and gain greater insight into their business activities and to provide them with lasting
benefits by automating their business processes. In fact, it offer a broad spectrum of
complex, medium and small scale IT applications covering a wide range of business
requirements.

Services and Working Areas

IN:TIMEs working areas are described hierarchically by this pyramid, from the Data
Integration to the knowledge Management.

Fi gure 1 : IN:TIME s worki ng are as

Considering those elements, IN:TIME released several products around its Alfresco Based
Framework.

Mail room Management: A complete solution to enable customers saving time and managing
mail items efficiently.

Financial Archiving: It provides a solution of the various companies allowing archive and
classifies invoices and all related documents according to the company business model in
order to increase office efficiency.

Health Record Management: Scalable and reliable solution suited for hospitals and clinics.

Project Documents Management: Managing all project related documents, permissions,

collaboration, processing, versioning, classification and archiving...

Law Offices Management: A full featured legal entity management solution for the small
and medium-sized corporations, designed to organize all their contacts, documents,
deadlines and data within a proven, flexible set of practice-specific windows and
workflows that can be easily customized to any office.

Business social networking: It helps customers to start implementing social networks to

promote collaboration amongst their employees.

Record Management: A service that provides the functionality to easily maintain, se- cure
your valuable information and simplify their records management according RM standards
DOD 5015.

Municipalities Document Management: Increasing municipalitys efficiency and citizens

satisfaction.

HR Documents Management: Enhance all facets of HR administration and employee

relationship management from the point of hire to the point of retires.

3 PROJECT MOTIVATION
IN:TIME Motivation

3.1

Due to the complexity of workflow implementation, Content Models and forms associated
generation in different target environments (Web, Mobile), the way to build applications
around, is a big challenge for companies.
IN:TIME Solutions aimed to build an ITS Modeler in order to decrease the development
process latency, increase productivity and Time To Market when dealing with its business
process reengineering customers needs .
This tool will be covering the objectives above:

Building a Visual Programming Modeler for forms, workflows and content models
design.

Enabling non-technical users to manage and deploy their business processes.

Implementing business logic for forms, workflows and content models generation
and hot deployment.

Managing integration of ITS Modeler output within the alfresco environment (The
basis of the ECM system of IN:TIME products)

Providing the ability to integrate the ITS Modeler outputs (workflow and content
forms) in mobile applications.

3.2

Student Motivation

IN:TIME products are built upon the Alfresco Enterprise Content Management System.
Understanding development process and content centric approach within a huge box such
as Alfresco is a big challenge to tackle. It covers sophisticated technologies related to
document and workflow management using the Activiti process Engine and the Lucene
search Engine.
Building a domain specific integrated environment is an unconventional approach in
perceiving softwares.
This will be a big opportunity for me to enhance Solution Architecting and Abstraction skills
and to cope with new project management methodologies.

4 PROJECT DESCRIPTION
This project aims at building an integrated web based Visual programming tool that
simplifies and accelerates the development process and resolves the dependency between

the Process Analyst and the developer. Thus, this tool will enable non-technical users to
integrate the development and implementation process, through an abstraction layer,
allowing them to easily create, manipulate, and deploy Business processes from the Design
step.
In order to achieve a successful implementation methodology, special heed ought to be
paid to cover the full lifecycle of a Business Process Management System (BPMS). This
would encompass the Analysis and Design phases, estimation, resourcing, progress
tracking, and integrating analytics and monitoring within the process.
In fact, Business process modeling, implementation, and reengineering is a common service
provided by IN:TIME. The latter should undertake the aforementioned tasks in a manner
that lays the foundation for continuous improvement after deployment.

For instance, the figure below describes the standard BPMS Implementation Methodology
used by IN:TIME. It involves frictionless dependency and collaboration between technical
and non-technical profiles in order to achieve the accomplishment of the process.

Figu re 2: Se que ntial BPM S Imp le me ntati on M ethod olo gy

The standard implementation approach, relying on the Activity explorer modeling tool (An
eclipse plugin used by the IN:TIME team) leads to an overload and a delivery delay. Those
drawbacks are due to the tools complexity and sequential aspect.
Therefore, IN:TIME requested an alteration in this sequential BPMS implementation
methodology .

The ITS Modeler will, not only, refine the implementation methodology itself, it will, also,
reshape the way it is performed by providing business analysts with the ability to develop
and test their business processes without requiring technical skills. It will also enable

developers to accelerate the implementation of complex Business processes. Hence, the

end-to-end standard methodology will be replaced by a parallel one.

Fi gure 3 : Paralle l BPM S Imple me nt ation M etho dol ogy

Besides, dealing with Business Process Implementation for Mobile Clients uncovers another
critical impediment of the standard approach. In fact, all forms of each task in a Business
Process have to be designed from scratch; this means that BP developers and Mobile
developers will work on the same output for different target environments.
However, on account of the ITS Modeler, we will be able to automatically generate a
mobile version of the Business Processes and deploy it on the targeted mobile application.
In a nutshell, the ITS Modeler would be a Domain Specific Tool [DST] (being related to
Alfresco Web Client environment) equipped with a Specific Visual Programming language
[SVPL] (as GUI Editor) and a Domain Specific Language [DSL] (editor background Language).
It has, mainly, the following characteristics:
ITS Modeler:
Alfresco Share (web client)

ITS Modeler

Simplify workflow implementation process to Developer

(technical users)

DST

DSL

Process from the Design step.

overvi ew

Integrated Development Environment within the Alfresco

Share (the repository web client).

Alfresco Repository

Fi gure 4 : ITS Mode le r

Enable Non-technical users to easily implement Business

Hot deploy of Business Process.

Enable Hot Business Processes Definition edit.

PROJECT METHOGOLOGIY

When dealing with Domain Specific Environment construction, we rarely use the standard
project working and implementation methodologies.
In all branches of science and engineering we can distinguish between generic approaches
and specic ones. A generic approach provides a general solution for many problems in a
certain area, but such a solution may be suboptimal, while a specic approach provides a
much better solution for a smaller set of problems [1].
Our aim with the ITS Modeler is to develop a new approach for designing business processes
under a specific environment that comes with a great amount of complexity.
To achieve this goal we will be creating models of each element in our project (process
definitions, content models, content forms) so we may construct the layer of abstraction
as defined in the project description section.
The Model-Driven Development (MDD) mainly describes what goes with our goal.

Model-Driven Development

5.1

The MDD approach is a style of software development that centers itself on building
models of a software system through modeling techniques. Later, transformations and
generation techniques are used to automate some aspect of the development process.
We found that the MDD approach define exactly how the ITS Modeler should be built.
Yet, MDD is just a software development technique and the development process should be
defined.
With MDD a sequential approach to development is often taken but opting for an Agile
methodology is required regarding to the system complexity and here come the AMDD the
agile version for the Model Driven Development.

Agile Model-Driven Development methodology

5.2

AMDD is an agile, model-driven iterative-incremental process.

The AMDD lifecycle includes three types of activities:

The envisioning

Throughout this iteration the goal is to identify the scope of our system. To do this we will
do both high-level requirements modeling and high-level architecture modeling. The goal
isn't to write detailed specifications that can be costly, but instead to explore the
requirements and come to an overall strategy for the project.

The Development

This activity is decomposed into several iterations. Each iteration will include the following
steps:
-

Modeling and DSL construction: during this step we analyze a part of the working
domain and define its model and meta-model then we design the Modeler DSL
which represent this part of the domain;

Editor developing: we develop the necessary elements that let the user
manipulate the previous representation within the Modeler graphical interface.

Execution engine developing: Within the Modeler execution engine we

implement the validation, generation, translation and deployment component
corresponding to the actual domain model.

Reviewing

This is final step of each iteration, where we will perform code testing and validation.

The following figure depicts the lifecycle of the project:

Fi gure 5 : ITS Mode le r projec t me thod olo gy lifec ycl e

After the definition of the project lifecycle, we now present the project scheduling
through Gantt diagrams:

Fi gure 6 : p ro je ct sc hedu ling overvi ew

Fi gure 7 : Projec t introducti on & Envisi onin g It erati on

Figu re 8: De ve lop me nt It erati on det ails

17

6 CONCLUSION
This chapter expounded in the first section the host company and its related working areas
while. The second one was dedicated to the motivation expressed by the company and me,
as student, to tackle this project. Therefore, the global project description and goals were
defined and highlighted as well as the methodology that will guide us through the
management of our project.
In the following chapter, we will go more deeply through investigating the project essential
elements and requirements.

18

CHAPTER II : PROJECT SCOPE AND REQUIREMENTS

1 INTRODUCTION
The ITS Modeler will be part of the IN:TIME Solutions framework which is mainly built on
top of the Alfresco core. Besides, defining the perimeter of this framework is of a great
significance, since the latter includes all the essential elements that define the scope of
our

project.

Thus, we will undertake the task of defining our solution essential requirements.
Moreover, a survey of similar available solutions will be presented, correlated and
compared to the desired solution functionalities.

PROJECT ESSENTIAL ELEMENTS

Enterprise Content Management (ECM) Overview

6.1

The ITS Modeler will be deployed into an Enterprise Content Management System, for this
reason we will be presenting this new IT trend.
ECM is the strategies, methods and tools used to capture, manage, store, preserve, and
deliver content and documents related to organizational processes. [2]

Capture: Create, obtain and organize information.

Manage: Process, modify and employ information.

Store: Temporarily back up frequently changing information in the short term.

Preserve: Back up infrequently changing information in the medium and long term.

Deliver: Provide clients and end users with requested information.[3]

A primary goal of ECM is to eliminate ad-hoc processes that can expose an organization to
regulatory compliance risks and other potential problems. Full-function ECM systems
include features such as document and records management, content taxonomies, auditing
capabilities, check-in/check-out and other workflow controls and security mechanisms.[4]

19

6.1.1

Alfresco Overview

The choice behind using Alfresco, was firstly imposed by the IN:TIME Solution as it is the
backbone of its products. This path was motivated by Alfrescos strength and extraordinary
richness that far exceed the other available solutions.
Alfresco provides modern software built on open standards that unlock the power of
business-critical content. Alfrescos open source technology enables global organizations to
collaborate more effectively across cloud, mobile, hybrid and on premise environments.
[5]

6.1.2

Alfresco Architecture

Alfresco is an open source Enterprise Content Management (ECM) system that manages all
the content within an enterprise and provides the services and controls that manage this
content.
At the core of the Alfresco system is a repository supported by a server that persists
content, metadata, associations, and full text indexes. Programming interfaces support
multiple languages and protocols upon which developers can create custom applications
and solutions. Out-of-the-box applications provide standard solutions such as document
management, and web content management.

Fi gure 9 : Al fre sc o EC M Overvi ew[6 ]

As an entirely Java application, the Alfresco system runs on virtually any system that can
run Java Enterprise Edition. At the core is the Spring platform, providing the ability to
modularize functionality, such as versioning, security, and rules.[6]

20

Alfresco uses scripting to simplify adding new functionality and developing new
programming interfaces. This portion of the architecture is known as web scripts and can
be used for both data and presentation services. The lightweight architecture is easy to
download, install, and deploy.[7]

Fi gure 1 0: Alfre sco E CM Archit ectu re [7 ]

6.1.3

xxx

6.1.3.1

Alfresco content repository

When it comes to managing enterprise content its critical to choose the right storage
mechanism for the job. The Alfresco uses a content centric storage mechanism which
stores data in ordinary files in the file system with an associated set of data management,
search and access methods allowing application-independent access to the content, rather
like an ordinary database.

6.1.3.2

Content models

The content model in Alfresco ECM system is analogous to the Schema of a database
system. It defines the structure of the content in the repository. It is the basis on which
the user interfaces, search capabilities and applications associated with the system are
built [8]. Defining a content model is expressed in terms of content met-models which
compromise an essential element: the content type.

21

6.1.3.3

Content type

A type is at the heart of the content meta-model, and represents objects in the real world
with support for properties and the ability to inherit the definition of a parent type.[9]
The following figure illustrate the storage mechanism in Alfresco:

Figu re 11 : Al fre sc o st orage mec hanism vs Relati on al St orage

6.1.3.4

Workflow models

The workflow model is a description of each task in a workflow. It defines attributes

associated with that task. A user interface component can use this description to
automatically generate an interface suitable for displaying the task information, in
addition to initializing a newly created task instance. [10]

6.1.3.5

Process definition

A process definition is a description of an execution flow in terms of activities and it

follows the BPMN 2.0 standard.

6.1.3.6

Task type

Each task in a process definition must correspond to a task type in the workflow model.
These tasks have properties which the workflow and user interface can use to present and
gather information from the user, change the behavior of the workflow, and monitor the
workflow. Tasks interact with the form system to display the forms that the user sees in
Alfresco Share. [11]
The following figure illustrate the relation between the workflow model, the process
definition and the client configuration in the Alfresco ECM:

22

Fi gure 1 2: Th e Wo rkflow M odel and the Proc ess De finiti on [1 0 ]

Business Process Management (BPM) Overview

6.2

The ITS Modeler will be abstracting the way we build and manage Business processes.
Through this section we will be presenting the Business process management approach and
its essential elements.
The modeling of Business process is performed by specific actors with business background
while

implementing

it

depend

on

people

with

technical

background.

We will be defining those actors and their roles (from the modeling to the implementation)
since the ITS Modeler essential goal is to fill the gap and remove the dependency between
technical and non-technical users when implementing a business process.

6.2.1

Definition

The Business Process Management is a systematic approach to making an organization's

workflow more effective, more efficient and more capable of adapting to an ever-changing
environment. A business process is an activity or set of activities that will accomplish a
specific organizational goal. [12]
The business objective is often to increase process speed or reduce cycle time; to increase
quality; or to reduce costs, such as labor, materials, scrap, or capital costs

6.2.2

BPM Actors

As the following figure describes a BPM is typically performed by:

Business analysts: provide expertise in the modeling discipline.

Functional experts: have a specialized knowledge of the processes being modeled.

23

Development team: implement and deploy the modeled process

To review

Business Analysts

Development Team

Fi gure 1 3: BPM Acto rs

6.2.3

BPM Implementation Engine

In this section we will define the BPM implementation engine used in Alfresco.
The ITS Modeler which will be integrated in alfresco will generate and deploy processes in
this engine.
The workflow engine used in Alfresco ECM is Activiti.
Definition
Activiti is a lightweight workflow and Business Process Management (BPM) Platform
targeted at business people, developers and system admins. Its core is a super-fast
and rock-solid BPMN 2 process engine for Java. It's open-source and distributed
under the Apache license.
Activiti runs in any Java application, on a server, on a cluster or in the cloud. It
integrates perfectly with Spring, it is extremely lightweight and based on simple
concepts.[13]
The figure 14 illustrates Activitis Architecture.

24

To review

Figu re 14 : Ac tiviti BPM En gin e

6.2.4

Business Process Modeling

It is mandatory to understand the standard way of defining and structuring a business

process.
The business process modeling in systems engineering is the activity of representing
processes of an enterprise, so that the current process may be analyzed or improved.[14]

6.2.4.1

Standard Business Process Modeling Techniques

Business process modeling (BPM) represents enterprise processes as models, often using
general-purpose process modeling languages (PMLs). PMLs like Business Process Model and
Notation (BPMN) qualify as general purpose in the sense of not being constrained to
processes to be deployed in a particular domain (environment).
The primary goal of BPMN is to provide a standard notation readily understandable by all
business stakeholders. These include the business analysts who create and refine the
processes, the technical developers responsible for implementing them, and the business
managers who monitor and manage them. [15]

6.2.4.2

ITS Modeler Modeling Techniques

The BPMN as a common modeling technique, bridges the communication gap that
frequently occurs between process analysts and developer. However, it does not fill the
real dependency gap between those participant actors in a considered sequential
implementation steps of a Business Process.
25

The ITS Modeler will provide a Business Process design and implementation environment
usable by both analysts and developer.

6.2.5

Change Management

6.2.5.1

Common Change Management Needs

Change management programs are typically involved to put any improved business
processes into practice. With advances in software design, the vision of BPM models
becoming fully executable (and capable of simulations and round-trip engineering) is
coming closer to reality. [14]

6.2.5.2

ITS Modeler Change Management Needs

The ITS Modeler includes a new approach of modeling Business Processes by abstracting the
implementation complexity for both technical and non-technical users.
This requirement introduced an other change management need in addition to the common
needs, which concern the migration from the standard modeling tools (BPMN) to ITS
Modeler modeling approach.

7 SOLUTION ESSENTIAL REQUIREMENTS

In the previous section we discussed the problems that arise when implemting business
processes. To mitigate those issues we present the essential requirements of our solution.

Function : Reengineering workflow development for developers

Objective

Optimize the design and deployment of Alfresco workflow

Description

Developing an approach that simplify workflow development

within the Alfresco environment.

Constraints, rules
and requirements
Priority

An approach without technical details.

Automated validation
Automated deployment

High

Function : Graphical Business Process design

26

Objective

Allowing non-technical user the ability to simply describe their

business processes.

Description

Non-technical user such as process analyst and business owner

arent familiar with the usual process notation techniques, our
aim is to provide an easy to understand and graphical technique
to design those business processes.

Constraints, rules
and requirements
Priority

No BPMN20 programming
No coding.

High

Function : Integrated within Alfresco environment

Objective

Having the functionalities wanted within the Alfresco share

environment

Description

The ITS Modeler should be available for all possible user which
maybe cant use the eclipse environment or equivalent ones.

Constraints, rules
and requirements
Priority

Integrate new web pages in the Share web client.

High

Function : Mobile client integration

Objective

Simplify the construction of BPM solution mobile client.

Description

The traditional task consultation is done via the Alfresco share

application, a new mobile approach is demanded where user can
see and perform actions through a mobile terminal.

Constraints, rules
and requirements
Priority

Automated generation of views/forms under a mobile

environment.

High

Function : Hot Edit/deployment of Business Processes

27

Objective

Enable the user to make changes and see the results without
restarting the Alfresco servers.

Description

The traditional development process under Alfresco require a

server restart to see the changes effects, so the ITS Modeler
should provide support for hot deployment.

Constraints, rules
and requirements
Priority

High

8 RELATED WORK
This paragraph will give us a short overview of similar business process modelings solutions
under the Alfresco ECM. Furthermore we will discuss how well they compare to the
requirements mentioned above.
Two main solutions are available for alfresco users:

The Activiti Designer Kickstart:

The Activiti Kickstart is an Eclipse plugin, which allows modeling BPMN 2.0
processes.

The Alfresco Activiti Modeler:

The Activiti Modeler is a web-based tool of authoring BPMN 2.0 compliant
processes.

The following table illustrates a comparison between these existing tools features and the
necessary solution requirements features:
ITS Modeler

Activiti Designer Kickstart

Alfresco Activiti Modeler

Requirements by

Feature

Feature

feature
Nature

Integrated web

Eclipse Plugin

based tool
Types of modeling

Processes and

Standalone web based

tool

Processes and Content

Processes and Content

BPM Developer

BPM Developer

No

No

content
User

BPM analyst, BPM

developer

Integration with

Yes

28

the Alfresco
environment
Deployment

Automatic

Manual

Automatic

Drag and drop

Yes

Yes

Yes

Mobile Compliance

Yes

No

No

Does not match any of the requirements

Matches sone of the requirements
Matches all requirements

We did not find a good match for our requirements in the solutions currently available on
the market; therefore we had to develop our solution from scratch.

9 CANDIDATE ARCHITECTURE
A first look at the above-mentioned requirements helps us to elaborate the following
candidate architecture:

29

Fi gure 1 5: ITS Mod el er Candid ate Arc hitec ture

10CONCLUSION
This second chapter was allotted to the formulation of the projects scope statement and
requirements which an indispensable document is including key features and evaluation
criteria to be met by the software engineer.
The required tasks now being outlined, the next chapter will deal with development tools
construction standards and considerations as it is the crucial part of this project.

30

31

CHAPTER III: BACKGROUND - DEVELOPMENT TOOLS & DOMAIN

SPECIFIC LANGUAGES

1 INTRODUCTION
Building an integrated environment within Share the web based client of Alfresco
repository should be studied carefully and in lined with considerations related to its
scope.
When dealing with development tools construction, it is mandatory to refer to another way
of perceiving things as it is the case in software development.
In this Chapter we will go through software development tools concepts and their
relationship with Domain Specific Languages (DSL).

11SOFTWARE DEVELOPMENT TOOLS

The ITS Modeler is part of software development tool family and for this reason, its
necessary to define its perimeter within the different types and classes of these tools,
besides we need to fix the standard considerations to be taken when building our ITS
Modeler.
11.1

Development Tools Classification:

The distinction between the different classes of development tools is important, since the
ITS Modeler should be positioned within a specific category depending on its requirements.
We will be comparing tools types in order to define the appropriate choices of building our
ITS Modeler.
There are many ways in which tools can be classified. Our comparison will be based on:
-

Whether they are command-line or UI tools,

Or whether they are general-purpose or domain-specific tools.

32

11.1.1

Command-line vs GUI Tool

Features

Command-Line Tools

GUI Tools

Command-line tools are optimized

GUI tools provide a graphical user

for batch processing: they take a

interface (GUI) with which users can

le as input and produce another

interact

in

a much

richer

way

The ITS Modeler aim to simplify the design and implementation of Business Process under
Alfresco, so as the GUI tools come to override the complexity of using command-line
tools we choose this family for our approach.

11.1.2
Usage scoop

General-purpose vs. Domain-Specific Tool

Generic tool

Domain specific tool

Generic tools are used broadly, and

Domain-specific tools are designed

users may prefer buying such tools

to provide an end-to-end solution

because they can "standardize" on

for a specific use case or narrow

them, reducing training cost by

range of use cases.

that. [16]
Context

Generic tools do not make any

The essential motivation behind

awareness

assumptions

Domain-specific tools is enhancing

about

the

specic

context of their applications.

productivity

by

providing

personalized utilities that support

only the concerned environment.
The ITS Modeler is related to a specific domain regarding its host environment
(Alfresco). Despite that, Alfresco solutions developers (such as ITS developers) are using
generic tools which lead to lots of impediments, the fact that confirm the need for a
domain-specific tool in our approach.

11.2

Development Tools Considerations Standards

Tools play an important role in software development regarding its complexity. The ITS
Modeler aims to fill this role by providing an adequate tool that has the potential to
support developers and ensures their expected consideration.

33

In the next table we are listing these considerations and their priority level (requirement
based) in the ITS Modeler (high, Medium or low):
Consideration

Role

Tedious

Language-aware

Automate

Tasks

editor

programming, such as generating code

Automation

some

Priority
aspects

of

High

snippets.
Code completion

Help to avoid typos and reduce the

High

number of keystrokes developers have

to type.
Refactor

Help

restructure

the

code

and

High

Enable the use of graphical notations

High

improve its internal structure.

GUI editor

to construct some of the software

aspect.
Problem

Debugging

fixing

Help to animate programs, allowing

developers

to

step

through

low

and

understand their execution.

Proling

Used to nd performance bottlenecks.

low

Quick xes

Suggest how to x type system or

High

structural errors as the developer

writes the code.
Developmen

Reporting

Help

create

reports

or

other

t Process

documents related to the system

Support

itself.
Requirements

Used to manage requirements or

management

documentation, and establish traces

between

code

or

models

Medium

Medium

and

requirements.
Version control

Help with managing versions and

High

releases of systems.
Content

Structural

Checking for structural correctness of

well-form

checking

programs codes or models.

Ensures

Type checking

Reject unrecognized types.

High

Derived

Artifacts

Help generating derived artifacts such

Low

artifacts

generation

as interface descriptions or code

34

High

Creation
Automation

documentation.
Code generation

Generate source code from models.

High

12DOMAIN SPECIFIC LANGUAGES

As defined and explained in the previous section, the ITS Modeler is concluded to be a
domain-specific tool
When we talk about a domain-specific tool (DST) its automatic to deal with DomainSpecic Language (DSL) as the core of DSTs.
This section starts with denitions and important terminology regarding DSLs. We will then
look at how to adopt our ITS Modelers DSL into our model-driven development (MDD)
approach.
12.1

Introduction to DSL

12.1.1

Definition

A Domain-specific language can be defined as a computer programming language of limited

expressiveness focused on a particular domain.
There are three key elements in this definition:

Computer programming language: A DSL is used by humans to instruct a computer

to do something. As with any modern programming language, its structure is
designed to make it easy for humans to understand, but it should still be something
executable by a computer.

Limited expressiveness: A general-purpose programming language provides lots of

capabilities: supporting varied data, control, and abstraction structures. All of this
is useful but makes it harder to learn and use. A DSL supports a bare minimum of
features needed to support its domain. We can't build an entire software system in
a DSL; rather, we use a DSL for one particular aspect of a system.

Domain focus: A limited language is only useful if it has a clear focus on a small
domain. The domain focus is what makes a limited language worthwhile.[17]

35

12.1.2

DSL Categories

DSLs are divided into two main categories:

1) External DSL: separate language from the main language of the application it works
with. Usually, an external DSL has a custom syntax, but using another language's
syntax is also common (XML is a frequent choice). A script in an external DSL will
usually be parsed by a code in the host application using text parsing techniques.
Examples of external DSLs that we come across include regular expressions, SQL
and XML configuration files for systems like Spring and Hibernate.
2) Internal DSL: It is a particular way of using a general-purpose language. A script in
an internal DSL is valid code in its general-purpose language, but only uses a subset
of the language's features in a particular style to handle one small aspect of the
overall system. The result should have the feel of a custom language, rather than
its host language. [17]
The ITS Modeler aims to provide a visual programming approach (drag/drop) in order to
create and manage Business Processes and contents. This, requires having a custom visual
syntax (different from the host environment language Alfresco).
We can conclude that the ITS Modeler DSL will be an external DSL.

12.1.3

DSL components

A domain-specic language consist of the following main ingredients:

Fi gure 1 6: DSL in gredi ent s

The concrete syntax: denes the notation which users use to express programs. It
may be textual, graphical, tabular (e.g. excel) or a mix of these.

The abstract syntax is a data structure that can hold the semantically relevant
information expressed by a program. It is typically a tree or a graph.

36

The semantic model is a representation, such as an in-memory object model, of

the same subject that the DSL describes (in the abstract syntax), the Semantic
Model is thus the library or framework that the DSL populates.

The execution semantics refers to the program once it is executed. It is realized

using the Execution Engine. [18]

12.2

DSL and MDD

In software engineering, Model-Driven Development is the methodology that emphasizes

the use of perspective models in a specific domain when aiming to automate a system.
If we use this model as the semantic model component of a DSL, we will be able to
generate some aspect of the software system with higher-level of abstractions.
Therefore, dening and using DSLs is a flavor of MDD: it includes the following steps:
1) We define and create the different components of our DSL (abstract syntax,
concrete syntax)
2) Then we define an editor to let people manipulate the DSL;
3) Finally,

we

use

interpretation

or

code

generation

to

transform

those

representations into executable code expressed in general-purpose programming

languages. [18]

13CONCLUSION
This chapter was devoted to the presentation of the projects essence. We tackled the
standards and considerations to be taken when building our ITS Modeler and concluded its
nature as a (DST) Domain Specific Tool. Therefore, we defined the DSL (Domain Specific
Language) concept, as it is the main core of our DST. In that section we draw a special
attention to the implementation steps of each component of our DST and its binding
philosophy with the model driven development approach best suited to our project.
This background statement will serves as a suitable lead-in for the aftermost chapter of
this report, allotted to the solutions implementation procedure.

37

CHAPTER IV : SOLUTION APPROACH

1 INTRODUCTION
After defining the theoretical guidelines of the ITS modeler construction, we will go
through the different bricks of our solution. In this chapter we will expose the different
architectures and semantic links between the various components of our solution.
The first section will be the global overview of the solution, which will be followed by a
description of each component independently.

2 SOLUTION OVERVIEW
Our approach emphasizes on development using a domain specific language, manipulated
within a graphical, integrated development tool, in the Alfresco Share environment.
Using this approach, the implementation of our solution will be guided through the major
components construction of the overall following architecture:

Figu re 17 : The ITS Mod ele r O ve rview

1. The ITS Modeler DSL [IMD]: It is the centric point of our approach, which focuses on
abstracting all the semantic models (used when creating Business Process and
Content) related to ITS Modelers domain and defining a concrete representation
for this abstraction.
2. The ITS Modeler Editor [IME]: It is the integrated web application in Alfresco Share
that serves as the graphical tool for manipulating the concrete representation.
3. The ITS Modeler Execution Engine [IMME]: It is the engine of the ITS Modeler that
will be responsible for the automatic validation, generation and deployment of the
needed artifacts (Business Processes and Contents).

38

4. The ITS Modeler Mobile ToolBox [IMMT]: It will ensure the exploitation of the
generated Business Process and Content in Titanium (The mobile target
Environment).

14DSL DESIGN

To develop our ITS Modeler DSL (domain-specic language) we need to go through a

number of important steps:
1. Analyze and define the domain (according to the MDD approach) concerned by this DSL
by listing the different models, which represent a concrete artifact (Business Process,
Content) within this domain. We use class diagrams to describe this representation.
2. Define the meta-models (the DSL abstract syntax) correlated with each model, which
describe what models for a specific purpose may look like. We choose to use JSON
format to structure the meta-models to be easily used later in transmitting
information between the ITS Modeler components.
3. Describe the concrete language syntax that will be manipulated by the end-user (a
visual language in our case).

The next figure illustrate the relation between the different elements in the Modeler DSL
design process:

39

Fi gure 1 8: Mod ele r DSL de sign

14.1

Domain analysis

Our domain is the Development and deployment of a business processes in Alfresco.

A deep study of this domain defined what it requires:

A BPMN file, containing the process definition

An Alfresco content model XML, containing the content types for all tasks in the
process.

An Alfresco form configuration, containing the appearance of the task forms.

This figure illustrates the files required for a 3 tasks workflow and their location:
To review

Figu re 19 : Al fre sc o workfl ow re quiremen ts

We can notice that three main models are taking place in our domain:

Alfresco Content Types

Business Process Definitions [BPD]

Forms Configuration

40

For that we will define three sub DSL within the ITS Modeler DSL:

14.2

The Content DSL

14.2.1

The Content Model

In order to elaborate the Content DSL, we define the alfresco content model elements,
which represent the necessary information needed for managing content in Alfresco.
The following diagram shows the relation between the elements composing the content
model and their properties:

Figu re 20 : C onte nt Mod el

A Type is a collection of properties and associations:

Properties have names and values (either single or multi-value).

41

Associations define relationships to other content in the repository.

There are two major types in alfresco: Content type and Task type.
-

Aspects allow addition of functionality to already existing type.

Constraints are made to specify tests that must passed before a property value is
considered valid and safe for persistence.

14.2.2

The Content Meta-Model

The meta-model is described with a JSON file, which can be represented with the
following tree:

Fi gure 2 1: Cont ent DSL Me ta-M ode l

Content

This is the main element of the meta-model, which contains the

basic information about it (name, version, author, description).

Element

Hold the content sub elements, it contains:

- Fixed input such as identifier and label
- Variable input within the Element option, which change with each
Element category.

Element option

Specify specific information for a given element category (Type,

Constraint or aspect)
42

Task Type

Define a workflow content type.

Content Type

Define an ordinary type.

Constraint

Parent element for constraints information

Aspect

Parent element for Aspects information

Constraint Option

Define a constraint for a given field

Aspect Option

Allow adding an aspect to the current content description

Identifier, Label,

Regular information about each field

required, CID

14.2.3

The content DSL syntax

We choose in the ITS Modeler to use a visual programming language, which will be based
on a palette holding graphical items that can be manipulated to define content types,
content tasks, constraints and aspects elements in the working scene.
Each item is bound with a corresponding element in the abstract syntax described by the
JSON structure as shown in the next figure:

43

Fi gure 2 2: Cont ent DSL Co ncret e Syn tax

44

14.3

The Business Process Definition DSL

14.3.1

The Business Process Definitions Model

In Alfresco a workflow is defined with a Business Process Definition [BPD], which is a

sequence of connected tasks. Each task can be performed by a person, a group, or
automatically.
The following schema illustrate the business process definitions model:

Figu re 23 : The Workfl ow Mod el

Event: models something that happens during the lifetime of a process.

Task: There are two types of tasks in a process definition:

User Task: describes work to be done by a human actor. When process

execution arrives at a user task, a new task is created in the task list of the
user or group assigned to that task.

System Task: describes an automatic activity. When a process execution

arrives at the system task, a corresponding script is executed.

Transition: The connector between two tasks within a process.

Assignee: As mentioned user task are assigned to one or more person.

Item: Used to attach an item for a given task. If the item already is part of that
task it will have no effect.

Gateway: Used to model concurrency in a process by controlling the flow of

execution. [19]

45

14.3.2

The Business Process Definition Meta-Model

This tree describes the workflow meta-model.

Figu re 24 : The Workfl ow Met a-M odel

BPM

This is the main element in process definition, which contains the

workflow name and ID.

Element

Hold the BPM sub elements, it has the same structure of the
previous Element (fixed + variable input).

Element option

Specify specific information for a given Element type (user task,

Gateway)

Gateway

This element corresponds to a gateway object in the business

process definition.

Seq Condition

Defines a path for a task in a gateway.

Task Constraint

Holds the information about the condition to be validated in order

to execute a task within the gateway.

Item1, Item2 and

Condition information

constraint

46

User task

This element represent the information about the task assigned to

a human actor, it is bound with the user task object in the
business process definitions model

Form key

Associate the user task with a form

Element type

Define the field type, it can be:

Identifier, Name,

User Task

Service task

Event (Start or End)

Gateway

Regular information about each element

CID

14.3.3

The Business Process Definition DSL syntax

47

Fi gure 2 5: Th e Wo rkflow DSL Co ncret e Syn tax

48

14.4

The Form DSL

14.4.1

The Form model

The Alfresco clients uses predefined "forms" (data view & entry dialogs) throughout
configurable user interfaces bounded with the task or content types.
The following figure illustrate the form model:

Figu re 26 : The F orm Mod el

Form: A form consists of one or more fields and the buttons required to submit the
form.

Field: The field is the area the current value is displayed and allows the user to
interact with to change the current value.

Set: A set is a configured group of fields that will all be displayed together.

Caption: The caption is the area above the form, by default, when shown, displays
the "Required Fields" instruction.[20]

14.4.2

The form meta-Model

The following tree shows the form meta-model structure:

49

Fi gure 2 7: Th e Fo rm M eta-Mode l

Form

The main element in the form tree.

Element

Hold the form sub elements.

Field

Represent a field within the form.

Set

The grouping element which hold a least one field.

Caption

Hold the text displayed on top of the form.

Identifier, Label,

Regular information about each element

Field_Type,CID

14.4.3

The form DSL syntax

50

Figu re 28 : The F orm DSL C onc re te Syntax

51

15EDITOR DESIGN AND IMPLEMENTATION

15.1

Editor Overview

The development of the ITS Modeler Editor was a very

involved process, requiring substantial time and patience
throughout.

The

overall

solution

requirements,

mentioned above, declared for us different considerations

to tackle when implementing our Editor. This led us to
adopt some best practices concepts related to GUI
development.
These concepts will be defined in the upcoming sections.

15.1.1

Visual Programming Language

Within the DSL design phase we saw in using graphical notations a way to raise the
abstraction level above ordinary programming languages, which are based on textual
syntax, thus improving development productivity.
Using such notation is compatible with the MDD vision that involves creating visual and
Computer-aided software engineering tools (CASE).
Linking this vision to our working case is an important factor to establish an appropriate
user

interface

for

managing

process

definitions

and

contents

within

Alfresco.

Indeed, during the conception of its processes, users (with or without technical
background) will be interacting with a real output more than a to-be-processed one.
This may obviously yield an amazing programming without coding approach.

15.1.2

Web based development tool

The web base approach shows a great potential to fill necessary requirements of the ITS
Modeler Editor.
Indeed, Desktop applications for several years were dominating in the field of development
tools, and within this environment many platform (Eclipse, Netbeans, Visual Studio, )
were created.

52

On the other hand, we have witnessed in the few last years a rapid growth of the browser
as an environment for building applications and the Web as infrastructure for
communication between the applications components.

15.1.3

Integrated development environment

When a user (Business Analyst, developer) of the ECM system Alfresco decide to create a
Business Process or a content, they need to switch their current working window (open
another tool for that). Indeed all the solutions presented in the market arent native to
the

Alfresco

web

client.

With the ITS Modeler, users will be able to do such operation in the same environment
where he perform his daily work concerned by the ECM System.
15.2

Editor Design

The first step in the editor design is to identify and describe actions that a user might do.
This allows us to define two main use cases: Content management and Workflow
management.
We will pack those actions within a navigation activity diagram, which illustrate the
different views of the interface.
Finally, we will draw the ITS Modelers mockups, which will be implemented in the next
phase.

53

15.2.1

Content Management Use Case

The use case diagram

Fi gure 2 9: Th e Cont ent M an agement Use Case diagram

The use case description

Use Case: Manage Content Model

Description

This use case allows the management of the content and task types
required for a given project.

Precondition
Nominal scenario

The user is authenticated to the Modeler in Alfresco share.

1) The user creates a new project or selects an existing

one in the project explorer.

Exceptions

2) The user selects one of the existing types or chooses one of the
contextual menu actions within the project explorer: create new
content type, import namespace...
3) The system loads the palette and the right view in the working
scene.
4) The user selects items from Add new field tab to create a new
content field (drag/drop).
5) For each element the user must fill the required properties when
the edit Tab view appears on the right
6) The user can save or export the content model using the menu bar
for further use.
The fields properties must respect naming conventions so an illegal input

Post condition

will be rejected with an alert.

None

54

Use Case: Validate Content model

Description

This use case is fired by the user and ensured by the Execution Engine
validator: an automated validation which checks if the content contains
errors or not.

Precondition

The user must be opening the content modeler and selecting the type he
want to validate.

Nominal scenario

1) The user click on the validate button in the menu bar.

2) The system constructs the corresponding JSON file of the current
modeling (if not constructed)
3) The system uploads the constructed JSON to the Execution Engine
validator.
4) The validator performs the necessary validation and sends back the
results to the user.
5) The system displays the validation result and highlight the elements
containing errors.

Exceptions

None

Post condition

None

Use Case: Deploy content model

Description

This use case allows the deployment of content models in Alfresco

automatically.

Precondition
Nominal scenario

The user must submit a valid content.

1) The user chooses to deploy the content model by clicking the
deploy button.
2) The system constructs the corresponding JSON file of the current
modeling (if not constructed).
3) The system calls the Execution Engine Generator to generate the
required artifacts.
4) The system calls the Execution Engine Deployer, which ensure
placing the artifacts in their right location.
5) When deployment is done, an acknowledgement is sent back.

55

Exceptions

Submission of a non-valid model, the system informs the user to

check the models types.

Server problem might occur during the deployment process, the

system interrupts the operation and informs the user.

Post condition

15.2.2

None

Workflow Management Use Case

The use case diagram

Fi gure 3 0: Th e Wo rkflow M an agement Use Case Diagram

The use case description

Use Case: Manage process definition

Description

This use case allows the management of a process definition including the
creation, modification and removal.

Precondition

The user is authenticated.

56

Nominal scenario

1) The user creates a new project or selects an existing

one in the project explorer.
2) The user chooses to create new process definition
from the contextual menu in the project explorer or
select an existing one.
3) The system loads the palette and the right view in the working
scene.
4) The user select items from Add new field tab to create the
process definition elements (tasks, gateways)

5) Form each element the user should specify its

properties (id, label, form)
6) The user can save the process definition as a draft or
export it for further use by using the menu bar buttons.
Exceptions

The elements properties must respect naming conventions so an illegal

Post condition

input will be rejected with an alert.

None

Use Case: Create Task Associated Form

Description

This use case allows the association of a form for a given task in the
process definition.

Precondition

The user is editing a process definition through the workflow Modeler and
selects a task to edit/create its form.

Nominal scenario

1) The user selects create new form from the process editor when
editing a task.
2) The system loads the palette and the right view in the working
scene.
3) The user uses the items from Add new field tab to create the
form (drag/drop).
4) For each item the user must fill the required properties when the
edit Tab view appears on the right
5) The user can save the form as a draft or as finished and reload the
workflow Modeler.

Exceptions

The fields properties must respect naming conventions so an illegal input

Post condition

will be rejected with an alert.

None

Use Case: validate workflow

57

Description

This use case is lunched by the user and maintained by the Execution
Engine Validator, which checks if the workflow implementation contains
errors, or not.

Precondition
Nominal scenario

The user should select a Process Definition.

1) The user clicks on the validate button.
2) The system constructs the corresponding JSON file of the current
process.
3) The system uploads the constructed JSON to the Execution Engine
Validator.
4) The validator performs the validation and sends back the results to
the user.
5) If there are errors, the system will highlight them in red.

Exceptions

None

Post condition

None

Use Case: Deploy workflow

Description

This use case allows the automatic deployment of a workflow in the

Precondition

selected target environment.

The user must submit a valid workflow.

Nominal scenario

1) The user chooses to deploy the current workflow.

2) A pop up is displayed allowing the user to select the target
environment (Mobile deployment, Alfresco deployment).
3) The system constructs the corresponding JSON file of the current
process.
4) The system calls the Execution Engine Generator to generate the
required artifacts.
5) The system calls the Execution Engine Deployer, which ensures
placing the artifacts in their right location in the target
environment.
6) When deployment is done, the system sends acknowledgement to
the user.

58

Exceptions

Submission of a non-valid model, the system informs the user to

check the process definition.

Server problem might occur during the deployment process, the

system interrupts the operation and inform the user.

Connection problems to the target environment might occur, so the

system alerts the user to check it.

Post condition

None

Use Case: Start workflow

Description

This use case allows the user to start the workflow directly from the
Modeler.

Precondition
Nominal scenario

Exceptions

The user has successfully deployed the workflow.

1) The user selects the workflow he wants to start and clicks on the
start button.
2) The system checks the deployment of the workflow by testing its
availability in the alfresco repository.
3) If the workflow is deployed the system invokes the start workflow
command.
The workflow is not deployed in the repository; the system shows a hint
for the user to deploy the workflow.

Post condition

15.2.3

None

ITS Modeler navigation diagram

59

Fi gure 3 1: Th e ITS Mo del er navigation diagram

15.2.4

The ITS Modeler Mockups

15.2.4.1

The content Modeler Mockups

60

Fi gure 3 2: Th e cont ent M odel er Mo ckup s Initi al view

Figu re 33 : The c onte nt Mod ele r M oc kups Edit vi ew

61

15.2.4.2

The workflow Modeler Mockups

Figu re 34 : The wo rkflow M odel er Moc kup s Intial view

Figu re 35 : The wo rkflow M odel er Moc kup s Edit View

62

15.3

Editor Implementation

15.3.1

Technical choices

As we mentioned above the ITS Modeler editor is integrated within the Alfresco web
Client, Share.
The ITS Modeler should ensure interactive and dynamic user experience including a lot of
actions to be performed fluidly around important data sets.
To respond to these considerations we decided to use a client side MVC framework that
ensures real time processing and binding of graphical items model/view.
Two frameworks were on the list; Angular.js and Backbone.js, bellow is a comparison:
Backbone.js
Framework Size

Angular.js

6.5kb

39.5kb

Backbone.js size greatly reduces the time required to load and

use the framework
Architecture

Model-View-Controller (MVC)

Model-View-View-Model (MVVM)

Backbone.js uses an Actor model to synchronize models and

views. This contrasts with Angular.JS, which uses a two-way
data binding to achieve the same effect.
Templating

Uses

third-party

template

The template engine is included

engines such as Underscore.js

within the framework, which uses

and Rivets.js.

dynamic HTML attributes added to

the document.

Using third-party template engine enables more flexiblility.

The previous comparison led us to choose the Backbone.js as the client side framework
for the ITS Modeler Editor considering how well it suites our needs.

15.3.2

Editor architecture

The following architecture illustrate the ITS Modeler Editors components

1 Templating refers to the data binding method used within the JavaScript framework
63

Fi gure 3 6: Th e ITS Mo del er Edito r Archit ectu re

15.3.2.1

The Modeler workbench

This component presents the ITS Modeler interfaces. Each page (ITS Content Modeler and
ITS Business Process Modeler) is composed of two sections:
-

The Modeler Explorer: The explorer is the centric entry point of the ITS Modeler, it
holds all the information about the available projects in the repository. Besides, it
is presented as a tree view where the user can select (display), add, save or delete
projects sub components (content or process definition files).

The Modeler workspace: This is the main portion of the editor; users may create
and edit content and process definitions using a set of components presented in the
editor palette. We used Backbone.js with the Rivets.js templating engine to build
the workspace and bind components views and models in real time.

64

15.3.2.2

The Modeler Global Handler:

This component presents the implementation of different pages of the ITS Modeler Editor
using the Share-side Spring Surf framework:
-

The Views: Define the page structure and render only the Modeler Explorer (The
workspace is client side rendered).

The Controllers: Enable binding between Models and views.

The Models: Hold the information loaded from the repository.

15.3.2.3

The Modeler workspace Handler

Part of the ITS Modeler JavaScript library, it presents a list of functions within two
modules:
-

The workspace builder: This module ensures the binding between the models in the
explorer handler and the Backbone.js collections used in the Modeler workspace.

The Action handler: This module intercept actions from the workspace section and
work as a proxy which redirect the request to invoke the corresponding
functionalities within the Modeler Execution Engine.

15.3.2.4

The Modeler Explorer Handler

Part of the ITS Modeler JavaScript library and interact with:

o

The Action handler: This module will handle all actions related to the
Modeler explorer (new project, new content model, new content type, new
process definition) through the Data Access Webscripts deployed in the
Alfresco repository.

15.3.3

User Interface Design Patterns

In the ITS Modeler Editor, we focus on leveraging an optimized user experience and for this
reason we made sure that we followed the possible UI design patterns [21] in our case:
Content Organizing pattern

Section shots should be

reviewed
65

One-Window Drilldown:
We show each of the Modeler pages within a
single window. As a user drills down through the
project explorer, or into an object's details, he
will get the new contents completely within the
: User click

original window.
Two-Panel Selector:
We put two side-by-side panels on the interface.
In the first (the workspace), we show a set of
items that the user can select at will; in the
other, (the right panel) we show the information
of the selected item.
Page Organizing pattern
Center Stage:
We put the most important part of the UI into the
largest subsection of the main window (in the
center); and we cluster secondary tools and
content around it in smaller panels.

Center stage
Visual Framework:

Basic layout :

We design each page( Business Process Modeler,

Content Modeler) to use the same basic layout,
colors, and stylistic elements.

Card Stack:

Palette tab:

We put sections of content onto separate panels

or "cards," and stack them up so only one is
visible at a time; and we use tabs to access
them.

66

Closable Panels:

Project structure visualisation:

We put sections of content onto separate div, and

we give the user the possibility to expand and
shrink them separately.

Responsive Enabling:
Starting with some disabled section, we guide the
user through some controls to enable them.

Navigation patterns
Global Navigation:

Using the project explorer to access all the

We use small section of every page to show a

views:

consistent set of links or buttons that help the

user navigate through all the Modeler views.
Commands and Actions patterns
Action Panel:
Instead of using menus, we present all the
possible actions on a UI panel (palette) that's
highly organized and easily accessible (drag/drop)

Multi-Level Undo:
The Modeler provides a way to easily reverse a
series of actions performed by the user.
Getting Users Input patterns

67

Fill-in-the-Blanks:
The modeler present clearly the fields to be
populated by the user in the forms situated
within the edit view.

Dropdown Chooser:

Example of a pop-up view:

To simplify the input of complex value we extend

the concept of a menu by using a dropdown or
pop-up view that contains the required input
without opening a new page.
Good Defaults:
Wherever appropriate, we initialize some form
fields with default values so the user doesnt
have to change them.

Illustrated Choices:

icons

We use pictures instead of words (or in addition

to them) to show available choices and describe
the fields.

68

15.3.4

ITS Modeler Screen Captures

To review: Content Modeler

Screen shot

69

16EXECUTION ENGINE DESIGN AND IMPLEMENTATION

16.1

Execution Engine Overview

After the implementation of the ITS Modeler
Editor, we continue in the MDD approach by
defining the execution engine of the ITS Modeler,
which ensures the following functionalities:

The validation of the content or the

process definition created.

The

translation

of

the

incoming

information from the Modeler Editor to the

corresponding models defined in the DSL domain models section.

The generation of the necessary artifacts needed to be deployed under the

standard environment (Alfresco) and into the mobile environment (Titanium).

The hot deployment of the generated artifacts.

In this section we start by defining the architecture of the ITS Modeler Execution Engine
and we will detail its components.
Then we will discuss the implementation details with respect to the chosen design
patterns.
Finally, we will highlight the extensibility features provided by the ITS Modeler execution
engine.
16.2

ITS Modeler Execution Engine architecture

As shown below, the IMEE (ITS Modeler Execution Engine) is composed of two layers:

The IMEE Tools: We define within this layer the implementation of all the functions
required for the validation, translation, generation and deployment.

The IMEE Services: Access to the IMEE tools is ensured via this layer, this to provide
a higher level of extensibility, abstraction and low coupling.

Besides those two layers, the IMEE uses the Alfresco service layer which ensures the
interaction with the Alfresco repository.

70

A typical working process using the IMEE include the following steps:
1) After Designing the content or the process definition, the user invoke the
validation services (the user click on the validation button and the editor
send the JSON to the IMEE);
2) The corresponding validation tool is fired through the service layer;
3) The validation results are sent back to the editor to be visualized.
4) If the information are valid, the user invokes the generation service to
create the necessary artifacts;
5) The requested generation service initiate the generation process by calling
the right generation tool (for the content, process definition or forms)
6) The generation tool calls the required translation functions from the IMEE
translation tool component.
7) The translation service parses the JSON file to correlate the information
with the semantic models and send them back to the generator.
8) The generator takes these models and writes the artifacts corresponding
information into the appropriate files.
9) The generation results are send back to the user.
10) The user can now invoke the deployment service to deploy the workflow in
the target environment.
11) The deployment tools are fired to put the artifact in the right places and
then acknowledge the user.
Figu re 37 : The ITS Mod ele r E xecuti on En gin e archit ectu re

71

16.2.1

Validation Component

This component is responsible for the validation of the user input before the generation
process and it can be invoked separately if the user doesnt want yet to generate the
artifacts for his current design.
The validation component is a two-layer component defined by two packages as illustrated
in the following package diagram:

Fi gure 3 8: Th e Valid atio n Compo nent p ackage di agram

16.2.2

Generation Components

This is the main component within the execution engine; it is responsible for the
generation

of

the

artifacts models,

process

definitions,

associated

forms

and

configurations files to be deployed later.

The generation component is actually supporting two target platforms:
-

The Alfresco environment

The Titanium mobile environment

Similarly, this component has two layers: one for accessing it and the other to implement
the required functionalities, the next package diagram illustrates its classes:

72

Fi gure 3 9: Th e Ge ne ration c ompon ent package diagram

73

16.2.3

Translation Component

The translation component is responsible for extracting and parsing the JSON input and correlates them with the predefined models (the ITS
Modeler DSL semantic models) needed by the generation service to perform the construction of the artifacts.

Fi gure 4 0: Th e Tran sl ati on co mp one nt pac kage diagram

74

16.2.4

Deployment Component

After the generation of the required artifacts, the deployment component ensures the
deployment of those artifacts in the right places within the different target environments.

Fi gure 4 1: Th e De plo ymen t co mp one nt pac kage diagramme

16.3

ITS Modeler Execution Engine Behavior Details

The following sequence diagrams illustrate two common execution sequence within the
IMEE, the first describe the generation of a content model and the second shows the
sequence of a process definition validation and generation:

75

Fi gure 4 2: Th e Cont ent M odel gen erati on sequ enc e diagram

76

16.4

IMEE implementation details

16.4.1

Project development: Maven Alfresco SDK

The ITS Modeler Execution Engine is developed and packaged within the Alfresco
environment which requires a standard development process supported by the Alfresco
SDK.
The Alfresco SDK - formerly Maven Alfresco SDK- provides a fully Maven support for Alfresco
ECM project development.
The Alfresco SDK relies on a number of components:

The SDK parent POM providing full Alfresco project lifecycle feature.

The Archetypes providing project templates to be used in the Alfresco module

development with the best practices. There are two types of archetypes:

The Repo AMP, a single project that customizes Alfresco Repository.

The Share AMP, a single project that customizes Alfresco Share.

The Maven Alfresco Plugin to manage AMP packaging and dependencies.

An AMP (Alfresco Module Package) is a ZIP file with a folder structure that follows a
specific convention. AMP files are used to make it easy to share and deploy customizations
to the Alfresco platform. [22]
The following figure illustrate the IMEE project structure:

16.4.2

Alfresco Web Scripts and Web Script Framework

The IMEE functionalities were developed using Alfresco web scripts which provide a unique
way to programmatically interact with the Alfresco content application server.
Web scripts let us implement the IMEE services as a Restful API backed by the Alfresco
content application server.
This approach in developing an Alfresco API means that web scripts offer many advantages
over existing technologies, such as SOAP, including ease and speed of development, and
flexibility in API design.
There are two kinds of web scripts that use the same underlying code:

Data web scripts;

77

Presentation web scripts. [23]

Fi gure 4 3: Alfre sco Web Scripts Typ e s [23 ]

For the IMEE we are interested in Data web scripts, which encapsulate access, and
modification of content/data held in the content repository.

To develop web scripts, Alfresco provides a framework (Web Script Framework) designed
according to the Model View Controller (MVC) pattern.
The following figure illustrate the Web Script framework architecture:

Fi gure 4 4: Alfre sco Web Script F rame wo rk Archit ectu re [24 ]

16.4.3

Implementation Design patterns

Facade Design Pattern

78

To hide the complexity of the IMEE functionalities, we implemented the Facade

design pattern by providing a simplified interface to interact with the execution
engine tools through the IMEE services:

Fi gure 4 5: Facad e De si gn Patt ern Imp le me ntati on

IoC
The Alfresco platform uses the Spring framework as the core foundation of its
architecture. This allow us to make use of the Spring IoC container to instantiate
and inject the different dependencies through the IMEE layers.

Figu re 46 : Depe nde ncy injecti on in the E xecu tion En gin e

Builder Design Pattern

79

The IMEE Generation tools classes use the builder design pattern where we the
content, workflow and form models are built incrementally by invoking a series of
sequential methods.
The following example illustrate the creation of a content model:

Figu re 47 : The C onte nt Mod el c re ation Proc e ss

16.4.4

IMEE extensibility features

Internal Extensibility

The ITS Modeler Execution Engine Generation Tools are mainly composed by 2 interfaces,
the I_ModelsGenerator and I_BusinessProcessDefinitionGenerator.
Each interface is implemented by the appropriate injected object, depending on the
service provoked by the Modeler editors user.
So, since a content model is composed by a list of types, the ContentModelGenerator
injected into the I_ModelGenerator will use the ContentTypeGenerator to generate the
type by using the appropriate translator (I_ContentTypeTranslator or I_TaskTypeTranslator).

External Extensibility

The idea behind exposing services per fragment came from the need to use some of the
included functionalities in a global service separately.

80

For example BusinessProcessDefinitionGenerationServices is a global service that include

share forms generation function. But a BusinessProcessModelGenerationServices is also
exposed for a standalone use: generating forms for an existing content.

Fi gure 4 8: IM EE E xte rn al Exten sibili ty fe ature

81

17THE ITS MODELER MOBILE TOOLBOX

17.1

Introduction

The ITS Modeler Mobile ToolBox provides the necessary features for implementing a mobile
version of a generated Business Process. In fact, the tradition approach to deal with such
objective is delicate and extremely complicated, due to the fact that it requires binding
between heterogeneous entities, such as task forms within a mobile environment and task
models within the business process engine.
Our aim is to generate a multiplatform solution; therefore we will survey the existing
frameworks that may responds to our goal and we will explain the reasons behind choosing
Titanium.
We will then expose the ITS Modeler Mobile Toolbox architecture.
17.2

Cross-Platform Framework benchmarking

When it comes to cross-platform development for mobile, the most popular frameworks
are Appcelerator Titanium, Xamarin and PhoneGap. All these frameworks solve the purpose
of developing a single app for multiple platforms.
However, there are vast differences between them:
Titanium
Platform support

PhoneGap

Xamarin

Android,

iOS,

Android,

iOS,

windows

phone,

windows

phone,

Android,

iOS,

windows phone

Blackberry, Tizen

Blackberry

Language

JavaScript

JavaScript

C#

Open Source

Yes

Yes

No

UI

Native

Web UI

Native

Access to device API

Full

Limited

Full

Native support

Yes

No

Yes

Given the computationally intensive nature of our context, since its dealing with ECM
repo, the choice is limited to platforms with almost Native support, to insure high levels of
performance and smooth rendering. This excludes PhoneGap.

82

Since Alfresco already invested in a repository management SDK dedicated to Titanium,

we decided to take the same path and build a Business Processes management tool box, for
future proofing integration wise.
17.3

The Appcelerators Titanium framework

17.3.1

Titanium framework overview

Appcelerators Titanium is an open source mobile application framework that provides an

environment to create native apps for several mobile platforms.
It is a complete solution for creating hybrid mobile apps by using the Titanium studio which
allows developer to create a unified project source code for several target environment.
The framework includes an SDK equipped with a number of mobile platform APIs and Cloud
services to use as an app backend. It also comes with a platform independent APIs which
makes it easier to access phone hardware.
The following figure shows an overview of the Titanium architecture:

Figu re 49 : Titaniu m Archi tectu re [2 4 ]

17.3.2

The Alloy MVC framework

Titanium uses Alloy, an MVC framework to enable rapid development of mobile apps.
Modules created using Alloy are easy to reuse across different apps, hence significantly
reducing the development time cost.
The following figure shows the different elements in a Titanium project using the Alloy
framework:
83

Figu re 50 : All oy Frame wo rk Ele me nt s

View: The view file declares the structure of the GUI.

Style: The style file formats and styles the components in the view file.

Controller: The controller file contains the presentation logic, which responds to
input from the user.

17.4

The ITS Modeler Mobile Toolbox implementation details

The IMM Toolbox provides the necessary modules to interact with the generated HTML
forms injected automatically by the ITS Execution engine in the target titanium mobile
app. Each action figuring in the generated views is bound to a corresponding event
registered in the IMM Toolbox. This allows a semantic basic communication between events
in the application and the Business Process Engine.

17.4.1

IMMT Architecture

The following figure illustrate the IMM Toolbox architecture:

84

Figu re 51 : The ITS Mod ele r Mo bile Tool Bo x Archit ectu re

The following table illustrates the different actions the user can perform by the
corresponding module in the IMM Toolbox:
Action

Module

Description

Show process list

IMMT Process module

Display the available processes.

Start Process

IMMT Process module

Allow the user to start a process

Show my tasks

IMMT Tasks module

Display the users tasks list

Display task form

IMMT form module

By selecting a task, the form module

points to the corresponding view and then
display it in a new tab. A counter
mechanism is used to navigate through
the process task forms and ensure the
synchronization with the Activit Business
Process Engine.

Submit task

IMMT form module

When the user clicks on the submit

button the form module invoke the
Alfresco

85

services

by

passing

the

constructed view object to the Business

Process Engine.
Select Assignee
Select attachment

IMMT Person picker

This action allows the user to choose an

module

assignee or a group to perform a task.

IMMT Doc picker module

This action helps the user to attach or

retrieve a document from the repository
to a specific task.

17.4.2

IMMT Integration and Behavior

Making use of the IMM Toolbox go through the following steps:

Development phase:
1) The developer uses the ITS Modeler Editor to design the business process definitions
and forms associated with each task.
2) Then he specifies the target Titanium application.
3) The Execution Engine generates and deploys the forms in the selected Titanium
application project.

Running phase:
1) When running the application, the necessary events of the IMMT will be registered
within the Titanium Event handler.
2) Users actions will fire the corresponding registered event, which invokes the right
web script in the Alfresco content application server and the Business process
Engine.

18CONCLUSION
This chapter dissected the depths of our solutions implementation approach. It illustrated
in practice all the relevant guidelines described throughout the previous chapters. It also
presented the incremental building blocks descripted by the project implementation
methodology: the MDD.
In each section we described in details a brick of our solution: From the ITS Modeler DSL
design to the ITS Modeler Mobile Toolkit.

86

Now that we completed the implementation of all the modules of our solutions, it is time
to tackle the requirements validation process with regards to our release.

87

CHAPTER VI : RESULT VALIDATION

1 INTRODUCTION
2 ITS MODELER ACHIEVEMENT LEVEL
ITS Modeler

Completio

ITS Modeler

Completio

ITS Modeler

Completio

Requirements

n level

Requirements

n level

Requirements

n level

Web based

BPM actors

Automated

tool

dependency

and Hot
deployment

Process

Integration with

Drag and

the Alfresco

drop

environment

modeling

Content

Automated

Mobile

modeling

validation

compliance

modeling

3 ITS MODELER IMPACT MEASUREMENT

In Order to measure the benefits of using the ITS Modeler in terms of the time required to
design and develop a workflow under the Alfresco ECM, we sat down with the ITS team to
investigate the duration of the traditional development process and then measure the time
saved by the use of the ITS Modeler:
We concluded the following indicators:

Average tasks number per Business Process = 5

Average properties number per task = 5.

Server restart average number per Business Process = 4.

The following table shows the average time during the different development steps:

88

Step

Duration in the

Tag

traditional approach
Process Design specification

2min per task

Design_duration

Modeling the Process Definition

2min per task

Pd_modeling_duration

Coding the workflow model (XML)

2min per field

Coding_duration

Coding The forms configurations

2min per field

using the Activiti Designer

(XML)
Testing/Fixes

Server restart

4min per fixe

Database cleanup

1min per fixe

Fixe_duration

With the above indicator, we conclude the following function that help us estimate the
required time for a given business process development:
F(task_num , field_avg, fixes_avg)= Design_duration * task_num * field_avg +
Pd_ modeling_duration * task_num +
coding_duration * field_avg * task_num +
fixes_duration * fixes_avg
We will illustrate the business process warranty claim which include four tasks with 18
fields, using this function we will calculate time by using the old approach and the ITS
Modeler:
Old: F (5,4,4)= 2 * 4 * 4 + 2 * 4 + 4 * 5 * 4 + 8 * 4 = 152 min (~2:30h)
With The ITS Modeler the same process takes only 5 min.

The following curve illustrate the gain coming with the ITS Modeler especially when the
number of tasks per process arise

89

19CONCLUSION

90

CHAPTER VII : GENERAL CONCLUSION & PERSPECTIVES

91

BIBLIOGRAPHY
[1]. Deursen, Arie Klint, Paul Visser, Joost. Domain-Specific Languages: An Annotated
Bibliography
[2]. what is Enterprise Content Management (ECM)? Aiim. [Online]
http://www.aiim.org/What-is-ECM-Enterprise-Content-Management
[3]. Patricia, Franks. Records and Information Management.
[4]. Enterprise content management (ECM). [Online]
http://searchwindowsserver.techtarget.com/definition/enterprise-content-managementECM
[5]. Alfresco. About Alfresco. [Online] https://www.alfresco.com/products
[6]. Alfresco. Alfresco overview. [Online]
http://docs.alfresco.com/community/concepts/system-about-community.html
[7]. Alfresco. Alfresco architecture. [Online]
http://docs.alfresco.com/4.2/concepts/alfresco-arch-about.html
[8]. McKnight, Richard. Content Modeling Demystified. [Online]
http://www.oldschooltechie.com/blog/2014/08/12/content-modeling-demystified
[9]. Alfresco. Content metamodel. [Online]
http://docs.alfresco.com/5.0/concepts/metadata-model-define.html
[10]. Alfresco. Task model. [Online] http://docs.alfresco.com/5.0/concepts/wf-taskmodel.html
[11]. Alfresco. Specifying the task type. [Online]
http://docs.alfresco.com/5.0/concepts/wf-specifying-task-type.html
[12]. Margaret , Rouse. Business process management (BPM). [Online]
http://searchcio.techtarget.com/definition/business-process-management
[13]. Activiti. Activiti BPM Platform. [Online] http://activiti.org/
[14]. Wikipedia. Business process modeling. [Online]
http://en.wikipedia.org/wiki/Business_process_modeling
[15]. Wikipedia. Business Process Model and Notation. [Online]
http://en.wikipedia.org/wiki/Business_Process_Model_and_Notation
[16]. Voelter, Markus. Generic Tools, Specic Languages.
[17]. Fowler , Martin. Domain-Specific Languages

92

[18]. Voelter, Markus. DSL Engineering

[19]. Alfresco. Process definitions. [Online] http://docs.alfresco.com/5.0/concepts/wfprocess-def.html
[20]. Alfresco. Forms. [Online] https://wiki.alfresco.com/wiki/Forms
[21]. Tidwell, Jenifer. Designing Interfaces.
[22]. Alfresco. Alfresco SDK. [Online]
https://artifacts.alfresco.com/nexus/content/repositories/alfresco-docs/alfresco-sdkaggregator/latest/index.html
[23]. Alfresco. Alfresco Web Scripts. [Online] http://docs.alfresco.com/4.2/concepts/wsarchitecture.html
[24]. Alfresco. Alfresco Web Script Framework. [Online]
http://docs.alfresco.com/4.2/concepts/ws-framework.html
[24]. Raj, Jay. The Top 7 Hybrid Mobile App Frameworks [Online]
http://www.sitepoint.com/top-7-hybrid-mobile-app-frameworks/
[25]. Hudson, Dave. Intro to appcelerator. [Online]
http://fr.slideshare.net/applification/intro-to-appcelerator-17158307

93