We've opted to make this documentation in HTML since we were asked to use an open standard. Since even open office document (e.g. .odt) do not provide an adequate amount of portability. The hint to use ascii was considered, but the expressiveness in this small character set is quite limited.
Besides trying to adhere to open standards as much as possible (HTML and SVG as W3C standards) we used open source software almost exclusively (NetBeans, kubuntu linux, inkscape (SVG), quanta (HTML editor)). SVGs (XML source code files) are available in the subfolder 'img/'.
We will show the structure of the class diagram in its entirety (The Big Picture), and after that in a step-by-step fashion. Each time a part of the diagram is highlighted.
The first image shows the generalization of some attributes (date, numberOfDays, cancellationNoticeRequired, price). These attributes are common to flight, hotel and car reservations, so they were transfered to the more general superclass Reservation. Reservation is an abstract class, specifically, because it will never be instantiated itself (no instance will be made from it), only from those classes that are derived from it. Many methods/operations/functions will also be derived, but for simplicity's sake we did not include those in the model at this point.
Similarly in the second figure on the left, there are attributes and operations inherited from the more general "Service Provider" class. To have an flexible and extensible framework, and to be able to adapt to new customer requirements, it should be relatively easy to add new service providers and to start offering those. You could imagine theme parks, train reservations, museum entrance, etc. as being part of a package. Connecting to these 'service providers' would allow ACME to generate more value to its customers.
The products that are requested by the customer are placed in a package that he or she decides to buy at once. The buyer may not be the person making the trip (e.g. business trips may be bought by a company). We consider the 'customer' as the actor that makes the purchase. The service providers may have other names registered that can make use of the corresponding reservations. Each package is always bought by one, and only customer. A customer may buy more than one package. We decided to allow a customer to have no package. The status of customer and potential customer is not that different from a systems perspective. Promotional efforts should take into account the (absense of) previous purchases anyway.
The reservations (each of the more specific reservation classes) are contained in the package. The flight reservation is an exception in that there needs to be at least one flight in the package. Because the multiplicities of the subclasses differ, the agreggation relationship to package (package has n reservations) is in threefold. If this were not the case, the superclass could be contained and this relationship would also be inherited. A newly created package is created by the act of choosing a flight (with the option of adding other services (0..*)). There could be multiple flights, hotels and rental reservations in a single package. A customer can return and buy anther package at another time (0..*). Usually, if the order is not committed yet, you will change the package and not make an entirely new order (by creating a new package). We chose aggregation over composition because perhaps at some point a package may be cancelled, but the flight may still remain valid. ACME personel may transfer this reservation to another package. Aggregation allows for the life-cycle of that which is contained to differ from the containing object. This way, a new package could pointer to the existing reservation. It will not be garbage collected once the old package is removed.
The FlightReservation is a specialization of the (abstract) Reservation class mentioned earlier. Each flight reservation is linked to only one flight. If there are multiple flights (more seats) ordered by a customer, the package will contain two reservations, each of these linked to one flight (probably on the same airplane). A flight will have either no reservations or * reservations. When it is just scheduled and there are none, after that there can be a limited number of bookings (depending on the airplane capacity).
A flight is always linked to one airliner. This doesn't mean that only one organization flies, for example, from Amsterdam to London. It means that if there are two organizations that do this (British Airways and KLM) that they each have their own flight using the same unique route.
The lower part, links the route to the local airports. There is always a departure and arrival (not taking into account any disasters), this is the intended course of the route. It can also have (0..*) a stop, multiple stops or no intermediate stops.
We decided that you need a separate reservation for each stay. A stay is always a sequence of consequtive days so we can express it by using start date and amount of days only. An example: If a visit to New York is from monday to saturday, and the client wishes to stay in a hotel all days except wednesday, he need two reservations (monday-tuesday, thursday-saturday). We kept the reservation and the stay separate so there is some flexibility. If a room is not cleaned in time, the hotel could suggest a different one. The reservation would include a stated preference, but this could end up being a stay in a different room.
A group will stay in at least one room. But if they want multiple rooms, the system should accomodate for that (1..*). In the other direction, a room can have people staying there, or it can be available (or under maintenance, in the process of being cleane, etc.). The hotel has rooms, at least one (e.g. a small bed-n-breakfast accommodation), each room is owned/managed by at least and at most one organization (labels [1..*], [1] are not shown). A hotel could have multiple people staying there, or in some (exceptional) cases none at all ([0..*]).
The rental reservation system is structurally identical to the hotel system. A reserved car could be broken or need repairs, so the same flexibility is desirable.
This is the global view of the system. It contains 2 main use cases which are: make package proposal and buy/change package. The only actors are the client, the airlines, the vehicle rental companies, the hotels and the payment service provider. ACME is not a actor i.e. the client can, without interference of a employee of ACME, buy or change a package via the reservation system. The making of a package proposal and the buying/changing of a package are seperated because the possibility exists that a client will not buy a proposed package. But before the client can buy a package, the package has to be created. This is the reason why buy/change package includes the making of a packet proposal. The ACME system thus supports "shopping" clients, which is also the case in the real world.
If a client chooses to use the ACME reservation system, it enters their demands in the system (set out trip). Information like departure date and airport and return flight date are filled in. The system uses this information to gather offerings from the airlines, vehicle rental companies and hotels. When this information is gathered, the system will make a proposal containing the flight(organisation), the total costs and recommended vehicles and hotels. Of course, before a proposal can be made, the gathering of offerings and the entering of tripdetails has to be done. This implies a include relationship.
It could happen that a airline company has a delay or cancellation of a flight. In the latter, the system seeks the next best option for a flight. We assume that a departure and destinationairport and route will always exist; this implies only minor changes (hours, days in stead of a "disappeared" destination) to packages as a consequence of a delay or cancellation.
If the airlinecompany reports a change in the flightschedule, the ACME system calculates the new aspects of the trip (like departure and arrival date). With the new tripinformation the system will check if the existing reservations could be changed or, if not, new offerings from other companies will be gathered. Together, this new package proposal is send to the client. The client has the possibility to refuse the new offering.
The reservation system has the proposed package stored. The client is the initiator to accept the (new) proposal. To change a existing package the systems cancels the current reservations and makes new ones. In case of a new package the full amount of money will be charged via the Payment Service Provider. In case of a change, the discounted sum of money will be either charged or reimbursed. At the end of the line, the customer will be sent a itinerary. Of course, the three steps have to be fulfilled before a itinerary could be composed and sent, which implies the include relation.
The client enters the details of their desired travel plans (i.e. date, length of stay, departure and destination airports, number of travelers, etc.) into the web interface. The system then automatically searches for available flights offered by various airlines based on the route, time slots, prices, etc. specified by the customer. If there are no flights available per the customer's specifications the customer is notified accordingly and prompted to search for alternative flights. If there are flights available then hotel and car rental services are searched for availability for the specified dates. Hotel and car rental availability are requested independently as each service is offered independently of one another as customers may choose one and reject another. ACME's system send the customer preferences (dates, duration, location, etc.) to the vehicle rental companies and hotels. Once the hotel and rental availability information is received ACME will propose various packages (consisting of different flights, hotels and rental options) along with their respective prices.
For the activity diagram we chose an important external event that has to be dealt with accordingly. In this case, there's a change in the flight schedule. In some cases, this will result in the need to change the other services that are delivered. The system should decide when this is the case and accomodate when this happens. If there's no significant impact to the other services delivered, the customer should simply be notified and the activity's endnode is reached.
If it is a significant change, the optionally selected service providers are checked again. When they have an alternative this is used. Otherwise, a more broad service search is done including all available service providers that match the requirements. We assume in this case, that the conditions are the same for both the hotel and rental car service provider and that they both react respond the same. The checks are done in parallel.
After the package is updated or a new package is created, the customer is notified and asked to confirm it. He then recieves the new itinerary. If he doesn't agree, he might be elligible for a refund.
This concludes group 8's work on the modeling assignment.