Architectural Design:
    I'm Fredrik and I will be elaborating our Architectural design.

    Criteria:

        Very important:

            Correct:
                The reason the application was developed was to minimize errors, so if the program was not correct, it would defeat the purpose of even having a system for it.

            Reliable:
                Similar to the Correct criterea, it needs to be reliable so it can be depended on, considering it handles appointments with real people.

            Interoperable:
                The system needs to incorporate or at least communicate with multiple existing systems; two calendars, a webshop, and a database. Therefore, interoperable is very important.

        Important:

            Usable:
                The webshop part of the system will most likely be constantly introduced to new users and therefore needs to be intuitive and easy to use. However, the application part of the system will be used daily by the same communication managers, so this criteria has been deemed important.

            Testable:
                It is vital that the program performs its intended function. The program being testable helps ensure that the implementation is done correctly and gives the intended result. It prevents mistakes after release and allows for testing future changes.

    System Architechture:

        The system architecture consists of different components and their relations. Components have well defined responsibilities in the system and encapsulates a set of classes. Uses an open-strict layered architecture.

            Database layer:
                Consist of only a single component. Responsible for storing all information about instansiated objects in the model component. The objects are created and read from a combination of components in the function layer. The webshop user interface also reads from the database through an accessor.

            Application layer:
                This layer encapsulates the function component layer, the model component and the webshop database accessor. The model component encapsulates all classes used to represent the problem domain.

            Function layer:

                The database accessor component is responsible for connecting to the database and make the stored data in the Database component available to the Booking controller component.

                The booking controller makes this data easily available to the other components in the function layer.

                The time checker component checks if a facility or a time slot is available for a requested booking. Uses the booking objects in the booking controller component.

                The mail component handles the automated e-mail correspondence between the communcation manager and the customer.

                Calendar posting: handles all the entries and updates of bookings in the Zoo's calendars. Like the time checker component, it is dependent on the booking objects from the booking controller.

                Statistics: calculates the statistics. Makes the statistics available to the user interface controller. Uses booking objects.

                Webshop databaser accessor component: responsible for connecting to the database and transferring data to and from the webshop

                User interface controller: contains all classes responsible for the functionality in the user interface. Provides information to the application user interface component in the user interface layer.

            User interface layer:

                Contains two sub components. Application user interface and Webshop user interface. Respectively, they are responsible for the visual representation of the application and webshop.


    Database Structure and Design:

        The database is structured in an object oriented way. This entity relationship diagram depicts the database, using Chen's notation. The most important characteristics of the database is the relationship between the booking table and the arrangement/lecture booking tables. The weak relationship between these tables indicate that any entry in the arrangment or lecture booking tables need a corresponding entry in the booking table. This is done using foreign keys, as we can see the primary key in these tables are partial key attributes. A partial key attribute (discriminator) is an attribute that,    entity, provides a unique identification for the weak entity. There is a similar relationship between the customer table and the lecture booking customer table.