DataMuseum.dk

top - metrics - download

    Length: 3105 (0xc21)
    Types: TextFile
    Names: »INSTRUCTOR_NOTES«

└─⟦180fe333a⟧ Bits:30000405 8mm tape, Rational 1000, SW CATALOG, 10_20_0
└─⟦180fe333a⟧ Bits:30000537 8mm tape, Rational 1000, SW Catalog 10_20_0
    └─⟦5cb1d1d7f⟧ »DATA« 
        └─⟦3b1ee7bd8⟧ 
            └─⟦this⟧ 

TextFile

The objective of this Level II problem is to get the student to start
to realize the value of abstraction.  In particular the value of
an interface that upper level procedures (the report procedure for example)
can code against without having to understand the internal data structures
or the implementation.

A candidate for this problem should either have a fairly good grounding in
Ada or completed one of the Level 1 problems.  You should encourage your
student to utilize the interfaces in !tools to the largest extent
possible.

Encourage them to think about the kinds of information that an accounting
report should provide.  You might also encourage them to investigate
accumulating other data such as disk utilization and printer usage and
as a follow-on add this to their report.  You should definitely get them
to try at least one of the suggested enhancements described in the 
specification of the Report procedure.  The one that is the easiest is
the one involving directory tools.  You might go through the packages
Object and Naming with them. Specifically :

     type object.handle;

     type Object.iterator;

     function naming.resolution (...) return object.iterator;
     -- you can give a wildcard name to this function and it
     -- will return an iterator contains all object that match it.
     
They will likely need Calendar and time_utilities for the time calculations.
They should probably use either the Set_Generic or List_Generic to
implement the iterator although it is useful to implement it with access
types at least once.  It would be best to use the table_formatter for the
report function.  You may want to encourage another intermeditate interface
that helps to total up entries or actually make an upward compatible addition
to the Job_accounting package to total two entries and return their sum.

It is probably best to let them start on their own with the agreement that
they come back at the end of the day at the latest.  This will give them
the opportunity to make discoveries but not spend too much time reinventing
things that they don't find.

When they have completed the Job_accounting problem, ask them to
sketch out a plan for the report package.  The right solution is
probably to use an intermediate interface such as Report_Data.  You
should first give them an opportunity to invent such an interface on
their own, then introduce this one to them as a possibility.  Make
sure that you drive home the idea of abstraction here.  Ask them, for
example, if they could write the report from the information provided
in Report_Data.  Ask them if another person in the team could
implement the Report_Data package without giving them any more
information than what is in the Spec of Report_Data.  Return to
the Job_accounting interface and see the same idea used there.


There exists a correct solution for the job accounting interface, but
none for the Report interface as yet.  The most creative solutions of
our students will migrate in as our best solution.  You should give
the student this solution when they are done and discuss it with them.