Deliverable 2

TABLE OF CONTENTS
1. Introduction…………………………………………………………………………...2
1.1.Use Case Description……………………………………………………………...2
1.2.High Level Use Case Diagram…………………………………………………..9
1.3.Domain Model…………………………………………………………………....10
1.4.Sequence Diagram……………………………………………………………….11
1.5.Collaboration Diagram…………………………………….…………………….19
1.6.Operations Contract……………………………………………………………..23
1.7.DesignClass Diagram…………………………………………………………....27
1.8.Data Model………………………………………………………….…………………..28

Deliverable 2 1
1 PUCIT | EM Planner
1. Introduction
Our project is an Event Management Planner, which is basically for the people who want to organize
some events and want a variety of choices that may help them to organize their event more
efficiently. Our project is basically web-based application in which clients/users can post their
requirements according to their event needs and on the other hand event organizer can also post the
services they are providing in the market. The basic theme of this application is to create a platform
for both the organizers and Clients/Users to accomplish their needs on a single platform.
The modules of the system are consisting of these ends.
 Sign In Module
 Place Order Module
 View Services Module
 Select services or packages
 Place Order
Now we are ready to strive for a solution for the problem domain by using object-oriented approach.
Following artifacts are included in this deliverable. And we will work on these artifacts.
1. Use case descriptions
2. Use case diagram refined
3. Domain Model
4. Sequence Diagram
5. Collaboration Diagram
6. Operation Contracts
7. Design Class Diagram
8. Data Model

Deliverable 2 2
1.1 Use case Description
1.1.1 UC_LOGIN:
Brief Description:
This Use Case describes the process by which administrator and customer log into the event management
system. It also sets up access permissions for various categories of users.
Primary Actors:
 Administrator
 Customer
Stake Holders:
Administrator: Want to successfully login to the system.
Customer: Want to successfully login to the system.
Pre-Conditions: Administrator and customer should already been registered by the developer.
Basic Flow:
1. The Use Case starts when the administrator and customer starts the application.
2. The system will display the login screen
3. The administrator and customer enters a username and password.
4. The system will verify the information.
5. The system will set access permissions.
6. The system will display the main screen
.

Deliverable 2 3
Alternate Flows:
1. (a) If the invalid login information is provided, it will be prompted entering the correct
information.
Post Conditions: Administrator and customer would get login successfully.
1.1.2 UC_ALLOCATE_ADMIN
Brief Description:
Administrator should have authority to add another administrator so that if present
administrator has been changed or in case of some emergency, admin will assign authorities to the
new admin.
Primary Actors:
Administrator
Stake Holders:
Administrator: Want to add another admin successfully.
Pre-Conditions: Administrator should be authenticated admin.
Basic Flow:
1. Admin login to the application.
2. Select option to add an admin.
3. Admin provides specific information and hand over the admin rights to the new admin.
Alternate Flows:
1. (a) Login Failed.
Post Conditions: The new Admin now can do all the tasks assigned to the administrator.
1.1.3 UC_ENROLL_EVENT
Brief Description:
Admin and customer enroll new event using enrollment form.
Primary Actors:
Administrator
Stake Holders:

Deliverable 2 4
Administrator: Successfully add event’s information.
Customer : Successfully add event information
Pre-Conditions:
1. Admin and customer itself should be already enrolled.
2. Event must be a final for Management.
Basic Flow:
1. Admin and customer logs in and start enrolling event and recording their Emil id.
2. Admin and customer give the full description about the event.
3. Admin and customer successfully updates application’s data.
4. Admin and customers successfully log out from the application.
Alternate Flows:
1. (a) Login failed.
2. (a) If the invalid information is provided in the enrollment form, it will be prompted for
entering the correct information.
Post Conditions: Data would be successfully entered in the database.
1.1.4 UC_DELETE_EVENT
Brief Description:
Admin can delete the event after some particular time.
Primary Actors:
Administrator
Stake Holders:
Administrator: Successfully delete event that will be post on site for the biding
Pre-Conditions:
3. Admin itself should be already enrolled.
4. Event must be a upload on the website for biding.
Basic Flow:
5. Admin logs in and start delete event
6. Admin confirm delete that event
7. Admin successfully updates application’s data.
8. Admin successfully log out from the application.

Deliverable 2 5
Alternate Flows:
4. (a) If the invalid information is provided, it will not be delete the particular event
5. (a)event time period will be end or close for biding
Post Conditions: updating data would be successfully entered in the database.
1.1.5 UC_CHECK_IN_STATUS
Brief Description:
Admin will check how many users are currently login.
Primary Actors:
Administrator, Customer, Viewers
Stake Holders:
Customers: Wants to successfully check-in in the system.
Administrator: Wants to check that who is currently login.
Pre-Conditions: Admin must be login and have specific option in interface.
Basic Flow:
1. Admin must be login successfully
2. Admin view the check in status of the users.
Alternate Flows:
Post Conditions: Admin could check the check in status successfully.
1.1.6 UC_BID_ON_EVENT
Brief Description:
Customer, Viewers and providers can bid on the suitable event that they want to manage
Primary Actors:
Providers
Stake Holders:
Providers: Want to successfully bid on the event.

Deliverable 2 6
Pre-Conditions: provider will be the member of the website through the signup form.
Basic Flow:
1. Provider login through the email id and valid password
2. And bid on the suitable project.
3. Logout after the successfully biding on the event.
Alternate Flows:
1. (a) login failed
(b) Biding event cannot match with the skill of provider
Post Conditions: The information send to provider and that want to manage the event also through
the email.
1.1.7 UC_EVENT_EMAIL
Brief Description:
During the lifecycle of an Event a number of emails will be generated by the Event
Administrator.
Primary Actors:
 Administrator
 Customer
Stake Holders:
Administrator: Wants to generate the performance report of the employees’ on the basis of
given input.
Pre-Conditions: The admin is successfully login.
Basic Flow:
1. Sent Emails should be archived with a record of to whom they were sent.
2. A standard set of embeddable links should be available -
○ View the event
○ Register for the event
○ Change your registration
3. Open rates and click-through should be tracked for events
Alternate Flows:
1. (a) Application is unable to provide services due to server down.
(b) Information provided is invalid.

Deliverable 2 7
Post Conditions: The report is generated successfully
1.1.8 UC_EVENT_LOCATION
Brief Description:
Location of Events is something that both Event Administrators as
well as Participants need to do.
Primary Actors:
Administrator and customer
Stake Holders:
Administrator: Wants to give the exact map of the event location.
Customer: Wants to give the exact location where he want to manage the event
Pre-Conditions:
1. Administrator’ information is already saved in the system.
2. Customer’ attendance record is maintained in the system.
Basic Flow:
1. Admin will select location option from the system.
2. Admin will give the exact location by any resources it may be Google map and another.
3. Admin will review the location of the event.
Alternate Flows:
1. (a) Admin can change the location of the event.
2. (a) Connection to the database fails and record is not upload.
Post Conditions:
Admin will give the exact date and time.
1.1.9 UC_AUTO _EMAIL_GENERATED
Brief Description:
As the result of some customer actions emails will be automatically generated
Primary Actors:

Deliverable 2 8
Customer
Stake Holders:
Application: Wants to generate the report of the event on the basis of given input.
Pre-Conditions: The admin is successfully login.
Basic Flow:
1. Upon registration either a “successful registration” or a “registration pending” email
will be sent to the registrant (what do with registrants who don't have emails?).An
approved pending registration will result in a notification email to the registrant.
2. A cancellation or change of information regarding an event will result in a notification
email to all registered users as well as all registration pending users.
3. A new registration or pending registration will result in an email being sent to the
Event
Alternate Flows:
2. (a) Application is unable to provide services due to server down.
(b) Information provided is invalid.
Post Conditions: The Email is generated successfully

Deliverable 2 9
1.2 High level use case diagram:

Deliverable 2 10
1.3 Domain Model

Deliverable 2 11
1.4SequenceDiagram
1.4.1 UC_LOGIN

Deliverable 2 12
1.4.2 UC_ login_info

Deliverable 2 13
1.4.3 UC_ LOGOUT :

Deliverable 2 14
1.4.4 UC_ User Delete

Deliverable 2 15
1.4.5 UC_User_Insert

Deliverable 2 16
1.4.6 UC_User_Update

Deliverable 2 17
1.4.7 UC_User_Profile

Deliverable 2 18
1.4.8 UC_Services

Deliverable 2 19
1.5 Collaboration Diagram
1.5.1 UC_LOGIN
1.5.2 UC_Search

Deliverable 2 20
1.5.3 UC_ Login_Info_Manage_Conroller

Deliverable 2 21
1.5.4 UC_Insert
1.5.5 UC_UPDATE

Deliverable 2 22
1.5.6 UC_DELETE
1.5.7 UC_LOGOUT

Deliverable 2 23
1.5.8 UC_LOGOUT_COLLABORATION
1.6 Operational Contracts
Name : placeOrder()
Responsibilities: Reservean Event
Cross References : Uc_1
Exceptions : None
Preconditions: Customer view the event description
Post Conditions : Order successfully placed
Name : viewServices()

Deliverable 2 24
Responsibilities:To provideservices information
Cross References : UC_4
Exceptions : None
Preconditions : conduciveenvironmentand necessary condition for successful
interaction are available.
Postconditions : Services should be reviewed by customer
Name : makeYourOwnMenu()
Responsibilities: To make order for an event according to customer choice
Exceptions : None
Preconditions : Customer will choosethe products to make menu
PostConditions : Customizemenu successfully created.
Name : selectExistingPackages()
Responsibilities: Providecustomer with different packages.
Exceptions : None
Preconditions : Customer will view the existing packages.
PostConditions : Customer will select packages according to his choice.
Name : orderPlaced()
Responsibilities: Placed the customer order successfully

Deliverable 2 25
Exceptions : None
Preconditions : Customer view the event description
PostConditions : Order successfully placed.
Name : giveFeedback()
Responsibilities: Customer can give any feedback.
Exceptions : None
Preconditions : Customer musthave an email address.
PostConditions : Feedback posted.
Name : Subscribe()
Responsibilities: Providesubscription facility for update information
Exceptions : None
Preconditions : Customer should have an email address to subscribe.
PostConditions : Customer will receive confirmation email for subscription.

Deliverable 2 26
Name : makePayment()
Responsibilities: To handle customer payments
Cross Refrences: Uc_1
Exceptions : None
Preconditions : Customer should have to register for an event.
PostConditions : Paymentshould be in formof draftor cash.

Deliverable 2 27
1.7 Design Class Diagram

Deliverable 2 28
1.8 Data Model

Deliverable 2 29

Deliverable 2

More Related Content

What's hot (10)

Similar to Deliverable 2 (20)

Deliverable 2