[cme-dev] Towards use cases for Conman loaders

[Stan Sutton <suttons@xxxxxxxxxx>]

Hello All,

As part of the on-going effort to redesign
the Conman loaders I'd like to suggest some ideas for use cases involving
the loaders.  (As Peri has pointed out, this is past due, and I agree
with her--even though I am mainly to blame for the delay.  :-)  )

I am a novice at use-case specification,
but I hope the ideas listed below are a start in the right direction.  The
text actually includes three parts:  The first is suggestions for
use case scenarios (more specific for end users, more general--or vague--for
tool builders).  The second is lists of generic actions abstracted
from the scenarios.  The third is a list of some of the dimensions
of concern that apply to loader design.  Ultimately (I believe) we
want to pick some points in the concern space so as to implement a useful
set of capabilities, in support of actions, that will allow us to address
validated scenarios--although the idea is to drive this process top-down.

Comments and suggestions on any and
all of this are requested.  We need to validate the use cases in order
to firm up the requirements in order to complete a design in order to get
the loaders built!

Thanks in advance and regards,

Stan



Use-Case Scenarios for Loaders

We envision two kinds of users for the
CME, end users and tool builders.  Thus we can imagine two corresponding
sorts of use-case scenario.

End-User Scenarios

Some candidate scenarios:

1. The user opens a CME perspective and presses a button that initializes a concern model by loading (alternatively)

1. All of the source model
2. The upper levels of the source model
3. Certain types of elements (entirely or just the upper levels)
2. The user is exploring down into a model and opens an element for which the children have not been loaded (perhaps by just double-clicking it, perhaps by right clicking and selecting a option from a menu); the user may want to

1. Load all of the children to their ultimate depth
2. Load the immediate children
3. Load the children of some particular type (or possibly a "working set" of types)
4. Load the children down to a certain descendent type (e.g., Java project to Java packages)
3. The user has run a query resulting in the return of some elements that are the descendents of some other elements, say, a collection of methods; the user may then want to

1. Load the immediate container (e.g., the declaring type)
2. Load up to some kind of container (e.g., the top-level type or package)
3. Load all the way up to the top of the model
4. The user is interested in an element and asks to see (some or all of ) the relationships for that element
5. The user has a relationship for an element and wishes to navigate to one of the other elements involved in the relationship

Notes:

• It seems unlikely (at least to me) that an end user would be concerned with specific loaders or loader types, e.g., selecting a particular loader/loader type from a list of available loaders/loader types.  Actually, it seems unlikely that end users will be concerned with loaders at all.  Are there any prospective scenarios that would support the exposure of loaders to end users?
• These scenarios all involve loading.  There are other scenarios that would involve unloading, but we're not quite at the point where we're ready to discuss unloading yet

Tool-Builder Scenarios

I'm not entirely sure how to characterize
tool-builder scenarios, but certainly in the design of the loaders the
concerns of tool builders should be taken into account.  It seems
to me that one general way to characterize tool-builder scenarios is in
terms of problems to be solved, actions to be implemented, effects to be
achieved, and so on.

(Relative to a particular kind of tool
(or component) such as a Conman loader, it is also possible to characterize
tool-builder scenarios as to whether the tool builder is using loaders
to build some other tool, or whether the tool builder is building (adapting,
configuring, extending, maintaining) a loader itself (possibly based on
an existing loader).  Here I am focusing on the former kind of scenario:
 what might a tool builder want to do with a loader in the course
of developing components or tools that might involve concern-model loading.
 However, scenarios for loader-builders should also be considered
at some point.)

Given the above, at least one category
of tool-builder scenario might be characterized as "implement end-user
scenario X", where "X" is something like  "top-down
loading of a concern model" or "on-demand loading of element
children."  Full implementation of these scenarios will generally
involve the use not only of loaders but also of other Conman elements and
possibly of CME elements in general.  Note that the use of the loaders
may involve actions that a typical end-user would not generally see, such
as finding and invoking loaders.  These actions may also go beyond
those indicated in the standard loader interface (i.e., beyond testing
the applicability of a loader to an element and loading an element).

Thus, one sort of scenario for a tool
builder would be to find some mechanisms to effect the loader (and non-loader)
actions required to address an end-user scenario, and then to assemble
those mechanisms into a tool to support the end-user scenario.  The
resulting requirements on us would be to design loaders (and related components)
in such a way as to support tool builders in realizing such tool-building
scenarios.
 
I could attempt to outline some specific
tool-builder scenarios, but it seems to me that there might be many of
these, that is, more than one for each of the end-user scenarios listed
above, depending on alternative implementation strategies or requirements.
 It would be helpful if prospective CME tool builders could suggest
specific scenarios of interest.


Generic Loader Actions

 Considering the scenarios, we
can abstract some generic sorts of actions that might be generally useful
in a loader:

1. Load a complete model beginning at the root element (e.g., an Eclipse workspace)
2. Load a complete submodel, beginning at an intermediate element (e.g., load an Eclipse project or Java package)

• Note:  Equivalent to loading a particular element, including its children
• Load just a particular element, with no children or parents
• Load a particular element with its children down to some specified depth (e.g., load a Java project to depth 1, which might be package roots)
  • Note:  At one extreme this would accommodate loading to the complete depth of the element, which would be equivalent 2 above, as I see it
  • Load a particular element with its children of one or more specified types (e.g., load a type with methods and initializers)
  • Load a particular element with its children down to some specified type (e.g., load a project down to the level of top-level types)
    • Note:  As I think of it, this includes the loading of children intermediate to children of the specified type, but it excludes the loading of children that are not intermediate to children of the specified type (so, in the example, this would entail the loading of projects, package roots, packages, and types, but not the loading of non-package folders in the project, and not the loading of non-Java files in a package)
    • Load a particular element with its parent(s) to the root of the model (e.g., with a CIType load the CITypeSpace and CIUniverse)
    • Load a particular element with its parent(s) to one or more specified levels (e.g., load a CIMethod to height 2 (depth -2?), thereby also loading the CIType and CITypeSpace)
    • Load a particular element with its parent(s) of one or more specified types (e.g., load a Java type with its parent-as-package or its parent-as-folder)
      • Note:  I haven't really worked out the notion of multiple parents of different types; I just suggest it here for completeness.  There seem to be at least two ways to make sense of this notion:  1) there is a single parent element which can be viewed (or cast) as multiple kinds of thing (e.g., a directory might be a Folder might be Project might be a JavaProject); 2) there are multiple sets of containment (parent-child) relationships that apply to a particular element (i.e., the element exists in multidimensional space), and there are actually distinct elements of different types that might be considered as its parent (not sure that we have a good example of this yet, outside of Conman, though).
      • Load a particular element with its parents up to some specified type (e.g., load a CIMethod up to the containing CITypeSpace)
        • Note:  notes analogous to those for case 6 apply here
        The above actions are all varieties of "load"; in each of these cases the ability to test the applicability of a loader to one or more elements is also implied.
        
        There are a number of other generic sorts of actions, in addition to "load" and "isApplicableTo", that may also be useful for loaders.  These include:
        1. Create a loader (may need to be done very differently depending especially on the type of domain model to be loaded)
        2. Find a loader
        1. For a given element
        2. For a given type of element
        3. Satisfying various properties
        3. Find the loader that loaded a given element
        4. Record the loader that loaded a given element
        5. Control the number or type of loaders used to load a given element
        6. Control the invocation of loaders (e.g., eager versus lazy invocation strategies)
        
        I am sure that neither of the above lists is exhaustive and I welcome suggestions as to how they might be extended or adapted.
        
        
        Dimensions of Concern for Loader Design
        
        The above actions (especially the first group) are described mostly in terms of the direction and extent of loading.  Those represent two dimensions of concern in the characterization of loaders or loader behavior.  To avoid a combinatorial explosion, I neglected other dimensions when compiling that list.  Off the top of my head I can think of at least the following dimensions of concern for loader design:
        
        Direction of load:
        1. Up
        2. Down
        3. Neither
        4. Both
        
        Extent of load:
        1. Fixed (at whatever)
        2. Specified by number of levels (regardless of kind of element)
        3. Specified by kind(s) of element
        1. Immediate
        2. Transitive (i.e., to a specified kind of element, including intermediate elements)
        
        Means of loader selection:
        1. Specified by instance
        2. Specified by type
        • Note:  We don't yet have a formal notion of loader type; this case would be a special case of the following ...
        • Specified by criteria
        • Selected by some strategy
          • Note:  Not sure that there's a strict difference between selection criteria and selection strategies.  Selection by criteria might be one strategy for choosing a loader, but selection of first available would be another strategy (and that doesn't seem like a criterion to me)
          
          Number of loaders used (when loading a particular element):
          1. One
          2. Some
          • Note:  Under some analyses this might not be a distinct case, e.g., "some" of the loader in a collection might be "all" as selected according to some criterion
          • All
          
          Source domain:
          • Whatever source domains you might want, alone or in combination (e.g., CIT., Eclipse core resources, Eclipse JDT resources,  ...)
          
          Target range:
          • Whatever combinations of model elements and structure you might want
          
          Reuse versus reload:
          1. Load a new element only if an existing element is not found
          2. Load a new element even if an existing element is found
          1. Replacing the found element
          2. "Supplementing" the found element
          
          And I'm sure there are others.