OBJECT ORIENTED MODELLING, A MODELLING METHOD OF AN ECONOMIC ORGANIZATION ACTIVITY

Transcription

1 OBJECT ORIENTED MODELLING, A MODELLING METHOD OF AN ECONOMIC ORGANIZATION ACTIVITY TĂNĂSESCU ANA, ASSOCIATE PROFESSOR PHD, PETROLEUM AND GAS UNIVERSITY OF PLOIEŞTI, FACULTY OF ECONOMIC SCIENCES, ROMANIA, atanasescuro@yahoo.com Abstract Now, most economic organizations use different information systems types in order to facilitate their activity. There are different methodologies, methods and techniques that can be used to design information systems. In this paper, I propose to present the advantages of using the object oriented modelling at the information system design of an economic organization. Thus, I have modelled the activity of a photo studio, using Visual Paradigm for UML as a modelling tool. For this purpose, I have identified the use cases for the analyzed system and I have presented the use case diagram. I have, also, realized the system static and dynamic modelling, through the most known UML diagrams. Key words: object oriented modelling, static modelling, dynamic modelling, use cases, UML JEL Classification: C81, C61 1. Introduction In order to capitalize their activity, most economic organizations use different information systems types. An information system can be designed using certain methodologies, methods and techniques, a detailed presentation of these existing in the specialty literature [2, 5, 7-9, 17]. In this paper I propose to model an economic organization activity, respectively a photo studio activity, using the object oriented approach. Forwards the advantages of using object oriented modelling at information systems design, as well as the stages achieved to model the activity of the analyzed economic organization (use cases identification, static modelling and dynamic modelling) are presented. 2. Object oriented methodologies used at information systems design Object oriented model was developed around the object concept, just as the entity relationship model was developed around the entity term [6]. This model includes the principles of abstraction, encapsulation, modularity, concurrency and persistence. The enumerated principles are not new, but there are interconnected in a synergistic way in this model [1]. Several information systems design methodologies that use this approach have been elaborated in time. Among the most important methodologies are [2, 8, 15]: Object Oriented Design (OOD) elaborated by Grady Booch; Object Oriented Analysis (OOA) created by Peter Coad and Edward Yourdon; Object Oriented Structured Design (OOSD) developed by Anthony Wasserman; Object Oriented System Analysis (OOSA) proposed by Sally Shlaer and Stephen Mellor; Responsibility Driven Design (RDD), having Rebecca Wirfs-Brock, Brian Wilkensson and Lauren Wiener as owners; Object Oriented Role Analysis, Synthesis and Structuring (OORASS), belonging to Reens Kaugh; Object Oriented System Analysis (OOSA) elaborated by David Embley; Object Modeling Technique (OMT) created by James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy and William Lorensen; Object Oriented Software Engineering (OOSE) built by Ivar Jacosbson; BON Methodology introduced by Jean-Marc Nerson and Kim Waldén; Hodge-Mock Methodology proposed by LeRoy Hodge and Mary Mock; Syntropy designed by Steve Cook and John Daniels; Fusion developed by a team of Hewlett Packard company; Objectory realized by Ivar Jacobson. 275

2 Unified Modeling Language (UML) has emerged in order to remove the limits and the multiple differences between symbols, notations or diagrams types existing in these methodologies [1-4, 11-14, 16, 18, 19]. The author used UML language to describe the functional services, the static structure and the operation dynamic of the analyzed system through its three diagrams types. Unlike the traditional structured methodologies used at the information systems analysis and design, object oriented methodologies present the following advantages [6, 8, 10, 15]: provide an abstraction method of the analyzed problem that represents the way the users view the reality; define the problems using objects, therefore data are not distinctly represented anymore, but they are encapsulated in objects classes; can easily and quickly modify the analysis realized for a certain system, in order to be used at the analysis of the systems from the same field; the used models are flexible and easy to maintain; have the ability to tackle more challenging fields; allow improving the communication between users, analysts, designers and programmers; increase the compatibility between analysis, design and programming activities; represent explicitly the common elements of the system components; the systems are robust; reuse analysis, design and programming results; increase the compatibility between all the models developed during object oriented analysis, design and programming activities, so that programmers can directly reuse designers specifications. Using a common approach for analysis, design and programming activities provide a consistent image during the system engineering process, ensuring efficiency and concordance in quick achieving of some products that are good and have small costs. 3. Use cases identification A use case models a service brought by the system. It expresses the interactions between actors and system and brings a notable added value to that actor [3]. Use case diagram can contain the following elements: actors, association relationships, generalization relationships, extend relationships and include relationships. It models the user requirements regarding the system functionalities. This diagram objective consists in identifying all the characteristics that customers request to the system, but does not reveal any detail about their implementation [14]. Use case diagram presented in figure 1 has been created using Visual Paradigm for UML modelling tool [20] and models services orders receiving system, the main activity object of the photo studio. Figure 1. Use case diagram for services orders receiving system. 276

3 This diagram analyzes the customer relations with the photo studio employees and with the information system (includes databases that store information regarding customers, portfolio, contracts and orders). As it can be seen in figure 1, the diagram contains the following use cases: Request Services Catalog, Place Order, Elaborate Contract, Pay Advance, Supply Service, Search Customer, Create Customer, Control Service Quality and Pay Service. A scenario represents a sequence of actions that emphasizes behaviour. A scenario can be used to emphasize an interaction or an execution of a use case instance [16]. The description of Elaborate Contract use case is detailed in table 1 that includes the following information: use case name, primary actor, secondary actor, objective, preconditions, post-conditions, nominal scenario and alternative scenario. Use case name Primary actor Secondary actor Objective Preconditions Post-conditions Nominal scenario Alternative scenario Table 1. Elaborate Contract use case detailed description. Elaborate Contract Employee Contracts DB<<System>>, Customer Elaborate the services supply contract based on the specifications from the customer order. Photo studio employee has received the customer order and has accepted his requirements. Services supply contract has been concluded and completed with the advance payment by the customer. 1. The employee requests to the customer an advance payment and the scenario continues with the unfolding of the phases that are specific to Pay Advance nominal scenario. 2. After the advance payment, the employee elaborates the services supply contract draft, taking into account the requirements that are specified into the customer order. 3. The customer analyzes the draft and resends it back to the employee, not having anything to object. 4. The employee completes the contract clauses and the scenario continues with the first phase of Search Customer nominal scenario. 5. The customer receives the contract final version and the scenario continues with the first phase of Supply Service nominal scenario. 2a. The employee does not elaborate any kind of draft for the services supply contract because the customer denies to pay the advance. 3a. The customer analyzes the draft and indicates a corrections list. 1. The employee reviews the contract based on the corrections and resends it back to the customer. The alternative scenario continues with the second phase of the nominal scenario. 4. System static and dynamic modelling The static aspects of the analyzed system are modelled by structure diagrams. These aspects offer the framework in which the model dynamic elements can be executed and are represented by: classes and associations, objects and links, as well as collaborations [14]. Among the seven structure diagrams [17], the author has chosen to present the class diagram and object diagram. Class diagram describes objects types from the system and different relationships types that exist between them. This, also, presents the properties and classes operations, as well as the constraints that apply to the way the objects are connected [4]. A class represents the abstract description of an object set [3], having the same structure (the values that their properties have at a given moment) and behaviour (defined by their operations set). After I had interviewed the photo studio employees about the orders receiving activity, I have identified and defined ten objects classes and two association classes. Class diagram designed by the author and presented in figure 2 contains: 10 objects classes represented by: the photo studio customers (Customer) that can be natural persons (NPCustomer) and legal persons (LPCustomer), the photo studio employees (Employee), types of studio supplies (SupplyType), the photo studio supplies (StudioSupply) that are, also, divided in the offered products (Product) and the offered services (Service), the orders sent by the customers to the photo studio employees (Order) and the contracts concluded by the customers with the studio employees (Contract). 2 association classes that describe the orders and the contracts content, namely OrderContent and ContractContent. 277

4 Figure 2. Class diagram that models a photo studio activity. In a class diagram can exist several relationships types: generalization relationships, dependency relationships and realization relationships between classes, as well as association relationships, aggregation relationships and composition relationships between instances of some classes. The proposed diagram includes the following relationships: two generalization relationships existing between Customer and NPCustomer classes, respectively LPCustomer, as well as between StudioSupply and Product classes, respectively Service; an aggregation relationship between StudioSupply and StudioType classes; two many to many bidirectional association relationships between Order and StudioSupply classes, but, also, between Contract and StudioSupply classes, whose characteristics are found in the two association classes, OrderContent and ContractContent; four one to many bidirectional association relationships between Customer and Order classes, Customer and Contract classes, Employee and Order classes, as well as Employee and Contract classes. Object diagram represents an instances graph that includes objects and values of their attributes [2]. While class diagram models resources definitions, object diagram treats facts or examples [14]. This diagram is useful in the early phases of the design because it models examples or instances. The rules that need to be part of the resources definitions and of their relationships can be identified by these instances. This diagram is, also, useful in the last phases of the design process because it allows modelling tests that verify the correctness of class diagram. The object diagram built for the analyzed system is emphasized in figure 3 whose goal is to verify the correctness of the classes and relationships defined between these classes from the class diagram. UML language uses three diagrams types to realize the system dynamic modelling, namely: state machine diagram, interactions diagrams and activity diagram. This modelling role consists in describing the objects behaviour when some events trigger. These are designed based on the use cases and their scenarios. I have chosen to present in this paper only the first two diagrams types, having as a starting point the Elaborate Contract use case detailed in table 1. State machine diagram describes the objects dynamic behaviour over time by modelling objects life cycles of each class [16]. Each object is treated as an isolated entity that communicates with the rest of the environment by identifying events and responding to them. Events represent the types of modifications that an object can detect (messages received from other objects, modifications of some values etc.). A state is a set of object values for a given class that have the same qualitative response to events that occur. 278

5 Figure 3. Object diagram. A state machine diagram is a graph of states and transitions. Commonly, it is associated to a class, but can be, also, associated to operations, use cases and collaborations in order to describe their execution. The distinct states that an object of the Contract class passes, as well as the transitions between these states are illustrated in figure 4. Figure 4. State machine diagram corresponding to an object of Contract class. Among the interaction diagrams existing in the UML language, the author has chosen to build the sequence diagram that can represent the scenarios of the use cases presented in the diagram from figure 1. Sequence diagram describes chronologically the objects interactions, identifying the messages exchanged between objects as a response to an event, together with the messages sequence [8]. This diagram is characterized by the existence of two dimensions: vertical indicates objects life lines; horizontal represented by the objects whose interaction is modelled (actors or system instances) and by the messages sent between them. 279

6 In a sequence diagram can, also, be added other elements, such as: references to other interactions diagram and combined fragments that define the complex sequences of objects behaviour. The sequence diagram of the Elaborate Contract use case (figure 5) contains the following elements: two actors represented by Employee1 that elaborates the contract based on the orders placed by customer, on the one hand and on the advance payment, on the other hand and Customer1 that pays the advance, analyzes the contract draft and accepts it, if the clauses are all right; an entity class (:ContractsDB) that stores the photo studio contracts; a boundary class (:SystemInterface) that ensures the interaction between the two actors and the database; life lines of the objects that interact; four references to the sequence diagrams of the following use cases: Place Order, Pay Advance, Search Customer and Supply Service; one alternative combined fragment that shows the two actors behaviour in the case of advance payment, respectively non-payment; The expression that is evaluated refers to the advance payment. one repetitive combined fragment that specifies the fact that contract draft analysis realized by the customer, respectively the draft modification by the employee and resending back to the customer will be repeated as long as the customer identifies errors. 5. Conclusions Figure 5. Sequence diagram of the Elaborate Contract use case. This article proposes to present the benefits of using object oriented methodologies, methods and techniques in the activity of an economic organization, generally and of a photo studio, particularly. For this purpose, after interviewing the photo studio employees, the main interactions between employees and customers have been identified and, based on them, the main use cases have been defined and the use case diagram for the modelled system has been created. Then, starting from this diagram, the static and dynamic modelling of the orders receiving activity by the photo studio employees was realized. The static modelling was represented by the class diagram creation (describes system classes and relationships between them) and object diagram (is an instance of class diagram and tests its correctness). The dynamic modelling was realized by state machine diagram (indicates the states that an object from the Contract class can be found in) and sequence diagram (describes the objects and the messages sent between them in order to elaborate a services supply contract). Using the object oriented approach in the activity of a photo studio offers the following advantages: capitalize the employees activity due to the existence of an information system based on object oriented methods that will provide them support; achieving a correct record of the orders sent by customers; 280

7 monitoring the employees that must provide the services requested by the customers. At the same time, the models presented in this article ensure the following benefits: can be easily and quickly adapted in order to be used to model the activity of any commercial society that supplies services; improve the communication between customers, employees and information system developers (analysts, designers and programmers); use objects to represent field problems; are flexible and easy to maintain by designers; system elements are explicitly represented. 6. References [1]. Booch, G. et all, Object-Oriented Analysis and Design with Applications, 3 rd Edition, Addison-Wesley Professional, 2007, 720 pg., ISBN-10: X, ISBN-13: [2]. Cogzarea, G., Metodologii orientate pe obiecte utilizate în proiectarea sistemelor informatice, Editura Infomega, Bucureşti, 2010, 215 pg, ISBN [3]. Dumitraşcu, L. et. all, Analiza şi proiectarea orientată obiect a sistemelor informatice cu UML, Editura Universităţii din Ploieşti, 2005, 406 pg., ISBN [4]. Fowler, M., UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition), Addison-Wesley Professional, 2003, 208 pg., ISBN-10: , ISBN-13: [5]. Gunasekaran, A., Techniques and Tools for the Design and Implementation of Enterprise Information Systems, IGI Global; 1 Edition, 2008, 408 pg., ISBN-10: , ISBN-13: [6]. Hoffer, J., Ramesh, V., Topi, H., Modern Database Management, 11 th Edition, Prentice Hall, 2012, 624 pg., ISBN-10: , ISBN-13: [7]. Langer, A., Analysis and Design of Information Systems, Springer, 3rd ed. Edition, 2008, 418 pg., ISBN-10: , ISBN-13: [8]. Lungu, I., Sabău, Gh., Velicanu, M., Sisteme informatice. Analiză, proiectare şi implementare, Editura Economică, Bucureşti, 2003, 526 pg., ISBN [9]. Oprea, D., Dumitriu, F., Meşniţă, G., Analiza sistemelor informaţionale, Editura Universităţii "Alexandru Ioan Cuza", Iaşi, 2005, ISBN [10]. Osvalds, G., Benefits in Using Object Oriented Methodology for Architecture Modeling, 14th Annual International Symposium, 4th European Systems Engineering Conference, Incose 2004, Toulouse France, June 2004, available at /Presentations_05/INCOSE%202004%20for%20Chesapeake%20Chapter%20Meeting%2019%20Jan% pdf [accessed on 15 th March 2014]. [11]. Pătraşcu, A., Tănăsescu, A., A document management system modeling, International Scientific Conference European Integration New Challenges for the Romanian Economy, 4th edition, Oradea, May 30-31, 2008, Analele Universităţii din Oradea, Seria Ştiinţe Economice, Ediţie pe suport CD-ROM, TOM XVII, 2008, pg , ISSN [12]. Pătraşcu A., Tănăsescu, A., Use Case Scenarios Developing for Document Management, Proceedings of the 14th International Business Information Management Association Conference, June, Istanbul, Turkey, 2010, pg , ISBN [13]. Pătraşcu A., Tănăsescu, A., Document management static modelling, Proceedings of the 14th International Business Information Management Association Conference, June, Istanbul, Turkey, 2010, pg , ISBN [14]. Pender, T., UML Bible, John Wiley & Sons, 2003, 984 pg., ISBN [15]. Ramsin, R., Paige, R.F., Process-centred Review of Object Oriented Software Development Methodologies, Technical Report, 2004, available at ftp://ftp.cs.york.ac.uk/reports/2004/ycs/381/ycs pdf [accessed on 15 th March 2014]. [16]. Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modeling Language Reference Manual, Addison- Wesley, 1999, 576 pg., ISBN-10: X, ISBN [17]. Tănăsescu A., Pătraşcu A., Proiectarea sistemelor informatice, Editura Universitară, Bucureşti, 2013, 210 pg., ISBN [18]. Udrică, M., Martinov, M.D., Lupoaie, A.E., UML prin aplicaţii. Studii de caz privind dezvoltarea sistemelor informatice, Editura Renaissance, Bucureşti, 2009, 194 pg., ISBN [19]. [20]