BNCC Information System

BNCC Information System
System Design
Prototype: Alpha One

Member Services
Event Attendance
July 22, 2002

Sasmito Adibowo
Wiratna Sari Wiguna
Yusri
Arcle Technologies
SIMPLE RELIABLE SOLUTIONS

Table of Contents
About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
People Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
People Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Member Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Administrative Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Event Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Shared Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Data-Access Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Member Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Sample Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Event Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Sample Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
System Design
1 About This Document

This document provides the design specification for the prototype of your
new information system, code-named Buncis. The prototype consists of
member services and attendance (which is a part of the planned event
organizer) modules. Like any other system designs, this document only acts
as a guide for the implementation and does not make every required
implementation decision. Included in the design is the system's general
architecture, database design, user interface design, business processes,
and significant classes that will be placed in the system.
1.1 Project History
BNCC is a Student Activity Unit that operates under the consent of Bina
Nusantara University. It is organized as a club that focuses on computer-
related interest groups. It maintains an approximately constant sum of
300 – 400 members yearly, which most of the new members among them are
first-year undergraduates. Its activities include tutoring, member meetings,
annual publications, visitations, contests, seminars, expositions, and
research. Its major income come from the yearly members' fees and
sponsors.
At the core of BNCC lies a committee that organizes all of its activities. The
committee is divided categorically into several major divisions, and each led
by a Division Chair. Each chair is organized horizontally and answers
directly to the General Chair.
The need for an information system was expressed in a meeting conducted
by Faran Gunawan, – the former coordinator of Fave Club, now the general
chair. Fave Club recognizes that the increasing number activities of BNCC
and likewise the number of members involved in it poses a growing load to
its core committee. To provide better service for its members, BNCC requires
a strong information system to back its daily activities.
The current information system employed by BNCC is primarily a manual
system. The uses of computers are limited in the creation and storage of
free-form documents and tables. Those documents and tables are created as
files by standard office applications – such as word processing, spreadsheet,
and file-based database software. There are no provisions to impose
structure to those data, which creates difficulties in assessing information
from them. This ad-hoc system – although it has been used for a significant
amount of time – has impeded the performance of BNCC in servicing and
maintaining its members.
Since its first conception, Buncis has received positive attitudes from the
organization. Additionally, it has expresses its commitment through the
http://www.arcle.com Page 3 of 39
System Design
mandates assigned to both Fave Club and the Organization Development

Team divisions in favor of Buncis’ development.
The design phase of the project has been initiated. Because of the urgent
need of a member registration and attendance system, the implementation of
those parts of Buncis are made prominent. Therefore, the initial prototype
consists of those modules.
2 General Description
2.1 System Architecture
Architecturally, the system is separated into three primary subsystems: The
Presentation Logics, the Business Logic, and the Data-Access Objects. This
separation is modeled after the Model-View-Controller pattern, where the
Presentation Logic interacts with the user acting as the View, the Data-
Access Objects provides a model of the data, and finally the Business Logic
controls the interaction between the two.
Data-
Security Control
Access
Presentation Business
Objects
Logic Logic
Value
Objects
User
SQL Database
Figure 1 Buncis Architecture Overview
This architecture is selected to minimize the impact of change to the system.

For instance, accommodation of new user interfaces will only affect the
Presentation Logics. Likewise, changes in the database schema and/or
DBMS will mostly affect the Data-Access Objects with minimal (if any)
impact to the other components.
The Data-Access Objects (DAO) perform queries to the database. Only the
classes in this layer may perform JDBC/SQL queries to the DBMS. Other
components that require to access the database must go through the
methods in this layer. Data-Access Objects are also responsible for
maintaining referential integrity of the records in the database.
The Business Logic (BL) layer implements the business processes embedded
in the system. Classes in this layer define how data are to be manipulated
from a business perspective. This layer relies on the Data-Access Objects to
actually manipulate the data in the database. Changes in business policies
and/or workflow will mostly affect the classes in this layer.
System Design
Consisting of JSP pages, the Presentation Logic drives the user interface.
It provides user screens and accepts user input. User commands are
translated into one or more actions in the Business Logic by this layer. By
not performing business processes in the user interface, more user
interfaces may be accommodated without re-coding the business process
layer.
Attached to the Business Logic is the Security Control layer. This layer
determines whether the currently logged-on user is allowed to access
specified functionalities of the Business Logic. Upon entry at each method
in the Business Logic, the invoked method first queries the security control
before executing the algorithm it contains. If the user is allowed access,
then the method will continue to execute normally. Whereas the user
doesn’t have access to the functionality, the method will throw an exception
without executing any further.
Instantiated by the Data-Access Objects, the Value Objects are simple data
structures. Value Objects are -- by definition -- unintelligent, and must not
perform processing on its own; the methods of these objects are only
accessor methods. These objects are passed around as parameters in the
system as required.
2.1.1 Prototype notes
Currently, the Alpha One prototype does not implement the Security Control
layer – thus security is not enforced. The Security Control layer design will
be included in the User Management module.
3 Database Design
3.1 People Tables
One of the goals of Buncis is to record the interaction of BNCC with other
parties. This includes the people within and outside the organization. In
relation to people, Buncis stores information about activists, staffs, seniors,
and contact persons.
System Design
person
person_id staff
person_id (FK)
name
active_year
gender
email active_position
birthday
home_address senior
home_phone person_id (FK)
mobile_phone last_active_year
personal_notes
dt_lastupdate last_staff_position
contact_person
person_id (FK)
member activist
organization_name (FK)
person_id (FK) person_id (FK)
office_address membership_year active_year
office_phone
office_email school_major division
dt_lastupdate
Figure 2 People Tables
3.1.1 Person
The person table is the primary table which stores a person’s personal
information. Entries in this table are created upon the person's first contact
with BNCC.
person
Field Name Type Constraints Description

person_id String primary key For people who have a student’s identity
card, this field is generated from the bar-code
printed on the card. For others, this value is
randomly generated in such a way that it will
not conflict with a student’s identity card
number.
name String alternate The full name which that person is prefer to
key, not null be referred to.
gender Char none The sex group the person belongs to.
Consists of either “M” or “F” values, for male
or female, respectively.
email String none The primary e-mail address of the person, if
any.
birthday Date none The birth date of the person, if known.
System Design

home_address Memo none The primary residence address of the person,
if known.
home_phone String none The telephone number of the primary
residence, if known or exists.
mobile_phone String none The primary mobile telephone number, if
known or exists.
personal_notes Memo none Free-form text which contains various notes
about the person.
dt_lastupdate Date/ not null The timestamp of the record’s last update.
Time
3.1.2 Members
The member table stores data about members for each period of membership.
Those members who register for more than one period of membership will
have multiple entries in this table, but only one entry in the person table. It
is assumed that a membership period lasts for one year.
member

person_id String primary key The unique identification of the member
and foreign as a person.
key to person
(person_id)
membersip_year String primary key The member’s period of membership.
This value is expressed as a four-digit
year at which the member registered.
Examples of valid values are {2002,
2003, 2004, ...}.
school_major String none The member’s university major. This
value is expressed as abbreviations of
the major names. Examples of valid
values are {TI, MI, TK, KA, ...}.
3.1.3 Activists
The activist table contains records about activists during a period of
occupancy (which each occupancy is normally one year). Since activists are
also people, this table records the occupancies of the person in question as
an activist. It is facilitated in the system for a person to have more than one
activist occupancy period, in which he/she will have one record in the person
table, and one or more records in the activist table.
System Design
activist

person_id String primary key and The unique identification of the activist as a
foreign key to person.
person
(person_id)
active_year String primary key The activist’s period of occupancy. This
value is expressed as a four-digit year at
which the activist began his or her
occupancy. Examples of valid values are
{2002, 2003, 2004, ...}.
division String none The division(s) of the activist in which he or
she participates during occupancy. Multiple
divisions are separated by commas.
3.1.4 Staffs
The staff table contains data about staffs during their periods of occupancies.
Each record in this table stores data about a person during one period of
occupancy. When a person occupies more than one period, this table stores each
occupancy as one record, referencing to that person’s identification in the person
table.
staff

person_id String primary key The unique identification of the staff as a
and foreign key person.
to person
(person_id)
active_year String primary key The staff’s period of occupancy. This
value is expressed as a four-digit year at
which the staff began his or her
occupancy. Examples of valid values are
{2002, 2003, 2004, ...}.
active_position String not null Describes the position of the staff at this
period of occupancy.
3.1.5 Seniors
The senior table records data about staffs that are no longer in service. In other
words, seniors are retired staffs.
senior
System Design

person_id String primary key The unique identification of the
and foreign key senior as a person.
to person
(person_id)
last_active_year String primary key The senior’s last period of
occupancy. This value is expressed
as a four-digit year at which the
senior ends its occupancy.
Examples of valid values are {2002,
2003, 2004, ...}.
last_active_position String not null Describes the last position as a staff
at this period of occupancy.
3.1.6 Contact Person

The contact_person table records data about people which played a role as a
representative for organizations outside of BNCC. The system allows a person to
represent more than one organizations, which is expressed by more than one record
in the contact_person table for that person.
contact_person

person_id String primary key and The unique identification as a
foreign key to person person.
(person_id)
organization_name String primary key and The name of the organization
foreign key to that the person represents.
organization
(organization_name)
office_address Memo none The branch/office address of the
organization in which this person
may be contacted.
office_phone String none The branch or office phone
number of the organization in
which this person may be
contacted.
office_email String none The branch/office e-mail address
of the organization in which this
person may be contacted.
dt_lastupdate Date/ not null Timestamp which this record
Time was last updated.
System Design
3.2 Member Services

These tables (Figure 3) store administrative data of the members. Those
data are magazines, member payments and magazine claims.
magazine member
magazine_id person_id (FK)
description membership_year
amount_in_stock school_major
dt_lastupdate
member_payment
member_take_magazine
person_id (FK)
magazine_id (FK) membership_year (FK)
person_id (FK) payment_date
membership_year (FK)
amount
dt_taken
Figure 3 Member Services tables

3.2.1 Magazine
The magazine table stores data about each printed edition of the magazines
published by BNCC.
magazine

magazine_id String primary key The identification number that signifies the
magazine’s edition. This number is unique
for each edition of the magazine, and is
printed as bar codes in the magazine.
Copies for the same edition have the
same identification number.
description String alternate The human-readable identification of the
key, not null magazine’s edition.
amount_in_stock Integer not null, >= 0 The number of copies for the current
edition which are still stored in stock.
dt_lastupdate Date/ not null Timestamp of the last update of this
Time record.
3.2.2 Magazine Claims
System Design
The member_take_magazine table records the members' magazine claims. Every

time a member claims a magazine, a record is inserted into this table. Each
member may only take one copy of a particular magazine edition.
member_take_magazine

magazine_id String primary key and foreign The identification number of the
key to magazine magazine taken.
(magazine_id)
person_id String primary key and foreign The person_id of the member
key to member who took the magazine.
(person_id)
membership_year String primary key and foreign The membership year of the
key to member member who took the magazine.
(membership_year)
dt_taken Date/ not null When was the magazine was
Time taken by the member.
3.2.3 Member Payments

The member_payment table keeps track of each member's installments. An
entry in this table is inserted when a member provides payment. These
installment data are used to validate the member's access to the
events/facilities provided by BNCC.
member_payment

person_id String primary key and The person_id of the member
foreign key to member providing the payment.
(person_id)
membership_year String primary key and The membership year of the
foreign key to member member providing the payment.
(membership_year)
payment_date Date primary key When was the payment provided.
amount Real not null, > 0 The amount of payment provided, in
monetary units.
3.3 Administrative Services
System Design
event
person event_name
person_id
event_start
name event_finish
gender
email
birthday
home_address
home_phone attendance
mobile_phone
person_id (FK)
personal_notes
dt_attend
dt_lastupdate
event_name (FK)
Figure 4 Administrative Services tables
3.3.1 Attendance
The attendance table records data about people who attend the various events
held by BNCC. It is assumed that a person may not attend more than one
event at an instance of time.
attendance

person_id String primary key and foreign key The Person’s ID of the attendee.
to person (person_id)
dt_attend Date/ primary key The timestamp at when the person
Time attends.
event_name String not null, and foreign key to The event attended.
event (event_name)
3.4 Event Organizer
System Design
contact_person
organization
person_id (FK)
organization_name
organization_name (FK)
primary_address
office_address
primary_phone
office_phone
primary_website
office_email
dt_lastupdate
dt_lastupdate
event
event_name
event_start
event_finish
Figure 5 Event Organizer tables
3.4.1 Events
The event table store data about the various events held by BNCC. Events
are identified by their name, which must be unique for all events. Therefore,
recurring (periodic) events must be made unique by appending the event
name with time information (for example: "FA May 2003").
event

event_name String primary key The name of the event. Since this field is the
primary key, event names must be globally
unique for all events.
event_start Date not null The start date of the event.
event_finish Date none The finish date of the event. If this date is not
known, it may be null.
3.4.2 Organizations
The organization table stores data about other organizations that came into
contact with BNCC. Organizations are identified solely by their names.
organization

organization_name String primary key The name of the organization. This name
must be globally unique for all
organizations.
System Design

primary_address String none The address of the head office of the
organization.
primary_phone String none The telephone number of the head office of
the organization.
primary_website String none The website address for the organization.
Typically this is a URL which contains only
the host name without any paths.
dt_lastupdate Date/ not null Timestamp which this record was last
Time updated.
4 Shared Components
4.1 Value Objects
System Design
ValueObject
(from data)
PersonVO
(from data)
ReportVO
name : Stri ng (from data)
gen der : Stri ng
emai l : String
birthday : Date
homeAddress : Stri ng
homePhone : String
mobi lePho ne : String
TableModel
personalNote s : String
dtLastU pdate : Timestamp (f rom table)
personID : String
addTableModelListener()
getNam e() : String getColumnClass()
getGender() : String getColumnCount()
getEm ail() : Strin g getColumnName()
getDtLastUpda te() : Times tamp getRowCount()
getPersonID() : PersonID getValueAt()
getBi rthday() : Date isCellEditable()
getHom eAddre ss() : String removeTableModelListener()
getHom ePhone() : Stri ng setValueAt()
getMobi lePho ne() : String
getPersonal No tes() : String
setNam e(name : Stri ng) : vo id
setPersonID(id : String) : voi d
setGender(gen der : Stri ng) : void
setEm ail(g ender : String) : void
setBi rthday(bi rthday : Date) : vo id
setHom eAddre ss(homeAddress : Stri ng) : void
setHom ePhone(homePho ne : String) : void
setMobi lePho ne(mobi lePho ne : String) : void
setPersonal No tes(personal Notes : String) : void
setPersonID(personID : String) : void
Figure 6 Shared value objects
4.1.1 PersonVO
Each PersonVO object represents a record in the person table. Like other value
objects, the methods in the PersonVO class are only accessor methods.
PersonVO
System Design
Property Field Notes

personID person_id
name name
gender gender
email email
birthday birthday
homeAddress home_address
homePhone home_phone
mobilePhone mobile_phone
personalNotes personal_notes
dtLastUpdate dt_lastupdate This VO property is read-only, the related field is

updated only by the DAO classes.
4.1.2 ReportVO
Unlike most other value objects, ReportVO does not correspond to any table.
Instead it is used to model spreadsheet-style report contents. The
representation is done through the implementation of the TableModel interface
(from javax.swing.table).
4.2 Data-Access Objects
DataAccessObject
(from data)
LoginSess ion
(f rom con trol )
1 0..* getPoolManager() : ConnectionPoolManager
<<factory method>> createEmptyList() : List
PersonDAO
(from data)
getPerson(personID : String) : PersonVO

insertPerson(person : PersonVO) : void
createPersonVO() : PersonVO
updatePerson(person : PersonVO) : void
Figure 7 Shared Data-Access Objects classes
System Design
4.2.1 DataAccessObject
The DataAccessObject class is the base class of all the classes in the Data-
Access Object layer. This class and its derivatives send SQL statements to
the database. It also maintains the referential integrity of the tables it
maintains.
Besides data access, this class provides methods useful for data access,
such as DBMS connection management and object creations.
Method Summary
public getPoolManager()
ConnectionPoolManager Returns the object used for database connection pooling.
public List createEmptyList()
A factory method [Gof95] to create objects which implements
the List (from java.util) interface. This method is to be used
by derived classes when returning a collection of objects.
4.2.2 PersonDAO
The PersonDAO provides access to the person table. This table stores data
about people who encountered the organization.
Method Summary
public createPersonVO()
PersonVO The primary factory method [GoF95] to create PersonVO objects.
public getPerson(String personID)
PersonVO Returns the personal data associated with the specified person's ID.
public insertPerson(PersonVO person)
void Creates a new entry in the person table. The new entry's personID must not
already exist in the database.
public updatePerson(PersonVO person)
void Updates the specified entry in the person's table. The personID property of
the value object specifies the table to be updated, while the other properties
specifies the new values of the record.
4.3 Business Logic
System Design
BusinessLogic uses
(f rom business)
Dat aAc cessObjec t
(f rom data)
1..* 1..*
PeopleManager
(f rom busin ess)
viewPersonProfile(personID : String) : PersonVO

<<factory method>> createPersonVO() : PersonVO
Reporter
(from business)
getMemberListByYear(membershipYear : String) : ReportVO

getTopActivists(numActivists : int = 10, activeYear : String) : ReportVO
getMemberListByMajor(membershipYear : String, schoolMajor : String) : ReportVO
getPersonDAO() : PersonDAO
createAttendanceReportVO() : AttendanceReportVO
generateAttendanceReport(eventName : String) : AttendanceReportVO
getEventDAO() : EventDAO
<<factory method>> createReportVO() : ReportVO
Figure 8 Shared Business Logic classes
4.3.1 PeopleManager
The PeopleManager class is responsible for managing the lowest-common
denominators of people data recorded by the system.
Method Summary
public createPersonVO()
PersonVO Pass-through to PersonDAO.createPersonVO() factory method [GoF95].
public viewPersonProfile(String personID)
PersonVO Returns the person's personal data.
4.3.2 Reporter
The Reporter class is responsible for generating various reports from the data
in the database. To obtain the data used in creating the reports, it uses
most of the DAO classes. The reports generated are in one-dimensional
spreadsheet-style report tables, represented in ReportVO objects. This
facilitates further data analysis and formatting by using general-purpose
spreadsheet packages.
System Design
Method Summary
public ReportVO getMemberListByYear(String membershipYear)
Returns a list of all members for the specified year.
public ReportVO getTopActivists(int numActivists,String activeYear)
Returns the most active activists for the specified year.
public ReportVO getMemberListByMajor(String membershipYear, String
schoolMajor)
Returns a membership year grouped by their majors for the
specified year.
public PersonDAO getPersonDAO()
Returns the PersonDAO object used to query the database.
public createAttendanceReportVO()
AttendanceReportVO The primary factory method [GoF95] to create new instances of
AttendanceReportVO objects.
public generateAttendanceReport(String eventName)

AttendanceReportVO Generates an attendance report for the specified event.
public EventDAO getEventDAO()
Returns the EventDAO object used to query the database.
public ReportVO createReportVO()
The primary factory method [GoF95] to create new instances of
ReportVO objects.
4.3.2.1 Attendance Report

The generate attendance report business process (Figure 9) is performed by
the Reporter.generateAttendanceReport() method. This method first retrieves
the list of all attendees for the event from the EventDAO object by calling
getAttendanceByEventName(). Since the list of AttendanceVO objects refers to a
person only by his/her person ID, the list must be formatted to fit human
consumption. Formatting the list is done by providing names and details of
each attendees that are obtained from the PersonDAO object by calling
getPerson() repeatedly, one for each attendees.
System Design
: Reporter : EventDAO : PersonDAO : AttendanceReportVO
1: getPerson DAO( )
2: getAttendanceByEventName(String)
3: *getPerson(String)
4: crea teAttendance Re portVO( )
5: *setValueAt(Object, int, int)
Figure 9 Generate Attendance Report business process
5 Member Services
5.1 Overview
In the context of member services (Figure 10), a MemberDAO object is used by
two business logic objects: MemberManager and Reporter. The MemberManager uses
the DAO to manage member data, records the member’s payment data,
records magazine claims, and retrieves the history about those payments
and claims.
MemberManager Reporter MemberHistoryReportVO

(from business) (f rom busi nes s) (from data)
0..* 1 1..1
1
0..n
1 1 1
MemberVO MemberDAO Report VO
(f rom da ta ) 0..n 1..1 (from data) (from data)
Figure 10 Member Services classes overview
System Design
These DAO and BL classes uses MemberVO objects to express data about a
member. It contains the member’s personal data (which are inherited from
PersonVO) and data about his/her current membership.
5.2 Sample Screens

5.2.1 Member Registration
The Member Registration screen (Figure 11) Member Registration 1.2.1
allows registration along with data entry Period: 2002

about the member’s personal information Person ID
(name, address, phone, etc). It is visible that Name
the membership year is automatically filled E-mail
in (obtained from the system’s internal clock). Address
This screen is optimized for fast data entry,
where typing-intensive tasks are performed Phone
prior to selection tasks. Mobile Phone
The new member’s Person ID is obtained Birthday Day Month Year
from his/her student identity number. This Gender (select)
number is scanned from the bar code located Majoring (select)
in the student’s identity card. Register Clear
The birthday is entered numerically, with the Figure 11 Member Registration screen
day ranges 1–31, month 1–12, and year is
entered as four digits (such as 1984, 1985, etc.).
All fields except Person ID and Name may be left blank – although the
completion of all fields is desirable. When all data has been entered, the
user clicks the Register button to enter the member’s data.
5.2.2 Member Sign-on
For each event held by BNCC, members must sign Member Sign-On 1.1.1
on to validate access to the event. This is Membership Year: 2002
performed by Person ID:
1.1.2
scanning the OK Exit
Member name : Bunbun member’s

Figure 12 Member Sign-On
Membership year : 2001 identity card
Administrative Records to obtain his/her Person ID. The
Payments received : Magazines taken this year : screen is shown in Figure 12.
1. 22 Jan 2002 Rp. 150.000 1. Feb 2002 25 Feb 2002
2. 21 Feb 2002 Rp. 300.000 2. Apr 2002 25 Apr 2002
---------------- After signing on, the screen in Figure
SUM Rp 450.000
13 is displayed. This screen shows the
member’s administrative records,
Action
which are his/her payments and
Pay membership fee Take magazine
Magazine ID
magazine claims. The records
Amount Rp
displayed allow the operator to decide
Confirm Finish whether the member may or may not
Figure 13 Member Administrative Records participate in the event and/or claim a
System Design
magazine. Additionally, this screen may also be used to enter a record for
the member’s payment, or claim a magazine.
When a member decides to pay the fee, the operator places a check mark in
the Pay membership fee check box and then enters the amount paid in the
field provided. When a member claims a magazine, a check mark is placed
in the Take magazine check box and the taken magazine’s ID is entered in
the field provided nearby. This Magazine ID is obtained by scanning the bar
code located on the magazine. Both the Pay membership fee and Take
magazine actions may be performed in one step.
The Confirm button performs the take magazine
Person ID /
desired actions (pay or take, Start
Membership
or
pay fee
inclusively) and then re-displays the year entered
screen, showing the newly entered
records. While the Finish button 1.1.1 Waiting for Person ID 1.1.2 Waiting
and Membership Year input
returns to the Member Sign-On screen for action
(Figure 12).
exit
These screens follow the state quit
End
diagram shown in Figure 14. The
dotted numbers in the state names
Figure 14 Member Sign-On state diagram
correspond to the numbers shown in
the upper-right of each screens.
5.2.3 Interaction with the business logic
The Member Services user interface performs business processes by calling
the appropriate methods in the MemberManager class. An example in Figure 15
illustrates the methods called when a member claims a magazine.
1: Request person ID and membership year

2: viewMemberProfile(String, String)
5: show member records
3: getMemberPaymentHistory(String, String)
4: getMagazineClaimHistory(String, String)
: JSP for Member : Me mberManager

Services
6: memberClai mMagazine (String, String, String)
Figure 15 Member Magazine Claims user interface.
System Design
5.3 Value Objects

ValueObject
(from data)
Serializable
(f rom io)
PersonVO
(f ro m da ta)
Ta bleMode l ReportVO
(from data)
(f rom table)
MemberPaymentVO
MemberTakeMagazineVO (from data)
MemberVO (from data)
perso nID : String
(from data) personID : String mem bership Year : Stri ng
me mbershipYear : Stri ng membershipYear : String paym entDa te : Date
schoo lMajor : String magazineID : String amou nt : floa t
dtTaken : Timestamp
getMembershipYear() : String setPe rsonID()
getSchoolMajor() : Strin g setPersonID() getPe rsonID()
setMembershipYear(membe rshipYear : String ) : void getPersonID() setMem bershipYear()
setSchoolMajor(s choolMajor : String ) : void setMembershipYear() getMem bershipYear()
getMembershipYear() setPa ymentD ate()
setDtTaken() getPa ymentD ate()
MemberHistoryReportVO getDtTaken() setAmount()
(from data) getAmount()
Figure 16 Member Services value objects
5.3.1 MemberVO
MemberVO is derived from PersonVO, therefore it inherits all of the parent class'
properties. Each MemberVO object represents one record in the member table and
its corresponding parent record in the person table. Updates on MemberVO
objects affects both the member table and the person table.
MemberVO

membershipYear membership_year
schoolMajor school_major
5.3.2 MemberTakeMagazineVO
Each MemberTakeMagazineVO object represents one record in the
member_take_magazine table.
MemberTakeMagazineVO

personID person_id
System Design
magazineID magazine_id
dtTaken dt_taken
5.3.3 MemberPaymentVO
Each MemberPaymentVO object represents one record in the member_payment table.
MemberPaymentVO

personID person_id
paymentDate payment_date
amount amount
DataAccessObject PersonDAO
(from data) (from data)
MemberDAO
(from data)
<<factory method>> createMemberVO() : MemberVO

insertMember(newMember : MemberVO) : void
updateMember(member : MemberVO) : void
deleteMember(member : MemberVO) : void
getMemberVO(personID : String, membershipYear : String) : MemberVO
getMemberByCriteria(membershipYear : String, criterias : Map) : List
<<factory method>> createMemberPaymentVO() : MemberPaymentVO
insertMemberPayment(memberPayment : MemberPaymentVO) : void
insertMemberTakeMagazine(magazineClaim : MemberTakeMagazineVO) : void
<<factory method>> createMemberTakeMagazineVO() : MemberTakeMagazineVO
Figure 17 Member Services data-access objects classes
5.4.1 MemberDAO
The MemberDAO class manages data about the members. Member data are
stored in the following tables:
• people
• member
System Design
• member_payment
• member_take_magazine
Method Summary
public MemberVO createMemberVO()
The primary factory method [GoF95] to create new instances of
MemberVO objects.
public void insertMember(MemberVO newMember)

Inserts a new member in the member table. The parent record in
the people table corresponding to the member must already exist,
or this method will throw an exception.
public void updateMemberVO(MemberVO member)
Updates the member’s data. Both the member table and the
people table are updated.
public MemberVO getMemberVO(String personID, String membershipYear)

Returns data about a member with the specified person ID and
membership year. Data from both of the people table and
member table are retrieved.
public List getMemberByCriteria(String membershipYear, Map criterias)
Returns a List (from java.util) which contains MemberVO objects
for the members matching all of the specified criterias. The
criterias parameter is specified by a set of (String name, Object
value) pairs, where name is the field name requested (either from
the people table or from the member table) and value is the
matching value of the field.
public createMemberPaymentVO()
MemberPaymentVO The primary factory method [GoF95] to create new instances of
MemberPaymentVO objects.
public void insertMemberPaymentVO()

Inserts a new entry in the member_payment table. The foreign keys
(person_id and membership_year) must be valid at the time of
insertion (the referred records exists).
public createMemberTakeMagazineVO()
MemberTakeMagazineVO The primary factory method [GoF95] to create new instances of
MemberTakeMagazineVO objects.
public void insertMemberTakeMagazine (MemberTakeMagazineVO

magazineClaim)
Inserts a new entry in the member_take_magazine table. The
foreign keys (magazine_id, person_id, and membership_year) must
be valid at the time of insertion (the referred records exists).
5.5 Business Logic

5.5.1 Member Manager
The MemberManager business logic implements business rules concerning
member services. At the beginning of each method, a security check is
System Design
performed to verify whether the currently logged-on operator may perform

the desired business action. If access to the action is denied, the
corresponding method throws a security exception.
Note that not all of the required methods are explained in the text. These
unlisted methods are typically simple – they passthrough to the related
methods in the DAO after performing some security checks and setting some
easily-obtained values.
Method Summary
MemberVO createMemberVO()
Pass-through to MemberDAO.createMemberVO() to create an empty MemberVO
object.
public payMemberFee(String personID, String membershipYear, float amountPaid)
void Registers a member's payment. The amount paid must be greater than zero,
or this method will throw an exception.
public getMemberPaymentHistory (String personID, String membershipYear)
List Returns a List (from java.util) which contains MemberPaymentVO objects for
the specified member. The value objects returned represents a history of the
member's payments for this period.
public getMagazineClaimHistory(String personID, String membershipYear)
List Returns a List (from java.util) which contains MemberTakeMagazineVO
objects for the specified member. The value objects returned represents a
history of the member's payments for this period.
protected getMemberDAO()
MemberDAO Returns the MemberDAO object associated with this business logic.
5.5.2 Create Member

Member creation (Figure 18) is done when a member registers for a period of
membership (one year). This process is invoked by the presentation logic and
handled by the MemberManager business logic at the createMember() method.
This method expects an initialized MemberVO object specifying the new
member's data. Within the method, MemberManager first makes sure that the
candidate member's personal data (in the person table) already exists --
creating a new entry if necessary, or updating the existing entry. Then the
person's membership data for this period (the current membership year) is
created. The MemberDAO takes care of the actual details of handling the tables.
System Design
: JSP for Me mb er Ser vices : Se cu ri tyC on trol : MemberManager : Membe rDAO
The new member's createMember()

data entered called
verify operator
privileges
privilege records
obtained
[ access denied ]
[ a ccess granted ]
security clearance
approved
lookup profil e data

get PersonID of in the people table
the new m ember
insert new record in

[ data not exist ] the people table
update the current data

[ data exist ] in the people table
Person data
obtai ned
New member insert new record in

created the member table
Figure 18 Create Member business process
System Design
: MemberManager : MemberDAO
1: getMemberDAO( )
2: getPerson(String)
3: insertPerson(PersonVO)
4: insertMemb er(Mem berVO)
Figure 19 Member Creation sequence
5.5.3 Member Payment

The Pay Member Fee business process is handled by the
MemberManager.payMemberFee() method. The method first verifies that the
payment amount is larger than zero. If the condition does not apply, then
the method will throw an exception. The process is shown in Figure 20.
System Design
: JSP for Mem ber Ser vices : Secur ityContr ol : Mem ber Manager : Mem ber DAO
Member's payment payMemberFee()

data entered called
verify operator
privileges
privilege records
obtained
[ acc es s denied ]
[ access granted ]
security clearance
approved
check payment
am ount
amount > 0
insert member
pay ment recor ds
am ount < = 0
payment
denied
member payment
recorded
Figure 20 Pay Member Fee business process
System Design
: MemberManager : MemberPaymentVO : MemberDAO
1: getMemberDAO( )
2: createMemberPaymentVO( )
3: setPersonID(String)
4: setMemb ershipYear(String)
5: setPaymentDate(Date)
6: setAmount(float )
7: insertMemberP ayment(MemberPayment VO)
Figure 21 Sample sequence for Pay Member Fee business logic
A sample sequence of method calls is shown in Figure 21 -- the diagram

shows that after some intermediate checks, the method passes through to
the DAO. The intermediary MemberPaymentVO object is used for communicating
the payment data to the DAO. Note: the sequence diagram in Figure 21 do
not visualize the security checks that must be performed by the business
logic beforehand.
5.5.4 Magazine Claims
The Claim Magazine business process is handled by the
MemberManager.memberClaimMagazine() method. After performing the necessary
security checks, this method simply passes through to the corresponding
DAO object (Figure 22).
System Design
: JSP for Member Serv ices : SecurityControl : MemberManager : MemberDAO
Magazine ID, Person ID and memberClaimMagazine()

Membership Year entered called
verify operat or
privileges
privilege records
obtained
[ acc ess denied ]

[ access granted ]
security clearance get magazine

approved record
decrement magazine
amount in stock by one
update magazine
record
magazine
amount updated
insert magazine
claim data
magazine
claim recorded
Figure 22 Magazine Claims business process
System Design
: MemberManager : MemberDAO : MemberTakeMagazineVO
1: getMemb erDAO( )
2: createMem berTakeMagazineVO( )
3: setPersonID(String)
4: getMembershipYear( )
5: setDtTaken(Timestamp)
6: insertMemberTakeMagazine(MemberTakeMagazine VO)
Figure 23 Sample Claim Magazine sequence
6 Event Organizer
6.1 Overview
In the context of event organizer (Figure 24), an EventDAO object is used by
two business logic objects: EventManager and Reporter
EventManager 1
1
(f rom business)
0..*
1
0..* EventVO
AttendanceVO (from data)
(from data)
0..n
0..* 1
1 1..1
EventDAO
(from data)
Reporter 1..1 0..n ReportVO AttendanceReportVO

(f rom business) (from data) (from data)
Figure 24 Event Organizer Class Overview
System Design
The EventManager uses the DAO to manage event data, records the event’s
attendance data, and retrieves currently active events. These DAO and BL
classes uses EventVO objects to express data about an event. It contains the
event start and finish date, the attendance of the event, and of course the
event name.
6.2 Sample Screens
6.2.1 Create Event
The event creation screen (Figure 25)
Create Event
allows the event manager to create a
new event in the database. The fields Event Name
to be filled in are the event name, the
event start date, and the event finish Event Start
date. If the event manager wishes to
create an event that is not expected Event Finish
to end (such as the secretariate
event), the event finish field should Create
not be filled. Events are identified by
their names, thus the name of the Figure 25 Create Event user interface
newly-created event must not already
exist in the database.
After all the fields (except event finish) has been filled in, the event manager
then clicks the Create button and the new event will be created. This event-
creation process will fail if there is an already-existing event with the same
name in the database.
6.2.2 Attend Event
After an event has been created, it can Attendance 3.1.1
be attended by many people. To start
the attendance service, the operator will Attend to active events
12 April 2001
ending not after:
bring up the attendance screen shown
in Figure 26. This screen will prompt Please select the event name :
the operator to select the event for FA April 2001
which the attendance records will be OK
entered. The screen also displays the
current date, which is used to filter the Figure 26 Attendance user interface
events available for selection. The
operator then chooses the event and click the OK button after ensuring his
choice is the right event. The available choices for the event are only the
currently active events (The event which has not finished at the current
date).
System Design
Figure 27 shows the screen after the Attend Event

3.1.2
operator clicks on the OK button at
the attendance screen. This following Event name : FA April 2001
screen will wait the operator to enter for Start : 12 April 2001
End : 12 April 2001
a Person ID. This ID number may be
entered using any tools (such a bar Person ID
code reader or keyboard). The operator
Attend Quit
should aware that there are two
buttons available here. The Attend Figure 27 Attend Event user interface
button should be clicked after the
operator entered the ID of the person who is attending the event. The Quit
button is used if there are no more people who will attend the event. The
button will send the operator to screen 3.1.1 (Figure 26).
If the operator the operator clicks the 3.1.3
Confirm Attendance
Attend button, he/she will go to the
confirmation screen (Figure 28). Here Name: John Doe
the operator may see the profile (name Address: One Doe's way, 1415,
and address) of the person attending California
the event. If the displayed profile Event FA April 2001
matches the real person, the operator
then clicks on the Confirm button. Cancel Confirm
Otherwise, the Cancel button will send Figure 28 Confirm Attendance user interface
the operator to the previous screen.
6.3 Value Objects
ValueObject
(from data)
EventVO AttendanceVO
Report VO (f rom d ata ) (from data)
(from data) eventName : String pe rsonID : Strin g
eventStart : Date dtAtte nd : Timestam p
eventFinish : Date eventName : String
At tendanceReportVO setEventName(name : String) : void se tPersonID(personID : String) : void

(from data) setEventStart(eventStart : Date) : void se tDtAttend(attend Timestamp : Tim estamp) : void
setEventFinish(finishDate : Date) : void se tEventName(eventN am e : String) : voi d
getEventName() : String ge tPersonID() : String
getEventStart() : Date ge tDtAttend() : Tim esta mp
getEventFinish() : Date ge tEventName() : Stri ng
Figure 29 Event Organizer value objects
6.3.1 EventVO
Each EventVO object represents a record in the event table. All properties are
to be set and retrieved using the public methods provided by the object.
System Design
EventVO

eventName event_name
eventStart event_start
eventFinish event_finish
6.3.2 AttendanceVO
Each AttendanceVO object represents a record in the attendance table.
AttendanceVO

personID person_id
dtAttend dt_attend
eventName event_name
Dat aAc cessObject

(f rom dat a)
EventDAO
(f rom dat a)
createEventVO() : EventVO
insertEvent(newEvent : EventVO) : void
updateEven t(event : EventVO) : void
deleteEvent(event : Even tVO) : void
getEventsBetwee n(startDate : Date, endDate : Date) : List
createAttendance VO() : Atte ndanceVO
getAttendan ceByEven tNam e(eve ntNam e : String) : List
insertAttend ance(attendance : Atten danceVO) : void
Figure 30 Event Organizer data-access objects
The EventDAO class manages data about the events. Event data are stored in
the event table and the attendance table
System Design
Method Summary
public createEventVO()
EventVO The primary factory method [GoF95] to create new instances of EventVO
objects.
public void insertEvent(EventVO newEvent)
Inserts a new event in the event table.
public void updateEvent(EventVO event)
Updates the event’s data. Both the event table and the attendance table
are updated.
public void deleteEvent(EventVO event)
Deletes an event in the event table.
public List getEventsBetween(Date startDate, Date endDate)
Returns a List (from java.util) which contains EventVO objects which are
still active in the time period given.
public createAttendanceVO()
AttendanceVO The primary factory method [GoF95] to create new instances of
AttendanceVO objects.
public List getAttendanceByEventName(String name)

Returns a List (from java.util) which contains AttendanceVO objects
which event name is according to the parameter given.
public void insertAttendance(AttendanceVO attendance)
Inserts a new attendance into the attendance table.
6.5 Business Logic

The EventManager business logic implements business rules concerning event
organizer services. At the beginning of each method, a security check is
performed to verify whether the currently logged-on operator may perform
the desired business action. If access to the action is denied, the
corresponding method throws a security exception.
Note that not all of the required methods are explained in the text. These
unlisted methods are typically simple – they passthrough to the related
methods in the DAO after performing some security checks and setting some
easily-obtained values.
System Design
BusinessLogic
(f rom business)
EventManager
(from business)
enterAttendance(personID : Stri ng, eventName : String) : void

createEvent(eventNam e : String, eventStart : Date, eventFini sh : Date) : void
getEventDAO() : EventDAO
getActiveEvents() : List
Figure 31 Event-Organizer business logic
Method Summary
public void enterAttendance(String personID, String eventName)
Pass-through to MemberDAO.createMemberVO() to insert an attendance to the
database.
public void createEvent(String eventName, Date eventStart, Date eventFinish)
Creates a new event.
public getEventDAO()
EventDAO Returns an eventDAO object associated with this business logic.
public List getActiveEvents()
Returns a List (from java.util) which contains EventVO objects which are
still active for the current time. This method generate current date an pass
it through the DAO.
6.5.1 Create Event

The event organizer services provide a create event service to provide an
event manager a tool to create a new event. If an event is going to be held, an
event manager will use this service to input the event name, start date, and
when will the event finish. These data will be very useful in generating
documents (such as attendance) later. The process is shown in Figure 32.
System Design
: JSP for Ev ent Management : SecurityControl : Ev entManager : Ev entDAO
New Event createEvent()

data entered c alled
verify operat or
privileges
privilege records
obtained
[ acc ess denied ]

[ acces s granted ]
security clearance
approved
insert new record

in the event table
new event
created
Figure 32 Create Event business process
6.5.2 Attend Event

This process is performed each time a person attends an event. It is
assumed that a person could not attend more than one event at an instance
of time. The business logic is shown in Figure 33.
System Design
: JSP for Ev entAttendance : Sec urityControl : Ev e ntMa nage r : Ev entDAO
event
specified
Person ID enterAttendance()
obtained called
verify operator
privileges
privilege records
obtained
[ access denied ]
[ access granted ]
security clearance
approved
insert new record in

the attendance table
person attendance
recorded
Figure 33 Enter Attendance business process
7 Appendix
7.1 References
[GoF95] Gamma, Erich, et. al. Design Patterns: Elements of Reusable Object-
Oriented Software. Addison-Wesley Publishing Company. 1995.
ISBN 0-201-63361-2.
[Yu02] Object-Oriented Systems Analysis and Design using UML.

BNCC Information System - Member Services Design

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

BNCC Information System - Member Services Design

Încărcat de

Drepturi de autor:

Formate disponibile

Prototype: Alpha One

July 22, 2002

SIMPLE RELIABLE SOLUTIONS

About This Document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1 About This Document

mandates assigned to both Fave Club and the Organization Development

This architecture is selected to minimize the impact of change to the system.

Figure 2 People Tables

Field Name Type Constraints Description

Field Name Type Constraints Description

Field Name Type Constraints Description

Field Name Type Constraints Description

Field Name Type Constraints Description

Field Name Type Constraints Description

3.1.6 Contact Person

Field Name Type Constraints Description

3.2 Member Services

Figure 3 Member Services tables

Field Name Type Constraints Description

3.2.2 Magazine Claims

The member_take_magazine table records the members' magazine claims. Every

Field Name Type Constraints Description

3.2.3 Member Payments

Field Name Type Constraints Description

3.3 Administrative Services

Figure 4 Administrative Services tables

Field Name Type Constraints Description

3.4 Event Organizer

Figure 5 Event Organizer tables

Field Name Type Constraints Description

Field Name Type Constraints Description

Field Name Type Constraints Description

Figure 6 Shared value objects

Property Field Notes

dtLastUpdate dt_lastupdate This VO property is read-only, the related field is

getPerson(personID : String) : PersonVO

Figure 7 Shared Data-Access Objects classes

4.3 Business Logic

viewPersonProfile(personID : String) : PersonVO

getMemberListByYear(membershipYear : String) : ReportVO

Figure 8 Shared Business Logic classes

public generateAttendanceReport(String eventName)

4.3.2.1 Attendance Report

: Reporter : EventDAO : PersonDAO : AttendanceReportVO

Figure 9 Generate Attendance Report business process

MemberManager Reporter MemberHistoryReportVO

Figure 10 Member Services classes overview

5.2 Sample Screens

allows registration along with data entry Period: 2002

from his/her student identity number. This Gender (select)

number is scanned from the bar code located Majoring (select)

in the student’s identity card. Register Clear

Member name : Bunbun member’s

1: Request person ID and membership year

: JSP for Member : Me mberManager

Figure 15 Member Magazine Claims user interface.

5.3 Value Objects

Figure 16 Member Services value objects

Property Field Notes

Property Field Notes

Property Field Notes

Property Field Notes

5.4 Data-Access Objects