This is the program for Software Design Phase 3.

Authors:

• Yuuuuuu-xue
• XY-Yue

The UML diagrams are in each package with name UML.pdf. They are all generated by IntelliJ.

Please make sure the working directory is the phase2 folder, so the file path will work properly. The main method is in the DemoMain file in the default package, the program runs through the main method.

All the required .ser files should already be in the repo in the data folder, if they are not, here is what will happen: When running for the first time, the program need to read from a .txt file in src for the account information only. The rest will require .ser files which does not exist at the beginning so there will be error messages, that's not a problem. After the program displays the welcome message and prompt for input, user can enter things to test the program.

Notice that all the user info, i.e. username and password, are not stored in the .txt file. We have a UserDataConverter class that reads .txt file and coverts into a .ser file. Notice when we convert .txt to .ser, we have a basic debugging step that ensures all the data are correct, if not then it will output some error messages and continue converting data. We have two tests on line 22 and line 26 that have wrong data type to be converted into user account.

We provide a starter data for you to test it. Please go to src -> data -> CSC207 Data Phase2.txt and see the details of starter data.

When finish testing, keep entering 'r' to return to the previous step and finally enter 'q' at the welcome menu to exit. There will be a option that asks to save data or not, saving data will allow testing again later, not saving will keep the current data.

All "Hosts" means Speakers for events.

Speakers and Organizers are allowed to send messages to everyone, and attend events.

"Favorite list" means friend list, can also be seen as contact lists on a cellphone. A user can message any user of any type as long as that user knows their username

Talks can only have exactly 1 host, party have no host, and panel discussions must have more than 1 hosts.

Notice when choosing to create an account, we only allow the user to create either an Attendee or VIP account. Since we have a data converter, that means we can have an organizer before we start the program. Due to the instruction, the organizer has the ability to create any other accounts. So in real life, we don't want the user to create an organizer or other account types. Instead, the organizer takes responsibility to create other accounts such as speakers when they need it.

VIP account can access VIP only event. Attendee account cannot access VIP only event. Both Speaker and Organizer can access VIP only event. (It makes sense due to the employee benefits, if not then it should be a easy fix)

Event's duration is measured in minutes, i.e. 9:10 to 10:11. Room's open time is measured in hours, i.e. this room is opened from 9am to 11pm.

User cannot send message to themselves.

User cannot delete a message from archived message list, must unarchive first.

Features:

We have multiple types of event:

• Talk is one speaker
• Party is no speaker
• Panel Discussion is more than one speaker as described above.

Events can be canceled by any organizer so at least one. We have one more user type, a VIP user type. It has the ability to attend VIP only event. A user can choose to create a VIP account or attendee account. In real world, this is the situation to gain profits by asking user to pay the cost. An organizer can create any other accounts including VIP account. Each event stores a maximum capacity. The maximum capacity of this event is less than or equal to the maximum capacity of the location of this event.

• More constrains in rooms when creating a new event: a room can have features such as computers/table/projector When organizers make a new event, the required features will be chosen prior to choosing rooms, and a list of available rooms with the required features and capacity/time will be provided. So the organizer can see a suggested list of rooms that fit the requirement of their event.

• A better messaging experience: user can set a message as unread/read/archive. This can be done in the message status menu, messages with separate status can be viewed separately.

• The alternative options on the third optional extension, we print the schedule to the screen. In addition, user can choose to see a schedule with given a time interval, by speaker, or location. In addition, they can also view the event they have signed up.

• Favourite list, user can add other username into their favourite list so they can find the username easily. A data converter to help convert between .txt files and .ser files. It is used for creating user account specifically. View message in order, form newest to oldest, or vice versa.

• Rooms' available times can be more customized. For example, a room can be available at morning and night only but not available in the afternoon. When entering the time intervals, if something like 1-2, 2-3 are entered, they will be recorded as 1-3. We also allow user to choose that room will open for 24 horus, 9 (9am) to 17 (5pm), or input your own time slots.

• User can choose to save the data or not. It is mainly for demo, in real life, we will automatically save the data.

• Organizer can upgrade an Attendee to a VIP. Organizer can also degrade a VIP into an Attendee. If that's case, then all the VIP event signed up will be removed so the degraded account will be no longer to access the VIP account.

• Event is now measured in minutes and can be host for multiple days.

• An organizer can choose to reschedule an event by date, time, or location. If by time, then if attendee is not available during the updated time, we will simply remove them from the list. This will be improved if we have more time.

• We solve the time issue. If user checks an event, it will compare the event's time and user's current time. So event will be expired, then attendees cannot sign up and organizer cannot reschedule it. A message also records the time it was created.

Design Patterns

Design Patterns Used:

• Factory: UserSystemFactory, EventFactory and AccountFactory: The three factories are used to encapsulate the constructors when making instances of subclasses for a abstract class. This way the class that needs to create a certain subclass based on user input does not need to know which type of subclass it is creating, therefore it improves encapsulation and abstraction.

• Strategy:

  • MessageSorter -> MessageNewestToOldest/MessageOldestToNewest
  • Validator -> SimpleValidationPassword/SimpleValidationUsername

  The 2 strategies are used so that the classes that required such different algorithms with common properties in various situations, can always use the interface and therefore does not know how the algorithm is implemented which helps to encapsulate the algorithm. Classes can now choose different algorithms based on different operations without depending on the certain algorithms.

• Iterator: Account, Event, Message: In the getters of our collections, we always return the default iterator instead of the collection it self. For Map, we created a new iterator inner class and return that iterator instead of the map. This encapsulates how information is stored in the entities while not affecting the overall efficiency. And therefore improves overall design and OCP.

• Facade: (not exactly the design pattern, but has similar properties). User/Speaker/Attendee/Speaker/VIP Systems: The classes listed above takes in user menu options and calls other controller methods to react to the option. This prevents the above controllers from having multiple actors (responsibilities) and encapsulates the code that responsible for different actors.

• Builder: (again, not exactly the design pattern, but has similar properties) EventSchedulerSystem: Creating a new event requires the user to enter various information one by one, this is similar to the application of Builder. But it is not creating a object with complex structure, it is gathering information required to create that object. The actual object creation is not complicated. The step by step operation demonstrated in the public classes of EventSchedulerSystem is similar to Builder.

Some of the Unused Patterns Explanation:

• Observer: Can be (and really should be) used widely in use case and entity layer, but it is not Serializable. We tried to create our own Observer class. So the Event is observable, and both Account and Room are observers (all of them are in Entity level). There will be an EventObserver interface that has abstract method update() and getName() that returns the roomName from Room or username from Account. And Event will store a collection of EventObserver (an abstraction layer). This way, when we create an event, reschedule an event, or cancel an event (by Organizer), we can notify our observers. As a consequence, we can reduce a significant amount of code in EventSchedulerSystem and other methods in Event/Account/Room Manager (use case level). However, this will require us to refactor the entire use case and entity level and we might not have time to finish it. So we decide to discuss our rough idea over here and hope to get some feedback so we can start working on our Phase 3 over the winter break.

Significant Design Decisions:

• We separated large Controllers into several smaller Controllers using the method described in Phase 1 Readme. This separated responsibilities in controllers to ensure each class is responsible for a more specific actor.

• Based on TA's comment, we refactored RegisterSystem to make it more extensible. Now we can easily make all types of accounts self register.

• We refactored overall the use case and entity level from Phase 1.

  • For Account, instead storing all account info in the message or event manager. We let account stores a collection of unique IDs so both MessageManager and EventManager can have a hashmap that maps the id to the object itself without knowing anything about account username.
  • For message, we store the time when message is created.
  • For event, we store the event start time and end time. It will be updated in the future so we will ask for more flexible way to create an event duration.
  • For room, it has their own time open time instead of 9am to 5pm in Phase 1.

Future plan:

We will definitely continue working this project, improve existing code and finish all the optional extensions with many our own features. We will spend our own time to learn database and implement GUI, so to end up with a full implemented project that we can share on our future interviews.

Last but not least:

really appreciated for all the helps provided by our instructors!

"# EventManagingSystem" "# EventManagingSystem"