Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Flattening Definitions of an Object-Oriented Application

IP.com Disclosure Number: IPCOM000105267D
Original Publication Date: 1993-Jul-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 122K

Publishing Venue

IBM

Related People

Merrick, TE: AUTHOR [+2]

Abstract

Disclosed with this bulletin are programs which maintain "flattened" lists of all ancestors and all inherited features with the Application Model &lbri.*]. These lists are maintained for each class in the application. As a new class is added, the lists for its parents are copied, consolidated, and updated with information defined for the new class to provide the flattened inheritance and feature lists for the new class. These lists are stored in a relational database (DB2) to allow persistence and ad hoc query capability.

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

Flattening Definitions of an Object-Oriented Application

      Disclosed with this bulletin are programs which maintain
"flattened" lists of all ancestors and all inherited features with
the Application Model &lbri.*].  These lists are maintained for each
class in the application.  As a new class is added, the lists for its
parents are copied, consolidated, and updated with information
defined for the new class to provide the flattened inheritance and
feature lists for the new class.  These lists are stored in a
relational database (DB2) to allow persistence and ad hoc query
capability.

      Flattened Feature Relationships are essential elements of the
invention.

1.  The following attributes are added to the description of features
    in the Application Model to support flattened feature
    relationships:

    a.  Class identifier of the originating class

    b.  Class identifier of class inherited from

    c.  Class identifier of last implementing class

    d.  Feature original name

    e.  Inheritance order

2.  The following verification and processing rules apply in addition
    to rules already defined for features in the Application Model.

1.  Inheritance cannot be added or deleted if the current class has
    children.

2.  As a new parent is added, all the flattened features for that
    parent are copied down.  Each entry receives preliminary update
    as follows:

1.  Class identifier and class number are set to the current class.

2.  Class inherited from is set to the parent class.

3.  The order of inheritance (of the new parent in relationship to
    other parents of the current class) and the order of the feature
    in the parent's frame are used to calculate the order of the
    flattened feature in the frame of the current class.  This is
    reflected in the sequence number assigned to the copied feature.

4.  The new flattened feature relationships are in development
    status.

5.  This defines the candidate flattened feature.  A verification
    must now be performed to determine if the name of any of the
    candidate flattened features matches the name of a direct or
    flattened feature of the current class.  This is true if there is
    an existing direct or flattened feature which satisfies all of
    the following:

1.  It is effective in development status.
2.  It is attached to the current class
3.  Its name is the same as the candidate flattened feature.

      This will be referred to as the "conflicting feature."  In this
case, the  current  class needs to rename (and possibly redefine) the
candidate flattened feature.

1.  If the class inherited from of the conflicting feature is the
    current class, it will now be treated as a potential redefinition
    of the candidate flattened feature.  The following verifications
    apply:  ol compact.
2.  The TYPE of the conflicting feature must be compati...