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 ... 349 350 [351] 352 353 ... 406
Uml Process / Re: Naming - Content Semantics
« on: April 05, 2006, 05:38:17 am »
The question of booleans is interesting.

A boolean is often used as a return value to denote the success or failure of a method.  If we were not interested in the processing result, the method would normally have have a void (or null) result.

I have now come to the view that this is an inappropriate use of the boolean, for a number of reasons (which I hope to elucidate in separate pattern when I've got my thoughts together).

However, the reason I'm talking about it here is that I believe there are naming implications for the method depending upon what is intended.

If the objective of the method is to deliver a boolean result such that it can be assigned to a LValue (that is, we are NOT returning the processing status), then it should follow the naming rules for a boolean variable or property.  The naming rules should be such that the name is that of a fact (and thus in the passive voice):  TaggedValueWasFoundInElement(Tag, Element),  .IsValidForPeriod(Commencement, Termination).  Naturally, this would allow it to be used directly in the if statement conditional, without further effort:
If TaggedValueWasFoundInElement(NameTag, Element) Then
   'Process Tag value
End If

if (!Cheque.IsValidForPeriod(Commencement, Termination))
   //Bounce it...

I use a different process to handle processing results.  I use a HResult concept to provide more information regarding the processing.  If I need to take appropriate action I can test to the required level.  I provide wrappers such as bool SUCCEEDED(HResult), bool FAILED(HResult) etc.  This allows me to implement multi-state logic very easily.  The method is named using an active (verb based) name - such as: FindUDXMLStructure(string  name), SetLogicalOnlyInferenceOnEntity(value As Boolean)



Uml Process / Naming - Content Semantics
« on: April 04, 2006, 06:01:50 am »
Apart from the normal organisational reasons for having naming standards, we also want to enforce the relevant semantics between the name of the element and its contents.  This aspect is vital in the creation of programs that perform reliably, can be more easily understood and maintained.  If the name of the element does not convey its content then the program cannot be understood easily.

[size=13]“Names are the heart of programming.  In the past people believed knowing someone's true name gave them magical power over that person.  If you can think up the true name for something, you give yourself, and the people coming after, power over the code.  Don't laugh!

A name is the result of a long deep thought process about the ecology it lives in.  Only a programmer who understands the system as a whole can create a name that "fits" with the system. If the name is appropriate, everything fits together naturally, relationships are clear, meaning is derivable, and reasoning from common human expectations works as expected.”
[/size] – Todd Hoff (,

[size=13]You need to choose a name for an element[/size]
  • Names that don't reflect the content make for confusion
  • Similar elements should have similar names
  • Elements in the same dimension should so indicate
  • Names that do reflect the content may be hard to type manually (likely to be long)
  • Short names (especially abbreviations) are unlikely to reflect the content
[size=13]Devise names that uphold the content semantics[/size]
[size=13]DriverShiftEpisode, TEMPORARY_DATABASE_PREFIX, TableHasAlreadyBeenGenerated, camel_cased_logical_table_persistence_caption[/size]
[size=13]When an element has good content semantics, the name of the element accurately conveys important information about its data content.  For example, if the element contains the count of the items in a list, then we know that the data within the element should be a non-negative integer – however it is implemented.  If we implement this element as a string, for example, then the string must always contain a non-negative integer.  In addition, if we need to perform arithmetic on this element, the process must conform to the rules of integer arithmetic.  We can thus define the semantics of a “count” element.  All such count elements have the same semantics.  We describe count as a dimension.  Each such dimension can have the appropriate semantics and constraints defined for it, in addition to its notional abstract data type.  This information can be retained in a formal lexicon.  If we include the dimension name as part of the element name, we are imparting a significant amount of information as to the contents of the element and the operations that can legitimately be performed on it.[/size]

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

Uml Process / Naming - Constants vs WORMs
« on: April 10, 2006, 08:45:30 pm »
C# makes a distinction between Constants and Read-Only variables.  I'm not sure which other languages have this facility, but I've found it useful.  For those unfamiliar with C#, a readonly variable may ONLY be set at definition time or in a constructor of a class.

Because of this defintion, a C# readonly variable is an example of a more general class of variables (sometimes known as WORMs - Write Once, Read Many).

Over the last six months, I've started to investigate specific adornments for WORMs.  In my Naming Architecture, WORMs look similar to Constants, but are sufficiently different to stand out.
(For those interested, constants are UPPERCASED_UNDERSCORE_SEPARATED and WORMs are lowercased_underscore_separated)

This has proving interesting and beneficial since I started.  As I said elsewhere, one of the objectives of my Naming Architecture is to ensure I don't inadvertantly use an RValue as an LValue.

Now, to the reason for this post...
Method parameters can be (conceptually) input only, output only or both.  Input only parameters can be by value or by reference.  Some languages (such as C++) allow you to define input only parameters as const - which means the variable can't be used as a LValue.  Now, how do we define a constant?

I'm going to define a constant as an element whose value does not change.  (Aside: this definition doesn't allow for "runtime constants" - these are WORMs)  Thus, a method parameter, by defintion, is NOT a constant and, in fact, the C++ const attribute is really a readonly designator.

Should I use WORM adornments for method parameters I do not intend to change?  As far as I can see, a Read-Only method parameter falls under my defintion of a WORM since its value is specified at the point of defintion (so to speak).

Interestingly, C# syntax doesn't seem to allow you to specify a method parameter as readonly (I may have that wrong).

Thoughts anyone?


Uml Process / UML 2.1 Superstructure Specification
« on: April 11, 2006, 11:41:00 pm »
I have just seen a reference to a new UML 2.1 Superstructure document

Quote the latest UML 2.1 spec (ptc/06-04-02).

I can't find it on the OMG site.  I suspect it is still Work In Progress (and thus not generally available).  Does anyone have a location for (or access to) a copy

Found it... It's at:

(Must have been a slip of the mind...  :-/ )



Uml Process / Re: new to UML
« on: March 21, 2006, 06:49:16 pm »
Hi all,

I am new to UML.

kindly provide some links to get knowledge on UML.

if i want to do some examples how can i do.

Start with the UML Tutorial at the top of the page... ::)

Books by Fowler on UML are usually good.  UML Distilled.


Uml Process / Re: Business modelling
« on: March 15, 2006, 09:18:33 pm »
Just a short observation on this thread...

As someone who regularly practises on all three sides of the fence  ;D (BA, SE, User)...

I echo Jim's standpoint on this.  I have found it most beneficial to ensure the domain is understood as much as is needed BEFORE plunging into systemic stuff.

(As I have said elsewhere... "Automating a business that makes sense is actually relatively easy.  Automating one that doesn't is impossible!")


Uml Process / Re: Control Flow Logic in Seqence Diagram
« on: March 26, 2006, 03:05:12 am »
Granted they appear to be using Rational but if I read the article correctly fragments are part of UML 2.0.

I don't know perhaps its best to have different scenarios in different diagrams just trying to reduce the amount of work involved. :D
Hi Joe,

I must confess that I was actually talking about interaction diagrams...  :-(  Since I'm principally a Data Architect, I'm not as familiar as I should be with the behaviour diagrams...  Alternate flows CAN be shown on sequence diagrams by means of suitable guards on the message transitions.

Anyhow, it does seem as though the example you referred to is using UML 2.0.  The UML 2 [size=13]Superstructure[/size] Specification confirms the usage.

However, for what it's worth, I might make a couple of observations on your diagram and what I saw in the IBM example.

1) The Alt frames use guards to create the various operands.  Guards, in my view, are slightly more complicated than simple conditionals and it's important to ensure that there is an explicit else option.  In your example, I would expect [User == null] and [else]

2) The Alt frame need to explicitly hook to an existing lifeline typically by extension.  From the naming of the Alt frame name, you appear to be expanding the Validate message.  This seems wrong to me.  If you were trying to model how the SecurityService handles the validation of the supplied user, then you might consider using a subordinate sequence diagram interposed between the Entry of the Validate message and the FetchUserEntity message (along the lines of the Figure 11 in the IBM article).  By the way, this would have the effect of encapsulating the downstream processing in a subordinate diagram.  (As a data person, I often see very complex sequence diagrams that attempt to show total interactions rather than the correctly encapsulated interactions one would expect from OO based designs - this would imply that the designers aren't actually thinking in OO terms)

3) The Alt guards are typically expressed in terms of a previously acquired data property.  You show the returns as guarded via [UserEntity]  - these aren't valid guards (as far as I can see - there is no condition).


Uml Process / Re: Control Flow Logic in Seqence Diagram
« on: March 25, 2006, 02:46:31 pm »
Hi all,

I am trying to model a Login Use Case with a Seqence Diagram.

I am having trouble getting control flow logic into the diagram. I have the main success flow laid out but if the users password or username is bad then i want to take a different action (i.e. show bad login to user instead of redirection to home page).

Now I have found that Fragments are what I should use for this, but I cannot figure out how to add sequences to the fragment.

If anyone could supply a link or reference or anything that can help me out, it would be greatly appreciated.

Many Thanks,

Hi Joe,

My understanding was that the Sequence diagram only models a sequence of calls.  No conditioanly logic s possible.

I thought they were designed to show a specific scenario in a use case - thus you would need a diagram for each flow.


Uml Process / Re: Help With Connectors
« on: March 22, 2006, 06:20:55 am »
[size=13][SNIP][/size]Consider the interface

Code: [Select]
const gravity g = 9.18;
void setGravity(gravity grav = g);

I would say that your 'gravity' type should be defined within a separate package (or packages), containing the types exchanged within your system (information view).
But the specific gravity instance, 'g', is part of the interface.)
Declarations of enumerations I would move to the information view as well.
Why?  If they are only used within the interface, shouldn't they go there?  Obviously, if they are used elsewhere they should be defined in a more common site.


Uml Process / Re: Help With Connectors
« on: March 22, 2006, 05:36:55 am »
Two answers, depending on how I read your question;
Sorry Tuser,
I didn't understand (pretty much) anything you said.  Can you recast your response?

Remember, I'm ONLY specifically asking about constants and enumerations (actually the literals).  Not about types or attributes.


Uml Process / Re: Help With Connectors
« on: March 22, 2006, 05:07:11 am »
As stated by the UML 2 specification (Superstructures, p99)

I'll confess that this section of the Superstructures document prompted my original post.  :D

However, since -as the Superstructures mentions earlier in the section:
An interface is a kind of classifier that represents a declaration of a set of coherent public features and obligations. An interface specifies a contract; any instance of a classifier that realizes the interface must fulfill that contract. The obligations that may be associated with an interface are in the form of various kinds of constraints (such as pre- and post-conditions) or protocol specifications, which may impose ordering restrictions on interactions through the interface.

Why shouldn't an interface expose constants and enumerations that are used to communicate via the interface?


Uml Process / Re: Help With Connectors
« on: March 14, 2006, 05:55:44 pm »
I'm a rookie, but what I know about <<realize>> is that if you design an interface (operations only, no attributes, stereotype <<interface>>), then you need another class to implement it.
Hi Derek,

Your response prompted me to ask the question:
Why must an interface be only behaviour?  

We accept this proposition almost as a mantra, but do we stop to analyse why this constraint is there?

I'd be interested in answers.  I discussed it with some people here at work and we've come up with a consensus that seems to make sense.  Also, I'm talking (as usual) at the Conceptual level since the ability of various languages to support conceptual interfaces at a syntactic and implementation level varies.

Finally, accepting that an interface can contain only behavioural elements, can it include Properties (which are behavioural elements masquerading syntactically as structural ones).


Uml Process / Re: UML Repository
« on: March 19, 2006, 02:10:03 pm »
I guess this is just a synoym for the concrete UML based in a (EA ;))-repository. Especially the sentence at the beginning of appendix A.

I agree with Thomas.  I interpreted any such models as: "here's how it might look like in (some arbitrary) repository."


Uml Process / Re: Lozenge (tm) & OCL
« on: March 05, 2006, 07:48:10 pm »
I received an off-line question which might be of interest to EAers.  Here's the question and the (slightly) amended response...

Would you use an association class or a ternary association to model a legal contract between two parties?
Personally, I like the association class approach best; the contract defines the relationship between the two parties.

Unfortunately it's at least a ternary:

A contract between First Party and Second Party under a Jurisdiction.  If one (incorrectly) assumes that all contracts will be written under the same jurisdiction then one can use the binary relation (and thus the AssociationClass).

However, you can try to get the best of both worlds by using the AssociationClass to model the Parties and use a single (additional) AssociationEnd (an EA Association - stereotyped «end») to add the Jurisdiction link.

This is the beauty of the AssociationClass is just a binary Lozenge approach!  8)  

However, since EA doesn't really provide access to all the Ends in the same way under this approach, I prefer a ternary Lozenge.


Uml Process / Re: Lozenge (tm) & OCL
« on: November 04, 2005, 03:21:12 pm »
EDIT: On thinking things through, you are free to model all associations as AssociationClass if you wish - it is, after all, adding extra information to the model not subtracting, and if you need the extra info then why not? So to answer your original point, Sparx don't "need to understand that the lozenge shape is merely a rendering of the AssociationClass" but we need to allow you to understand that. I think.


PS "KP" is pronounced the same as my surname and is easier to type. I've always used it on message boards. In the UK it's also a brand of nut  :-/
Hi Neil,

Thanks for the edit.  There's hope for you yet. ;D

You're half way there...  The problem with the Association Class is that as manifest (on OMG Diagrams etc) it appears to apply only to a binary relation.  This can't possibly be the case!  We have a continuum of (outbound, N-ary) AssociationEnds for an AssociationClass from 2 upward.  Similarly, we have a continuum of AssociationClass Features from N (one attribute for each (N-ary) AssociationEnd) upward.  

Accordingly, If I can represent a binary Association as either:
  • a single Association line (which is composed of the two AssociationEnds) between the two Associated Classes
  • or a line with the (rendered) attached AssociationClass
  • or the Association lozenge and the two AssociationEnds
then it is obvious (at least to me on a few minutes thought) that the lozenge IS the AssociationClass!

If this is so, the we have an elegant proof that is then extensible to the N-ary case!  In short, it works!

Now all we need is for Sparx to provide the additional context menu item on the AssociationClass (which IS the Lozenge) ("Use Lozenge Notation") (similar to the "Use Circle Notation" for an Interface) to allow us to switch between renderings and we're sweet!).

BTW: I don't know how many of you have been bothered by the question "What makes an AssociationClass different from an ordinary Class?"

Do you (the reader - not just Neil!) know?  Have you thought about it?  Will it come up as a question on the OMG Certification Exam?

An AssociationClass is a Class that represents an Association and thus has one required attribute referencing the associated Class for each arity of the N-ary Association it represents.  Add/Remove an AssociationEnd and the attribute is accordingly added/removed.

It all works!

So, Neil, when do we get the "Use Lozenge Notation" context menu Item?  Or at a minimum, the ability to change the Type of the Lozenge from Association to Class and back; as I think has been requested before in the forum?


BTW: The UML specifications are either somewhat compressed and potentially confusing or, in at least one place, downright incorrect on the subject of the N-ary Association.  In particular, Figure 74 of the the UML 2 [size=13]Infrastructure[/size] Specification showing Binary and ternary Association is incorrect in the placement of the multiplicities.  The multiplicity of the each AssociationEnd with respect to the associated Class is one!  The N-ary Association is defined as a Tuple and therefore the multiplicity MUST be one!  As far as I can tell, constraints on the number of Tuples for a given associated Class can only be handled by Class level constraints on the AssociationClass.  For example, "a Player can only be a goalie on no more than two team in a season".
[size=0]©2005 Paolo Cantoni, -Semantica-[/size]

Pages: 1 ... 349 350 [351] 352 353 ... 406