SC32/WG2-SAF025

ISO/IEC JTC 1/SC32/ WG2 SAF025

Date: 2000/01/27

Framework for Classification and Identification of Enterprise Objects

Working Draft

Document type:

Document subtype:

Document stage:

Document language: E

Table of Contents

1 Foreword 1

2 Introduction 2

3 Scope 5

4 Conformance 7

5 Normative reference(s) 8

6 Definition(s) 10

<The precise definition of following terminologies should be provided.> 10

administered component: 10

atomic object 10

attribute: 10

attribute value: 10

basic attribute: 10

concept: 10

conceptual data model: 10

data: 10

data element concept: 10

data element: A unit of data that in a certain context is considered indivisible. 10

data element dictionary: 10

data model: 10

domain specific object pattern: 10

enterprise object 10

domain specific entity object 10

domain specific plug-in object 10

domain process object 10

function object pattern 10

unction object framework 10

metadata registry. 10

Intity: 10

Identifier: 10

metadata: 10

object class: 10

permissible value: 10

property: 10

registration authority: 10

relationship: 11

schema: 11

shareable data: 11

value domain: 11

7 Classification 12

8 Identification 14

Annex A (Informative or TR) Concept of the Atomic Objects 16

Definition of the Atomic Objects 16

Use of Atomic Object 17

Advantages of atomic object standardization 19

Annex B (Informative or TR) Representation of Business Function Object Patterns 34

Introduction 34

Background Facts 34

Meta concept and pattern 35

BFOP pattern principle 35

Concept and Mechanism of Patterns 35

UML Profile for BFOP 35

BFOP Constraints to collaboration 35

BFOP Collaboration and BFOP Package 35

BFOP Meta Model 35

The motivation behind the constraints 35

Basic Patterns 35

Unit Patterns 35

Optional Patterns 35

Pattern Definition (excerpt of examples) 35

Basic Patterns 35

Master & Detail 35

DAG (Directed Acyclic Graph) 35

Header & Detail 35

Settlement for Paying 35

Overall Package Structure 35

Sample Object Model for BFOP 35

Annex C (informative) An Example of Modeling A Conceptual Bicycle 35

References 35

1  Foreword

ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liasion with ISO and IEC, also take part in the work.

Draft International Standards adopted by the technical committees are circulated to the member bodies for voting Publication as an International Standard requires approval by at least 75% of the member bodies casting a vote.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part3.

2  Introduction

This NWI proposal is intending to initiate a new standardization activity which focuses on the common view to the metadata for categorizing and structuring enterprise business objects, extending ISO/IEC 11179 Specifications.

The enterprise objects which consist of both information and process elements, should be used, not only in the development efforts of a particular organization, but also, in the interchanging and sharing them among different organizations by the means such as the Electronic Commerce (EC), Electronic Data Interchange (EDI).

The major issues of the standardization are as follows:

a)  reference model of enterprise object architecture

b)  rules and guidelines for categorizing atomic objects

c)  rules and guidelines for categorizing business function objects

d)  rules and guidelines for categorizing business function object patterns

e)  rules and guidelines for the formulation of basic business function object patterns

f)  naming and identifying principles for enterprise objects.

g)  rules and guidelines for registering enterprise objects.

PURPOSE AND JUSTIFICATION

This proposal intends to establish a common reference model of the enterprise object architecture relying upon the object concept which enables consolidation of both data concept and software concept.

Major objectives of the reference model of the architecture:

a) to support establishment of common technical infrastructure for component based system.

b) to support promotion of the reusing and the distribution of enterprise business object component.

c)to support promotion of the standardization of undefinable atomic objects.

d)to support promotion of the standardization of basic enterprise business process model and business object pattern and framework

To cope with current trends on IT area, there must be a common infrastructure which enables effective and consistent collaborations among different organizations through the internet.

In the software development domain, the component based development manner became popular to built enterprise information systems with the standard fashion by standard components, to cope with effective collaboration with others in the changeable business environment.

Information system in a particular organization, should be developed with standard components which were derived by materializing predefined object patterns or frameworks, with the component assembling manner or purchase & plug-in manner.

In realizing those manner, there must be common platforms, standard component interface specifications and exchanging protocols. However, there must be also, a common architecture which enables all of system integrators, software venders, information contents venders, and end users, locate their products in the term of the business semantics.

In the EC area, consistent business collaboration among BtoB, BtoC,CtoC, have to be proceeded with common business semantics which are necessary to create business information and related software processes. There must be a common schema which enables consistent implementation of software processes triggered by the standard messages, specified by such as EDFACT. So far, no standard were specified for the business software process.

However, before specifying those standard, there must be common view for enterprise object architecture, which consist of both data aspect and process aspect of the enterprise and their collaborations.

The benefits of the reference model of the architecture :

The architecture could be useful in both information system constructions and sharing & exchanging software components. However, following aspect of the architecture should be reinforced.

l  Provide common bases for exchanging information contents among different domains and different organizations across countries.

l  Provide common bases for effective evaluation mechanism of proprietary components in both software and information content, by asking for each components to declare their ingredients with specifying standard elements.

l  Provide common bases for evaluating business performance of the enterprise.

l  Provide common bases for effective investigation of business modeling and its change which might cause information system changes.

Those benefits are mainly brought by providing common bases for both business peoples and IT peoples.

3  Scope

This proposal is an extension to the ISO/IEC 11179 Specifications and intend to standardize metadata for categorizing and structuring enterprise business objects. The scope of the proposal is focused on the standard common architecture which covers enterprise object for Electronic Commerce (EC), Electronic Data Interchange (EDI) and various business information systems in enterprises.

In this proposed standard, elements are classified into several conceptual layers: atomic object, enterprise function object, enterprise function object pattern and framework.

This proposal intend to specify a reference model of enterprise business object component architecture based on those conceptual layers, categorized elements and required attributes for registry in order to identify useful and reusable business object components. Actual conformant business object components derived from materializing a pattern or framework may be provided by software venders and built up into a specific system environment by system integrators.

The major issues of the standardization are as follows:

a)  reference model of component based enterprise business object architecture

b)  rules and guidelines for categorizing atomic objects

c)  rules and guidelines for categorizing enterprise business function objects

d)  rules and guidelines for categorizing enterprise business function object patterns

e)  rules and guidelines for the formulation of basic enterprise business function object patterns

f)  naming and identifying principles for elements of enterprise business objects.

g)  rules and guidelines for registering elements of enterprise business objects.

Overall architecture of the Framework of meta model

The meta model as the framework have to be consisted of following contents.

•Meta object for Naming scheme

•Meta object for Terminologies and Taxonomy scheme

•Meta object for Identification scheme of various Business Objects

•Meta object for Modeling Facilities

•Meta object for Modeling Constructs

•Normative Atomic Objects

•Normative Value Domain

•Normative Modeling Patterns as profiles

•Meta object for Registering

4  Conformance

<TBD>

5  Normative reference(s)

The following standards contain provisions which, through reference in the text, constitute provisions for this Part of the International Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Part of the International Standard are encouraged to investigate the possibility of applying the most recent editions of standards indicated below. Members of IEC and ISO maintain registers of currently valid International Standars.

ISO TR 9007:1987 Information processing systems –Concepts and terminology for the conceptual schema and the information

ISO 704:1987, Principles and methods of terminology

ISO 2382-4:1987, Information processing systems –Vocabulary

ISO Standards Handbook 10, Data Processing –Vocabulary, 1982

ISO 1087:1990, Terminology –Vocabulary

ISO 10241:1992, International terminology standards – preparation and layout

ISO/IEC FDIS 11179-1, Information technology –Specification and Standardization of elements Part 1:Framework for the specification and standardization of elements

ISO/IEC FDIS 11179-2, Information technology –Specification and Standardization of elements Part 2: Classification of elements

ISO/IEC 11179-3, Information technology – Specification and standardization of elements Part3: Basic attributes of elements components or Metadata registry structure, administration and content

ISO/IEC 11179-4:1995, Information technology –Specification and Standardization of elements Part4: Rules and guidelines for the formulation of data definitions

ISO/IEC 11179-5:1995, Information technology –Specification and Standardization of elements Part 5: naming and identification principles for elements

ISO/IEC 11179-6:1997, Information technology – Specification and Standardization of elements Part 6: Registration of elements

ISO 11404: 1995, Information technology – Language-independent Datatypes

ISO/IEC FDTR 15452, Information technology – Specification of data value domains

6  Definition(s)

<The precise definition of following terminologies should be provided.>
administered component:
atomic object
attribute:
attribute value:
basic attribute:
concept:
conceptual data model:
data:
data element concept:
data element: A unit of data that in a certain context is considered indivisible.
data element dictionary:
data model:
domain specific object pattern:
enterprise object

domain specific entity object

domain specific plug-in object

domain process object

function object pattern

unction object framework

metadata registry.

Intity:

Identifier:

metadata:

object class:

permissible value:

property:

registration authority:

relationship:

schema:

shareable data:

value domain:

7  Classification

One of the purposes of this NWI is establishing a Common schema for classifying meta object in the common metamodel.

To cope with current requirements in the IT and business trends, meta objects in the common meta model might be classified as followed. The standardization on those classification have to be obtained.


In Fig.2, a framework of the meta model is illustrated. In this framework,, Meta object hierarchy, and meta objects that represent normative modeling facilities and modeling constructs were shown.

8  Identification

It is indispensable to provide a common schema which enable to global identification of various enterprise business objects, to cope with current EC, EDI environments.

The framework should address those requirements preparing a common identification mechanism which consist of ;

l  Naming scheme

l  Terminologies and Taxonomy scheme

l  Encoded value domain for Business scheme

²  Identification of business enterprise scheme

²  Identification of business products scheme

²  etc

Those schema should be established in the meta model, facilitating the atomic object mechanism.

Annex A (Informative or TR) Concept of the Atomic Objects

Definition of the Atomic Objects

A normative set of atomic object should provide the bases for defining more complex objects which represent concepts in a particular domain, in order to establish share-ability of those objects.

The concept of the atomic objects could be defined, in the term of atomicity, as followed.

[1]  Non Decomposable:

An atomic object is an elementary object which can not be decomposable any more. Accordingly, it has no structure in it.

[2] Un-definable(Needless to Define) concept:

The atomicity, also can be defined by it’s nature of commonality against those, who use them. An atomic object can be recognized among those peoples or organizations without providing any definitions on its.

[3] Immutable:

Immutable means “no change” on its contents or values. An atomic object must be immutable, if contents of it have changed it become different object. Although atomic Objects have types (classes) and instances, instances of an atomic object type should not be changed.

[4] Self-contained & Independent object

An atomic object is a independent object which has no relationship with other object. Also, has no lifecycle process (CRUD) activated by events that should be caused on the relationship of more than two objects.

However, an atomic object has own constraints that govern its consistency or completeness in itself.

[5] Classification:

It might be allowed to define categories on a set of atomic objects. So, the specialization might be allowed on them. Although, no aggregation should not allowed on them. It might be allowed to provide couple of attribute to an atomic object, in order to enable to specify constraints using those attributes, instead of using the property concept.

Use of Atomic Object

Atomic objects prepared for providing elementary object to be aggregated into other structured and attributed objects as ingredients. So, atomic objects have to be defined by investigating numerous object instances, distinguishing attributes of those structured and attributed objects from their values.

To use atomic objects effectively, an attribute should be recognized as a Role of an atomic object. The Role is a specific pattern which guides an aggregation manner.

For example, to materialize a typical attribute "Order_Date" of “Order Object “, an atomic object "Calendar Date", could be used to represent a role, such as, “ Order timing”. Constraints that were encapsulated in each atomic object, have to be inherited by Structured objects.