SPECIFICATION OF E-COMMERCE SYSTEMS USING THE

UMM MODELLING METHODOLOGY

Ioannis Ignatiadis, Konstantinos Tarabanis

Centre for Research and Technology Hellas-Informatics and Telematics Institute (CERTH-ITI)

1st Km Thermi-Panorama Road, Thermi-Thessaloniki, GR-57001 Greece

Keywords: e–commerce, information systems analysis, modelling methodology, UMM

Abstract: UN/CEFACT (United Nations / Centre for Trade Fac

ilitation and Electronic Business) Modelling

Methodology – in short UMM – has been developed by the TMWG (Technical Modelling Working Group)

within UN/CEFACT, in order to support the development of e-business applications in a technology-

neutral, implementation-independent manner. The purpose of this paper is to provide the results from an EU

co-funded project, entitled “LAURA”, where UMM was used for the analysis and design of the e-commerce

system to be developed. In particular, an analysis of the strengths and weaknesses of UMM will be carried

out, as those were evidenced from a practical perspective in the “LAURA” project.

1 INTRODUCTION

One methodology for the specification of e-

commerce systems that has appeared during the last

couple of years is UN/CEFACT’s Modelling

Methodology (UMM). The purpose of this paper is

to examine the UMM methodology, and point out its

strengths and weaknesses. The framework used for

this analysis is the IST project “LAURA”, where the

UMM methodology was used.

In the sections that follow, section 2 presents a

gh-level description of the UMM methodology.

Section 3 presents a description of the LAURA

project. Section 4 presents the strengths and

weaknesses of the UMM methodology, and section

5 concludes with suggestions for further research.

2 DESCRIPTION OF UMM

According to the UMM specification (UN/CEFACT,

2001), the UMM business process and information

modelling technique is based on the Unified

Modelling Language (UML) from the Open

Management Group. The UMM methodology is

based on configuring the Unified Process

methodology developed by the Rational Corporation

meet UN/CEFACT needs for modelling business

processes in addition to objects. This requires

extensions of the UML metamodel through business

dom

ain specific stereotyping to support a complete

business process and information definition,

resulting objects and interface-specific object

behaviour descriptions.

A set of specifications for e-commerce systems

at utilise the UMM methodology is ebXML

(Electronic Business XML). According to ebXML’s

Technical Architecture Specification document

(ebXML & OASIS, 2001), the UMM Meta Model is

a mechanism that allows Trading Partners to capture

the details for a specific business scenario using a

consistent Modelling methodology.

The UMM methodology uses a series of

worksh

eets to capture the details of the modelling

effort. There are various levels of abstraction in each

step of the modelling effort, and each step carries its

own set of worksheets. In addition, each worksheet

may include one or more Unified Modelling

Language (UML) diagrams, to make clearer the

purpose and scope of the relevant worksheet.

According to ebXML’s “Business Process

Analysis Worksheets

and Guidelines” document

(ebXML & OASIS, 2001), the worksheets used in

UMM are as follows:

386

Ignatiadis I. and Tarabanis K. (2005).

SPECIFICATION OF E-COMMERCE SYSTEMS USING THE UMM MODELLING METHODOLOGY.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 386-389

DOI: 10.5220/0002513003860389

 SciTePress

EC Kernel

Business

Organisations

EC Shell

SME

Support

Centers

SME

Local – Regional - National

IT Provider

EC Kernel

Business

Organisations

EC Shell

SME

Support

Centers

SME

Local – Regional - National

IT Provider

Figure 1: Regional entities in an e-commerce kernel and e-commerce shell

• Business Reference Model.

• Business Process Identification and Discovery

• Business Process Elaboration.

• Business Collaboration Definition.

• Business Transaction Definition.

• Business Information Definition.

As UMM’s technical specification

(UN/CEFACT, 2001) mentions, many projects have

contributed to the specification of the UMM:

• Open-edi reference model (ISO/IEC 14662

1997).

• Unified Modelling Language (OMG, 2003).

• Unified Process (Rational Corporation 1998,

Ward & Kroll 1999, West 2002).

• Business collaboration framework

(UN/CEFACT, 2003).

3 DESCRIPTION OF LAURA

PROJECT

The authors of this paper were engaged in a project

co-funded by the European Commission, entitled

“LAURA – Adaptive Zones for Interregional

Electronic Commerce based on the concepts of

Request-Based Virtual Organizations and sector-

specific Service Level Agreements” (LAURA

Project, 2003). This project belongs to the

Information Society Technologies (IST) programme

that is part of the Fifth Framework Programme for

Research, Technological Development and

Demonstration Activities.

The e-commerce system resulting from the

LAURA project is initially employed in four Less

Favoured Regions of Europe: Messinia and Epirus

(Greece), Saxony-Anhalt (Germany) and South-

Central region (Bulgaria).

At the regional level the e-commerce zones

include various types of actors that are classified

upon the notion of State-of-the-Art “Electronic

Commerce (EC) Kernels” and “Electronic

Commerce (EC) Shells” (see figure above). Actors

may be persons or organizational units from the

private or public sector.

The EC Shells include the broad population of

small and medium enterprises (SMEs) existing in the

geographical area (rural or urban) of each

participating region. E-Commerce Kernels have a

rather supportive role aiming at facilitating the SME

actors to conduct e-business successfully. E-

commerce Kernels typically include Business

Organizations, Support Centres set up in each

region, and associated IT providers for the provision

of the hardware and software infrastructure

necessary to run the LAURA system.

A more complete description of the LAURA

project can be found in its official website,

www.lauraproject.net .

4 UMM STRENGTHS AND

WEAKNESSES

4.1 UMM Strengths

One major strength of UMM is the fact that it allows

for the bottom-up or top-down analysis and design

of the e-commerce system to be developed, or

indeed a combination of both approaches. As an

SPECIFICATION OF E-COMMERCE SYSTEMS USING THE UMM MODELLING METHODOLOGY

387

example, a person who is trying to model a system

that is based on existing document standards (e.g.

EDIFACT), might want to start at the lower levels

and work his or her way up. On the other hand, a

person trying to model an entire industry segment

would start at the highest level and work his or her

way downwards.

UMM

Another major strength of UMM is the definition

of business documents to be used and exchanged

between trading partners. This allows to use existing

standards (for example UN/EDIFACT, xCBL, UBL,

RosettaNet, OBI, ANSI X12 850, etc). This use of

standards promotes standardisation in the e-

commerce arena, but at the same time UMM allows

for the adaptability of these standards to the

particular e-commerce application being modelled.

Another advantage of using UMM is the ability

to choose the level of the modelling details

according to the audience and use intended. For an

overview of the system to be built it suffices to show

the first couple of levels of the modelling effort, for

example the Business Reference Model, Business

Areas and Process Areas. For a more refined view of

the system the use case views and collaboration

patterns may be shown. If the modelling effort is

targeted to the developers of the system, the lower

levels of the UMM have to be shown, for example

the definition of the transactions in the system, as

well as the definition of the business documents to

be used by the trading partners.

UMM is also fully compliant with the ebXML

specifications, and its constructs (UMM worksheets)

can be stored in an ebXML-compliant registry. The

output from the UMM analysis can therefore be a

direct input to the specification of an ebXML

Business Process Specification Schema (BPSS), that

includes the transactions carried out between trading

partners, and the choreography (sequence of steps

and order) necessary in order to carry out those

transactions. UMM is in fact the chosen modelling

methodology by the ebXML team.

In addition, as UMM is fully compliant with the

ebXML specifications, this means that the modelling

of certain business processes can be reused. This

adds to the ease of use of UMM, as well as to the

standardisation efforts with respect to the e-

commerce community.

Finally, as the table below shows, UMM can be

considered as a subset of the Rational Unified

Process (RUP). This means that UMM is compatible

with the RUP, which is a proven methodology for

the whole software life-cycle. UMM however, can

be more compact than RUP, which allows for the

ease of its use.

Table 1: Phases and Workflows used in UMM (Source:

UMM Specification)

Rational Unified Process Phases

Workflows Incepti

Elabora

tion

Constr

uction

Tran

sition

Business Modelling

Requirements

Analysis

Design

Implementation

Test

Deployment

4.2 UMM Weaknesses

Having described the major strengths of UMM, as

those were evidenced in the LAURA project, we

will now describe what we consider to be some of

the weaknesses of this modelling methodology.

As it was mentioned, UMM fits very well with

the ebXML technical specifications. As ebXML’s

Technical Architecture document (ebXML &

OASIS, 2001) mentions, Business Process and

Information Modelling is not mandatory. However,

if implementers and users select to model Business

Processes and Information, then they must use the

UN/CEFACT Modelling Methodology (UMM) that

utilizes UML.

Although UMM fits very well within the ebXML

technical specifications, there is no evidence to

suggest that it does so within other, non-ebXML

environments. As UMM contains a mixture of

analysis and design considerations, various levels of

abstraction can be used to describe the e-commerce

platform to be built. At the higher levels of

modelling, the analysis part contains such

components as the business and process levels of the

system, as well as the individual processes to be

carried out. On the other hand, as one gets closer to

the lower levels of the UMM methodology

(collaboration / transaction patterns, business

document structures), which are more design-

related, the independence from the underlying

technology starts to fade out. As an example, the

UMM methodology defines transactions according

to pre-specified transaction patterns, for example

Query / Response, Notification, Request / Confirm,

etc. Each of those patterns has a set of semantic

values associated with it, for example if the

transaction is legally binding, if authorization for

carrying out the transaction is required, if non-

repudiation of receipt of messages is compulsory,

the time allowed to perform the transaction, etc.

There are defaults for each of the semantic values of

the transaction patterns, which can be overwritten by

the designer of the system. However, the logic of

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

388

using these semantic values is not built in many

systems other than ebXML, and considerable work

may be needed to make the system conform to this

logic.

Another drawback of the UMM methodology is

that it doesn’t encourage definition of transactions

with the system, but only those between two trading

partners. The worksheet templates used by UMM

specify the partner types and authorized roles of the

trading partners carrying out the transaction, and the

documents that they exchange between them as part

of the transaction. However, there is no mention

about transactions carried out between a trading

partner (a human) and the e-commerce system (a

machine). For a complete definition of the system

those types of transactions also need to be defined.

As another consideration, the compactness of

UMM means that although it is relatively easy to

define e-commerce projects in this methodology,

crucial information may be lost during the analysis

and design stage. As an example, UMM does not

allow for the definition of the user interface that the

user is exposed to. In this case the designer of the

system must resort to other methodologies, e.g. the

Rational Unified Process to fill in the missing parts.

Another drawback of the UMM methodology is

that at the time of writing of this paper, and to the

writers’ best knowledge, there is no design tool to

ease the task of using the UMM methodology. There

is some work by the TMWG group responsible for

UMM regarding this matter, in particular a proof-of-

concept analysis that certified the need for such a

tool. However, up to this point there does not exist a

tool that can be useful in the designer’s hands when

designing an e-commerce system using UMM.

5 CONCLUSIONS AND FUTURE

RESEARCH

UMM was found to be a compact and quite robust

methodology when specifying e-commerce systems

to be developed. There were also several drawbacks

which were described, and suggestions for

improvement of this methodology were mentioned.

As a suggestion for further research, one needs

to examine what changes are required to UMM to

include modelling of non-human transactions, i.e.

interactions with the system. This may include

extensions of the number of transaction patterns

currently defined by UMM, as well as inclusion of

additional fields in the relevant UMM worksheets to

reflect interaction with the system.

REFERENCES

Bosak, J., 2002. UBL: The Universal Business Language,

Web Services Edge East. New York City.

Clark, C.J., 2000. The UN/CEFACT Modelling

Methodology: An overview.

http://www.unece.org/cefact/docum/download/00bp03

0.doc

ebXML & OASIS, 2001. Business Process Analysis

Worksheets and Guidelines.

http://www.ebxml.org/specs/bpWS.pdf

ebXML & OASIS, 2001. Technical Architecture

Specification.

http://www.ebxml.org/specs/ebTA.pdf

ISO/IEC 14662, 1997. Information Technologies – Open-

Edi Reference Model.

http://www.disa.org/international/is14662.pdf

LAURA Project, 2003. LAURA project on the net. IST

Project 2001-33251. http://

www.lauraproject.net

OMG, 2003. Unified Modelling Language Specification,

v1.5.

http://www.omg.org/cgi-bin/doc?formal/03-03-

Rational Corporation, 1998. Rational Unified Process –

Best Practices for Software Development Teams

(Rational Software White Paper).

http://www.rational.com/media/whitepapers/rup_bestp

ractices.pdf

UN/CEFACT, 2001. UMM (N090) – Draft, Ref: CEFACT

/ TMWG / N090R10.

http://www.gefeg.com/tmwg/n090r10.htm

UN/CEFACT, 2003. The Unofficial Home of

UN/CEFACT’s Business Collaboration Framework.

http://www.unbcf.org

Ward Stan and Kroll Per, 1999. Building Web Solutions

with the Rational Unified Process: Unifying the

Creative Design Process and the Software

Engineering Process. A Rational Software & Context

Integration White Paper.

http://www.rational.com/media/whitepapers/76.pdf

West David, 2002. Planning a Project with the Rational

Unified Process (Rational Software White Paper).

http://www.rational.com/media/whitepapers/tp151.pdf

SPECIFICATION OF E-COMMERCE SYSTEMS USING THE UMM MODELLING METHODOLOGY

389