Analysis

In this phase of the project we spend a lot of time discussing on the steps we should take in the project. We followed the SAD curse, did the exer- cises, which corresponded very good to what we had to do in order to make our project. Every decision and task at this point were discussed in the whole group and noted on the blackboards. We had some early problems in deciding what system we should make. At first we decided to make an ordinary warehouse management system to an online warehouse, but some of the group members quickly came up with the idea that we should make an online web portal listing computer hardware from different suppliers all over Europe. And so we began planing for the development of the system.

One of our lecturer pointed out that it would be unwise to code such a sys- tem in Java, and there was some concern, that the system we had begun to develop, did not contain enough classes to make a project in the scale required by the study guidelines. We decided to go back to the original idea. However, we liked the web part of the project, and decided to make a website where a customer could browse around and place an order, which would be sent to a warehouse for processing.

At this point we had lost a considerable amount of time, and began to work hard in order to catch up. Each group member became responsible for a part of the analysis. This of course meant that not all of the group members knew what was going on in other part of the project. To ensure the project stayed on course, everything made was controlled by at least a few other members of the group

In retrospect, it would properly have been a good idea if we had stuck to one idea. Because out of all this we had some trouble writing our system definition in the right “academic” way and also so it would correspond to the system we actually would make. We had a similar problem concerning the class diagram, which went through considerable changes right up until we began coding the system.

In the beginning it was very difficult for us to separate the problem and appli- cation domain this resulted in use cases that used functions instead of events. Early in the process we also became too ambitious and began to design a very large and complex system, which consisted of an administration part to administrate statistics, employees, products and warehouses. Fortunately we realized this would become to large for us to make in the time available, and so we simplified it. In the end we decided that we wanted to make a home page using JSP, that could be used to create customer and order objects that would be stored in a database. The system would also be a warehouse storage program that would be used to view orders and then process them. We did this because we liked the challenge of making a system that would use network and databases. We also wanted to concentrate on creating a good user interface and believed we, by working with this idea would get the opportunity.

13.1.2

Design

This section concerns the work process in the design as well as how the design is connected with the analysis and the implementation.

We had some problems getting the design document done in time for the second review. The two weeks between the first and second review was very little time, and our work did became somewhat frantic as we worked to meet the deadline. The material we delivered was a result of this, and not finished at all. And due to this we continued working with the design for some time after this. The final changes in the design document did come later as a result of working with the implementation. We discovered there was some- thing, which could be done differently, and we choose to add the changes to the design document, to make it consistent to the program. We felt that the things in the documentation should reflect the finished program, but it must be pointed out that not everything in the design document has been implemented.

In this phase the work process was both co-operation and individual work. To ensure the work everybody did was adaptable with the rest of the project. The while designing the database we found minor problems with the struc- ture. We will explain the problems we had, and how we solved them, in section 13.3.

Later in the design phase we noticed something strange in the OOA&D method. In the application analysis the method deals with the user interface but neither the architecture design nor the component design to follow up on this work. This is somewhat puzzling because the work done in the analysis seems to be wasted, unless you use another design method to create the user interface. We decided to combine the OOA&D method with a method better suited for graphical user interface design explained in the DEIB course.

13.2

User interface

In this section we will discuss the different problems we encountered as well as our experiences and the decisions we made, involving the work with user interfaces.

Warehouse and web shop GUI

The analysis made it clear that there was two kinds of requirements for the system, so we had to design the GUI according to these. The warehouse GUI had to be a professional tool, which should enable the user to quickly get the

task done, with a minimum of effort and concentration. The web shop GUI had a different purpose, to sell products. We decided that a website designed to e-commerce, should be visually interesting, but not be an interference in solving the task, and not an annoyance.

we had early on some design suggestions to how the user interface should look like. One of the members form the group made a sketch of how the user interface could look like, on a computer using the paint program Photoshop. The Sketch had so many details that the rest of the group desired to use i as a reference point as to how the user interface approximately should look like.

To that end we decide, based on the DEIB lectures, to set up some design rules for the interface. Here are an explanation of how and why we choose these rules.

Gestalt Laws

We decided to use the Gestalt laws of perceptual organization when we first heard of them during a DEIB lecture. The reason why we wanted to work with it, was that we would like the information on the user interface to be understood by the end users without any misunderstandings. We meant the Gestalt laws could be helpful in meeting this goal. We utilized the Gestalt most heavily on the design of the web shop, because we chose to test this in a usability test.

We had some difficulties finding appropriate literature which concerned the subject, as the library did not have the books we looked for and the librari- ans looked baffled when we asked for books or articles concerning the Gestalt laws. But in the end the library found a book we could use.

During the design we tried to keep the Gestalt principle in mind, which meant that we tried to make related objects stand out and be identifiable as being part of the same group.

A downside working with the Gestalt laws was that the five principles merge with one another and as a result made it difficult for us to work with. On the other hand it did make sense in the project to focus on some regula- tions on the design in order to make an user oriented user interface. Therefore using the Gestalt law of perceptual organization makes sense, as the Gestalt

laws set up rules to do just that.

Colors and text

In order to make an user interface, which helps getting information across and support the systems purpose, sales system, we came up with an idea of looking at how these two areas could be utilized. The idea came as a result of a brainstorm, which came about because we wanted to focus more on the user interface, and wanted to explore these two areas.

We decided to set up some design rules concerning use of colors and text. These rules apply for the design of the warehouse GUI as well as the web shop GUI. However, the use of colors where going to be used most prominently in the web shop user interface. We estimated the use of colors could benefit the sales environment and help set up the web shop as both a conservative and reliable business, which would do little good in the warehouse GUI where customer attraction means nothing.

The choice of which font type to use was based partly on the fact that we, the designers, liked it and partly because of guidelines we found on the web. During the test we did ask the participant to evaluate the colors on the site, to make sure the web shop had colors which suited the websites purpose. The result is shown in 12.1.

Frames

Another thing we did as part of the focus on the user interface of the system was to work thoroughly with designing frames. as we meant we by focusing on how the implemented interface should look like would be able to better understand and visualize the user interface early on in the process. We be- lieved we would get a tool which would be valuable in setting up how the website should be designed.

All of us already had some experience working with frames, we had worked with HTML before, and this had some influence in us choosing to work with frames in the project.

We had some problems with frames, as the page location bar and the shop- ping cart did not update automatically. This problem had to be resolve by

making java scripts. We believe this should not be a problem, if the HTML interface was made on one single page.

Wisdom

Because we focused on the GUI, we choose to use the wisdom method taught to us in the DIEB lecture. The wisdom method was a tool when designing user interfaces, it gave us a general course to take, from the use cases to finding out what information the different screens should contain and which functions they should handle. After this the only thing to do was to decide how the actual GUI frames and windows should look. Because we did not have a lot of time, we only did two essential use cases. Further more we were told at the first review only to make on use cases, ass making more would be to much work. The two use cases are however the most central ones in the whole system. The use cases we choose were “Process order” and “Place order”. Process order because this is the central use case for the employee and therefore it must function properly, and Place order because it is very central to the system that the user has no problems when placing an order. We began making use case diagrams for the two. We had to make interaction models, but we ran into some problems, as we had no idea how to actually make them, and the examples we had from DEIB, consisted of a lot of useless information. Some members missed a couple of work days trying to figure out what to do, but after a meeting with a teacher we knew what we had to do, and the process went fairly fast.

As we made the dialog models ran we into another problem with the “place order” use case. We wanted to give the user of the system a lot of options, so he/she can cancel what he/she does when he/she wants, and also have other optional choices. However, the notation we used, does not fit particularly well for this kind of use case and we are not sure if the dialog model is absolutely correct. Out of these diagrams we made interaction space models on which we based the design of the GUI. We could not do this for the whole system so we had to go with what we felt was right, and by using our Design rules.

13.3

Database design

At the very start of the project we decided to store our data in some kind of a SQL database. The reason we used MySQL database, was because some of the group members knew it from personal web development projects.

When designing the database we had some problems with circularizes in our design, which we could not work around. We were afraid there would be problems inserting data, but we found out that because our entities are not mutually depending of one another, and the tests we made did not show any errors, the database system could be used. We know that the database is not designed perfectly, however database design and persistence is not part of our focus area.

As we implemented the database, we created and dropped both databases and a lot of tables, as we designed and redesigned. During so, we learnt that the MySQL syntax and SQL are definitely not the same thing. Not all SQL commands works in MySQL. It may have been the MySQL version 4.1.7 we used, but many commands, which should have worked, did not. As an example the ALTER query did not work as expected. We could not use the alter command to change foreign or primary key, but it did work when used with any other attributes.

We discovered that any changes made in the design which involved foreign keys, would result in us dropping one or more tables. The reason we decided to implement the database while still working on the design was that we could see if our design actually worked or not.

To make sure our database could handle a situation where data was deleted or updated the ON DELETE CASCADE and ON UPDATE CASADE, com- mands were used. This was done to make sure that if data was updated or deleted in one table, data in other tables with a foreign key to the first table would be either updated or deleted.

The ER-diagram at figure 8 shows that the delivery details, represented as attributes starting with “delivery”, were not existing in the early design of the database.

13.4

Implementation

Our implementation phase started out pretty well and we got our model classes and a basic warehouse client GUI made fast. We decided to divide the implementation out between the members of the group, so some worked with the database, some with the warehouse server, and others with the clients. Minor problems occurred with that but the problem that kept re-

turning all the way through the implementation phase were design changes and errors. A lot of time were used to “fix” minor changes, that sometimes grew into bigger problems.

The decision about using RMI for our network functionality proved to be an good idea since it was very easy to implement into our system. More ad- vanced functions like a callback between the clients were left out though, since we did not have any courses in distributed programming, and not enough time to study it further.

The web shop were made with JSP and acts like a client on the warehouse server, sharing methods with the ’warehouse client’. We had some problems setting up the servers to run JSP and a RMI and we ended up with using java version 1.5 instead of the advised version 1.4.

Sadly the system became really hard to install on every platform we tried it on, The user need a web server, a jsp server, and registries for the RMI and java installed and setup and that is not easy for most people to do.

13.5

Test

Usability test

We decided to use Jeffrey Rubins book [13], as a guide to making the usabil- ity test. To do so we decided we wanted to make profiles of the participants, and therefore made a background questionnaire. The qustionnarie should provide us with information about whether the participants had prior exspe- rience with a web shop. the demografically

At the day of the test, we had invited the first test participants to come at around 14.00 and the next participant to come half an hour later and so on. We just had enough time, in the test lab, to make a pilot test in order to make sure no major mistakes would occur.

The test went rather smoothly, but we did encounter a few glitches along the way. TP3 encountered an SQL error, which he could mot recover from without outside help. The test monitor which could not see the server, also had to be helped in order to get on with the test. The interference did not seem to ruined anybodys consentration and the rest of the rest of the test

went as it should.

To avoid the test participants were to nervous, we showed them what was on the other side of the one side mirror. We did this to make them more confidence about the whole situation.

The group had an positive experience with the test. The one who had not tried conducting a test before, could see . The data which we got from the test was immense and gave us a good understanding of the things in the system which should be change and which worked as intended. On the down side we may have found more usability errors if we had tested more people, but we decided that we did not have time to analyze more data. We made the decision that some of us would be responsible of analyzing the data, and make a recommendation based on the test.