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 ... 352 353 [354] 355 356 ... 410
Uml Process / Re: BPMN Text Annotation
« on: May 17, 2006, 03:14:07 pm »
Seems to make sense. Where and why - in the sense of "what result are you seeking" - are you doing the mapping?
Well, my Universal Interface attempts to communicate the semantics of the either side.  So as I mentioned I already have elements for depicting Notations (whether Notes n diagrams, Text on diagrams, Notes attached to elements, Notes attached to features of elements).  It's compatible with UML, but not isomorphic.

So annotations are Notation Elements in my semantics.
Just to be on the safe side, it might be worth looking up the most recent BPMN specification (1.0 or 1.1 if I remember) and scanning through to make sure they don't do or expect something exotic from their annotation elements.
I'd already done that.  I'm using the Final Adopted Specification - Feb 2006 dtc/06-02-01.

It looks as though (as I previously mentioned) I can use the current notation element unchanged and do everything I need there.

My interface doesn't (for the moment) include graphical information, apart from noting what's on which diagram - as there are some semantics involved there.

My intention is to separate the rendering from the semantics.

Thanks for you help.


Uml Process / Re: BPMN Text Annotation
« on: May 17, 2006, 07:36:06 am »
Well that leaves me with a problem.  I already have Notation Elements in my Universal Interface.  They have most of the standard attributes of EA elements.  They are currently used for UML Notes and Text Block.

I guess I can use the Note element for Text Annotation (unchanged).  I just map a BPMN Text Annotation Artifact to a Notation Element and vice versa.



Uml Process / BPMN Text Annotation
« on: May 17, 2006, 06:55:18 am »
Anyone have any idea why OMG decided to make the Text Annotation an Artifact and not a UML Note?

Seems a bit strange to me...


Uml Process / Re: Naming Architectures - Why?
« on: April 05, 2006, 08:13:14 pm »
Paolo, I hope, that you'll enjoy the same as I did while reading this ;D
Besides, this has deep relations with your posted topics and idea
Yes I did thanks, SF_lt.   ;D

I've added it to my favourites.

As usual, there's a lot of truth in humour...


Uml Process / Naming Architectures - Why?
« on: April 04, 2006, 05:44:37 am »
This is the first of a series of postings on principles for naming things (in models and in code).  It is the result of an offer I made in the thread: [size=13]customize code engineering?[/size]; which dealt with the problem of trying to synchronise model names and code names where they aren't the same.

In that thread, I made a plea for developers of naming standards to define requirements first and then supply reasons why their naming architectures were the way they are.  Since it would be inappropriate to assume my personal naming architecture would apply to someone else's situation, I suggested some posting on some of the principles I've adduced and have found useful in developing my architecture.

I'd like there to be robust discussion, so I can learn.  I suspect we will be able to develop a pattern language for Naming similar to other pattern languages (such as an excellent one for Use Cases or one I've referenced in other postings regarding User Interface design.

[size=18]Why have naming rules?[/size]

So this thread is about the reasons why we should have naming rules...

I'll throw it open with...

[size=13]In any systems project, there are elements that must be named to differentiate one from another.[/size]
  • ... (Here we will list issues that a good naming standard has helped to resolve)
  • Compromises made to align the many different points of view may result in a less than satisfactory naming architecture.
  • ... Here we will list issues that a bad naming standard has created
  • Different tools and languages have different syntaxes
  • Different project needs may require different levels of conformance
  • Arbitrary rules make adherence difficult
  • Rules that have practical benefits make adherence easier
[size=13]Develop and maintain a naming architecture[/size]
[size=13]This pattern should evolve as a result of the thread discussion.  I'll periodically update it as a result your input.  This first posting will edited as the pattern evolves.[/size]

[size=0]2006 Paolo Cantoni, -Semantica-[/size]

Uml Process / Re: XOR vs Cardinality order of precedence
« on: May 02, 2006, 04:28:10 pm »
With one exception I think Paolo and I are saying the same thing.

I've allowed for another case. A car MAY have ONE radiio. This allows you to buy a car without a radio, but if you do get a radio there can only be one in the car, and it must be a valid specialization of the abstract radio class.

This also allows the wholesaler to receive a valid car, even though the radio slot is not filled.

Apart from that we're saying the same thing.

Strikes me this would all be easier to explain with a small UML model. Of course this was the whole idea of UML in the first place...
Yes, David. I was just using Jim's rules as he'd specified them.

In my fact-based modelling methodology, you also need to account for:
"I know this car hasn't a radio"
"I know this car has a radio, but I don't know what kind it is."

This gets into the "Extrinsics" pattern.


Uml Process / Re: XOR vs Cardinality order of precedence
« on: May 02, 2006, 03:07:47 pm »

I'd model the relationship between a generic car and generic radio. I'd then specialize the radio into the three specific types.

That seems to model the two business rules you've enunciated:

A car MUST have a radio
A radio MUST be one of three types.


Uml Process / Re: Activity Diagrams
« on: May 01, 2006, 03:15:53 pm »
Woe me,
According to the UML 2.0 spec, an action must have all inputs satisfied before being executed. The only ORing node is the merge node.
This means that my last post was out to lunch. I can live with these rules, but I cannot reconcile examples that I've seen on the web that apparently use a different set of rules.

here's an example
The "Enroll in University" action has three inputs, of which only one can be active at a time.

Is it wabbit season or is it duck season?
HI Steve,

You do need to distinguish between Activities and Actions - They aren't the same thing.  Also you need to be able to determine if the diagrams you see are UML 1 or UML 2  (typically they will be UML 1).  And finally (although this is mostly NOT true of Scott Ambler) many web based UML diagrams are like most stuff on the net - quality unguaranteed.


Uml Process / Re: Naming - Adornments
« on: April 23, 2006, 02:44:58 am »
Hi Hans,
Personally, I think, that goes a bit too far:
It's not clear to me what you are referring to here. The pattern or some of the subsequent discussion.
Although I am with you that consistent naming is the decisive measure for good domain modeling and thus for the rest of the application, it is domain driven.
This should be obvious, but apparently it isn't. I still find I have to argue this.
Hungarian notation itself is not a good strategy.
Why is Hungarian not a good strategy? As I mention, I don't use it, but do use elements of it. I know why I don't use it, but as I mentioned when I started this series of threads, I'm interested in why others do and say what they do. Can you elaborate on WHY you see Hungarian notation as not a good strategy.
The same holds for any table centric naming convention for stored procedures (within the database).
Can you elaborate further what you mean here. I have an inkling, but as I'm said else where, I prefer not to make any assumptions whenever I can.


Uml Process / Re: Naming - Adornments
« on: April 18, 2006, 04:24:15 pm »

I reckon they should be global facilities provided by the IDE. (Sort of like a certain modelling tool... ;) )

We now accept and deliver requirements for end user systems that provide useability features to make their lives easier. My beef is that we put up with this entire problem when we should be complaining to the IDE deliverers to come up with a workable solution.


(P.S. I'm not having a go at this thread tho!)


Uml Process / Re: Naming - Adornments
« on: April 18, 2006, 06:16:33 am »
While I understand and agree that adornments are useful, I don't always like them because:

1)  Lack of consistent standards.  If adornments are so good I really believe there should be global standards enforced by the compiler.
Adornments, as you suggest, shouldn't take the place of semantically valid names.  I don't think there can be universal standards.  
Some adornments are like additional metadata about the element.  My preference would be to formalise these metadata similar to .NET attributes and then let the compiler or runtime use this information to locate errors.
2)  Readability.  Adornments can cause the code to start to look less like plain spoken English and more like gobbly-gook only understood by the author.  (See comment 1).
While, technically this is true, when you use adornments in a consistent fashion, you become "blind" to them.
Because of this I like to minimize my usage of adornments myself.  When I code, I typically try and expose every data element as interface elements in my classes.  I don't want to burden these names with adornment rules because the name itself should communicate exact meaning to a client of the class.
In my naming architecture, the use of adornments is not universal (but, I hope, consistent).  They are used within methods and attributes.  As with your point here, publicly visible elements are essentially unadorned.


Uml Process / Re: Naming - Adornments
« on: April 18, 2006, 05:41:10 am »
This looks like an object oriented version of the old Hungarian notation.
Looks can be deceiving...  ;)

Yes, there are elements of Simonyi's Hungarian notation.  I actually bothered to read the original paper.  One interesting feature is that Charles Simonyi decreed was that the datatype should be the abstract datatype.  This appears to observed "more in the breach"!

Also, if you look at all the public examples in the original pattern, they are almost all unadorned.

So, in my view, it is sufficiently distinct from Hungarian notation to not be tagged as such...

The examples I give are from my naming architecture; but, as I previously said, each team should decide what their needs are, document them, and then compare any naming architecture proposal with the stated requirements.


Uml Process / Re: Naming - Adornments
« on: April 05, 2006, 03:03:27 pm »
one thing: LV and RV stands for something left and right? ???

LV is short for LValue and RV correspondingly.

<programming> A reference to a location, an expression which
can appear as the destination of an assignment operator
indicating where a value should be stored. For example, a
variable or an array element are lvalues but the constant 42
and the expression i+1 are not. A constant string may or may
not be an lvalue (it usually is in {C}).


Source: The Free On-line Dictionary of Computing, 1993-2005 Denis Howe


Uml Process / Naming - Adornments
« on: April 04, 2006, 06:49:17 am »
[size=13]You need to use named elements correctly.[/size]
[size=13]Various factors often contribute to errors in writing code.  Often these are picked up by the language processor, but often they aren't.  Some of these are:
  • Scoping (coding block)
  • Visibility (Public ... Private)
  • Datatype (Integer, String, Real, Boolean...)
  • Volatility (Constant, variable, WORM)
  • Nature (atomic element versus structure)
  • limited range of mechanisms to indicate these issues
[size=13]Adorn the basic name to reduce errors[/size]
[size=13]gsSECTION_NAME        (global string constant Section Name)
moAncestorClassifier        (private member object reference to Ancestor Classifier)
IsEmpty        (public boolean property indicating the instance is empty)
validateSubTypeCluster        (private method to validate a subtype cluster)
SetLogicalOnlyInferenceOnEntity        (public method)
s_camel_cased_logical_table_persistence_caption         (local string WORM variable containing the camel cased caption to be used for this logical table)

[size=13]My experience has been that with the kinds of adornments I use, I actually reduce the number of errors I make in coding.  The form of the name tells you a lot about where it can be used (LV versus RV), where it came from, what it looks like or how it can be cast.  Also, the adornments allow the same conceptual thing, rendered differently to have the same semantic name, but be differently adorned.  I find this capability to be most useful.

Finally, language processors often can't process hardcopy very well...   ;)

[size=0]2006 Paolo Cantoni, -Semantica-[/size]

Uml Process / Re: Naming - Content Semantics
« on: April 23, 2006, 07:11:05 am »
Hi Paolo,

   as to Italy: I sometimes run into mistakes ;-)
As to count in class Orders, it is Orders.count.

I am not a missionary in ultimate naming principles myself, just a victim of silly rules in my company for which a majority voted.
Ah... yes... the majority vote!  Of all the naming standards I've seen, the worst were majority votes.
E.g: The db folks objected the liberal namings in stored procedures hampering their work and the underscores annoyable to write. They thought: If the table names which the SPs use were given as a prefix, things would appear in order and harmony.
However, these SPs for most part don't belong to the db, but to application layers that the db folks are incapable to write nor even to maintain! Things will worsen by that silly convention, as no one will be able to tell what the SP code will be actually doing when a table name changes and if that SP actually will be obsolete.
I thought that was why... What can I say???
Another example: You qualify the counter further, for instance into prefixing longCounter, since a type is a long. A developer may be conformant to that rule, but he may right away misuse the word counter for something different, for instance an address. That's what I personally would object against! I mean: when names obscure or even mislead the *real* meaning of the type in its very context, that is what is bad. Other adornments are simply superfluous.
No, I don't qualify with types.  I (conditionally) adorn with type symbols and then these are abstract datatypes, not actual datatypes (thus iCounter - an Integral {as opposed to Real or Boolean)).  

Using a counter for an address is not misuse it's abuse! :-)


Pages: 1 ... 352 353 [354] 355 356 ... 410