Book a Demo

Author Topic: Specificity of Language  (Read 10748 times)

alicecbrown

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
  • Silence condones.
    • View Profile
Specificity of Language
« on: February 28, 2007, 06:53:14 am »
I really don't mind that you can't spell 'realize'  :D  but some of your 'explanations' are incomprehensible, possibly from cutting and pasting errors.
When you're trying to learn a new tool, this is maddening.
For example,  Definition of 'include relationship':  A relationship between two use cases in which one use case 'includes' the behavior. This is indicated where there a specific business use cases which are used from many other places - for example updating a train record may be part of many larger business processes.
I can finally grok this meaning, I think, but we are software engineers, where specificity is crucial to avoid implanting bugs that won't be caught by test. :-[
Unto him who is given much, much is required.

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
Re: Specificity of Language
« Reply #1 on: February 28, 2007, 08:59:33 am »
I usually report such typos as bugs - they update the documentation occasionally.

I note that EA can't really decide whether to speak English or North American.

alicecbrown

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
  • Silence condones.
    • View Profile
Re: Specificity of Language
« Reply #2 on: February 28, 2007, 12:24:15 pm »
Related to this question is the ability (weakness?) of the tool that allows you to name a STate identically to its Method.  You don't have to but you can.  I have a State named "LockCovers" and a method named "LockCovers" and nothing to tell me nay. :P
On the other hand, I understand why I have a state diagram named 'PUMP' and another state diagram named 'BOWL' , each with the substate oval of 'Idle'.  But if I were to code it, it would be the 2 separate states of  Pump_Idle and Bowl_Idle.  No problem with that at all.  :)  This other situation bothers me, which brings up the question, "How do I turn on the error checker?"  The old Rational Ada machine would correct you as you went with its WhatDidIMeanToSay syntax checker, but don't guess EA has gotten around to that yet. ;)
Unto him who is given much, much is required.

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
Re: Specificity of Language
« Reply #3 on: March 01, 2007, 01:47:02 am »
I guess EA allows you enough slack to hang yourself ...

sargasso

  • EA Practitioner
  • ***
  • Posts: 1406
  • Karma: +1/-2
  • 10 COMFROM 30; 20 HALT; 30 ONSUB(50,90,10)
    • View Profile
Re: Specificity of Language -> UML is not L.A.W
« Reply #4 on: March 01, 2007, 04:32:45 am »
Quote
Related to this question is the ability (weakness?) of the tool that allows you to name a STate identically to its Method.  You don't have to but you can.  I have a State named "LockCovers" and a method named "LockCovers" and nothing to tell me nay.


Forgive me but I still dont realise what the problem is here.  See my other answer elsewhere.

To be pedandtic, I would have thought a specific statement of the state name would have been "CoversLocked" rather than a possibly abiguous imperative.

Let me metaphorize. (To enphrase a coinism!) If the architect draws a WC icon in the middle of the kitchen floor on your house plans and the plumber installs it there, then the model has been implemented correctly. On a rational planet, the plumber would query the model based on "common sense".  Now, to my knowledge, no CAD program will actually stop the architect placing the WC in the middle of the kitchen and so we rely to an extent on the intellect, experience and comon sense of the implementer (plumber) to recognize and query such incongruencies.

Yet we seem to want here, in a toolkit that is much more temporally immature than architectural blueprints and in an industry that has been around several centuries less than plumbing, automated (as in automaton-like) conformance to IT common sense.  Nay say I.  The UML is immature and even ambiguous, you only have to try and read the spec to find that out.  

I actually find that the relative freedom of EA from attempting to impose UML as L.A.W. one of its strengths.

regards

bruce
« Last Edit: March 01, 2007, 04:33:34 am by sargasso »
"It is not so expressed, but what of that?
'Twere good you do so much for charity."

Oh I forgot, we aren't doing him are we.

alicecbrown

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
  • Silence condones.
    • View Profile
Re: Specificity of Language
« Reply #5 on: March 01, 2007, 05:37:26 am »
The problem: I have been a software engineer for 35 years, back when we were still called 'programmers'.  One horrible bugaboo was the mistakes made by various programmers working different areas of a huge program, calling their variables by a name identical to someone else's, unknowingly.  For that reason, 'public' and 'private' was coined: identifying to all concerned that this was a GLOBAL name/address broadcast to the whole program and the 'private' held its value only as long as that module that named it was working on it.
With that background, I am sensitive to any redundancy in nomenclature and have to wonder if it's deliberate.
Or, like C, is it giving you the freedom to hang yourself, as has been said.
I'm going to try and run this down later today.  The software engineer who wrote it is an excellent worker, and might have a deliberate reason for the identicality.
Unto him who is given much, much is required.

mikewhit

  • EA User
  • **
  • Posts: 608
  • Karma: +0/-0
  • Accessing ....
    • View Profile
Re: Specificity of Language
« Reply #6 on: March 01, 2007, 05:51:04 am »
Hmmm, I guess an EA feature to check for name-collisions or near thereof would be of use in a large project ... but also some naming conventions imposed by the architect would also be helpful. Now that is an area that EA could also assist.

alicecbrown

  • EA User
  • **
  • Posts: 30
  • Karma: +0/-0
  • Silence condones.
    • View Profile
Re: Specificity of Language
« Reply #7 on: March 09, 2007, 06:25:26 am »
Excellent reponse :D!!!
At this point it bothers me that EA is duplicating the same freedom/problem with C, that it allows you to do anything you want.
Are there ANY rules or controls in EA?
We've got two classes, pump and reservoir that I've discovered have two stereotypes 'active instance' and 'external mechanism'.  Shouldn't EA at least warn the author that he has assigned two different stereotypes to the same class?  If we used the 'Generate Code' feature, which one would dominate, and does it even matter?  Calling into question the entire purpose of <<stereotype>>!! ???
Unto him who is given much, much is required.

thomaskilian

  • Guest
Re: Specificity of Language
« Reply #8 on: March 09, 2007, 02:32:26 pm »
Quote
If we used the 'Generate Code' feature, which one would dominate, and does it even matter?  Calling into question the entire purpose of <<stereotype>>!! ???

Good question indeed. Can we have an answer from Sparx, please?

Eve

  • EA Administrator
  • EA Guru
  • *****
  • Posts: 8090
  • Karma: +118/-20
    • View Profile
Re: Specificity of Language
« Reply #9 on: March 12, 2007, 01:07:36 pm »
The code generation templates currently only have access to a single stereotype, the first one in the list.  This is an issue with code generation.

No, EA shouldn't warn that you have two stereotypes.  UML explicitly allows any element to be stereotyped by many stereotypes.