Browse Prior Art Database

Object-Oriented Calendar Scheduling

IP.com Disclosure Number: IPCOM000120862D
Original Publication Date: 1991-Jun-01
Included in the Prior Art Database: 2005-Apr-02
Document File: 3 page(s) / 149K

Publishing Venue

IBM

Related People

Baber, RL: AUTHOR

Abstract

This article describes a structure for design and development of OfficeVision*/2 (OV/2) Calendar scheduling with provisions for future extensions that build on present function.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Object-Oriented Calendar Scheduling

      This article describes a structure for design and
development of OfficeVision*/2 (OV/2) Calendar scheduling with
provisions for future extensions that build on present function.

      Customers have delivered a long list of requirements for
Calendar scheduling function.  Indeed, some have made a subset of the
requirements a prerequisite for becoming OV customers.  The number of
functions on the full list of requirements make the design of a
Calendar component to deliver on these requests a daunting task.
Addition of new function would require knowledge of previously
existing code if a monolithic view of the application is taken.
Management of the software development of such a component, to run
across/between all OS/2* platforms, would be extremely complex.
Also, many of the functions requested may be applicable to other
components and code implementing them should be available for their
use.

      Divide scheduling requirements by function.  Each function may
be designed and developed separately, with appropriate APIs.
Conceptually, these functions become reusable 'objects', with clearly
defined interfaces in the form of APIs.  Most importantly, such
objects are available for reuse by applications other than Calendar
scheduling. In addition, function may be added incrementally without
disturbing the system design.  (See Figs. 1 and 2, graffiles calndr0
and calndr1, respectively.)
Tool Objects:

      Function objects which are the most generic in use are classed
as 'tool objects'.  These may already exist, being developed for
applications other than calendar scheduling, or may be developed to
meet calendar requirements with potential use outside this scope.
Coordinator Object:

      What emerges is a model of many separate processes (tool
objects) which execute independently of one another. For any
meaningful scheduling work to occur the tool objects must be
coordinated by a 'higher power', a parent object which has knowledge
of the pro...