Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Fw: [cme-dev] Towards use cases for Conman loaders

On Fri, 2004-06-25 at 20:44, Harold Ossher wrote:

<snip>
> 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.

Dangling references suck. ;-)
Most of the time I encounter them is when the query I defined is
"bigger" than the concern model I have (and yes, this is a somewhat
different level of abstraction than the loader level).
In my use cases, I deal with them by either ignoring them (and
documenting that) or expanding the model to successfully complete the
reference resolution.
Ignoring them more often than not bites me later, so I would opt for an
expansion of the model / classpath / path of objects to be referenced,
etc.


>    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).>

I can only compare that to the role editors play in Eclipse... while I
have certain editors configured to open certain file types, there are
regular cases where a different editor solves a specific issue better
than another and so I want to be able to configure the editor I use...
but I do not know many other users doing the same.


> <
> 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.
> >

Hmm... is "creating units for all methoids" not an option or is
"creating units for all used methoids" not an option?



>    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)

Merge a submodel into a more general model (adding a subtree)
Merge several submodels into a more general model (merging two subtrees
into 1 tree)


>             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.>

I do not know whether that is applicable here but when browsing a
concern model, I often us different detail levels to identify whether
there is a latent concern (or relationship) hidden somewhere (two
officially unrelated concerns converge in a class but do not converge on
the method level vs. two concerns converging on both levels).
I do not know whether that notion is useful on the level of loaders, but
I thought I'd mention it anyway.


I hope that helps somewhat.


	Juri


-----
"I saw _Lassie_. It took me four shows to figure out why the hairy kid
never spoke. I mean, he could roll over and all that, but did that
deserve a series?" -- the alien guy, in _Explorers_



Back to the top