Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Paolo F Cantoni

Pages: 1 ... 351 352 [353] 354 355 ... 403
Uml Process / Re: Thoughts about Collections
« on: October 25, 2005, 01:32:12 am »
Yes, I'm happy with your explanation on heterogeneous sets.  That's what I thought you were saying.  :)
OK Jim,

Now, lets look at Collections in general.

What are the features the most basic collection must have?

I've already alluded to two types of collections:
Associative (Maps, Hashes etc) and Non-Associative (Lists, Vectors etc).  

It seems to me that the Collection must have an Iterator.  Indexers and Enumerators are available depending upon the Collection type.

What Features should an Iterator implement?


Uml Process / Re: Thoughts about Collections
« on: October 24, 2005, 05:09:08 pm »

Everything made sense and I agree with everything  up to this point...
it may not need the same Attribute in each Item, but it must be there (and only one of) for the Enumerator to work.  
 I agree with what I think you said, but I'm not sure that what you think you said is what I think you said.  Can you fly a bit slower? ???
When I wrote it I thought it might be contentious.
I'm taking my cue from the discussion on Indexers.
It seems to me that in the simple case, homogeneous collection.  Every item has the same Attribute with the same name and the same Enumeration.  So there should be no problem applying the Enumerator.  OK?  (I think we agree on this).

Now, assume a heterogeneous collection where some items are as before and some items have no such Attribute and no such Enumeration (in any other attribute).  By definition those Items without the Enumeration can't be part of the subset.  This should be OK (from first principles)

Now, consider a third case, heterogeneous collection with some of the original Items and some others That have the same Enumeration but with a different name.  If we allow that Enumerators are defined by their signature, then the compiler can work out that this other Attribute can be used to select subset Items.

Are you happier with that?

Example, Collection of Items.  Some are Jelly Beans (Attribute: BeanColour:ConfectionColour) others are Liquorice All-Sorts (AllSortColour:ConfectionColour).

We can ask the question get me the green items and get both Jelly Beans and All-Sorts.

Now, most (if not all) languages don't (natively) support this idea.  But we are defining CIM related concepts here.

Besides, to paraphrase the old aphorism:  Define it and they will code. ;D


Uml Process / Re: Thoughts about Collections
« on: October 24, 2005, 02:34:10 pm »
I lost you here...

Does your use of the word type mean an object's classifier/data type or are you referring to the attribute values shared by members in a <<memberOf>> relationship?  I'm with you if the term is used in the latter sense. :)
Yes Jim,
I think it's the latter sense is what I'm meaning.  This is a bit of thinking on-the-fly...

Essentially, I'm trying to make a distinction between a name given to something (like Jim, Paolo, bruce etc) and some categorisation (Senior, Youth, Adult, Baby) for which I can ascribe an Enumeration.

I previously said, we should use Enumerator for Enumerations.  This requires that each Item in the Collection has the Attribute that is the Enumeration.

Now, I suspect that if the collection is mixed, it may not need the same Attribute in each Item, but it must be there (and only one of) for the Enumerator to work.

Make sense?  It is on-the-fly.


Uml Process / Re: Thoughts about Collections
« on: October 24, 2005, 12:52:28 am »
Sounds good to me!  ;) but for Enumerator I didn't ask for the peanut butter I asked for its location.
Good point Gunga Din...
Collection is: Items in the fridge (therefore Index is Item number)

Indexer: use this to retrieve the item numbers labeled "Peanut Butter"
Iterator: use this to iterate through the collection looking for items labelled "Peanut Butter" or of type Peanut_Butter (or both)
Enumerator: use this to return the subset of items of type Peanut_Butter

The Indexer uses some search strategy to locate the items (usually get me the nth item).
The Iterator uses a repetetive stepping through the items.
The Enumerator applies a filter to the list.

The Indexer and Enumerator are essentially declarative, the Iterator is essentially procedural.


Uml Process / Re: Thoughts about Collections
« on: October 23, 2005, 08:59:07 pm »
I think all three access items are necessary - at an abstract level...

Client: "Where's the peanut butter?"

Indexer: "On the middle shelf in the fridge"
Iterator: "Look at the contents of each shelf in the fridge until you find it."
Enumerator: "Remove and inspect each object in the fridge until you find one that's labelled peanut butter, then you'll know where it was"

Notice that i have ordered them by decreasing "power",  IOW the Indexer has a lot of power as it knows something about the collection (and the container), the Iterator knows something about the structure of the container but little about the collection, the Enumerator only knows
that the collection exists in the container.

There are probably lots of examples where the power structure could be different, but I hold that all are necessary.
Great Example!  But...  IMO

Indexer: "On the middle shelf in the fridge"
Iterator: "Look at the contents of each shelf in the fridge until you find it."
Enumerator: "These two items are peanut butter"

I think if we ensure that Enumerator applies only to Enumerations (Ordered Sets) then we can be rigorous.

We might say the Iterator knows nothing about the Item.  The Enumerator knows that the Item can be Enumerated and returns a subset of the collection.  I think (and this is a repetition of my point in the earlier post) that you can only apply an Enumerator to an Enumerable collection (that is, contains items that can be classified by a simple Enumeration).  It has been put to me that such an Enumerator is, by definition, a filter.  I think this is a reasonable proposition.

In C#, you can have string Indexers that would do the job of: Find me the item marked Peanut Butter.  Note, I said marked (or labelled).  In my view, the Enumerator knows the Type.


Uml Process / Re: Thoughts about Collections
« on: October 22, 2005, 06:52:59 pm »

I've put your original quote in Blue and my response in  Navy...
With regard to the terms Iterator, Enumerator, & Indexer and in the context of Collections, I have the following (personal & informal) thoughts and connotations attached to them:

A work in process...
  • All three terms relate to working with the Items in a Collection;
    [/color]For the purposes of the discussion I'm going to propose the following definitions:
    Iterate: To say or perform again; repeat  Thus Iterator: Something we use to repeatedly access the collection.  In particular, the process of moving from one item to the next is repeatable.
    Enumerate: To count off or name one by one; list  It's not clear to me what the difference is between an Enumerator an Iterator.  In this context.
    Index: To guide, point out, or otherwise facilitate reference  This would appear to be the ability to randomly access something.

    • All three differ in the degree of services they provide in maintaining the list of Items held by a Container;[/color]  Yes, in principle, but as I said above, there seems to be precious little difference between some - maybe we will be able to tease out sufficient difference
      • I suggest we select and define one of these terms for use at the CIM level; discarding the others.[/color]  I don't agree here.  we need to keep those terms which have meaning in the CIM
        • For me, Indexer carries too much baggage from the implementation level to be a good candidate.  I'd like to discard this term out of hand.[/color]  My feeling is that (taking the cue from C#) if we are able to access a collection as though it was an Array (conceptual of course!), then Indexer is a valid term.  In particular, if we choose to iterate through the Array using the Indexer, it doesn't stop it being an Indexer.
          • At the implementation level, Collections are held in a variety of structures (vectors, linked lists, binary trees, etc.). At the CIM level, we don't wish to concern ourselves with how the Items are held, but we don't want our definition to foreclose on any structural options.[/color]  Here I think you hit the nail squarely on the head!  What I'm trying to do with this thread (and by the sound of it so are you) is to determine which forms of collections have validity in the Conceptual domain and which are purely implementation mechanisms?  What transformations are possible between the conceptual collections and their implementations so that the implementation does not violate any contracts that are in place at the conceptual level?
            • I think the terms Iterator, Enumerator relate to the services provided by the container of a Collection.[/color]  I don't want to use the term Container (since I don't believe we've established that every Collection is a Container - only that every Container has a Collection), perhaps Collector (or Collection holonym).  I'd now add Indexer the list.
              • I can envision a variety of specialized container types.[/color]  Yes (but Collectors), as discussed above
                • Thus, I like the Java concept of declaring Iterators, Enumerators as an interface to a Collection.  ( Need to think a bit about the case of multiple collections held in one container.)[/color]  Yes.  Now getting back to Containers,  For the moment it might be useful to consider that every Container has a Collection.  That collection might be a Collection of Collections!  I have a container of jelly beans (of various colours).  I therefore have a Collection of jelly beans.  But do I also have a collection of black jelly beans (my favourite!).  I suspect I don't, unless I have separated them into their own bag within the original container.  Thoughts?
                  • I understand the underlying reasons, but, linguistically speaking, I don't like Java's movement from enumerator to iterator in order to enhance the services provided.[/color]  I agree.
                    • For me, Iterator connotes a form of repetition.  This relates then to flow of control within a process.[/color]  Agreed, see my comments above
                      • Enumerator connotes a presentation of things for whatever purpose I wish to apply to them.[/color]  I'm not so sure.  I didn't like using Enumerator for Collections since it has such a strong affinity with Enumerations.  Then I suddenly realised that an Enumeration is an Ordered Set!  In my view, Iterator should be the principle interface to any Collection.  If the Collection meets certain criteria (that is, can behave like an Enumeration), we can also use the Enumerator
                        • At the CIM level, I would cast my vote for Enumerator and I like the concept of it being an Interface (or a set of interface specializations);[/color]  See comments above
                          • I think of the Enumeration interface as being the prime feature of an object's role as a Container.  Perhaps later we can discuss, at the PSM level, adornments on the associations between the collection and its Items relating to the nature of the structure within which the items are organized?
                          • I would suggest that our definition of an Enumerator be broad enough to include control of Item access, Ordering and inclusion within the Collection.  By Ordering I mean specification of the basis for ordering access to the Items, not the fact that the items are Ordered within the association.[/color]  Can you clarify?
                            I offer this stream of consciousness simply as a set of discussion starting points.  Care to add your thoughts and/or comments?




Uml Process / Re: Thoughts about Collections
« on: October 21, 2005, 07:16:58 pm »
Assuming you have no further problem with Collection being the Member_Of meronymy, we can continue this (Collections) thread discussion the nature and properties of the various Collection types.
Go for it...

One thing where I think we might constructively start is on defining some terms in a (coding) language neutral way.

I've had trouble, in the past, getting a clear definition (with respect to collections) of the differences (if any) between :

  • Iterator
  • Enumerator
  • Indexer

Maybe we can start with that?

Also, while we are at it.  I think we should formally define that Collection meronyms are Items (not Elements etc)


Uml Process / Re: Thoughts about Collections
« on: October 21, 2005, 05:47:05 pm »
In another thread, Paolo asserted:
Collections collect (group) things
I'm not sure, but I don't think he was using the word group in the same way we do when discussing the <<memberOf>> meronymic relationship.

Jim, so you don't have to make any assumptions :):
I was using the noun  Collection: A group of objects or works to be seen, studied, or kept together.
and I was using the verb group: To place or arrange in a group
At least, I hope not, for I'm thinking that the term Collection is better reserved and used for a gathering of objects, in a simple association, which are not part of a meronymic relationship.
I think you have been offered the Eric Morecambe Gambit (Eric was a very famous British comedian - with his partner Ernie Wise):  "Get out of that - without moving!"
It seems to be you can't get a collection of things without a meronymic relation, since you automatically create a whole - the Collection.
However, I've seen in other texts that in order for two objects to be associated, messages must pass between them.  I kind of like that thought, but I can also visualize a vector of objects that do not intercommunicate that I might also call a collection (e.g.; things in a shopping cart).  Perhaps, this latter context, the vector is a container of objects that are not in a collection?  But then I must reconcile myself to another truthful assertion:
All containers define collections (even if only implicitly - the objects contained)
I seem to be caught in a Catch-22 with this.  Can anyone help me clarify this?
The message assertion is another example of how object modellers are constrained by their own language (as you concurred with the observation by my colleague Vince).

For two objects to be associated, someone/thing has to make the association.  The objects themselves never need know they are associated.  They can be associated by inference (derivation).  My brother (Luigi) is such, because he is also the son of both my mother and father.

Two objects that are associated may pass messages:
a) if they want to
b) if they can locate the associated object and their interface.

In neither case does this affect the association.

In the limiting case, the objects may be associated merely[/] because I have chosen (arbitrarily) to place them in the same collection (vector being a form of collection)

I once went to a talk on "Objects without Classes".  The presenter, a University lecturer, was going on about how his system merely created Objects and dynamically grouped them together using Attribute values.  So I asked him what he thought Classification was?  What is a Class but a collection (Classifier) of objects that share the same structure and behaviour?

What structure is the Collective whole we defined above?  A Classifier (in this case a Class).

I have previously expressed the view that Collection describes the Member_Of meronymy.  I still hold to that.

You appeared to have a problem with that.  Has my clarification resolved anything for you?

Assuming you have no further problem with Collection being the Member_Of meronymy, we can continue this (Collections) thread discussion the nature and properties of the various Collection types.


Uml Process / Re: Components and Interfaces
« on: September 19, 2005, 06:49:03 am »
Not sure I understand the question...
Do you mean nested in... similar to a nested class?
Well no not really,

Over the weekend, I refactored my view of a Component.  It is currently modelled in my UMLPlus XSD as a Classified Collection\Container with Interfaces.

As an Element, it can be nested in a variety of other Elements, as an Element it may nest other Elements.
As a Container it may contain other Elements (Physical Component).
As a Collection it may include other Elements (Logical Component).
As a Classifier it holds Classifier information.
As a Component it may (must?) have Interfaces.

My point was really that Interfaces can have "lives of their own" but a Component may provide or require an Interface (whether pre-existing or not).  Thus the determination of whether an Interface is a required or provided one is determined by its relationship to another element (in this case a Component) than any intrinsic aspect of the Interface itself.

Feedback invited...


Uml Process / Components and Interfaces
« on: September 16, 2005, 08:43:39 pm »
The topic: Composite vs Component
got me thinking about the way I emit Interfaces...

UML2 provides for a formal Interface Classifier.  When such a Classifier is defined stand alone, it seems to me it just IS...

When the Interface is attached (more like embedded in)  to a Component then it needs to be qualified as to whether it is a Required Interface, a Provided interface or both.

Have I got this right? Any other issues I should consider when emitting Interfaces?


Uml Process / Re: UML didn't trigger my brain
« on: October 26, 2005, 01:45:55 pm »
For end users, I find it's best not to "teach them UML". Just get a white board and start drawing the diagram as you go through the domain model, then walk them through the diagram to confirm it.
When I start modelling with end users, I tell them, not to worry about the funny signs, I'll verbalise the model to them as required.
After a point they reach an "appreciation" of the model.  They can see it does something and is conistent but they don't have to understand the detail.


Uml Process / Re: UML didn't trigger my brain
« on: October 26, 2005, 01:24:55 am »
For most people that I know, "learning UML" is very different from learning a new language.
When you learn a new language, like French or English, you already know what you want to express with that language.
Most programmers who try to "learn UML" are not used to the process of abstracting problems and turning them into abstract designs, which is what UML is so useful for.
These people have to learn both the process (what to express) and the language (how to express it).

This, IMHO, is the great challenge in "learning UML". Not only do you have to learn the language (that is the simple part), you also have to learn what to use it for and why.

Excellent observation Mikkel!

I think you are spot on!

If anyone is having difficulty abstracting then the discussions Jim Shaw and I are having may be of interest (see other threads in this Forum).  They are specifically targeted at creating the right level of abstraction for the various model forms in:
MDA (Model Driven Architecture)
CIM (Computationally Independent Model)
PIM (Platform Independent Model)
PSM (Platform Specific Model)


Uml Process / Re: MDA- Which Language type to use for PIM
« on: October 27, 2005, 01:34:36 am »
I've created my own language type called "Conceptual"  for this purpose.

The EA help tells you how to do it.

if you use a PSM language, you implicitly bind the PIM to the concepts of the implementation language.


Uml Process / Re: User Manual Vs Use Case
« on: October 23, 2005, 07:39:09 pm »
Hey, can everyone tell me what's the difference between User Manual and Use Case? I found out both of documentation are telling users what to do on the system.

Use Cases (when stored in a model like EA) and when created with a formalism are more amenable to automated processing than User Manuals...

I have difficulty reading some user manuals, I can't expect my automatic emitter to be better at it... ;D


Uml Process / Re: Thoughts about Containers & Containment.
« on: October 20, 2005, 05:12:45 pm »
Paolo, I need to think about the implications of our quotes above and get my thoughts better organized.  Instead of responding here on collections, let me start a Collections thread.
Jim, the tutorial on collections you previously referenced has disappeared.  You seem to get redirect to buy some Sun books... ;D

When you start a new thread on collections, bear that in mind.


Pages: 1 ... 351 352 [353] 354 355 ... 403