AN OBJECT ORIENTED APPROACH TO BUSINESS MODELING

IN INFORMATION SYSTEMS DEVELOPMENT*

Jonás Arturo Montilva C.

Universidad de Los Andes Facultad de Ingeniería

Escuela de Ingeniería de Sistemas Departamento de Computación

Mérida, Mérida, 5101, Venezuela jonas@ing.ula.ve

ABSTRACT Developing a business information system (BIS) is a very complex process that involves not only the application of

modern information and telecommunication technologies but, most important, a good understanding of its

application domain: the organization. Nowadays, object oriented methods and languages are commonly used in

many BIS development methodologies. However, most of these methods focuses only on the representation of the

objects or entities of the BIS domain and the interaction between the BIS and its domain through use-cases. When

applied to the development of BIS, most of the OO methods ignore other important components of the BIS domain,

such as the organizational culture, the business ends, the business rules and, even, the job structure. Business

modeling can help the BIS analysts and designers to gain a more comprehensive understanding of the problem, the

business needs, and the BIS objectives, which is essential to identify, analyse and specify user´s requirements. We

present in this paper an object-oriented business model that captures the main components of an organizational

system. This model is then used as a framework for describing an object-oriented method for business modeling in

the context of BIS development.

Keywords:

Business Modeling, Information Systems Development, Enterprise Modeling, Business Engineering

1. Introduction Business information systems (or BIS, for brevity) are special kinds of software applications that deal with the

problem of supplying information for decision making purposes in an organization. Management information

systems, on-line transaction processing systems, executive information systems and decision support systems are

typical examples of BIS.

* Proceedings of the III World Multiconference on Systemics, Cybernetics and Informatics - SCI´97. Orlando,

Florida : International Institute of Informatics and Systemics, Orlando, Florida, USA, August, 1999, Volume 2. pp.

358-364.

2

A BIS is part of a wider system, called here the organizational system. An organizational system is a human

activity system that has being designed to perform a set of activities (processes) in order to achieve ends that have

been previously defined [1]. An organizational system is a purposeful system. Its processes are carried out by actors

(people or machines) in order to reach the pre-defined ends. Actors require information, as well as other resources,

for performing processes. The BIS goal is to provide the information that actors need for executing business

processes.

Developing a BIS is a very complex process that involves solving not only technological problems but also

organizational and human problems involved in information systems development [2], [3]. Most of the existing BIS

methodologies focus only on the technological and/or the human problems. Attention to the human problems has

being given by different movements in information systems development, including participative system design,

usability design, use-centred approach [4] and use-case driven approach [5].

A well-known human problem is concerned with the definition and specification of well defined, complete and

unambiguous user's requirements. This problem has also been addressed by the object-oriented movement to BIS

development [6], [7], [8], [9], [10] and [11]. Most of these methods, however, focus mainly on the application and

ignore the most essential elements of the organizational system in which the BIS will operate. All of them

concentrate only on one or more of the following components of an organizational system: the business entities, the

business processes and/or the business events. Other important aspects of an organizational system such as the

organizational culture, its business ends, its job structure and its business rules are not taken into consideration.

A good understanding of the organizational system is a success factor for the process of defining the

requirements to be satisfied by a BIS [2], [3] and [13]. By modeling the organizational system, before modeling the

application itself, we can define more stable user's requirements. A business model of the organizational system can

help BIS analysts and designers to gain a more comprehensive understanding of the user´s requirements. On the

other hand, users can go deeper into their understanding of their business and can elicitate more easily their

requirements.

Business modeling is a central process to many different areas, including Business Process Reengineering,

Organizational Development, Enterprise Modeling & Integration, and Information System Development. In this

paper, we introduce a generic object-oriented business model that captures the main components of an organizational

system. This model was used to design an object-oriented method for building specific business models of

organizational systems. The Unified Modeling Language – UML [14], [13] – is partly used in this method for

describing the business model and for representing the entities, processes and events of an organizational system

through the application of the method.

In the next section, we present a conceptual and generic business model that shows the main relationships

between the different components of any organizational system: ends, processes, actors, entities, rules, technologies,

events, and job structure. Section 3 describes the relationship between a BIS and an organizational system. Section 4

describes the method for building business models of organizational system. The concluding remarks are finally

given in section 5

2. An object-oriented business model of the organizational systems

3

An information system is an open system. It is embedded into a wider system usually called environment or

application domain. The main objective of the information system is to provide services to its domain. Examples of

these services are supplying information, controlling a process or device and managing data.

BIS are the most common kinds of information systems. They provide information to their application domains,

which are referred here to as organizational systems. An organizational system is also part of a major system: an

organization. An organization may be seen as a human activity system whose main activities, also called functions,

are designed to reach a set of pre-defined ends. A production organization, for example, is structured into functions

such as engineering, production, marketing, personnel, finance, and accounting. An organizational system is an

activity system associated with one of these functions. An organization can be conceived as a set of organizational

systems, one or more for each of its functions.

An organizational system is comprised by an organized set of activities or processes that are designed and

performed by a group of actors with the purpose of achieving a set of pre-defined ends. Actors are organized into a

job structure (e.g. departments, divisions or business units) which defines the responsibilities for performing the

processes. Each processes requires, uses or involves a set of entities (e.g., personnel, clients, raw materials, products

and clients) and one or more technologies (e.g., methods, techniques or devices). A process is triggered by an event

(e.g., the arrival of raw material or a service order) which may modify the state of the entities involved in the

process. A process is regulated by business rules (e.g. laws, policies, norms and procedures). These components of

an organizational system and their interrelationships are partly shown in the UML class diagram of Figure 1.

Business End

Event Business RuleEntity

Technology Process Actor

definesachi

eves

de

term

ines

applies performs

Job Structuremodifies

is-mem

ber-of

regulates

inv

olves

parti

cipat

es

triggers

**

**

*

*

*

1

*

**

Figure 1. A generic business model

2.1 Ends: missions, goals and objectives

Ends are the reason of being of an organizational system. They are established by actors (e.g., top managers) to

comply with organizational interests and needs demanded by the environment. Ends may be classified according to

their scope into: mission, goals, and objectives. A mission is a broad purpose that is expected to be reached in a long

term. A goal is a state or condition that contributes to the fulfillment of the mission. Objectives are derived from

goals and are short-term, specific and measurable [16]. To reach its ends an organizational system must design,

organize, and perform a set of activities called business processes.

4

2.2 Business processes

A business process is a set of structured and hierarchical activities designed for reaching organizational ends.

Processes may be of many different types: decision making, administrative, production, services, communication,

data management and so on. Figure 2 shows different types of business processes that are usually found in

organizational systems.

Business Process

CommunicationProcess

Data AcquisitionProcess

Data ManagementProcess

AdministrativeProcess

ServiceProcess

Decision MakingProcess

ProductionProcess ...

DB ManagementProcess

Business ControlProcess

OrganizationDesign Process Planning Process ... Information Prod.

Process

...

Figure 2. A generalization hierarchy of typical business processes

The business processes of an organizational system may be organized into a hierarchy of activities made of

several levels of abstractions. We identify three levels: functions, processes and tasks, as exemplified by Figure 3.

The upper level corresponds to the main functions of the organizational system. Each of these functions is divided

into two or more concrete processes. Each of these processes is then divided into detailed activities called tasks.

Each level could also be divided into sublevels. The depth of the hierarchy depends on the complexity of the system.

ManagingAccidents

DeterminingCombat Resources

Selecting ResponseActivities

AccidentResponse

EmergencyPlanning

ImpactEvaluation

Functions

Processes

Tasks...

AccidentEvaluation

Risk Analysis andPlanning

Figure 3. A hierarchical decomposition of a business process

The distinction between functions, processes and tasks is based on three factors: the scope of the activity, the

effort required to be performed and the time needed to be completed. A function performs a complete job that

contributes to reach one or more ends of the organizational system. At the next level, each function is divided into

smaller units of job called processes that are usually performed by a small group of actors. Each process is then

divided into a set of tasks (the leaves of the hierarchy) which are the lowest units of job that are normally performed

by an actor in a relatively short unit of time.

2.3 Actors and job structure

5

Actors carry out business processes. An actor may be either a person or a machine capable of performing defined

actions. Actors may be external or internal to the scope of the organizational system. External actors are part of the

organizational system environment. They interact with the organizational system to fulfill their needs. Clients,

suppliers, sponsors, and actors belonging to other organizational systems are examples of external actors. Internal

actors, on the other hand, are central to the organizational system. They are responsible for performing the business

processes (i.e., functions, processes and tasks) of the organizational system.

Actors are organized according to the task they perform into a job structure. This structure defines the jobs to be

executed by the actors and the authority line that governs the inter-personal relationships.

The grouping jobs into organizational units is a decision making process called organizational design or

departmentalization. A organizational system may be structured into departments or organizational units according

to its functions, its projects, its products, its customers or a combination of them, and so on (see Figure 4).

Job Structure

Division

Product-basedStructure

TerritorialStructure

FunctionalStructure

OrganizationalUnit

MatrixStructure

1+

Department SupervisionUnit...

...

Figure 4. Types and components of a Job Structure

2.4 Technologies

Business processes use technologies to perform their activities more efficiently and effectively. For instance,

information technologies, such as object-oriented programming and databases are used to improve the performance

of data management processes. Similarly, a production process that transform raw materials into finished products

may apply many different technologies including chemical processes and electromechanical equipment. Figure 5

illustrates some of the most common technologies found in production organizations.

InformationTechnology

Technology

CommunicationTechnology

ProductionTechnology

TransportationTechnology

...

Figure 5. Types of technologies

Technologies are the result of applying the scientific knowledge to the solution of real-world problems. Methods,

techniques, models, devices, tools, machines, software and hardware are some of the most common types of

technologies.

2.5 Business rules

6

The nature and structure of business processes are determined not only by the technologies they use, but also by the

business rules they must comply. Any organizational system must adhere, for instance, to all government regulations

and laws related to its ends. Similarly, an organizational system must satisfy the policies, plans and standards

established by their managers.

Processes are therefore regulated or controlled by a set of business rules. These rules may be of different types:

policies, standards, norms, procedures, government regulations and laws (see Figure 6).

Knowing the business rules is crucial for organizational design and business process reengineering. A critical

success factor for implementing a new business process model in an organization is that this model must comply or

follow the established business rules. Therefore, the business rules of an organizational system must be tightly

linked or embedded into its business processes.

Figure 6. Types of business rules

2.6 Business entities

An entity is anything that can be known through its properties by a subject or individual. Figure 7 presents a

classification of entities (objects) from an ontological point of view [17], [18]. A real or concrete entity is an object

that can be perceived by the subject (e.g., the modeler) through its senses. Physical entities are externally perceived

through any of the subject senses, whereas psychical entities are internally sensed by the subject (e.g., desires, pains,

and mental representations). Physical entities are usually called things. They have spatial, temporal and causal

properties; that is to say that they exist in a given location of the real world, at a given time, and are transformed or

caused by other entities. People, machines, places, plants, animals, physical phenomena, devices and materials are

examples of physical entities.

Ideal or abstract objects, on the other hand, cannot be perceived by the subject through its senses. They do not

exist in the real world. They do not have spatial, temporal or cause-effect properties, but they do exist and can be

mentally represented. They can be specialized into four groups: relationships, semiotic objects, mathematical objects

and conceptual objects. Relationships establish an association between two or more entities (e.g. equality, similarity,

comparison, spatial order, temporal order, composition, cause-effect, aggregation, classification, generalization,

etc.). Semiotic objects include all forms of signs and the natural and artificial languages created using them. The

mathematical objects are the numbers, geometrical figures, logical-mathematical symbols, and all the expressions,

formulas, equations and so on used in Logic and Mathematics. Finally, conceptual objects are divided into concepts,

properties, propositions, and reasoning [18].

...Policy

Business Rules

ProcedureStandardProgramPlanLaw

7

Entity

Ideal or AbstractObject

Real or ConcreteEntity

PsychicalObject

PhysicalObject

ConceptualObject

MathematicalObjectRelationship

Figure 7. An ontological classification of entities

An organizational system involves, in many different ways, a rich set of entities. A business entity is a concrete

or abstract object that is relevant to the organizational system. Entities are related to the execution of business

processes. For instance, resources such as people, money, raw materials, equipment, and data are kinds of entities

that are required to carry out processes. Clients and suppliers are also kinds of entities involved in most business

processes. An attempt to classify the most common business entities is given in Figure 8.

...Product

BusinessEntity

AccountOrderResourceService SupplierClient

HumanResource Knowledge TechnologyInformationDataFinancial

ResourceRaw

Material Facility

...

Figure 8. Typical business entities

Each entity has an unlimited set of properties. Not all the properties of an entity are relevant to an organizational

system. The relevance of the entity properties is determined during the modeling process based on the information

needs and requirements that are imposed by the business processes. The selected properties of an entity are called

attributes.

The set of all the values assigned to the known properties of an entity at a given time is called the state of the

entity. Each entity of the organizational system is, at a given time, in some state.

2.7 Events

Processes are activated by the occurrence of events. An event is an action of very short duration that takes place

inside or outside the organizational system. It signals the starting or ending point of a process. Events may be

programmed or casual. For instance, the occurrence of the time to initiate an activity in a plan or schedule is a

programmed event, whereas the occurrence of an accident, incident or happening is a casual event.

Events are also classified into external and internal. External events occur in the environment of the

organizational system. The arrival of an order or a payment is an example of external events caused by an external

8

actor or another organizational system. Internal events happen into the organizational system. Reaching a production

quote, an equipment failure and the occurrence of a programmed time for starting (or stopping) a production process

are examples of internal events.

An event may change the state of one or more entities of the organizational system. A change of state implies

changes in some of the attribute values of an entity. Attributes that do not change with the occurrence of events are

called invariants (e.g. the name and birth date of a person).

3. The relationships between an organizational system and its business information

system(s) The relationships between an organizational system and its BIS are shown in Figure 9. The BIS objective is to

produce the information needed by actors (users) in an organizational system.

Organizational System

Ends

Events

Business Rules

Processes Entities

Actors

Business Information System

trigger

updatedata

objects

perform

producesinformation

requestinformation

updatedata

objects

modify state

models

uses orinvolves

...

......

DB

Figure 9. Relationships between an organizational system and its BIS

Actors request information from BIS to perform business processes. Information is produced by the BIS by

managing a database that stores data about the entities related to the organizational system. A BIS database is a

model of the entities of an organizational system. Each relevant entity of the organizational system is represented in

the database by a data object, which captures the state and behavior that the entity has in the organizational system at

a given time. The business processes, and/or the events that occur in the organizational system or in its environment,

generate data that are used by the BIS to update the database.

The different relationships between the components of the organizational system and its BISs have determined in

many OO analysis and design methods the need for identifying and modeling processes, events and entities.

However, the close relationships existing between all the eight components of an organizational system indicate the

9

need to consider the system as a whole, that is, from a systemic or holistic perspective. The method described in the

next section identifies and models not only the processes, events and entities of an organizational system, but its

ends, job structure, actors, technologies, and business rules which altogether conform the system as a whole.

4. Modeling the Business Domain of a BIS Our generic business model may be used as an organizational design pattern for modeling the domain of an

information system. This process is called Business Modeling. In this section, we outline the structure of a method

for object-oriented business modeling. The basic premise of this method is that a good understanding of the BIS

organizational system is essential for a comprehensive definition of its requirements. Knowledge acquisition about

the organizational system is a critical success factor for developing BIS. An organizational system can be known

through a system modeling process that captures and represents its components and their interrelationships. The

phases of the method are defined based on these components, as shown in Figure 11.

The main inputs to the method are the existing documentation and the knowledge that human actors (BIS users)

have about their organizational system. The output of the method is a model that describes the components of the

organizational system and their relationships. The resulting model can then be used as a framework for defining and

specifying the user's requirements during the Requirement Analysis & Specification phase in most OO analysis and

design methods.

A detailed description of the method is given in [17]. The purpose of each step and the techniques used to

perform the tasks are given next.

1. Identify the organizational problems. - The development of a new BIS is usually motivated by information

requirements that are not fully satisfied by the existing systems. The objectives of this step are to define the

organizational system and determine what motivates the need of developing a new BIS. Problems can be easily

identify by applying reverse engineering. A process model of the existing organizational system is developed

and used as a vehicle for determining the organizational and information problems.

2. Define the organizational ends. - This step involves the definition of the mission, goals and objectives of the

organizational system. These ends could be redefined based on the scope of the organizational change that will

be introduced into the organization, by the use of new information technologies. The objectives of the new

information system are also outlined here.

3. Identify the technologies and business rules to be used. - Technologies and business rules determine the way

processes are designed. A descriptive list of technologies and business rules must be done in this step. This list

is then used for refining and adjusting the process architecture defined in the next step.

4. Redesign the business processes. - In this step, modelers redesign the existing business processes, or create

entirely new processes, based on the ends, technologies and business rules previously established. This activity

is called forward engineering. The result of this step is an acyclic directed graph called process architecture (an

example is shown in Figure 3).

10

Figure 11. A method for modeling organizational systems

5. Redesign the job structure. - The business processes redesigned above may imply a redesign of the job

structure. This structure is captured by a diagram called organization chart. It is also an acyclic directed graph

whose nodes are the departments involved in performing the processes of the system. The job structure can be

related to the process architecture using a matrix whose entries determines what processes are performed by

each department of the job structure. In this manner, we not only identify the users of the BIS but the processes

that they carry out.

6. Identify the actors. - Actors are the people and machines involved in the execution of processes in the

organizational system. Actors could be external or internal to the organizational system. External actors are in

the environment of the organizational system, whereas internal actors are members of the organizational units

(i.e., departments, divisions or groups) that comprise the job structure of the system.

(Organizational Model)

IdentifyOrganizational

Problems

DefineOrganizational

Ends

IdentifyTechnologies &Business Rules

Redesign BusinessProcess

Identify andModel Events

Identify andModel Business

Entities

AssembleOrganizational

Model

Identify ActorsRedesign

Job Structure

(Org.Syst.Documentation)

(Process Architecture)

(Organizationalchart)

(Use case diagrams)

(Class diagrams)

11

7. Identify and model the events. - An event is any action or incident that occurs into or outside the

organizational system. The execution of processes into the organizational system is caused or triggered by

events. An event may change the state of an entity. The state of an entity is the set of values associated with its

properties at a given time. Events can be modeled using use-case diagrams [12]. We concentrate here in two

types of events: external and internal. External events define the interaction between the organizational system

and its environment. Use-case diagrams can be used here to model the external actors and the events that trigger

the main business processes of the organizational system. Internal events are related to the information system.

By using use-case diagrams, the modelers identify and model the main interaction between the internal actors

and the information system.

8. Identify and model the business entities. - The execution of processes in the organizational system uses,

consumes, produces, requires or involves a set of entities. An entity is a concrete or abstract object that is of

interest to the organizational system. Entities have properties that define their characteristics. Properties may be

spatial, temporal, physical, psychological, sociological, etc. Based on their common properties, entities are

grouped or classified into entity types or classes. The purpose of this step is to identify and represent the classes

or types of entities that are relevant to the organizational system. Deciding on the types of entities and the

properties that should be captured or modeled is based on the knowledge we have about the processes, their

associated technologies, the business rules, and the actors that perform those processes. UML Class Diagrams

[12, 13] are used here to capture the main classes of entities of the organizational systems, as well as the

relationships between these classes. If the organizational system is too complex (made of many processes), we

propose here to built a class diagram for each main process of the process architecture and then integrate the

resulting diagrams into a unique class diagram.

9. Assemble the organizational model. - The organizational model is a collection of notes, diagrams and

documents produced by the steps 1-8. These diagrams are collected, organized and documented in this step in

order to produce and deliver the organizational model.

5. Conclusions We have introduced in this paper an object-oriented business model that captures the main components of a BIS

domain. A BIS domain, called here organizational system, is the application domain, organization or system that is

supported by a BIS. We believe that by modeling the BIS domain before modeling the BIS itself, the modelers can

get a more comprehensive knowledge of the problems that are present in the organizational system, as well as a

better understanding of user’s requirements.

Our business model helps to represent organizational systems from a comprehensive point of view, in terms of all

the components of the organizational system: ends, actors, processes, technologies, entities, job structure, rules and

events.

We also introduce in this paper a method for modeling business domains (organizational systems). It uses some

of the notatios of the Unified Modeling Language [14], [15] for representing the different components of the

organizational system. The method may be applied with the existing object-oriented analysis and design methods as

12

the initial phase just before the requirement analysis and specification phase. It may be used, for instance, as an

introductory phase to be applied just before the Inception Phase of the Rational Objectory Process [9, 10].

The significance of our method is that it helps the BIS modelers to: (a) gain a better understanding of the ends,

processes, actors, rules, job structure, events and entities of the organizational system; (b) define user's requirements

based on business processes rather on user preferences; as a consequence, the specified user's requirements are more

stable; and (c) apply business reengineering techniques which can help to incorporate the BIS more easily into the

new organizational processes.

The business model is actually been used for designing a reference model for integrated automation in

manufacturing organizations. The method, on the other hand, is been extensively used as a teaching instrument for

developing small projects in several courses on information systems conducted at the University of Los Andes in

Mérida, Venezuela.

References

[1] R. Fuenmayor, "Una teoría sistémico-interpretativa sobre organizaciones (An Interpretive System Thinking Theory about Organizations)". Internal report, Universidad de Los Andes, Facultad de Ingeniería, Escuela de Ingeniería de Sistemas, Departamento de Sistemología Interpretativa, Mérida, Venezuela. 1989.

[2] D.E. Avison, Information systems development methodologies: a broader perspective" In Method Engineering (Eds. ), 199?.

[3] Wegscheider, “Toward Code-Free Business Application Development,” IEEE Computer, 30(3), 1997, 35-43. [4] D.J. Flynn, Information Systems Requierements: Determination and Analysis, (London: McGraw-Hill, 1992). [5] I. Jacobson, Object-Oriented Software Engineering: A Use Case Driven Approach, (Reading, MA: Addison-

Wesley, 1992). [6] J. Rumbaugh, et al., Object-Oriented Modeling and Design, (New York: Prentice-Hall, 1991). [7] J. Martin and J. Odell, Object-Oriented Analysis and Design, (New Jersey : Prentice Hall, 1992). [8] D. Coleman, et al., Object-Oriented Development: The Fusion Method, (New Jersey: Prentice-Hall, 1994). [9] G. Booch, Object-Oriented Analysis and Design with Applications, Second edition, (Massachusetts: Addison-

Wesley, 1994). [10] E. Yourdon, K. Whitehead, J. Thomann, K. Oppel and P. Nevermann, Mainstream Objects : An Analysis and

Design Approach for Business, (NJ : Prentice Hall, 1995). [11] Rational Software Corporation. Executive Briefing: Business Engineering with Objectory – A Technical

Overview. (http://www.rational.com/Objectory, 1998). [12] Rational Software Corporation. Rational Objectory Process 4.1: Your UML Process. White Paper.

(http://www.rational.com/Objectory, 1998). [13] Cook, S. and Daniels, J. “Essential Techniques for Object-Oriented Design”, In A. Carmichael (Ed.), Object Development Methods, (New York : SIGS Books, 1994), 45-66. [14] M. Fowler and K. Scott, UML Distilled: Applying the Standard Object Modeling Language. (Massachusetts:

Addison-Wesley, 1997). [15] Rational Software Corporation. The Unified Modeling Language: Notation and Semantics Guides,

(http://www.rational.com, 1997). [16] J.L. Gibson, J.M. Ivancevich and J.H. Donnelly, Organizations: Behavior, Structure, Processes, Third Edition,

(Dallas: Business Publications, 1979). [17] J. Montilva. Un Estudio de los Modelos Semánticos de Datos (In Spanish). Trabajo de Ascenso a Profesor

Asociado. (Universidad de Los Andes, Facultad de Ingeniería, Escuela de Ingeniería de Sistemas. 1989).

13

[18] A.Garcia Morente. Lecciones Preliminares de Filosofía (in Spanish). (México: Editores Mexicanos Unidos, 1983).

[19] J. Montilva, Modeling the Application Domain in Object-Oriented Analysis and Design, Research Report, (Universidad de Los Andes, Facultad de Ingeniería, Escuela de Ingeniería de Sistemas, Departamento de Computación, Grupo de Ingeniería de Datos y Conocimiento, 1997).