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

Pages: [1] 2 3 ... 94
Automation Interface, Add-Ins and Tools / Re: Technopedia and EA
« on: November 05, 2017, 08:15:34 pm »
what I'm interested in is just being able to access their database from EA in order to automatically collect vendor-supplied information about packaged applications, system software, and hardware.
For some reason this reminds me of one of those medieval maps, with the annotation ....

---> Here be beasties!


Bugs and Issues / Re: Timing diagrams
« on: October 18, 2017, 09:27:12 pm »
"using timing diagrams", in what sense?
We used them back in the day, to sort out asynch comms conversations. But apart from, say, exploring possible (or improbable) scenarios I cannot really conceive a need for them?
Keep me informed.

Bugs and Issues / Re: EA clear the file. Now 's empty 0Ko
« on: October 16, 2017, 07:23:16 pm »
(This is probably a furphy, but anyway.)

I recall that about a million years ago there used to be a problem with the Jet engine when the MDB file was stored on a network drive. I did a bit of a search through the forum but cannot find anything apropos. All I really can remember is that one symptom was "suddenly" empty mdb files.  It was not an EA problem, as I said it was something about the Jet engine. 
Anyway I would presume that by now that issue would have been resolved, so this is probably a furphy.


What is actually needed is that a true doppelganger is as fully visually configurable as the master, but with a decoration to indicate that it is, in fact, a doppelganger.

What would be nice is something we used in the early 1970's in data flow modelling and that is a duplicate icon for an element - if you senior practitioners remember it was a sort of an inverse of a UML note icon, a box with a filled in triangle in the bottom LHC or RHC - that represented "this element is some where else in this diagram" go see it for actual details.

The trick would be to be able to drag a link between  the original element and the "copyof" icon - this would not change the original link specs just where its geometry goes.



General Board / Re: What is Sparx and for what purposes it should be used
« on: September 28, 2017, 06:49:01 pm »

Uml Process / Re: What is an "Instance"?
« on: September 19, 2017, 10:56:20 pm »
an "Instance" is something you can perceive with your senses

Far, far, far be it for me to throw a (conceptual) "spanner" into the (conceptual) "machinery", but ....
a (conceptual) "instance", which I conceive that the (conceptual) "Paolo" may have been alluding to can also be a thing beyond our perception. Putting that another way, can an instance be imaginary?

YMMV, but personally, I certainly hope so. Because if not, then the (classifier) "set of imaginary numbers" could not exist. Therefore, the square root of -1 could not exist. Therefore a great deal of the mathematics of quantum physics could not exist. Thus it follows that a great deal of semiconductor technology could not etc etc. Etc, ad absudium, until this "thing" that I perceive that I am banging my fingers on cannot exist.  Which is a bit of a problem, because then, none of you exist. (Others have discussed this in detail.) Ahem, to get back on track..

"Why is a raven like a writing desk?" is a question posed by a mathematician of the 19th century who did a bit of work on set theory a wrote a certain book. Or at least I conceive that he was and did, for I have never met the fellow. His generally accepted identifying attribute was (and still is) "Lewis Carroll". He had other identifying attributes as well, but that would depend on the "classification scheme" that could be used. (You see where I am going here?) The one I will use in this instance discussion is (let's just accept, for the sake of sanity) "The set of all English writers, mathematicians, logicians, Anglican deacons, and photographers born in a parsonage at Daresbury, Cheshire in  January 1832 and resident at Christ Church College, Oxford in 1862". Hopefully then, one could construct a Carroll diagram where the cardinality of the set of instances in the "Yes" box is 1. However, that is not important.

What is important is that at that time "set theory" or the "mathematics of categorization" had just begun to be formalized (or at least in the so-called "western hemisphere" of this planet). Now, "a set" is unfortunately just a concept, you cannot pick up (touch) "a set", nor can you see, hear, smell or taste "a set". But it is a good thing that instances of "a set" exist, because if not then Dr Codd could not have invented relational theory and then...
(and don't even think about, let alone mention, "the set of all sets" at this point. It's been done.)

Which in my usual obtuse fashion, brings me back to the point.

Set theory is is the science of categorization. To keep this short, in a Venn diagram the rectangle is the universe of all physical and conceptual "things", the circles are classifiers which abstract a set into which one can put or not put (or partially put!) "things". (Deep breath) A class, as we use the term here, is a description of such an abstraction of a set. And an instance is one, and only one, of those "things".

All "things" exist, physical and conceptual, invented and not-yet invented. They are in Venn's rectangle. Out job is to decide whether they are also inside this or that circle or both or neither (or partially). To be successful, we must define the circles properly such that they adequately describe their membership.

So, qwerty, I agree with you entirely or at least 99%.  For sure, there are Cars and Customers and Cabbages and Kings. But there are also Accounts and Payments and Messages and Ratios and other kinds of things.

BTW, regarding ravens etc, just like the Hatter and Dodgson, I have no idea either.

(I think I might go and have a little lie down now.)

General Board / Re: What is a "property"?
« on: August 24, 2017, 03:00:08 pm »
"What's in a name? that which we call a rose"  :)
(Now I was given the understanding that we were eschewing the Bard? Mneh?)

Don't forget that just at the beginning of that she (being the Juliet in question) says:

"'Tis but thy name that is my enemy."

Which of course brings back in a full circle to "What is a Romeo?" (originally "Wherefore art thou Romeo?")
Is it a part, a role, an actor, a class, a classifier, an instance of any of the beforesaid?
I think the only thing that we can definitely agree upon is that "Il est pas une pipe!"


General Board / Re: What is a "property"?
« on: August 24, 2017, 01:10:21 am »
And so the question is begged...  Over the last couple of weeks, since I came back from holidays, I have been grappling (again), occasionally, with the question of what is an "instance"?   ;)

No, the question most definitely is:,
"Is the instance of the picture of the picture of a pipe
that you see
on your PC
the same instance of the picture of the picture of a pipe
that I see
in front of me
on my PC?"

It must surely be
that that could not be.
Unless we gaze upon the same PC.

Then I'd be thee, and thee'd be me ...
a thought that doth not comfort me.

See,this UML stuff is easy!  Even a child could understand it.

As usual, I will sign off with a


Uml Process / Re: What is an "Instance"?
« on: August 17, 2017, 11:37:05 pm »
I'm not sure about your distinction between classifiers and classes. It may just be that you're using the terms in a different way than the UML specification. (Which says that "Classifier" is to "Class" as "Car" is to "BMW 318i" in your example.) The terminology it uses for the the definition of a class is "metaclass".

A CLASS is a classifier. A CLASS is also something in a text file in a directory somewhere called something like "source".

A TUNE is a classifier (perhaps, ontology raises it's ugly head again?). A tune could also be some script on a piece of paper, or maybe it's something your beloved daughter wrenches excrusiably {sp: damned if I know} out of a piece of torture equipment called a "recorder", or maybe it's just something in your head  (I have one of those...

All "tunes" so we can form a mental concept of a thing, context context context. 

Seriously. Classes are classifiers, so are components, interfaces and the other ones I have forgotten.  Classifiers, in the UML sense, are just "things" which have some "stuff" in them.  They are represented in UML as a rectangle (or a blobby balloon or a sausage or maybe even a hamburger shaped thing - who really cares). "This is not a pipe"! 
Other stuff is not stuck on a UML diagram as a rectangle, balloon, sausage, hamburger or even a dalek. These things are NOT classifiers. Usually they are "lines", "sticks", "arrows", etc. Their intent is to convey some sort of relationship between those classifier things.
"This is a picture of something but it is not a pipe".
There is a third group of stuff we stick on diagrams. I can't remember wtf they are called "officially" but for the sake of this argument let's call them "annotations". A couple of them leap to mind. One sort of looks like one of those 3M "sticky note" things. Another is something that looks a bit like a sandwich with the bottom right hand corner folded over that occasionally appears at the top left hand corner of a diagram. I think they are supposed to represent some sort of "title" or something.
(They have meaning AFAIC only in the eye of the diagram making person.)
"This is a picture of something that is not a pipe with a limp sandwich in the upper left hand corner containing the words "La trahison des images" "

This is a picture of a Dalek.

Code: [Select]
              |  ---(
             / \

Am I starting to make any sense yet?


General Board / Re: What is a "property"?
« on: August 17, 2017, 01:21:38 am »
Sorry for bringing this up again, but I have to vent my anger and here at least there are sane people.

This happened elsewhere and today by the way!

THEY: Oh, you can't have the same name for a component and a class.
ME:  (deep breathing for at least 24 minutes) Que?
THEY: Oh, you can't do that because they would mean the same thing!
ME: (madly fumbling for 000 on my phone) So, a picture of a brick called "Fred" is the same thing as a picture of a dog called "Fred"?
THEY: Uh, what do you mean?
ME: ("Yes, hello operator. I desperately need three kg of Valium") Listen carefully, I will say this only once! (thinks: or twice,or thrice or perhaps 6.023*10^26 times...) (Very deep breath) OK. Is a picture of a dog called Fred the same thing as a picture of fish called Wanda?
THEY: I thought we were talking about the system?

Oh and by the way Paolo, that is actually a picture of a Picture that is (vicariously) called "This is not a Pipe" :P

Well, in a sense the way that this stuff "should" be done is through XMI.
(But then again, beware young man .. that way lies madness.  Ha ha he he ... he he .. hee .... .......................

General Board / Re: What is a "property"?
« on: August 03, 2017, 12:46:21 am »
? Same page (372), "Behavior" at top center and bottom left.
? And now I look at the there are two "Redefinable Elements" as well.

General Board / Re: What is a "property"?
« on: August 03, 2017, 12:16:28 am »
A classifier is a classifier.
An attribute/property/pin/part/pineapple/frangipani is an informational feature of the classifier.
It is "convenient", within a context to give such feature a "prominent" name.
There are 10 types of things about a classifier: attributes (informational features) and behaviors (things you can tell an instance to perform).
There are no other things.
No matter how you dress up reality with this, that or the other "approach" to modelling the universe.

A model is a picture of the universe that helps explain an aspect of something in the universe.
A house plan helps explain the dream between the architect and the builder.
A color patch helps (occasionally to) explain what the wall will look like when it is painted.

A UML diagram should be constructed to explain, within some conversational context, some aspect of a system.
If the so called "rules" of UML don't let me do that, then I break them.

Let me say this only once (for the second time)! The model is not reality. The house plan is not the house, the color patch is not the paint. To paraphrase(?) Sylvia Plath "A rose is a rose", a picture of a rose is not a rose but it may give some audience an idea of the plant that I am talking about.
Go think about a painting that you like, of a rose if you like, or a fish or a tree or a car or a scream. Why is it good? Because it engenders something in your psyche - it just "gels".

And explains.

Now consider the person who painted it. Were they worried about whether this shade of blue was called "Prussian" or "Cobalt"?
Or were they just using that shade to convey, as clearly as possible, to the "audience" some aspect about that flower that they wanted to explain?

Model to explain, perhaps even unto yourself, aspects of the universe. Dressing up models with OMG names and trying to comply with the so called "rules" is a waste of both your and your intended audience's waste of time.
Is a property the same as a "Prussian Blue"? I think not.

Not clear enough? Well let's go sit in a coffee shop tomorrow and you can explain to me "how to get from here to Tiffany's in time for breakfast", on the back of a napkin.  Would I expect a Google map of the world? (Complying to dog knows whatever "standard" they use.) Now, given the current context, that we are sitting in a cafe in rural South Australia - would you try and draw a google map?

Classifier: Location
Attribute: geopos? (whatever)
Behaviour: Describe_route(destination::Location) as Scribble_on_napkin

bah! Sometimes I think UML modelling has got to the point of acute cranial-recto-insertion.


p.s. This rave was in part incited by a recent post on the dreaded "more than one instance of the same entity on one diagram" dinosaur. In particular let me refer to figure 15.1 in the most recent adopted specification. Oh dear! There is more than one instance of an Adapter Behavior in that diagram. Oh dear, worlds will collide!  Oh no, don't tell me OMG just broke one of their own rules. Oh hang on - there is no such rule anyway. But why didn't they draw it with so many damn criss-cross lines as to make it totally unintelligible?

(Damn. It was another diagram, but the point is still there.)

(The reality is, they are the funny shaped bits of metal on the ends of custom made roof struts - the name escapes me for the moment - we are trying to come up with a way to classify them to reduce the errors between the salespeople, the designing engineers and the fabricators.) Remember those ASCII box drawing characters, they sort of look like them only in three dimensions and there's lots more of them.

Geert has come up with the right answer.  When I first thought about it, I thought gawd there's going to be hundreds of them. But it's looking like there will only be a couple of dozen - which is copable.

Thanks Geert! One of those cases of being too close to the problem.


Greetings Sparxbeings!,

Just tried EA13 today and by-crikey things certainly have changed around here while I was away. (But judging by a bit of a browse through recent postings there are still some more-experienced (read "old") faces around and there are still some of those wonderful "consistent inconsistencies" abounding.)

Anyway, serious question on theory:

Is there such a thing as a "constrained, enumerated multiplicity"?  By that I mean a multiplicity on an association that can only be one of a set of enumerated multiplicities and that choice is dependent on a value in the owning class. In other words, for a given instance of the subject class where the value of a specific attribute is "x" then the multiplicity of objects related to that instance via that association is exactly "y", where "y" may be a single value or a range.

Consider this example:

class:Religion has attributes Deities and Theism_Type.
class:Deity is associated to Religion through the Deities set.

So, an instance of Religion where Theism_Type = "mono" can/should have 1 and only one Deity instance. Another instance, with Theism_Type = "duo" can/should have exactly 2 Deities instances and so on until the instance with Theism_Type = "multi" can have 1:* Deity instances associated.

My problem is figuring out how to show this type of multiplicity concisely and simply and is not specifically a how to do it EA question.

Any input?


p.s. Yes, you may well be thinking "OMG! Someone's left the back gate unlocked and that nutcase has crawled back in again!"  ;D

Pages: [1] 2 3 ... 94