bncc information system - member services design

8/14/2019 BNCC Information System - Member Services Design

1/39

BNCC Information SystemSystem Design

Prototype: Alpha One

Member ServicesEvent Attendance

July 22, 2002

Sasmito AdibowoWiratna Sari Wiguna

Yusri

Arcle Technologies

S IMPLE RELIABLE SOLUTIONS


2/39

Table of Contents

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

Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5People Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Project History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

General Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14People Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Member Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Administrative Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Event Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Shared Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Data-Access Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Member Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32Sample Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Data-Access Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Event Organizer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Sample Screens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Value Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Data-Access Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Business Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39


3/39

BNCC Information System

System Design

http://www.arcle.com Page 3 of 39

1 About This Document

This document provides the design specification for the prototype of yournew information system, code-named Buncis. The prototype consists of

member servicesand 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 requiredimplementation 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. Thecommittee 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 generalchair. 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 manualsystem. The uses of computers are limited in the creation and storage of

free-form documents and tables. Those documents and tables are created asfiles 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 andmaintaining its members.

Since its first conception, Buncis has received positive attitudes from the

organization. Additionally, it has expresses its commitment through the


4/39


System Design


SQL Database

Data-

Access

Objects

Value

Objects

Presentation

Logic

UserSecurityControl

Business

Logic

Figure 1 Buncis Architecture Overview

mandates assigned to both Fave Club and the Organization DevelopmentTeam divisions in favor of Buncis development.

The design phase of the project has been initiated. Because of the urgentneed 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 ArchitectureArchitecturally, the system is separated into three primary subsystems: The

Presentation Logics, the Business Logic, and the Data-Access Objects. Thisseparation 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 Logiccontrols the interaction between the two.

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 theclasses in this layer may perform JDBC/SQL queries to the DBMS. Other

components that require to access the database must go through themethods in this layer. Data-Access Objects are also responsible for

maintaining referential integrityof 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 policiesand/or workflow will mostly affect the classes in this layer.


5/39


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. Bynot performing business processes in the user interface, more userinterfaces 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 methodin 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

doesnt have access to the functionality, the method will throw an exceptionwithout 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 willbe 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 otherparties. This includes the people within and outside the organization. In

relation to people, Buncis stores information about activists, staffs, seniors,

and contact persons.


6/39


System Design


person

person_id

namegenderemailbirthdayhome_addresshome_phonemobile_phonepersonal_notesdt_lastupdate

member

person_id (FK)membership_year

school_major

activist

person_id (FK)active_year

division

contact_person

person_id (FK)organization_name (FK)

office_addressoffice_phoneoffice_emaildt_lastupdate

senior

person_id (FK)last_active_year

last_staff_position

staff

person_id (FK)active_year

active_position

Figure 2 People Tables

3.1.1 PersonThe person table is the primary table which stores a persons personal

information. Entries in this table are created upon the person's first contactwith BNCC.

person

Field Name Type Constraints Description

person_id String primary key For people who have a students identitycard, this field is generated from the bar-codeprinted on the card. For others, this value israndomly generated in such a way that it willnot conflict with a students identity card

number.

name String alternatekey, not null

The full name which that person is prefer tobe referred to.

gender Char none The sex group the person belongs to.Consists of either M or F values, for maleor 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.


7/39


System Design



home_address

Memo none The primary residence address of the person,if known.

home_phone String none The telephone number of the primaryresidence, 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 notesabout the person.

dt_lastupdate Date/

Time

not null The timestamp of the records last update.

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 keyand foreignkey to person(person_id)

The unique identification of the memberas a person.

membersip_year String primary key The members period of membership.This value is expressed as a four-digityear at which the member registered.Examples of valid values are {2002,2003, 2004, ...}.

school_major String none The members university major. This

value is expressed as abbreviations ofthe major names. Examples of validvalues 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 arealso 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.


8/39


System Design


activist


person_id String primary key andforeign key toperson(person_id)

The unique identification of the activist as aperson.

active_year String primary key The activists period of occupancy. Thisvalue is expressed as a four-digit year atwhich the activist began his or heroccupancy. 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. Multipledivisions 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 persons identification in the person

table.

staff


person_id String primary keyand foreign keyto person(person_id)

The unique identification of the staff as aperson.

active_year String primary key The staffs period of occupancy. Thisvalue is expressed as a four-digit year atwhich the staff began his or heroccupancy. Examples of valid values are{2002, 2003, 2004, ...}.

active_position String not null Describes the position of the staff at thisperiod of occupancy.

3.1.5 Seniors

The senior table records data about staffs that are no longer in service. In otherwords, seniors are retired staffs.

senior


9/39


System Design



person_id

String primary keyand foreign keyto person(person_id)

The unique identification of thesenior as a person.

last_active_year String primary key The seniors last period of occupancy. This value is expressedas a four-digit year at which thesenior 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 arepresentative 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 andforeign key to person(person_id)

The unique identification as aperson.

organization_name String primary key andforeign key toorganization(organization_name)

The name of the organizationthat the person represents.

office_address Memo none The branch/office address of theorganization in which this personmay be contacted.

office_phone String none The branch or office phonenumber of the organization inwhich this person may becontacted.

office_email String none The branch/office e-mail addressof the organization in which thisperson may be contacted.

dt_lastupdate Date/Time

not null Timestamp which this recordwas last updated.


10/39


System Design


member

person_id (FK)membership_year

school_major

magazine

magazine_id

descriptionamount_in_stockdt_lastupdate

member_take_magazine

magazine_id (FK)person_id (FK)membership_year (FK)

dt_taken

member_payment

person_id (FK)membership_year (FK)payment_date

amount

Figure 3 Member Services tables

3.2 Member Services

These tables (Figure 3) store administrative data of the members. Those

data are magazines, member payments and magazine claims.

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 themagazines edition. This number is uniquefor each edition of the magazine, and isprinted as bar codes in the magazine.Copies for the same edition have thesame identification number.

description String alternatekey, not null

The human-readable identification of themagazines edition.

amount_in_stock Integer not null, >= 0 The number of copies for the currentedition which are still stored in stock.


not null Timestamp of the last update of thisrecord.

3.2.2 Magazine Claims


11/39


System Design


The member_take_magazine table records the members' magazine claims. Everytime a member claims a magazine, a record is inserted into this table. Each

member may only take one copyof a particular magazine edition.

member_take_magazine


magazine_id String primary key and foreignkey to magazine(magazine_id)

The identification number of themagazine taken.

person_id String primary key and foreignkey to member(person_id)

The person_id of the memberwho took the magazine.

membership_year String primary key and foreignkey to member(membership_year)

The membership year of themember who took the magazine.

dt_taken Date/Time

not null When was the magazine wastaken 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 andforeign key to member(person_id)

The person_id of the memberproviding the payment.

membership_year String primary key andforeign key to member(membership_year)

The membership year of themember providing the payment.

payment_date Date primary key When was the payment provided.

amount Real not null, > 0 The amount of payment provided, inmonetary units.

3.3 Administrative Services


12/39


System Design


person

person_id

namegenderemailbirthdayhome_addresshome_phonemobile_phonepersonal_notesdt_lastupdate

attendance

person_id (FK)dt_attend

event_name (FK)

event

event_name

event_startevent_finish

Figure 4 Administrative Services tables

3.3.1 AttendanceThe 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 keyto person (person_id)

The Persons ID of the attendee.

dt_attend Date/Time

primary key The timestamp at when the personattends.

event_name String not null, and foreign key toevent (event_name)

The event attended.

3.4 Event Organizer


13/39


System Design


organization

organization_name

primary_address

primary_phone

primary_website

dt_lastupdate

contact_person

person_id (FK)

organization_name (FK)

office_address

office_phone

office_email

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. Eventsare 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 theprimary key, event names must be globallyunique 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 notknown, 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 namemust be globally unique for allorganizations.


14/39


System Design



primary_address

String none The address of the head office of theorganization.

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 onlythe host name without any paths.


not null Timestamp which this record was lastupdated.

4 Shared Components

4.1 Value Objects


15/39


16/39


System Design


PersonDAO

getPerson(personID : String) : PersonVO

insertPerson(person : PersonVO) : void

createPersonVO() : PersonVO

updatePerson(person : PersonVO) : void

(from data)

DataAccessObject

getPoolManager() : ConnectionPoolManager

createEmptyList() : List

(from data)LoginSession

(from con trol )0..*1 0..*1

Figure 7 Shared Data-Access Objects classes

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 isupdated 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


17/39


18/39


System Design


Reporter

getMemberListByYear(membershipYear : String) : ReportVO

getTopActivis ts(num Activis ts : int = 10, activeYear : String) : ReportVO

getMemberListByMajor(membershipYear : String, schoolMajor : String) : ReportVO

getPersonDAO() : PersonDAO

createAttendanceReportVO() : AttendanceReportVO

generateAttendanceReport(eventName : String) : AttendanceReportVO

getEventDAO() : EventDAO

createReportVO() : ReportVO

(from business)

PeopleManager

viewPersonProfile(personID : String) : PersonVO

createPersonVO() : PersonVO

(from busin ess)

BusinessLogic

(f rom business)

DataAccessObject(from data)

1..* 1..*1..* 1..*

uses

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

publicPersonVO

createPersonVO()

Pass-through to PersonDAO.createPersonVO() factory method [GoF95].

publicPersonVO viewPersonProfile(String personID)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-dimensionalspreadsheet-style report tables, represented in ReportVO objects. This

facilitates further data analysis and formatting by using general-purpose

spreadsheet packages.


19/39


System Design


Method Summary

public ReportVOgetMemberListByYear(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, StringschoolMajor)

Returns a membership year grouped by their majors for thespecified year.

public PersonDAO getPersonDAO()

Returns the PersonDAO object used to query the database.

public

AttendanceReportVO

createAttendanceReportVO()

The primary factory method[GoF95] to create new instances ofAttendanceReportVO objects.

publicAttendanceReportVO

generateAttendanceReport(String eventName)

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 ofReportVO objects.

4.3.2.1 Attendance ReportThe generate attendance reportbusiness 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 callinggetAttendanceByEventName(). Since the list ofAttendanceVO 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 ofeach attendees that are obtained from the PersonDAO object by callinggetPerson() repeatedly, one for each attendees.


20/39


System Design


: AttendanceReportVO: Reporter : EventDAO : PersonDAO

1: getPersonDAO( )

2: getAttendanceByEventName(String)

5: *setValueAt(Object, int, int)

4: createAttendanceReportVO( )

3: *getPerson(String)

Figure 9 Generate Attendance Report business process

MemberHistoryReportVO(from data)

ReportVO(from data)

MemberVO(f rom da ta)

MemberManager(from business)

1

0..*

1

0..*

MemberDAO(from data)

1

1

1

1

1..10..n

Reporter(f rom busines s)

1

1

1

1

1..1

0..n

Figure 10 Member Services classes overview

5 Member Services

5.1 OverviewIn 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 members payment data,

records magazine claims, and retrieves the history about those paymentsand claims.


21/39


System Design


Member Registration

Person ID

Name

E-mail

Address

Phone

Mobile Phone

Birthday

Gender

Majoring

Day Month Year

(select)

(select)

Register Clear

1.2.1

Period: 2002

Figure 11 Member Registration screen

OK

Person ID:

Member Sign-On 1.1.1

Membership Year:

Exit

2002

Figure 12 Member Sign-On

1.1.2

Member name :

Membership year :

Administrative Records

Payments received :

1. 22 Jan 2002 Rp. 150.0002. 21 Feb 2002 Rp. 300.000

----------------

SUM Rp 450.000

Magazines taken this year :

1. Feb 2002 25 Feb 20022. Apr 2002 25 Apr 2002

Action

Pay membership fee

Amount Rp

Take magazine

Magazine ID

Finish

Bunbun

2001

Confirm

Figure 13 Member Administrative Records

These DAO and BL classes uses MemberVO objects to express data about amember. It contains the members personal data (which are inherited from

PersonVO) and data about his/her current membership.

5.2 Sample Screens5.2.1 Member Registration

The Member Registration screen (Figure 11)allows registration along with data entry

about the members personal information

(name, address, phone, etc). It is visible that

the membership year is automatically filledin (obtained from the systems internal clock).

This screen is optimized for fast data entry,

where typing-intensive tasks are performedprior to selection tasks.

The new members Person ID is obtained

from his/her student identity number. This

number is scanned from the bar code located

in the students identity card.

The birthday is entered numerically, with theday ranges 131, month 112, and year is

entered as four digits (such as 1984, 1985, etc.).

All fields except Person ID and Name may be left blank although thecompletion of all fields is desirable. When all data has been entered, the

user clicks the Register button to enter the members data.

5.2.2 Member Sign-on

For each event held by BNCC, members must signon to validate access to the event. This is

performed by

scanning themembers

identity card

to obtain his/her Person ID. Thescreen is shown in Figure 12.

After signing on, the screen in Figure

13 is displayed. This screen shows the

members administrative records,

which are his/her payments andmagazine claims. The records

displayed allow the operator to decide

whether the member may or may not

participate in the event and/or claim a


22/39


System Design


Start

1.1.1 Waiting for Person ID

and Membership Year input1.1.2 Waiting

for action

take magazine

or

pay fee

End

Person ID /

Membership

year entered

exit

quit

Figure 14 Member Sign-On state diagram

: JSP for MemberServices

: MemberManager

1: Request person ID and membership year

5: show member records

2: viewMemberProfile(String, String)

3: getMemberPaymentHistory(String, String)

4: getMagazineClaimHistory(String, String)

6: m emberClaimMagazine(String, String, String)

Figure 15 Member Magazine Claims user interface.

magazine. Additionally, this screen may also be used to enter a record forthe members payment, or claim a magazine.

When a member decides to pay the fee, the operator places a check mark in

the Pay membership feecheck 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 magazinecheck box and the taken magazines 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 feeand Take

magazineactions may be performed in one step.

The Confirmbutton performs the

desired actions (pay or take,

inclusively) and then re-displays thescreen, showing the newly entered

records. While the Finishbutton

returns to the Member Sign-On screen(Figure 12).

These screens follow the statediagram shown in Figure 14. The

dotted numbers in the state names

correspond to the numbers shown inthe upper-right of each screens.

5.2.3 Interaction with the business logicThe 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.


23/39


System Design


PersonVO(from data)

MemberVO

mem bershipYear : String

schoolMajor : String

getMembers hipYear() : String

getSchoolMajor() : String

setMembershipYear(members hipYear : String) : void

setSchoolMajor(schoolMajor : String ) : void

(from data)

ReportVO

(from data)

ValueObject

(from data)

Serializable

(from io)

MemberHistoryReportVO(from da ta)

TableModel

(from table)MemberPaymentVO

personID : String

mem bershipYear : String

paym entDate : Date

amount : float

setPersonID()

getPersonID()setMem bershipYear()

getMem bershipYear()

setPaymentDate()

getPaymentDate()

setAmount()

getAmount()

(from data)MemberTakeMagazineVO

personID : String

membershipYear : String

magazineID : String

dtTaken : Times tamp

setPersonID()

getPersonID()

setMembershipYear()

getMembershipYear()

setDtTaken()

getDtTaken()

(from data)

Figure 16 Member Services value objects

5.3 Value Objects

5.3.1 MemberVOMemberVO is derived from PersonVO, therefore it inherits all of the parent class'

properties. Each MemberVO object represents one record in the member table andits 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 MemberTakeMagazineVOEach MemberTakeMagazineVO object represents one record in themember_take_magazine table.

MemberTakeMagazineVO


personID person_id



24/39


System Design



PersonDAO(from data)

DataAccessObject(from data)

MemberDAO

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

createMemberPaymentVO() : MemberPaymentVO

insertMemberPayment(memberPayment : MemberPaymentVO) : void

insertMemberTakeMagazine(magazineClaim : MemberTakeMagazineVO) : void createMemberTakeMagazineVO() : MemberTakeMagazineVO

(from data)

Figure 17 Member Services data-access objects classes

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

5.4 Data-Access Objects

5.4.1 MemberDAO

The MemberDAO class manages data about the members. Member data are

stored in the following tables:

people member


25/39


System Design


member_payment member_take_magazine

Method Summary

public MemberVO createMemberVO()

The primary factory method[GoF95] to create new instances ofMemberVO objects.

public void insertMember(MemberVO newMember)

Inserts a new member in the member table. The parent record inthe people table corresponding to the member must already exist,or this method will throw an exception.

public void updateMemberVO(MemberVO member)

Updates the members data. Both the member table and thepeople table are updated.

public MemberVO getMemberVO(String personID, String membershipYear)

Returns data about a member with the specified person ID andmembership year. Data from both of the people table andmembertable are retrieved.

public List getMemberByCriteria(String membershipYear, Map criterias)

Returns a List (from java.util) which contains MemberVO objectsfor the members matching all of the specified criterias. Thecriterias parameter is specified by a set of (String name, Objectvalue) pairs, where name is the field name requested (either from

the people table or from the member table) and value is thematching value of the field.

publicMemberPaymentVO

createMemberPaymentVO()

The primary factory method[GoF95] to create new instances ofMemberPaymentVO 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 ofinsertion (the referred records exists).

publicMemberTakeMagazineVO

createMemberTakeMagazineVO()

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. Theforeign keys (magazine_id, person_id, and membership_year) mustbe valid at the time of insertion (the referred records exists).

5.5 Business Logic5.5.1 Member Manager

The MemberManager business logic implements business rules concerning

member services. At the beginning of each method, a security check is


26/39


System Design


performed to verify whether the currently logged-on operator may performthe 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 someeasily-obtained values.

Method Summary

MemberVO createMemberVO()

Pass-through to MemberDAO.createMemberVO() to create an empty MemberVOobject.

publicvoid

payMemberFee(String personID, String membershipYear, float amountPaid)

Registers a member's payment. The amount paid must be greater than zero,or this method will throw an exception.

publicList

getMemberPaymentHistory (String personID, String membershipYear)

Returns a List (from java.util) which contains MemberPaymentVO objects forthe specified member. The value objects returned represents a history of themember's payments for this period.

publicList

getMagazineClaimHistory(String personID, String membershipYear)

Returns a List (from java.util) which contains MemberTakeMagazineVOobjects for the specified member. The value objects returned represents ahistory of the member's payments for this period.

protectedMemberDAO

getMemberDAO()

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 ofmembership (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 newmember'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 theperson's membership data for this period (the current membership year) is

created. The MemberDAO takes care of the actual details of handling the tables.


27/39


System Design


verify operator

privileges

privilege recordsobtained

security clearance

approved

get PersonID of

the new member

createMember()

called

Person dataobtained

New member

created

lookup profile data

in the people table

insert new record in

the member table

update the current data

in the people table[ data exist ]


the people table[ data not exist ]

The new member'sdata entered

[ a ccess granted ]

[ access denied ]

: MemberDAO: MemberManager: Securi tyC ontrol: JSP for Member Ser vices

Figure 18Create Memberbusiness process


28/39


System Design


: MemberManager : MemberDAO

1: getMemberDAO( )

2: getPerson(String)

3: insertPerson(PersonVO)

4: insertMember(Mem berVO)

Figure 19 Member Creation sequence

5.5.3 Member Payment

The Pay Member Feebusiness process is handled by theMemberManager.payMemberFee() method. The method first verifies that the

payment amount is larger than zero. If the condition does not apply, thenthe method will throw an exception. The process is shown in Figure 20.


29/39


System Design


Member's payment

data entered

verify operator

privileges

privilege records

obtained

payMemberFee()

called

[ acc ess denied ]

security clearance

approved

[ access granted ]

member payment

recorded

check payment

amount

payment

denied

amount < = 0

insert member

pay ment recor ds

amount > 0

: MemberDA O: MemberManager: Secur ityControl: JSP for Member S ervices

Figure 20 Pay Member Fee business process


30/39


System Design


: MemberPaymentVO: MemberManager : MemberDAO

1: getMemberDAO( )

2: createMemberPaymentVO( )

3: setPersonID(String)

4: setMembershipYear(String)

5: setPaymentDate(Date)

6: setAmount(float)

7: insertMemberPayment(MemberPaymentVO)

Figure 21 Sample sequence forPay 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 communicatingthe 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 Magazinebusiness process is handled by the

MemberManager.memberClaimMagazine()method. After performing the necessarysecurity checks, this method simply passes through to the corresponding

DAO object (Figure 22).


31/39


System Design


Magazine ID, Person ID and

Membership Year entered

verify operator

privileges

privilege records

obtained

memberClaimMagazine()

called

security clearance

approved

magazine

claim recorded

decrement magazineamount in stock by one

magazineamount updated

get mag azinerecord

update magazinerecord

insert magazine

claim data

[ acc ess denied ]

[ access granted ]

: MemberDAO: MemberManager: Se curityControl: JSP for Member Services

Figure 22Magazine Claims business process


32/39


System Design


: MemberManager : MemberDAO : MemberTakeMagazineVO

1: getMemberDAO( )

2: createMem berTakeMagazineVO( )

3: setPersonID(String)

4: getMembershipYear( )

5: setDtTaken(Timestamp)

6: insertMemberTakeMagazine(MemberTakeMagazineVO)

Figure 23 Sample Claim Magazine sequence

ReportVO(from data)

AttendanceReportVO(from data)

Reporter(f rom business)

1..1 0..n

AttendanceVO(from data)

EventVO(from data)

EventDAO(from data)

1

1

1

1

0..* 10..* 1

EventManager(f rom business)

0..*

1

0..*

11

0..*

1

0..*

1

1

1

1

1..10..n

Figure 24 Event Organizer Class Overview

6 Event Organizer

6.1 OverviewIn the context of event organizer (Figure 24), an EventDAO object is used by

two business logic objects: EventManager and Reporter


33/39


System Design


Event Name

Create

Event Start

Event Finish

Create Event

Figure 25 Create Event user interface

Attendance

Please select the event name :FA April 2001

OK

3.1.1

Attend to active events

ending not after:12 April 2001

Figure 26 Attendance user interface

The EventManager uses the DAO to manage event data, records the events

attendance data, and retrieves currently active events. These DAO and BLclasses uses EventVO objects to express data about an event. It contains theevent start and finish date, the attendance of the event, and of course the

event name.

6.2 Sample Screens6.2.1 Create Event

The event creationscreen (Figure 25)allows the event manager to create a

new event in the database. The fields

to be filled in are the event name, the

event start date, and the eventfinishdate. If the event manager wishes to

create an event that is not expectedto end (such as the secretariate

event), the event finishfield should

not be filled. Events are identified bytheir names, thus the name of the

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 Createbutton 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 canbe attended by many people. To start

the attendance service, the operator will

bring up the attendancescreen shownin Figure 26. This screen will prompt

the operator to select the event for

which the attendance records will beentered. The screen also displays the

current date, which is used to filter the

events available for selection. Theoperator 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).


34/39


System Design


Attend Event

Event name : FA April 2001Start : 12 April 2001End : 12 April 2001

Person ID

Attend

3.1.2

Quit

Figure 27 Attend Event user interface

Confirm Attendance

Name: John Doe

Address: One Doe's way, 1415,

California

Confirm

3.1.3

Event FA April 2001

Cancel

Figure 28 Confirm Attendance user interface

EventVO

eventName : String

eventStart : Date

eventFinish : Date

setEventName(name : String) : voidsetEventStart(eventStart : Date) : void

setEventFinish(finishDate : Date) : void

getEventName() : String

getEventStart() : Date

getEventFinish() : Date

(from d ata)

ValueObject(from data)

ReportVO(from data)

AttendanceReportVO(from data)

AttendanceVO

personID : String

dtAttend : Times tamp

eventName : String

se tPersonID(personID : String) : voidse tDtAttend(attendTimestamp : Timestamp) : void

se tEventName( eventNam e : String) : void

getPersonID() : String

getDtAttend() : Timestamp

getEventName( ) : String

(from data)

Figure 29 Event Organizer value objects

Figure 27 shows the screen after theoperator clicks on the OK button at

the attendancescreen. This followingscreen will wait the operator to enter fora Person ID. This ID number may be

entered using any tools (such a bar

code reader or keyboard). The operatorshould aware that there are two

buttons available here. The Attend

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 theAttend button, he/she will go to the

confirmation screen (Figure 28). Herethe operator may see the profile (name

and address) of the person attending

the event. If the displayed profilematches the real person, the operator

then clicks on the Confirmbutton.

Otherwise, the Cancelbutton will send

the operator to the previous screen.6.3 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.


35/39


System Design


DataAccessObject

(from data)

EventDAO

createEventVO() : EventVO

insertEvent(newEvent : EventVO) : void

updateEvent(event : EventVO) : void

deleteEvent(event : Even tVO) : void

getEventsBetween(startDate : Date, endDate : Date) : ListcreateAttendance VO() : AttendanceVO

getAttendanceByEven tNam e(eventNam e : String) : List

insertAttendance(attendance : AttendanceVO) : void

(from data)

Figure 30 Event Organizer data-access objects

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

6.4 Data-Access Objects

The EventDAO class manages data about the events. Event data are stored inthe event table and the attendance table


36/39


System Design


Method Summary

publicEventVO

createEventVO()

The primary factory method[GoF95] to create new instances ofEventVOobjects.

public void insertEvent(EventVO newEvent)

Inserts a new event in the event table.

public void updateEvent(EventVO event)

Updates the events data. Both the event table and the attendance tableare 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 arestill active in the time period given.

publicAttendanceVO

createAttendanceVO()

The primary factory method[GoF95] to create new instances ofAttendanceVO objects.

public List getAttendanceByEventName(String name)

Returns a List (from java.util) which contains AttendanceVO objectswhich event name is according to the parameter given.

public void insertAttendance(AttendanceVO attendance)

Inserts a new attendance into the attendance table.

6.5 Business LogicThe 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 performthe 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.


37/39


System Design


BusinessLogic(from bu siness)

EventManager

enterAttendance(personID : String, eventName : String) : void

createEvent(eventName : String, eventStart : Date, eventFinish : Date) : void

getEventDAO() : EventDAO

getActiveEvents() : List

(from business)

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 thedatabase.

public void createEvent(String eventName, Date eventStart, Date eventFinish)

Creates a new event.

publicEventDAO

getEventDAO()

Returns an eventDAO object associated with this business logic.

public List getActiveEvents()

Returns a List (from java.util) which contains EventVO objects which arestill active for the current time. This method generate current date an passit 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, anevent manager will use this service to input the event name, start date, andwhen will the event finish. These data will be very useful in generating

documents (such as attendance) later. The process is shown in Figure 32.


38/39


39/39


System Design

event

specified

Person ID

obtained

verify operator

privileges

privilege records

obtained

enterAttendance()

called

security clearance

approved

person attendance

recorded


the attendance table

[ access denied ][ access granted ]

: EventDAO: Ev entManager: Sec urityControl: JSP for EventAttendance

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

Documents