Document Product Lines (DPL) is a document engineering methodology that applies product-line engineering principles to the generation of documents in high variability contexts and with high reuse of components. Instead of standalone documents, DPL promotes the de nition of families of documents where the members share some common content while di er in other parts. The key for the de nition is the availability of a collection of content assets which can be parameterized and instantiated at document generation time. In this demonstration, we show the features of the DPL framework (DPLfw), the tool that supports DPL. DPLfw implements the domain engineering and application engineering stages of typical product line engineering approaches, supports di erent asset repositories, and generates customized documents in di erent output formats. We use the case study of the generation of customized emergency plans in a University campus [http://youtu.be/ueKGfmfkyI0].
The concept of document has changed in last decades from the classical printed
artifact to a purposeful and self-contained collection of information in a
technology-neutral way [
Customization can be made in three dimensions, namely content, structure
and presentation. Speci cally, content customization has been tackled from two
di erent perspectives. On the one hand, proposals on Variable Data Printing
(VDP) use variables within documents that are used as placeholders for
content that are replaced with values to generate customized documents. These
approaches are mostly XML-based [
The Document Product Lines approach (DPL) [
The Document Product Lines methodology DPL is a method for the generation of variable content documents. As in SPLE, the DPL process is the concatenation of two main subprocesses, namely Domain Engineering and Application Engineering. Fig. 1 shows the most relevant tasks and artifacts in each subprocess using the BPMN notation.
The goal of the Domain Engineering is to de ne a family of documents and related artifacts. A family is a set of documents that share some mandatory content while di er in other optional content. To enforce reuse, the content of a
Fig. 1. DPL-based Document Generation Process family of documents is structured via a document feature model. In the Analyse Document Family task, a domain engineer speci es the documents in terms of features and feature attributes. The result is a document feature model including mandatory, optional, alternative features and their corresponding attributes (if applicable). In the Design Document Family task, the generic document architecture is de ned by identifying the document components (called core assets in the SPLE terminology and InfoElements in DPL) required according to the feature model built in the previous stage. These InfoElements may de ne a set of variables corresponding to a set of placeholders, i.e., parts of their content that may be instantiated at later stages of the document generation process. Speci c instances of the architecture are created later in the process, after the variability points and document variable have been xed for a speci c document. DPL assumes the existence of a Repository where InfoElements are stored and organized for reuse. Metadata are attached to each InfoElement in order to support retrieval processes in the Develop Core Asset task to nd existing components. Finally, in the Generate Document Line task, a production plan is obtained; it is a process that speci es how the components are integrated according to the di erent relationships de ned between the document features.
In the Application Engineering subprocess, a member of the document family is generated. The process starts with the Characterize Document task by selecting in the con guration the speci c document features and variable values to be included in the nal document. Next, the core-assets associated to the selected document features are retrieved and put together to Generate a Document Creation's Work ow model that it is used to generate a set of Custom Document Editors. The editors provide guidance for Enacting the Document's Creation Work ow by giving both a task-oriented and user-centered view of the document based on editing task and permissions producing the nal document. 3
document feature model describing the domain at the end of the stage. The Feature Editor is used by the Domain Engineer to characterize the variability of the domain as a document feature model. The Feature Editor interfaces with the Repository, which contains the InfoElements that will later be reused. All these elements support the Analyse Document Family task (cf. Figure 1).
It is noteworthy that, for the sake of simplicity, the Reference Architecture matches the structure of the feature model, and thus, the Design Document Family task does not require user-interaction. The Component Editor supports the Develop Core Assets task and is used to create new InfoElements and add them to the Repository. The Generate Document Line, which will describe how to retrieve and integrate the di erent components to obtain the nal product, is also hidden from the user-point of view.
Regarding the Application Engineering subprocess, the Con guration Editor
supports the Characterize Document task through the selection of variability
points. Once a document feature model con guration is de ned, the Enact
Document Creation's Work ow task starts and the Custom Document Editors are
generated by composing the InfoElements. These editors are used to ll in any
remaining variable data. Finally, the Document Generator (a DITA-based [
Emergency plans development is the eld we selected for our case study. An emergency plan is a document that contains all the knowledge required to respond to any incident in an organization. Emergency plans development is a domain that brings together a set of requirements that makes it an interesting real case study. In our demonstration we will show how a family of emergency plans is modeled, and how a customized emergency plan is generated. The UPV Campus is a real case study, and its document feature model represents the family of emergency plans of the university campus; where each building of the campus has its own emergency plan obtained as a con guration of the family.
Prior to the adoption of the DPL methodology in the UPV, new emergency plans were manually created using a text editor (MS Word). Applying DPL to the development of emergency plans requires that a set of document fragments (i.e. InfoElements ) need to be created to be combined in the nal document and a Document Feature Model describing the family of plans. However, sometimes an InfoElement needs some small parts to be changed from one emergency plan to another (e.g. the building name or the speci c maps or warning systems, etc.). This scenario allows us to show how both approaches for document customization (variability-based customization and Variable Data Printing) have been combined in DPL and DPLfw.
DPLfw supports the generation of variable content documents in a product-line style. Such an approach has several advantages. On one hand, a domain-oriented variability speci cation helps to hide the complexity intrinsic to document description languages such as XML. On the other hand, the de nition of generic content components increases the reusability of content signi cantly. DPLfw supports the generation of customized documents with high levels of reuse. Its foundation, DPL, aims at raising the level of abstraction in comparison with previous approaches, helping domain engineers and document engineers to develop families of documents without knowledge of the underlying document representation techniques such as XML, XPath, DITA or DocBook.
We have illustrated the use of DPLfw with an example taken from our
collaboration with the emergency planning team at the Universidad Politecnica
de Valencia. The DPLfw documentation and prototype are publicly available
for download in [