Semantics of Envy Application (was Re: Envy's Prerequisite Graph) 
Author Message
 Semantics of Envy Application (was Re: Envy's Prerequisite Graph)


Quote:
(Leslie A Tyrrell) writes:
> Actually... I've been looking at Envy for some time now, and it seems to
> me that it is missing a few pieces.  For instance, the notion of
> "application" doesn't seem to fit well- to me it makes more sense to
> think of an Envy "application" as a kit, or collection of useful parts-
> while the things we try to stuff into "applications" ought to have been
> organized in a different manner, such as according to some scheme
involving
> "systems".  Seems to me that "kit" and "system" are orthogonal concepts-
> Envy should allow you to look at your repository both ways.

IMO, it does.  The application is a class-grouping mechanism that
can be used in both ways.  With experience and/or successive refinement
it is possible to arrive at a partitioning of classes into
applications which represent subsystems and which exhibit a high degree
of internal cohesion but a low degree of external coupling.

But then there are always groups of classes that exhibit a certain
affinity or similarity, but do not form an independent subsystem.
A typical example of this type of "toolkit" application is, say,
the subapplication UIBasicComponents, which is OTI's (re-) packaging
of ParcPlace's basic widget set.

Randy Stafford



Tue, 25 Nov 1997 03:00:00 GMT  
 Semantics of Envy Application (was Re: Envy's Prerequisite Graph)


|> (Leslie A Tyrrell) writes:
|>
|> > Actually... I've been looking at Envy for some time now, and it seems to
|> > me that it is missing a few pieces.  For instance, the notion of
|> > "application" doesn't seem to fit well- to me it makes more sense to
|> > think of an Envy "application" as a kit, or collection of useful parts-
|> > while the things we try to stuff into "applications" ought to have been
|> > organized in a different manner, such as according to some scheme
|> involving
|> > "systems".  Seems to me that "kit" and "system" are orthogonal concepts-
|> > Envy should allow you to look at your repository both ways.
|>
|> IMO, it does.  The application is a class-grouping mechanism that
|> can be used in both ways.  With experience and/or successive refinement
|> it is possible to arrive at a partitioning of classes into
|> applications which represent subsystems and which exhibit a high degree
|> of internal cohesion but a low degree of external coupling.
|>
|> But then there are always groups of classes that exhibit a certain
|> affinity or similarity, but do not form an independent subsystem.
|> A typical example of this type of "toolkit" application is, say,
|> the subapplication UIBasicComponents, which is OTI's (re-) packaging
|> of ParcPlace's basic widget set.

This is true... but-

Perhaps the thing that is bothering me most about using the Envy
"application" as a "system" is that I want, to the extent possible,
to be able to discuss the system independently of implementation and
versioning of components.

That is, the "system" is not expressed in terms of particular
implementations of its componenents- rather, the system and components
are themselves expressed according to a non-implementation-specific
specification language which is testable and which can be used to
automatically select implementation-specific components ( which have
been built and tested according to same such specs ) from the
repository.  It should not matter what "version" the implemented
component is- as long as it meets the same spec that is appearing
in the system.

This is not a new idea- you can do this sort of thing on paper.
You can get a better feel for what I'm after if you take a look at
Ed Berard's book, "Essays On Object-Oriented Software Engineering".
But, it would be nice to have version control of the system and
its specificaitons as well within the same development environment.

Current state-of-the-art ( ie, Envy ) is not able to do this.
Instead, as you point out, we create applications which have
implemented components and call those our systems.  This is the
primary difference between what I am wanting in "system"
management and what Envy is able to offer- my "system" is not
an implemented system, but rather a specification which is used
to select appropriate components from what I am calling "kits".

In essence, the specification language is "compiled" to implemented
components.

That's all I want.




Wed, 26 Nov 1997 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. Envy's Prerequisite Graph

2. Changes in ENVY/Manager R3.0 application prerequisites

3. ENVY Application file in to non-ENVY VisualWorks

4. ENVY Prerequisite Question

5. How exporting Parcels From Envy For Non-Envy

6. 3.0 + Envy -> 5i.X + Envy

7. ENVY: No Datasets in envy???

8. Non-Envy from Envy image, how?

9. Envy 1.43->Envy 3.01 core dumps

10. file-out from Envy image for use in non-envy image

11. Envy to Non-Envy Image Conversion?

12. ENVY: Unload applications

 

 
Powered by phpBB® Forum Software