[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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.
