Vision Design Methodology: Application Classes

Overview

A number of Abstract Classes have been defined to organize different components of your Vision class hierarchy. Abstract classes are not normally instantiated directly; instead they serve to organize a set of subclasses that share some basic behavior. Built-in abstract classes include Collection which is the superclass of List and TimeSeries and Ordinal which is the superclass of Number, Date, and String.

It is useful to have a basic hierarchy for your application classes as well. Several abstract classes have been defined to help organize application classes:

  • Entity
  • DataRecord
  • LinkRecord
  • Bridge
  • DataFeed
  • DBEntity

Most applications will interact with the database via Entity instances. The other classes are used to store data or manage navigations from an entity to other parts of the database.

The organization provided by these classes is intended to serve as a guideline that can be applied as appropriate. These classes are all defined in Vision and can therefore be modified and expanded as needed by the database designer.

Note:
Some of the classes referenced in this document were added to the Vision bootstrap database as part of release 5.9.4. If your installation was bootstrapped prior to this, you may need to define the following: 
  Entity createSubclass: "Support" ;
  Entity createSubclass: "Table" ;
  Object createSubclass: "Bridge" ;
  IncorporatorPrototype createSubclass: "DataFeed" ;

Entity Classes

The Entity class is a superclass of the classes whose instances represent real-world entities such as companies, products, and industries. Instances of the entity subclasses are named, often with several different aliases. Instances of the entity subclasses normally have one or more descriptive names in addition to a unique identifier. Instances of the entity subclasses are often referenced individually by name or as the value of a property of another entity instance. Almost all applications are designed to start with a specific entity or a set of entities.

Core entities in your application domain are normally defined as direct subclasses of Entity. In an investment management application, these entities could include: Company, Security, Account, and Broker. In a pharmaceutical application, these entities could include: Drug, Pharmacy, HealthPlan, and Doctor.

Entity classes represent objects that are named. Every entity subclass has a corresponding naming dictionary that allows you to reference specific instances by one or more identifiers. The properties name, shortName, sortCode, and numericCode are defined for the class. Initially these properties are all set to the value of code; you can modify any or all of these values as needed.

The Classification Class

The class Classification has been defined as an abstract subclass of Entity to organize subclasses which are used for grouping and summarization purposes. This class is included with all Vision installations. Instances of Classification subclasses are normally referenced by other Entity instances. For example, the property region could be define for the class Company to return an instance of the Region class representing the region in which the company is based and the property industry could be defined to return an instance of the class Industry representing the company's major industry.

Instances of many classification subclasses are often managed as a hierarchy. For example, Industry 123 may refer to "Book Publishing", Industry 120 may refer to "General Publishing", and Industry 100 may refer to "General Media". The Classification class provides protocol to link these instances into a hierarchical structure.

Support and Table Classes

Two additional abstract subclasses, Support and Table are recommended for organizing classes that require objects that are individually named that are not really core entities in the application. Note that these classes may need to be added to your database if you want to use them. There is no special protocol that needs to be defined for these classes. They simply provide a way of organizing the entity subclasses so that the expression: 

  Entity showInheritance
neatly separates the core entity classes from miscellaneous support classes. For example, you could create a subclass of Table when you need a place to store descriptions for coded information.

The Currency Class

The class Currency is a subclass of Entity that is included as part of all Vision installations. This class is used to track exchange rate information between currencies. Instances of the class currency represent the currencies in which monetary transactions are performed such as "US Dollars" or "British Pounds".

The Universe Class

The class Universe is a subclass of Entity that is included as part of all installations. Instances of this class are used to name and track lists of related entities over time. For example, a Universe instance named SP500 could be defined to track the list of Security instances comprising the Standard & Poors 500 each month.

Data Records

The subclasses of DataRecord are used to manage sets of related information about a specific entity. These classes provide a way to organize data about an entity into manageable substructures.

For example, in an investment management application you need to track various pieces of pricing information for a security such as high, low, and closing price. You could define this protocol directly at the Security class including properties to hold the data values and methods for manipulating the values. Alternatively, you could define a subclass of DataRecord to manage this information and create a single property that can link a security instance to its pricing instances over time.

DataRecord instances are not usually accessed directly. An instance of a DataRecord subclass is normally accessed via a property defined at the entity instance with which it is associated. The createInstance: message for this class assumes you are supplying four values: the entity, a date, a value, and a base currency if applicable.

For example: 

  #-- Create price time series for Security class
  Entity createSubclass: "Security"
  Security define: 'price' ;

  #-- Create PriceRecord which tracks high, low, and close for a security
  DataRecord createSubclass: "PriceRecord" ;
  PriceRecord defineFixedProperty: 'high' ;
  PriceRecord defineFixedProperty: 'low' ;
  PriceRecord defineFixedProperty: 'close' ;

  #--  Update IBM's prices for several dates
  Security createInstance: "IBM" ;
  Named Security IBM 
  do: [ !newPrice <- ^global PriceRecord createInstance: ^self, 9601 .
            do: [ :high <- 101.25 ; :low <- 100.75 ; :close <- 101.00 ] ;
        :prices asOf: 9601 put: newPrice;
        !newPrice <- ^global PriceRecord createInstance: ^self, 9602 .
            do: [ :high <- 102.25 ; :low <- 100.75 ; :close <- 101.75 ] ;
        :prices asOf: 9602 put: newPrice;
      ] ;

 #-- Display the data
 Named Security IBM :prices
    do: [ ^date print: 15 ; high print ; close print ; low printNL ] ;

The subclasses of LinkRecord are used to manage information that symmetrically relates two or more entities. For example, in an investment application a holding describes a relationship between a specific security and account on a specific date. Properties of the class Holding could therefore include account, security, date, sharesOwned, and cost. A consumer products application could define a subclass of LinkRecord to manage sales transactions. Properties of the class SalesTransaction could include product, customer, and store as well as unitsSold and dollarValue. The values of the first three of these properties could be instances of the Entity subclasses Product, Customer and Store.

Instances of LinkRecord subclasses are not normally referenced directly. Subsets of LinkRecord instances are often cross-referenced at the entity classes with which they are associated. For example, the time series property holdings could be defined at the Entity subclass Account could to return the list of Holding instances associated with the specific account instance over time. The property salesTransactions at the Entity subclass Customer could be defined to return a list of the SalesTransaction instances associated with the specific customer instance.

Bridge Classes

The subclasses of the Bridge class are used to manage the protocol for connecting an entity to one more DataRecord instances. It is useful when there are complex relationships that need to be managed and you do not want to overburden the entity class with all the required information.

An instance of a Bridge subclass is normally referenced via the entity instance with which it is associated.

External Data Sets

The classes Data Feed and DataSet are subclasses of the abstract class IncorporatorPrototype with subclasses that represent data that is supplied via an external file or transfer. Each external feed maps to a specific subclass of DataFeed or DataSet. The instances of these subclasses correspond to the records or rows in the external feed. The properties of these subclasses correspond to the fields or columns in the external feed.

Instances of the DataFeed subclasses are normally used to create and update instances of Entity and DataRecord subclasses and are not normally accessed directly by applications once the data has been processed.

Unlike DataFeed classes which are not normally referenced even indirectly by other objects, subclasses of DataSet are used to store information which are an active part of the database. DataSet instances are normally access via an instance of the DBEntity subclass, described below. Once the data from an external feed has been incorporated into a DataSet's instances, there is no logical difference between a DataSet and a DataRecord.

DBEntity Classes

Data from multiple sources is often managed within a single Vision database. This data is normally associated with instances of one or more entity subclasses. A specific source may not supply information for every instance in the related entity class. The source may also provide data for entities that do not have a corresponding entity instance. In this case, you may not want to lose the data; however, you do not necessarily want to manufacture new entity instances to house it.

The abstract class DBEntity has been defined to provide protocol for defining pseudo-entities that correspond to the set of instances tracked by a specific data source. Subclasses of this class are normally used to manage the links between core Entity instances and the actual data supplied by the data source. These subclasses are normally named LocalEntity and are defined in the object space associated with a particular data source. In the current Vision database bootstrap, this class is a direct subclass of Object. Based on its role, it should probably be viewed as a subclass of the Bridge class since it links a single Entity to one or more DataSet instances.

More information about the DBEntity model is available.

Related Topics