CC BY
37
UML FOR THE REPRESENTATION OF OQL-RESULTS
Pavel Oleynik, System Architect, JSC Aston, Russia, Rostov-on-Don, xsl@list.ru Euclid Keramopoulos, Department of Informatics, Technological Education Institution of Thessaloniki,
Greece, Thessaloniki, euclid@it.teithe.gr
Introduction
Modern corporate information systems (CIS) are developed using object-oriented technologies (ООТ), which has as key stage the design. For the description of various aspects of software behavior and structure we use graphic notations, most known of which is UML [1]. Let's mark, that the object-oriented design (OOD) principles is used for the development of client applications, and also for the underlying database (DB) structures by using object-oriented database management systems (OODBMS). The main standard regulating OODBMS functional capabilities is ODMG 3.0 specification [2] which supports the Object Query Language (OQL) [2, 3], an SQL like query language for the OODBMS.
In the literature we found a lot of graphical query languages [4 - 16] that represent query elements by using graphical notation. On the other hand researchers did not pay attention to present the query output in a graphically way. They present the results either textually or in a tabular way. As Catarci [17] remarks the query output should be graphical and among the few efforts for such an outcome, only GOMI [8] and AMAZE [6] gives a graphical solution to that specific problem. GOMI presents the query output graphically in a similar notation as it presents its query features. AMAZE, on the other hand presents the query output in a 3D way which is rather awkward for users.
A two dimensional table is natural to used for the representation of query results in the Relational data model because an attribute can save only an atomic value [18, 19]. The Object-Oriented data model intended for saving more complex structures of data (classes) and therefore tabulated format is inappropriate. On the other hand, the UML object diagram, which presents model interrelation of objects (class instance) of the data domain, can be considered as the best solution for the representation of OQL output. That is because, the output of an OQL query can be a collection type; i.e. set, list, bag and therefore building blocks of this syntax construction can be considered as the creation of an Object diagram. Finally, UML is a technique that a big proportion of users are familiar with.
In this paper we present the OQL output in a graphic notation using UML Object diagram [1]. More specifically, in section 2 the running example is presented using a UML diagram whereas in section 3 our technique is analyzed by giving some examples. In section 4, we are presenting different types of OQL query outputs via examples. Finally, in section 5 some conclusions are drawn and we are discussing our future work.
1. Domain Model
On Fig. 1 the Class diagram of the running example is represented. On this diagram two classes are presented, the Order and the Item class, which are subclasses of the abstract root class Object (Object is predefined in an OODBMS). The class Object consists of a single attribute OID that is used to save the object identifier in an OODB. The class Order includes three attributes, (a) the ClientName that describes the client surname and name, (b) the order Description and (c) the Items, a collection of Item objects. The class Item includes three attributes, (a) the ProductName that keeps the product name, (b) the product Price and (c) the Count, which represents the product quantity.
2. A metamodel for the presentation OQL-results
For the representation of OQL-results it is required the development of a corresponding metamodel, which include classes presented in Class Diagram (Fig. 1). In order to create the metamodel we draw a list of six optimality criterions (OC). More specifically,
1. The initial OQL-query is presented in an Object-diagram.
9
2. The retrieved elements are shown in an ordered sequence.
3. The result collection is represented for each projected object.
4. Every projected object property value is shown in the diagram.
5. The projected item type is presented.
6. The produced Metamodel is unified and have the capability to be extended in any data domain.
Fig. 1. The Class diagram of the running example
In Fig. 2 the instances of the described classes are presented.
: Order : Item : Order : Item
OID = 00001 Items OID = 00002 OID = 00011 Items OID = 00013
ClientName = John Wolker Ф- > ProductName - Shirt ClientName = Bill Henderson ProductName = Chair
Description = First order Price = 10 Description = Patron Price = 43
Items Count = 5 Items Count = 3
I
Items
: Item
OID = 00003 ProductName = Dress Price = 120 Count = 7
Items^ : Item
У OID = 00004 ProductName = Chemise Price = 12 Count = 40
l
Items
: Item
OID = 00012 ProductName = Desk Price = 150 Count = 2
Items : Item
OID = 00014 ProductName = Sofa Price = 180 Count = 5
: Order Items — ^ : Item
OID = 00021 ClientName = Pavel Oleynik Description = Rush order Items ^ OID = 00022 ProductName = Computer Price = 970 Count = 11
I
: Order
OID = 00031
ClientName = Patrick Yells Items
Description = Front money
Items
: Item
OID = 00023 ProductName = Monitor Price = 240 Count = 11
Items
l
Items
: Item
OID = 00034 ProductName = Nail Price = 0,2 Count = 120
Items
: Item : Item
OID = 00024 OID = 00035
ProductName = Keyboard ProductName = Screw
Price = 4 Price = 0,15
Count = 11 Count = 70
I tern s.^ : Item
OID = 00033 ProductName = Hammer Price = 1 Count = 3
Fig. 2. The Object diagram for the stored instances
First of all the text of the initial OQL-query is drawn in an Object diagram (OC1). The output is a collection type which can be ordered (by using the order by feature) and because of that a taxonomy mechanism of the projected properties is implemented (OC2). Moreover, the result of the executed query is a collection that includes all the projected elements and therefore it is necessary to develop a mechanism for the representation of the produced objects that derive from the projection (OC3) and the object properties (OC4). Furthermore, OQL is a strictly typed [2] language, which means that we can also represent the types of the projected Objects (domain model) (OC5) and the type of each Object property in the object diagram (OC4). Finally, taking into account the fact that object technologies are applied at the decision of the broad audience of tasks, it will be impossible
10
to predetermine the representation of query results for every data domain that the metamodel can be used. Therefore it is necessary to provide a mechanism for its extension according to the structure of an underlying domain model (OC6).
On Fig. 3 the metamodel Class diagram is used for the representation of OQL-results. The abstract class OQLResult is used to store the initial OQL query. It consists of a string attribute OQL that contains the initial query (OC1). After the execution of the OQL-query the returned collection of the output of the query is stored in the class SelectQueryResult. It contains an attribute the ResultItems which is of type collection of SelectResultItems and it is used for storing all the projected elements. Every SelectResultItem class instance represents an element of the output collection (OC3) and stored into the collection SelectItems (OC4). Taking into account that the representation of the projected element types is necessary (OC5), we define the abstract class DataType for that specific usage. On Class diagram are shown as atomic literal types (inherited from Literal class) which, as a rule, are defined in OODBMS, and the classes representing entity of a subject domain model (inherited from Object), i.e. there are the classes shown on Fig. 3. It accomplishes a unique metamodel which is independent of the domain model as the UML is and thus, it can be applied to any domain model (OC6).
Fig. 3. The metamodel Class diagram for represent OQL-results
3. Examples of OQL-queries
In this section we present the OQL output as a UML Object diagram by using some examples. On Fig. 4, it is given the first example where all the order details are presented. In the center of Fig.
4, there is an instance of class SelectQueryResult which presents the structure of the OQL-query in the ODMG 3.0 notation. In the select clause the attributes of class Order are listed and therefore on Fig. 4 the value of each attribute is submitted by a separate literal type object (instance). So for each collection item that returned by select clause, the object OID of literal type BigInt representing the objective identifier of the certain order is submitted.
11
Fig. 4. Find all the order details
Let's consider a more complex example of an OQL-query that presents all Items’ details in an alphabetical order by the ProductName attribute (Fig. 5). Here all the instances of class Order are presented with the corresponding instance of the class Item as a reference to the attribute Items.
Fig. 5. List the Item’s details ordered by the product name
On Fig. 6, it is represented a more complex query where instances of two different classes are used. In this example the query gets the instances of the Order class that the customer ‘Pavel Oleynik’ did and calculates the total amount of money that the specific customer has spend for those orders. We have to notice here the attribute Items which is of type Item. Therefore OQL-result includes instances of class Item and Order objects. Finally, the type of the attribute OrderCost is Money because the attribute Price (Item class) has been defined with this datatype.
12
Fig. 6. Get the order instance of customer ‘Pavel Oleynik’ and the total amount that spend for that
orders
Conclusions
In this paper we introduce a new graphical representation of OQL-query results based on the Object diagram of the UML. We believe that UML is appropriate to present the output of an application because (a) UML object diagram can represent model interrelation of objects (class instance) of the data domain, (b) UML is independent of the data model and (c) UML is popular enough between the application designers. In our future plans we include the implementation of this method for GOQL [5], which is a graphical query language based on OQL. We believe that our method can give the solution to the graphical representation of query results in a standardized way for the majority of data models.
References
1. Hamilton K., Miles R. Learning UML 2.0 (O'Reilly, 2006).
2. Cattell R.G., Barry D.K. The Object Data Standard: ODMG 3.0 (Morgan Kaufmann Publishers, 1999).
3. O2 Technology. ODMG OQL User Manual, Release 5.0 - April 1998,
http://www.csd.uwo.ca/courses/CS411a/pdfO2manuals/oql.pdf
4. Jun Y.S., Yoo S.I. GOMI: A Graphical User Interface for Object-Oriented Databases. Proc. of International Conf. on Object-Oriented Interface Systems (OOIS), 1995, p.238-251.
5. Keramopoulos, E., Pouyioutas P. & Ptohos T.. The GOQL Graphical Query Language. International Journal of Computers and Applications (IJCA), 24(3), 2002, 122-131.
6. Boyle J., Leishman S. & Gray M.D.. From WIMPS to 3D: The Development of AMAZE. Journal of Visual Languages and Computing, 7(3), 1996, pp. 291-319.
7. Paredaens J., Peelman P. & Tanca L.. G-Log: a graph-based query language. Journal of IEEE Transactions on Knowledge and Data Engineering, 7(3), 1995, 436-453.
8. Jun Y.S. & Yoo S.I.. GOMI: A Graphical User Interface for Object-Oriented Databases. Proc. of International Conf. on Object-Oriented Interface Systems (OOIS), 1995, 238-251.
9. Murray N., Paton N., Goble C. & Bryce J.. Kaleidoquery: A Flow-based Visual Language and its Evaluation. Journal of Visual Languages and Computing, 11(2), 2000, 151-189.
13
10. Kim H., Korth, H.F. & Silverschatz, A.. PICASSO: A Graphical Query Language. Software-Practice and Experience, 18(3), 1988, 169-203.
11. Kuntz M. & Melchert R.. Pasta-3's Graphical Query Language: Direct Manipulation, Co-operative Queries, Full Expressive Power. Proc. of the 15th International Conf. on Very Large Databases, Amsterdam, 1989, 97-105.
12. Angelaccio M., Catarci T. & Santucci G.. QBD*: A Graphical Query Language with Recursion. IEEE Transaction on Software Engineering, 16(10), 1990, 1150- 1163.
13. Dennebouy Y., Andersson M., Auddino A., Dupont Y., Fontana E., Gentile M. & Spaccapietra S.. SUPER: Visual Interfaces for Object + Relationship Data Models. Journal of Visual Languages and Computing, 6(1), 1995, 73-99.
14. Papantonakis A. & King P.J.H.. Syntax and Semantics of Gql, a Graphical Query Language. Journal of Visual Languages and Computing, 6(1), 1995, 3-25.
15. Dar S., Gehani N.H., Jagadish H.V. & Srinivasan J.. Queries in an Object-Oriented Graphical Interface. Journal of Visual Languages and Computing, 6(1), 1995, 27-52.
16. Chavda M. & Wood P. T.. Towards an ODMG-Compliant Visual Object Query Language. Proc. of the 23rd VLDB Conf., Athens (Greece), August, 1997, 456-465.
17. Catarci T., Costabile M.F., Levialdi S. & Batini C.. Visual Query Systems for Databases: A Survey. Journal of Visual Languages and Computing, 8(2), 1997, 215-260.
18. Date C.J. An Introduction to Database Systems, Eighth Edition (Addison Wesley, 2003).
19. Connolly T.M., Begg C.E. DataBase Systems: A Practical Approach to Design, Implementation and Management (4th Edition), (Addison Wesley, 2004).
УДК 681.3
АНАЛИЗ ИНСТРУМЕНТАЛЬНЫХ СРЕДСТВ МОДЕЛИРОВАНИЯ БИЗНЕСПРОЦЕССОВ СОВРЕМЕННОГО ПРЕДПРИЯТИЯ
Королев Евгений Николаевич, к.т.н, доцент кафедры САПРИС, Воронежский государственный технический университет, Россия, Воронеж, korolev73@mail.ru
Бескоровайная Мария Александровна, студент, Воронежский государственный технический
университет, Россия, Воронеж, masya89@mail.ru
Фиртыч Оксана Александровна, студент, Воронежский государственный технический университет, Россия, Воронеж, oksanka@ya-blondinka.com
Исследование процессов функционирования современной организации в условиях постоянно меняющихся факторов внешней и внутренней среды приобретает особую актуальность, особенно с точки зрения взаимосвязи динамического, статического и структурного аспектов, с одной стороны, и понимания механизмов адаптации к меняющимся условиям, с другой. Совершенствование деятельности организации в настоящее время должно базироваться на управлении процессами её функционирования и концепции их жизненного цикла.
Следовательно, реализация информационно-ориентированного механизма управления современной организацией, базирующегося на передовых информационных технологиях и информационных системах, является актуальной задачей, решение которой способствует повышению адаптивности и конкурентоспособности организации в условиях динамично меняющейся рыночной среды [1].
Методика моделирования ARIS основывается на разработанной профессором Августом Шером теории построения интегрированных ИС, определяющей принципы визуального отображения всех аспектов функционирования анализируемых компаний. ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:
• организационные модели, представляющие структуру системы
• функциональные модели, содержащие иерархию целей, стоящих перед аппаратом управления
• информационные модели
14
