Re: [cme-dev] Towards use cases for Conman loaders

[Vincent Kruskal <kruskal@xxxxxxxxxx>]

The red
got stripped off somewhere.

Regards -- Vincent

Harold Ossher/Watson/IBM@IBMUS
Sent by: cme-dev-admin@xxxxxxxxxxx

06/24/2004 05:54 PM

Please respond to
cme-dev

To	cme-dev@xxxxxxxxxxx
cc
Subject	Re: [cme-dev] Towards use cases for Conman loaders

Stan,

Wow, there's a lot of interesting stuff here. As you say, the space is
large and we'll need to pick some key points. I've added some notes below
in red  that suggest enlargements, without the implication that they
should
be included in the points chosen in the end.

- Harold



                    
                     
                     
          
             Stan        
                     
                     
     
             Sutton/Watson/IBM    
                     
                  
             @IBMUS      
                     
                     
  To 
             Sent by:      
           cme-dev@xxxxxxxxxxx    
            
             cme-dev-admin@ecl    
                     
               cc 
             ipse.org      
           Stan Sutton/Watson/IBM@IBMUS  
     
                    
                     
                     
  Subject 
                    
                  [cme-dev]
Towards use cases for     
             06/22/2004 05:58    
     Conman loaders            
         
             PM        
                     
                     
       
                    
                     
                     
          
                    
                     
                     
          
             Please respond to    
                     
                  
                  cme-dev
                     
                     
     
                    
                     
                     
          
                    
                     
                     
          





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:

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

   All of the source model (or the corresponding binary model)
   The upper levels of the source model
   Certain types of elements (entirely or just the upper levels)
   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

   Load all of the children to their ultimate depth
   Load the immediate children
   Load the children of some particular type (or possibly a "working
set"
   of types)
   Load the children down to a certain descendent type (e.g., Java
project
   to Java packages)
   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

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

Presumably loading can be either eager or lazy, as noted later in the
document. If the user asks to load some amount of material, it can actually
be done lazily as needed, as long as it is never missed.

When a user executes a query, including following a relationship, the query
might conceptually extend beyond elements already loaded, introducing
various options:
   Look only in loaded elements (including those that remain to be
loaded
   lazily; the query results should not depend on what the loader
has
   happened to load so far)
   Warn the user that loading other elements will expand the result
of the
   query, and ask what to do
   Automatically load more elements. This should not be confined to
the
   results needed for the query, or the concern model contents will
depend
   on the query history. But a query could cause the loaders to load
   (perhaps lazily) further levels of detail. Possbily warn the user
if
   this will take a long time.

I think the same sorts of criteria that apply to substructure also apply
to
related elements. If an element is loaded, relationships from it can be
determined, and there are similar questions about how to handle their
targets, from not loading them at all (ignore the relationships or create
stubs, as options), to full transitive closure. A related issue is how
to
handle dangling references, where the target cannot be found.

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? I agree. The user
might
   select kinds of artifacts to load or relationships to compute,
as you
   noted above, but by artifact/relationship designation, not loader.
(On
   the other hand, perhaps sophisticated users might configure the
system
   with a particular loader/analyser they know abuot, and want to
be able
   to turn it on and off).
   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.

Incremental update and its attendant support are likely to be important
to
tool builders, and they'll need an interface to it.

I also wonder about the notion of "transient" concern model elements
(because I use them currently for methoids). These are real elements,
perhaps computed to show query results, but they behave like they are not
there for certain kinds of access and iteration (so the fact that some
of
them have been created to show some query result doesn't really alter the
model itself). I'm not sure how good an idea this is, but creating units
for all methoids is not an option, so this sort of requirement must be
handled somehow.

Generic Loader Actions

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

   Load a complete model beginning at the root element (e.g., an Eclipse
   workspace)
   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)
         Would it be possible to characterize these
in terms of the
         resulting model, rather than the sourc artifacts?
Similarly some
         of the others?
         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:
               Create a loader (may
need to be done very differently
               depending especially
on the type of domain model to be
               loaded)
               Register a loader for
a particular kind of artifact
               Find a loader
               For a given element
               For a given type of element
               Satisfying various properties
               Find the loader that
loaded a given element
               Record the loader that
loaded a given element
               Control the number or
type of loaders used to load a given
               element
               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:
               Up
               Down
               Neither
               Both

            Extent of load: Similar for related
elements (or treat
            containment as a relationship
and do this for related
            elements). Is something like
"detail level" a useful
            abstraction here? I vaguely remember
our coming up with some
            useful levels that made sense
across different kinds of
            artifacts.
               Fixed (at whatever)
               Specified by number of
levels (regardless of kind of
               element)
               Specified by kind(s)
of element
               Immediate
               Transitive (i.e., to
a specified kind of element, including
               intermediate elements)

            Means of loader selection:
               Specified by instance
               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
Does one of these include
               isApplicable?
                  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):
                  One
                  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:
                  Load a new
element only if an existing element is not
                  found
                  Load a new
element even if an existing element is found
                  Replacing
the found element
                  "Supplementing"
the found element

               And I'm sure there are
others.



_______________________________________________
cme-dev mailing list
cme-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cme-dev