WP3 Technologies and methods for Web applications

Transcription

1 WP3 Technologies and methods for Web applications Introduction The primary goal of work package WP3 - Technologies and methods for Web applications - is the definition, design, and implementation of the consolidate repository infrastructure for the Virtual Campus project, as well as the deployment of all the content management applications required to enter information in the repository at all the levels of interaction described in the Virtual Campus conceptual model. This document describes our contribution to the project. The final repository has been designed by integrating several databases that model the peculiar and somehow orthogonal dimensions of the Virtual Campus project. A unique data repository increases performances, guarantees data integrity, and simplifies data maintenance. Note that this unique database provides access to all the data which are necessary to coordinate several different applications in a centralized way. In addition to the repository, we designed a collection of Web site views for the delivery and management of LOs, with particular emphasis on various personalization capabilities. These Web site views include a large number of Web pages for populating, accessing, and managing the repository data. Dynamic Web pages have been generated using WebRatio ( a tool capable of generating ASP and JSP pages starting from an abstract description in a declarative language, called WebML ( Then we implemented the database component (based on MS SQL Server) and the vertical Web portal (based on MS IIS). This document is focused upon the schema of the global repository, rather than detailing the Web interfaces. This choice is motivated by the fact that the repository is indeed an important aspect of the Virtual Campus project and a key to understand the system s functionality. The Web interfaces are much easier to demonstrate by means of the live fruition of the authoring and administration environment, or at least through a demo, rather than by a written description.

2 DB Schema Figure 1: Entity-Relationship description of the schema of the entire repository Figure 1 shows the Entity-Relationship schema of the entire repository. This database allows to store any information relevant to Virtual Campus, in a way that is compliant with its conceptual model. The different levels of abstraction at which the LOs are described in the conceptual model and the corresponding sets of metadata have been integrated in one database. Metadata (as the Virtual Campus conceptual model states) are described according to an extension of the IEEE LOM standard, called VC LOM. The designed database is very flexible: it stores all LO metadata in a unique table (LO), that describes the objects at different levels of abstraction. This centralized approach facilitates all updates and corrections. The tables in the bottom left corner in Figure 1 store the dictionary of the Virtual Campus, containing all the possible values of predefined fields, just making the repository extensible: every new term can be simply obtained by adding new tuples to these tables. We will now analyse the database in more detail, to explain how it is used in the project.

3 Figure 2: The reusable level Figure 2 shows the portion of the database that supports the reusable level. The most important table is LO. It contains all and sole the attributes described in the abstract model. LO is unique for all the levels at which Los can be described. Indeed, the metadata of the same LO, described at two different levels, are the same (if specified in both descriptions); the use of a unique table also simplifies its maintenance and facilitates the search for LOs in the repository, as the search addresses one table only. The four tables Alternative, Requirement, OnFailure, and Reference (also shown in Figure 2) respectively represent the IsAlternativeTo, Requires, RequiresOnFailure, and References semantic relationships between LOs, described in the Virtual Campus conceptual model (as well as their inverses CanBeReplacedBy, IsRequiredBy, IsRequiredOnFailureBy, and IsReferencedBy). Such

4 relationships are context dependent, since two LOs can be in a particular relationship within a third LO, which must be a Complex LO and must contain both the previously mentioned LOs, and the same two LOs can be in a different relationship (or in no relationship at all) with respect to another Complex LO that contains both these LOs. Indeed, according the abstract description of the Virtual Campus conceptual model, every relationship is visualized as an arc that links two nodes, and these nodes are contained in a complex LO. The tables contain a field (fromlo) for the source LO, a field (tolo) for the target LO and a third field (contextlo) for the LO inside which the relationship holds. The Keyword table contains keywords related to LOs; note that a keyword can be associated to more than one LO, and a LO can be described by means of more than one keyword. Figure 3: The didactic level

5 Figure 3 shows the portion of the database that supports the didactic level. The PathStep relationship represents all the precedence constraints of the didactic level. Each tuple in this table represents a step in the possible alternative itineraries along which a LO can be executed. Two nullable fields ( suggestion and constraint ) may add information about the kind of constraint the relationship expresses, such as the fact that a step is mandatory or simply preferred. Using a unique table to store all the paths dramatically increase the performance of the entire system, due to the fact that the search for the next step can be addressed to the same table, with one query only. This performance optimization doesn t limit the expressiveness: all possible paths can be represented with labelled graphs, where the semantics of the arcs is captured by their labels. Each arc of these graphs directly maps to a tuple (in table PathStep) containing a field (fromlo) for the source LO, a field (tolo) for the target LO, a field (contextlo) for the LO inside which the relationship holds, and two fields for the information contained into the arc label (as labels can express suggestions or constraints). Figure 4: The fruition level

6 Figure 4 shows the portion of the database that supports the fruition level. The core of this part is the Course table. Each course is a LO, and the metadata of the corresponding LO are stored in the LO table, to which the Course table is connected by means of a relationship. Each course is associated to some teachers, some tutors, some learners, and some exams (exams are also LOs). Courses are associated to lectures and announcements as well. Figure 5: Admin tables Figure 5 includes tables which are necessary for the administration of Virtual Campus. The table User stores information to manage the authentication of the users. Table RoleWrtLO is used to manage the specific permissions of each user with respect to different LOs. Table Credentials contains information about the precedence constraints of LOs (preconditions and postconditions); each credential can be a precondition to obtain access to a specific LO or can be a synthetic description of the skills that a LO provides (a postcondition), and these two roles are described within the two different relationships that connect the Credentials table to the LO table. The timeconstraints field represents the temporal aspects (such as the duration) of the credential, as some skills do not last forever, once acquired. Table Content stores the information about the contents of LOs, i.e. the raw material to which the metadata are associated (to form a complete LO). Finally, tables Forum and Messages store data about the forum of Virtual Campus. These data support the monitoring and evaluation activities, performed by the agents designed and developed within the WP1 work package.

7 Figure 6: System requirements Table SystemRequirement (shown in Figure 6) describes the minimal hardware and software requirements for each LO to be accessed. Note that this table is connected to the LO table by a relationship, whose cardinality is [0,N] on LO side. This is due to the fact that the minimal requirements may be different on different platforms. Site views The repository is fully manageable through a collection of site views, one for each category of user (according to the roles presented in the Virtual Campus conceptual model), allowing each of them to view and maintain their own relevant data in a very easy way. This site has been fully generated using WebRatio ( a tool capable of generating ASP and JSP pages starting from an abstract description in a purpose-specific language, WebML ( The Web Modeling Language (WebML) is a visual notation for specifying complex Web applications at the conceptual level. WebML describes a Web application using several orthogonal dimensions, including: The organization of data (structure model) The organization of the hypertextual front-end into site views, areas, and pages (composition model) The topology of explicit and implicit links between pages, areas, and site views (navigation model) The business components that define the application's behaviour (operation model) All the concepts of WebML are associated with a graphic notation, which makes Web modelling natural also for non-technical people. At the same time, WebML is a formal language that can be effectively used for generating a site implementation in any specific architectural setting. WebML can also be regarded as a UML profile for Web application developers. WebML concepts can be naturally expressed using UML class diagrams and used in conjunction with traditional UML object-oriented modelling to extend model-driven analysis and design to the realm of Web front-ends.

8 In order to enable the separation of roles and of concerns, the authoring process leading to the development of LOs is structured in different site views. Note that all site views work on the same data, but no conflict is possible, due to an accurate design of the diverse roles, among which different and complementary authoring responsibilities have been distributed. Figure 7: WebML specification of the Home Page for administrators Administration site view The WebML specification of one of the home page for Administrators is exemplified in Figure 8. The administration site view provides pages to manage and organize the access rights of all the other users of Virtual Campus. Administrators can add new users, they can assign them one or more roles, they can assign teachers and students to courses, and they can also perform many similar management activities. Author site view The author site view allows authors to define contents: some pages allow to build Reusable LOs starting from raw materials and adding them appropriate metadata. The set of metadata has been divided in two part: a mandatory set, to be specified in a page that the author is not allowed to skip during the authoring process, and an optional set, whose specification is possible from a page which is linked by the mandatory one. These data can be modified at any time, through the page shown in Figure 8. Authors can also create Atomic LOs by simply giving to existing materials a new metadata description. Materials can thus be stored, searched and reused in the design of course. Moreover, authors can assemble pre-existent LOs into new Complex LOs. This authoring process is supported by a graphical interface, with which the relationships between the LOs are instantiated by drawing arcs (to recall the visual language used in the Virtual Campus conceptual model). The resulting graphs are automatically converted into the relational representation described above. The composition and the properties of these newly generated LOs can be modified and maintained after the time of their creation by means of the management interface shown in Figure 9.

9 Figure 8: Modifying LO metadata Figure 9: Management (modification) of existing LOs Teacher site view The teacher site view offers the possibility to extend the set of LOs creating new Complex LOs starting from existing Complex LOs and adapting them for special needs. Teachers can also create Didactic LOs: these are specializations of Reusable LOs.

10 Fig 10: Choosing LO Organizer site view The organizer site view is devoted to the management of fruition LOs. Before a didactic LO becomes available for fruition, further details need to be added concerning the specific edition of a course or a lesson where they are used. Examples are the names of students who will attend the course, the course calendar, etc. A crucial aspect of this site view is the possibility to search LOs in the repository by their keywords or by their preconditions or postconditions. This last feature is intended to help the teachers to organise a sequence of LOs in the construction of a self contained chain of knowledge. A snapshot of the search interface is given in Figure 11.

11 Figure 11: Search for LOs based on their postconditions Fruition site view The fruition site view contains all the pages through which the students can access the LOs and thus attend the courses they are signed in for. Lessons created by teachers (and specialized by the contribution of organizers) are shown to students. When students start the fruition of a LO the system shows them all possible navigation paths. More specifically, a student starts from the entry point (the first step of a LO) and then navigates it, depending on both his preferences (when allowed) and the result of tests, if any. As long as the exploration goes on, only the available (or suitable) choices are proposed to the user, so as to implement a sort of navigation of the LO. Forum site view The forum site view is composed of several pages that implement the Forum functionalities for Virtual Campus. Forums allow on-line asynchronous communication between users. This service gives the possibility to post and organise messages in threads of discussion on specific topics. Forums are provided to support an enhanced co-operation between all the actors of the whole learning environment: the forum service might support asynchronous discussion between teachers and their students on a specific subject, among lab users (or students engaged in a practical laboratory activity), etc.; on the other hand, authors and teachers can use forums to cooperate in providing new contents for Virtual Campus.