Conference
Registration
System
December 8
2010
This document details the problem statement of the domain, as well as analysis
via diagrams, models, and discussion, to provide system analysis, system design,
physical design, and applications design, which could lead to the creation of an
automated registration system for academic conferences.
Group Seven:
John Ehring
Joe Lizzi
Rob Sullivan
2|Page
Contents
Introduction ...............................................................................................................................................................4
Systems Analysis ........................................................................................................................................................4
Problem Statement ................................................................................................................................................4
Goals & Importance................................................................................................................................................4
Project Scope ..........................................................................................................................................................5
Functional and Data Requirements ........................................................................................................................5
Assumptions ...........................................................................................................................................................7
Use Cases ................................................................................................................................................................7
Detailed Use Cases .............................................................................................................................................. 11
Use Case Diagram ................................................................................................................................................ 14
Analysis Class Diagram ........................................................................................................................................ 15
Design Class Diagram........................................................................................................................................... 16
System Analysis – Validation & Discussion.......................................................................................................... 17
System Design ......................................................................................................................................................... 18
System Sequence Diagram .................................................................................................................................. 18
Sequence Diagram (Add Account)....................................................................................................................... 19
Sequence Diagram (Add Event to Cart) ............................................................................................................... 20
Sequence Diagram (Pay for Ticket) ..................................................................................................................... 21
State Diagram ...................................................................................................................................................... 22
System Design – Validation & Discussion ............................................................................................................ 23
Physical Design ............................................................................................................................................ 24
Entity-Relationship Diagram ................................................................................................................................ 24
Deployment Diagram .......................................................................................................................................... 25
Physical Design – Validation & Discussion........................................................................................................... 25
Applications Design ................................................................................................................................................ 27
Screenflow Diagram ............................................................................................................................................ 27
Applications Design – Validation & Discussion.................................................................................................... 28
Evaluation of Analysis & Design ............................................................................................................................. 28
Project ................................................................................................................................................................. 28
Domain ................................................................................................................................................................ 28
UML ..................................................................................................................................................................... 28
3|Page
Modeling Tools .................................................................................................................................................... 29
Appendix ................................................................................................................................................................. 29
Division of Work .................................................................................................................................................. 29
Lessons Learned – John ....................................................................................................................................... 30
Lessons Learned – Joe ......................................................................................................................................... 30
Lessons Learned – Rob ........................................................................................................................................ 30
References............................................................................................................................................................... 30
4|Page
Introduction
The International Conference on Information and Knowledge Management (CIKM) has contacted our group to
assist in the creation of an automated registration system for their yearly academic conferences. Our group was
presented with a problem statement which outlined many of the needs of the system, as well as certain
assumptions, conditions, and restraints that we would have to take into considering while designing the system.
Upon receipt of the problem statement, our group underwent a number of system analysis, system design,
physical design, and application design procedures to design the system and document our decisions. A number
of use cases were created by analyzing information available in the problem description. Detailed use cases
were then developed to understand how some of these use cases might operate in more detail. A use case
diagram was created to illustrate how these use cases might be utilized by certain actors which serve as the
direct means of interaction with the system. Based on this information, two class diagrams were created which
serve as the fundamental pieces of how our system will operate practically.
Using the detailed use cases and class diagrams as a basis, sequence diagrams were developed to understand
how sequential events might occur in the typical success scenario of these use cases. A systems sequence
diagram was developed to illustrate the main success scenario of the entire system, not just specific processes.
Similarly, a state diagram was developed to show how the state of the system will change over the course of a
completed transaction.
Two diagrams were created to explore how our system might be physically implemented. The entity-relationship
diagram illustrates how the system could be represented in a database. Meanwhile, the deployment diagram
seeks to identify which physical tools and software protocols will be necessary to get the system up and running.
A screenflow diagram was created to map out how the system’s different interfaces will transition and interact.
While a large portion of the total work necessary to successfully implement this system has been completed,
more work is necessary before this can become a reality. Only a portion of the physical design has been
outlined, and much more application design (specifically the development of the web interfaces) must be laid
out before work can begin. This being said, we feel our team has laid a good, solid basis which covers the
fundamental components of how the system should operate.
Systems Analysis
Problem Statement
The organizing company of a yearly international academic conference, along with different workshop and
tutorial sessions, needs a simpler, faster, and more reliable system of tracking attendee registration information.
Goals & Importance
The goal of the Conference Registration System (CRS) is to allow conference attendees to quickly and easily
register for conferences, workshops, and/or tutorial sessions. This includes being able to purchase additional
materials (such as printed conference proceedings) and paying the registration fees via one of several methods
(check, credit, cash [on-site only], or traveler’s check). The system will also allow the attendee to add or modify
5|Page
registration choices up to the conference or workshop date. The system will be used for self-registration
(online), registration through customer service (email or phone), or via an on-site setup (conference staff, kiosk,
etc). Regardless of whether the attendee or a customer service representative (acting on the attendee’s behalf)
is accessing the system, the process will be consistent.
A well-run conference or workshop needs to have an efficient and reliable method of attendee registration. An
automated system reduces the amount of necessary paperwork, time and effort spent by staff on registration,
and errors in registration processing. The Conference Registration System, therefore, provides benefits to both
the conference attendees and the conference organizers.
Project Scope
The system is designed to be used for registration of a specific yearly conference. However, it will also be flexible
enough to be used for special workshop or tutorial sessions that are held outside of the conference, and can be
readily adapted to other conferences that the organization may decide to host. The scope of this document is to
set up initial requirements planning, system analysis, system design, physical design, and some application
design. Final aesthetic and design decisions, a working prototype, and the final product are outside the scope of
this document and are left for future work.
Functional and Data Requirements
1. The software package will be able to process transactions for multiple conferences. Each conference will
be defined by the following:
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
Conference ID
Name
Description
Date(s)
Time(s)
Registered Attendees
2. The schedule for the conference will be defined by various sessions. Each session type will have the
following data requirements:
2.1. Paper Session
2.1.1.Paper Title
2.1.2.Speaker(s)
2.1.3.Capacity
2.1.4.Currently registered
2.1.5.Discount cutoff date
2.2. Tutorial Session
2.2.1.Title
6|Page
2.2.2.Instructor(s)
2.2.3.Minimum required registrants to have session
2.2.4.Capacity
2.2.5.Currently registered
2.2.6.Fee
2.2.7.Discount cutoff date
2.3. Workshop session
2.3.1.Title
2.3.2.Instructor(s)
2.3.3.Minimum required registrants to have session
2.3.4.Capacity
2.3.5.Currently registered
2.3.6.Fee
2.3.7.Discount cutoff date
2.4. Banquet
2.4.1.Additional tickets (the registrant’s ticket is included in the conference registration fee)
3. The software package must track individual registration information and correctly calculate all costs for
the participant based on sessions selected.
3.1. The following general registration information will be collected:
3.1.1.Name
3.1.2.Title
3.1.3.Company/Association
3.1.4.Phone Number
3.1.5.Student Status
3.1.6.Mailing Address – mailing address will need to support international in addition to domestic
addresses.
3.2. Each registrant will have the following fees tabulated:
3.2.1.Conference registration
3.2.2.Tutorial session (this fee will be refunded if session cancelled due to lack of interest)
3.2.3.Workshop session
3.2.4.Additional banquet tickets
3.2.5.Additional conference proceedings
3.3. Fee schedule
3.3.1.Fees will be tabulated based on attendee (regular/student) and date of registration (before/after
discount date).
7|Page
3.4. The package should interface with online registration as well as manual input from conference
personnel using phone or mail based registration.
3.5. The package should generate a name tag for each registrant.
3.6. The package should generate a receipt for each registrant. The receipt should contain:
3.6.1.Conference Title
3.6.2.Date(s)
3.6.3.Location
3.6.4.Attendee’s name
3.6.5.Attendee’s title/affiliation
3.6.6.Attendee’s address
3.6.7.Amount paid (itemized)
Assumptions
1. The software package will track how the payment was made, but will not actually handle the transaction
with the financial institution.
2. If a customer had previously made a transaction and seeks to make a new one, a new receipt will be
issued.
3. If multiple transactions are made, the most recent receipt will reflect all transactions.
4. There are only 4 types of conference ticket prices as opposed to 8: student price, early price (before
cutoff date), standard price (neither early nor late), and late price (after cutoff date). However, multiple
pricing structures may be used in combination with each other depending on the circumstances.
5. If an event is updated by an administrator after a ticket has been purchased, the attendee will receive
an updated receipt.
6. An author of an academic paper being shown at a conference will go through the same motions as a
normal attendee to attend that conference.
Use Cases
Use Case
Name
Actor
Purpose
Overview
Evaluate Tutorial Attendance
Use Case
Name
Actor
Purpose
Cancel Tutorial
System
The system will check to see if tutorial attendance is high enough.
At a predefined date, the system will check to see if the amount of registered
attendees for a particular tutorial meets the predefined minimum requirement. If
the number of attendees is not at least this number on the predefined date, the
system will cancel the tutorial.
System
If a tutorial does not meet attendance requirements, the system will cancel the
8|Page
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
tutorial.
If the “Evaluate Tutorial Attendance” process determines that tutorial
attendance requirements are not met, this use case will be instantiated. The
tutorial will then be removed from the list of offered tutorials, and notification
will be sent to all previously registered attendees informing them of the
cancelation.
Refund Money
System, Attendee
An attendee’s money will be refunded to them in the event that their tutorial is
canceled.
If a tutorial is canceled (via the Cancel Tutorial process), then the attendee’s
money must be refunded. This will be accomplished by issuing a credit on the
user’s account (if paid by credit) or by sending a check to the user’s billing
address (if paid via some other method).
Apply Discount
System
The system will automatically apply discounts to the customer’s purchase
before they pay.
Depending on when some items are purchase, they may be eligible for a
discount. After the user finalizes their purchases but before they pay, a discount
may or may not be applied. The user will see the final total, including discount,
before they finalize their payment.
Send Receipt
System, Attendee, Conference Staff
Regardless of how the attendee pays, they will receive a receipt in some form
after they complete their purchase.
If a attendee completes their purchase online, their receipt will be e-mailed to
them. If a attendee pays via mail, their receipt will be mailed to their billing
address. If the attendee pays via phone, the attendee may choose to either
receive a digital receipt via e-mail or a printed receipt via mail. If the attendee
pays on site, the conference staff will print out the attendee’s receipt and hand it
to the attendee.
Issue Badge
9|Page
Actor
Purpose
Overview
Attendee, Conference Staff
The attendee will show their receipt at the front desk of the conference center
and receive a badge.
Regardless of how an attendee purchased their tickets, they will have received a
receipt. The attendee will present this receipt at the front desk. The staff will
then ask for photo ID to verify that the receipt belongs to that person. Then, the
staff will check the attendance list for that attendee’s name for that particular
conference. After the staff has verified that the attendee did indeed register for
that particular conference, he will print out a badge and present it to the
customer.
Use Case
Name
Actor
Purpose
Overview
Pay for Ticket
Use Case
Name
Actor
Purpose
Overview
Handle Payment
Use Case
Name
Actor
Purpose
Overview
Register an Account
Use Case
Name
Actor
Purpose
Overview
Add Item to Cart
Use Case
Verify Student Status
Attendee
Interaction for attendee to submit payment
Attendee submits payment and receives confirmation of receipt.
System, Conference Staff (if payment in person or by phone/mail)
Validate and account for payment. Update registration information
Once registration items have been added to cart, the attendee (or conference
staff) proceeds to checkout to complete payment information, update
registration and generate a receipt.
Attendee, Conference Staff (if payment in person or by phone/mail)
If attendee does not already have an account, create an account.
Accounts are used to track cart items and registration information. If the
attendee does not have an account, create an account containing contact
information. Cannot proceed to “Add Item to Cart” without an account.
Attendee, Conference Staff (if payment in person or by phone/mail)
Allows attendee to select registration options
Attendee selects registration options – workshops, tutorials, extra proceedings,
etc. and when finished, proceeds to checkout cart.
10 | P a g e
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Use Case
Name
Actor
Purpose
Overview
Attendee, Conference Staff (if payment in person or by phone/mail)
Allows attendee to register at student discount rates
Attendee provides verification of student status in the form of an active .edu
email address or by presenting student ID card in person at conference.
Check for Scheduling Conflicts
System
Prevents attendees from inadvertently signing up for two or more events
occurring at the same time.
When attendee submits the cart for checkout, each event (workshop, tutorial) is
evaluated to see if the time conflicts with an existing event registration. If it
does, an error message is presented to the attendee. The attendee may chose to
override the error and register for both conflicting events.
Add Event/Extra
Administrator
Allows the administrator to add new conferences, tutorials, or workshops to the
system, as well as extra items, such as additional pamphlets.
When the administrator of the program must add new events (conferences,
tutorials, and workshops) or extras to the system, they will be able to directly
add these events or extras, which will immediately display in the system.
Modify Event/Extra
Administrator
Allows the administrator to modify conferences, tutorials, workshops in the
system, as well as extra items, such as additional pamphlets.
When the administrator of the program must modify events (conferences,
tutorials, and workshops) or extras in the system, they will be able to directly
modify these events or extras, which will immediately display in the system.
Delete Event/Extra
Administrator
Allows the administrator to delete conferences, tutorials, or workshops in the
system, as well as extra items, such as additional pamphlets.
When the administrator of the program must delete events (conferences,
tutorials, and workshops) or extras in the system, they will be able to directly
delete these events or extras, which will immediately display in the system.
11 | P a g e
Detailed Use Cases
USE CASE #
UC-001
USE CASE Name
Pay for ticket
ACTOR
Attendee
Purpose (1 phrase)
Interaction for attendee to submit payment
Overview and scope
Attendee submits payment (online with credit card) and receives confirmation of receipt.
Level
Primary
Preconditions
Postconditions in words
1. Attendee has a user account.
2. Attendee has events/extras in his cart.
3. Attendee is paying online.
Payment processed and ticket accounting updated. Confirmation email sent to attendee
Trigger
Use case triggered by attendee submitting web form
Included Use Cases
Handle Payment
Extended Use Cases
None
USE CASE DESCRIPTION in
numbered sequence:
Actor Action
Reference “included use
cases” in this section using
INCLUDE ius_name
System Action
1. Attendee completes web form and
submits.
2. System validates fields and calculates cost
of ticket(s).
3. Attendee submits credit card info.
4. INCLUDE Handle Payment
5. System updates ticket accounting and
sends confirmation.
6. Attendee receives confirmation email
SUBFLOWS, VARIATION
and EXTENSIONS (Specify
any variations of normal
execution paths, including
extension points using
EXTEND eus_name)
EXCEPTIONS (erroneous
situations)
Step
Priority in scheduling
First
Frequency
Once per user
Superordinates
None
Developer
John Ehring
Creation date and last
modified date
Other Comments
Created: 04 November 2010
Modified: 16 November 2010
None
Branching Action
None
Conditions
Actions
2a. Form validation fails (blank or invalid
entry);
5a. Credit card validation fails
Report error message to attendee and
instruct to correct and resubmit.
Ask to pay by another card or abort
12 | P a g e
USE CASE #
UC-003
USE CASE Name
Add an account
ACTOR
Attendee, Conference staff (if payment in person or by phone/mail)
Purpose (1 phrase)
If attendee does not already have an account, create an account.
Overview and scope
Level
Accounts are used to track cart items and registration information. If the attendee does
not have an account, create an account containing contact information.
Primary
Preconditions
Attendee does not have an account
Postconditions in words
Attendee has an account
Trigger
Included Use Cases
Use case triggered by attendee (or staff member for an attendee) starting the registration
process.
None
Extended Use Cases
None
USE CASE DESCRIPTION in
numbered sequence:
Actor Action
Reference “included use
cases” in this section using
INCLUDE ius_name
System Action
1. Attendee is prompted to create an
account if one does not already exist.
2. System displays account creation form.
3. Attendee completes form and submits
4. System evaluates form for correctness and
a unique account name.
6. Attendee receives confirmation of
successful account creation.
SUBFLOWS, VARIATION
and EXTENSIONS (Specify
any variations of normal
execution paths, including
extension points using
EXTEND eus_name)
EXCEPTIONS (erroneous
situations)
Step
Branching Action
1.
Staff member can complete form for
attendee in the case of phone order or mail
or if attendee is registering in person at time
of the conference.
Conditions
Actions
2a. Form validation fails (blank or invalid
entry);
2a. Requested account name already
exists
Report error message to attendee and
instruct to correct and resubmit.
Report account name already exists. Prompt
for a new account name or provide path to
login screen to allow attendee to login (in
case this was their account)
Priority in scheduling
First
Frequency
Once per user
Superordinates
None
Developer
Robert Sullivan
Creation date and last
modified date
Other Comments
Created: 04 November 2010
Modified: 16 November 2010
None
13 | P a g e
USE CASE #
UC-004
USE CASE Name
Add Item to Cart
ACTOR
Attendee, Conference staff (if payment in person or by phone/mail)
Purpose (1 phrase)
Allows attendee to select registration options
Overview and scope
Level
Attendee selects registration options – workshops, tutorials, extra proceedings, etc. and
when finished, proceeds to checkout cart.
Primary
Preconditions
Attendee has an account
Postconditions in words
Payment processed and receipt issued. Registration information updated.
Trigger
Use case triggered by attendee after logging into account.
Included Use Cases
None
Extended Use Cases
None
USE CASE DESCRIPTION in
numbered sequence:
Actor Action
Reference “included use
cases” in this section using
INCLUDE ius_name
SUBFLOWS, VARIATION
and EXTENSIONS (Specify
any variations of normal
execution paths, including
extension points using
EXTEND eus_name)
EXCEPTIONS (erroneous
situations)
System Action
1.Attendee completes login and selects
item from conference list.
2. System adds item to cart and calculates
and displays cost of items individually and
aggregate.
3. Attendee continues adding items as in
step 1 until proceed to checkout is
selected
Step
Branching Action
1.
Staff member can complete form for
attendee in the case of phone order or mail
or if attendee is registering in person at time
of the conference.
Conditions
Actions
Abort adding item; display “Prerequisite
Registration Needed” error dialog
Priority in scheduling
1. Attendee attempts to add an item
without an existing (in-cart or previously
registered) prerequisite (e.g. tutorial or
banquet ticket w/o corresponding
conference registration)
2. Attendee attempts to add a nonconference event (tutorial or workshop)
that has a schedule conflict with an
existing (in-cart or previously registered)
non-conference event
Primary
Frequency
Once per user
Superordinates
None
Developer
Joe Lizzi
Creation date and last
modified date
Other Comments
Created: 04 November 2010
Updated: 15 Novermber 2010
None
Abort adding item; display “Schedule Conflict”
error dialog
14 | P a g e
Use Case Diagram
Register Account
«uses»
Add Event to Cart
Add Workshop
«uses»
Add Tutorial
«extends»
Attendee
Check for Schedule
Conflicts
Add Option to Cart
Pay for Cart
Print Receipt
«extends»
«external
system»
«uses»
Handle Check
Payment
«uses»
«extends»
Handle Credit Card
Payment
Verify Student
Status
Agent
Print Badge
Apply Discount
Cancel Event
«extends»
Issue Refund
Admin
Modify Event
Add Event
Figure 1 - Use Case Diagram
Payment Verifier
15 | P a g e
Analysis Class Diagram
Workshop
Conference
Tutorial
-workshopID
-name
-description
-theme
-date
-startTime
-endTime
-registeredAttendees
-conferenceID
-name
-description
-startDate
-endDate
-startTime
-endTime
-registeredAttendees
-tutorialID
-name
-description
-topic
-minimumRegistered
-startDate
-endDate
-startTime
-endTime
-registeredAttendees
Administrator
-accountName
-permissions
0..*
Event
CustomerAccount
-registrationID
-name
-address
-phoneNumber
-email
-affiliation
-isStudent
-isRegistered
1
1
0..*
0..*
0..*
-eventID
-price
-location
-city
-discountCutoffDate
-earlyDiscount
-studentDiscount
Extras
-name
-description
-price
-extrasID
0..*
0..*
1
1
1..*
1
Payment
1
Receipt
-eventName
-eventDate
-city
-datePaid
-amountPaid
-affiliation
-address
-receiptID
-type
-amount
-date
-transactionID
Verification<<interface>>
-isAuthorized
1
Credit Card
-number
-CSC
-expDate
-
Figure 2 - Analysis Class Diagram
Check
-checkNbr
-routingNbr
-date
16 | P a g e
Design Class Diagram
Workshop
Conference
Tutorial
-workshopID
-name
-description
-theme
-date
-startTime
-endTime
-registeredAttendees
-conferenceID
-name
-description
-startDate
-endDate
-startTime
-endTime
-registeredAttendees
-tutorialID
-name
-description
-topic
-minimumRegistered
-startDate
-endDate
-startTime
-endTime
-registeredAttendees
Administrator
-accountName
-permissions
+login()
0..*
CustomerAccount
Event
-registrationID
-name
-address
-phoneNumber
-email
-affiliation
-isStudent
-isRegistered
-registeredEvents : collection : Event
-boughtExtras : collection : Extras
-eventReceipt : Receipt
+createAccount()
+updateInfo()
+validateStudent()
+login()
+createCart()
+updateCart()
+viewCart()
+deleteCart()
11
1
1
0..*
1
-eventID
-price
-location
-city
-discountCutoffDate
-earlyDiscount
-studentDiscount
+createEvent()
+updateInfo()
+getInfo()
+deleteEvent()
+getDiscount()
+getDiscountPrice()
+registerAttendee()
0..*
Extras
-name
-description
-price
-extrasID
+createExtras()
+setDependency()
+updateInfo()
0..*
0..*
1
1..*
Payment
1
Receipt
-eventName
-eventDate
-city
-datePaid
-amountPaid
-affiliation
-address
-receiptID
+createReceipt()
+printReceipt()
+updateReceipt()
0..*
-type
-amount
-date
-transactionID
+submitPayment()
+verifyPaymentStatus()
+issueRefund()
Credit Card
-number
-CSC
-expDate
Figure 3 - Design Class Diagram
Verification<<interface>>
-isAuthorized
Check
-checkNbr
-routingNbr
-date
17 | P a g e
System Analysis – Validation & Discussion
The system analysis of our Conference Registration System involved the formulation of the fundamental
principles of our system. To properly understand and flesh out these principles, we developed a number of
textual use cases and extended use cases, as well as a use case diagram, an analysis class diagram, and a design
class diagram. All of these techniques allowed our team to better articulate the demands of our system in terms
of objects, classes, attributes, relationships, scenarios, and actors.
The use cases presented above each serve as a particular scenario or function that would expect the Conference
Registration System to have to complete to satisfy the objectives stated in the problem statement. The three
detailed use case diagrams (also above) take three specific use cases into much further depth, offering
information such as preconditions, postconditions, sequences, subflows, and many other types of important
information that was immediately relevant in the creation of several UML diagrams. One such diagram, the use
case diagram (Figure 1), is perhaps the most immediately relevant to the individual use cases. This diagram
illustrates how each actor will be involved with each use case, as well as how the use cases themselves interact,
include, or extend other use cases.
The analysis class diagram (Figure 2) brings the information presented in Figure 1, the use case descriptions, and
extended use cases into focus by modeling the classes of our system. These classes, though not software
components themselves, will influence later software development. All objects in our system will be
instantiations of these classes. With this in mind, each class has some inherent attributes which are passed to all
objects of that class. An interesting example of this aspect of classes occurred during our development process.
At first, we deemed it most efficient for the Events class to comprise all attributes of the Conference, Workshop,
and Tutorial classes. In this regard, a Conference would be an object which was instantiated from the Events
class. However, we later determined that too high a degree of variation existed between these three concepts,
and so we decided to create the three Events subclasses: Conference, Workshop, and Tutorial. Another
additional feature of the analysis class diagram is its inclusion of cardinality for its classes. Figure 2 illustrates
how the cardinality of our system is centered on the notion that only one customer account can exist. All
transactions, events, and actions occur under the assumption that they will only interact with one customer
account at any given time.
The final diagram presented in the System Analysis portion of our project is the design class diagram. Very
similar to our analysis class diagram, Figure 3 offers more information about how our system will operate in the
form of functional methods. These methods will form the basis of most interactions of our system, and as such
will be modeled in the sequence diagrams in the System Design section (Figure 4, Figure 5, Figure 6, and Figure
7). The methods covered in Figure 3 cover most actions in our system, including those functions related to the
creation of accounts, the creation, modification, and deletion of events, the calculation of discount prices,
processing payments, sending receipts, enter information, and many other tasks which are essential to the
successful operation of the system.
18 | P a g e
System Design
System Sequence Diagram
A Customer <<actor>>
conference:Conference
ticket:Extras
customer:CustomerAccount
payment:Payment
Verification<<interface>
>
submitInfo()
confirmInfo()
<<create>>
selectEvent()
addtoCart()
finalizePurchase()
selectAdditional()
addtoCart()
finalizePurchase()
gotoCheckout()
calculatePrice()
requestCCDetails()
enterCCInfo()
confirmPayment()
submit()
verifyPayment()
paymentVerified()
sendReceiptInfo()
sendReceipt()
Figure 4 - System Sequence Diagram
receipt:Receipt
19 | P a g e
Sequence Diagram (Add Account)
Attendee<<actor>>
account:CustomerAccount
Security
AddAccount()
Request Username
SubmitUsername(Username, password, pwd_verify)
checkUsername(Username)
returnUsernameOK(Username)
Verify not duplicate
checkPassword(password, pwd_verify)
Verify passwords match
Verify complexity req.
returnPasswordOK(password)
Report Username OK
Request Contact Information
submitContact(address)
Validate Address
submitEmail(email_address)
Validate Email
Report Account Creation Success
Figure 5 - Sequence Diagram (Add Account)
20 | P a g e
Sequence Diagram (Add Event to Cart)
EVENT
ATTENDEE
ATTENDEE:Cart
list Events()
getDiscount(isEarly, isStudent)
event list, discount %
get Info(Event)
getDiscountPrice()
description, price, discounted price
createCart()
[Cart does not exist]
addItem(Event)
getPrice(Event)
price
viewCart()
Figure 6 - Sequence Diagram (Add Event to Cart)
updateCart()
21 | P a g e
Sequence Diagram (Pay for Ticket)
USER
Payment
Verification<<interface>
>
Pay for items
Check Cutoff Date
Validate items
Return Cutoff Status
Check Student Status
Return Student Status
Apply Discounts
Request Payment
Calculate price
Enter Credit Info
Verify Credit Info
Credit Verified
Approve Purchase
Receipt
UpdateGenerate
inventories
E-mail receipt
Figure 7 - Sequence Diagram (Pay for Ticket)
Receipt
22 | P a g e
State Diagram
User submits login credentials
Prompt for
resubmission
Fail
Validate
Login
Notify Error
Pass
Display Conference Pick List
Select
Item
Added to Cart
Add
Another?
Yes
No
Yes
Calc Student Discount
Is student?
No
Yes
Is early?
No
Display Price/Prompt for payment
Receive
Payment
Error
Prompt for Cancel or Retry
Validate
Payment
OK
Generate Receipt
User Log out
Figure 8 - State Diagram
Calc Early Discount
23 | P a g e
System Design – Validation & Discussion
The System Sequence Diagram (Figure 9) shows the success path for conference registration and payment using
the Conference Reservation System. The diagram shows the interaction required to create an account, select
conference offerings and make payment. Each of these steps is shown in greater detail in subsequent Sequence
Diagrams.
The Add Account Sequence Diagram (Figure 10) shows the interaction required to initially create an account
prior to shopping with the Conference Reservation System. The attendee (actor) submits the desired
username/password to the Customer Account system. Customer Account first passes the desired username to
the Security system to verify the username does not already exist. Once the username clearance is received, the
Security system evaluates the desired password to ensure complexity requirements are met and the password
and repeated password entered match. Customer Account receives the Password OK and reports success to the
attendee. The attendee is then prompted to supply contact information to associate with the account.
Assigning each attendee an account allows the system to track “carts” and provides a mechanism for the
attendee to only enter the contact information only once instead of once per conference.
The Add Event to Cart Sequence Diagram (Figure 11) shows the success path for adding one or more items to
the attendee’s “cart”. Once the attendee selects the conference, the system displays all the items available
(sessions, tickets, proceeding, etc.) and the attendee’s price for each item, based on status (student/regular) and
registration status (early/late). As the attendee selects items for the cart, the system maintains a running list of
the cart’s contents, item price and total price. The “cart” system was selected to allow flexibility in the
programming of the system. By treating sessions, tickets, et al. as items to be added it allows the system to
maintain a simple database for each conference, instead of custom programming.
The final Sequence Diagram, Pay for Ticket (Figure 12), is activated when the attendee is finished adding items
to the cart and proceeds to checkout. The attendee’s student and registration status is verified to ensure the
pricing displayed is correct. Once confirmed, the attendee is prompted for payment information. Following
successful conformation of the financial transaction, a receipt is generated and sent via email to the attendee.
This method allows the system to save the cart, so the attendee can come back and view what has been
purchased for a given conference.
The State Diagram (Figure 13) shows the success path (as in the System Sequence Diagram). The State Diagram
shows the decision tree that is followed for completing a transaction from start to finish.
24 | P a g e
Physical Design
Entity-Relationship Diagram
custAccount
PK
registrationID
name
address
phoneNum
email
affiliation
isStudent
Attendee
boughtExtras
FK1
FK2
FK3
registrationID
EventID
transactionID
FK1
FK2
FK3
Extras
extrasID
FK1
name
description
price
EventID
registrationID
extrasID
transactionID
Event
PK
PK
EventID
Name
location
city
discountcutoff
price
type
description
startTime
endTime
earlyDiscount
studentDiscount
Conference
PK,FK1
EventID
startDate
endDate
PK,FK1
EventID
theme
date
Receipt
PK
Tutorial
Workshop
transactionID
date
amount
paymentType
Figure 14 - Entity-Relationship Diagram
PK,FK1
EventID
topic
minimumAttendees
startDate
endDate
25 | P a g e
Deployment Diagram
<<kiosk>> ;CRS Kiosk
<<web server>> ;CRS WebServer
<web server>>
;Apache 2.1
<<database>>
;MySQL Database
PHP:MySQL
Module
<<OS> ;Ubuntu
HTTP/S
<<interface>>
;PHP5
HTTP/S
<<browser>>
;Firefox
<<PC>> Home/
Registration PC
<<browser>
Web browser
Figure 15 - Deployment Diagram
Physical Design – Validation & Discussion
The Entity-Relationship Diagram (Figure 9) maps the class-object model into a more database-ready design. Each
entity represents a table in the database. An Event represents the conference itself, as well as the various
workshops and/or tutorials that may be available. In addition to things like the name, dates, and location, it also
stores any available discount (early registration and/or student). Extras is for the optional things such as printed
(versus on CD) proceedings, banquet tickets, and so on; note that no Extra can exist by itself, but needs to be
linked to a particular Event (generally the conference itself, although there may be optional materials available
for specific workshops or tutorials).
custAccount represents the attendee’s personal information, and is modeled on a “registered account” model of
ordering (such as would be found in most online stores, like Amazon). Along with the expected address and
name, there is also a flag for student discount eligibility (when applicable). The student eligibility is set through
automated means such as a “.edu” email address, or manually via a copy of the student ID card. The Attendee
entity allows the database to store the many-to-many relationship inherent with attendees and events (each
event can have multiple attendees, and each attendee can register for multiple workshops and tutorials), by
creating a “bridge” that acts as a quick lookup table. boughtExtras has a similar purpose, but for the Extras
entity.
26 | P a g e
Finally, the Receipt entity stores the total amount paid by the attendee for the conference, workshops, tutorials,
and any extras. It, too, is linked to Attendee and boughtExtras, so that it may accurately reflect all registration
fees and purchases.
The Deployment Diagram (Figure 10) shows the overall system and software architecture. The Conference
Registration System will be designed as a web application, which can be accessed from any standard web
browser (Internet Explorer, Firefox, Safari, etc), including those on most modern phones. It can run in both
normal (HTTP) and secure (HTTPS) browsing modes, although HTTPS will automatically be used when entering
any credit card payment information.
The system itself is a simple Apache web server, running the PHP scripting language, and connecting to a MySQL
database. The “CRS Kiosk” will be a terminal setup at the conference for on-site registration; it will be a
simplified setup of Firefox running on Linux, and can either be hooked to a touch-screen for input, or a standard
mouse-and-keyboard.
27 | P a g e
Applications Design
Screenflow Diagram
Conference
Homepage
Create Account
Create
Account
User Login
Account Created
Login
Login Successful
Continue Shopping
View Cart
Logout
Conference
Offerings
Order Cleared
Logout
Proceed to Checkout
Cart Contents
Proceed to Checkout
Cancel
Order
Cancel Order
Checkout
Cancel Order
Enter Payment
Payment
Payment Verification Successful
Order
Confirmation
Figure 16 - Screenflow Diagram
Cancel Order
28 | P a g e
Applications Design – Validation & Discussion
The Screenflow Diagram (Figure 17) provides the navigation path between screens based on user (attendee)
actions. The home page is the Conference Homepage, which is unique for each conference. The attendee
either creates a new account or logs in using an existing account. Following successful login authentication, the
Conference Offerings page is shown. This page lists the sessions, event tickets, additional proceedings and other
items available for sale for the conference. The price displayed for each item is based on the attendee status
(regular/student) and registration status (early/late). At any time, the attendee can view his/her cart’s current
contents. Once the attendee is finished adding items, he/she proceeds to the Checkout. Here, the attendee
enters payment information. Alternately, the attendee can choose to return to the Conference Offerings page
to add more items or clear the cart.
Completion of the order is shown on the Order Confirmation screen. Leaving the Order Confirmation screen or
logging out at any point sends the attendee back to the Conference Homepage.
Evaluation of Analysis & Design
Project
If we could redo the project, and had more time to do so, there are several things that we would change:



We would look at a few existing designs, in order to have a better starting point for Inception.
We would create three or four different approaches to the problem, doing initial analysis work on each
one to determine which approach is the most straightforward and feasible. (The current account-andshopping-cart approach does work, but it was a little bit difficult at times to model, given our limited
experience with UML and OOA&D concepts.)
Work deadlines, section meetings, and general discussions would follow a more defined and structured
schedule.
Domain
The domain of the project, a semi-automated registration system for an academic conference, was very
appropriate for our group. We were able to successfully implement a number of functional and design artifacts
which could contribute to the actual creation of this system. However, our team stopped short of completing
more of the Physical Design and Interface Design which would be necessary to fully flesh out the system and
create a working prototype. With more time, effort, and resources, the design of this system could be
completed, and development work could begin.
UML
Unified Modeling Language was used to successfully model the design of the Conference Registration System
and critically evaluate the design for conformance to the requirements. The process required to create a UML
based model necessitated carefully reviewing the system requirements. Creating the sequence diagrams
flushed out the parameters and methods for the class model.
29 | P a g e
Modeling Tools
During the course of our project, we primarily used two modeling tools: Microsoft Visio and Gliffy. We began
using Gliffy for its ability to assist in the creation of models and diagrams in real time over the Internet. This was
seen as particularly attractive, because it was impossible for our team to meet face-to-face. That being said, we
found Gliffy’s options to be limited in terms of diagramming capability, in addition to setbacks we faced while
trying to diagram via Gliffy and communicate via Skype voice chat. We soon abandoned Gliffy for the vastly
superior Microsoft Visio.
Visio, a recommendation of the professor to be used in the course, offered a lot more in terms of compatibility,
availability, and ease of use. One team member was using Visio on a Mac; this caused a number of compatibility
issues, such as partially corrupting a diagram file and making changes to another impossible. These setbacks
were frustrating, but ultimately they were few and far between. The majority of our work with Visio was very
productive, and Visio provided a very clean way to not only create our diagrams, but to share them as well.
Appendix
Division of Work
Item
Problem Statement
Requirements
Use Cases
Detailed Use Cases
Use Case Diagram
Analysis Class Diagram
Design Class Diagram
System Sequence Diagram
Sequence Diagram (Pay for Ticket)
Sequence Diagram (Add Account)
Sequence Diagram (Add Event to Cart)
State Diagram
Deployment Diagram
Entity-Relationship Diagram
Screenflow Diagram
Evaluation of Analysis & Design
Validation & Discussion
Completed Primarily By
Group Seven
Rob Sullivan
Group Seven
John Ehring, Joe Lizzi, Rob Sullivan
Group Seven
Group Seven
Joe Lizzi
John Ehring
John Ehring
Rob Sullivan
Joe Lizzi
Rob Sullivan
John Ehring, Joe Lizzi
Joe Lizzi
Rob Sullivan
Group Seven
Group Seven
Note: While the above table demonstrates the person primarily responsible for each item, all items were
discussed and edited collaboratively and approved by the team.
30 | P a g e
Lessons Learned – John


Perhaps the most important phase of the entire project was the initial planning stages at which the use
cases and class diagrams were created. While not true of all diagrams, the class diagrams (created from
the information gathered in the use cases) provided a basis for many of the other diagrams created in
this project.
A very useful tool was the creation of a project proposal which outlined which diagrams and work items
would be due and when. This allowed for easier communication and better planning, which resulted in a
more coherent product.
Lessons Learned – Joe



The UML specification is very flexible and powerful, and is able to model many things in many ways.
Unfortunately, this can also make it confusing and hard to work with sometimes, as I wasn’t always sure
that I had the right notation or symbol.
Having gone through this project, it is easier to see how the various diagrams and specifications relate to
one another, both directly and indirectly.
Working in Visio is both a blessing (powerful, most of the UML symbols, easy to move around objects),
and a curse (some of the UML notation is slightly different, changing the labels and text on lines and
other objects is not straightforward, the snap-to-grid feature only kinda-sorta works).
Lessons Learned – Rob


I found the exercise to be very time consuming. I suspect that with practice and experience, the effort
required to create a UML design will decrease.
I found the state diagram to be implementation dependent. That is, it makes sense when dealing with a
physical system. However, I found it less useful when dealing with a system that is strictly abstract.
References
Larman, Craig (2004). Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and
Iterative Development, Third Edition. Prentice Hall. Retrieved from the Drexel University Library Online
Song , Il-Yeol, Kurt Yano, Juan Trujillo, and Sergio Luján-Mora (2004). “A Taxonomic Class Modeling Methodology
for Object-Oriented Analysis". Information Modeling Methods and Methodologies. Idea Group Publishing. pp.
216-240