Conference Registration System - Drexel University ...je58/docs/info620.docx · Web viewThe...

Conference Registration System

December 8

2010This 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 | P a g e

ContentsIntroduction.............................................................................................................................................................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.............................................................................................................................................12

Use Case Diagram...............................................................................................................................................15

Analysis Class Diagram.......................................................................................................................................16

Design Class Diagram..........................................................................................................................................17

System Analysis – Validation & Discussion.........................................................................................................18

System Design........................................................................................................................................................19

System Sequence Diagram.................................................................................................................................19

Sequence Diagram (Add Account)......................................................................................................................20

Sequence Diagram (Add Event to Cart)..............................................................................................................21

Sequence Diagram (Pay for Ticket).....................................................................................................................22

State Diagram.....................................................................................................................................................23

System Design – Validation & Discussion...........................................................................................................24

Physical Design...............................................................................................................................................25

Entity-Relationship Diagram...............................................................................................................................25

Deployment Diagram.........................................................................................................................................26

Physical Design – Validation & Discussion..........................................................................................................26

Applications Design...............................................................................................................................................28

Screenflow Diagram...........................................................................................................................................28

Applications Design – Validation & Discussion...................................................................................................29

Evaluation of Analysis & Design............................................................................................................................29

Project................................................................................................................................................................29

3 | P a g e

Domain...............................................................................................................................................................29

UML....................................................................................................................................................................29

Modeling Tools...................................................................................................................................................30

Appendix................................................................................................................................................................30

Division of Work.................................................................................................................................................30

Lessons Learned – John......................................................................................................................................31

Lessons Learned – Joe........................................................................................................................................31

Lessons Learned – Rob.......................................................................................................................................31

References.............................................................................................................................................................31

4 | P a g e

IntroductionThe 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 StatementThe 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 & ImportanceThe 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

5 | P a g e

(check, credit, cash [on-site only], or traveler’s check). The system will also allow the attendee to add or modify 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 ScopeThe 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. Conference ID1.2. Name1.3. Description1.4. Date(s)1.5. Time(s)1.6. 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 Session2.1.1.Paper Title2.1.2.Speaker(s)2.1.3.Capacity2.1.4.Currently registered2.1.5.Discount cutoff date

2.2. Tutorial Session

6 | P a g e

2.2.1.Title2.2.2.Instructor(s)2.2.3.Minimum required registrants to have session2.2.4.Capacity2.2.5.Currently registered2.2.6.Fee2.2.7.Discount cutoff date

2.3. Workshop session2.3.1.Title2.3.2.Instructor(s)2.3.3.Minimum required registrants to have session2.3.4.Capacity2.3.5.Currently registered2.3.6.Fee2.3.7.Discount cutoff date

2.4. Banquet2.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.Name3.1.2.Title3.1.3.Company/Association3.1.4.Phone Number3.1.5.Student Status3.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 registration3.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 tickets3.2.5.Additional conference proceedings

3.3. Fee schedule3.3.1.Fees will be tabulated based on attendee (regular/student) and date of registration (before/after

discount date).

7 | P a g e

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 Title3.6.2.Date(s)3.6.3.Location3.6.4.Attendee’s name3.6.5.Attendee’s title/affiliation3.6.6.Attendee’s address3.6.7.Amount paid (itemized)

Assumptions1. 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 CasesUse Case Name

Evaluate Tutorial Attendance

Actor SystemPurpose The system will check to see if tutorial attendance is high enough.Overview 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.

Use Case Name

Cancel Tutorial

Actor System

8 | P a g e

Purpose If a tutorial does not meet attendance requirements, the system will cancel the tutorial.

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

Use Case Name

Refund Money

Actor System, AttendeePurpose An attendee’s money will be refunded to them in the event that their tutorial is

canceled.Overview 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).

Use Case Name

Apply Discount

Actor SystemPurpose The system will automatically apply discounts to the customer’s purchase

before they pay.Overview 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.

Use Case Name

Send Receipt

Actor System, Attendee, Conference StaffPurpose Regardless of how the attendee pays, they will receive a receipt in some form

after they complete their purchase.Overview 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.

Use Case Issue Badge

9 | P a g e

NameActor Attendee, Conference StaffPurpose The attendee will show their receipt at the front desk of the conference center

and receive a badge.Overview 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

Pay for Ticket

Actor AttendeePurpose Interaction for attendee to submit paymentOverview Attendee submits payment and receives confirmation of receipt.

Use Case Name

Handle Payment

Actor System, Conference Staff (if payment in person or by phone/mail)Purpose Validate and account for payment. Update registration informationOverview 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.

Use Case Name

Register an Account

Actor Attendee, Conference Staff (if payment in person or by phone/mail)Purpose If attendee does not already have an account, create an account.Overview 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.

Use Case Name

Add Item to Cart

Actor Attendee, Conference Staff (if payment in person or by phone/mail)Purpose Allows attendee to select registration optionsOverview Attendee selects registration options – workshops, tutorials, extra proceedings,

etc. and when finished, proceeds to checkout cart.

10 | P a g e

Use Case Name

Verify Student Status

Actor Attendee, Conference Staff (if payment in person or by phone/mail)Purpose Allows attendee to register at student discount ratesOverview 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.

Use Case Name

Check for Scheduling Conflicts

Actor SystemPurpose Prevents attendees from inadvertently signing up for two or more events

occurring at the same time.Overview 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.

Use Case Name

Add Event/Extra

Actor AdministratorPurpose Allows the administrator to add new conferences, tutorials, or workshops to the

system, as well as extra items, such as additional pamphlets. Overview 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.

Use Case Name

Modify Event/Extra

Actor AdministratorPurpose Allows the administrator to modify conferences, tutorials, workshops in the

system, as well as extra items, such as additional pamphlets.Overview 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.

Use Case Name

Delete Event/Extra

Actor AdministratorPurpose Allows the administrator to delete conferences, tutorials, or workshops in the

system, as well as extra items, such as additional pamphlets.Overview When the administrator of the program must delete events (conferences,

tutorials, and workshops) or extras in the system, they will be able to directly

11 | P a g e

delete these events or extras, which will immediately display in the system.

Detailed Use CasesUSE 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 1. Attendee has a user account.2. Attendee has events/extras in his cart.3. Attendee is paying online.

Postconditions in words 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:

Reference “included use cases” in this section using INCLUDE ius_name

Actor Action 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 usingEXTEND eus_name)

Step Branching Action

None

EXCEPTIONS (erroneous situations)

Conditions Actions

2a. Form validation fails (blank or invalid entry);

Report error message to attendee and instruct to correct and resubmit.

5a. Credit card validation fails Ask to pay by another card or abort

Priority in scheduling First

Frequency Once per user

Superordinates None

Developer John Ehring

Creation date and last modified date

Created: 04 November 2010Modified: 16 November 2010

Other Comments None

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 Accounts are used to track cart items and registration information. If the attendee does not have an account, create an account containing contact information.

Level Primary

Preconditions Attendee does not have an account

Postconditions in words Attendee has an account

Trigger Use case triggered by attendee (or staff member for an attendee) starting the registration process.

Included Use Cases None





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.



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);

Report error message to attendee and instruct to correct and resubmit.

2a. Requested account name already exists

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


Superordinates None

Developer Robert Sullivan


Created: 04 November 2010Modified: 16 November 2010

Other Comments 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 Attendee selects registration options – workshops, tutorials, extra proceedings, etc. and when finished, proceeds to checkout cart.

Level 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





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



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

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)

Abort adding item; display “Prerequisite Registration Needed” error dialog

2. Attendee attempts to add a non-conference event (tutorial or workshop) that has a schedule conflict with an existing (in-cart or previously registered) non-conference event

Abort adding item; display “Schedule Conflict” error dialog

Priority in scheduling Primary


Superordinates None

Developer Joe Lizzi


Created: 04 November 2010Updated: 15 Novermber 2010

Other Comments None

14 | P a g e

Use Case Diagram

Figure 1 - Use Case Diagram

15 | P a g e

Analysis Class Diagram

Figure 2 - Analysis Class Diagram

16 | P a g e

Design Class Diagram

Figure 3 - Design Class Diagram

17 | P a g e

System Analysis – Validation & DiscussionThe 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

Figure 4 - System Sequence Diagram

19 | P a g e

Sequence Diagram (Add Account)

Figure 5 - Sequence Diagram (Add Account)

20 | P a g e

Sequence Diagram (Add Event to Cart)

Figure 6 - Sequence Diagram (Add Event to Cart)

21 | P a g e

Sequence Diagram (Pay for Ticket)

Figure 7 - Sequence Diagram (Pay for Ticket)

22 | P a g e

State Diagram

Figure 8 - State Diagram

23 | P a g e

System Design – Validation & DiscussionThe 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

Figure 14 - Entity-Relationship Diagram

25 | P a g e

Deployment Diagram

Figure 15 - Deployment Diagram

Physical Design – Validation & DiscussionThe 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

Figure 16 - Screenflow Diagram

28 | P a g e

Applications Design – Validation & DiscussionThe 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

ProjectIf 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-and-shopping-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.

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

UMLUnified 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 ToolsDuring 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 Completed Primarily ByProblem Statement Group SevenRequirements Rob SullivanUse Cases Group SevenDetailed Use Cases John Ehring, Joe Lizzi, Rob SullivanUse Case Diagram Group SevenAnalysis Class Diagram Group SevenDesign Class Diagram Joe LizziSystem Sequence Diagram John EhringSequence Diagram (Pay for Ticket) John EhringSequence Diagram (Add Account) Rob SullivanSequence Diagram (Add Event to Cart) Joe LizziState Diagram Rob SullivanDeployment Diagram John Ehring, Joe LizziEntity-Relationship Diagram Joe LizziScreenflow Diagram Rob SullivanEvaluation of Analysis & Design Group SevenValidation & Discussion 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.

ReferencesLarman, 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

Conference Registration System - Drexel University ...je58/docs/info620.docx · Web viewThe...

Documents

Transcript of Conference Registration System - Drexel University ...je58/docs/info620.docx · Web viewThe...