To design a good database for a given need, it is important to analyse the data to be stored. It should be determined which data should be stored, what kind of data they are, and which, if any, other data they have a relation with. This information can be gathered in several ways - the software can be built based on the given databases, or the databases can be designed from the requirements introduced by the software.[4] When designing a database, it is important to be able to identify one row from an- other. This can be obtained by using unique columns or a serial number for each row. In our database, we have chosen to give all our tables a numeric serial number, which allows us to identify an unique item, without checking every column in each row. This unique column can be marked as a primary key, and thereby be used as a foreign key in another table. This way, we can split up entities into several inter- nally linked tables.
The tables in the database can have different relationships, one-to-one, one-to-many or many-to-many. A one-to-one relation is used, when at most one instance of an entity is associated with an entity of the related table. One-to-many relations are used when there for an instance of an entity are zero, one or many instances of the related entity. This is the kind of relation usually used when representing stock in storages. Many-to-many relations are used when zero, one or many entities are related to zero, one or many entities in the related table.
Process
These last pages will be devoted to a study on the process of this project. We will describe findings, problems and thoughts regarding the four parts of this report de- voted to development, in chronological order. Each section will include a reflection of the observations made. We will not describe trivial operations that didn’t either cause us trouble or caught our interest.
25.1
Analysis document
In this section we will try to comment on the parts of the analysis phase that we found troublesome or especially interesting.
25.1.1
The pre-analysis phase
In the very beginning of this project we had not yet understood the scope of a project like this. We had talked about making a “fridge system” for private users, which could keep track of expiration dates and other characteristics of groceries. In the pre-analysis phase we changed this to a cafeteria management system to achieve a higher level of relevance. We drew a lot of rich pictures on a blackboard to un- derstand the processes in a cafeteria. The idea of rich pictures was introduced by the OOA&D method[6] and although they helped a lot in the pre-analyse phase, we found it hard to draw them in a manner that would fit onto a piece of paper. The first version of our system definition emerged at this stage, but was updated several times to reflect the current ideas and heading of the project.
Early in the project we tried to base our study on an actual cafeteria, but without any luck. We made an appointment with the manager of the AAU cafeteria, but unfortunately he never showed up at the appointed date. As a result, we spent a lot of time discussing more or less insignificant details, that could have been agreed upon if we could have studied an actual cafeteria. Slowly we began to find the classes that the problem domain consists of, and relating them to each other. These helped us find other classes later on, although it was hard to distinguish between different types of classes in the different parts of the development. We found that classes in the analysis was very different from classes in, for example, the design, which at times meant that we had our minds on the classes in the analysis when we should be working in another direction.
The next task was the application domain. We started finding actors and use-cases and drew some rich pictures of how we imagined the system would look. It helped us to shed light on some problems that we might have missed, had we not followed the OOA&D model.
25.1.3
Summary
The analysis phase helped us develop a clearer picture of the project. One prob- lem with the method was that it seemed very rigid, not allowing much for intuition and free development of ideas. One misunderstanding of the method which ham- pered our development was that instead of following the method step-by-step in monolithic steps, we should have returned to earlier stages and made it an iterative process.
25.2
Design document
The transition from analysis to design was focused on architecture and components. The classes and objects in the analysis reflect our understanding of the situation in which the system will exist, whereas the classes and objects in the design are closely related to the Java classes in the final system. This forced us to think in terms of Java, which added a number of constraints related to what was actually possible to implement. Unfortunately, we had a tendency to be too literal in our interpretation of the OOA&D method. Like in the analysis document, we also didn’t practice the
25.3
Implementation document
Many changes had to be made between the formulation of the design and its actual implementation in code. Unfortunately, our design proved excessively difficult to implement, largely because most of the group had little experience with object- oriented programming in Java. As the actual programming proceeded, much of the proposed design had to be redone. Possibly, this is once more a side effect of our failure to practice the process in a properly iterative manner. We chose to deviate from the design document where it was necessary.
25.4
Test document
In this phase we ran into problems with JUnit due to incompatibilities with Java 5. Specifically, JUnit 3.81 was not compatible with the new typesafe enums and generics in Java 5. After wresting a while with those issues, we ended up recoding part of the implementation using the old Java2 syntax.
Conclusion
Summarising the entire development project we have had some thoughts and knowl- edge we wish to leave for others to find. This has not been a perfect project, both due to the limitations of this semester and the limitations in personal ambition. Object- oriented design is a subject that we all need to be familiar with, but a strict model can easily take the fun out of development. We think of the strict enforcement of the OOA&D model as the primary cause why CAKE was not carried out to its max- imal potential. Although the OOA&D model is good and consistent it should not be forced upon anyone. Of course the enforcement of the model cannot be blamed for all of our development problems, but it is certainly a part of them. We all have an interest in software development, but we would rather have used the model only as inspiration, had we known earlier that it was an option.
26.1
The status of the CAKE system
The CAKE system was not as thorough and well designed as it could have been, if we had got off to a better start. The system we intended to implement is in some ways far from what was actually implemented, which is a shame. The system is a stripped down version of the optimal system, but it functions satisfactory. If we had had the time we would have implemented all five parts described in the analysis, to some extend.