Design - Blog 04

This week, our group was tasked with producing the following items/decisions/designs regarding the project at hand. I'll go into more detail on the solutions to each and how we arrived at them in the paragraphs below.

0. Assign teams/roles

When the group got together at the beginnning of the week, the first thing that needed to be done before we could begin progress on any of the other requirements was break into subgroups within our team. This was a simple process since there perfectly half of the group that wanted to work in the back end and with the storing and handling of data, and then half of the group that much preferred to work on the user interfaces in the front end. So the group split up so the current teams are myself, Andrew, Charles, Bradley, Adam B, Justin C and Bhagirath on the back end, and then Bobby, Justin K, Adam C, Aaron, Nick and Reean on the front end. These are the teams as they stand right now, however in the coming week or so, I'm anticipating that the back end will be in a good enough place for myself and 1-2 others to migrate over and help the front end with some of their code.

1. Decision for what Database we'll use

Once in the back end group, we discussed how we wanted to store and work with the data. Our decision was quick and unanimous as everyone learned MySQL in their database course here at Wentworth.

2. Decision on what Environment we'll work in

We then discussed how we are going to implement our solution. This required a bit more discussion, as some people in our group have more of insight with different experiences and projects they have worked on in their unique and various coop environments. We are all familiar with Java and C, as those are the two languages that we have all been using throughout our academic careers. However the more experienced members of the group recognized that these languages are probably not the best tools for the problem at hand. I personally suggested ASP/.Net as that was what I have been most recently exposed to. Andrew suggested we use Go, and we decided as a group that that will be the language we use. Only half of us know the language, so myself and a couple others will be learning that this weekend.

3. Sketches of UI

I'm not too certain as to the decision process that the front end team used to design the UI for our solution, but eventually they came up with a tabbed application with which the user can enter the data for a Room, Speaker, Time Slot, and Session -- each on a different tab. When they drew it on the board, in looks like they intended on having the UX be like a step by step wizard, which I think will need to be reconsidered, as the user reserves the right to enter a Room, then another Room, then a speaker, then a time slot, then a session, then another session, in any order. Not just in the set order of Room -> Speaker -> Time slot -> Session which is what it currently looks like they have.

4. ERD for the Database

The ERD for the database was a simple task that we were able to just fill in with the requirements we solidified in previous weeks. We need entities for Rooms, Speakers and Sessions. Rooms will be defined with a unique room ID along with a capacity. Speakers will be defined with a unique ID (email), and a first and last name. Sessions will have a unique ID constructed with the RoomID and Timeslot, and will also store the speaker, title of session, and the length of the session.

5. Class Diagrams

This is the least finalized section of the requirements we worked on this week. We have a rough draft of basically how our system is going to operate, but this area will definelty need more work before we begin coding. We have defined our plan to have classes to represent and carry each piece of data defined in the ERD. We also intend on having classes that will allow for the writing, reading, and editing of the data in the database (db). We also know that we will implement API calls to allow the front end to access these classes with db access. The only part that we do not yet have a design for is the connection between the UI and the API calls. We need to figure out that layer that recognizes a button has been pushed and that data is waiting to be pulled in and that communication with the db is imminent. This design will probably be expanded upon by the UI team next week, and implemented by one of the flexible team members from the back end the week after.

With President's Day approaching, the other group in our session will be missing in class time with our client/professor, so to account for this disadvantage, our group will not be meeting next week. This means that we have 2 weeks to work on solidifying our designs enough to begin implementing phase one (data entry) to our solution with code. This also means that next weeks post may be a have a little rougher picture to paint, as we will most likely meet twice out of class without contact from the client. We have notes from our in class meeting with the client, so there's a variety of things we will be working on next week. Stay tuned for updates on how we grow closer to our first release!