deliverable 2

TABLE OF CONTENTS

1. Introduction…………………………………………………………………………...21.1. Use Case Description……………………………………………………………...21.2. High Level Use Case Diagram…………………………………………………..91.3. Domain Model…………………………………………………………………....101.4. Sequence Diagram……………………………………………………………….111.5. Collaboration Diagram…………………………………….…………………….191.6. Operations Contract……………………………………………………………..231.7. Design Class Diagram…………………………………………………………....271.8. Data Model………………………………………………………….…………………..28

Deliverable 2 1

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 descriptions2. Use case diagram refined3. Domain Model4. Sequence Diagram5. Collaboration Diagram6. Operation Contracts7. Design Class Diagram8. Data Model

1 PUCIT |

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

.

2 PUCIT |

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:

3 PUCIT |

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.

4 PUCIT |

Deliverable 2 5

Alternate Flows:

3. (a) Login failed.4. (a) If the invalid information is provided, it will not be delete the particular event5. (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 successfully2. Admin view the check in status of the users.

Alternate Flows:

1. (a) Login failed.

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.

5 PUCIT |

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

6 PUCIT |

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

7 PUCIT |

Deliverable 2 8

Primary Actors:

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

8 PUCIT |

Deliverable 2 9

1.2 High level use case diagram:

9 PUCIT |

Deliverable 2 10

1.3 Domain Model

10 PUCIT |

Deliverable 2 11

1.4Sequence Diagram

11 PUCIT |

Deliverable 2 12

1.4.1 UC_LOGIN

1.4.2 UC_ login_info

12 PUCIT |

Deliverable 2 13

13 PUCIT |

Deliverable 2 14

1.4.3 UC_ LOGOUT :

14 PUCIT |

Deliverable 2 15

1.4.4 UC_ User Delete

15 PUCIT |

Deliverable 2 16

1.4.5 UC_User_Insert

16 PUCIT |

Deliverable 2 17

1.4.6 UC_User_Update

17 PUCIT |

Deliverable 2 18

1.4.7 UC_User_Profile

18 PUCIT |

Deliverable 2 19

1.4.8 UC_Services

19 PUCIT |

Deliverable 2 20

1.5 Collaboration Diagram

1.5.1 UC_LOGIN

1.5.2 UC_Search

20 PUCIT |

Deliverable 2 21

1.5.3 UC_ Login_Info_Manage_Conroller

1.5.4 UC_Insert

21 PUCIT |

Deliverable 2 22

1.5.5 UC_UPDATE

1.5.6 UC_DELETE

22 PUCIT |

Deliverable 2 23

1.5.7 UC_LOGOUT

1.5.8 UC_LOGOUT_COLLABORATION

23 PUCIT |

Deliverable 2 24

1.6 Operational Contracts

Name : placeOrder()

Responsibilities : Reserve an Event

Cross References : Uc_1

Exceptions : None

Preconditions: Customer view the event description

Post Conditions : Order successfully placed

Name : viewServices()

Responsibilities : To provide services information

Cross References : UC_4

24 PUCIT |

Deliverable 2 25

Exceptions : None

Preconditions : conducive environment and 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 choose the products to make menu

PostConditions : Customize menu successfully created.

Name : selectExistingPackages()

Responsibilities : Provide customer 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


Exceptions : None

Preconditions : Customer view the event description

25 PUCIT |

Deliverable 2 26

PostConditions : Order successfully placed.

Name : giveFeedback()

Responsibilities : Customer can give any feedback.


Exceptions : None

Preconditions : Customer must have an email address.

PostConditions : Feedback posted.

Name : Subscribe()

Responsibilities : Provide subscription facility for update information


Exceptions : None

Preconditions : Customer should have an email address to subscribe.

PostConditions : Customer will receive confirmation email for subscription.

Name : makePayment()

26 PUCIT |

Deliverable 2 27

Responsibilities : To handle customer payments

Cross Refrences : Uc_1

Exceptions : None

Preconditions : Customer should have to register for an event.

PostConditions : Payment should be in form of draft or cash.

1.7 Design Class Diagram

27 PUCIT |

Deliverable 2 28

1.8 Data Model

28 PUCIT |

Deliverable 2 29

29 PUCIT |

deliverable 2

Documents