As reported in the figure below, the WebML approach to the development of Web applications consists of different phases that must be applied in an iterative and incremental manner. The process undergoes several cycles, each cycle producing a prototype or a partial version of the application that allows conducting testing and evaluation since the early development phases.
Out of the entire process, data and hypertext design are the activities most influenced by the adoption of WebML.
Our approach to data design does not aim at replacing the general-purpose guidelines for conceptual data modeling, but simply extends them with a few specific rules of thumb, which may help designing data “for the Web”. Indeed, data publishing and content management applications have some regularities and peculiarities, which can be exploited in the design of data. Recognizing them may help the data designer organize his work in a systematic way, which normally results into more consistent data schemas. Therefore, our method stresses the distinct roles played by objects, and use this distinction to propose a sequence of steps for assembling the data schema of a Web application.
After data design, hypertext design proceeds top-down:
- A first coarse design activity aims at producing a first high-level specification of site views that exploits an informal textual notation to express visibility level for site view areas (landmark, default or internal areas), and specify the area content in terms of entities and relationships of the data schema.
In doing so, special attention is paid to the role played by the various data elements, which may be exploited for accessing information, for publishing the content of core objects, for interconnecting core objects, or for personalization purposes.
- Detailed design is a top-down refinement of coarse design, in which the draft schemas of site views are progressively revised until they become collections of WebML pages and units compliant with the user’s requirements. Detailed design exploits WebML hypertext sub-schemas, which are "canonical" configurations of pages and units, built on top of the core, access, interconnection, and personalization sub-schemas.
|