AN OBJECT ORIENTED APPROACH TO BUSINESS MODELING IN INFORMATION SYSTEMS DEVELOPMENT *

Transcription

1 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 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

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 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 2

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. Event Entity Business End achieves determines applies performs Technology Actor triggers modifies 2.1 Ends: missions, goals and objectives involves participates regulates Business Rule Figure 1. A generic business model defines is-member-of 1 Job Structure 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. 3

4 2.2 Business processes A business process is a set of structured and hierarchical activities designed for reaching organizational ends. es 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 Production Decision Making Service Administrative Data Management Organization Business Control Data Acquisition DB Management Information Planning Design Communication Prod. 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. Risk Analysis and Planning Managing Accidents Accident Evaluation Functions Impact Evaluation Emergency Planning Accident Response es Selecting Response Activities Determining Combat Resources Tasks 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 4

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 1+ Organizational Unit Functional Structure Territorial Structure Product-based Structure Matrix Structure Division Department Supervision Unit 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. Technology Information Technology Communication Technology Production Technology Transportation Technology 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 5

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. es 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. Business Rules Law Policy Plan Program Standard Procedure 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]. 6

7 Entity Real or Concrete Entity Ideal or Abstract Object Physical Object Psychical Object Relationship Mathematical Object Conceptual Object 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. Business Entity Product Service Resource Order Account Client Supplier Human Resource Financial Resource Raw Material Data Information Knowledge Technology 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 es 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 7

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 Business Rules modify state Events trigger es uses or involves Entities update data objects update data objects request information perform Actors produces information Business Information System models 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 8

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). 9

10 Identify Organizational Problems (Org.Syst.Documentation) Define Organizational Ends Identify Technologies & Business Rules Redesign Business ( Architecture) Redesign Job Structure Identify Actors (Organizational chart) Identify and Model Events (Use case diagrams) Identify and Model Business Entities Assemble Organizational Model (Class diagrams) (Organizational Model) 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. 10

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 11

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 [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 [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, [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. ( 1998). [12] Rational Software Corporation. Rational Objectory 4.1: Your UML. White Paper. ( 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), [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, ( 1997). [16] J.L. Gibson, J.M. Ivancevich and J.H. Donnelly, Organizations: Behavior, Structure, es, 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). 12

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). 13