1. First alternative is based on component separation found in Multical related papers.
According to this idea, we have two basic packages under tauzaman (by convention package names should be all lower-case) package; ucs and tadt. ucs (Uniform Calendric Support) package contains all classes related to calendar, property, field since they provide calendar services. On the other hand, tadt (Temporal Abstract Data Type) package contains low level classes, such as temporal data types and timestamp operations. So, although components inside these packages communicate with each other, we have the understanding of clusters.
Figure 1 shows overall package structure based on this idea.
Information on which sub-package contains which class is shown in Table 1.
Disadvantage of this structure is that package names such as ucs and tadt are hard to understand at first sight.
2. Second alternative is flattened version of first one. Here each component has a package name.
Under tauzaman package, we have calendar, calendricsystem, property, field, timestamp, temporaldatatypes.
Figure 2 shows overall package structure based on this idea.
Information on which sub-package contains which class is shown in Table 1.
Disadvantage of this structure may be that it is too flattened that there is no understanding of relations between them, at first sight. Another idea here in this structure is, placing timestamp package under temporaldatatypes package, since operations in timestamp are only called by classes in temporaldatatypes package. But when we choose flat idea, then there is no concrete gain doing so.
|
sub-package name |
contains |
| calendricsystem |
CalendricSystemManager, CalendricSystem, Epoch, Granularity along with package granularitylattice, which will provide services for building and maintaining a granularity lattice of calendars. And related exceptions |
| calendar |
Calendar, CalendarRepository, along with a package mapping (that contains a base mapping class, and two specialized classes; RegularMapping and IrregularMapping), which will keep granularity information of a calendar. And related exceptions |
| property |
PropertyManager, Property, Format, ImportFormat, FieldInfo, PropertyStackService. And related exceptions. |
| field |
FVManager, FVTable, FVFunction, Field, Fields. And related exceptions. |
| temporaldatatypes | Input, Output and temporal data types and related exceptions |
| timestamp | all low level operations |
| root package | tauZaman service classes, XMLParser, root tauZaman Exception, |
Table 1
Note: I chose to go with the second alternative (flat structure). My reasons may seem a little bit vague, nevertheless I think
none of the alternatives (or any other) is better than others.
1. Since there is no distinct advantage between alternatives, it is better to use a general way of structuring, which is
obviously the flat way.
2. Although clusters of ucs and tadt in the first alternative seems fine, for a user they don't make too much sense
since one has to be familiar with the history of tauzaman (multical, timeadt) to understand them.
3. The idea of packaging (or in general encapsulation) is to partition the components as isolated as possible, however,
even with the clusters there is an extensive communication between ucs and tadt. (even more in multical -due to
variable spans-). So, it is really hard to include one component into the other and make them self understandable,
and furthermore, although it seems convenient to include them in clusters, it may also confuse a user due to complexity
(or should I say "nature") of interactions.
4. History shows that multical is open to further developments and improvements, so, it might be appropriate to
use a flat structure to adjust to possible future changes easily.
As we tried to emphasize above, criteria of packaging the classes does not necessarily depend on interaction between classes in the same package. There are two examples; field and temporaldatatype packages
Fields and Field classes in field package has no interaction with other classes in the same package, however, they are closely related. Field, for example, keeps parsed values of variables in input strings or parsed values of Granules in output. And these values are converted to strings (or indexes) by using field value support classes in field package, such as FVTable, FVFunction. But again they are not directly related.
Input and Output classes are more related, then in classes in field package, with other classes in temporaldatatypes package. All of the temporal data types will call Input / Output to convert their timestamps to temporal constants or vice versa. Moreover, Input and Output are the only classes, which uses classes of field package (especially Field and Fields). However, still we can form a sub-package under temporaldatatypes, called io, and put Input, Output, Field, Fields classes into it. But I still prefer the current design of packages, especially because of the some of the reasons listed above.