Volgende: bcoWeb compliant web services Omhoog: Technical implementation of the Vorige: Internet-based software development Inhoudsopgave
Goal of bcoWeb is to allow multiple people to collaboratively edit the same FU/TS-based Ontology. The chosen technical basis is implementation in Python/Zope/Plone and as a web-based application, both explained in the previous section.
First, the UML model of the application is introduced, followed by the application structure. Third, the web services capability of bcoWeb itself. See also the next chapter for a walk-trough of the application.
The open source application source code is available at [116], licensed under the GPL.
This section discusses the inner workings of the bcoWeb application by looking at the UML model, figure 7.2. From this UML model a large part of the web application was generated. As this model is used as the starting point for a code generator, the needs (and occasionally wards) of the code generator weigh more heavily than 100% neat model correctness.
 |
The starting point is the object library (Ontology9.3), which can contain all other items. It functions as a folder in which the other items can be placed. Main inhabitants are the functional unit and the technical solution. The FU/TS-typical fulfills and consists of relations are implemented on the technical solution, which means that--in the generated user interface--the technical solution is the place where you can add or change these relations.
Both collection (functional unit set) and abstract technical solution are implemented as subfolders of the object library. The collection is just a grouping mechanism for functional units, grouping them under one common name. Abstract technical solutions can contain technical solutions, but implementation-technical also inherit from (sic) the technical solution class. This provides an easy and intuitive way to associate technical solutions with an abstract technical solution, simply by putting the solution in the abstract's folder. The fulfills and consists of relations from the abstract technical solution to functional units are inherited by the contained technical solution.
Each of the UML classes gets a basic web page auto-generated by the Plone mechanism9.4. For most of the classes, small changes were made by adding explanations and filtering some information.
The classes, implementing the core functionality, are stored in the ZODB. In this manner, they are both available in the running Zope web server and stored reliably for later use. This is a real advantage of the ZODB, and it does away with the need for a separate storage layer. In this sense, the ZODB is one of the few object databases seeing real use.
For visualising the running objects, Zope page templates are used. An example of such a template is provided in figure 7.3. The Zope templating system provides a clean way of separating the actual object's code and the visualisation, always a goal of good programming.
For extra actions that do not really belong in the core classes, the possibility exists to add small Python scripts that can be called on the classes. An example is provided that calculates the FU/TS objects displayed on the starting pages of an object library (see figure 7.4). The starting page is meant to be a good starting point for browsing through the object library. The best starting points seem to be the top-level items in the FU/TS hierarchy. Such an item is a functional unit that is not contained by a technical solution. So the database must be searched for such functional units. Afterwards, they should be sorted with the functional unit having the most technical solutions first, as that will put the least-developed functional units near the end.
| 6#6 |
Support for NG Internet is build into bcoWeb. The most important feature is the ability to download all contents of an Ontology as an RDF/OWL file. This file contains the functional units, technical solutions, their names and their fulfills/consist_of relations. This way, every bcoWeb Ontology is available in machine-readable format on the Internet.
A possibility added in a later stage was to download information on the individual objects, so that a client application could rapidly get at the information it needs without needing to download the entire Ontology. For some classes of applications, this can make all the difference. Just imagine the possibilities presented to mobile phone applications in this way.
