Backend: Design of the API Discussion

[sevab]

Hand-in: Week 6, Term 2 (February 17th, 2014). Duration: 5 hours. Value: 5%. Product: a description of the interface between the back-end and front-end of the of the prototype computer system in the form of class diagrams with method signatures. Process: a record of the evolution of the interface in the form of a printed copy of the discussion that took place on Google Code.

Disambiguation of usernames:

• sevab Usevalad Baskin
• akshay378 Akshay Mittal
• armand64 Armand Baboian
• hornets Vlad Valeanu

[sevab]

Gotta ask David what exactly is meant by front-end and back-end. Front-end could be the user interface or the whole of client software. Backend could be all the software except the user interface or just the server software that connects all client machines maintains one central database. Any ideas?

[akshay378]

Hey team! As per our meeting today (Wednesday the 5th), we started constructing class diagrams with more or less all the attributes and method signatures we thought would be required.

We started by noting down the major classes (by making use of our Use Case Diagram) we thought would be required for the design of the API, which are as follows:

Customer Review Movie Screening Booking Seating Plan Administrator and Newsletter

For most of the classes, their attributes and method signatures seemed to be pretty straight forward after a brain storming session within the team members as well as according to the specification provided to us. For example, for the Customer class we have name (String), password (String) and credit_card (Number) as the attributes and create (name, password, credit_card), update (name, password, credit_card), delete() and find() as the method signatures. However, for the Seating Plan class there came a point when the team had a discussion at length on the way we would represent it within the system. The team decided and is certain that the seating plan is to be stored in a database using SQL, but was however not sure how to represent it.

Hence, we decided to ask David for his input in tomorrow's lecture and then take this design any further.

Here is a picture of what we noted down in rough on paper today, that is the class diagram along with its attributes and method signatures:

[sevab]

I'm reading Chapter 4 on Class Diagrams from Fowler's UML Book and suggest you do the same, the book points out a number of deficiencies in our first draft. For example, we have too much detail in regard to attributes (e.g. ids and explicit pointers between classes are unnecesary). Our diagram also tries to think too much about the final implementation, which shouldn't be the case. Instead it should take a specification and conceptual perspective. Anyways, have a read.

[hornets]

This is an outline of our meeting today (Friday 14th of February 2014).

After long attempts of creating a simple structure for our app, we decided to conduct some research on best approaches.

After conducting some research online and in reference to Using UML : Software Engineering with Objects and Components (P. Stevens with R. Pooley) and UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition by Addison Wesley), the group decided to utilize the MVC approach. The reason behind our decision is because we feel the MVC approach separates the three main components of our App, therefore creating a simple yet flexible structure, which would help and ease the developmental phase.

[armand64]

(Friday 14th of February 2014)

Another important part of our discussion was the design patterns. As we’ve been thought in the lectures design patterns, we’ve been looking whether or not this would help us with our current structure. We’ve come across the Active Record pattern, which we’ve decided to use as it makes most sense.

Some other points we’ve discussed were: • Creating a mysql connection from Java, which we successfully managed to do via the ActiveJDBC • If we should remove the bidirectional arrows in the uml for the controller view relation • And if we should work on the multiplicity or not