Software Design Document for XML Legal Document Utility, Study notes of Design

Download Software Design Document for XML Legal Document Utility and more Study notes Design in PDF only on Docsity!

Example

XML Legal Document Utility

Software Design Document

Version <1.0>

Rex McElrath

Software Design Document Date: 2007-04- SDD-XLDU

Revision History

Date Version Description Author 04/18/07 <1.0> Initial Version of Document Rex McElrath

Software Design Document Date: 2007-04- SDD-XLDU

Software Design Document

1 Introduction

The Software Design Document is a document to provide documentation which will be used to aid in software development by providing the details for how the software should be built. Within the Software Design Document are narrative and graphical documentation of the software design for the project including use case models, sequence diagrams, collaboration models, object behavior models, and other supporting requirement information. 1.1 Purpose The purpose of the Software Design Document is to provide a description of the design of a system fully enough to allow for software development to proceed with an understanding of what is to be built and how it is expected to built. The Software Design Document provides information necessary to provide description of the details for the software and system to be built. 1.2 Scope This Software Design Document is for a base level system which will work as a proof of concept for the use of building a system the provides a base level of functionality to show feasibility for large scale production use. This Software Design is focused on the base level system and critical parts of the system. For this particular Software Design Document, the focus is placed on generation of the documents and modification of the documents. The system will be used in conjunction with other pre-existing systems and will consist largely of a document interaction facade that abstracts document interactions and handling of the document objects.

Software Design Document Date: 2007-04-

SDD-XLDU

1.3 Definitions, Acronyms, and Abbreviations ● Data Objects – Data objects are Java objects with predefined structures capable of holding data in a structure that is quickly and easily accessible by other parts of the software system. They provide also can help provide a convenient abstraction of the data in a database so that it can be retrieved into a format, such as a denormalized format, that makes access and manipulation of the data easier than if the database had to be called

directly. http://java.sun.com/products/jdo/

● Denormalized - Normalization of a database is the activity of restructuring the database to avoid data anomalies and inconsistencies by focusing on functional dependencies to help structure the data. A web address to reference about normalization is:

http://en.wikipedia.org/wiki/Database_normalization. Denormalization is the act of

undoing some of the structural changes made during normalization to help with

performance. http://en.wikipedia.org/wiki/Denormalization

● Digital Signature – A digital signature is a unique object which is strongly tied to a single entity and the document which signature is intended for. In the same way that a ink on paper signature has characteristics that are unique to a person due to variations in writing a digital signature has characteristics that uniquely tie it to a single person and signing instance. http://en.wikipedia.org/wiki/Digital_signature ● Document Interaction Class, XMLDocumentInteractionEngine – These are the two terms that will be used to refer to the main software class described within this document. ● Editable Form Layout - A user interface presentation layout in which the contents of a document are presented to a user in the format of a form predefined editable areas based on the type of document which is being edited. This type of layout allows for changes to be made in a specific manner so that the data used in the form can be reassembled into a structured data format for transfer to other systems and archival. ● FOP Libraries – FOP stands for Formatting Objects Processor. The FOP Processor use an XSL-FO stylesheet and an XML instance to create PDF's, RTF's, and HTML files. FOP libraries bring the functionality of an FOP processor to a library form which can be used within another software program. http://xmlgraphics.apache.org/fop/ ● JDBC/ODBC – These two acronyms stand for Java Database Connectivity and Open Database Connectivity API's which allow for standardized database access and interaction from software products. JDBC: http://www.learnthat.com/define/view.asp?id=. ODBC: http://en.wikipedia.org/wiki/ODBC ● LegalXML – A standards body dedicated to issues related to the use of XML in the legal domain, http://www.legalxml.com/ ● PDF – Portable Document Format, http://en.wikipedia.org/wiki/Portable_Document_Format ● Pro se – This is a Latin term which directly translated means “for self” and is used to indicate that a party to a case has chosen to represent them selves to the court instead of choosing for an attorney to represent them to the court. http://en.wikipedia.org/wiki/Pro_se ● Required Field – A critical field is a field in a data set for a document that is required for successful document generation. For example, missing parties in a case, missing county location of court, or other data elements that are required to create a valid legal document.

Software Design Document Date: 2007-04- SDD-XLDU 1.4 References ● XML Legal Documents Utility Software Development Plan ○ Version 1.0, Last Updated on 2007-01- 1.5 Overview The Software Design Document is divided into 11 sections with various subsections. The sections of the Software Design Document are: 1 Introduction 2 Glossary 3 Use Cases

4 Design Overview........................................................................................................................................

5 System Object Model 6 Object Descriptions 7 Object Collaborations 8 Data Design 9 Dynamic Model 10 Non-functional Requirements 11 Supplementary Documentation

Software Design Document Date: 2007-04- SDD-XLDU

2 Glossary

2.1 Glossary is unused in current document due to Section 1.3 Definitions, Acronyms, and Abbreviations providing terms and definitions for internal use of the document.

Software Design Document Date: 2007-04- SDD-XLDU 3.3 Use Case Diagrams 3.3.1 Document Manager- Essential Use Cases (“Enter Document into Workflow” for future update)

Software Design Document Date: 2007-04- SDD-XLDU 3.3.2 Document Manager – Use Cases (Future)

Software Design Document Date: 2007-04- SDD-XLDU 3.4 Use Cases 3.4.1 Document Manager Use Cases – Create New Document Use case name: Create New Document

ID:

CND

Priority: High Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Overview Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the creation of a document which is a key function of the system. In this use case, the actor's goal is to generate a document. Goal: ● The successful completion of document generation. Success Measurement: ● The document is generated and reviewed by the user as acceptable for use. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● Data sufficient to populate all required fields in a data set for a document has been entered into the system that will be used to draw data from to generate the document's data set. Trigger: ● Document Management User has reached a point in their workflow in which a document is to be generated. Relationships: Include: Extend: Depends on: Typical flow of events:

1. A document or set or related documents are selected to be generated.
2. The data from the case management system is pulled by the System Under Design based on the template and case record chosen to populate the document or documents data sets.
3. The Document Management User is allowed to preview the documents and summary of data set used to populate document
4. Once satisfied with the document and data, the user saves the document and enters it into a work flow such as sending to reviewer, or sending for signature. Assumptions
5. It is assumed that workflows will be carried out internally or with close partnered agencies that can be interacted with n a similar manner as with an internal system.
6. It is assumed that the case management system will hold appropriate data for use to generate documents.
7. It is assumed that a standardized template for a document is desired instead of using a free form document. Implementation Constraints and Specifications:

Software Design Document Date: 2007-04- SDD-XLDU 3.4.2 Document Manager Use Cases: Create Document (Detail) Use case name: Create New Document (Detail)

ID:

CNDD

Priority: High Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Detail Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the creation of a document which is a key function of the system. In this use case, the actor's goal is to generate a document. Goal: ● The successful completion of document generation. Success Measurement: ● The document is generated and reviewed by the user as acceptable for use. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● Data sufficient to populate all required fields in a data set for a document has been entered into the system that will be used to draw data from to generate the document's data set. Trigger: ● Document Management User has reached a point in their workflow in which a document is to be generated. Relationships: Include: Extend: Depends on: Typical flow of events:

1. Document sets are selected to be generated by user by selecting the document type from a presented list or list of document packages.
2. The data from the case management system populates the document sets
3. The System Under Design uses the document or set of documents selected to determine the criteria for pulling data from the case management system, populating the XML instance for a data set for the documents and matching the XML data sets with XSL style sheets.
4. The System Under Design uses predefined security classifications of data elements to include security criteria for elements within XML data sets.
5. Exception: If insufficient data is available to completely populate a document, a notice is given to the user with a summary of missing or incomplete items and the choice to return to the case management system to fill out the missing information or to proceed with document generation if the missing fields are not classified as required fields for the document.
6. Invalid data is not expected as the case management system is expected to handle validation of data before it reaches the point of generating documents.
7. “Populating the document” means populating an XML instance per document that is paired with a specific style sheet so that when previewed, the data and other prose of the document are presented in a single presentation.
8. The user is allowed to preview the documents and summary of data set used to populate document

Software Design Document Date: 2007-04- SDD-XLDU 3.4.3 Document Manager: Generated Document Modification (Overview) Use case name: Generated Document Modification - Overview

ID:

GDMO

Priority: High Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Overview Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the modification of a data set which modifies the document that is displayed to a user. In this use case, the actor's goal is to modify the data elements of a document. Goal: ● The successful completion of document modification. Success Measurement: ● The document is modified and reviewed by the user as acceptable for use. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● A document has been generated and is saved for use by a workflow or archive. Trigger: ● Document Management User has reached a point in their workflow in which a document is to be modified. Relationships: Include: Extend: Depends on: Typical flow of events:

1. To modify the data set used for a document a user selects a document to update.
2. To select the document to update, the user uses a text based search or a reference number to locate the document within the System Under Design.
3. Once selected, the user initiates an update data set routine to update the data set which then populates the documents with new data when next previewed. Assumptions
4. It is assumed that no structural changes are to be made to standardized template based documents, such as not introducing movement of document sections without creation of new templates that contain the new layout for sections. Implementation Constraints and Specifications:

Software Design Document Date: 2007-04- SDD-XLDU 3.4.4 Document Manager: Generated Document Modification (Detail)– Element From Data Set Use case name: Generated Document Modification – Element From Data Set

ID:

GDMEDS

Priority: High Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Detail Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the modification of a data set which modifies the document that is displayed to a user and can initiate an update of the case management system database. The data is new and not already present within the case management system database. In this use case, the actor's goal is to modify the data elements of a document. Goal: ● The successful completion of document modification through modifying the elements of the data set of the document. Success Measurement: ● The document is modified and reviewed by the user as acceptable for use. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● A document has been generated and is saved for use by a workflow or archive. Trigger: ● Document Management User has reached a point in their workflow in which a document is to be modified with data that is not currently in the user database. Relationships: Include: Extend: Depends on: Typical flow of events:

1. To modify the data set used for a document a user selects a document to update.
2. To select the document to update, the user uses a text based search or a reference number to locate the document within the System Under Design.
3. Once the document is selected, the user selects to edit the documents data elements.
4. The System Under Design reads in the documents data set into memory structures.
5. The System Under Design then presents the user with a screen that has the data from the elements in the data set for the document displayed in manner that allows for them to be reviewed and selected for editing.
6. The System Under Design presents the user with the data elements in an ordered layout with edit options next to each data item, or section of data items.
7. To edit an item, the user clicks on the “Edit” button next to the element, or element set, desired to be edited.
8. When the element, or group of related elements, to edit is selected by the user, the System Under Design takes the user to a data entry page built specifically for that type of data (searches for persons, validations for telephone numbers, etc) and allowed to edit the data.
9. Once edited, the data is validated and reinserted into the data set and data base by the System Under Design using the documents metadata to correctly match the data set with the correct case in the case management system.

Software Design Document Date: 2007-04- SDD-XLDU 3.4.5 Document Manager: Enter Document Into Workflow (Overview) Use case name: Enter Document Into Workflow(Overview)

ID:

EDIWO

Priority: Medium Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Overview Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the entering of a created document into a workflow, such as adding to a package of documents being prepared, sending for review, sending to the court (aka Filing into Court), or sending to case participants. The use case routes the document to the next “inbox” of the workflow by saving the document, updating status of the document, and notifying the target of the workflow that the document is ready to be processed. Goal: ● The successful completion of readying a document to be processed as part of a workflow and notification of the intended target that the document is ready to be processed. Success Measurement: ● The document is saved with a status of ready to be processed, and the appropriate target has been notified of the status of the document. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● A document has been generated, modifications are completed, and it is ready to be saved for use by a workflow. Trigger: ● Document Management User has reached a point in their workflow in which a document is ready to be entered into another workflow. Relationships: Include: Extend: Depends on: ● Create New Document ● Generated Document Modification Typical flow of events:

1. Document Manager User has a document that is ready to be entered into a workflow.
2. The System Under Design presents the user with a selection of workflow types.
3. The user selects a type of workflow to use.
4. The System Under Design presents the user with addressing options.
5. The user selects a destination address(es) for the document.
6. The user selects submit to enter the document into the workflow. Assumptions
7. The types of workflow are known and there are existing code types and addressing information for notifications to be received. Implementation Constraints and Specifications:

Software Design Document Date: 2007-04- SDD-XLDU 3.4.6 Document Manager: Enter Document Into Workflow (Detail) Use case name: Enter Document Into Workflow(Detail)

ID:

EDIWD

Priority: Medium Primary actor: Document Manager Source: Attorneys, Judges Use case type: Business Level: Detail Interested Stakeholders: Judge, Court Clerk, Attorney, Paralegal Professional Brief description: This use case describes the entering of a created document into a workflow, such as adding to a package of documents being prepared, sending for review, sending to the court (aka Filing into Court), or sending to case participants. The use case routes the document to the next “inbox” of the workflow by saving the document, updating status of the document, and notifying the target of the workflow that the document is ready to be processed. Goal: ● The successful completion of readying a document to be processed as part of a workflow and notification of the intended target that the document is ready to be processed. Success Measurement: ● The document is saved with a status of ready to be processed, and the appropriate target has been notified of the status of the document. Precondition: ● Document Management User has successfully passed through Authentication and Authorization ● A document has been generated, modifications are completed, and it is ready to be saved for use by a workflow. Trigger: ● Document Management User has reached a point in their workflow in which a document is ready to be entered into another workflow. Relationships: Include: Extend: Depends on: ● Create New Document ● Generated Document Modification Typical flow of events:

1. Document Manager User has a document that is ready to be entered into a workflow.
2. The System Under Design presents the user with a selection of workflow types. (a) The List of Workflows known at this point is: i. Send to Court ii. Send to Judge iii. Send Copy as Secondary Service iv. Send to Peer for Review
3. The user selects a type of workflow to use.
4. The System Under Design captures the workflow type code for the selected by the user to use when submitting the choice.
5. The System Under Design presents the user with addressing options. (a) The addressing options are based on the user's profile and which courts, judges, and service recipients, and peers are configured within their profile as allowable addressing options.
6. The user selects a destination address(es) for the document.
7. The System Under Design Records the destination address(es) id's for use when