Historical Document Viewer

Historical Document Viewer
Software Architecture Document
Version 1.1
Revision History
Date
Version
Description
Author
April 21, 2010
1.0
Initial version
Tárik S. Salem
May 4, 2010
1.1
Extended architecture diagram and edited

description of data view
Tárik S. Salem
Table of Contents
1 Introduction
......................................................................................................................................
2
1.1 Purpose
......................................................................................................................................
2
1.2 Scope
.........................................................................................................................................
2
1.3 Definitions, Acronyms and Abbreviations
................................................................................
2
2 Architectural Representation
............................................................................................................
2
3 Architectural Goals and Constraints
.................................................................................................
2
4 Use Case View
..................................................................................................................................
3
4.1 Use Case Descriptions
..............................................................................................................
3
5 Logical, Implementation and Deployment View
..............................................................................
4
5.1 Component Descriptions
...........................................................................................................
4
6 Data View
.........................................................................................................................................
5
6.1 Data View Description
..............................................................................................................
5
7 Size and Performance
.......................................................................................................................
8
8 Quality
..............................................................................................................................................
8
Page
1
of
8
1
Introduction
1.1
Purpose
This document provides a comprehensive architectural overview of the Historical Document

Viewer, using a number of different architectural views to depict different aspects of the system.
1.2
Scope
This document describes the aspects of the Historical Document Viewer design that are considered

to be architecturally significant; that is, those elements and behaviors that are most fundamental for

guiding the construction of Historical Document Viewer and for understanding this project as a

whole.
1.3
Definitions, Acronyms and Abbreviations
HDV
Historical Document Viewer
CMS
Content Management System
PHP
Hypertext Preprocessor
CCK
Content Construction Kit (Drupal module)
2
Architectural Representation
This document presents the architecture as a series of views; use case view, logical, implementation

and deployment view and data view. There is no separate process view described in this document.
3
Architectural Goals and Constraints
There are some key requirements and system constraints that have a significant bearing on the

architecture.
According to requirements in the Vision Document the Historical Document Viewer is web

application that must be designed as modules for Drupal CMS.
This results in further restrictions

arising from
Drupal system requirements:
•
Deployment on Apache (recommended) or Microsoft IIS web server.
•
Support of MySQL or PostgreSQL database server.
•
Support of PHP and development in this programming language.
Other requirements and system constraints:
•
The system must be designed in accordance with standards, security and best practices of

development in Drupal (http://drupal.org/node/360052).
•
HDV must be able to deal with several languages (at least English, Czech and German).
•
Viewing of JPEG2000 pictures.
•
All used technologies should be free or open-source.
•
All functions must be available through most used web browsers.
Page
2
of
8
Requirements, as stipulated in the Vision Document and the Specification Document, must be taken

into consideration as the architecture is being developed.
4
Use Case View
4.1
Use Case Descriptions
View Register
This Use Case occurs when an user visits HDV website without archivist or administrator

privileges. Pages are dynamically built to show the user
required content of a database.
Maintain Register
This Use Case occurs when a user with archivist privileges edits folders with register pages and

edits register database.
Maintain The System
This Use Case occurs when a Drupal administrator manage users, install new modules, edit content,

etc. Administrator has full privileges.
Page
3
of
8
5
Logical, Implementation and Deployment View
Constraints of the use of Drupal allows us to express logical, implementation and deployment view

into one diagram. Components represent Drupal modules.
5.1
Component Descriptions
Components Chronicle, Stock and PEVA Import will be not implemented in the first version of

HDV. Description of these components is not included in this document.
Municipality + District
This module creates database of municipalities and districts and allows you to change the content of

a database.
Register + Source
This module creates database of registers and sources and allows you to change the content of a

database.
IIPImage Viewer
This module uses IIPImage server for viewing of high resolution JPEG2000 images. Image
viewer

allows user to zoom and move pictures during viewing. Another function of this module is creating

thumbnails of high resolution images.
Migration
Module Migration imports data from old database to database of Drupal HDV.
Page
4
of
8
6
Data View
This simplified ERA diagram is sufficient for implementation of database in Drupal via CCK.
6.1
Data View Description
HDV must allow editing of database attributes.
Municipality
Attributes:
•
Identifier
•
Name
•
GPS coordinates
•
Alternative names
•
Type:
Page
5
of
8
•
Village
•
Part of the villige
•
Hamlet
•
Date (from - to)
•
Comment
Municipality-Municipality relation
Municipality can be in relation with other municipalities (M:N).
Attributes:
•
Type of relation:
•
Subset
•
Equal
•
Date (from – to)
•
Comment
District
Attributes:
•
Identifier
•
Name
•
GPS coordinates
•
Alternative names
•
Type:
•
Parish (Roman Catholic, evangelical)
•
Earldom
•
Jurisdiction
•
District
•
Region
•
Country
•
Register circuit
•
Diocese
•
Date (from – to)
•
Comment
Page
6
of
8
District-District relation
District can be in relation with other districts (M:N).
Attributes:
•
Type of relation:
•
Subset
•
Equal
•
Date (from – to)
•
Comment
Municipality-District relation
District contains municipalities (M:N).
Attributes:
•
Date (from – to)
•
Comment
Source
Attributes:
•
Name
•
Comment
•
Type:
•
Roman Catholic Church
•
Evangelical Church (Czech, German)
•
District authorities
•
Sanctification (only for Roman Catholic Church)
District-Source relation
Source belongs to a district (1:N).
Register
Attributes:
•
Name
•
Comment
•
Book proportions (w x h x d)
•
Page count
•
Completeness
Page
7
of
8
•
Language
•
Physical state
•
Type (identical with entity Source, default values are identical with source but can be

changed):
•
Roman Catholic
•
Evangelical (Czech, German)
•
District authorities
Source-Register relation
Source creates registers (1:N).
Register-Municipality relation
Register describes municipalities (M:N).
Attributes:
•
Type of record:
•
Birth
•
Marriage
•
Departeds
•
Birth index
•
Marriage index
•
Departeds index
•
Date (from – to)
•
Pages (from – to)
7
Size and Performance
The system must allow fast viewing of high resolution JPEG2000 images. E
ach of this file will be

about 50MB. System will contain millions of images.
8
Quality
Modularity and extensibility of the system is important for future extensions. Program code must be

well commented.
The system must be designed in accordance with standards, security and best

practices of development in Drupal
as stated above.
Page
8
of
8