Generating database schemas from business artifact models

Published Online February 2018 in MECS DOI: 10.5815/ijitcs.2018.02.02

As an alternative to traditional activity-centric Business Process Models , artifact-centric models seek to unify both process and data aspects of a business into the same model [1]. This unification of process and data is achieved by modeling business processes as a set of selfevolving and interacting semantic entities referred to as Business Artifacts [2]. The goal of the artifact-centric approach is to provide a holistic and intuitive framework that can be used by business people on a daily basis in order to manage, analyze, and transform business processes with limited or no IT expertise.

As described in [3], an artifact-centric business process is composed from three main components:

• 1)    Business Artifacts that include an Information Model and a Lifecycle . The Information Model is a collection of attribute/value pairs used to store information about the Business Artifacts or relevant objects in the business process. The Lifecycle is a finite-state machine that describes the possible evolutions of a

Business Artifact from initial to final states.

• 2)    Services are the basic units of work that operates on Business Artifacts and update their information models. And,

• 3)    Business Rules are declarative Event-Condition-Action Rules (ECA Rules) that are used to invoke Services or to trigger Lifecycle ’s state transitions.

In order to model artifact-centric business processes on a conceptual level, the Business Artifact Modeling Notation ( BAMN ) is proposed in [4]. BAMN provides six graphical constructs: Task , Repository , Flow Connector , Data Attribute List , Condition , and Event . Using the six modeling constructs, users can construct conceptual models referred to as Business Artifact Models ( BAMs ) that capture the three components of an Artifact -centric business process, and at the same time omit implementation and technical details that are not relevant to end users.

On the other hand, developing information systems that implements BAMs is a serious challenge due to the conceptual nature of BAMs . Moreover, three types of data attributes including Simple , Complex , and Reference types can exist in the information model of Business Artifacts as described in [5]. This diversity in Business Artifact components and relationships leads to a complicated database design when implementing BAMs .

In this paper, we address the problem of generating Database Schemas that support BAMs by devising a suitable algorithm that automatically collects needed information from BAMs and generates Database Schemas . The database tables and relationships are generated according to the different relationships that can exist between Business Artifacts and the different types of data attributes in the Information Models of Business Artifacts .

The remainder of the paper is organized as follow: Section II introduces the Business Artifact Modeling Notation (BAMN) and Business Artifact Models (BAM). Section III describes the Database Schema generation algorithm in addition to an example scenario about a candidate admission process in a university master program. Section IV describes our prototype implementation of a BAM Modeler and a Database Schema Generator. Section V is a description of related works. Finally, Section VI concludes the paper.

• II.    Business Artifact Modeling Notation

In Table 1, we summarize the Business Artifact Modeling Notation ( BAMN ) constructs and their graphical representations for modeling Business Artifact Models ( BAMs) . The notation’s main focus is to capture artifact functional properties in terms of data, Events, and Tasks .

The graphical notation is based on six modeling constructs: Task , Repository , Flow connector (read-only and read/write) , Data Attribute List, Condition, and Event . Using these constructs, an artifact-centric process can be represented at a conceptual level by modeling interacting artifact lifecycles.

• 1)    Tasks correspond to Services in Artifact Systems and

represent units of work to be performed in order to manipulate artifacts and evolve them in their lifecycle thus achieving goals.

• 2)    Repositories denote storage locations into which artifacts can be stored awaiting for future processing if any. For every state of an artifact, an associated Repository is used to store all the artifact instances that are in that state of their lifecycle. Artifact instances can then be pushed into or pulled from particular Repositories as needed.

• 3)    Flow Connectors connect Tasks and Repositories and allow Artifact instances to be transferred between them. Read/write Flow Connectors indicate that Artifacts are transferable between Tasks and Repositories where they are manipulated and evolved with respect to their lifecycles. Read-only Flow Connectors indicate that artifact content is required in read-only mode and no modification is performed, thus the artifact remains in the same Repository . Fig. 1(a) illustrates a Repository connected to a Task through a read/write Flow Connector .

Table 1. Business Artifact Modeling Notation (BAMN)

Modeling Construct	Graphical Notation			Description
Task		/           \ Task		Units of work operating on business artifacts
Repository		Repository		Storage locations where artifacts await future processing if any
Read/write Flow Connector	Artifact			Transit business artifacts between tasks and repositories
Read-only Flow Connector	Artifact			Read business artifact content from a repository
Data Attribute List	- Attribute 1 :Type 1 - Attribute 2 :Type 2 - Attribu . t .. e . n :Type n			Attribute-Type pairs that characterize a repository
Condition	1    Condition     1			Conditions associated to flow connectors
Event	Event			Event associated to flow connectors

• 4)    Data Attribute Lists are associated to Repositories . They describe Information Models by annotating the conceptual model when Artifacts reach a certain state. Simultaneous definitions of the Information Model and the Lifecycle in the same conceptual model leads to building business processes incrementally without dealing with fine-grained details related to Artifact models . Additionally, the aggregation of Data Attribute Lists allows the generation of Information Models of

interrelated artifacts and eventually of Database Schemas . Data attributes are written as attribute-type pairs. Fig. 1(b) depicts a Repository with an attached Data Attribute List .

• 5)    Events are attached to Flow Connectors and specify external Events that are received. For example, a Create New Order Event is generated when clients make new orders.

• 6)    Conditions are also attached to Flow Connectors and specify constraints that should be satisfied in order to

activate a Flow Connector . Conditions express constraints over artifact attributes by using the defined (attribute)/ notdefined (attribute) and scalar comparison (>, <, <=, >=, =, !=) predicates . The defined (attribute)/ notdefined (attribute) predicates signify that attribute respectively has or does not have a value. Fig. 1(c) displays a Flow Connector with attached Event and Condition constructs.

Artifact

Repository

Task

• a)    A Repository connected to a Task using a Flow Connector

  

  Repository

  
  

  - Attribute1 : type1

  - Attribute2 : type2

• b)    A Repository with an attached Data Attribute List

  
  
  

  Condition

  
  

Artifact

• c)    A Flow Connector with attached Event and Condition

Fig.1. Examples of Possible Construct Combinations

Using the six modeling constructs a BAM can be constructed as illustrated in Fig. 2 about a candidate application artifact that deals with admitting a candidate into master programs. In this example, when the CreateNewApplication event is received, the CreateCAA task is executed and a CandidateApplicationArtifact is created with information regarding candidate name, date of birth, and master program. When the SubmitRequiredDocuments event is received, the SubmitDocuments task is executed in order to collect required documents. If all documents are validated, the candidate application becomes complete , otherwise, it is rejected .

Fig.2. Conceptual Model of Candidate Application Artifact

• III.    Generating Database Schemas from Business Artifact Models

In order to generate Database schemas from Business Artifact Models , we define a formal representation for BAMs that serves as the input to the described algorithm.

A BAM is defined as a tuple G= where: T is the set of Tasks . R is the set of Repositories . F is the set of Flow Connectors . L is the set of Data Attribute Lists . E is the set of Events . And, C is the set of Conditions . In the Database Schema generating algorithm, we make no use of Events and Conditions sets which are only relevant for process execution.

We then define an algorithm that takes the formal representation of BAM and generates the corresponding Database schema. This algorithm is based on Data Attribute types constituting the Information Model of Business Artifacts . In BAM , the Information Model is expressed through Data Attribute Lists attached to Repositories .

• A. Data Attribute Types

We differentiate between three types of data attributes of artifact’s Information Model : Simple, Complex, and Reference .

• 1)    Simple attributes can hold one value at a time and are used to record information related to Artifact instances. i.e. the instance identifier, the candidate first name, the candidate last name,… Simple attributes are written as Name:Value pairs in Data Attribute Lists and are attached to the Repository of the corresponding Business Artifact . i.e. ApplicationArtifactId:Integer , FirstName:String , LastName:String . In the generated Database Schemas , simple attributes correspond to tables’ columns.

• 2)    Complex attributes represent relations and are expressed as lists of simple attributes. Like relations, complex attributes can hold many tuples at a time. They are used to record information about various objects that are related to the Artifact . i.e., Documents, Interview Results. Complex attributes are written using the Name:{Att1:Type1, Att2:Type2,…} syntax in Data Attribute Lists and are attached to the Repository of the corresponding Business Artifact . i.e. Documents:{Type:String, Title:String, URL:String} . In the generated Database Schemas , complex attributes correspond to tables.

• 3)    Reference attributes refer to other Artifacts that are directly related to the main Artifact in a Parent-to-Child relationship. For example, the Candidate Application Artifact dealing with candidate admission is the parent of a Candidate Interview Artifact dealing with interviewing the corresponding candidate. In BAM, reference attributes are deduced from Tasks creating child Artifacts . In other words, Tasks creating child Artifacts are Tasks that takes an Artifact as input and emit two Artifacts as output. i.e. The CreateCIA Task takes a Candidate Application Artifact instance as input, creates a Candidate Interview Artifact instance, and insert the child