INFO 620 ~ Information Systems Analysis and Design
Fall 2003
Analysis & Design Project
Conference Registration System
(CRS)
Olga Alsheimer
Nicole Carfagno
Alex Podoksik
December 11, 2003
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Table of Contents
Section
Page
Introduction ......................................................................................... 4
Overview .......................................................................................... 4
Nature of CRS ................................................................................... 4
Assumptions and Scope ...................................................................... 4
Systems Analysis .................................................................................. 5
Problem Statement ............................................................................ 5
Use Case Diagram ............................................................................. 7
Analysis Class Diagram ....................................................................... 8
Use Case Descriptions ........................................................................ 9
Maintain Conference Offerings - Carfagno .......................................... 9
USE CASE # ........................................................................................ 9
USE CASE Name ................................................................................... 9
ACTOR ................................................................................................ 9
Purpose (1 phrase) ............................................................................... 9
Overview and scope .............................................................................. 9
Level................................................................................................... 9
Preconditions ....................................................................................... 9
Postconditions in words ......................................................................... 9
Collect Marketing Data – Carfagno .................................................. 12
USE CASE # ...................................................................................... 12
USE CASE Name ................................................................................. 12
ACTOR .............................................................................................. 12
Purpose (1 phrase) ............................................................................. 12
Overview and scope ............................................................................ 12
Level................................................................................................. 12
Preconditions ..................................................................................... 12
Postconditions in words ....................................................................... 12
Process Registration – Podoksik ...................................................... 14
USE CASE # ...................................................................................... 14
USE CASE Name ................................................................................. 14
ACTOR .............................................................................................. 14
Purpose (1 phrase) ............................................................................. 14
Overview and scope ............................................................................ 14
Level................................................................................................. 14
Preconditions ..................................................................................... 14
Postconditions in words ....................................................................... 14
Process Payment – Podoksik........................................................... 18
USE CASE # ...................................................................................... 18
USE CASE Name ................................................................................. 18
ACTOR .............................................................................................. 18
Purpose (1 phrase) ............................................................................. 18
Overview and scope ............................................................................ 18
Level................................................................................................. 18
2
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Preconditions ..................................................................................... 18
Postconditions in words ....................................................................... 18
Process Cancellation – Alsheimer .................................................... 22
Process Refund – Alsheimer ........................................................... 24
Generate E-mail Confirmation – Alsheimer ....................................... 26
Systems Analysis - Validation & Discussion ......................................... 28
Systems Design ................................................................................. 32
System Sequence Diagrams .............................................................. 32
Process Registration SSD - Podoksik ................................................ 32
Process Payment SSD – Podoksik .................................................... 33
Process Cancellation SSD – Alsheimer ............................................. 34
Sequence Diagrams ......................................................................... 35
Collect Marketing Data SQD - Carfagno............................................ 35
Collect Marketing Data SQD – Carfagno ........................................... 36
Maintain Conference Offerings SSD – Carfagno ................................. 37
Process Registration SQD - Podoksik ............................................... 40
Process Payment SQD – Podoksik ................................................... 43
Process Cancellation SQD – Alsheimer ............................................. 45
Process Refund SQD – Alsheimer .................................................... 47
Generate E-mail Confirmation SQD - Alsheimer ................................ 48
State Diagram – Registration ............................................................ 49
Design Class Diagram....................................................................... 50
Systems Design – Validation & Discussion........................................... 51
Evaluation of Analysis and Design ......................................................... 53
Summary and Lessons Learned ............................................................ 54
References ........................................................................................ 55
Appendices ........................................................................................ 56
Individual Experience & Lessons - Alsheimer ....................................... 56
Individual Experience & Lessons – Carfagno ........................................ 58
Individual Experience & Lessons – Podoksik ........................................ 59
Taxonomic Class Modeling Methodology .............................................. 60
SQD 10-step Heuristics..................................................................... 63
3
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Introduction
Overview
This purpose of this project is to develop a web-based conference
registration system (CRS) to accommodate organization of yearly
conferences, tutorials and workshop sessions. The system should be flexible
enough to adapt to various conference registration needs. For example,
some conferences may include tutorials, workshops, technical programs and
expositions, while others include only a subset of those activities. The
system should also allow registrants to select attendance at associated
special events and to purchase extra copies of conference material.
Nature of CRS
Through this system, a conference participant should be able to enter and
maintain personal information, select conference activities, and enter
payment information. The system should also allow for collection of
marketing data. The system should display information regarding what is
included in each registration, as well as registration dates and fees for each
activity. The system should also display refund policies and cancellation
procedures.
The system should accommodate different types of conference fees for each
activity, according to early/late registration date and registrant status. It
should calculate the proper price for each activity based on registration date
and status. The system should allow registrants to pay for all activities at
once or to select and pay for separate components at different times using
different registrations. Participants should be able to indicate preferred form
of payment and enter related information. Credit card payments would be
authorized and processed as part of the web-based registration.
Assumptions and Scope
The conference registration system will be in one language (English) and
payment will be in one currency (US Dollars). This system will support
automated conference registration, billing, ticket purchasing and financial
reporting. The system will support web, phone, mail-in, and walk-in
registration modes. The system will process attendee payment information.
Although the registration system will track participant payment for
conference materials, procedures for actual distribution of conference
proceedings and tutorial notes will be outside the scope of the system.
Ideally, the system could be integrated with an organization's overall
conference management system (i.e., tracking of accepted papers, invited
speakers, hall assignments). This integration is outside the scope of the
project.
4
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Systems Analysis
Problem Statement
This project designs a web-based conference registration system (CRS) to
accommodate organization of yearly conferences, tutorials and workshop
sessions. The system should be flexible enough to adapt to various sponsor
organizations' (e.g., CIKM, XML, Seybold) particular conference registration
needs. For example, some sponsors may offer tutorials, workshops,
technical programs and expositions, while other sponsors offer only a subset
of those activities. Thus, the system may be used for any combination of
conference activities. The system should also allow registrants to select
attendance at associated receptions, lunches and banquets (including special
meal request), and/or other special events (e.g., sightseeing tours affiliated
with a particular conference).
Through this system, a conference registrant should be able to enter and
maintain personal information (name, mailing address, phone numbers, email, company affiliation, job function, and status such as membership
identification), select from a menu of conference activities, and enter
payment information. Furthermore, the system should allow sponsors to
collect marketing data (i.e., inquire where registrants learned about the
conference) and ask whether registrants wish to be included on future
mailing lists.
The system should display information regarding what is included in each
registration, as well as registration dates (pre-, late, on-site) and
registration fees (by date and status) for each of the conference activities.
The system should also display refund policies, cancellation procedures, and
instructions and contact information for registrants with questions.
Registrants must submit cancellation request via mail, phone or fax. Only
conference staff may process cancellations and refunds.
The system should accommodate different types of conference fees for each
activity (workshop, tutorial, etc) according to early/late registration date and
registrant status (member, nonmember, student). It should also include a
"quick calculator" to calculate the proper price for each activity based on
registration date and status. Once a registrant selects a combination of
activities (conference sessions, tutorial, workshop, one or more tickets for
lunches or banquets, receptions, tours, extra proceedings), the system
should calculate the total fee.
The system should allow registrants to pay for all activities at once or to
select and pay for separate components at different times using different
registrations. Registrants should be able to indicate preferred form of
payment and enter related information. Acceptable forms of payment include
cash, check, traveler's check and credit card. Cash, check and traveler's
5
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
check payments would need to be mailed and processed separately from the
web-based registration. A registration would be marked as "incomplete" until
payment was received and processed. Credit card payments would be
authorized and processed as part of the web-based registration.
The system should keep a record of participants registered for each type of
session, indicate seat availability, and identify if conference tutorial session
cannot be opened due to lack of required number of participants registered.
Conference staff should be able to generate conference reports, including
attendee lists by event (e.g., conference, workshops, tutorials), and print
tickets for special events.
This system will support automated conference registration, billing, ticket
purchasing and financial reporting. The system will support web, phone,
mail-in, and walk-in registration modes. The system will process attendee
payment information. The system will centralize all the activities surrounding
registration and billing.
Although the registration system will track registrant payment for conference
materials, procedures for actual distribution of conference proceedings and
tutorial notes will be outside the scope of the system. This system will allow
for web-based registration. However, conference personnel will be able to
use the system to process registrations received by mail, phone and/or fax.
Furthermore, an sponsor may choose to set up workstations at a conference
site to accommodate on-site registration.
Ideally, the system could be integrated with an sponsor's overall conference
management system (i.e., tracking of accepted papers, invited speakers,
hall assignments). This integration is outside the scope of the project.
Finally, maintenance of the main organization and conference websites is
outside the scope of the system.
6
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Use Case Diagram
System Boundary =
Conference Registration System (CRS)
The follow ing aspects are OUTSIDE the scope of CRS:
1. Maintenance of conference w ebsite;
2. Distribution of conference proceedings;
3. Tracking conference papers, speakers, hall assignments.
<<extend>>
Request Event Tickets
Sponsor
<<include>>
Process Conference Registration
Collect Marketing Data
Registrant
<<include>>
Check Registration Status
Issue Confirmation
<<include>>
<<include>>
Process Payment
Staff
CCAS
<<include>>
Process Cancellation
Process Refund
Generate Conference Reports
Maintain Conference Offerings
7
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Analysis Class Diagram
8
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Use Case Descriptions
Maintain Conference Offerings - Carfagno
USE CASE #
USE CASE
Name
ACTOR
Purpose (1
phrase)
Overview
and scope
Level
Preconditio
ns
UC01
Maintain Conference Offerings
Staff
CSR maintains conference offerings
To keep track of the type of conference being offered
and its id. Also to keep track of they type of member
and the amount due for the conference. Also keeps
track of refund policies, cancellation policies and
contact information for registrants that have
questions.
Primary
The
The
The
The
The
sponsor has listed the conferences.
list of dates and status are listed for each activity
refund policies are included
cancellation policies are included
contact information is included
The conferences are offered
Postconditio The dates and status were listed for each activity
ns in words The refund policies were included
Trigger
Included Use
Cases
Extended Use
Cases
MAIN
SUCCESSFUL
SCENARIO in
numbered
The cancellation policies were included
The contact information was included
A list of conferences are offered
Actor Action
1. The sponsor lists
yearly conferences and
types of conferences
System Action
9
INFO 620, Fall 2003, Analysis & Design Project
sequence
Reference
“included use
cases” in this
section using
INCLUDE
ius_name
Alsheimer, Carfagno, Podoksik
2. The system displays the
conferences offered and
what is included in each
registration
3. The sponsor added
the fees for each activity
by date and status
4.The system displays
different fees for each
activity by date and status
5. The sponsor added
the refund policies for
the conferences
6. The system displays
refund policies.
7. The sponsor added
the cancellation
procedures
8. The system displays
cancellation procedures
9. The sponsor added
instruction and contact
information for
registrants with
questions
10. The system displays
instructions and contact
information for registrants
with questions
OTHER
SUCCESSFUL
SCENARIOS
(Specify any
successful
variations of
the normal
execution path,
including
extension
points using
EXTEND
eus_name)
UNSUCCESSF
UL
SCENARIOS
Step
Branching Action
Conditions
1a. No conferences are
available
Actions
CRS can not maintain
information
10
INFO 620, Fall 2003, Analysis & Design Project
(erroneous
situations)
4a. No prices are added
to conferences
6a. No refund policies
are added
8a. No cancellation
procedures are added
10a.No contact
information is provided
Priority in
scheduling
Frequency
Superordinate
s
Developer
Creation date
and last
modified date
Other
Comments
Primary
Alsheimer, Carfagno, Podoksik
Can not display to
registrant
Can not notify registrants
on refund policies
Can not notify registrants
of cancellation policies
Registrants will not know
who to contact regarding
questions
Yearly
Nicole Carfagno
11-11-2003
11
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Collect Marketing Data – Carfagno
USE CASE #
USE CASE
Name
ACTOR
Purpose (1
phrase)
Overview
and scope
Level
Preconditio
ns
U02
Collect Marketing Data
Sponsor
CRS collects marketing information
For the sponsor to track of information about
registrants such as where they heard about the
conference and if they would like to receive
information about future conferences by being part of
the mailing list
Included
Information regarding registrant is included in
personal information
The registrant’s information as to how they heard
Postconditio about conference was known.
ns in words The registrants requested information about future
conferences
Trigger
Sponsor inquires information about how registrants
learned about conference
Included Use
Cases
Extended Use
Cases
MAIN
Actor Action
System Action
SUCCESSFUL
1. The CRS displays a form
SCENARIO in
to fill out marketing data.
numbered
2. Staff adds registrants
sequence
marketing information
3. CRS updates statistics as
Reference
to how registrants learned
“included use
about conference.
12
INFO 620, Fall 2003, Analysis & Design Project
cases” in this
section using
INCLUDE
ius_name
Alsheimer, Carfagno, Podoksik
4. CRS checks to see if
registrant requests
information about future
conferences.
5. CRS sends out
information about future
conferences.
OTHER
SUCCESSFUL
SCENARIOS
(Specify any
successful
variations of
the normal
execution path,
including
extension
points using
EXTEND
eus_name)
UNSUCCESSF
UL
SCENARIOS
(erroneous
situations)
Step
Branching Action
Conditions
2a. Registrant does not
include information on
how they learned about
conference
Actions
No information is collected
Priority in
scheduling
Frequency
Superordinate
s
Developer
Creation date
and last
modified date
Other
Comments
Second
Several times a year
Nicole Carfagno
11-11-03
13
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Registration – Podoksik
USE CASE #
USE CASE Name
ACTOR
Purpose (1
phrase)
Overview and
scope
Level
Preconditions
Postconditions
in words
Trigger
Included Use
Cases
Extended Use
Cases
MAIN SUCCESSFUL
SCENARIO in
numbered
UC03
Process Conference Registration
Registrant
To register for a conference
Registrant enters all the necessary personal and billing
information, selects conference activities,
accommodations and proceedings, pays for purchased
items. System will store all provided information,
determines seat availability, calculates total fee, updates
seat availability information and sends conformation by
email to registrant.
Should registrant decide to pay by CC online, system
validates customer credit and process payment.
Primary
Registrant is successfully accessed CRS entrance web
site.
 Registrant registered for conference.
 Registrant had scheduled conference activities.
 System recorded all required registrant
information and scheduling.
 System had calculated and recorded total fee.
 If desired, credit card payment for conference is
processed, and the card is charged.
 Confirmation email has been sent to registrant
with registrant’s detailed registration information.
Customer logged into the system and navigates to
“Register for Conference” option. “Register for
Conference” web page appears.
Process Payments.
Send Email Confirmation.
None.
Actor Action
System Action
1. Navigates to “Register
Conference” page.
14
INFO 620, Fall 2003, Analysis & Design Project
sequence
Alsheimer, Carfagno, Podoksik
2. Display conference
activities, such as:
presentations, tutorials,
workshop sessions, technical
programs and expositions.
Display other conference
offerings, such as:
receptions, banquets (with
“special” meal requests
forms), special events and
extra proceedings. Display
their schedule and specify
pricing options.
Indicate variances in fees
based on different criteria
such as: registrant status
(member, nonmember, and
student), early/late
registration.
Allow registrant to select
various items from the
conference activities and
offering lists and
accommodate registrant in
calculation of total fee.
The system should present
the final total fee to
registrant. Display the option
to cancel or continue
registration. Display a form
with username and login text
boxes to enter if registration
account is already created.
[Scenario:
Registrant registers
online for conference
including online
credit card
payment.]
3. Registrant chooses to
continue registration.
4. Display required input form
for registrant to fill out name,
mailing address, phone
numbers, e-mail, company
affiliation, job function, status
and, if member, membership
identification. Allow registrant
to create username and
password. Display message
to review entered information
and continue registration.
15
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
5. Registrant proceeds
to the next page.
6. Display information
presented by registrant with
ordered conference options
and total fee. Prompt
registrant to confirm entries
or edit information.
7. Display a message
indicating that registration
account for registrant has
been created and provide
registrant with Registration
ID.
8. Display to registrant
payment options: cash,
check, traveler’s check or
credit card. For mail-in
payments display address for
mail-in payments. Display an
option to pay in full or
partially by credit card online.
Display an option to finish
registration now with
“incomplete” status until
payment for conference is
processed.
9. Registrant selects to
make a payment by
credit card.
10. INCLUDE Process Credit
Card.
11. If status returned ok,
display message thanking for
registration and informing
registrant that confirmation
email report is sent to
registrant’s email address.
12. INCLUDE Send
Confirmation Email.
OTHER
SUCCESSFUL
SCENARIOS
Step
Branching Action
2a. Registrant aborts
registration
6a. Registrant selected
to edit the information.
System displays starting page
of the conference.
Return to step 4.
16
INFO 620, Fall 2003, Analysis & Design Project
8a. Registrant decided
to pay by other means
than credit card later.
UNSUCCESSFUL
SCENARIOS
(erroneous
situations)
Priority in scheduling
Frequency
Superordinates
Developer
Creation date and
last modified date
Other Comments
Conditions
10a. Credit card
validation fails
Alsheimer, Carfagno, Podoksik
Proceed to step 10 continue
from there. Registrant
information is considered
incomplete until paid in full.
Confirmation report should
contain an INCOMPLETE
status.
Actions
Abort transaction. Inform
registrant about the failure.
Go to step 11.
Primary
TBD
Alex Podoksik
Created 11/12/2003
17
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Payment – Podoksik
USE CASE #
USE CASE
Name
ACTOR
Purpose (1
phrase)
Overview
and scope
Level
Precondition
s
Postconditio
ns in words
Trigger
Included Use
Cases
Extended Use
Cases
U06
Process Payments.
Registrant, Staff, CCAS, Bank.
Process payments for conference.
Registrant or Staff on behalf of Registrant pays for
conference by credit card, check, traveler’s check or
cash.
If paid by cash, Staff enters paid amount and
system returns ok status.
If paid by check or traveler’s check, Staff enters
check amount. Checks are deposited to conference
bank account and system returns ok status when
money is transferred to the account.
If paid by credit card, Registrant or Staff enters
registrant’s credit card information. System submits
the data to CCAS for authorization. If authorized,
system processes the charge, submits the charge to
subscriber’s credit card and returns ok status.
Included
Registrant submits some form of payment or
chooses to pay by credit card online.

Registrant payment is processed by the
system and conference is paid by registrant.
 Status successfully returned to the host
system.
Registrant mails-in the check.
Registrant pays by cash or traveler’s check
Registrant calls in to pay by credit card.
Registrant selects to pay by credit card online.
none
none
18
INFO 620, Fall 2003, Analysis & Design Project
MAIN
SUCCESSFUL
SCENARIO in
numbered
sequence
Actor Action
Alsheimer, Carfagno, Podoksik
System Action
1. Display login page with
username and login inputs.
2. Staff enters login
and username.
3. Display message to user
indicating that he/she is
about to be redirected to
the secure site.
4. Display input box to
enter Registration ID or
other input boxes (name,
membership ID, phone
number, email) to search
for registrant’s registration
account.
5. Staff enters
Registration ID
provided by Registrant
6. Display registrant’s
account information with
payment options:
 Pay by cash
 Pay by check
 Pay by credit card
7. Staff selects to Pay
by Credit Card
8. Display billing and credit
card information form with
required fields indicated to
be filled in.
9. User inputs credit
card information and
submits data for
processing.
10. Verifies that required
fields are filled in.
11. If required fields are
filled in, validate data
integrity and data format.
6 If data appears correct,
sends authorization request
for the submitted amount
through credit line gateway
to CCAS.
19
INFO 620, Fall 2003, Analysis & Design Project
OTHER
SUCCESSFUL
SCENARIOS
(Specify any
successful
variations of the
normal execution
path, including
extension points
using
EXTEND
eus_name)
Step
2a.User who enters
username and
password is Registrant.
7a. Staff selects to
“pay by cash” option.
7a. Staff selects to
“pay by check” option
7c. Staff uses 7a when
processes traveler’s
check.
10a. Not all required
fields are filled in.
11a. Incorrect data
entered.
UNSUCCESSFUL Conditions
SCENARIOS
2a. Login fails less
(erroneous
than 3 times
Alsheimer, Carfagno, Podoksik
12. If authorization is
successful and charge has
been approved, display
success message and
calculate the balance.
13. If balance is zero,
return “complete” status to
calling application,
otherwise return
“incomplete” status.
Branching Action
Go to step 3, then skip to
step 6 with only “pay by
credit card” option.
Display form to enter
amount. After amount
entered, calculate the
balance. Proceed to step
13.
Display form to enter the
amount from the check,
check number, branch
routing number and bank
name. Balance is calculated
and check submitted to
accounting department.
Periodically check
accounting system if
money is transferred.
When money transferred,
proceed to step 13.
Display billing and credit
card information form again
with missing fields being
highlighted.
Display billing and credit
card information form again
with incorrectly entered
fields being highlighted.
Actions
Go to step 1.
20
INFO 620, Fall 2003, Analysis & Design Project
situations)
2b. Login fails 3 times
5a. CCAS Authorization
fails.
Priority in
scheduling
Frequency
Superordinates
Developer
Creation date
and last
modified date
Other Comments
Alsheimer, Carfagno, Podoksik
Display message “Login
Failed”
Display failure message to
subscriber and return
failure status to calling
application.
Primary
TBD
Add a paid subscription
Alex Podoksik
Created 10/27/03
21
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Cancellation – Alsheimer
USE CASE #
UC07
USE CASE Name
Process Cancellation
ACTOR
Staff
Purpose
Staff accesses CRS to process Registrant's cancellation request and
issue a refund.
Staff accesses CRS and initiates 'cancel registration' request. CRS
accesses appropriate registration record. CRS flags registration
record as 'cancelled' and decrements 'number registered' by one
for each conference offering included in registration. CRS
processes refund and auto-generates confirmation e-mail to
Registrant.
Primary
Overview and
scope
Level
Preconditions
Postconditions
Trigger
Included Use Cases
Extended Use
Cases
MAIN SUCCESSFUL
SCENARIO
CRS system is available.
Staff is logged on.
Registrant requesting cancellation has a current registration.
Correct registration record is flagged as cancelled.
'numRegistered' counter for each conference offering included in
registration is decremented by one.
Registrant receives appropriate refund.
Confirmation e-mail sent to Registrant.
Registrant submits cancellation request via phone, fax or mail.


UC08 Process Refund
UC09 Generate E-mail Confirmation
Actor Action
System Action
1. Staff initiates
cancellation request,
entering Registration ID
and request date.
2. CRS retrieves current Registrant,
Registration and Payment records,
displaying Registrant's personal
information, list of Registration
Selections, and amount paid by
Registrant.
3. Staff selects 'cancel
current registration'
option.
4. CRS prompts to confirm registration
cancellation (Are you sure you want to
cancel registration for Registrant X?).
5. Staff confirms that
registration should be
cancelled.
6. CRS sets 'registrationStatus' in
Registration record to 'Cancelled.'
22
INFO 620, Fall 2003, Analysis & Design Project
OTHER
SUCCESSFUL
SCENARIOS
Step
1a. Cancellation request
does not contain
Registration ID
Priority in
scheduling
Frequency
5a. Staff entered
registration ID for wrong
Registrant
Conditions
*a. Staff aborts process

Use case ends.
2b. No corresponding
registration record found
after 3 entry attempts
Primary

Use case fails.

Approx 1% of registrations
Superordinates
None
Other
Nonfunctional
Requirements
Developer
Olga Alsheimer
Creation date and
last modified date
Other Comments
7. For each Registration Selection (line
item) on the Registration, CRS
decrements the corresponding
Conference Offering's 'numRegistered'
and Conference Material's
'numOrdered' by one.
8. CRS processes refund. <<UC08:
Process Refund>>
9. CRS auto-generates cancellation email to Registrant
INCLUDE <<UC09: Generate E-mail
Confirmation>>
Branching Action
Staff selects 'find Registration ID'
option.
 Staff enters Registrant
membership ID or name (last,
first, middle).
 CRS searches and obtains
Registrant, Registration and
Payment records.
 CRS displays message that
registration does not exist and
prompts for new registration ID.
 Staff re-enters valid registration
ID.
 Staff responds 'no' to confirm
cancellation prompt.
 CRS repeats step 2.
Actions
2a. No corresponding
registration record
UNSUCCESSFUL
SCENARIOS
Alsheimer, Carfagno, Podoksik
Created: 11-9-2003
Last modified: 12-8-2003
23
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Refund – Alsheimer
USE CASE #
USE CASE Name
UC08
Process Refund
ACTOR
Purpose
CRS processes credit card or check refund.
Overview and
scope
For credit card refunds, total amount paid is credited to selected
credit card. CRS calls credit card authorization service (CCAS) and
obtains validation. For check refunds, total amount paid is
processed into a refund check. Refund information is stored.
Included
Level
Preconditions
Postconditions
in words
Trigger
CRS system is available.
Staff is logged on.
CCAS site is available.
Registrant has an active paid Registration.
Refund amount equal to Payment amount in Payment record.
If credit card refund, validation obtained.
If check refund, Registrant information and refund amount
transmitted to accounts payable department for check
processing.
 Refund data stored.
Staff confirms that registration should be cancelled.







Included Use Cases
Extended Use
Cases
MAIN SUCCESSFUL
SCENARIO
Actor Action
System Action
1. CRS creates Refund record,
deriving 'refundAmount' from
'pymtAmount' in Payment table.
2. CRS obtains Registrant's credit card
information (ccType, ccNumber,
ccExp) from CreditCardPayment
record.
3. CRS transmits Registrant's refund
data to CCAS.
4. CCAS validates
Registrant credit card
information and approves
refund.
OTHER
SUCCESSFUL
SCENARIOS
Step
5. CRS stores refund data (refundID,
refundAmount, refundDate,
refundMethod) in Refund table.
Branching Action
2a. Check refund

CRS skips this step.
24
INFO 620, Fall 2003, Analysis & Design Project
3a. Check refund
Alsheimer, Carfagno, Podoksik


UNSUCCESSFUL
SCENARIOS
Priority in
scheduling
Frequency
CRS obtains Registrant's personal
information (name, phone,
address).
CRS transmits Registrant
information and refund amount
and date to accounts payable for
check processing.
CRS skips this step.
4a. Check refund

Conditions
Actions
4b. Credit card
authorization fails
Primary
CCAS returns failure message to CRS
and use case terminates.
Approx. 1% of registrations
Superordinates
UC07: Process Cancellation Request
Other
Nonfunctional
Requirements
Developer
Olga Alsheimer
Creation date and
last modified date
Other Comments
Created: 11-11-2003
Last modified: 11-28-2003
25
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Generate E-mail Confirmation – Alsheimer
USE CASE #
USE CASE Name
UC09
Generate E-mail Confirmation
ACTOR
Purpose
Overview and
scope
Level
Preconditions
Postconditions
in words
Trigger
CRS generates and sends a confirmation e-mail for a Registration
or Cancellation.
CRS creates and fills in e-mail template. For registrations, CRS fills
in registration data (registrationID, registrant personal
information, list of registration selections, special meal requests,
and payment data). For cancellations, CRS fills in cancellation data
(registrationID, registrant personal information, list of cancelled
registration selections, and refund data). Email data is stored.
Included
CRS system is available.
Staff is logged on.
E-mail template is available.
Registration or Cancellation has successfully processed.
E-mail containing subject (confirmation or cancellation),
registrant personal information, and registration/payment or
cancellation/refund data is transmitted to Registrant
 E-mail data stored.
Registration or Cancellation successfully processed.





Included Use Cases
Extended Use
Cases
MAIN SUCCESSFUL
SCENARIO
OTHER
SUCCESSFUL
SCENARIOS
Actor Action
System Action
1. CRS creates an instance of Email
Template with the subject
"Registration Confirmation."
2. CRS fills in Registrant's
emailAddress.
3. CRS fills in Registrant's personal
information (name, phone, fax,
company, title, status, membership
ID, username, password).
4. CRS fills in Registration information
(list of registration selections with qty,
meal requests, early or late, payment
data).
5. CRS transmits e-mail.
Step
6. CRS stores Email Template data
(description, sentDate, subject,
emailAddress) and updates
Registration record with confEmailSent
=Y and sentDate.
Branching Action
1a. Cancellation

CRS fills in subject "Cancellation
Confirmation."
26
INFO 620, Fall 2003, Analysis & Design Project
4a. Cancellation
Conditions
CRS fills in Cancellation
information (list of cancelled
selections with qty, refund data).
 CRS updates Cancellation record
with confEmailSent =Y and
sentDate.
Actions
5a. E-mail bounces back

6a. Cancellation
UNSUCCESSFUL
SCENARIOS
Alsheimer, Carfagno, Podoksik


CRS returns failure message to
Staff
Staff sends out a letter of
confirmation to Registrant
Priority in
scheduling
Frequency
Primary
Superordinates
UC03: Process Conference Registration
UC07: Process Cancellation Request
Other
Nonfunctional
Requirements
Developer
Creation date and
last modified date
Other Comments
100% of registrations
Olga Alsheimer
Created: 11-28-2003
27
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Systems Analysis - Validation & Discussion
The use case model we developed adheres to the main idea of use case
development: it describes what system does but it does not specify how it
does it. The main decision about use case diagram was to identify
appropriate level of detail, so it would allow correctly identify classes and
operations. The other problem was to place reasonable boundaries to the
system (another word to identify “scope” of the system).
As it was stated in our problem statement, primarily the system should be
able to maintain conference offerings and activities, be able to present them
to registrant. System should allow registrant to register through online
registration interface, allow participant to modify personal and registration
information. System should also allow staff to perform the above operations
on behalf of participant. Furthermore, system should be able to present,
store and process financial information. System should also be able to
channel marketing information to conference sponsors.
Our initial desire was to list all possible activities performed by main actors
during at the conference in our use case diagram. First step in developing
use case diagram was to identify main actors. Our initial list consisted of:
registrant, staff, and sponsor/speaker and site manager. For exception of
site manager, which we later dropped by scaling down the scope of the
system, our list of main actors remained the same. By placing different
activities against each of the actor, we developed first iteration of our use
case diagram.
Actor
Activities
Sponsor/Speaker manage staff,
manage finances,
manage conference offerings (<<include>> monitor seat
availability), present marketing data
Registrant
collect marketing data,
maintain personal info,
process conference registration (<<include>> get
confirmation email, process payment, calculate total fee,
compile custom registrations) (<<extend>> request event
ticket, request special accommodation)
Staff
all Registrant activities,
maintain conference badges, generate special event tickets,
process payment, process cancellation (<<include>>
process refund)
By analyzing our use case diagram, we realized few things: our diagram is
not complete without a business actor such as credit card authorization
service/financial institution; and our diagram appeared too granular. At this
level of granularity, any of the activities that were not captured, needed to
28
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
be added later. This means we would not be able to finalize our design.
Therefore, the next version of use case diagram is a rebuild of the first
version from a higher view. In this version we collapsed granular activities
into generalized use cases that would list just abstracted actions of the
actors.
Actor
Activities
Sponsor/Speaker provide conference offerings
Registrant
select offerings and activities,
maintain personal info,
register for conference and accommodations(<<include>>
schedule activities (<<include>> issue confirmation)),
pay for conference (process payment (<<include>> issue
confirmation))
Staff
all Registrant activities,
process cancellation (<<include>> generate refund)
By analyzing this diagram, we came to the conclusion that we were making
one crucial mistake. We were creating actions that actor does with the
system but not what system does for actor. Finally, we have developed our
last version of the use case diagram that seemed to serve the purpose of the
system under development.
Actor
Activities of the System
Sponsor/Speaker collect marketing data
Registrant
process conference registration
((<<include>> collect marketing data, process payment,
issue confirmation) (<<extend>> request event tickets))
Staff
all Registrant activities,
process cancellation (<<include>> process refund)
process payment,
generate conference reports,
check registration status,
maintain conference offerings
Listed below are our use cases with brief explanation.
Use Case Name
Collect
Marketing Data
Actor
Sponsor
Purpose
Allow sponsors and
speakers to submit
marketing data to
the system
Overview
System should be able to
collect conference
offerings submitted by
sponsors, such as
tutorials, workshops,
technical programs,
expositions.
29
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Maintain
Conference
Offerings
Staff
Allow staff to add
and modify
conference
offerings.
Process
Conference
Registration
Registrant,
Staff
Allow registrant or
staff on behalf of
registrant to
register for
conference,
schedule activities
and reserve seats.
Request Event
Tickets
System
Allow participant to
get tickets to the
events outside of
conference location.
Issue
Confirmation
Registrant,
Staff,
System
Generate
Conference
Reports
Staff
Process
Payment
Registrant,
Staff,
System
CCAS/Bank
Participant receives
confirmation by
email about
conference
registration or
cancellation
Staff prints out
specialized reports
about conference
statistics to support
seat and session
availability and
participation.
Participant is
capable of paying
for conference by
credit card online,
or by paying to staff
member by cash or
check.
System should be able to
provide means to add,
delete and update
offerings for the
conference.
System should be able to
enable registrant to submit
his personal and billing
information, order
activities, get fees
calculated, get registration
number and provide a
channel for payment by
credit card.
System should
accommodate participant
in booking special events
outside the conference
location.
System generates an
email, sends it to
registrant triggered by
successful conference
registration or
cancellation.
System capable of
generating specialized
reports with calculated
statistics about conference
participation, registration
information and seat
availability.
System should be able to
store payment data,
calculate balance, and
display resulting balance
to participant or Staff.
System should be able
automatically process
credit card payment online
using CCAS, and report on
check payment through
the accounting system.
30
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process
Cancellation
Staff
Staff is capable of
canceling
participant’s
registration at
registrant’s request.
Process Refund
System
System generates
refund to registrant
after conference
cancellation was
successful.
Check
Registration
Status
Staff
Staff is able to see
whether the author
of each paper has
registered for
conference.
System should update
registrant’s record;
deactivate registrant’s
participation on the
conference. System must
trigger email generation to
registrant on successful
cancellation.
System should be able to
calculate refund according
to conference refund policy
and generate refund
payment and invocate
check mailing to registrant
through accounting
department.
System returns status
based on the data stored
about registrants. System
is capable of analyzing
who of registrants is an
author of the paper and
whether his record exists
as an active registrant.
31
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Systems Design
System Sequence Diagrams
Process Registration SSD - Podoksik
32
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Payment SSD – Podoksik
33
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Cancellation SSD – Alsheimer
: CRS
: Staff
1. initiateCancellation(registrationID)
2. displayRegistrationData(registrant, registration, and payment data)
3. confirmCancellation()
4. sendConfirmation(cancellation and refund data)
34
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Sequence Diagrams
Collect Marketing Data SQD - Carfagno
10-step Heuristic – Collect Marketing Data – Carfagno
#
Step
Include
1.
2.
3.
4.
5.
Actor
Primary Boundary Object
Use-case Controller
Secondary Control Object(s)
Secondary Boundary
Object(s)
Domain Classes
Block Labels
MarketingHandler
none
6.
7.
8.
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
9.
10.
Message Obvious
Parameters
Problem-Solving Operations
Instance Creation
Association Forming
Attribute Modification
Calculation
Change Status
Display/Reporting
Collect marketing data
Marketinghandler, collect
marketing data, sponsor
Displayform()
none
Updatestatistics
get customer_info
Get future_requests
Interface
Processfuture_info
Rearrange the sequence
none
Updatestatistic(registrants name,phone number, address,email
address)
Updatefuture_requests(registrationStatus
35
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Collect Marketing Data SQD – Carfagno
: MarketingHandler
: Collect marketing data
: Sponsor
display form( )
get customer_info( )
get future_requests( )
updatestatics( )
36
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Maintain Conference Offerings SSD – Carfagno
:CRS
: Staff
lists yearly conferences
display (conferences offered)
add fees for activities
displays fees( )
add refund policies
displays refund policies( )
add cancellation procedures
display cancellation procedures( )
add contact info
display contact info
display type of members, conferences, and fee
37
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
10-step Heuristic – Maintain Conference Offering – Carfagno
#
Step
Primary
1.
2.
3.
4.
5.
6.
7.
Actor
Primary Boundary Object
Use-case Controller
Secondary Control Object(s)
Secondary Boundary Object(s)
Domain Classes
Block Labels
Staff
Conference Screen
Conference Controller
none
none
Maintain Conference Offering
Conference Screen, Conference Controller, Maintain
Conference Offering
8.
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
9.
10.
Instance Creation
Association Forming
Calculation
Change Status
Display/Reporting
Interface
Rearrange the sequence
Message Obvious Parameters
Conference Screen
none
none
Updateconferences_offfered
Displayconference_offered
Display fees
Displayrefund_policies
Displaycancellation_policies
Displaycontact_info
Maintain Conference Offerings
none
38
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Maintain Conference Offering SQD – Carfagno
: Staff
: Conference Screen
: Conference controller
: Maintain conference
Offering
enters conference list
inputs conference( )
sorts conferences( )
display conferences( )
enters fees
inputs fees( )
sorts fees( )
display fees( )
enter refund policy( )
iputs refund( )
sorts refunds( )
display refunds( )
enter cancellation policy( )
inputs cancellation policy( )
sorts cancellation policy( )
return cancellation policy( )
enter contact info( )
inputs contacts( )
sorts contact info( )
display contact info( )
39
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Registration SQD - Podoksik
40
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Registration SQD (continued)
41
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Registration SQD (continued)
42
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Payment SQD – Podoksik
43
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Payment SQD (continued)
44
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Cancellation SQD – Alsheimer
: Staff
: CancellationWindow
: CancellationController
: Cancellation
: Registrant
: Address
: Registration
: RegistrationSelection
: Payment
: RefundHandler
: Refund
: EmailHandler
1. initiateCancellationRequest(registrationID)
2. create(registrationID)
3. create(cancellationID)
4. getRegistrant()
5. getAddress()
6. * getRegistrationSelection()
7. getPymtAmount()
8. returnRegistrationData(registrant data, registration selections, pymtAmount)
9. displayRegistrationData(registrant data, registration selections, pymtAmount)
10. enterCancellation(requestDate, cancelMethod, reasonCode)
11. display ConfirmationRequest()
12. confirmCancellation(Y)
13.passCancellation(requestDate, cancelMethod, reasonCode)
[confirm = 'Y']
14. setCancellationParameters(requestDate, processDate, cancelMethod, reasonCode)
45
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Cancellation SQD (continued)
: Staff
: CancellationWindow
: CancellationController
: Cancellation
: Registrant
: Address
: Registration
: RegistrationSelection
: Payment
: RefundHandler
: Refund
: EmailHandler
15. updateRegistrationStatus(cancelled)
16. * decrementconfOfferingNumRegistered(-1)
17. *decrementconfMaterialNumOrdered(-1)
18. getPaymentData()
19. process Refund(pymtAmount, ccType, ccNumber, ccExp)
20. getRefundData()
21. generateCancellationEmail(registrant data, registration selections, refund data)
46
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Process Refund SQD – Alsheimer
: RefundHandler
: Refund
: CCAS
1. create(refundID, refundMethod)
2. authorizeRefund(pymtAmount, ccType, ccNumber, ccExp)
3. updateRefund(refundAmount, refundDate)
[status=authorized]
4. returnErrorMsg
[status=unauthorized]
47
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Generate E-mail Confirmation SQD - Alsheimer
: EmailHandler
: EmailTemplate
: EmailSystem
: Registration
1. create(registrant data, registration data, refund data)
2. addEmailAddress()
3. addRegistrantInfo(name, phone, fax, company, title, status, membershipID)
4. * listRegistrationSelection(description, qty)
5. addRefundData(refundDate, refundMethod, refundAmount)
6. transmitEmail()
7. storeEmailTemplate(description, sentDate, subject, emailAddress)
8. updateRegistration(confEmailSent, emailSentDate)
48
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
State Diagram – Registration
STATE DIAGRAM REGISTRATION
Selected
Cancelled
Accepted
Registered
Cancelled
cancelled
Payment processed
Paid
payment denied
Declined
not paid in full
Paid in full
Partially
Paid
Fully Paid
fully paid
49
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Design Class Diagram
50
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Systems Design – Validation & Discussion
The center of the CRS system design is the REGISTRATION class. A
registration is composed of one or more REGISTRATION SELECTIONs, as
a conference attendee may elect to participate in numerous conference
activities. Registration selections include CONFERENCE OFFERINGS such
as TUTORIALS and WORKSHOPS, as well as SPECIAL EVENTS (e.g.,
banquets and tours). A Registration selection may also consist of extra
copies of CONFERENCE MATERIAL, such as PROCEEDINGS, WORKSHOP
NOTES or TUTORIAL NOTES.
A REGISTRANT may have one or more registrations for a given
conference. Registrations may be incomplete, active or cancelled.
Thus, the system allows a registrant to register for one or more
activities, cancel activities, register for additional activities, and pay
separately for these various registrations. A given registration may,
therefore, have one or more PAYMENTS. A payment may be via cash,
traveler's check, personal CHECK or CREDIT CARD. We chose not to
include cash in our model, since there are no interesting properties to
track. Similarly, traveler's checks were modeled as a type of check
(attribute checkType). Overall, the model is flexible enough so that
multiple registrations (incomplete, active or cancelled), payments and
cancellations may be tracked for each registrant.
Each registration may have zero or one CANCELLATIONS. The model
allows for tracking of cancellation request date, processing date,
reason, and method (i.e., written, phone). A cancellation may or may
not have an associated REFUND. For example, if an incomplete
registration (payment not yet made) was cancelled, there would be no
associated refund.
Early versions of our design included classes related to conference
sessions, technical programs and expositions. We subsequently
removed these classes, because they are beyond the scope of CRS.
Since anyone who registers for a conference may attend these sort of
sessions, we did not feel it necessary to track them. They seemed
more important for purposes of monitoring capacity and physical
space, which were not considered part of the CRS design.
In the initial model, we also used a generalization hierarchy wherein all
conference offerings (tutorial, workshop, special event and conference
material) were deemed subclasses of conference offering. We later
revised the model to separate special events and conference material
as their own unique classes. We made this decision partly because
51
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
these latter classes do not need the inherited attributes related to
conference offering fees (i.e., member, nonmember, student, early,
late). As a rule, special events and proceedings are offered at the
same cost to everyone regardless of membership or time of
registration. The other reason for this decision is that these seem
logically different from regular conference events such as tutorials and
workshops.
In the final version of the system design, we also added classes to
track AUTHOR registrations and their associated PAPER presentations.
One author may present multiple papers, and a paper may have
multiple authors. We realized that these classes are important because
conference staff may want to check that each paper has a registered
author (i.e., even authors must not forget to register for the
conference!).
52
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Evaluation of Analysis and Design
This was a very successful design effort. The domain, a conference
registration system, is an important problem and is familiar to us as
students and professionals. In terms of scope, this domain was a
reasonable size for a 10-week analysis and design project.
As a group, we are pleased with the UML models we developed: use
case diagram, use case descriptions (3 primary, 4 included), analysis
class diagram, 4 system sequence diagrams, 7 sequence diagrams, a
design class diagram and a state diagram. We feel these models
accurately depict our intention, address the problem statement, and
could be given to a programmer to start writing code. The models, as
designed, meet all the goals and functionality of the system as
described in the problem statement.
We were also satisfied with the tools we used as a group: our primary
software for developing diagrams and graphs was Rational Rose
Modeling Edition, version 2001.03.01. Text was created with
Microsoft Word 2002. Microsoft Project Professional 2002 was used
to maintain the group's work plan. Most communication was via e-mail
and in class.
53
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Summary and Lessons Learned
This analysis and design project was challenging from inception
through many design iterations. As a group, we learned to create a
problem statement with a reasonable scope. The domain, conference
registration system, lent itself nicely to a moderate-sized design
project.
The iterative development of the use case model was also a useful
exercise, in which we learned the importance of refining granularity!
We also learned a good deal from the iterative and circular nature of
refining use case descriptions, class diagram, interaction diagrams. As
we developed our interaction diagrams, we were able to see the holes
and inconsistencies in our use case descriptions and class diagram.
Changes to the class diagram also needed to be reflected in the use
case description and interaction diagrams. After repeated interations,
we arrived at a satisfactory model. In this respect, the project was an
excellent representation of an actual design process that we may
encounter in the real world.
54
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
References
12th International Conference on Information and Knowledge
Management (CIKM '03) Conference Registration. Conference on
Information and Knowledge Management: (Online), Available:
http://www.cikmreg.org/.
Cockburn, A. (2001). Writing Effective Use Cases. Boston: AddisonWesley.
XML Conference & Exposition 2003 Conference Registration.
International Digital Enterprise Alliance: (Online), Available:
http://www.xmlconference.org/xmlusa/2003/registration.asp.
The Unified Modeling Language User Guide
by Grady Booch ,James Rumbaugh , Ivar Jacobson
Addison-Wesley Pub Co (1998)
55
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Appendices
Individual Experience & Lessons - Alsheimer
I found this project challenging, but rewarding, from inception through
design. In terms of individual contributions, I created a draft PROJECT
PROPOSAL (problem statement, knowledge acquisition,
software/hardware specifications, deliverables) for group discussion
and review. I then worked with the group to refine and assimilate our
varied proposals. In the initial analysis phase, I developed a USE CASE
MODEL and facilitated team review of alternate models, ultimately
incorporating the best of each into one model. After your review of the
group's use case model, I took the lead on refining the model through
several iterations.
For the ANALYSIS CLASS DIAGRAM, I applied the Taxonomic Class
Modeling (TCM) Methodology (see Appendix) to the problem
statement, identifying noun, discovered and transformed classes. I
created a proposed analysis class diagram, which was ultimately
selected by the group for submission. I also created a USE CASE
DESCRIPTION for 'Process Cancellation' and its <<include>> use cases,
'Process Refund' and 'Generate E-mail Confirmation.' After your
review, I again took the lead on refining the class diagram until the
group was satisfied with the design.
In the system design phase, I developed a SYSTEM SEQUENCE DIAGRAM
(SSD) and a SEQUENCE DIAGRAM (SQD) for the use case 'Process
Cancellation.' I also developed SQD's for the <<include>> use cases
'Process Refund' and 'Generate Email Confirmation,' following the 10step Heuristic on SQD Development (see Appendix).
Using operations identified in these interaction diagrams, I created a
first draft of a DESIGN CLASS DIAGRAM for team review. I worked on
several iterations of the design class diagram, adding operations and
refining layout. I also wrote the VALIDATION AND DISCUSSION for the
systems design portion of the documentation.
Finally, I created the final term PROJECT DOCUMENTATION, with table of
contents and INTRODUCTION SECTION for the group's convenience. I
also wrote the first drafts of the EVALUATION OF ANALYSIS AND DESIGN
and SUMMARY AND LESSONS LEARNED for the group's review and editing.
I then circulated the complete set of documentation and diagrams so
the team members could add their individual contributions.
56
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
In terms of lessons learned, I learned a lot from the entire analysis
and design process. I had previous experience with business modeling
using UML, but find system analysis and design much more
challenging! This project was my first exposure to object-oriented
systems; I have never programmed in OO. Until this project, I did not
know the meaning of class, object, responsibility/operation/method,
polymorphism, inheritance or encapsulation. The learning curve was
steep!
I found it very stimulating to tackle a systems analysis and design
project from inception to design. It is no trivial matter to write a
problem statement and make decisions regarding project scope. Even
deciding upon the appropriate granularity for the use case model can
be difficult. Most likely due to practice with TCM, I thought the analysis
class diagram was relatively straightforward, although I am still a bit
fuzzy on the associations between classes. For example, why is it
better that Author has an association with Registrant rather than an
'isa' relationship? I hope to have the opportunity to more fully
understand the links between classes, in the same way I now
understand the relationships between entities in an ERD.
Of all the models, I found interaction diagrams the most difficult. This
is interesting, because these diagrams are not difficult in business
modeling. With business models where many actors are collaborating
with business entities (e.g., databases, systems), it is very clear who
sends which message to whom. I found working with the multi-layered
architecture (external actor -> boundary class -> control class ->
entity class) a bit more confusing. I think this will become clearer with
experience. I also believe this was a valuable exposure, since I work in
a software development environment, albeit in a testing/project
management capacity.
57
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Individual Experience & Lessons – Carfagno
I have learned many lessons throughout this project of designing
and analyzing this problem domain. Working with a talented team was
an excellent way to see how others analyze and a design a the same
problem domain. It allows me to look at thing in many different ways.
This is my first experience with object-oriented systems and it was a
challenging, but knowledgeable experience. Beginning with creating
the problem statement and continuing through with the rest of the
project design was very educational. This helped me to see what how
the problem statement and scope were so important to the systems
analysis and design of the project. The Taxonomic Class Methodology
was very helpful in creating class diagram and the examples were very
useful in view to our problem domain. Discovering domain class
without this methodology would have been quite challenging. Creating
interactive diagrams became a little more confusion to me. The tenstep heuristic method for developing sequence diagrams helped me
understand it much clearer, but I will definitely need to practice and
will become better with experience. This knowledge will allow me to be
able to take on a diverse projects which will help me to move forward
in my career.
58
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Individual Experience & Lessons – Podoksik
I have grouped and formulized my previous understanding about
how to design and analyze the problem domain. Working with a
talented team was an excellent way to see how others analyze and a
design a the same problem domain. It allows me to look at thing in
many different ways. Even it is not my first experience with objectoriented systems; still it was a challenging, but beneficial experience.
Beginning with creating the problem statement and use case diagram
and following through with the rest of the project design was very time
consuming but also very rewarding. This helped me to organize and
scope the significant amount of the sparse knowledge I had about
systems analysis and design of the project. The Taxonomic Class
Methodology was very helpful in creating class diagram and the
examples were very useful in view to our problem domain. Ten step
heuristics for sequence diagrams were really good methodology for
building interaction domain. The most important part for me was
realizing interaction diagram technology. A lot of practice will definitely
bring needed skills for becoming a good system architect. This
knowledge will allow me to be able to take on diverse projects which
will help me to move forward in my career.
59
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Taxonomic Class Modeling Methodology
Noun Classes
N1:
Nouns
N2:
Class Elimination Rules
N3:
Class Categories
Conference
Registration System
CRS
Organization
Conference Session
Tutorial
Workshop
System
Sponsor Organization
Registration
Needs
Technical Program
Exposition
Subset
Activities
Combination
Registrant
Attendance
Reception
Lunch
Banquet
Special Event
Sightseeing Tour
Information
Name
Mailing Address
Phone Number
E-mail
Company Affiliation
Job Function
Status
Membership ID
Menu
Payment
Marketing data
Mailing lists
Registration date
Registration fee
Refund
Policies
Cancellation
Procedures
Instructions
Contact information
Questions
Request
CER1; adopt CRS
-
<<singleton>>
CER3 - vague
PSN; adopt "Conference Offering"
PSN
PSN
CER1 - adopt CRS; CER6 – meta
CER2 – beyond scope
PSN
CER3 – vague; CER6 - meta
PSN
PSN
CER3 – vague
CER3 – vague; CER6 – meta
CER3 – vague
PSN
CER3 - vague
CER8 – value (type of Event)
CER8 – value (type of Event)
CER8 – value (type of Event)
PSN
CER8 – value (type of Event)
CER6 - meta
CER7 - attribute
CER7 - attribute
CER7 – attribute
CER7 – attribute
CER7 – attribute
CER7 - attribute
CER7 - attribute
CER7 – attribute
CER6 - meta
PSN
CER6 - meta
CER6 – meta
CER7 - attribute
CER7 – attribute; adopt totalPrice
PSN
CER3 – vague; CER6 – meta
PSN
CER3 – vague
CER3 - vague
CER9 - derived
CER3 - vague
CER1 – redundant; adopt
Registration & Cancellation
CER8 – values (requestMethod)
CER8 – values (requestMethod)
CER8 – values (requestMethod)
CC4
CC7
CC7
CC7
CC5
CC7
CC7
CC1
CC7
CC5
CC5
CC5
-
Y
Y
Y
Y
-
-
-
Mail
Phone
Fax
Keep as a
Class?
-
Y
Y
Y
Y
Y
Y
-
60
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
Staff
Types
Member
Nonmember
Student
Quick calculator
Price
PSN
CER3 – vague
CER8 – values (status)
CER8 – values (status)
CER8 – values (status)
CER5 – implementation construct
CER7 – attribute (see Registration
fee/Conference fee)
CER2 – beyond scope
PSN
CER8 - value
CER6 - meta
CER3 – vague; CER6 - meta
CER7 - attribute
CER2 – irrelevant; nothing
interesting to track
CER2 – irrelevant; CER8 – value;
(i.e., value of checkType)
PSN
PSN
CER6 – meta; CER9 - derived
CER7 – attribute; adopt spaceLimit
CER3 - vague
CER9 - derived
CER6 – meta
CER6 – meta
CER6 - meta
CER8 – values (requestMethod)
CER6 - meta
CER1 – redundant; adopt Registrant
PSN
CER3 – vague
PSN
CER1 – redundant; adopt Staff
CER2 - irrelevant
CER2 – beyond scope
CER2 – beyond scope
CC1
-
Y
-
CC2
-
Y
-
-
-
CC5, CC13
CC5, CC13
CC4, CC11
CC3
-
Y
Y
Y
Y
-
CER2
CER2
CER2
CER3
CER2
-
-
Ticket
Proceedings
Total fee
Components
Times
Form of payment
Cash
Traveler's check
Check
Credit Card
Record
Seat availability
Number
Attendee list
Billing
Purchasing
Financial reporting
Web
Modes
Attendee
Conference material
Distribution
Tutorial Notes
Personnel
Workstations
Conference site
Conference
management system
Papers
Speakers
Hall assignments
Integration
Conference website
–
–
–
–
–
beyond scope
beyond scope
beyond scope
vague; CER6 - meta
beyond scope
Transformed Classes - none
Discovered Classes
CC1 People: none
CC2 Places: none
CC3 Physical Things: Workshop Notes
CC4 Organizations: none
CC5 Events/Transactions: none
CC6 Transaction Line Items: Registration Line Item
CC7 Concepts/Intangibles: none
CC8 Specification: none
61
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
CC9 Interaction: none
CC10 Rules/Policies: none
CC11 Containers: none
CC12 Contained: none
CC13 Financial: none
CC14 Lookup/Reference: none
62
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
SQD 10-step Heuristics
10-step Heuristic – Process Cancellation SQD - Alsheimer
#
Step
Include
1.
2.
3.
4.
Actor
Primary Boundary Object
Use-case Controller
Secondary Control Object(s)
5.
Secondary Boundary Object(s)
6.
Domain Classes
7.
Block Labels
Staff
CancellationWindow
CancellationController
RefundHandler
EmailHandler
no separate screens needed for refund or e-mail
confirmation
Registrant, Address, Registration,
RegistrationSelection, Payment, Cancellation,
Refund
CancellationWindow, CancellationController,
Registrant, Address, Registration,
RegistrationSelection, Payment, Cancellation,
Refund, RefundHandler, EmailHandler
8.
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
9.
10.
Problem-Solving Operations
Instance Creation
Association Forming
Attribute Modification
Calculation
Change Status
Display/Reporting
Interface
Rearrange the sequence
Message Obvious Parameters
CancellationController, Cancellation, Refund
Cancellation-to-Registration
Refund-to-Cancellation
none
updateRegistrationStatus()
* decrementconfOfferingNumRegistered()
* decrementconfMaterialNumOrdered()
getRegistrant()
getAddress()
*getRegistrationSelection()
getPymtAmount()
displayRegistrationData()
displayConfirmationRequest()
getPaymentData()
getRefundData()
processRefund()
none
displayRegistrationData(registrant data,
registration selections, pymtAmount)
updateRegistrationStatus(cancelled)
processRefund(pymtAmount, ccType,
ccNumber, ccExp)
* = iterate until done
63
INFO 620, Fall 2003, Analysis & Design Project
Alsheimer, Carfagno, Podoksik
10-step Heuristic – Process Refund SQD - Alsheimer
#
Step
Include
1.
2.
3.
4.
5.
6.
7.
8.
Actor
Primary Boundary Object
Use-case Controller
Secondary Control Object(s)
Secondary Boundary Object(s)
Domain Classes
Block Labels
Problem-Solving Operations
Instance Creation
Association Forming
Attribute Modification
Calculation
Change Status
Display/Reporting
Interface
Rearrange the sequence
Message Obvious Parameters
---RefundHandler
none
Refund
RefundHandler, Refund, CCAS
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
9.
10.
createRefund()
none
none
updateRefund
none
authorizeRefund()
none
authorizeRefund(pymtAmount, ccType,
ccNumber, ccExp)
updateRefund(refundAmount, refundDate)
10-step Heuristic – Generate E-mail Confirmation SQD Alsheimer
#
Step
Include
1.
2.
3.
4.
5.
6.
7.
Actor
Primary Boundary Object
Use-case Controller
Secondary Control Object(s)
Secondary Boundary Object(s)
Domain Classes
Block Labels
---EmailHandler
EmailSystem
EmailTemplate, Registration
EmailHandler, EmailTemplate, EmailSystem,
Registration
8.
8.1
8.2
8.3
8.3.1
8.3.2
8.3.3
8.3.4
9.
10.
Problem-Solving Operations
Instance Creation
Association Forming
Attribute Modification
Calculation
Change Status
Display/Reporting
Interface
Rearrange the sequence
Message Obvious Parameters
EmailTemplate
none
none
storeEmailTemplate()
updateRegistration()
addEmailAddress()
addRegistrantInfo()
* listRegistrationSelection()
addRefundData()
transmitEmail()
none
* listRegistrationSelection(description, qty)
updateRegistration(confEmailSent,
emailSentDate)
* = iterate until done
64