Bus, Plane, Train classes
The classes that describe public transports bus, plane, and train, they all are children of class TransportInfo and hence they inherit the parent’s virtual methods. This includes the methods: of ISerializable getType(), serialize() and deserialize(); of IEmissionable: calculateFuelConsumption() and calculateEmissions(); ICloneable: clone(). All of them will be present in these classes as well as their specific private fields such as number of cars and passengers for each car in Train:
Figure 2.9 - Train class design
fuel efficiency of Bus:
Figure 2.10 - Bus class design
and fuel consumption per kilometer and flight number of Plane:
Figure 2.11 - Plane class design
Data storing. Transport schedule class
Moving towards our key task – creating the ‘database’ class where each transport will be stored and accessed. There can be multiple designs of the requirements, but we will focus on the exact one that is, in my opinion, the most efficient, maintainable, and generic. First, we must understand what the type of connections we will use in our system: rather it a composition, dependency, aggregation, or association. It was decided that using aggregation is the most efficient and comprehensible way to represent our program.
TrainSchedule class. This class should store TransportInfo objects as pointers, but having internal fields like size, capacity etc. does not make sense because these are not connected to schedule in any way, hence define a separate container class with TransportInfo objects in it. Moreover, the TrainSchedule should have some kind of user interface(UI).
Figure 2.12 - Design of the class that stores the data about transport
Route representation. The task is to find the shortest route from one point to another and so we must define routes as an objects of the system. The route is defined by its starting and ending point, possible transfers, total fee, and time.
Figure 2.13 - Design of the class that stores the data about transport
Array of pointers. Container class.
As it was stated in the previous paragraph the PtrArray class will store such fields: capacity, size, and pointer at the collection of pointers of T type objects. The container should meet these requirements: emplacing back an object, erasing the object at arbitrary position, getting size of the container, clearing the whole container, being able to be used in for-each loops. For these purposes we must define iterator class which meets the ‘Iterator Concepts’[2] to work properly with STL containers. As we said already objects used in this container must implement ICloneable interface, so template only an object that inherits ICloneable.
Figure 2.14 - Container to store TransportInfo objects
Iterator for PtrArray. An iterator is an object that points to an element inside a container[2]. Like a pointer, an iterator can be used to access the element it points to and can be moved through the content of the container. Concretely, an iterator is a simple class that provides a bunch of operators: increment ‘++’, dereference ‘*’ and few others which make it very similar to a pointer and the arithmetic operations we can perform on it. In fact, iterators are a generalization of pointers, which are often used as a foundation when writing the iterator itself. It has its own hierarchy and can be diverse types.
Figure 2.15 - Iterators hierarchy in C++
As can be seen on figure 2.15, iterators vary according to its direction of moving and type of operations. For our container we will definitely need random access iterators because we will use algorithms of C++ Standard Library which requires implementing the dereference *, pointer dereference -> operator, increment ++ and decrement -- operators, addition + and subtraction - operators, difference - operator.
Figure 2.16 - Iterator’s approximate design
Summary. After all the above considerations we can now connect all the boxes and merge them into one general UML-diagram to represent our system. Describing relationships between classes.
Figure 2.17 - Complete diagram of ‘Transport schedule’ system
The used relationships explanation.
The Clock class inherits Time class, so generalization is used.
StationInfo stores Clocks as a field, but at the same Clocks’ lifetime does not depend on the lifetime of the StationInfo, it can exist independently hence we connect with aggregation. And so, with Coordinates.
TransportInfo uses aggregation to connect StationInfo and association to connect TransportType because TransportInfo class simply uses this enumeration. Interface realization arrow to connect ISerializable, IEmissionable and ICloneable with TransportInfo.
Generalization for Train, Bus, Plain to TransportInfo
Dependency between three above classes and TransportArray because the last one stores them as pointers. Also, TransportArray ‘has a’ iterator class and the lifetime of the one depends on the first, so obviously direct association is used.
The last TransportSchedule. The existence of TransportArray depends on the class so aggregation is used. And Route is only used in class but not stored, so association.