SlideShare a Scribd company logo
1 of 30
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
2 PUCIT | EM Planner
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
3 PUCIT | EM Planner
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
4 PUCIT | EM Planner
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
5 PUCIT | EM Planner
Alternate Flows:
3. (a) Login failed.
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:
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.
Deliverable 2 6
6 PUCIT | EM Planner
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
7 PUCIT | EM Planner
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
8 PUCIT | EM Planner
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
9 PUCIT | EM Planner
1.2 High level use case diagram:
Deliverable 2 10
10 PUCIT | EM Planner
1.3 Domain Model
Deliverable 2 11
11 PUCIT | EM Planner
1.4SequenceDiagram
1.4.1 UC_LOGIN
Deliverable 2 12
12 PUCIT | EM Planner
1.4.2 UC_ login_info
Deliverable 2 13
13 PUCIT | EM Planner
1.4.3 UC_ LOGOUT :
Deliverable 2 14
14 PUCIT | EM Planner
1.4.4 UC_ User Delete
Deliverable 2 15
15 PUCIT | EM Planner
1.4.5 UC_User_Insert
Deliverable 2 16
16 PUCIT | EM Planner
1.4.6 UC_User_Update
Deliverable 2 17
17 PUCIT | EM Planner
1.4.7 UC_User_Profile
Deliverable 2 18
18 PUCIT | EM Planner
1.4.8 UC_Services
Deliverable 2 19
19 PUCIT | EM Planner
1.5 Collaboration Diagram
1.5.1 UC_LOGIN
1.5.2 UC_Search
Deliverable 2 20
20 PUCIT | EM Planner
1.5.3 UC_ Login_Info_Manage_Conroller
Deliverable 2 21
21 PUCIT | EM Planner
1.5.4 UC_Insert
1.5.5 UC_UPDATE
Deliverable 2 22
22 PUCIT | EM Planner
1.5.6 UC_DELETE
1.5.7 UC_LOGOUT
Deliverable 2 23
23 PUCIT | EM Planner
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
24 PUCIT | EM Planner
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
Cross References : Uc_1
Exceptions : None
Preconditions : Customer will choosethe products to make menu
PostConditions : Customizemenu successfully created.
Name : selectExistingPackages()
Responsibilities: Providecustomer with different packages.
Cross References : Uc_1
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
Cross References : Uc_1
Deliverable 2 25
25 PUCIT | EM Planner
Exceptions : None
Preconditions : Customer view the event description
PostConditions : Order successfully placed.
Name : giveFeedback()
Responsibilities: Customer can give any feedback.
Cross References : Uc_1
Exceptions : None
Preconditions : Customer musthave an email address.
PostConditions : Feedback posted.
Name : Subscribe()
Responsibilities: Providesubscription facility for update information
Cross References : Uc_1
Exceptions : None
Preconditions : Customer should have an email address to subscribe.
PostConditions : Customer will receive confirmation email for subscription.
Deliverable 2 26
26 PUCIT | EM Planner
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
27 PUCIT | EM Planner
1.7 Design Class Diagram
Deliverable 2 28
28 PUCIT | EM Planner
1.8 Data Model
Deliverable 2 29
29 PUCIT | EM Planner

More Related Content

What's hot

Airline Reservation Software Requirement Specification
Airline Reservation Software Requirement SpecificationAirline Reservation Software Requirement Specification
Airline Reservation Software Requirement Specification
Deborah Kronk
 
School admission process management system (Documention)
School admission process management system (Documention)School admission process management system (Documention)
School admission process management system (Documention)
Shital Kat
 

What's hot (20)

Software Requirement Specification
Software Requirement SpecificationSoftware Requirement Specification
Software Requirement Specification
 
Chapter 7 Use Case Model
Chapter 7 Use Case ModelChapter 7 Use Case Model
Chapter 7 Use Case Model
 
Alpha & Beta Testing
Alpha & Beta TestingAlpha & Beta Testing
Alpha & Beta Testing
 
Systems request
Systems requestSystems request
Systems request
 
Sequence diagram- UML diagram
Sequence diagram- UML diagramSequence diagram- UML diagram
Sequence diagram- UML diagram
 
Airline Reservation Software Requirement Specification
Airline Reservation Software Requirement SpecificationAirline Reservation Software Requirement Specification
Airline Reservation Software Requirement Specification
 
Incremental model presentation
Incremental model presentationIncremental model presentation
Incremental model presentation
 
School admission process management system (Documention)
School admission process management system (Documention)School admission process management system (Documention)
School admission process management system (Documention)
 
SRS on online auction system
SRS on online auction systemSRS on online auction system
SRS on online auction system
 
Use Case UML Diagram
Use Case UML DiagramUse Case UML Diagram
Use Case UML Diagram
 
Srs example webapp
Srs example webappSrs example webapp
Srs example webapp
 
Ecommerce srs
Ecommerce  srsEcommerce  srs
Ecommerce srs
 
Incremental model
Incremental modelIncremental model
Incremental model
 
ONLINE EXAMINATION SYSTEM
ONLINE EXAMINATION SYSTEM ONLINE EXAMINATION SYSTEM
ONLINE EXAMINATION SYSTEM
 
Basis path testing
Basis path testingBasis path testing
Basis path testing
 
Online Restaurant Management System
Online Restaurant Management SystemOnline Restaurant Management System
Online Restaurant Management System
 
software Prototyping model
software Prototyping modelsoftware Prototyping model
software Prototyping model
 
Interaction Modeling
Interaction ModelingInteraction Modeling
Interaction Modeling
 
System Analysis & Design (NCC Education)
System Analysis & Design (NCC Education)System Analysis & Design (NCC Education)
System Analysis & Design (NCC Education)
 
Software Requirements
Software RequirementsSoftware Requirements
Software Requirements
 

Similar to Deliverable 2

cuACS Requirements Analysis Document Nicholas Aubé.docx
cuACS Requirements Analysis Document Nicholas Aubé.docxcuACS Requirements Analysis Document Nicholas Aubé.docx
cuACS Requirements Analysis Document Nicholas Aubé.docx
dorishigh
 
Customer Contact DB Development Project
Customer Contact DB Development ProjectCustomer Contact DB Development Project
Customer Contact DB Development Project
Nicholai Stevens
 
Event Management System Document
Event Management System Document Event Management System Document
Event Management System Document
LJ PROJECTS
 
FINAL PROJECT REPORT1
FINAL PROJECT REPORT1FINAL PROJECT REPORT1
FINAL PROJECT REPORT1
waqar younas
 
Final report_Raymond
Final report_RaymondFinal report_Raymond
Final report_Raymond
Akash Indani
 
Protectourwater.ie SRS
Protectourwater.ie SRSProtectourwater.ie SRS
Protectourwater.ie SRS
Killian Vigna
 
Software Requirements ElicitationRequirements specify a set of f.docx
Software Requirements ElicitationRequirements specify a set of f.docxSoftware Requirements ElicitationRequirements specify a set of f.docx
Software Requirements ElicitationRequirements specify a set of f.docx
whitneyleman54422
 
ChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesignChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesign
Chris Garrison
 

Similar to Deliverable 2 (20)

cuACS Requirements Analysis Document Nicholas Aubé.docx
cuACS Requirements Analysis Document Nicholas Aubé.docxcuACS Requirements Analysis Document Nicholas Aubé.docx
cuACS Requirements Analysis Document Nicholas Aubé.docx
 
Customer Contact DB Development Project
Customer Contact DB Development ProjectCustomer Contact DB Development Project
Customer Contact DB Development Project
 
Tour guidance srs (Software Requirements Specification)
Tour guidance  srs (Software Requirements Specification)Tour guidance  srs (Software Requirements Specification)
Tour guidance srs (Software Requirements Specification)
 
SRS Document for Digital Time Stamping
SRS Document for Digital Time StampingSRS Document for Digital Time Stamping
SRS Document for Digital Time Stamping
 
ValidityUseCases
ValidityUseCasesValidityUseCases
ValidityUseCases
 
Event Management System Document
Event Management System Document Event Management System Document
Event Management System Document
 
Report Tracking Actions in KC-Screenshots
Report Tracking Actions in KC-ScreenshotsReport Tracking Actions in KC-Screenshots
Report Tracking Actions in KC-Screenshots
 
SAD_del3
SAD_del3SAD_del3
SAD_del3
 
FINAL PROJECT REPORT1
FINAL PROJECT REPORT1FINAL PROJECT REPORT1
FINAL PROJECT REPORT1
 
Final report_Raymond
Final report_RaymondFinal report_Raymond
Final report_Raymond
 
Srs sample
Srs sampleSrs sample
Srs sample
 
E-commerce (System Analysis and Design)
E-commerce (System Analysis and Design)E-commerce (System Analysis and Design)
E-commerce (System Analysis and Design)
 
Group 9 SRS
Group 9 SRSGroup 9 SRS
Group 9 SRS
 
Report Tracking Actions in KC
Report Tracking Actions in KCReport Tracking Actions in KC
Report Tracking Actions in KC
 
Chapter 4
Chapter 4Chapter 4
Chapter 4
 
Protectourwater.ie SRS
Protectourwater.ie SRSProtectourwater.ie SRS
Protectourwater.ie SRS
 
Test plansample
Test plansampleTest plansample
Test plansample
 
Software Requirements ElicitationRequirements specify a set of f.docx
Software Requirements ElicitationRequirements specify a set of f.docxSoftware Requirements ElicitationRequirements specify a set of f.docx
Software Requirements ElicitationRequirements specify a set of f.docx
 
ChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesignChrisGarrisonFeatherweightArchitecture-DetailDesign
ChrisGarrisonFeatherweightArchitecture-DetailDesign
 
Use S
Use SUse S
Use S
 

Deliverable 2

  • 1. 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
  • 2. 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
  • 3. Deliverable 2 2 2 PUCIT | EM Planner 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 .
  • 4. Deliverable 2 3 3 PUCIT | EM Planner 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:
  • 5. Deliverable 2 4 4 PUCIT | EM Planner 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.
  • 6. Deliverable 2 5 5 PUCIT | EM Planner Alternate Flows: 3. (a) Login failed. 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: 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.
  • 7. Deliverable 2 6 6 PUCIT | EM Planner 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.
  • 8. Deliverable 2 7 7 PUCIT | EM Planner 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:
  • 9. Deliverable 2 8 8 PUCIT | EM Planner 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
  • 10. Deliverable 2 9 9 PUCIT | EM Planner 1.2 High level use case diagram:
  • 11. Deliverable 2 10 10 PUCIT | EM Planner 1.3 Domain Model
  • 12. Deliverable 2 11 11 PUCIT | EM Planner 1.4SequenceDiagram 1.4.1 UC_LOGIN
  • 13. Deliverable 2 12 12 PUCIT | EM Planner 1.4.2 UC_ login_info
  • 14. Deliverable 2 13 13 PUCIT | EM Planner 1.4.3 UC_ LOGOUT :
  • 15. Deliverable 2 14 14 PUCIT | EM Planner 1.4.4 UC_ User Delete
  • 16. Deliverable 2 15 15 PUCIT | EM Planner 1.4.5 UC_User_Insert
  • 17. Deliverable 2 16 16 PUCIT | EM Planner 1.4.6 UC_User_Update
  • 18. Deliverable 2 17 17 PUCIT | EM Planner 1.4.7 UC_User_Profile
  • 19. Deliverable 2 18 18 PUCIT | EM Planner 1.4.8 UC_Services
  • 20. Deliverable 2 19 19 PUCIT | EM Planner 1.5 Collaboration Diagram 1.5.1 UC_LOGIN 1.5.2 UC_Search
  • 21. Deliverable 2 20 20 PUCIT | EM Planner 1.5.3 UC_ Login_Info_Manage_Conroller
  • 22. Deliverable 2 21 21 PUCIT | EM Planner 1.5.4 UC_Insert 1.5.5 UC_UPDATE
  • 23. Deliverable 2 22 22 PUCIT | EM Planner 1.5.6 UC_DELETE 1.5.7 UC_LOGOUT
  • 24. Deliverable 2 23 23 PUCIT | EM Planner 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()
  • 25. Deliverable 2 24 24 PUCIT | EM Planner 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 Cross References : Uc_1 Exceptions : None Preconditions : Customer will choosethe products to make menu PostConditions : Customizemenu successfully created. Name : selectExistingPackages() Responsibilities: Providecustomer with different packages. Cross References : Uc_1 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 Cross References : Uc_1
  • 26. Deliverable 2 25 25 PUCIT | EM Planner Exceptions : None Preconditions : Customer view the event description PostConditions : Order successfully placed. Name : giveFeedback() Responsibilities: Customer can give any feedback. Cross References : Uc_1 Exceptions : None Preconditions : Customer musthave an email address. PostConditions : Feedback posted. Name : Subscribe() Responsibilities: Providesubscription facility for update information Cross References : Uc_1 Exceptions : None Preconditions : Customer should have an email address to subscribe. PostConditions : Customer will receive confirmation email for subscription.
  • 27. Deliverable 2 26 26 PUCIT | EM Planner 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.
  • 28. Deliverable 2 27 27 PUCIT | EM Planner 1.7 Design Class Diagram
  • 29. Deliverable 2 28 28 PUCIT | EM Planner 1.8 Data Model
  • 30. Deliverable 2 29 29 PUCIT | EM Planner