Help With Connectors

[jofreder]

I am a developer but very new to this product and process, we do nothing like this at work and I have to teach myself.

My question is can someone explain to me what these mean and when they are used

<<includes>>
<<Extends>>
<<realized>>

I think that is what they said. I have a general understand and can figure things out but need clarification.

Any book recommendation?

Thanks

[Oliver Michalski]

Hi,

read the UML2 Tutorials at:

http://sparxsystems.com.au/resources/


Oliver

[thomaskilian]

You might additionally search this forum for related threads since this has been asked several times before.

[derek73]

I just went through about two months of self-teaching and got a lot of help on this forum.

Check out http://www.holub.com/goodies/uml/ for a great summary tutorial on UML diagrams (though ignore his curved corner syntax for interfaces).

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.  This can be stereotype <<implementationClass>> if you wish.  The <<implementationClass>> realizes (or "comes to fruition", or "makes it real", if you will) the <<implementation>>.

Consider the following:

[code]
class Animal() {
   breath()
   move()
}

class Fish(Animal) {
   breath() {
       print "Fish breaths with gills"
   }
   move() {
       print "Fish moves with fins and swims around"
   }
}

class Human(Animal) {
   breath() {
      print "Human breaths with lungs"
   }
   move() {
      print "Human walks on two legs"
   }
}


Both classes Fish and Human realize the interface defined by Animal.  Animal may also be abstract and purely virtual.  This differs from a Generalization (solid line, triangle) which inherits the parent's protected and public attributes and implementation, whereas an interface class typically has no defined implementation -- realizing an interface is creating the implementation.  This is my two-month-old understanding of the difference -- experts will define it much more clearly.

When you use the Realize connector in EA, you'll get a pop-up menu asking you which behaviors you'd like to override and copy.  It will handily populate your class with behaviors from the source class.

For <<extend>> do a search on this forum (which is the same advice I got when learning about it).

[jofreder]

Thanks That was very helpful. I appreciate your time and effort.

[Paolo F Cantoni]

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).

Quizzically,
Paolo

[Tuser]

An interface can contain properties.

However this does not specify that a realizing class must contain such attributes, only that it must appear so to the user of the interface.

As stated by the UML 2 specification (Superstructures, p99)

Properties owned by interfaces are abstract and imply that the conforming instance should maintain information corresponding to the type and multiplicity of the property and facilitate retrieval and modification of that information. A property declared on an Interface does not necessarily imply that there will be such a property on a classifier realizing that Interface (e.g., it may be realized by equivalent get and set operations). Interfaces may also own constraints that impose constraints on the features of the implementing classifier.

[Paolo F Cantoni]

As stated by the UML 2 specification (Superstructures, p99)

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

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?

Paolo

[Tuser]

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

Two answers, depending on how I read your question;

1.  If the question is 'Why should the interface not impose a specific attribute, i.e. actually contain it, so if two classes realize the same interface, then neither have the attribute; the interface does.'

Well, it should. But that does not inforce that these variables/enumerations are implemented by the realizing class.

I think this is related to the reason to have interfaces; to create a Facade for the realization. The user of the interface should not know anything about the interface internals, only what he can 'get' through it. For the user the attribute are therefore real, but for the realization they arn't necesarrily. Ok, that sentence got a bit weird, but I hope you catch my drift.

2. If the question is 'Why shouldn't the interface defines the types and enumerations exchanged as part of the interface operations?'.

This is the concern of your information viewpoint, which provides the horizontal standardization of your system, i.e. collects all types used. The interface is part of the computational/functional viewpoint, which is specific for a component/class. But the computational viewpoint uses the information viewpoint.

This does not mean that the information viewpoint is a big pot with all types inside. Its structured and encapsulates the types used within composite components, but will typically contain parts used across all components.

[Paolo F Cantoni]

Two answers, depending on how I read your question;
[size=13][SNIP][/size]

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.

Paolo

[Tuser]

I didn't understand (pretty much) anything you said.

Sorry, I have been analysing standards for to long and have lost grip with reality. Even my wife complains...

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 seperate 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.

[Paolo F Cantoni]

[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).

Agreed...

But the specific gravity instance, 'g', is part of the interface.)

Agreed...

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.

Paolo

[Tuser]

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.

Hmm... good question.

It would even seem to make sense when considering implementation, as multiple classes can realize the interface. Each would therefore have to declare the enumeration type, or share a information view package with the declaration.

Actually your comments holds for the declaration of 'gravity' in my example as well. I guess it would make sense to define the type in the interface, if the type is only used by the class realizing the interface. But the type cannot be passed from the realizing class to another class, as the related class would then have to include the interface as well, which would be rather nasty.

Actually an interface property can then likely be seen as a constraint on the realizing class, as it dictates a type that the realizing class must define.

I think I would agree with you; Types which are solely used to describe the interface should be defined within the interface... until someone else to come in and set me right with meta-meta-model talk...

[jofreder]

Well, glad I could spark up a good discussion but I have one simple question maybe one of you can help me with.

I have a Class called ExecuteMain

ExecuteMain is going to implement IExecuteTest

I create the Class diagram for each

To connect these do I drag the Arrow from ExecuteMain and mark it <<Include>>,<<Realize>>?
OR
Do I drag the arrow from IExecuteTest and Mark it ?

Also

ExecuteMain is going to inherit from ExecuteBase
To connect these do I drag the Arrow from ExecuteMain and mark it <<Include>>,<<Realize>>?
OR
Do I drag the arrow from ExecuteBase and Mark it ?

Thanks again for you help.

[Tuser]

For ExecuteMain and IExecuteMain use <<Realize>>. For the realize, the 'arrow head' must point TO the Interface, i.e.

[ExecuteMain ] - - - > [IExecuteMain]

For ExecuteMain and ExecuteBase, the 'arrow headed' should point from ExecuteMain to ExecuteBase, i.e.

[ExecuteMain]--------|>[ExecuteBase]

Select ExecuteMain, drag the arrow to ExecuteBase and select 'Generaliye'

Consider whether the ExecuteBase shouldn't have the stereotype <<abstract>>. Look at the help in EA which is pretty good for a desciption.are not abstract itself).