Derivation of Architecture and Behavior from Static Diagrams, Widely-Accepted Requirements and Design Patterns

Size: px

Start display at page:

Download "Derivation of Architecture and Behavior from Static Diagrams, Widely-Accepted Requirements and Design Patterns"

Madeleine Ball
5 years ago
Views:

1 Derivation of Architecture and Behavior from Static Diagrams, Widely-Accepted Requirements and Design Patterns Macario Polo, Agustín Mayoral, Juan Ángel Gómez, Mario Piattini and Francisco Ruiz Escuela Superior de Informática University of Castilla-La Mancha Ronda de Calatrava, Ciudad Real, Spain mpolo@inf-cr.uclm.es ABSTRACT This paper presents a method for building fully executable, high-quality code from a static view (class diagram, relational schema...) of the system to be developed. For this issue, we take has input products the static view and a set of requirements generally solicited and accepted by users. The high quality of the system generated is guaranteed by the utilization of several design patterns for object-oriented systems. Keywords Design Patterns, Requirements, Software Architecture, Software Engineering automation 1 INTRODUCTION Many software systems have, as one of their main responsibilities, the managing of a enterprise database. There are many approaches for developing the software which must execute this task, as external programs that access the database via embedded SQL instructions or stored procedures, programs developed with the tools provided by the Database Management System itself, etc. Currently, relational databases are the most common databases used by organizations [5], and there are several well-known design patterns that help in the development of object-oriented software for its managing. These patterns cover from what classes must receive the responsibilities related to persistence of objects [1, 3, 4] to the type of architecture of the system. In the other side, users of programs developed for managing these databases share a wide set of required functionalities, as, for example: Introduction, modification and updating of 1 information in the database. Generation of different kinds of reports. Navigation across related data in multiple tables. Possibilities of data interchange with other applications. Possibilities of accessing data via web. From the afore-mentioned patterns, the common general requirements and a static view of the system (which can be a class diagram, a relational schema or an entityrelationship diagram), it is possible the automatic generation of code with a wide set of functionalities, specially related to the common requirements. Moreover, the use of the patterns provides the system with a very robust architecture that facilitates the addition of noncommon functionalities (not listed above) to the system, once it is generated. In this paper we present several ideas related to these transformations. We introduce a formal approach for explaining some of them (formal descriptions for describing methods used in Software Engineering are required [2]) as well as more informal descriptions. The paper is organized as follows: basic principles of the systems to be generated are depicted in Section 2; in Section 3, the method used for transforming diagrams and generating code is presented. The architecture of the tool we have built is explained in Section 4. Section 5 contains our conclusions and some promising future lines of work. 2 DESCRIPTION OF THE REQUIRED ARCHITECTURE AND BEHAVIOR One of the most widely used patterns for making objectoriented software is the multi-tier architecture. Through it, a system is divided into several tiers of objects, in such manner that a tier only has dependencies with their adjacent ones. Even, the use of interfaces, abstraction and other techniques reduces the dependence to one or even none tier.

When the software to be developed must manage an enterprise database with the general requirements stated in Section 1, a good choice is to use three-tier architecture: several types of screens can

2 When the software to be developed must manage an enterprise database with the general requirements stated in Section 1, a good choice is to use three-tier architecture: several types of screens can be designed for different types of access (local network, web, etc.) with no changing the Domain classes. Instances of many of these classes will need to be stored in the database; responsibilities related to persistence of these objects are assigned using different patterns: To the persistent class itself. To an associated class (a Pure Fabrication ). In this case, persistent classes delegate their persistence responsibilities to their respective associated classes. To an abstract class that generalizes all persistent classes (or their respective pure fabrications ): this would be the utilization of a Template Method class, which enumerates all operations related to persistence and implements only those whose code is common to persistent classes. The rest of operations are implemented in each class. For example, methods as begintransaction and endtransaction could be implemented in the superclass, whereas it would declare the insert, delete, etc. as abstract operations, since their implementations depends on the object class to be manipulated. Presentation layer design Certainly, from a class diagram or an entity-relationship schema we can completely derive a three-tier design. As users communicate with the system through the Presentation layer, we must put at this level a set of classes that fulfil the common requirements mentioned in Section 1. For example: A screen for individually showing and manipulating (create, delete, update, print) the data of every persistent class, including the navigation across related data. A screen for showing lists of persistent objects. Of course, an initial screen with some menus, buttons or other widgets to go to the other screens. Domain layer design Any action performed by the user on one screen is translated into a message which is passed to the respective object at the Domain layer (i.e.: every instance of a class at the Presentation layer knows an object at the Domain). Changes in the status of these objects is communicated to the Presentation layer through observers, what allows the absolute independence of domain objects from their respective screens. In this manner, the same set of classes is valid to work with applets and with frames (for example). Persistent objects must be capable of being materialized (instantiated from the information saved in the database), inserted, deleted and updated. For this goal, persistent classes must include at least a constructor to materialize, and the insert, delete and update methods. Storage layer design At the Storage layer we put some classes which allow the access of the Domain classes to the database. There are also several patterns to guarantee this access, as the use of a Broker, a Facade or even the direct access from Domain classes to the database. Spite the database system is typically an product acquired to an external supplier, it can be also considered as an element of the Storage layer. In the systems we are describing, the class diagram of persistent classes can be used as the conceptual diagram for designing the database, and there exist some patterns for doing the transformation, as the one class, one table, one inheritance tree, one table or one inheritance path, one table [6]. An example as starting point For illustrating our approach and space saving, we will use the single class diagram shown in Figure 1: it shows that a person may have many cars. Figure 1. Class diagram taken as example. The minimal set of required functionalities for this system is: Management of persons and cars. Users need screens to view cards of both persons and screens, with buttons for inserting, deleting, etc. Possibility of listing the cars of a person. Possibility of navigate from a car to its owner. A main screen to go to the listing screens of persons and cars and, by selecting an item in the list, to its respective card screen. Figure 2 illustrates these functionalities, from the Presentation layer point of view. 2

3 TRANSFORMATION OF STATIC VIEWS Taking into account the considerations made in the previous section, from a Domain diagram we obtain a fixed Presentation diagram, which has a card screen per

3 3 TRANSFORMATION OF STATIC VIEWS Taking into account the considerations made in the previous section, from a Domain diagram we obtain a fixed Presentation diagram, which has a card screen per persistent class, a screen for lists and a main screen. In the other side, depending on the pattern used for transforming the class diagram to the relational schema (see subsection Storage layer design ), we will get a different type of database design; but if we always use a same pattern, a totally predictable database design will be obtained. With the exposed rules, the simple existence of the «persistent» stereotype in persistent classes is required to generate elements in both sides of the Domain layer: they do not need to specify persistent methods, since they will incorporate all of them. Obtaining the Presentation layer Formally, the generation of the Presentation layer from the Domain one is adjusted to the following equations. By reasons of space, we offer a reduced version of them: Let be: D a class diagram which consists of persistent classes; C the set of classes of D; R the set of relationships among classes in C: D= (C, R)=({(c1, r1), (c2, r2)... (cn, rn)}, R) A class is denoted as the pair (ci, ri), where ci represents the class itself, and ri the set of relationships of this class Figure 2. Required navigation among screens. 3 with others. The Presentation layer, P, is obtained as a function of the Domain layer: P=f(D)={m, s} f(c1, r1) f(c2, r2)... f(cn, rn) m is the Main screen; s is the screen for listings. f(ci, )=screen with (1) a reference to an instance of ci, plus (2) an adequate set of widgets for all fields in ci whose type is a basic data type, plus (3) a set of widgets for sending messages to the associated instance of ci. f(ci, ri )=f(ci, ) { widgets for navigating to related objects (4)} With (1), we denote that the screen knows a persistent object at the domain tier. The adequate widgets mentioned in (2) mean that, for example, textfields or textareas are used for Strings fields, checkboxes for booleans, etc. The set of widgets in (3) could be the buttons or the option menus that the users presses to delete, save, etc. persistent objects (see Figure 2). The widgets for navigating mentioned in (4) could consist of a menu for going to the records in other tables related to the current object (for example, the Relationships menu of Figure 2). Function f can have different implementations for

4 different programming languages, different development environments and different types of screens (frames and applets, for example). Obtaining the Storage layer The storage layer can be obtained using any of the patterns mentioned in Section 2. This transformation can also be formally specified using equations. Assigning and code generation of responsibilities As we noted in Section 2, several patterns can be used to assign persistence responsibilities. For example, if the Person class of Figure 1 is in charge of its persistence, its insert method could be (supposing Java code, embedded SQL and the use of a database broker): public void insert() throws Exception { } String SQL= Insert into Person + (SSN, Name, Age) values ( + mpkssn+, + mname +, + mage + ); ; Broker.insert(SQL); If the class delegates these operations to an associated class, its code would be: public void insert(person p) throws Exception { } String SQL= Insert into Person + (SSN, Name, Age) values ( + p.getssn()+, + p.getname() +, + p.getage() + ); ; Broker.insert(SQL); But also the pattern used for doing the transformation to the relational schema has strong influence on the code of the persistent methods, depending overall on the presence or absence of inheritance: so, for example, when there is inheritance and every class has been transformed in a table, there are integrity restrictions that, in some moments, obligate to insert records in more than one table. An example of this is shown in Figure 3: for inserting an employee or a student, it must exist previously in the Persons table and, then, two insertions would be needed in one transaction. The situation is absolutely different (and also the code of the persistent methods), if all the inheritance tree is translated into just a table with the One inheritance tree, one table, or to two or three tables with the One inheritance path, one table pattern (in this latest case, the fact that Person is or is not abstract would have also influence). These politics for assigning responsibilities, and the needed code to be generated, can be also mathematically expressed. Figure 3. A relational schema obtained from the "One class, one table" pattern. 4 AN ARCHITECTURE FOR GENERATING CODE We have developed a set of tools for generating code from the static view of a system, supposing it will have the minimal requirements of Section 1. We start from the basis of that any static view of a system can be transformed into an instance of the following class diagram (Figure 4): Figure 4. General diagram for describing systems. 4

5 In fact, applying transformation rules, the class diagram of our little example (Figure 1) would be an instance of this latest. Inside this instance, there would be: One instance of the System class. Two instances of the Class class (Person and Car). Six instances of the Field class (three corresponding to Person and three to Car). With other different transformation rules, a relational schema can be also be transformed in an instance of that diagram. Storage layers; also ideally, the tool should generate the code in any programming language, for any development environment (because, for example, the Visual Café Java environment is not capable of interpreting frames, applets, etc. of Forte, and vice-versa) and for any database management system. All these characteristics are obtained with our tool, since we have provided it with a set of interfaces which are implemented by a variety of little tools. Figure 5 shows the general architecture of the tool. To generate, for example, Java code for the Presentation tier that will be used in Visual Café, we only need to instantiate the classes that implement the IPresentationClass and IPresentationField interfaces for Visual Café. Figure 6 shows the classes that implement the interfaces of Class : Code for the Presentation layer depends on the environment and on the programming language. Code for the Domain layer depends on the language and on the pattern used to assign responsibilities. The Storage layer depends on the RDBMS used. In a future, we will add implementations for this interface which allow to create the database following the three transformations patterns mentioned in subsection Storage layer design of Section 2. Figure 5. Macroarchitecture of the tool for generating code. Required interfaces Once we have build one instance of the diagram of Figure 4, we can execute its generatecode method on the System class to generate the desired code. Ideally, this execution should produce code for the Presentation, Domain and 5 Figure 6. Classes that implement interfaces for "Class". Interfaces implemented The tool is capable of building instances of its class diagram (Figure 5) from some formats:

6 Rational Rose. Microsoft Access XML files. This means that the tool implements three interfaces for data acquisition and transformation. 5 CONCLUSIONS AND FUTURE LINES OF WORK We have presented a method for generating code from the static view of a system, as well as the architecture of a tool that supports it. The method is based on some common requirements that are generally desired by users. Currently, we have three lines of work opened: The construction of more classes which implement the three interfaces required by the tool. The addition of more formats to import data. In this sense, we are evaluating some CASE tools for entityrelationship modeling in order to process their diagrams and generate code. As some authors have noted a similar expressiveness of the Objectorientation and the Extended Entity-Relationship notation [6], we expect that this kind of diagrams is also valid to generate code. The formalization of all transformation methods using mathematical notation. The collection and formalization of more common requirements, in order to generate automatically code for them. ACKNOWLEDGEMENTS This work is partially supported by the MPM project (Mejora del Proceso de Mantenimiento; Iniciativa ATYCA, Ministerio de Industria y Energía, Spain). REFERENCES 1. Brown, K. and Whitenack, B. (1996). Pattern Languages of Program Design, vol. 2. Reading, MA: Addisson-Wesley. 2. Broy, M. (2001). Toward a Mathematical Foundation of software Engineering Methods. IEEE Trans. Software Eng., 27(1), Heinckiens, P.M. (1998). Building Scalable Database Applications, Addison-Wesley. 4. Keller, W. (1997). Mapping objects to tables. A pattern languages. Proceedings of the 1997 European Pattern Languages of Programming Conference, Irrsee, Germany. 5. Leavit, N. (2000). Whatever happened to Object- Oriented Databases? Computer, 33(8), Object Architects. On-line at (March 7, 2001) Shoval, P. and Shiran, S. (1997). Entity-relationship and object-oriented data modeling-an experimental comparison of design quality. Data & Knowledge Engineering, 21(3),

Reflective CRUD (RCRUD: Reflective Create, Read, Update & Delete)

Abstract Reflective CRUD (RCRUD: Reflective Create, Read, Update & Delete) Macario Polo, Mario Piattini and Francisco Ruiz University of Castilla-La Mancha Ronda de Calatrava, 5 13071-Ciudad Real (Spain)