Contoh Template AE

i

A Thesis for the Degree of Master

A Method to Generate a Feature Model from a Business Process

Model for Business Applications

Jongsu Bae

School of Engineering

Information and Communications University

2007

ii



iii



Advisor : Professor Sungwon Kang

by

Jongsu Bae School of Engineering

Information and Communications University

A thesis submitted to the faculty of Information and Communications University in partial fulfillment of the requirements for the degree of Master of Science in the School of Engineering Daejeon, Korea July 10, 2007. Approved by (signed) Professor Sungwon Kang Major Advisor

iv

A Method to Generate a Feature Model from a Business Process Model for

Business Applications Jongsu Bae

We certify that this work has passed the scholastic standards

requested by the Information and Communications University as a thesis for the degree of Master

July 10, 2007

Approved: Chairman of the Committee Sungwon Kang, Associate Professor School of Engineering

Committee Member Danhyung Lee, Professor School of Engineering

Committee Member Jongmoon Baik, Assistant Professor School of Engineering

M.S. 20052047

Jongsu Bae A Method to Generate a Feature Model from a Business Process Model for Business Applications School of Engineering. 2007, p.66 Major Advisor: Associate Professor. Sungwon Kang. Text in English

i

Abstract

The growing competitive market requires high-quality, flexible, and adapt-

able software to support business activities. Understanding business activities in

an organization is the first step in developing business administrative software.

Most development methodologies model business processes so as to capture or

improve the overall functionality of many organizations (e.g., banks, government

and, generally, service organizations). Currently, there are many development

methodologies that guide model business activity (e.g., Rational Unified Process,

PPC). These methodologies only focus on single system development. Some

others focus on how to bridge between business activity and a system model,

such as BPM (Business Process Model). On the other hand, SPL (Soft-ware

Product Line) practice focus on software reuse by developing a family of

systems. Many researchers say software reuse is the answer to improve software

quality and productivity. Some of SPL methods try to model business activities

such as PLUS, but do not provide business process variability and properly

ii

bridge between business activities and software products in the view of end-user

or customer. Some researchers attempt to present business process variability by

extending existing notation, but do not show how to use this model in do-main

analysis.

There is no unique or uniform business process for various organizations,

but common business processes in same business domain exist. Therefore, it is

possible to reuse those common business processes. The primary goal of this

thesis is to establish Domain Analysis activities in product line engineering for

business applications named FMBP (A Method to Generate a Feature Model

from a Business Process Model for Business Applications). It adds domain

process analysis to existing domain analysis methods by analyzing common and

variable business processes. It shows how to transform BPM (business process

model) into DPM (Domain Process Model) and how to organize FM (Feature

Model) from DPM from the end-user’s perspective.

iii

Contents

Abstract ................................................................................................................. i

Contents...............................................................................................................iii

List of Tables ....................................................................................................... vi

List of Figures ....................................................................................................vii

List of Abbreviations........................................................................................viii

I Introduction................................................................................................... 1

1.1 Motivation................................................................................................ 1

1.1.1 Need to increase software quality & productivity ....................................1

1.1.2 Lack of SPL practices in business applications ........................................1

1.1.3 Characteristics of a business process in the same domain........................2

1.1.4 A need to analyze business process ..........................................................3

1.2 Needs a SPL method to reuse a business process..................................... 3

1.3 Research Objective ................................................................................... 4

1.4 Summary of Contributions ....................................................................... 5

1.5 Thesis Outline .......................................................................................... 5

Ⅱ Background & Related works ..................................................................... 6

2.1 Business Process Model and Feature Model ........................................... 6

2.1.1 What is Business Process Model? ............................................................6

2.1.2 What is a Feature and a Feature Model?...................................................7

2.2 Analysis and modeling methods for single system development ............. 8

2.2.1 Traditional analysis methods......................................................................8

2.2.2 Methodologies including business process analysis ..................................9

2.2.3 Business process modeling Notations......................................................11

iv

2.2.4 Needs to analyze business process in whole enterprise business for SPL

12

2.3 Domain Engineering............................................................................... 12

2.3.1 Domain modeling methods ......................................................................13

2.3.2 Feature modeling methods.......................................................................14

2.3.3 A survey of domain analysis using feature model....................................15

2.4 Related works ......................................................................................... 17

2.4.1 Gomaa: PLUS ..........................................................................................17

2.4.2 Schnieders: Modeling process variability ................................................19

Ⅲ. Generating a Feature Model from a Business Process Model................. 20

3.1 Definitions used in this thesis................................................................. 20

3.1 Relationship: Business activity, Use-case and Feature........................... 21

3.2 Domain Analysis Approach: From a business process to a feature model

22

3.3 FMBP Steps ............................................................................................ 23

3.3.1 Step 1: DPA (Domain Process Analysis)..................................................24

3.3.2 Step 2: FA (Feature Analysis) ..................................................................28

3.4 Notations................................................................................................. 32

3.4.1 Representing alternative process..............................................................32

3.4.2 Representing optional process .................................................................33

Ⅳ Case Study.................................................................................................... 36

4.1 Business process about IP....................................................................... 36

4.1.1 Overview about IP business processes.....................................................36

4.1.2 Short descriptions about IP business processes .......................................37

4.2 Business Process Analysis ...................................................................... 38

4.2.1 A document business process...................................................................38

v

4.2.2 An application business process...............................................................38

4.2.2 A registration business process ................................................................40

4.3 Domain Process Analysis ....................................................................... 41

4.3.1 Derive Domain Modeling plan ................................................................41

4.3.2 Analyze business process commonality and variability from BPM.........42

4.3.3 Generate Domain Process Model.............................................................43

4.4 Feature Analysis ..................................................................................... 46

4.4.1 Folding Business process model ..............................................................46

4.4.2 Feature Identification ...............................................................................47

4.4.3 Feature Modeling .....................................................................................48

Ⅴ Evaluation.................................................................................................... 51

5.1 Comparison with existing modeling methods ........................................ 51

5.1.1 Existing comparison framework at a glance ............................................51

5.1.2 Comparison Framework...........................................................................52

5.1.3 Comparison result between Gomaa, Schnieders and the proposed method

52

5.2 ROI Analysis........................................................................................... 55

Ⅵ Conclusions & Further Works ................................................................... 58

국문요약 ............................................................................................................. 59

References .......................................................................................................... 61

Acknowledgements............................................................................................ 65

Curriculum Vitae............................................................................................... 66

vi

List of Tables

Table 1. Traditional analysis methods ................................................................... 9

Table 2. A research for product line engineering................................................. 13

Table 3. Modeling approach in feature analysis & modeling.............................. 17

Table 4. Activity characteristic from business process model............................. 25

Table 5. An example about feature candidate lists .............................................. 30

Table 6. Process variability notations.................................................................. 32

Table 7. Notations used in this thesis .................................................................. 35

Table 8. A list of a registration business activities .............................................. 38

Table 9. A list of an application business activities............................................. 39

Table 10. Lists of a registration business activities ............................................. 40

Table 11. New Product List about ‘Self-digitization’ business process .............. 42

Table 12. Feature lists for digitization business process ..................................... 47

Table 13. group feature lists for receiving business process ............................... 49

Table 14. group feature list for receive business process .................................... 54

Table 15. Input factor and data for IP business application ................................ 56

Table 16. Product Line Development Cost Estimation result ............................. 56

Table 17. Comparison about effort saving .......................................................... 57

vii

List of Figures

Figure 1. General Project Life Cycle in RUP ................................................... 10

Figure 2. Overall Analysis Process ................................................................... 11

Figure 3. The survey of domain analysis using feature model ......................... 16

Figure 4. Variability modeling about business process model(example).......... 19

Figure 5. Relation among Business activity, Use-case and Feature.................. 22

Figure 6. From business process to feature model............................................ 23

Figure 7. FMBP Steps ....................................................................................... 24

Figure 8. Receiving process for an application/registration business process .. 27

Figure 9. Model transformaion according to process variability ...................... 28

Figure 10. Conceptual image to apply folding technique ................................. 30

Figure 11. Feature Modeling by introducing group feature .............................. 31

Figure 12. Feature Modeling by introducing group feature.............................. 33

Figure 13. Feature Modeling by introducing group feature.............................. 34

Figure 14. Overall IP business process ............................................................. 36

Figure 15. A Business process model for an application process ..................... 40

Figure 16. A business process model for a registration business process ......... 41

Figure 17. Integrated Business Process Model ................................................. 43

Figure 18. Process Variation Point .................................................................... 44

Figure 19. To-Be business process model......................................................... 45

Figure 20. After folding step 2 .......................................................................... 46

Figure 21. Receiving officer’s use-case folding for digitization....................... 47

Figure 22. Feature presentation......................................................................... 48

Figure 23. Create partial feature tree by introducing group feature.................. 50

Figure 24. Partial Feature Model for IP business process................................. 50

Figure 25. Partial Feature Model for IP business process................................. 57

viii

List of Abbreviations

AD Activity Diagram

AE Application Engineering

BE Break Even

BPA Business Process Analysis

BPM Business Process Model

BPMN Business Process Modeling Notation

DE Domain Engineering

DP Domain Process

DPA Domain Process Analysis

DPM Domain Process Model

FA Feature Analysis

FM Feature Model

FMBP Feature Model from a Business Process Model

ICU Information and Communications University

IP Intellectual Property

OOA/D Object Oriented Analysis and Design

PCT Patent Cooperation Treaty

RO Receiving Office

RUP Rational Unified Process

SPL Software Product Line

UML Unified Modeling Language

WIPO World Intellectual Property Organization

ICU Information and Communications University

1

I Introduction

1.1 Motivation

1.1.1 Need to increase software quality & productivity

The growing competitive market requires high-quality flexible software for

business activities to increase efficiency and productivity. To promote efficiency

and productivity in organizations, most develop or adopt a software system that

supports their business activities and replace their manual activities with auto-

mated processes. Some organizations in Korea develop software systems for

their whole business process. After doing so, productivity and work quality

remarkably increases and the time required to complete work is reduced.

The more the need for adopting software system grows, the more

competitive software development companies grow. One of the issues for

software development companies is quality & productivity. Software reuse has

long been recognized to be an effective way to improve software quality and

productivity [9]. SPL (Software Product Line) is a good candidate to effective

software reuse since SPL focuses on software reuse by developing a family of

systems [35].

1.1.2 Lack of SPL practices in business applications

Currently, there are many development methodologies that guide business

activity modeling, such as RUP (Rational Unified Process)[27], PPC[26] and

Spiral methodologies, etc. These methodologies only focus on single system

2

development. Clements say that “One simple way to achieve business

responsiveness is speeding up the software development process with advanced

reusability techniques provided by Software Product Lines (SPL)” [22]. There

are some trials to tackle business processes in SPL; Gomaa tries to model

business process in a PLUS method by using UML [30], and Kim proposes a

method managing variability for Software Product-Line [42]. Although both

methods consider variability in use-case, they do not consider the whole

enterprise business process. On the other hand, Schnieders tries to present

business process variability by extending existing notations [43]. But these

methods did not consider whole enterprise business process or show how to use

this model within domain analysis.

1.1.3 Characteristics of a business process in the same domain

Although there are some differences, the business processes in the same

industry domain are similar according to business standards and regulations. In

general, business processes in the same industry should be influenced by

accepted business rules or standards in that domain (e.g. PCT1 standards,

Accounting Standards).

For example, PCT Standards, related to IP (Intellectual Property) rights,

define business rules for PCT patent RO’s (Receiving Offices) as follows: create

document, formality examination for received document, sign and send, and

transfer to WIPO2. If a government accepts PCT standards, they must adhere to

carry out these procedures in their business.

1 PCT(Patent Cooperation Treaty) standard : Washington, DC June 19, 1970 2 WIPO(World Intellectual Property Organization)

3

1.1.4 A need to analyze business process

Understanding business activities in an organization is the first step to

develop business administrative software. Most development methodologies

guide to model business processes to capture or improve the overall

functionalities of many organizations (i.e., banks, government and generally,

service organizations). It is not necessary to model the business process for all

software development. However in developing business administrative software,

understanding business activities is the first action before analyzing user

requirements, and is recognized as the most essential activity of the model

business processes. For example, RUP (Rational Unified Process) guides

business modeling before requirement analysis [27]. It allows traceability

between business activity and a software model, and ultimately a software object

module. It also provides very effective communication facility between software

engineer and end-users or customers. This kind of software development method

is frequently used in IT (In-formation Technology) service companies that have

experiences in developing business administrative software.

1.2 Needs a SPL method to reuse a business process

In general, ‘IT service’ companies adopt software processes to optimize

development and maintenance activities such as CMMI, 6-sigma, ISO, etc.

Although these kinds of methods contribute to remarkable productivity, quality

increase, and cost saving in software development, they are not the ultimate

solution to reduce the cost of software development or maintenance. The main

reason is developing duplicate functions, although the required functions of the

4

application and business process are same. This means there is no

comprehensive research about adopting SPL (Software Product Line) for

business applications.

To adapt SPL for business applications, analyzing the business process

that should be performed in a specific business domain is required. It is said

about the possibility about adopting SPL for developing business applications

that “Business activities in the same business domain are very similar.”

Despite over ten years of research on domain modeling, few methods

have attempted to address the business application domain. One of the reasons is

the absence about practical guides to generate a domain model from a business

process, and bridge between business activities and software products from the

view of end-users or customers. The other is the lack of studies on commonality

and variability analysis for business processes that are highly variable and

require flexibility. It is necessary to design a new approach to overcome these

problems in SPL for business applications.

1.3 Research Objective

The aim of this thesis is to propose a method to a generate feature model

from a business process model. It requires variability notations to illustrate

commonality and variability of business processes, and a mapping mechanism

from a business process model to a feature model. First, to represent

commonality and variability of business process, I propose extended business

process modeling notations for a domain process model. Second, I will show

how to generate feature models from DPM by using folding techniques and a

detailed guideline for each step.

5

1.4 Summary of Contributions

In this thesis, I propose FMBP (A Method to Generate a Feature Model

from a Business Process Model for Business Applications). With this method, a

feature concept is extended to have a service meaning. This gives a

comprehensive understanding on the business process between system engineers

and end-users or customers. It provides traceability between a domain process

model, a domain use-case model, and a feature model. From this traceability, we

can analyze the how feature impact on the whole business processes. Also, it

provides consistent activities between domain engineering and application

engineering for business application development. For example, domain process

modeling activity in domain engineering method matches business process

modeling activity in application engineering method.

1.5 Thesis Outline

The thesis is organized as follows. Section 2 reviews background

knowledge about business process modeling and various feature modeling

methods, and related works about domain modeling method and process

variability modeling method. Section 3 introduces essential concepts in FMBP

and describes detailed guides in each step. An industrial case study employing

this method is shown in section 4. In section 5, I will evaluate proposed method

by comparing it with other works, analyze the economics, and then discuss the

contributions about of proposed method. Finally, I will conclude my work and

discuss further researches.

6

Ⅱ Background & Related works

In this chapter, I will review terms and definitions related to my thesis,

and define a domain model specifically as a feature model and a domain process

model used in this thesis. Next, I will briefly overview background knowledge

about single system development methodologies for a business application and

domain modeling methodologies. Finally, I will illustrate related works such as

the PLUS method, a process variability modeling method, and their drawbacks.

2.1 Business Process Model and Feature Model

2.1.1 What is Business Process Model?

Business activities are those that are concerned with seeking to meet the

needs of customers by providing a product or service. A business process is a set

of linked activities that creates values by transforming inputs into more valuable

outputs. We can see other definitions related to business process in Sprax,

Hammer, WFMC 1995, Davenport 1990, etc.

- “A business process is a set of logically related tasks performed to

achieve a defined business outcome” [4]

- “A kind of process in the domain of business organizational[sic]

structure and policy for the purpose of achieving business

objectives”[10]

- “A business process is defined as a group of tasks that together create a

result of value to a customer” [11]

-“ A business process is a collection of activities designed to produce a

specific output for a particular customer or market. It implies a strong

emphasis on how the work is done within and organization, in contrast

7

to a product's focus on what. A process is thus a specific ordering of

work activities across time and place, with a beginning, an end, and

clearly defined inputs and outputs: a structure for action” [33]

A business process modeling is an activity to generate business

processes model from business processes, Caetano defines business process

modeling as follows.

“Business process modeling specializes on describing how activities

interact and relate with other organizational elements while supporting

the operation of the business.” [37]

From the definitions about business processes and business process

modeling, we can derive business process model as a representation for a

business process by using formal diagrams.

2.1.2 What is a Feature and a Feature Model?

The purpose of feature modeling is to analyze commonalities and

variability among a family of applications in terms of application features, and

then to organize the analysis results into a feature model. Several definitions for

a feature and a feature model are defined as follows.

- “A prominent or distinctive user-visible aspect, quality, or characteristic

of a software system or system” [5]

- “A feature is a requirement or characteristic that is provided by one or

more members of the product line” [30]

- “A feature is a distinguishable characteristic of a concept (e.g., artifact,

area of knowledge, etc) that is relevant to some stakeholders (e.g.,

8

analysts, designers, and developers” [13]

- “A feature is an abstraction of services provided by a system” [Chastek

2001]

- “Feature model is the activity of identifying externally visible

characteristics of products in a domain and organizing them into a

model called a feature model” [25]

- “The feature model specifies the stakeholders’ views of the product line”

[21]

2.2 Analysis and modeling methods for single system development

Generally, development steps for a single system application are

composed of four steps: analysis, design, implementation, and test. I will

reviews some methods about analysis and modeling that are frequently used in

analysis of business application development cases, and then derive some

necessary activities for Software Product Lines for a business application.

2.2.1 Traditional analysis methods

Traditional system analysis methods for a single system application are

categorized into keyword analysis, structured analysis, and scenario-based

analysis. Keyword analysis is for identifying candidate objects from the nouns in

an English description of the problem [2,6]. It is very simple and straightforward.

But, the objects from keyword analysis tend not to be reusable in other

applications because it does not consider a proper domain perspective. That is

the failure to standardize the terminology of the problem domain. Structured

analysis [8] is adapted to solve textual problem descriptions, by applying

9

guidelines for object identification. It derives candidate objects from data flow

diagrams and other products of the structured analysis. The objects are derived

from the models, but it does not accommodate the differences among related

applications as the models are defined for a single application and as they are

based on procedural decomposition. In scenario-based analysis [7,3],

identification of objects is a human activity and analyzing scenarios can

facilitate the identification process. Use Case and CRC cards are the most

frequently used analysis methods. Scenario-based analysis does not provide

rigorous steps for examining the variations that objects should accommodate.

Table 1. Traditional analysis methods

Analysis methods Description Characteristics

Keyword analysis

[2,6]

Finds candidate objects from the

nouns in an English description

of the problem.

very simple and

straightforward

Structured analysis

[8]

Derives candidate objects from

data flow diagrams and other

products of the structured

analysis

The objects derived

from the models

Scenario-based

analysis

[3,7]

Identification of objects is a

human activity and analyzing

scenarios can facilitate the

identification process.

Use Case,

CRC cards

2.2.2 Methodologies including business process analysis

Many methodologies guide the analysis of business processes in early

development such as Waterfall, Spiral, RUP, etc. In this thesis, I will briefly

10

reviews most typical and practical development methodologies based on OOA/D

(Object-Oriented Analysis and Design) for developing business applications,

especially analysis and modeling methods. These methodologies are frequently

used by IT Service Companies that develop business applications.

RUP

The RUP is an iterative software development process framework

created by the Rational Software Corporation in 2002 and is based on OOSE

(Object Oriented Software Engineering). This method gives connectivity

between business engineering and software engineering. A business modeling

and requirement analysis is performed in the analysis phase. In business

modeling, business processes called business use-cases are analyzed. We can

derive all business processes in an organization and common senses from all

related stakeholders. Figure 1 shows detailed tasks in each RUP phase [27].

Figure 1. General Project Life Cycle in RUP

In the RUP, a business model that contains business processes composed

of a business use-case model that is a high-level representation of a business

model, and a business object model that is a detailed-level business model. The

11

RUP shows a clear and concise way of showing dependencies between business

and system models (i.e., use-case model) [27].

PPC methodology

PPC methodology is one commercial development methodology [26].

Many IT Service companies use this methodology to develop a business

administrative application, and are based on a spiral model. From the Figure 2,

‘Work flow analysis’ activity is performed before a requirement analysis. In this

step, we analyze overall business activities in organizations.

Figure 2. Overall Analysis Process

2.2.3 Business process modeling Notations

Although there are many business modeling methods(e.g. BPMN[32],

UML (Unified Modeling Language), BPEL4WS, XPDL (XML Process

Definition Language), no well established modeling standard is available in this

area. Most of the above modeling notations, UML2 Activity Diagram and

BPMN are good candidates for business process model in terms of meta-model,

graphical notation, serial representation, and tool support [39]. UML2 AD is

implemented by various tool vendors, but it is relatively hard to build the model

with. Also, it is difficult to distinguish between some notations. On the other

12

hand, BPMN is more concise, relatively easy to read, and clear in structure [39].

Since it is mainly for business process modeling, it has various modeling

notations. So, BPMN is more suitable for a business process model.

2.2.4 Needs to analyze business process in whole enterprise business for SPL

The RUP recommend business modeling for every software engineering

effort adds more value when there are more people directly involved in using the

system and more information is handled by the system [27]. The reason why

business process modeling should be done is the client is unlikely to know much

about computer system development, but a great deal about their business and

workflow. Discussing the business environment is the basis on which an analyst

should be agree to a system specification with a client. The purpose of business

process modeling is to get an abstract representation of the actual business

processes.

The reasons for modeling business processes are:

– look for candidates for automation

– consider changes to the business process

– consider reengineering the business process

An activity to analyze business process is very essential to develop

business applications. Therefore, it is recommended to consider analyzing

business processes for SPL of business applications.

2.3 Domain Engineering

There are various SPL (Software Product Line) practices. Most

commonly accepted and well-known concept about SPL consists of DE (Domain

13

Engineering) and AE (Application Engineering). Domain Engineering consists

of domain analysis, domain design, and domain implementation. This subsection

introduces some of the most known domain engineering methods. Also, it

discusses detailed feature modeling methods and its evolution history.

2.3.1 Domain modeling methods

Clements classifies product line engineering into four categories:

upgrading older Domain Engineering methods, specializing customizable

Domain Engineering methods, extending existing OOA/D methods, and second

generation integration [16]. Table 2 shows a result research of product line

engineering methods.

Table 2. A research for product line engineering

Categories Methods

Upgrading older Domain

Engineering methods

- FODA(Feature Oriented Domain Analysis)

Specializing customizable

Domain Engineering methods

-ODM( Organizational Domain Model)

-DEMRAL( Domain Engineering Method for

Reusable Algorithmic Libraries)

Extending existing OOA/D

methods

- RSEB(Reuse-driven Software Engineering

Business)

- OOSE(OO Software Engineering)

Second generation integration - FeatuRSEB( Featured RSEB)

- PLUS( Product Line UML-Based Software

Engineering)

14

2.3.2 Feature modeling methods

Feature modeling is very close to conceptual modeling and represents

graphical notation about requirements. Domain analysis concept is first

introduced Neighbors in research about the problem domain of a family of

applications [Neighbors 1980]. After its introduction, many researchers try to

define a domain analysis concept, but some differences exist. The common

things introduced in Harsu are domain scoping (domain definition, context

analysis), commonality analysis domain dictionary (domain lexicon), notations

(concept modeling, concept representation), requirements engineering (feature

modeling) [23]. These activities are categorized into context analysis and domain

modeling [12]. Domain modeling is further divided into three kinds of detailed

analysis, such as feature analysis, information analysis, and operational analysis.

FODA (Feature Oriented Domain Analysis) considers the features of

similar applications in a domain [5]. Features are capabilities of the applications

considered from the end-user’s point of view. Features cover both common and

variable aspects among related systems. They are divided into mandatory (or

common), alternative, and optional features. FODA includes different analyses

such as a requirements analysis and a feature analysis. It produces a domain

model covering the differences between related applications. FODA is currently

a part of the model-based approach of domain engineering. This approach covers

both domain and application engineering. The domain engineering part consists

of domain analysis (FODA), domain design, and domain implementation. In

addition, FODA is further extended into FORM (Feature-Oriented Reuse

Method) [14]. FORM covers both analyzing domain features and using these

features to develop reusable domain artifacts.

15

2.3.3 A survey of domain analysis using feature model

FODA (Feature Oriented Domain Analysis) provides powerful domain

analysis methods from the perspective of end-users. For the various benefits of

FODA in PLE (Product Line Engineering), there are many trials to adopt

modeling methods that are related to SPL. Figure 1 shows various modeling

methods that originate from FODA and a synthesis of other methods. These

methods are divided by three categories. One of them upgrades original feature

modeling method, another adopt feature modeling technique to improve other

modeling methods, and the third is a synthesis of other methods to improve those

methods. FOPLE (Feature Oriented Product Line Engineering) enhances original

FORM (Feature Oriented Reuse Method) and FODA (Feature Oriented Domain

Analysis) [24]. FORE enhances feature modeling notations by adding cardinality

[41]. The second one is methods that use feature modeling to supplement their

domain engineering deficiencies. GP (Generative Programming)[19],

FeatuRSEB (Reuse-Driven Software Engineering Business), PLUS (Product

Line UML-Based Software Engineering), PLUSS (Product Line Use case

modeling for Systems and Software engineering), and FOOM (Feature Oriented

Object-oriented Method) are included in this categories. FeatuRSEB, which is

originated from RSEB, adapts FODA’s feature modeling methods to provide

more flexible requirement engineering [15]. PLUS and PLUSS enhances

FeatuRSEB. It adopts the most powerful functionality of commonality and

variability in FODA to provides SPL of each methods and meta-model of FODA

and RUP [30, 36]. The last one is FOMDA (Feature-based Model-Driven

Architecture), FODM (Feature Oriented Domain Modeling). FOMDA is a

synthesis with MDA and Feature modeling. FODM introduces enhanced feature

modeling techniques and more concrete feature modeling compared to original

16

feature modeling.

Figure 3. The survey of domain analysis using feature model

Chastek et al classifies a product line analysis strategy into two

approaches: Feature-driven and Use-case-Driven [21]. In a Use-case-driven

approach, a feature model is just used for organizing and representing the

commonalities and variability in a UML model. In a Feature-Driven approach,

Use-Case has a role to analyze detailed system responsibility. Table 3 shows

classifications about feature analysis and modeling methods according to

product line analysis strategies.

FODA

(1990)

FeatuRSEB

(1998)

PLUSS

(2004)

FORM

(1998)

FOOM

(2002)

FODM

(2003)

FOMDA

(2006)

FOPLE

(2002)

PLUS

(2004)

Generative

Programming

(2000)

FORE

(2003)

17

Table 3. Modeling approach in feature analysis & modeling

Approach Description Methods

Feature Driven

Approach

Upgrading Original Feature

Modeling methods

FOPLE, FORE, FODM

Use Case Driven

Approach

Integrating Feature Modeling by

using UML

PLUS, GP, FeatuRSEB

PLUSS, FOOM,

Others Integrating Feature Modeling

and Other Methods

FOMDA

2.4 Related works

Despite various Domain Engineering methods, there are some

difficulties to adopt it for business applications. Feature-driven approach mainly

focuses on embedded software that aims to operate specific functionality, thus it

is not easily adopted to develop business applications based on complex and

variable workflows. Use-case driven approach is possible candidate to develop

business applications. The PLUS is the most elaborated methods for this

approach.

2.4.1 Gomaa: PLUS

PLUS is a sort of Use-case-driven approach which provides software

product line by using UML for business application [30]. It illustrates detailed

modeling methods based on UML by integrating previously introduced various

feature analysis methods. In this method, domain analysis composed of SPLRM

18

(Software Product Line Requirement Modeling) and SPLAM (Software Product

Line Analysis Modeling). SPLRM carries out use-case modeling at first like

FeatuRSEB, and then feature modeling follows based on the result of use-case

modeling. This method tries to overcome the drawbacks in UML-based domain

analysis by adapting commonality and variability analysis techniques in feature

modeling. In use-case modeling, it guides to identify a detailed use-case for a

system, and then generate a domain use-case to show abstract information of a

detailed use-case.

Because it uses the bottom-up approach to generate a final feature model

by analyzing individual use-cases, it does not consider the impact how one use-

case affects the overall system. As a result, there probably exist missing or

duplicate functions. Features are organized with respect to use-case

characteristic (i.e. kernel, optional, and alternative) not by the common

functionality that is visible to end-user. For example, all mandatory use-case

models are organized to Kernel Feature. Therefore it does not give intuitive

understanding about feature functionality. This method has drawbacks as follows.

It is possible to create missing or duplicate functions because of its

bottom-up approach. This is its most serious fault.

It is not possible to analyze what is important about a feature in the

whole business process and how it impacts the whole business process.

It does not consider the complexity and variability of the business

process.

It does not provide proper traceability between the business activity

and software product.

19

2.4.2 Schnieders: Modeling process variability

There is a trial to model variability of business processes based on a

family-based software development process [17]. Schnieders introduces

variability modeling notations that extend BPMN by adapting a stereotype of

UML2 [43]. Figure 4 shows two kinds of variability modeling notations for a

business process model introduced in his paper. But, there are some drawbacks

to this method. This method only depicts the representation of business process

variability. It does not show a relationship between a business process variability

model and other domain modeling elements. Also, these notations did not

represent composite variability. For example, a process has optional and

alternative characteristics, one of characteristics is not represented by notation,

see ‘4.3 Notations’.

Figure 4. Variability modeling about business process model(example)

a) Alternative sub-processes b) Optional sub-processes

20

Ⅲ. Generating a Feature Model from a Business Process Model

Generally, the output produced by business activity is used as an input

for next business activity. Therefore, business applications have more complex

functionalities and should be integrated in view of the whole enterprise. It is

necessary to access a Top-Down and Divide-and-Conquer approach to solve

these problems appropriately. This thesis tackles these issues from a whole

enterprise business process viewpoint.

3.1 Definitions used in this thesis

From the background knowledge, it is necessary to define some newly

introduced essential concepts about DP(Domain Process), DPM(Domain Process

Model), and DM(Feature Model). Domain Process is a similar concept against

business process in application engineering, and shows abstract business

activities in some domain: “DP (Domain Process) is a collection of work

activities which shows abstract information of business activities.” Also, DPM

(Domain Process Model) is a similar concept against business process model,

and present commonality and variability of business process in some domain:

“DPM (Domain Process Model) is a business process model that represents

commonality and variability of business process model.”

As seen in before, feature concept is widely used in most domain

engineering practices. Many researchers define a feature concept, but there are

some differences in feature concept according to application domain. In this

thesis, I will define feature concept as follows by including service concepts. “A

feature is a distinguishable and user-visible characteristic of a service that is

relevant to among stakeholders (e.g., end-user, analysts, designers, and

developers).

21

3.1 Relationship: Business activity, Use-case and Feature

It is necessary to adapt three kinds of use-case concepts to explain

relation between business activity, use-case and feature: system/sub-system use-

case, group use-case, and use-case. This is based on the fact that system or

subsystem usually consists of several services, and a service is also divided into

several use-cases that are expressed in minimum interaction units between

system and user. A use-case group is a bundle of unit use-cases that have similar

and closely related functionality. This use-case group is further linked to a

feature. Use-case means a domain use-case that is referred to in PLUS[30]. In

doing such, it is possible to show clear relationships on between use-case model

and business process model.

From RUP, we can see the relationships between the business process

model and use-case model. The size of business activity can vary according to

abstract level or design strategies. The RUP defines 6 design scenarios for

business modeling. In this thesis, ‘One Business, Many Systems’ is more

suitable. Another scenario to be considered is ‘Domain modeling’ for its

representation of information at a business level. In this thesis, business activity

is a business entity in business use-case and represents business level

information that is stated in RUP.

From the definition of feature, feature can have many functions. It

means that a feature can be composed of many use-cases. From the definitions of

the use-case group, a feature can be mapped to a use-case group. Therefore, one

feature can be related to many business activities. This relationship is depicted in

Figure 5. These relationships provide traceability between each model.

This approach gives trace information among each model in domain

analysis. The characteristic of this method is as follows. It was devised to keep

22

consistency between software product and business activity by analyzing the

business process analysis that is not handled by existing methods, and also pro-

motes Software Product Line for Business Applications.

Figure 5. Relation among Business activity, Use-case and Feature

3.2 Domain Analysis Approach: From a business process to a feature model

The starting point of FMBP is a business process analysis. A Domain

Process Analysis makes it possible to know where one use-case belongs to whole

Feature

C

BA 2

BA 4

BA 5

BA n

Feature

B

Use-Case 4

Use-Case 5

Use-Case 3

Use-Case 2

Use-Case 1

Use-Case 6

Use-Case n

Group Use-Case 2

Group Use-Case 1

System/sub-system Use-Case

BA 6

Domain Process Model Domain Use-Case Model Feature Model

Feature

A

BA 3

BA 1

[PLUS approach][FMBP approach]

23

process, and to grasp how one use-case can affect the whole system. Moreover it

can supplement consideration about system engineer’s viewpoint that is

insufficient in an existent feature-driven approach and end-user’s insufficient

evaluation of an actual existent use-case driven approach. Figure 6 shows

conceptual image about FMBP and its analysis steps. DPM (Domain Process

Model) has the central role of connecting business activities and feature models.

In step 1, commonality and variability in business process model is analyzed

(①). Then creates a DPM according to process variability notations (②). DPM

is used (③) in feature analysis and a folding technique is applied. DPM is folded

for generating use-case groups that is further identified to feature candidates and

generate (④) feature models.

Figure 6. From business process to feature model

3.3 FMBP Steps

FMBP consists of two steps. This method is invented to apply SPL

(Software Product Line) for developing business application’s domain that is

rarely studied in current SPL.

Feature Analysis

Business Process Model

Feature Model

Domain process analysis

Step1. Step2.

Domain Process Model)

Marketing plan, etc

SPL plan -product plan, etc ① ② ③ ④

24

Figure 7. FMBP Steps

3.3.1 Step 1: DPA (Domain Process Analysis)

Business process analysis allows the analyst to capture the broad outline

and procedures that govern what a business does. In an early model of business

activity, it allows the analyst to capture the significant events, inputs, resources,

and outputs associated with a business process. Therefore, the first step in

domain process analysis is to understand user activity and identify business

activities. And then realize an overall map of the relevant domain processes

among those business activities. By analyzing business process, we can realize

characteristics of business activities, the effect on whole business process, and

the scope of the proposed system.

① Derive domain modeling plan

Scoping means a product line scope. This idea is based on MPP

(Marketing and Production Plan) in FOPLE [24]. The scope of a software

product can be varying according to enterprise's marketing strategy or other

Step2. FA(Feature Analysis)

① Folding business process model

② Identify feature candidate

③ Generate FM(Feature Model)

Step1. DPA(Domain Process Analysis)

① Derive domain modeling plan

② Analyze business process commonality and variability from BPM

③ Generate DPM(Domain Process Model)

25

things. Thus, this is the step to analyze these marketing and other materials to

determine product scope and generate a product line domain process model.

From the marketing plan and other materials, we can derive a domain modeling

plan. We can generate any format for a domain modeling plan. In this thesis, I

will use textual modeling plan as follows.

Plan 1; implement machine formality check in some part of formality

check

② Analyze business process commonality and variability from BPM

Business process model gives us an intuitive representation about the

characteristic (Optional, Alternative, Mandatory business process) of individual

business activity in whole business processes. Commonality and variability

analysis should be carried to find out the characteristics of business processes

from whole or part of business process model. The relationship between activity

notation and characteristic of BPMN and UML ADs is summarized in Table 4.

We can realize commonality and variability in business processes from this table.

Table 4. Activity characteristic from business process model

Activity Characteristic

UML ADs BPMN Optional Alternative Mandatory

Sequence Sequence O

Fork Fork(AND-Split) O

Join Join(AND-join) O

Decision(OR-split) O O Decision

Inclusive O O

26

Activity Characteristic

UML ADs BPMN Optional Alternative Mandatory

Merge Merging (OR-join) O

③ Generate DPM(Domain Process Modeling)

After modeling current business process, we should transform this

business process model to DPM (Domain Process Model) from the modeling

plan. We analyze the commonality and variability of business processes

according to Table 5, and then derive a domain business process model.

Merge similar business processes

In some cases, such as application and registration business process in

the aforementioned IP business, some business activities are very similar in their

operation. Therefore, these similar business activities can be merged and

integrated according to their similarity. Figure 8 shows partial business process

about ‘Receiving’ and ‘Form examination’ process in an application and

registration process. As we can see in Figure 8, there are similar activities such

as ‘Application document receiving’ and ‘Registration document receiving’.

Since these two activities perform the ‘Document receiving’ action for an

application document or a registration document. In this case, classify one

representative common business activity for similar business activities. A

merged business process is shown to the right business process model in Figure

8. An ‘Application document receiving’ and ‘Registration document receiving’

activity is merged to a ‘Document receiving’ activity. And add a branch notation

to branch ‘request for digitization’ and ‘digitizing bibliography’ after ‘document

receiving’ activity according to received document type.

27

Figure 8. Receiving process for an application/registration business process

Transforms BPM to DPM

Figure 9 shows examples of transforming a business process model to

domain process model by adding a process variability model. This modeling

notation is first introduced in Schnieders [43]. In Figure 9-a,’online submit’ and

‘paper submit’ can be organized to ‘submit’. Thus, introduce

‘<<Abstract>>Submit’ to represent variability about ‘Online submit’ and

‘Offline submit’. After ‘Document receiving’ activity, process should be

branched into two different sequence of digitization process. Thus, it is

necessary to show process variability. Figure 9-b shows process variability of the

digitization process.

Application receiving process

Document audit

Document stock

Request for digitization

Application document receiving

Digitizing bibliography

Registration documentreceiving

Registration receiving process

Receiving Process

Document receiving


Document Audit

DocumentStock

Request for digitizationMerge

28

Figure 9. Model transformaion according to process variability

3.3.2 Step 2: FA (Feature Analysis)

In the feature analysis step, features are realized from DPM (Domain

Process Models). In this step, it is needed to organize use-case groups from

domain process models. This technique is called ‘folding’. Folding is a technique

to group use-cases. It is used to identify feature candidates from a business

process model. As we can see in Figure 5, one business activity can mapped to

one use-case. Thus, folding is a method to organize the result of domain process

analysis to use-case groups that have the highly related or similar functionality.

After folding DPM, features are identified and depicted by graphical notations.

In this thesis, a use-case group can be identified to a feature. Identify feature

candidates from the use-case groups and create feature models from identified

OnlineSubmit

Offline Submit

<<Abstract>> Submit

b)

Out-sourcing digitization

Self digitization

<<Abstract>> Digitization

a)

29

feature candidates. Therefore, features in our method have a business process

concept. Its aim is to easily adapt the process change, and improve

communication for the end-user.

① Folding business process model

Figure 10 is a conceptual image to apply folding technique from whole

business process. It is important to give traceability among each model used in

FMPB. The level of traceability depends on the level of abstraction in each

model. In this thesis, the abstraction is the user activity level. This requires three

important aspects: a user viewpoint that is related to business process, functional

relativities among each business process, and process commonality/variability in

the whole business process. In this figure, a part of business process is extracted

by process characteristics. The following are detailed folding method steps. But

it is not important which step start first between step1 and step 2.

Step 1. Analyze functional variability

- Organize business process according to functional similarity

- If some business processes are recursive, then these business processes

are very similar functionality.

Step 2. Analyze process variability

- Organize business process according to commonality and variability in

business process

- Go to step 1 utile business process is properly organized

Step 3. Analyze end-user variability

- If there are many users who involved in grouped business process, then it

should be split into sub process from the perspective on the user as much

as possible.

30

Figure 10. Conceptual image to apply folding technique

② Identify feature candidates

Identifying candidate features is very simple. One use-case group can be

identified to one feature. The characteristic of feature reflects the characteristics

of use-case group in the whole business process.

Table 5. An example about feature candidate lists

Feature Use-Case group

Name Property Name Property

Digitizing Bibliography, Mandatory Document scanning Mandatory

Self-digitization Optional

Eye Checking Mandatory

For example, if use-case group is optional in a whole business process,

the relevant feature is becomes an optional feature. From the figure 10,

<<Abstract>>Receiving

<<Abstract>>Digitization

Allotment

<<optional>> Fee rightness

check

Machine Formality

Check

Document Scanning

Digitizing Bibliography

Eye Checking

Receiving

Officer

Functional View:-Digitization

User ViewProcess View - Commonality - Variability


Self digitization

<<Abstract>> Digitization

31

‘Digitizing Bibliography’, ‘Document scanning’ and ‘Eye Checking’ are further

realized to ‘Self-digitization’ use-case group. This is identified to ‘Self-

digitization’ feature like Table 5.

③ Generate feature model

We can see the basic feature modeling methods in Kang [Kang 1990]. In

this thesis, I will adopt FORE notation which adds cardinality notation in feature

model [34]. This notation represents feature composing constraints and

eliminates ambiguity in the model, and gives a clear meaning in model structure

[41].

Figure 11. Feature Modeling by introducing group feature

To organize the feature model from the candidate business process

feature, it is necessary to introduce group feature concepts. Group features do

not have real function. They only have a common conceptual meaning among

subordinated sub-features. As we can see Figure 11, group features such as

Alternative OptionalMandatory Cardinality

Legend

Feature

G1

Feature

B

Feature

A

1

Feature

C

Feature

G2

1..2

step2. Grouping

Feature G1 and C step1. Grouping

Feature A and B

32

‘Feature G1’, ‘Feature G2’ are used to organize the feature model together with

real features, such as ‘Feature A’, ‘Feature B’, and ‘Feature C’. In step1, sub

feature model is made by introducing ‘Feature G1’ together with ‘Feature A’,

‘Feature B’. In the next step, previously organized sub-feature model and

‘Feature C’ is used to form the final feature model.

3.4 Notations

Schnieders tries to model process variability [43]. But, his notations do

not properly represent business process variability in some complicated cases of

the business process. Therefore more notations to represent process variability

should be introduced. Table 6 summaries of new notations.

Table 6. Process variability notations

Variability process Notations

Mandatory prpcess

Optional process

Alternative process

3.4.1 Representing alternative process

‘Screen formality check’ in IP business should be followed after joining

‘Machine formality check’, ‘Fee rightness check’, ‘Allotment’ like Figure 12-a

or after rejected in ‘Sign’ process like Figure 12-b. But existing notation can not

describe these business constraints. Reducing this ambiguity in this business

process model, it is very suitable to mark process variability above an ‘arrow

line’ which represents a flow of business process. If merged business processes

are exclusively selected, then mark alternative process notations in each arrow

33

such as Figure 12-c.


3.4.2 Representing optional process

From Schnieders’ notations, optional process can be illustrated as

‘<<Optional>>’’ notation. But if one business process has the optional and

alternative characteristics, then this ‘<<Optional>>’ notation is not appropriate.

This case is appeared in reiterated conditional branch process as we can see in

Figure 13-a.

Allotment

<<Optional>> Fee rightness

check

Machine Formality

Check

Send

Sign

Allotment

<<Optional>>Fee rightness

check

MachineFormality

Check

a)

b)

Process curtailmentLegend

Send

Sign

c) Formality Check

Formality Check

Formality Check

34


In Figure 13, digitization sub-process has an alternative and optional

property. In this case, use ‘<<Abstract>>Digitization’ to represent alternative

process like Figure 13-b, then mark optional process notation in its arrow line as

shown in Figure 13-c.

Notations used in this thesis are BPMN, feature modeling notation and

use-case modeling notation. In domain process analysis, BPMN and process

<<Abstract>>Document Receiving


Allotment

<<Optional>>Fee rightness

check

MachineFormality

Check <<Abstract>>

Document Receiving


Allotment

<<Optional>> Fee rightness

check

Machine Formality

Check

c)b)

Allotment

Fee rightness check

Document receiving

MachineFormality

Check Digitizing bibliography

Eye Checking

Document Scanning

Audit document

Stock document


a)

35

variability notations are used to represent domain business process with

commonality and variability. In feature analysis, UML and FODA notation is

used. As seen from the comparison result about feature modeling, FORE

notation reduce ambiguity in a feature model [41]. FORE notation is more

suitable for clear structure and meaning in a feature model. In this thesis FORE

notation is used for feature model. Table 7 summarizes notations used in this

thesis.

Table 7. Notations used in this thesis

Analysis steps Default Extensions Related model

Business process

analysis BPMN

UML2 stereotype

Process variability notation

Business process model

Domain process model

UML AD - Use-case model Feature analysis

FODA FORE Feature model

36

Case StudyⅣ

4.1 Business process about IP

4.1.1 Overview about IP business processes

IP business processes consist of application, examination, registration,

publication and petition business for internal users, and documentation for

external users. In this case study, I will show an application and a registration

business process for their similarities of business processes. The business

processes of an application and a registration consist with receiving, form

examination, and sign&send business. Figure 14 shows an overall IP business

process model proposed by Ericksson and Penker [18]. In this method, the depth

of the process hierarchy depends on the complexity of the business system to be

modeled. But, final levels of business processes should be present user activities.

Figure 14. Overall IP business process

Receiving Form

Examination

Sign &

Send

Application Examination Registration Publication Petition Documentation

<<Abstract>> Document Receiving


Receiving Business

Level 1:

Level 0:

Level 3:

37

4.1.2 Short descriptions about IP business processes

Applicants submit an application document to RO(Receiving Office) by

using on-line receiving application or visiting office. An IP document is

composed of bibliography and specification part. In case of receiving paper

document, it must be digitized in electronic document. But, there are some

differences in digitization processes. In application document, bibliography and

specification part should be digitized by out-sourcing, but registration document

only requires to digitize bibliography part. A document received by online and

digitized is distributed to form examiners after allotment business process.

Allotment business process sets form examiners for each received documents.

Form examiners examine formality in document mainly bibliography part such

as formats of date, formats of application number, and regal status for

application event. If a paper requires fee, fee rightness check must be followed

after formality check. After finishing form examination process, form examiners

draft a document to accept his examination work result such as acceptance,

denial and amend of document. If the examination result is denial or amend, the

draft document will be sent to applicants. Bellows are summaries about the

difference in business processes between an application business process and a

registration business process.

Document structure: An application document is composed of

bibliography part and specification part, but a registration document only

has bibliography part.

Digitization process: An application document should be digitized full

paper by out-sourcing, but registration document is digitized in self

document entry function.

After send process: Application receiving history was created from

38

application document. Registration history was created from registration

document data.

4.2 Business Process Analysis

In business process analysis, it is required to identify business activities

and model business process according to business process modeling notation.

4.2.1 A document business process

Table 8 shows lists of business activities about an application business

process from the business process analysis step.

Table 8. A list of a registration business activities

Business

categories

Business

Activity Description

Documenting

application document

Create application document according to the formatting

guide that is defined at patent law.

Online submit Submit document through internet.

Paper submit Submit document by mail or visiting the receiving office.

Document

Fee submit If the document requires fee, then submit the required

fee.

4.2.2 An application business process

Table 9 shows lists of business activities about an application business

process from the business process analysis step and Figure 15 shows application

business process model together with a documentation business process.

39

Table 9. A list of an application business activities

Business

categories

Business

Activity Description

Application

Document receiving

An activity to receive paper document and create

receiving information.

Request for

Digitization

An activity requesting digitization about received paper

document

Document audit Check the results of digitization.

Document stock Stock a document that is digitized.

Receiving

On-line receiving Receive document and create receiving history.

Formality check Check formality of application or interim document such

as digitization error that is not recognized at document

audit activity, correctness of entry item.

Allotment Distribute received document to formality examiner

Fee rightness

check

If the paper requires fee, then check the amount of

required fee.

Form

examination

Document

drafting

After formality check, form examiner decides whether

accept or denial about received document. After deciding,

form examiners create a draft according to predefined

drafting document format.

Sign An action decide whether approve or reject about draft

Send Send the notifications about the result of form

examination

Sign &

Send

Create application

history

Create application histories according to received

document contents

40

Figure 15. A Business process model for an application process

4.2.2 A registration business process

A registration business process is very similar to an application business

process. Table 10 shows lists of a registration business process that is different

from an application business process and Figure 16 shows business process

model for registration business together with documentation business process.

Table 10. Lists of a registration business activities

Business Activity Description Others

Documenting

registration document

Create application document according to the

formatting guide that is defined at patent law

Registration An activity to receive paper document and create

41

Business Activity Description Others

Document receiving receiving information.

Digitizing

bibliography

Create bibliography element about received paper

document

Modify registration

history

Update registration history according to received

document contents

Figure 16. A business process model for a registration business process

4.3 Domain Process Analysis

4.3.1 Derive Domain Modeling plan

After analyzing marketing, product plan, and business process model the

42

result of previous analysis, domain modeling plan is summarized as follow.

Plan 1; Implement a new process for machine formality check which

automatically check some part of formality check

Plan 2; Design parallel process about ‘Machine formality check’, ‘Fee

rightness check’, and ‘Allotment’.

Plan 3; Design ‘Out-source digitization’ business process for specification

part, add more functions for bibliography part such as ‘Document scanning’

and ‘Eye checking’.

From the domain modeling plan, we can identify newly product

candidate for digitization business process from the plan 3. Table 11 shows

partial lists of new product candidate for ‘Self-digitization’ business process.

Table 11. New Product List about ‘Self-digitization’ business process

Business

Activity

Product

ScopeDescription

Document scanning Yes Scan received document

Eye checking Yes Check the quality of scanned document and

digitized document.

4.3.2 Analyze business process commonality and variability from BPM

From the ‘Application business’ process and ‘Registration business’

process, most of activities are very similar. Some business processes is same

such as ‘Online submit’,’ Paper submit’, ‘Fee submit’, ‘Formality check’, ‘Sign’,

etc. Some business processes are very similar but not same such as

‘Documenting registration document’, ‘Documenting application document’,

43

‘Application document receiving’, ‘Registration document receiving’, etc. But

some business processes are different such as a sequence of ‘Out-sourcing

digitization’ business process such as ‘Request for digitization’, ‘Stock

document’, and ‘Audit document’, and a sequence of ‘Self-digitization’ business

process such as ‘Digitizing bibliography’, ‘Create application history’, and

‘Modify registration history’ activities.

4.3.3 Generate Domain Process Model

By analyzing commonality and variability in activity and reducing

business process complexity, merge business processes according to process

similarities. For example, ‘Application document receiving’ and ‘Registration

document receiving’ activity are merged to ‘Document receiving’ activity. Add

branch diagram between ‘Request for digitization’ and ‘Digitizing bibliography’.

The result of merging business process model is shown in Figure 17.

Figure 17. Integrated Business Process Model

44

Process variations are shown in Figure 18 and overall domain process

model is shown in Figure 19. Organize ‘<<Abstract>> Submit’ process with its

variable process ‘Online submit’ and ‘Offline submit’ process by process

variability. Draw ‘Receiving’, ‘Fee submit’, ‘Document transfer’ and ‘Submit’

and ‘Digitization’ process as abstract process like Figure 18. From the domain

modeling plan, new product list should be integrated domain process model. Add

‘Document scanning’ and ‘Eye checking’ activities after ‘Digitizing

bibliography’ process. These digitization related business processes are

composed of a sequence of process and also have a variability characteristic.

Compose ‘ Documenting bibliography’, ‘Document scanning’ and ‘Eye

checking’ process to ‘Self-digitization’ business process like Figure 19-d. Other

business processes are composed to ‘Out-sourcing digitization’ process like

Figure 19-c. Compose these two business processes to ‘<<Abstract>>Digiti-

zation’ process like Figure 18-b. From this domain process model, receiving

officers choose ‘Out-sourcing digitization’ process and ‘Self-digitization’

process after ‘Document receiving’.

Figure 18. Process Variation Point

Online Document receiving

Offline Document receiving

<<Abstract>> Receiving

Online Submit

Offline Submit

<<Abstract>> Submit

Credit Card

Account Transfer

<<Abstract>> Fee Submit

Create application

history

Modify registration

history

<<Abstract>>Document Transfer


Self digitization


a) b) c)

d) e)

45

Figure 19. To-Be business process model

Organize parallel process for ‘Fee rightness check’, ‘Machine formality

check’, and ‘Allotment’ after ‘<<Abstract>>Digitization’ activity. Digitized

document or document received by on-line are split to ‘Fee rightness check’,

‘Machine formality check’, ‘Allotment’ processes. After processing each

sequences, they are merged (synchronized) to ‘Screen formality check’ process.

a)

Audit document


Stock document



Eye Checking

Document Scanning

Self digitization

Online Receiving

Issue receipt Paper

Online Document receiving b)

c)

d)

Edit Document

Documentation

Send

Sign

Form Examination Sign&Send Receiving

<<Abstract>> Document Transfer

<<Abstract>> Submit

<<Abstract>> Fee Submit


AllotmentScreen

Formality Check

<<Alternative>>Fee

rightness check

Machine Formality

Check

Document drafting

<<Abstract>>Receiving

46

4.4 Feature Analysis

4.4.1 Folding Business process model

After modeling domain process model, then fold this model to generate

feature models. In this step, we will show folding process and its result about

digitization business process. The folding steps for digitization business process

are as following.

Step 1- Split partial business process based on Swimlanes: Receiving, Form

examination sub process. Continued folding process shows receiving

officer’s business process.

Step 2- Business processes for receiving largely consist of two different

functions: document receiving and digitizing the received document.

Therefore, receiving business process is partitioned into ‘Document receiv-

ing’ and ‘Digitization’ business processes. The result of this step is shown in

Figure20.

Figure 20. After folding step 2

Step 3- Digitization process related to different users, their functional

similarity differs from each other. Each sub processes are processed

optionally. Therefore, the ‘Digitization’ processes should be spited into ‘Out-

sourcing digitization’ and ‘Self digitization’ sub processes for user viewpoint.

And group those business activities according to use-case model like Figure

21.


self digitization


Online Document receiving

Offline Document receiving

<<Abstract>>Document receiving

47

Figure 21. Receiving officer’s use-case folding for digitization

4.4.2 Feature Identification

In this step, we can analyze feature candidates from use-case models and

group features to organize feature models. Identifying feature candidates form

use-case groups are very straightforward. A use-case group can be mapped to a

feature candidate. Name the feature from the use-case group name, and get the

characteristics of use-case group. Table 12 shows candidate feature and its

characteristics with respect to Figure 20 and Figure 21.

Table 12. Feature lists for digitization business process

Feature Use Case

Name Name Name Property

Document receiving Mandatory Off-line document Receiving

AlternativeIssue paper receipt Mandatory Online receiving Mandatory On-line

document receiving Alternative

Issue online receipt Mandatory Audit Document Mandatory

Request for document electronic Mandatory Out-sourcing digitization

Alternative

Receive electronic document Mandatory

Document scanning

Eye checking

Making bibliography

Request for digitizationdocument

Audit document

Stock document

Document

Audit

officer

Document

Editor

officer

48

Feature Use Case

Name Name Name Property

Digitizing bibliography Mandatory Document Scanning Mandatory

Self-digitization Alternative

Eye checking Mandatory

The feature lists in Table 12 can be presented like Figure 22 as we can

see this notations in PLUS.

Figure 22. Feature presentation

4.4.3 Feature Modeling

To construct a feature model from feature lists, it is necessary to create

group features such as ‘Receiving’, ‘Document receiving’, and ‘Document e-

filing’ group features. In this case, digitization group feature includes ‘Out-

sourcing digitization’ and ‘Self digitization’ business processes. Table 13 shows

<<alternate Feature>> e-filing out-sourcing

<<alternate Feature>> Electronic documenting

<<alternative Feature>> Off-line document receiving

<<alternative Feature>> On-line document receiving

Online receiving

Issue online receipt

Document receiving

Issue paper receipt

Request for document electronic

Audit document

Stock document

Documentscanning

Eye checking


49

partial group features for ‘Receiving’ business process.

Table 13. group feature lists for receiving business process

Group Feature Sub feature

Name property Name Others

Receiving Mandatory Document receiving, Digitization

Document receiving

Mandatory On-line document receiving,

Off-line document receiving

Digitization Mandatory out-sourcing digitization,

self-digitization

From feature lists in Table11 and group features in the Table 12, feature

model for ‘Receiving’ feature is represented in Figure 23. At first, organize

‘Document receiving’ feature with ‘On-line document receiving’ feature and

‘Off-line document receiving’ feature. Give optional properties to them and then

set the cardinality according to the number of sub features. This is shown at

Figure 23-a. In Figure 23-b, previously organized ‘Document receiving’ sub

feature tree and ‘Digitization’ sub-feature are used to organize ‘Receiving’

feature tree continuously. By doing this feature modeling for all IP business

process, final feature model for partial IP business process is show in Figure 24.

50

Figure 23. Create partial feature tree by introducing group feature

Figure 24. Partial Feature Model for IP business process

On-line document receiving

Off-line documentreceiving

Documentreceiving

out-sourcing digitization

1

Digitization

Receiving

self-digitization

1

1..2



Document receiving

1

a) b)



Document receiving

out-sourcing digitization

Send

Sign & Send

1

Digitization

Receiving

self-digitization

1

1..2

Machine formality

check

Formality Check

2..3

Screen formality

check Allotment

Fee rightness

check Create

application history

Document transfer

Modify registration

history

Signc)

a)

d)

Fee Submit

Documentation

Document editor

1..2

2..4

1

b)

51

Ⅴ Evaluation

In this thesis, I will consider existing comparison frameworks, and

propose a new framework to evaluate various practical modeling factors. Finally,

I will estimate a cost to development application under my approach, and

analyze ROI against existing ad-hoc reuse cost with a short discussion of the

results.

5.1 Comparison with existing modeling methods

5.1.1 Existing comparison framework at a glance

There are many methods for comparison with product line design

methods. Mari Matinlassi proposes NIMSAD Framework for comparison about

architecture design methods [31]. In his paper, we can see a comprehensive

comparison result between COPA, FAST, FORM, KobrA and QADA. NIMSAD

framework composed of Context, User, Contents, and Validation. Generic

Product Line Process Framework compares with SEI FSPLP, Synthesis, DsE,

RSEB, SPICE, NRC, and SPF methods in the point of product line management,

domain engineering, application engineering, and third party product acquisition

[20]. Other methods for software architecture evaluation methods are SAAM,

ALMA, PASA, and ATAM [28]. In these methods, each method is evaluated in

the point of context, stakeholders, contents, reliability. Also this method provides

more detailed modeling techniques to generate software an architecture model

from a feature model. But, those methods are too high to compare detailed

modeling factor, there is needs to be a more detailed low-level of comparison to

derive new feature modeling technique.

52

5.1.2 Comparison Framework

Comparison framework consists with an analysis task to develop a

process-oriented business application, commonality & variability analysis in

each analysis tasks, and other important factors to organize a domain model. In

an analysis task, I will compare whether or not to perform business process

analysis or use-case analysis as in single system development methods. Business

process analysis is a top-down approach to see an overall system perspective.

The benefit of in this method is that it provides traceability between business

activity and software product, and facilitates communication between end-user

and system engineer. Also, it provides swift adaptation. Use-case analysis is a

frequently used analysis method in the application engineering phase. In this

thesis, use-case model is a bridge between business process model and feature

model. Commonality and variability analysis is very important. By doing this,

we can identify a reusable software product. I will compare commonality and

variability representation notations and its ambiguity. Other comparisons

categories are modeling aspects, like traceability and completeness.

5.1.3 Comparison result between Gomaa, Schnieders and the proposed

method

It is suitable to compare Gomaa’s PLUS method, Schnieders’ process

variability modeling method. The PLUS method shows various application do-

mains and a method to generate a feature model from a use-case model. His

overall approach is very similar to the proposed method. The reason why

compares Schnieders’ methods is that it tries to analysis commonality &

variability in business process and shows variability notations about business

process model.

53

Analysis task

PLUS method uses a use-case analysis. Therefore its modeling

approach is bottom-up. The proposed method and Schnieders’ method use a

business process analysis that is a top-down approach. Business process analysis

can help to see overall business process viewpoint. Use-case analysis is used in

PLUS and proposed work. In PLUS, use-case analysis is core activity to derive

feature model, but proposed work uses use-case as a bridge between business

process model and feature model. In this thesis, a folding task in feature analysis

generates a use-case model. After producing a use-case model, a feature model

extracted from it.

Commonality & Variability

In commonality & variability analysis, I will compare business process

analysis and feature analysis. Schnieders uses BPMN (Business Process

Modeling Notation) to represent business process. He proposes variability

notations to illustrate process variability by extending a UML 2 stereotype. But

his method has some ambiguity in presenting process variability. For example,

the ‘Digitization’ process in the IP business processes is optional, and

‘Digitization’ has two alternative sub-processes. In this business process,

Schnieders’ methods only present optional or alternative characteristics. So, one

of process characteristic is omitted. Alternatively, the proposed method provides

notations to mark optional or alternative characteristics in business flow.

Ambiguous in business process is eliminated by using this notation.

Model aspects

The proposed method and Gomaa’s work provide traceability between

user’s business activity and a feature model. The proposed method provides

54

traceability between a business process, a use-case, and a feature model, whereas

Gomaa’s work only provides traceability between a user-case and a feature

model. The range of traceability for business activities and a domain model in

the proposed method and Gomaa’s work is limited to only the portions within

product scope.

Gomaa’s work tends to produce duplicated functions and omit some

functions, since it uses a bottom-up approach. On the other hand, the proposed

method and Schnieders’ work uses top-down approach. Therefore there are no

duplicated or missing functions. As a consequence, Gomaa’s work is incomplete

and the proposed method and Schnieders’ are more complete in the point of

model’s completeness.

Table 14. group feature list for receive business process

Proposed Method Gomaa Schnieders

Analysis task

Analysis approach Top-down Bottom-up Top-down

Business Process

Analysis

Yes No Yes

Use-case Analysis Yes Yes -

Feature Analysis Yes Yes

(Mapping Table)

-

Commonality & Variability Analysis

Business Process

Notations DPM

( BPMN+ process

variability notation)

- BPMN

Notation ambiguity No - Yes

55

Proposed Method Gomaa Schnieders

Feature

Notations FORE

( FODA +

cardinality notation)

UML

Notation ambiguity No Yes N/A

Modeling aspects

Traceability DPM-UML-FM UML-FM -

Completeness Complete In-complete Complete

5.2 ROI Analysis

There are three types of development to economically analyze no re-use,

ad-hoc reuse, and FBMP. Ad-hoc reuse is a existing development type that

reuses the results of existing application without adopting SPL. COPLIMO is a

kind of cost estimation model [29]. In this ROI analysis, I will analyze ROI

against ad-hoc reuse in addition to analyze ROI against no reuse. For the

complexity of analysis, I will estimate not each feature cost but the whole

product cost, because it is too time consuming and difficult to identify which

parts of source code in existing application are matched to newly produced

features. Reusing scale for FMBP is the value of ad-hoc reuse except ‘Design

Modification’, since ad-hoc reuse only considers reusing code. As seen in

Yamamoto [38], sharing know-how can save time in the early phases of business

system development. So, the reuse ratio for design is higher than code reuse. So,

‘Design Modified’ ratio is less than 34%. But I will assume ‘Design Modified’

ratio of 35% same as ‘Code Modified’. There are 17 similar business processes.

56

Average source code line is 181 KSLOC. The code modify ratio is 34% and

‘Integration Required for the Adapted Software’ ratio is 40%. The following are

input factors for IP applications.

Table 15. Input factor and data for IP business application

Input item Value Scale

Product-specific fraction (PFRAC): 181 KSLOC

Product-specific fraction (PFRAC): 40 %

Adapted-software fraction (AFRAC): 30 %

Reused-software fraction (RFRAC): 30 %

# of products in product line: 17 %

DM(% Design Modified) 25 %

CM(% Code Modified) 34 %

IM(% of Integration Required for the Adapted Software) 40 %

Table 16 and Figure 25 show the cost estimations result of product line

development with FMBO versus ad-hoc reuse and no reuse. From the table,

Product Line Savings against ad-hoc reuse is BE(Break Even) at fifth product,

and Product Line Savings against no reuse is BE at second product.

Table 16. Product Line Development Cost Estimation result

# of Products Effort (PM) 0 1 2 3 4 5 6 7 8 9 10

No Reuse Effort 0 532 1,065 1,597 2,130 2,662 3,195 3,727 4,260 4,792 5,325

Ad-hoc Effort 0 500 849 1,199 1,549 1,898 2,248 2,598 2,948 3,297 3,647

Product Line Effort 0 782 1,052 1,322 1,592 1,862 2,131 2,401 2,671 2,941 3,211

Product Line Savings against ad-hoc reuse 0 -282 -202 -123 -430 37 117 196 276 356 436

ROI against ad-hoc reuse 0 -1.00 -0.72 -0.43 -0.15 0.13 0.41 0.70 0.98 1.26 1.54

57

# of Products Effort (PM) 0 1 2 3 4 5 6 7 8 9 10

Product Line Savings against no reuse 0 -249 13 276 538 801 1,063 1,326 1,588 1,851 2,114

ROI against no ruse 0 -1.00 0.05 1.11 2.16 3.21 4.27 5.32 6.37 7.43 8.48

Product Line Dev elopment Cost Estimation

-300

200

700

1200

1700

2200

1 2 3 4 5 6 7 8 9 10 11

Product Line Savings aginst ad-hoc reuse

Product Line Savings aginst no reuse

Net development

effort savings

Figure 25. Partial Feature Model for IP business process

As seen Table 16 and Figure 25, there is an effort saving compare with

existing tow types of developments. To analyze effectiveness, compare the effort

of this result and ad-hoc reuse method. Table 17 shows a comparison results.

From the table, we can easily realize that SPL with FMPB is more effective

method to reduce effort.

Table 17. Comparison about effort saving

Effort(PM) Effort Saving compare with No reuse

No Reuse 9,052 -

Ad-hoc Reuse 6,095 2,957

SPL with FMBP 5,101 3,951

58

Ⅵ Conclusions & Further Works

In this thesis, I introduce a method to generate a feature model from a

business process model and a method to analyze business process commonality

and variability. Until now, business administrative software embodies functions

that became oriented in a specification enterprise, it is very hard to apply already

produced software components for similar enterprise business process. Also,

implementation is limited. To solve these issues, I try to synthesize existing

feature modeling methods and business process modeling methods. The

necessary elements to a software product line for business application are

realized during studies in existing business application development methods.

I expect my work is the basis for more wider and practical study on SPL for

a business application domain. I hope that this research will lead to develop

more detailed guidelines for developing a business application’s product line.

However, more comprehensive research is needed for practical use of this

approach in various business application domains and more elaborate guidance

is needed to be effective. My further work is to research for more detailed

domain modeling notations that represent process commonality and variability in

domain process models and devise more elaborated process commonality and

variability analysis methods. Second is an Engineering framework to show the

relationships of these methods on domain engineering material and application

engineering, and the principles of using this method, such as the abstract level of

each model, in a domain model. Third is a language to describe constraints (i.e.

dependency, traceability) of each model. Last is a judgment framework to

estimate process similarities.

59

국문요약 석사학위논문

비즈니스 어플리케이션을 위한 비즈니스 프로세스로부터

휘처를 생성하는 방법

공학부 배종수

경쟁이 심화되는 시장 환경은 기업의 활동을 지원할 수 있는 고 품질의

유연하고, 적응성이 높은 소프트웨어를 요구하고 있다. 비즈니스 활동을 이

해하는 것은 이러한 기업 업무용 소프트웨어를 개발하는 첫 단계로써, 많은

개발 방법론이 기업들(예, 은행, 정부기관, 일반적인 서비스 기업등)의 전반적

인 파악하고 개선하기 위해서 업무 프로세스 모델링을 채택하고 있다. 대표

적으로 RUP, PPC 등과 같은 개발 방법론에서는 업무 활동을 모델링 할 것을

제시하고 있다. 그렇지만, 이러한 방법론은 주로 단일 시스템 개발에 초점을

두고 있다. 다른 방법중의 하나로 비즈니스 프로세스 모델 (BPM)의 경우 어

떻게 업무 활동과 시스템 모델을 연결할 것인 가에 중점을 두고 있다.

반면에 소프트웨어 제품계열(SPL)은 시스템 패밀리의 개발을 통해 소프

트웨어의 재사용을 강조하고 있다. 많은 연구자들이 재사용이 소프트웨어 품

질과 생산성을 높이는 해결책이라고 말하고 있다. 일부 소프트웨어 제품계열

방법에서, 예를 들어 PLUS, 업무 활동을 모델링하는 시도를 하였다. 그렇지

만 PLUS는 비즈니스 프로세스의 가변성을 표현 방법을 제시하지 못했고, 최

종사용자 관점의 업무 활동과 소프트웨어간의 적절한 연결을 제공하지 못하

고 있다. 일부 연구자의 경우 BPMN 표기법을 확장해서 업무 프로세스의 가

변성을 표현하려는 시도가 있었다. 그렇지만, 이방법에서는 다른 도메인 모

60

델과의 관계를 보여주지 못하는 단점이 있다.

비즈니스 프로세스는 기업별로 상이하지만, 동일한 업무 영역의 기업에

서는 동일한 비즈니스 프로세스가 존재하고 있다. 그렇기 때문에, 동일한 비

즈니스 프로세스의 재사용이 가능하게 할 수 있다. 본 석사 논문의 주요 목

적인 FMBP(비즈니스 어플리케이션을 위한 비즈니스 프로세스로부터 휘처를

생성하는 방법)라고 불리는 업무용 어플리케이션을 위한 소프트웨어 제품 계

열의 도메인 분석 활동을 수립하는 것이다. 이 방법은 비즈니스 프로세스의

공통성과 가변성을 분석함으로써 기존의 도메인 분석 방법에 도메인 프로세

스 분석 방법을 채용하는 것이다. 그렇게 함으로써 비즈니스 프로세스 모델

로부터 도메인 프로세스 모델로의 전환을 보여주고, 도메인 프로세스 모델로

부터 휘처 모델을 생성하는 방법을 보여 주고 있다.

61

References

[1] James M. Neighbors. Software Construction Using Components. PhD thesis,

University of California, Irvine, Department of Information and Computer Science,

1980.

[2] Abbott R. Program design by informal English descriptions. Communications of

the ACM 1983; 26(11).

[3] Beck K, Cunningham W. A laboratory for teaching object oriented thinking, ACM

SIGPLAN Notices, v.24 n.10, p.1-6, Oct. 1989

[4] T. Davenport, J. Short. The New Industrial Engineering: In-formation Technology

and Business Process Redesign. Sloan Management Review, 1990.

[5] K.C. Kang, Cohen SG, Hess JA, Novak WE, Peterson AS. Feature-oriented

domain analysis (FODA) feasibility study. Technical Report CMU/SEI-90-TR-21,

Pittsburgh, PA, 1990.

[6] Wirfs-Brock R, Wilkerson B, Wiener L. Designing Object-Oriented Software.

Prentice-Hall: Englewood Cliffs, New Jersey, 1990

[7] Jacobson I, Christerson M, Jonsson P, Overgaard G. Object-Oriented Software

Engineering. Addison-Wesley: Workingham, England, 1992.

[8] Gomaa H. Software Design Methods for Concurrent and Real-Time Systems.

Addison-Wesley: Reading, Massachusetts, 1993.

[9] H. Mili, F. Mili, and A. Mili, “Reusing Software: Issues and Re-search Directions”,

IEEE Transactions on Software Engineering, June 1995, 21(6):528-562.

[10] Workflow Management Coalition. The Workflow Reference Model, 1995,

www.wfmc.org/

[11] Hammer, M.: Beyond Reengineering – How the process-centered organization is

changing our work and our lives. Harper Collins Publishers. 1996.

[12] Philippe Kruchten, Architectural Blueprints. The "4+1" View Model of Software

62

Architecture, IEEE Software, 1995.

[13] Simons, M. et al, Software technology for Adaptable Reliable Systems(STARTS)

Organization Domain Modeling(ODM) Guidebook Version 2.0, STARS-VC-

A025/001/00, Manassas, VA, Lockheed Martin Tactical Defense System(1996)

[14] K.C. Kang, Kim S, Lee J, Kim K, Kim GJ, Shin E.] FORM: a feature-oriented

reuse method with domain-specific reference architectures. Annals of Software

Engineering 1998; 5:143–168.

[15] Martin L. Griss, John Favaro, Massimo d’Alessandro. Integrating Feature

Modeling with the RSEB, Proceedings of Fifth International Conference on

Software Reuse, Victoria, B.C., 1998

[16] P. Clements, L.M. Northrop, et al. A Framework for Software Product Line

Practice, Version 2.0, Report from the Product Line System Program, Software

Engineering Institute, Pittsburgh, PA, July 1999.

[17] David M. Weiss and Chi Tau Robert Lai. Software Product-Line Engineering: A

Family-Based Software Development Process. Addison-Wesley, 1999.

[18] Eriksson H-E., Penker M., Business Modeling with UML: Business Patterns at

Work, Addison Wesley, 1999

[19] Krzysztof Czarnecki and UlrichW. Eisenecker. Generative Programming: Methods,

Tools, and Applications. Addison-Wesley, 2000.

[20] T. Vehkomaki and K. Kansala, "A Comparison of Software Product Family

Process Frameworks", International Workshop on Software Architectures for

Product Families 3, 2000.

[21] Gary Chastek, Patrick Donohoe, Kyo Chul Kang, Steffen Thiel. Product Line

Analysis- A Practical Introduction, CMU/SEI-2001-TR-001.

[22] Clements, P. & Northrop, L. Software Product Lines: Patterns and Practice.

Reading, MA: Addison Wesley.

[23] Maarit Harsu. A survey on domain engineering, Report 31, Institute of Software

63

Systems, Tampere University of. Technology, December 2002, 26 pp. Iglesias, C.

et al.

[24] Kyo C. Kang and Jaejoon Lee, Patrick Donohoe, Feature-Oriented Product Line

Engineering. IEEE Software, Vol. 19, No. 4, Jul./Aug. 2002, pp. 58-65.

[25] Kwanwoo Lee, Kyo C. Kang, and Jaejoon Lee. Concepts and Guide lines of

Feature Modeling for Product Line Software Engineering, 2002.

[26] A Study on the Audit Guide for Component, 2003.11. http://www.nca.or.kr.

[27] Philippe Kruchten. The Rational Unified Process 3rd Edition: An Introduction.

Reading, MA. Addison-Wesley Longman. 2004

[28] Babar, M.A.; Zhu, L.; Jeffery, R. A framework for classifying and comparing

software architecture evaluation methods, Software Engineering Conference, 2004.

Proceedings. 2004.

[29] Boehm, B., Brown, A.W., Madachy, R., Yang, Y. (2004) “A Software Product Line

Life Cycle Cost Estimation Model”, International Symposium on Empirical

Software Engineering (ISESE’04)

[30] Gomaa H, Designing software product lines with UML : from use cases to pattern-

based software architectures , Boston : Addison-Wesley ; 2004.

[31] Mari Matinlassi. Comparison of Software Product Line Architecture Design

Methods:COPA, FAST, FORM, KobrA and QADA. 26th International Conference

on Software Engineering (ICSE'04). pp. 127-136

[32] Business Process Modeling Notation (BPMN), Version 1.0 - May 3, 2004.

http://www.bpmi.org/

[33] THE BUSINESS PROCESS MODEL, Sparx system UML Tutorial. http://

www.sparxsystems.com.au

[34] Klaus Pohl, Günter Böckle, Frank J. van der Linden, Software Product Line

Engineering: Foundations, Principles and Techniques; 1st ed, Springer, September

19, 2005

64

[35] Artur Caetano, Marielba Zacarias, António Rito Silva, José Tribolet. A Role-Based

Framework for Business Process Modeling, Proceedings of the 38th Hawaii

International Conference on System Sciences - 2005.

[36] Magnus Eriksson, Jürgen Börstler, Kjell Borg. The PLUSS Approach - Domain

Modeling with Features, Use case, use case realizations. Software Product Lines,

9th International Conference, SPLC 2005, Rennes, France, September 26-29, 2005,

Proceedings. Lecture Notes in Computer Science 3714 Springer 2005

[37] Rieko Yamamoto, Kouji Yamamoto, Kyoko Ohashi and Junji Inomata.

Development of a Business Process Modeling Methodology and a Tool for

Sharing Business Processes. Proceedings of the 12th Asia-Pacific Software

Engineering Conference (APSEC’05), December, 2005. IEEE.

[38] Wei Wang, Hongwei Ding, Jin Dong, Changrui Ren. A Comparison of Business

Process Modeling Methods. Service Operations and Logistics, and Informatics,

2006 IEEE International Conference on 2006 Page(s):1136 – 1141

[39] F.P. Oliveira, T.C. Becker, L.B. Using the FOMDA Approach to Support Object-

Oriented Real-Time system development

[40] O. Djebbi, and C. Salinesi. "Criteria for Comparing Requirements Variability

Modeling Notations for Product Lines", Comparative Evaluation in Requirements

Engineering, in RE/'06 (CERE), Minneapolis, USA, pp. 20 - 35, September 2006.

[41] Young-Gab Kim; Jin-Woo Kim; Sung-Ook Shin; Doo-Kwon Baik. Managing

Variability for Software Product-Line. Software Engineering Research,

Management and Applications, 2006. Fourth International Conference on 09-11

Aug. 2006 Page(s):74 – 81

[42] A. Schnieders, F. Puhlmann. Variability Mechanisms in E-Business Process

Families. In W. Abramowicz, H. Mayr (Eds.): 9th Inter-national Conference on

Business Information Systems (BIS 2006), volume P-85.

Contoh Template AE

Documents

Transcript of Contoh Template AE