Design

Release Information
Project : Dorm Keeper

Related Documents : : Design > Architecture Worksheet

Design > Source Organization and Build Worksheet
Design > User Interface Worksheet
Design > Persistent Storage Worksheet
Design > Security Worksheet

Introduction

How is this design document organized?

This main page describes the system design in terms of packages, classes,
relationships, and behavior. Several attached worksheets address specific
aspects of the overall system design, such as user interface and database
design.

What are the most important facts that a developer should know about
this design?
• The design considered the limited time for developing the
project
• Correctness and feasibility are the topmost priorities
• To realize the project, strict adherence to this design is expected

What are the prioritized goals of this design?

1. Correctness
2. Feasibility
3. Understandability
4. Implementation Phase Guidance
5. Modularity
6. Testability
7. Efficiency

UML Structural Design

The system's behavioral design is described in the attached UML structural

diagrams.

UML Behavioral Design

The system's behavioral design is described in the attached UML behavioral

diagrams.
UML Design Checklist

Correctness: How do you know that this design is correct?

The design is guided by the specifications given by the client.

Feasibility: What indicates that this design can be implemented and

tested with the planned amount of time and effort?
The design prioritizes the realization of the project within the given time
frame. The bases of the design are the past experiences of the developers on
project development. These experiences provided enough information to be
able to come up with an estimated schedule as well as a plausible division of
tasks.

Understandability: What makes this design understandable?

The design offers specific details about the project’s structural and behavioral
design using UML. It also includes a UML which describes the components.
There are supporting documents which not only contain comprehensive
description but also specify the purpose of components of the project, i.e.,
build configuration, naming conventions, and key directories and files.

Implementation phase guidance: Does the design suggest reasonable

implementation tasks?
Yes. The design is patterned after the agreed object model which clearly
defines the division of components.

Modularity: How have concerns been separated and addressed in

distinct modules?
The design ensured that a module can be implemented and tested
independently from other modules so that if ever there is an encountered
problem, it is only limited to a particular module.

Testability: What makes this system easy to test?

Because the system is highly modularized, testing can be done at each
module without infringing the other modules.

Efficiency: Does the system consume an acceptable amount of time,

storage space, bandwidth, and other resources?
The design did less consideration on this matter. But because this project is
relatively small, resources are not really much of a concern.
 Design > Architecture

Overview

What are the most important facts that a developer should know about
this system architecture?
2-tier web application: webserver/app-server, database.

What are the ranked goals of this architecture?

1. Ease of integration
2. Capacity matching

Components

What are the components of this system?

The components of this system are clearly defined in this UML Model with
Component Diagram.
The components of this system are listed below by type:
• Presentation/UI Components
o C-00: Login Page
o C-01: Administrator Page
o C-02: Dormitory Staff Page
• Application Logic Components
o C-03: DormKeeper Application
• Data Storage Components
o C:04: DormKeeper DB

Deployment
How will the components be deployed to processes and machines?
The deployment of components to processes and machines is clearly defined
in this UML Model with Deployment Diagram.

2-tier Web Application

• Tomcat Process
o C-03: DormKeeper Application
• Database Process
o C:04: DormKeeper DB

What aspects/resources of their environment are shared?

Everything is on one server so all machine resources are shared by all
components.

What alternative deployment configurations are possible?

 This is the only possible deployment.

Integration

How will components be integrated? Specifically, how will they

communicate?
All of our code uses direct procedure calls. Communication with the database
uses Torque-generated methods.

Architecture Checklist

Ease of integration: Have mechanisms been provided for all needed

types of integration?
Yes. In this system, all of the new components are designed to work together.
And, the reused components are integrated via fairly simple interfaces.

Has the architecture been communicated to the development team and

other stakeholders?
While there is communication at the development team level, there is not
much interaction with the actual client because of physical absence. This will
be addressed in the Risk Management section.
Design > Source Code Organization and Build
System
Overview
What are the most important facts that a developer should know about
this source code organization and build system?
The source code will be organized to the packages detailed in the table below
and will use the directory structure and package naming conventions.

What are the ranked goals of this source code organization and build
system?
1. Separation of files by type
2. Separation of version-controlled files from files generated by the build
process
3. Compatibility with standard build processes

Key Directories and Files in Developer Working Copies

Path VC Description
build.xml Yes Build file
build.properties Yes Build properties file
src/ Yes Source code
src/java/ Yes Java source code
src/java/[nested Yes Java source code of classes in each package
packages]/
src/java/[nested Yes Java source code of unit tests for classes in each
packages]/test/ package
web/ Yes HTML and ZK files
web/css/ Yes CSS files, if any
web/images/ Yes Image files, if any
web/web-inf/web.xml Yes Java web application configuration file
conf/ Yes Configuration files, if any
data/ Yes Initial data to load into database and/or file
system, if any
lib/ Yes Libraries reused by this project, if any
www/ Yes Project documents (e.g., overview, plan,
requirements, and design)
build/ No Output of build process
build/web-inf/classes/ No Compiled code output by build process
dist/docs/api No API documentation output from build process
dist/dormkeeper.war No Deployable web archive of classes and
configuration files generated by build process

Build Targets
Target Description
Compile = Compiles Java source code and creates .class files under the "build"
default directory.
dist Packages the system for distribution/deployment to servers or end
users. Specifically, it creates .war archive of compiled classes and
configuration files.
install Places executable code into location where it will actually be
executed. Specifically, it copies .war file into Tomcat's webapps
directory for use. You must then restart Tomcat or use the "reload"
link in the Tomcat Manager.
javadoc Generates Java API documentation under "build/docs/api/".
clean Deletes files generated by previous build commands. Files under
version control are not touched.

Build Configuration Options

Property Description
dormkeeper The name of this application. This should
be one short word. Used in the name of
resulting package files. Specifically,
the .war file. And, it will be used to
access the application via
http://localhost:8080/APP.NAME/
dormkeeper.version Version number of this release. Used in
the name of resulting package files.
Specifically, the .war file.
webapps.path Path to the Tomcat "webapps" directory.
Defaults to C:\Program Files\Apache
Software Foundation\Tomcat 5.5\webapps

Source Code Organization and Build System Checklist

Separation of files by type: Are files separated by type?
Yes. All files are separated by type.

Separation of version-controlled and non-version controlled files: To what

extent has this been achieved?
It has been achieved. Everything is under version control except for the
“build” directory. No step in the build process should create or modify any file
in any other directory.

Have these implementation decisions been communicated to the

development team and other stakeholders?
No, this is a risk that is noted in the Risk Management section
Design > User Interface

Overview

What are the most important facts that a developer should know about
the user interface of this system?
• The UI should be as user friendly as possible so the users will not
have a hard time to understand it.
• The flow should enable the user to browse fast into the system
so when the customer queue is stacking up the system will be able to
handle it.

What are the ranked goals for the user interface of this system?
1. Understandability and learnability
2. Task support and efficiency
3. Safety
4. Consistency and familiarity

Metaphors, Exemplars, and Standards

What is the central metaphor of this UI design?

UI design is the helper of the dormitory staffs which will make their works
easier.

What existing systems have user interfaces similar to the UI you want
to build? What specific aspects are similar?
• Sancofa: Online Examination System (CMSC100 Project): Our
system will look like and will have a flow like this system.

What UI design standards, guidelines, and styles are you following?

• Microsoft UI guidelines
• Java UI guidelines
• W3C Accessibility guidelines

Task Models
 What types of users will use this system?
See the user needs document.

What types of tasks will those users perform?

See the use case suite.

Content Model / Interaction Contexts

Interaction
Context
--Abstract
Purpose Contents / Constraints / Behavior
UI
Component
s
Verify that the current user The page asks user to input his username
Login Page is actually the person that and password, then to click to the button
they claim to be. corresponding to his/her user type.
An image to show they are using our
--Banner Show the system’s banner
system
The name of the user account. Regex: [-_a-
z0-9]{1-16}. The application should not do
Identify the user account
anything that would help users guess
--Username that the current user is
usernames. E.g., this should not be a
trying to access.
combo-box with recent users listed, and it
should not offer auto-complete.
Verify that the current user
The password of 4-16 characters. Do not
knows a secret password
display the password on the screen. The
--Password that only the true user of
application should not do anything that
that user account should
would help users guess passwords.
know.
Allow the user to indicate "Login" Only enabled when Username !=
that they have completed "". If the username or password is
--Login
entry of their username incorrect, delay a few seconds, and then
and password. clear all fields.
This is where all the links
Home are shown to enable faster
browsing.
The links are all put here so These will serve as shortcuts to go to other
--Menu
they are easy to find pages
This is where all the
--Main Depending on what page you are in, this
primary information is
Window part is the one that changes its contents.
shown.
 Tell the user the current
--Date Panel date to guide him/her for E.g. Monday | January 28, 2008
dormitory transactions
Provide user with help
This will contain descriptions for each
--Help Panel regarding the use of the
module; may contain how-to’s
system
--Footer Show copyright Displayed at the bottom of every page
Assist registration of new
New Account
dormitory residents
Identify the last name of
--Last Name Asks for the resident’s last name
the applying student
--Middle Identify the middle name of
Asks for the resident’s middle name
Name the applying student
Identify the first name of
--First Name Asks for the resident’s first name
the applying student
Insert the full name of the Checks the last name, middle name, and
--Submit applying student to the first name fields for invalid inputs; Auto-
database capitalize first letter
--
Provide feedback for the Tells the user whether the process was
Confirmatio
user successful or not
n
Allow editing of information
Edit Profile
about a resident
Displays the full names of the residents in
Show the user a list of full
--Full name the following format: Last name, First
names of the residents
Name, M.I.
Show the user the date
--Application Displays the date in the following format:
when the resident
Date HH:MM AM/PM| Month DD, YYYY
completed his registration
Redirect user to the page ‘Edit’ button is aligned with residents
which contains the current names; clicking an ‘Edit’ button will
--Edit
information about a redirect the user to the profile of the
resident corresponding resident
Delete Allow user to delete
Account resident accounts
Show user the list of Displays full name in this format:
--Full Name
residents Last name, First Name, M.I.
Show user corresponding Displays date in this format:
--Date
registration dates HH:MM | Month DD, YYYY
Delete specific resident Inactivates the respective account of the
--Delete
account resident when the 'Delete' button is clicked
-- Show user that deletion Contains text explaining that specific
Confirmatio was successful resident's account is deleted
 n
Statement of Allow user to issue
Account statement of account
Identify the first name of
Asks the user to input first name;
the resident who will be
--First Name existence of the first name in the database
issued of Statement of
will be checked
Account
Identify the middle name of
Asks the user to input middle name;
--Middle the resident who will be
existence of the middle name in the
Name issued of Statement of
database will be checked
Account
Identify the last name of
Asks the user to input last name; existence
the resident who will be
--Last Name of the last name in the database will be
issued of Statement of
checked
Account
Input should be multiple of the agreed
Identify the payment of the dormitory fee; rate is based on Philippine
--Dorm Fee resident for his/her stay in Peso (Php)
the dormitory

Identify the overall total of Each appliance has its corresponding fee;
--Appliance payment for the appliance rates are set by the administrator at the
Fee of the resident, if there is start of the semester; rate is based on
any Philippine Peso (Php)
--
Identify the amount to be Asks the user to enter an amount for the
Reservatio
paid as reservation fee reservation fee
n Fee
Checks the fields of the form for Statement
--Print Print Statement of Account of Account; entered name should exist in
the database
Register appliance(s),
Register which will be used inside
Appliance the dormitory, owned by a
resident
Asks the user to input first name;
Identify the first name of
--First Name existence of the first name in the database
the owner of the appliance
will be checked
Asks the user to input middle name;
--Middle Identify the middle name of
existence of the middle name in the
Name the owner of the appliance
database will be checked
Asks the user to input last name; existence
Identify the last name of
--Last Name of the last name in the database will be
the owner of the appliance
checked
--Appliance Classify appliance Classification of Appliances: Electric fan,
Computer without printer, Computer with
 printer, and refrigerator
Provide a unique
--Control
identification for each Autogenerated 5-digit number
Number
appliance
--Date Record the installation date
ZK datebox
Installed of the appliance
Insert the data entered to
--Submit None of the fields should be empty
the database
Cancel Withdraw the use of an
Appliance appliance
Show the owner of the
--Full Name Last Name, First Name, Middle Initial
appliance
--Control Show the control number of
Must be unique
Number the appliance
Classification of Appliances: Electric fan,
--Type of
Show the type of appliance Computer without printer, Computer with
Appliance
printer, and refrigerator
Inactivates the appliance horizontally
aligned with the ‘Cancel’ button; an
--Cancel Inactivate the appliance inactivated appliance will no longer be
charged of appliance fee; redirects the
page to the confirmation page
Report Report violation committed
Violation by a resident
Asks the user to input first name;
Identify the first name of
--First Name existence of the first name in the database
the violator
will be checked
Asks the user to input middle name;
--Middle Identify the middle name of
existence of the middle name in the
Name the violator
database will be checked
Asks the user to input last name; existence
Identify the last name of
--Last Name of the last name in the database will be
the violator
checked
--Nature of Identify the nature of Types of Violation: (refer to the dormitory’s
Violation violation house rules)
--Date of Record the date when the
ZK datebox
Violation violation was committed
Check-in
Admit transient
Transient
Identify the first name of
--First Name ZK input box
the transient
--Middle Identify the middle name of
ZK input box
Name the transient
 Identify the last name of
--Last Name ZK input box
the transient
Autocomplete (source: residents’ table of
Identify the full name of the
--Guarantor the database); input should be one of the
guarantor
entries in the residents’ table
Insert data into the Checks the field of the form; redirects the
--Submit
database page to the confirmation page
Check-out
Dispatch Transient
Transient
--Full Name Show transient’s full name Last Name, First Name, Middle Initial
--Admission Show when the transient
HH:MM | Month DD, YYYY
Date/Time checked in
Inactivate the transient’s Redirects the page to ‘Issue Statement of
--Dispatch
record Account’
View All List all residents of the
Residents dormitory
Show the full names of the Linked to the residents’ respective pages
--Full Name
residents which contain their profile
List all violations
View
committed for the current
Violations
semester
Show the full names of the Linked to the residents’ respective pages
--Full Name
violators which contain their profile
--Nature of Show the nature of
ZK Label
Violation violation committed
Show the date when the ZK Label
--Date
violation was committed Month DD, YYYY
--Remarks Show the action taken ZK Label
View Show all the registered
Appliances appliances
Show the owner of the
--Full Name Last Name, First Name, Middle Initial
appliance
Classification of Appliances: Electric fan,
--Appliance Classify appliance Computer without printer, Computer with
printer, and refrigerator
Provide a unique
--Control
identification for each Autogenerated 5-digit number
Number
appliance
--Date Record the installation date
Month DD, YYYY
Installed of the appliance
View Show all transients who
Transients have not yet checked out
 Show the full names of the
--Full Name Last Name, First Name, Middle Initial
transients
Show the name of the Last Name, First Name, Middle Initial;
--Guarantor
guarantor should be resident of the dormitory

Technical Constraints / Operational Contextualization

What are your assumptions about the output devices?

We assume that the user has a 17-inch or larger screen with 1024x768 pixels
that can display thousands of colors (16 bit or more). We assume they will
use Mozilla Firefox as their web browser. We will not use any audio features.

What are your assumptions about the input devices that you will use?
We assume only that the user has a standard keyboard and mouse.

What are your assumptions about the amount of time users will spend
on tasks?
The module which is expected to take about 10 minutes to finish is the filling
up of resident’s information. The rest of the modules which require the user
to provide inputs will take 2 minutes on the average. Viewing and printing will
require at most 5 seconds.

What windowing systems, UI libraries, or other UI technologies will you

use?
ZK framework
Standard HTML, CSS and Javascript

User Interface Checklist

Understandability and learnability

Are there any labels of icons that are likely to be misunderstood?
The icons will have their own captions so the users will understand them.

Is the user's current place and state clearly visible?

Yes. The UI displays module name (which somehow provides cues about the
module) the user is currently working on.

Are there no invisible options or commands? E.g., hold down the control
key when opening a dialog box to see advanced options.
None, we only included necessary options so that it will not be too
complicated.

Task Support and Efficiency

Which use cases force the user to perform slow or difficult UI steps?
E.g., entering a long code number like an ISBN. E.g., long mouse-drag
operations.
 Entering the data of the resident

Safety
Are there any dangerous or irreversible actions that are done with only
one step?
None. Any action which may affect the data asks the user for confirmation.
Once confirmed, the only way to reverse it is to prevent the system from
committing the changes to the databases before it uploads data to the
Internet.

Consistency and Familiarity

Do UI elements in your system work the same as they do in the existing
example systems you identified?
Yes, the elements will also work like the ones in Sancofa.

Do all elements in your system that appear the same, actually function
the same?
Yes.

Are all elements share consistent visual characteristics such as font

and color scheme, unless there is a reason for them to differ?
Yes.

Are labels used consistently throughout the system? E.g., not

"forward/back" in some contexts and "next/prev" in others.
Yes.

Design > Persistence

Overview

What are the most important facts that a developer should know about
persistent data storage in this system?
• The developer should know how much data can be stored in the
system.
 • The developer should also know how large the data is to be
stored.

What are the ranked goals for persistence in this system?

1. Data capacity
2. Expressiveness
3. Data security
4. Performance
5. Ease of access
6. Reliability
7. Interoperability

Central Database

What is the logical database design?

The logical database design is described in this UML model or this ER
diagram.
Additional logical constraints on the database are:
• A student can register only once every semester. Only Freshmen
can avail the services of the dormitory residency.
• The student is required to pay his/her accounts every month.
These accounts can include appliances if the student has any.
• The database can be accessed only by the Dormitory staff & the
Administrator. The Dormitory staff can add or register students. The
Administrator can add the dormitory staff & can configure the
database.

What are the physical tables and views?

The physical database design is described in this UML model or this ER
diagram.

How will objects in the application be stored in the database?

We will use a database table for all of the residents in the dormitory. It will
also contain the information of the residents. We will use a library to do our
object-relational mapping specifically torque. There will also be separate
tables for dormitory staffs and dormitory residents as well as views for
payments, violations, and transients.

What database access controls will be used?

A database administrator account will be created to access the needed
application database tables.

Is this application's central database accessible to other applications?

No. This database should always be accessed through this application. All
relevant pieces of information are available through the application
interfaces. The database itself does not protect against data corruption that
could be caused by other applications.
File Storage
What data needs to be stored in files?
The server stores most data in the database. It also uses the network to act
as back ups in case of any unexpected deletion of the database. The
information and transactions of the residents are to be stored in SQL files.

What are the conventions for directory structure and file naming?
Files are stored on the server as data/dormkeeperYYYYSSSMM.dat
*YYYY – Year SSS – Semester MM – Month

What file system access controls will be used?

Users can use whatever file permissions they like.

What file format will be used?

• Database information will be saved in a binary file (.dat)
• Settings of the database are specified in XML file
• Schema of the database is specified in XML file
• All modules will be written in ZUL
• Java files

Distributed Storage
What information (if any) will be stored on client machines? For how
long?
All the user data will be stored on files on their computers for a minimum of
one month

Persistence Mechanisms Checklist

Expressiveness: To what extent has this been achieved?

When the dormitory staff adds new residents on the dormitory database,
he/she will enter the residents’ information. The inputted data will be stored
in the database of the system.

Ease of access: To what extent has this been achieved?

The data in the database can only be accessed by the administrator or the
student assistants. A password will be provided for both of the users in order
to provide security for the data involved.

Reliability: To what extent has this been achieved?

The application has all of its data in a database. Back-ups for the database
are also provided.

Capacity: To what extent has this been achieved?

 This system is expected to provide back ups to the database so that if the OS
the application will be running doesn’t have enough memory capacity, the
large data can be stored.

Security: To what extent has this been achieved?

The system is can only be accessed by the administrator the Student
assistants. For security purposes, a password will be provided.

Performance: To what extent has this been achieved?

The data in the database is easily accessed every time the administrator
checks the accounts of the residents.

Has the persistence design been communicated to the development

team and other stakeholders?
While there is communication at the development team level, there is not
much interaction with the actual client because of physical absence. This will
be addressed in the Risk Management section.

DESIGN – SECURITY
Overview

What are the most important facts that a developer should know about
the security of this system?
• The developer focuses more on the application security.
• The developer has a trust on the dormitory staffs that they will
not use the system for unnecessary purposes or actions not related to
the dormitory services.

What are the ranked goals for security in this system?

1. Data security
2. Intrusion prevention
3. Abuse prevention
4. Auditability

Security Mechanisms
What physical security mechanisms will be used?
• Server will be kept in a secured room
• Only the administrator has the access to the server

What operating system security will be used?

• Operating system permissions on files and directories are set to
prevent undesired access or modification.

What application security mechanisms will be used?

• Values input into every field are validated before use
• Values input into every field will be free from any scripting
attacks
• Usernames and passwords are required for access
• Passwords are stored encrypted
• Verification of usernames
• The quality of passwords is checked
• Users are given roles that define their permissions. Those roles
are:
o Administrator: Permission to add new user accounts, delete
account, modify existing password.
o Dormitory staff: Permission to create new resident account, view
or update pending registrations, edit resident’s profile, issue
statement of account, report violations, register and cancel
appliances and check-in and check-out transients
• Each action (information display or change) requires that the
user has a role with proper permissions
• Administrators can review dormitory staff permissions
Security Checklist
Protection of data: To what extent has this been achieved?
There will be back-up copies of all the files

Prevention of intrusion: To what extent has this been achieved?

All entries on the input boxes will be free from any scripting attacks.

Accountability/auditing: To what extent has this been achieved?

All information in the database will be saved in the Internet monthly and can
be retrieved for auditing

Have these security mechanisms been communicated to the

development team and other stakeholders?
While there is communication at the development team level, there is not
much interaction with the actual client because of physical absence. This will
be addressed in the Risk Management section.

C-00 : Login Page

 Description: The page asks user to input his username and password, then to
click to the button corresponding to his/her user type. Login page
verifies that the current user is actually the person that they claim
to be.

Environmental Mozilla Firefox (browser), Java Runtime Environment, at least 15”

Constraint monitor with at least 16-bit color configuration

Available Username (input box), Password (input box), Login (button)

Interfaces

C-01: Administrator Page

Description: The page contains the functionalities that are available for the
administrator

Environmental Mozilla Firefox (browser), Java Runtime Environment, at least 15”

Constraint monitor with at least 16-bit color configuration

Available Administrator Menu

Interfaces • New Account
• Modify Password
• Delete Account
• View All Accounts
• Configure System
• Documentation

C-02: Dormitory Staff Page

Description: The page contains the functionalities that are available for the
dormitory staff

Environmental Mozilla Firefox (browser), Java Runtime Environment, at least 15”

Constraint monitor with at least 16-bit color configuration

Available Dormitory Staff Menu

Interfaces • New Account
• Pending Accounts
• Edit Profile
• Delete Account
• Statement of Account
• Register Appliance(s)
• Cancel Appliance(s)
• Report Violation(s)
 • Check-in Transient
• Check-out Transient
• View All Residents
• View Unsettled Fees
• View Violations
• View Appliances
• View Transients

C-03: DormKeeper WebApp

Description: .war file which contains all the classes, style sheets, etc.; the gist
of the entire project

Environmental Mozilla Firefox (browser), Java Runtime Environment, at least 15”

Constraint monitor with at least 16-bit color configuration, Tomcat, Database

Available DormKeeper Class

Interfaces Resident Class
Statement of Account Class
Transient Class

C:04: DormKeeper DB

Description: Database constructed using MySQL which will contain all the data
of the web application

Environmental Windows 9X/Windows XP, at least 256MB RAM

Constraint