Realization vs Generalization
Hello,
Could anyone help me with the "realize" relationship in UML/Rose?.
While maintaining a design specification in UML for a J2EE application, I found a lot of occurences of a "realization" relationships, that I have trouble understanding. With not much experience in UML, it's the first time I have stumbled on this term in this context (realization).
In the document I have to maintain, I found it several times used to describe the relationship between a class and an interface it implements. I would have modelled this notion merely as a generalization.
Rose documentation describes it as a "relationship between classes, interfaces, components, and packages that connects a client element with a supplier element", which sounds much like an association to me...
So my questions are:
- could you clarify the semantics of the "realize" relationship if it's a standard term?
- could you voice your opinion whether a generalization or realization is more appropriate between a class and an implemented interface? i guess it will be "it depends", so here are two educational examples :
publicclass MyEJBimplements javax.ejb.EntityBean// technical plumbing interface, polymorphism is used by the container logic
publicclass SomeDomainObjectImplimplements MyDomainObject// core domain interface, polymorphism is used in business logic
[1664 byte] By [
jdupreza] at [2007-9-29 19:56:01]
> So my questions are:
> - could you clarify the semantics of the "realize"
> relationship if it's a standard term?
"A Generalization encapsulates a relationship in which
objects of the specialized element (the child) may be
substituted from objects of the generalized element
(the parent). The child shares the structure and
behavior of the parent."
"A Realization is a semantic relationship between
elements, in which one element specifies a contract
that the other element guarantees to fulfill. There are
too common places were Realizations are encountered:
between Interfaces and the Classes or Components
that realize them, and between Use Cases and the
Collaborations that are the realization of the use case."
> - could you voice your opinion whether a
> generalization or realization is more appropriate
> between a class and an implemented interface?
Realization.
Thank you, that clarifies it.
What is the source of your quotes? UML standard? Some book?
Still it worries me that a realization graphically appears (at least in Rational Rose) like a mere association (straight solid line), unless we specify a prototype <<realize>> (which is quite readable but a bit heavy) whereas generalization has a clearly different representation (and as interfaces have a different representation as classes, the intent is clear as well).
Though logically not as appropriate as realization, is a generalization relationship between a class and an interface readable enough, or does it really violate the standard?
> What is the source of your quotes? UML standard? Some
> book?
I had a definition in mind and found a web page UML summary
that matched my definition so I quoted it. I don't have the page
handy but I'm sure Google could find it for you.
> Still it worries me that a realization graphically
> appears (at least in Rational Rose) like a mere
> association (straight solid line), unless we specify a
> prototype <<realize>> (which is quite readable but a
> bit heavy) whereas generalization has a clearly
> different representation (and as interfaces have a
> different representation as classes, the intent is
> clear as well).
>
> Though logically not as appropriate as realization, is
> a generalization relationship between a class and an
> interface readable enough, or does it really violate
> the standard?
Well, people reading UML diagrams tend to think in
terms of their own pet language. You may be thinking
Java with its interface concept but a C++ guy thinks
abstract class when he wants an interface. Only problem
is that an abstract class may also represent an "is-a"
relationship in C++ in addition to its role as specifying
an interface. Using realization drive home the fact that
you are using that abstract class as an interface. Rose
may already make this clear by how it renders UML but
other tools may not.
Having said that, if I saw generalization used instead of
realization I'd know what you meant and not think twice
about it.
> Still it worries me that a realization graphically
> appears (at least in Rational Rose) like a mere
> association (straight solid line), unless we specify a
> prototype <<realize>> (which is quite readable but a
> bit heavy) whereas generalization has a clearly
> different representation (and as interfaces have a
> different representation as classes, the intent is
> clear as well).
Realization is typically represented graphically by what looks like a generalization relationship (or specialization depending on your perspective) except the line is dashed, not solid.
-S
quite a good explanation (Realization) when I think it from the view of OO language : Java. - interfaces as defined from the http://java.sun.com as
An interface defines a protocol of communication between two objects. An interface definition is comprised of a declaration and a body.
The section The Interface Declaration shows all possible components of an interface declaration. The interface body contains declarations, but no implementations, for a set of methods. An interface might also contain constant definitions. A class that implements an interface must implement all the methods declared in the interface. An interface name can be used anywhere a type can be used.
Hope it help!
Nathan
