Example SoftwareDesignDocument LegalXMLUtility
Example SoftwareDesignDocument LegalXMLUtility
Version:
<1.0>
Date: 2007-04-20
Revision History
Date
Version
04/18/07
<1.0>
Description
Initial Version of Document
Author
Rex McElrath
Page 2 of 48
Version:
<1.0>
Date: 2007-04-20
Table of Contents
1 Introduction...................................................................................................................................................4
1.1 Purpose..............................................................................................................................................4
1.2 Scope.................................................................................................................................................4
1.3 Definitions, Acronyms, and Abbreviations.......................................................................................5
1.4 References.........................................................................................................................................7
1.5 Overview...........................................................................................................................................7
2 Glossary........................................................................................................................................................8
3 Use Cases......................................................................................................................................................9
3.1 Actors................................................................................................................................................9
3.2 List of Use Cases...............................................................................................................................9
3.3 Use Case Diagrams.........................................................................................................................10
3.4 Use Cases........................................................................................................................................13
4 Design Overview........................................................................................................................................22
4.1 Introduction.....................................................................................................................................22
4.2 System Architecture........................................................................................................................22
4.3 System Interfaces............................................................................................................................23
4.4 Constraints and Assumptions..........................................................................................................23
5 System Object Model.................................................................................................................................24
5.1 Introduction.....................................................................................................................................24
5.2 Subsystems......................................................................................................................................24
5.3 Subsystem Interfaces.......................................................................................................................24
6 Object Descriptions....................................................................................................................................25
6.1 Objects............................................................................................................................................25
7 Object Collaboration...................................................................................................................................40
7.1 Object Collaboration Diagram........................................................................................................40
8 Data Design................................................................................................................................................41
8.1 Entity Relationship Diagram...........................................................................................................41
9 Dynamic Model..........................................................................................................................................42
9.1 Sequence Diagrams.........................................................................................................................42
9.2 State Diagrams................................................................................................................................45
10 Non-functional Requirements...................................................................................................................47
10.1 Performance Requirements...........................................................................................................47
10.2 Design Constraints........................................................................................................................47
11 Supplementary Documentation................................................................................................................48
11.1 Tools Used to Create Diagrams....................................................................................................48
Page 3 of 48
Version:
<1.0>
Date: 2007-04-20
Page 4 of 48
Version:
<1.0>
Date: 2007-04-20
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
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=106 .
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/
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.
Page 5 of 48
Version:
<1.0>
Date: 2007-04-20
Structured Data Format A structured data format is data assembled into a discernible
structure, such as when data is placed into an XML instance which is validated through the
use of an XML schema which defines the structure of the XML document.
Workflow The movement of documents through a work process that is structured into
tasks with designated persons or systems to perform them and the definition of the order or
pathway from start to finish for the work process. http://en.wikipedia.org/wiki/Workflow
Page 6 of 48
Version:
<1.0>
Date: 2007-04-20
1.4 References
XML Legal Documents Utility Software Development Plan
1.5 Overview
The Software Design Document is divided into 11 sections with various subsections. The
sections of the Software Design Document are:
1
2
3
4
5
6
7
8
9
10
11
Introduction
Glossary
Use Cases
Design Overview
System Object Model
Object Descriptions
Object Collaborations
Data Design
Dynamic Model
Non-functional Requirements
Supplementary Documentation
Page 7 of 48
Version:
<1.0>
Date: 2007-04-20
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.
Page 8 of 48
Version:
<1.0>
Date: 2007-04-20
3 Use Cases
Use-Case Model Survey
3.1 Actors
3.1.1 Document Manager
3.1.1.1 Information: The Document Manager is a user who works with legal documents.
This is an abstraction of the specific users as they all perform similar actions, but for
different reasons. For example, a court clerk and an attorney both sign documents, but
an attorney does so to state that they created or agree to the documents and the court
clerk does so to state that the document has been received and is now secured with a
secure hash to detect modification. The mechanics and the processes used for each
are the same to apply their respective digital signatures, but the intent and meaning of
each application of a digital signature is different. The specific actors who fall into the
broader category of document manager are:
3.1.1.1.1 Judge
3.1.1.1.2 Court Clerk
3.1.1.1.3 Attorney
3.1.1.1.4 Paralegal Professional
3.1.1.1.5 Pro Se Party
3.1.1.2 Additional Information: The Document User is the only user seen in the use cases
considered essential to the System Under Design. Of the three essential use cases,
Create New Document, Generated Document Modification, and Enter Document Into
Workflow, the use cases considered the highest priority, Create New Document and
Generated Document Modification, have been focused on. Following diagrams in
Section 3.3 contain current and future implemented use cases for illustrative purposes
of future directions for the System Under Design.
3.1.2 System Under Design
3.1.2.1 The System Under Design is the XML Legal Document System that is being
created. This actor represents the system and the actions that it takes.
3.1.3 Administrative User
3.1.3.1 Information: The Administrative User is a user who administers the system by
overseeing accounts creation and administration.
3.1.4 Public User
3.1.4.1 Information: The Public User is a generic user to represent a person who is not an
attorney or pro se party who will be creating documents but has a valid reason to view
and research a document or set of documents in relationship to one or more cases and
has been validated through security measures such as signing up for an account in
person at the Court Clerk's Office and providing proof of identity.
3.2 List of Use Cases
3.2.1 Document Manager User Use Cases
3.2.1.1 Create New Document (Overview)
3.2.1.2 Create New Document(Detail)
3.2.1.3 Generated Document Modification (Overview)
3.2.1.4 Generated Document Modification (Detail) Element From Data Set
3.2.1.5 Enter Document Into Workflow(Overview)
3.2.1.6 Enter Document Into Workflow(Detail)
Page 9 of 48
Version:
<1.0>
Date: 2007-04-20
Page 10 of 48
Version:
<1.0>
Date: 2007-04-20
Page 11 of 48
Version:
<1.0>
Date: 2007-04-20
Page 12 of 48
Version:
<1.0>
Date: 2007-04-20
Page 13 of 48
Version:
<1.0>
Date: 2007-04-20
Version:
<1.0>
Date: 2007-04-20
Page 15 of 48
Version:
<1.0>
Date: 2007-04-20
Page 16 of 48
Version:
<1.0>
Date: 2007-04-20
3.4.4 Document Manager: Generated Document Modification (Detail) Element From Data Set
Use case name:
ID:
Priority:
Generated Document Modification Element From
GDMEDS
High
Data Set
Primary actor:
Source:
Use case type:
Level:
Document Manager
Attorneys, Judges
Business
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.
Page 17 of 48
Version:
<1.0>
Date: 2007-04-20
10. Once the XML data set is updated by the System Under Design with the new information,
the user is allowed to preview the document to review the updated document.
Assumptions
1. 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:
Page 18 of 48
Version:
<1.0>
Date: 2007-04-20
Page 19 of 48
Version:
<1.0>
Date: 2007-04-20
Version:
<1.0>
Date: 2007-04-20
Page 21 of 48
Version:
<1.0>
Date: 2007-04-20
4 Design Overview
4.1 Introduction
The Design Overview is section to introduce and give a brief overview of the design. The System
Architecture is a way to give the overall view of a system and to place it into context with external
systems. This allows for the reader and user of the document to orient them selves to the design and
see a summary before proceeding into the details of the design.
4.2 System Architecture
4.2.1 Overall Structure for the XML Legal Document Utility System
Page 22 of 48
Version:
<1.0>
Date: 2007-04-20
Page 23 of 48
Version:
<1.0>
Date: 2007-04-20
Page 24 of 48
Version:
<1.0>
Date: 2007-04-20
6 Object Descriptions
6.1 Objects
6.1.1 XMLDocumentInteractionFacade
Class name: XMLDocumentInteractionFacade
Brief description: The XMLDocumentInteractionFacade class is responsible for controlling actions relating
to managing documents. For example, the XMLDocumentManagementFacade class would handle such tasks
as searching for and retrieving documents. It is the controller class that abstracts more specific helper classes.
Attributes (fields)
Attribute Description
DocumentFactory docFactory;
This is a declaration of a Document Factory object to be used
throughout the class for different methods.
Program Description Language
private DocumentFactory docFactory;
AuditLog auditLog;
Attribute Description
This is a declaration of a Audit Log object to be used throughout the
class for different methods.
Program Description Language
private AuditLog auditLog;
DocumentSigner docSigner;
Attribute Description
This is a declaration of a Document Signer Object to be used
throughout the class for different methods.
Program Description Language
private DocumentSigner docSigner;
WorkFlow workflow;
Attribute Description
This is a declaration of a WorkFlow object to be used throughout the
class for different methods.
Program Description Language
private WorkFlow workflow;
Document doc;
Attribute Description
This is a declaration of a Document Object to be used throughout the
class for different methods.
Program Description Language
private Document doc;
Methods (operations)
Method Description
Page 25 of 48
Version:
<1.0>
Date: 2007-04-20
Method Description
A method to locate the document and retrieve document structure with
contains both the XML data set and XSL stylesheet.
Program Description Language
public void pullDocument(Uuid docUuid) {
doc = docFactory.pullDocument(docUuid);
return null;
}
checkDocumentCriteria()
Method Description
A method to lookup and retrieve the data criteria for a document.
Program Description Language
public String checkDocumentCriteria() {
String validationResultsHolder;
validationResultsHolder = doc.validateXML();
return validationResultsHolder;
}
pullDataFromCaseManagement()
Method Description
A method to retrieve data from the case management system based on
the data criteria for the document selected and load or refresh the
document with the data retrieved.
Program Description Language
public void pullDataFromCaseManagement(String caseRefId) {
// Assumes Case UUID has been searched for and found
doc.pullData(caseUuid);
return null;
}
Page 26 of 48
Version:
<1.0>
Date: 2007-04-20
Page 27 of 48
Version:
<1.0>
Date: 2007-04-20
readAuditLog()
generateDocument()
XMLDocumentInteractionFacade()
Method Description
A method to update audit logs based on the actions taken.
Program Description Language
public int updateAuditLog(actorUuid, docUuid, actionCode) {
int auditUpdateSuccessSignal;
// 0 if successful, 1 if error
auditLogUpdateSuccessSignal = auditLog.newEntry(actorUuid,
docUuid, actionCode);
return auditLogUpdateSuccessSignal;
}
Method Description
A method to allow for returning a result set containing the audit log for
a particular document.
Program Description Language
public ResultSet readAuditLog(Uuid docUuid) {
auditLog.getEntries(docUuid);
}
Method Description
A method to generate a document using the type of document to
generate and the data source of a case record. The method utilizes a
factory pattern class to generate the document.
Program Description Language
public String generateDocument(int docTypeCode, Uuid caseUuid) {
String createdDocUuid;
docFactory.createDocument(docTypeCode, caseUuid);
createdDocUuid = doc.getUuid().toString();
return creatDocUuid.toString;
}
Method Description
This is a constructor method for the class.
Program Description Language
public XMLDocumentInteractionFacade() {
docFactory = new DocumentFactory();
auditLog = new AuditLogFacade();
docSigner = new DocumentSigner();
workflow = new WorkFlowFacade();
}
Page 28 of 48
Version:
<1.0>
Date: 2007-04-20
6.1.2 DataSetEditBackingBean
6.1.2.1 The DataSetEditBackingBean is left without design details temporarily in order to
focus on internal mechanics of the system.
Class name: DataSetEditBackingBean
Brief description: The DataSetEditBackingBean is responsible for supporting the logic and
validation of user interface pages used for editing the data held within the XML data set of a
document.
Attributes (fields)
Attribute Description
uiInterfaceComponent
This is a generic for attributes used to represent user interface
components to be displayed and used in the user interface.
dataComponent
This is a generic for the data holding attributes that will need to
be created based on the set of elements to be edited.
Methods (operations)
getUIInterfaceComponent()
setUIInterfaceComponent()
getDataComponent()
setDataComponent()
validate(data, validationType)
DataSetEditBackingBean()
Method Description
This is a generic for the getters used for user interface backing
beans.
This is a generic for the setters used for user interface backing
beans.
This is a generic for the getters used for data used with the
interface for documents.
This is a generic for the setters used for data used with the
interface for documents.
An overloaded method set which is used to validate modifications
to a data set based on the type of element being edited.
This is a constructor method for the class.
Page 29 of 48
Version:
<1.0>
Date: 2007-04-20
6.1.3 DocumetFactory
Page 30 of 48
DocumentFactory()
Version:
<1.0>
Date: 2007-04-20
Method Description
This is a method to generate a document object
Program Description Language
public Document pullDocument(UUID docUuid) {
dbFacade = new DatabaseInteractionFacade();
dbFacade.pullDocumentXMLFromDB(docUuid);
// DB facade retrieves XML data and style instances
// XML objects are read into memory to create an in memory
// structure of the XML to create document
// Created document reference is returned to the caller.
return doc;
}
Method Description
This is a default constructor method.
Program Description Language
public void DocumentFactory() {
}
Page 31 of 48
Version:
<1.0>
Date: 2007-04-20
6.1.4 SpecificDocumentFactory
Version:
<1.0>
Date: 2007-04-20
Page 33 of 48
Version:
<1.0>
Date: 2007-04-20
6.1.5 Document
DatabaseInteractionFacade
dbFacade
HashMap hmapElementToId;
Attribute Description
This is a grouping of data elements that are common to all documents
which will be inherited by subclasses which will create specific
documents.
Program Description Language
/* Data Elements with cardinality in XML instances */
/* Elements with cardinality greater than 1:1 are assumed
* to be arrays of elements
*/
/* All are set to be private to the class */
// Case Caption Information
Court // 1:1
Internal Tracking Number // 1:1
Case Reference Number // 1:1
External Case Number // 0:*
Case Style // 1:1
Alias Case Style // 0:*
// Parties
Initiating Party // 1:*
Responding Party // 1:*
Initiating Party Attorney // 0:*
Responding Party Attorny // 0:*
Witness // 0:*
Related Party // 0:*
// Matters
Matter Code // 1:*
// Prose Sections
Prose Elements // 1:*
// Prose Locations
Prose Location Info // 1:*
Attribute Description
This is a declaration of a Database Interaction Facade object to be used
throughout the class.
Program Description Language
// Declare a DB Facade
private DatabaseInteractionFacade dbFacade = new
DatabaseInteractionFacade();
Attribute Description
This is a variable to create a hash map for keeping track of identifiers
for the data elements for a document. This allows data elements to be
referenced by id number instead of by String based name.
Program Description Language
// Declare Hashmap for mapping elements to id's
private HashMap hmapElementToId;
Page 34 of 48
int changeTrackerForElements[];
XMLInstanceData xmlData;
XMLInstanceStyle xmlStyle;
int docType;
Methods (operations)
Data Element Getter
Version:
<1.0>
Date: 2007-04-20
Attribute Description
This is an variable to help keep track of the number of data elements to
be used as in index variable for loops or for working with the hash
map.
Program Description Language
// Declare an element to be used to hold the number of data elements
// present.
private int numberOfDataElements = 1;
Attribute Description
This is a integer array for use in tracking changes to the data in use so
that it can be synchronized with the case management system using the
appropriate update methods of the database facade.
Program Description Language
// Declare an array to hold id's of elements that have been updated
// 0's indicate no change, 1's represent change and need to
// synchronize
// If there is a 1 present in (elementId - 1) position of the array,
// then the element has been updated and needs to be
// synchronized back to the database
private int changeTrackerForElements[];
Attribute Description
This is a declaration of the document object model type of holder for
the XML instance responsible for data when the data from the
Document object is transferred or read from XML.
Program Description Language
// Declare a XML Data Object for data
private XMLInstanceData xmlData;
Attribute Description
This is a declaration of the document object model type of holder for
the XML instance responsible for stylesheet data when needed for use
by the Document object.
Program Description Language
// Declare a XSL Object for Style
private XMLInstanceStyle xmlStyle;
Attribute Description
This is an integer to hold the document type code.
Program Description Language
// Holds the Document type code for the document.
private int docType;
Method Description
This is a place holder for the simple getter methods for the general
document data elements contained within this class.
Program Description Language
public String getValueOfSpecificDataElement() {
}
Page 35 of 48
Document()
hashElementsToId()
Version:
<1.0>
Date: 2007-04-20
Method Description
This is a place holder for the simple setter methods for the general
document data elements contained within this class.
Program Description Language
public void setValueOfSpecificDataElement(String value) {
GeneralDataElement = value;
}
Method Description
This is a constructor for the class which allows for the instantiation of
the XML data and style structure objects, the setting of the
Program Description Language
public void Document(int docTypeCode) {
docType = docTypeCode;
// InstantiateDOM object for dealing with data
xmlData = new XMLInstanceData();
// InstantiateDOM object for dealing with style data
xmlStyle = new XMLInstanceStyle();
// Load style sheet info based on the Document Type
xmlStyle.loadStyle(docType);
}
Method Description
HashElementsToID() is a method which adds the data elements to an
id structure. The reason for using a hash map is to allow for easy
lookup of elements by id number, working with a list of ids or
elements, or getting a list of the mapped elements.
Program Description Language
// Code to element mapping
public void hashElementsToId() {
hmapElementToId = new HashMap();
hmapElementToId.put(numberOfDataElements++, Court);
hmapElementToId.put(numberOfDataElements++, Internal
Tracking Number);
hmapElementToId.put(numberOfDataElements++, Case
Reference Number);
hmapElementToId.put(numberOfDataElements++, External
Case Number);
hmapElementToId.put(numberOfDataElements++, Case
Style);
...
// add all elements to the hashmap
// Initialize Change Tracker Array
changeTrackerForElements[numberOfDataElements];
}
Page 36 of 48
getDataElement()
hmapToSetterLocator()
Version:
<1.0>
Date: 2007-04-20
Method Description
This method allows for an abstraction of setting data elements. It
allows for setters to be located by id number for a proxy method for
other setter methods.
Program Description Language
public void setDataElement(String value, int elementId) {
hmapToSetterLocater(elementId, value);
}
Method Description
This method allows for an abstraction of getting data elements. It
allows for getters to be located by id number for a proxy method for
other getter methods.
Program Description Language
public String getDataElement(int elementId) {
String value;
value = hmapToGetterLocator(elementId);
return value;
}
Method Description
This is a method to allow for setting data elements based on id. It is a
private method used by setDataElement() method.
Program Description Language
private void hmapToSetterLocator(int id, String value) {
if (id == 1) {
setCourt(value);
changeTrackerForElements[id] = 1;
} else if (id == 2) {
setInternalTrackingNumber(value);
changeTrackerForElements[id] = 1;
} else if (id == 3) {
setCaseReferenceNumber(value);
changeTrackerForElements[id] = 1;
} else if . . .
// add locater statements for all elements
return void;
}
Page 37 of 48
pushData()
Version:
<1.0>
Date: 2007-04-20
Method Description
This is a method to allow for getting values of elements by using id
numbers.
Program Description Language
private String hmapToGetterLocator(int id) {
String value;
if (id == 1) {
value = getCourt();
return value;
} else if (id == 2) {
value = getInternalTrackingNumber();
return value;
} else if (id == 3) {
value = getCaseReferenceNumber();
return value;
} else if // . . .
// add locater statements for all elements
}
Method Description
This is method for synchronizing the changed data in the document
with the case management system database.
Program Description Language
public void pushData() {
int i;
Uuid caseRecordUuid = getCaseRecordUuid();
if (changeTrackerForElements[i++ - 1] == 1) {
dbFacade.updateCaseRecordCourt(caseRecordUuid,
getCourt());
} else if (changeTrackerForElements[i++ - 1] == 1) {
dbFacade.updateCaseRecordInternalTrackingNumber(
caseRecordUuid, getInternalTrackingNumber());
} else if (changeTrackerForElements[i++ - 1] == 1) {
dbFacade.updateCaseRecordCaseReferenceNumber(
caseRecordUuid, getCourt());
// . . .
// Continue until all options for changes have been checked
// and updated.
}
Page 38 of 48
Version:
<1.0>
Date: 2007-04-20
6.1.6 SpecificDocument
Methods (operations)
Data Element Getter
Attribute Description
This is a grouping of data elements that are common to all documents
which will be inherited by subclasses which will create specific
documents.
Program Description Language
/* Document Specific Data Elements with cardinality in XML */
/* Elements with cardinality greater than 1:1 are assumed
* to be arrays of elements
*/
/* All are set to be private to the class */
// Assuming a Summons
// Appearance Info
Appearance Date // 1:1
Appearance Time // 1:1
Court House Identifier // 1:1
// Service Info
Respondent Party Work Address // 1:1
// More addresses can be added on service info sheet
....
Attribute Description
This is a place holder for the simple getter methods for the general
document data elements contained within this class.
Program Description Language
public String getValueOfSpecificDataElement() {
}
Attribute Description
This is a place holder for the simple setter methods for the general
document data elements contained within this class.
Program Description Language
public void setValueOfSpecificDataElement(String value) {
GeneralDataElement = value;
}
Page 39 of 48
Version:
<1.0>
Date: 2007-04-20
7 Object Collaboration
7.1 Object Collaboration Diagram
7.1.1 This is a diagram depicting the object relationships. Items in blue are described in Section 6.
Page 40 of 48
Version:
<1.0>
Date: 2007-04-20
8 Data Design
8.1 Entity Relationship Diagram
8.1.1 Basic Entity Relationship Diagram
Page 41 of 48
Version:
<1.0>
Date: 2007-04-20
9 Dynamic Model
9.1 Sequence Diagrams
9.1.1 Document Generation Sequence Diagram
9.1.1.1 This diagram show the overview level sequence form moving from data and
template to a document.
Page 42 of 48
Version:
<1.0>
Date: 2007-04-20
Page 43 of 48
Version:
<1.0>
Date: 2007-04-20
Page 44 of 48
Version:
<1.0>
Date: 2007-04-20
Page 45 of 48
Version:
<1.0>
Date: 2007-04-20
Page 46 of 48
Version:
<1.0>
Date: 2007-04-20
10 Non-functional Requirements
10.1 Performance Requirements
The system should be able to generate previews of documents within 15 seconds of user
request.
The system should be able to hold and search through large amounts of documents. The data
structures used for the system will be fairly simple consisting of a few fields to hold document
types and their related codes, XML instances with an id, and an audit log table, however the
size of the simple data structures could potentially be quite large.
Expected capacity for large volume courts approximately 108, 000 new documents a
year with expected retention capacity of 10 years of active documents. After 10 years,
documents can be stored in slower to access storage media. Which equates to
approximately 1,080,000 documents that will need to be able to be stored and searched.
The work will be licensed under an existing open source license, available at,
http://license.gaje.us , and donated for use to standards committees that the agency
participates in, such as the LegalXML Technical Committee.
XML schemas should follow the National Information Exchange Naming and Design Rules,
http://www.niem.gov/topicIndex.php?topic=file-ndr-0_3 .
When implemented in later versions, document retention schedules should follow the
guidelines set forth by the Administrative Office of the Courts in Georgia for records retention,
http://www.georgiacourts.org/aoc/records.php .
Page 47 of 48
Version:
<1.0>
Date: 2007-04-20
11 Supplementary Documentation
11.1 Tools Used to Create Diagrams
11.1.1 UML Modeling Tools
11.1.1.1 ArgoUML Version 0.24, http://argouml.tigris.org/
11.1.2 Entity Relationship Diagramming Tools
11.1.2.1 Dia Version 0.95, http://live.gnome.org/Dia
Page 48 of 48