T Technical specification: FASTAXON Group: Muuntaja

Transcription

1 T Technical specification: FASTAXON Group: Muuntaja 0

2 Version History Owner of the document: All members of the group Muuntaja. Version Date Author(s) Description Pekka Korhonen First Draft Pekka Korhonen GUI chapter added Pekka Korhonen Description of database added Pekka Korhonen Database schema and ER-diagram added Pekka Korhonen Complemented Esko Simpanen Finalized for release Pekka Korhonen Chapters 3.3 and 4 updated Esko Simpanen Finalized for I2 release. 1

3 Contents 1. Introduction Purpose of the document Terminology and definitions References Document overview System overview Application description Software environment Hardware environment Architecturally significant quality requirements System architecture Main principles of design Design patterns Database architecture User interface Designer GUI Object indexer GUI End User GUI Modules Class diagram Responsibilities of the classes Error handling

4 1. Introduction 1.1 Purpose of the document Purpose of this document is to define architecture of the FASTAXON-product. Chosen architecture solution is based on the requirement document and discussions with customer. 1.2 Terminology and definitions Table 1 shows basic terminology needed to understand this document. Table 1. Terminology and definitions. Term API J2SE J2EE JDBC SQL JRE JSP HTML Definition Application Programming Interface Java 2 SDK Standard Edition Java 2 SDK Enterprise Edition Java Database Connectivity Structured Query Language Java Runtime Environment Java Server Pages HyperText Markup Language 1.3 References [1] Haikala, Märijärvi, Ohjelmistotuotanto, 6. edition, Talentum Media, [2] Mika Hakkarainen, User Requirements: FASTAXON, [3] Yannis Tzitzikas, FASTAXON, A fast method for building taxonomies,

5 1.4 Document overview Chapter 2 describes the application and defines environment of the product from software and hardware point of view. Chapter 3 contains main principles of the design and defines main architecture for the system. Decisions of the architecture also rationalized and database described in this chapter. Chapter 4 defines user interface. Chapter 5 gives detailed information of the class hierarchy of the system. Class diagram presented here and main responsibilities of the classes described. Chapter 6 defines methods for error handling. 4

6 2. System overview 2.1 Application description Purpose of FASTAXON project is to develop a system, which allows building, maintaining and browsing taxonomies by exploiting the faceted classification paradigm and Compound Terms Composition Algebra. System should implement both administration and end user interfaces. FASTAXON is a part of research project in VTT. Main goal is to build a prototype system for demonstrating and proofing usability and flexibility of the Compound Terms Composition Algebra. Requirements are described in more detail in Requirement Specification [2]. Stakeholders and concerns Designers: They can create and update entire projects and have full rights to a whole system. Object indexers: They can only create and maintain object-bases, i.e. they can browse the navigation tree (of an existing project created by designer) and index objects with compound terms. End users: They can only browse the navigation tree of an existing object-base of an existing project created by Designer and Object Indexer. Using the navigation tree, end users try to locate relevant object (information) of their interest. 2.2 Software environment The basic requirement for the system is that it must operate on Windows 2000 operating system. Because the software project will be published as an open source project, architecture should choose so that developing and running of the product will be possible also in other platform in future. Java is used as developing environment. In this way the product will be platform indepent and can be run any operating system supported by Java and JRE. The product will be implemented as client/server system by dynamic HTML-pages Because that, WWW-server and application server are needed. Apache will be used as WWW-server and open source Tomcat as application server, but it must be possible to change any other application server if will be needed in future. On server side also J2EE is needed. 5

7 Persistence of the data is solved by SQL based ralation database. Open source MySql sofware is used as database management system and it is used by JDBC-driver. Database system can be easily changed in future. Only a new driver is required for a new database system In user end, only to be needed is operation system and Web-browser supported by Java. 2.3 Hardware environment Primary use and development environment is PC-computers, but as mentioned earlier, implementation will be platform independent and software should be easily portable also to other environments. 2.4 Architecturally significant quality requirements System must support at least 10 end users concurrent. The system should be developed in modular way. All modules have to be replaceable and have complete API. The customer would like to further develop the system. 3. System architecture 3.1 Main principles of design There are several approaches to implement the client/server system. After strict evaluation, fully web based solution was selected. Other seriously taken option was stand-alone application in designer module. Following benefits helped choice of fully web based system: No installations in the client end. Only web browser is required. One application serves many clients. J2EE technique is standardized and widely used. True platform independence. Parallel processing. 6

8 Number of applications and components. Figure 1. Components of the system. Database server and Web server are located physically in same place, but they have JDBC as API so that they can be separated easily to different machines. User interface will be implemented by dynamic HTML. JSP and Servlet technologies are used in implementation. 7

9 3.2 Design patterns Model-View-Controller One of the user requirements is modularity and system must implement in a way that any component can be changed easily. Modularity helps also in developing process, because implementation work can divide easier for many developers. Main design pattern used in the system is Model-View-Controller (MVC). That means the system is divided to three independent parts and each of them have a clear API. Responsibilities of the component described below: Model: Represents the underlying data and business logic in one place. View: The user interface, things the user can see and respond to. Represents a window into the model and there can be many of these. Controller: Connects the model and view. Used to communicating between model and view. The Model-View-Controller ("MVC") design pattern decouples the model from its view, enabling loose coupling and the ability to change one without affecting the other. 8

10 Figure 2. MVC-design pattern. Benefits of MVC: Promotes code reuse The purpose of the model is to provide business logic and data access in one place This logic can be reused in many applications at the same time without the need for any extra coding Reduces development time The model, view and controller can be development in parallel More maintainable 9

11 The view can be changed without affecting the model. The model can be changed without affecting the view. 3.3 Database architecture This chapter describes the used database, database schema structure and its implementation principles Used database As system requirements state our customer wants to publish the results of the project under VTT s open source licence. This limits our scope in selection of database management system (DBMS). The selected DBMS is relational database called mysql. The suitability of selection was affirmed during architecture prototyping. Even though mysql is mainly used in small/medium sized applications and it s no where near to performance of the commercial databases and some crucial features like transactions have been in use in it only for short time it is very competitive and by far the best from available open source RDBMS solutions. MySQL offers all features needed in development. It has also free online documentation that will help the development Database schema designing Due the iterative and incremental nature of used development process the database structure will evolve along with developed code. Crucial point in DB schema design is to avoid designing database too much up front. The data model design is done with co-operation with the class model design. This does not mean that one of them drives the other. The data model may and most probably will differ from class model if performance, maintainability or any other quality factors require so Database implementation During the development the database is implemented following principles. All tables are InnoDB type to enable use of foreign key constraints 10

12 All possible row deletes are implemented using ON DELETE CASCADE clause in foreign key constraints. All primary and foreign keys will be indexed. Other indexes will be created only if system performance requires them. Systematic DB performance tuning is done only if it is needed. DB performance tuning is done only if adequate test material, which proofs the systems bad performance, is available. Developers and testers must be able to restore the development /test database and its contents with one command ER-diagram 11

13 3.3.5 Tables of the database Name (Table/Column) USER Column type Indexed colum Key type Description ID INTEGER Id of the user USERNAME CHAR(255) Username of the user PASSWORD CHAR(255) Password of the user ROLES INTEGER Userroles of the user PROJECT ID INTEGER PK Id of the project NAME CHAR(255) Name of the project USERID INTEGER PK,FK (*) Id of the user CREATOR CHAR(255) Name of the project creator CREATED DATETIME Time when project was created MODIFIER CHAR(255) Last modifier of the project MODIFIED DATETIME Time when project was last modified FINALID INTEGER Id of the projects final expression TAXONOMY ID INTEGER X Id of the project PID INTEGER X PK,FK (*) ID of the project NAME CHAR(255) PK Name of the taxonomy CREATOR CHAR(255) Name of the taxonomy creator CREATED DATETIME Time when taxonomy was created MODIFIER CHAR(255) Last modifier of the taxonomy MODIFIED DATETIME Time when taxonomy was last modified FACET 12

14 ID INTEGER X Id of the facet PID INTEGER X PK,FK (*) Id of the facet NAME CHAR(255) PK Name of the facet TID INTEGER X FK Id of the facet CREATOR CHAR(255) Name of the facet creator CREATED DATETIME Time when facet was created MODIFIER CHAR(255) Last modifier of the facet MODIFIED DATETIME Time when facet was last modified OPERATIONTYPE ID INTEGER Id of the operationtype NAME CHAR(10) Name of the operationtype SUBEXPRESSION ID INTEGER X Id of the subexpression PID INTEGER X PK,FK (*) Id of the subexpression NAME CHAR(255) PK Name of the subexpression CREATOR CHAR(255) Name of the subexpression creator CREATED DATETIME Time when subexpression was created MODIFIER CHAR(255) Last modifier of the subexpression MODIFIED DATETIME Time when subexpression was last modified OPERAND ID INTEGER Id of the operand SUBEXPID INTEGER X PK,FK (*) Id of the subexpression OPTYPE INTEGER X PK Id of the operationtype OPERANDID INTEGER X PK Id of the operand (Note!: operandid <0 means ref. to this table, operandid > 0 ref. to facet table TERM 13

15 ID INTEGER X Id of the term TID INTEGER X PK,FK (*) ID of the taxonomy PARENTID INTEGER X PK ID of the parentterm NAME CHAR(255) PK Name of the term PARAMETER SUBEXPID INTEGER X PK,FK (*) Id of the subexpression PARNUM INTEGER X PK TERMID INTEGER X PK Id of the term OBJECT ID INTEGER X Id of the object PID INTEGER X PK,FK (*) Id of the project OBJECT CHAR(255) PK Name of the object DIGEST CHAR(20) X? OBJECT_TERM_SET ID INTEGER X PK,FK (*) Id of the object TERMID INTEGER X PK,FK (*) Id of the term Indexed column: X=column is indexed Key types: PK=primary key, FK=foreign key,fk (*) =Foreign keys having ON CASCEDE DELETE clause 4. User interface All user interfaces are implemented in Internet Explorer browser. Other browsers may work but they are not officially supported during this project (i.e. support implementation is left for further development). User interfaces are pure views of the model and for that reason does not contain internal states to hold project related information. Every changes like adding new taxonomy to the project requires saving the data first to the model and then updating the view based on that change. End user and Object indexer GUI's are as pure HTML as possible but in Designer GUI also DHTML is used to add dynamic operations and increase usability. 14

16 The navigation diagrams do not show the working flow, states of the procedure or exact content of the view i.e. content may change dynamically or some parts should be disabled in certain situation. These diagrams are used as a base information diagrams of the GUI implementation. 4.1 Designer GUI Designer GUI is used to manage projects. The solution is frame-based view (Figure 3) and this allows one view of the GUI to be active all the time. The navigation diagram of the Designer GUI is described in Figure 4. Figure 3 : View layout (draft) First user has to login to the system (1 Login Screen). After successful login, the frame-based view is generated. The left frame if menu view and right is working area. From menu, user is able to open the project or create new one and select the part of the project he/she would like to manage. Some of the views can be also pop-up windows. 15

17 16

18 Figure 4 : Designer GUI navigation diagram 4.2 Object indexer GUI Object Indexer GUI is used only for managing object base of the project. The implementation is as pure HTML as possible. The solution can be based on frames like in Figure 3 or can be implemented as a single view. The Figure 5 describes the navigation diagram. Figure 5: Object indexer navigation diagram The system requires login procedure before object base management is allowed. After successful login the Object Indexer GUI is created. 17

19 4.3 End User GUI End user GUI is used only to browse navigation tree. There is no login procedure. The navigation diagram is described in Figure 6. The view "2 Select node" can be 'dynamic' i.e. the view can change based on the users selection when browsing the tree. The view can contain the full navigation tree or part of it and the implementation decision is left for developers. Figure 6 : End user navigation diagram 18

20 5. Modules 5.1 Class diagram The following diagram represents class hierarchy of the system. Because iterative and incremental developing process is in use, only architecturally significant classes are defined in this phase. In implementation phase 2 this diagram will be completed. Figure 7 : Class diagram of the system. 5.2 Responsibilities of the classes ApplicationContext The class is a common environment of the software. There is only one instance of this class and it is implemented by singleton-pattern. Designer 19

21 The class for designers. By this class a user has fully rights to the database. The user can create projects and expressions, modify and delete them, index objects and of course browse navigation tree. Indexer The class for object indexers. The indexer has not so much rights as designer but he can associate real objects (e.g. www-links) to the taxonomy tree, and browse the tree. Context A repository of the projects. Main responsibility of the class is to be interface to all projects. The user can maintain all his own projects by this class. Project Includes all data is needed for creation and modification of the expression. A designer can have several projects and has fully rights to them, but not to the projects that are created by other designers. ObjectDBEditor Responsibility of the class is to manage the database of the objects. The primary users of the class are object indexers. Expression The class contains all needed data for present expression and methods to maintain them. Taxonomy Taxonomy consists of many terms that can be associated to real objects. NavigationTree The class is responsible for maintain a whole structure of the object tree in a way that the end user can easily and fast enough to browse the tree. 6. Error handling Java exceptions are used in error handling. All database related errors are passed to model in a form of SQL error messages via used JDBC interface. The model is responsible of transforming 20

22 these errors to more understandable form before they are presented to user in UI. Errors are handled by UI-classes (servlets). 21