Paper Title (use style: paper title)

2 downloads 0 Views 134KB Size Report
Business Process Model and Elements. Of Software Design: The Mapping Approach. Lj. Kazi*, B. Radulovic*, D. Radosav*, M. Bhatt**, N. Grmusa*, N. Stiklica*.
Business Process Model and Elements Of Software Design: The Mapping Approach Lj. Kazi*, B. Radulovic*, D. Radosav*, M. Bhatt**, N. Grmusa*, N. Stiklica* * University of Novi Sad, Technical faculty “Mihajlo Pupin”, Zrenjanin, Serbia ** University of Mumbai, R. D. National College, Mumbai, India [email protected], [email protected], [email protected], [email protected] [email protected], [email protected] Abstract - Approach to mapping elements of business process model to elements of software design elements has been described in this paper. Primitive processes are mapping with software functions, i.e. use cases, while data dictionary and data stores are mappeed to data model elements.

I.

INTRODUCTION

After completion of business process modeling, a phase of software design is starting. Business process models (diagrams, data dictionary) as well as client requirements present material needed for the phase of software design, i.e. design of information system. Design is usually presented by UML diagrams, followed by textual (semi-formal) specifications as well as data model diagrams. This paper describes approach to mapping business

process models to models related to software functions design and design of data models. It also illustrates how this approach could be applied in particular cases, i.e. examples. II.

THEORETICAL BACKGROUND

The core processes in software development within information systems development is based on two main streams: functionality and data [1]. Real-world business process knowledge is presented as business process model and specification of client requirements is captured. Two parallel processes (for functionality and data) are following particular steps in requirements analysis and design, which are technology independent processes and implementation, which are technology dependent processes. Figure 1. shows enhanced model that was presented in [1].

Real world

Business process modeling

Functional requirements analysis

Functional analysis

Client requirements specification

Data requirements analysis

Conceptual data model design

Technology independent Technology dependent Logical schema in DBMS Design of software

Implementation of transactions

Implementation of physical schema in DBMS

SOFTWARE APPLICATION

Figure 1. “Two main-streams based” model for software development for information systems (enhanced model from [1])

III.

THE MAPPING APPROACH

Figure 1. shows two main streams of activities: 

Functionality related



Data related

For each of them as an input material is used: 

Business process model



Client requirements specification.

According to [2] and [3], the mapping approach includes: 

for functionality - each primitive process from business process model is related to one or many software functions, i.e. use cases that enable particular business process to be implemented by using information technologies and software functions

TABLE II.

ENHANCED TABLE STRUCTURE FOR TEXTUAL MAPPING PRIMITIVE PROCESS TO SOFTWARE FUNCTIONS

Primitive business process Primitive process 1

Software functions Software function 1 Software function 2

User profile User profile1 User profile2

Software Module Software module1 Software module2

There are certain heuristics that could be used in this process of mapping business processes to software functions: 

It is not obligatory that each primitive process has to be mapped to a software function. If it is not possible or needed, we write "N/A" or "not supported by software"



It is needed to let creativity be free, to have as much as possible software functions that could be applied



In functionality domain, practical mapping approach is applied by creating a textual table (Table 1.) that would have a column related to primitive business proces and a column related to set of software functions that implement particular business process.

From the multitude of all software functions that could be mapped, there should be left in the second column only those that could really be usefull and really used in everyday working environment; those that are not implementable, appliable or useful should not be written



For having second column filled, creative efforts is to be engaged and they are filtered or enhanced by client requirements specification.

There are some business processes that are technology supported and organizationally related, but not all are needed to be software supported



In suggestions for software functionailities there could be many alternatives. It is needed that software functions to be grouped and organized as: NEED TO HAVE and NICE TO HAVE software functions. At first iteration, to a user is to be given NEED to HAVE software functions, while NICE to HAVE functions are left for another iteration.



Some suggestions could be related to other software already developed by others. These solutions should be described and distinction is to be made between the proposed solution and existing solutions available.



for data - each primitive process is assigned to data sub-model, each data dictionary item is assigned to entity attribute, each data store is decomposed to sub-set of entities from data model. IV.

FUNCTIONALITY DOMAIN

TABLE I.

TABLE STRUCTURE FOR TEXTUAL MAPPING PRIMITIVE PROCESS TO SOFTWARE FUNCTIONS

Primitive business process Primitive process 1

Software functions Software function 1, Software function 2, Software function 3

Usually software functions that implement particular primitive process are related to data manipulation such as data input/edit/delete, presentation of data in tabular form or printing documents, filtering data etc. After having this table filled, UML's USE CASE diagram could be created according to second column. Since more precise data that describe software function is needed for USE CASE diagram, there could be more columns describing more precisely proposed software solution, such as (Table II): 

user profile assigned to certain software function,



software module that particular function could belong to, etc.

software

V.

DATA RELATED DOMAIN

Conceptual data modeling is considered as one of the most difficult processes, since it is based on business process knowledge and client requirements specification There are many different approaches to creation of data models. Integration of different approaches to creating conceptual data model and other data models is applied at Technical faculty "Mihajlo Pupin" Zrenjanin, Serbia within Information systems education and students' practical laboratory work. This integration is described within strategy approaches (Table III) and following information systems development phases (Table IV).

TABLE III.

STRATEGY APPROACHES AND INTEGRATION OF METHODS FOR DATA MODEL CREATION ([4])

Strategy Iterative and increment refinement At each IS development phase

Direct modeling Sequential / partial modeling

Method

Material

Requirements collection Business process modeling System design Complete model Integration of sub-models for each: Taking material:

Grammar analysis regarding:

of

text

Text that describe business process and client requirements Business process models UML models of system design - Primitive process from SSA - USE case from UML - Attributes - Data flows (SSA) - Data stores (SSA) - XML message Lifecycle of business process Use case specification - action steps

Using design patterns Normalization

TABLE IV.

INTEGRATED DATA MODEL CREATION METHODS FOLLOWED BY INFORMATION SYSTEM DEVELOPMENT PHASES ([4])

IS development phase Requirements of Business domain and client Business process and data flow modeling

Material

Method

Textual description of main processing object lifecycle SSA model

Grammar analysis of nouns and verbs candidates for entities and relations Creating sub-models for each primitive process

Data dictionary attribute

Each attribute from data dictionary has entity mapping ("belongs to some entity") Each data store from SSA model is to be normalized. Using substructure notations to analyze and derive sub -entities from a data store Creating a complete model by corrections and adjustments

Data dictionary data store

Creating conceptual data model

1st, 2nd and 3rd draft data model

Creating model

Final conceptual model

physical

Implementing database

VI.

Data stores Data flows

Result

Adding indexes for preserving semantic uniqueness Automatically by using CASE tool

CONCLUSION

Information system development starts with knowledge capturing from business real-world organizations and specification of client requirements. Results of business domain modeling are diagrams, process tree and data dictionary. Results of client

Activity order

1st draft model - only entities

1

Final complete model verification by dividing to sub-models and checking: completeness or entities and relations. Each sub-model has entities for reading and writing data, since each primitive process has input and output data flows 2nd draft model - adding attributes to existing entities (from 1st draft) or deriving more entities from attributes (attribute has to have an entity to belong to) 3rd draft model - transforming each data store to set of entities and appropriate attributes, consolidating with entities from 1st and 2nd draft

5

Final model corrected byAbstraction, redundancy validation, Adding missing attributes and identifiers, Extraction of general data from specific data Physical (relational) model with added indexes

4

Database file, ready for data entry

7

2

3

6

requirements capturing are textual specifications of needed functional and data aspects. After that initial core processes, two main-stream set of activities are performed: functionality related and data related. Each of these sets of activities use business process modeling results and client requirements specifications as input.

In this paper we show the mapping approach between business process model elements and core design elements: software functions and data model. Mapping between business process and software functions is performed within textual tables. These software functions present basis for later creation of use case diagrams, specifying use cases for functionality of software.Mapping between elements of business process model and data dictionary to data models is described within integrated approach of different methods. Future work in this field would include development of automated procedures that could enable implementation of presented mapping approach and application to diversity of business process domains.

REFERENCES [1] [2]

[3]

[4]

R. Elmasri and S.B. Navathe,”Fundamentals of Database Systems”, 5th edition, Pearson International Edition, 2007 Lj. Kazi and B. Radulović,”Projektovanje informacionih sistema kroz primere i zadatke”, Technical faculty "Mihajo Pupin" Zrenjanin, Serbia, 2008 B. Radulovic, Lj. Kazi and Z. Kazi, “Informacioni sistemi odabrana poglavlja”, Technical faculty "Mihajo Pupin" Zrenjanin, Serbia, 2006 Lj. Kazi, Z. Kazi, B. Radulovic and O. Stanciu: Integration Of Conceptual Data Modelling Methods In Information System Development, I International Symposium Engineering Management And Competitiveness 2011 (EMC 2011), Zrenjanin 2011.