Book a Demo

Author Topic: Links from Operations to «table»s  (Read 6012 times)

Thomas Mercer-Hursh

  • EA User
  • **
  • Posts: 386
  • Karma: +0/-0
  • Computing Integrity
    • View Profile
Links from Operations to «table»s
« on: June 14, 2007, 11:07:37 am »
I am working on a profile for modeling existing Progress ABL code in UML.  While modern ABL programs can be written in OO, the historical legacy systems which are most likely to need modeling for analysis purposes are not OO.  One of the characteristics on finds in this legacy code is that it is common to have a single compile unit which contains a number of separate entry points and the entry points may or may not have a lot to do with one another.  E.g., they may be a collection of utility processes that are either widely used or are used by a particular group of other programs.  Thus, one can instantiate the compile unit persistently and execute the individual entry points as needed.  It is also good practice in this code to tightly scope any database access to the individual entry point, i.e., it is a property of the code associated with that entry point, not the collection as a whole.

Since it appears to me that one cannot link an Operation to a Class (i.e., a «table»), it seems to me that I need to model each individual entry point as its own Class in order to have the Code to Data links represented.  Similarly, only by making the individual code block its own Class can I link to other Classes, i.e., either other entire compile units or  other entry points in the same or other persistent instances.

This seems to imply that the only appropriate way to group the collection of entry points together into a single compile unit is to make them a part of a Package.

Agree?  Disagree?  Other approaches?