DesignFest^® Group: Wednesday Full Day – "Network Document Distribution"

Designers:

• Deepa Matta
• Martin McClure
• Patrick Parato
• Dana Whicker

Moderator:

• Jutta Eckstein

Process

We first tried to define the scope and boundary of the system. Because there was no domain expert available, it took us a while to understand the problem. Holly Beck from the AnalysisFest was a good helper by supporting our assumptions.

By looking at the Use Cases we decided first to concentrate on the external systems we had to talk with. This helped us to narrow down the problem. We formulated the main UseCase as a sequence diagram, but by using a system's point of view.

We then took the same Use Case, but focused on the internals of our system. That was actually the first time we really talked about objects. From that point of view this was probably the most important step. We modeled that through a CRC card session. Afterwards we captured the interactions in a sequence diagram.

We found it quite easy to translate what we had at that point into a class diagram.

Assumptions we made

• We decided that the process of generating the document, from a user standpoint, was as follows:

1. The user connects to the web site and logs in, with a password. (The User ID is stored from this transaction, to be sent in the XML stream.)
2. The client is then presented with a list of documents.
3. The client selects a document template, fills it out, and clicks on a button to indicate the document is completed. (The Document ID was part of the template, and so is automatically transmitted with the completed document information.)
4. The User ID, the Document ID, and the values entered by the client are sent in an XML stream that is received by our system.

• The Contract ID corresponds to Application ID
• For each session there exists only one Document ID.
• User ID refers to the client. Client information does not need to be checked from our system because the login process ensures that only validated clients can access the client application.
• Application ID is omitted, because it's the same as Contract ID.
• Blank Document Use Case is an error case.

Other important points we decided on

• We don't have to deal with the PDF-file. We just have to look up the file name and pass this name to PDFFusion.
• The Oracle DB allows us to look up the correct template, by using the Document ID, which in turn allows us to look up the tags for this template.

Further considerations:

• Create the contract even if some critical values are incorrect or not included. Then append an error message to the resulting XML stream.
• Allow reuse of a contract, where only some of the information was exchanged.

Overall impression

• It was great fun working on the project, mainly because the whole team participated very actively in the project.
• But at the very end we doubted if this project really reflects reality, because:

We finished in time, on budget ;-) and besides – had fun!