[UML Forum] Primitive Type musn't be a DataType
Timothy Marc
Hi again,
another question regarding PrimitiveTypes. With respect to the UML2 spec, PrimitiveTypes may not have any logical structure. That means, they won’t have operations and attributes within UML (the spec mentiones clearly that operations and structures may be defined outside of the scope of UML). But in the spec, PrimitiveType extends DataType. A DataType specializes the Classifier’s union regarding to ownedAttributes and onwedOperations. The conversed argument is that PrimitveTypes are technically prepared to own attributes and operations.
I was wondering why PrimitiveType doesn’t extend Classifier directly. Since Classifier is abstract and only describes union associations to other relevant metaclasses (property, behavioral feature etc,) a PrimitiveType would never be able to own such elements, due to missing concrete subsets of the superclass’ unions.
What do you think?
Cheers
Timothy
sanja...@wipro.com
Hi,
Can anyone provide a tutorial that explains the classes and diagrams step by step?
Regards,
Sanjay Amin
--
You received this message because you are subscribed to the Google Groups
"UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.
H. S. Lahman
> another question regarding PrimitiveTypes. With respect to the UML2
> spec, PrimitiveTypes may not have any logical structure. That means,
> they won�t have operations and attributes within UML (the spec
> mentiones clearly that operations and structures may be defined
> outside of the scope of UML). But in the spec, PrimitiveType extends
> DataType. A DataType specializes the Classifier�s union regarding to
> ownedAttributes and onwedOperations. The conversed argument is that
> PrimitveTypes are technically prepared to own attributes and operations.
>
What OMG is trying to describe is what everyone else calls and Abstract
Data Type (ADT). That is, a data structure that can be hidden behind a
scalar knowledge attribute. Thus the details of the data
implementation's complexity are not of interest at the level of
abstraction of the containing subsystem so they are hidden. The use of
ADTs is critical to the OO paradigm because it allows a flexible view of
logical indivisibility, which is essential to "flattening" functional
decomposition trees to avoid hierarchical dependencies when supporting
peer-to-peer behavior communications among objects. However, flexible
logical indivisibility also applies to data when trying to mange
complexity of data structures and hide computing space implementations.
The classic example is Person.Name. Name is an ADT that hides both the
semantics of {FirstName, LastName} and the semantics of a text string
composed of multiple characters. Within a subsystem that doesn't care
about such details, one can manipulate the Name as a scalar (e.g., to
compare it to other Names). At the same time one still gets considerable
semantic discrimination because Person.Age is a quite different thing.
But if one needs to access individual characters or FirstName, one needs
to explicitly expand the ADT into its components in a subsystem at a
lower level of abstraction. For accessing characters one would also need
to elevate the ADT to a first class object (e.g., String) that would
have an interface that exposed the characters. For accessing the
semantics of {FirstName, LastName} one would need to replace Person.Name
with separate attributes, Person.FirstName and Person.LastName.
> I was wondering why PrimitiveType doesn�t extend Classifier directly.
> Since Classifier is abstract and only describes union associations to
> other relevant metaclasses (property, behavioral feature etc,) a
> PrimitiveType would never be able to own such elements, due to missing
> concrete subsets of the superclass� unions.
>
The notion of 'primitive type' captures the idea that at a particular
<high> level of abstraction the Name is logically indivisible. Since
this only has meaning to an object's knowledge attributes, it is a
specialization of Data Type. A Classifier, OTOH, already has a notion of
being comprised of identifiable properties so directly specializing an
ADT from a Classifier would be inappropriate; that is already done via
Data Type and the Primitive Type deals with the special case of a scalar
Data Type.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Ken Lloyd
From: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com] On Behalf Of sanja...@wipro.com
Sent: Friday, July 09, 2010 5:10 AM
To: umlf...@googlegroups.com
Subject: RE: [UML Forum] Primitive Type musn't be a DataType
sanja...@wipro.com
Hi Ken,
Thanks a lot for the information. The links are pretty useful.
I am using Java. I have a java class and I am calling other java class by creating an instance and calling some of its method. Is this indicates dependency or association? Where can I find few examples related to class diagrams and relationships?
Regards,
Sanjay Amin
Timothy Marc
Responding to Sanjay…
It depends on what do you want to express. Dependencies can be used to say, that class A uses class B somehow, this indicates the usage of class B’s methods as well. It is a kind of meta-concept, saying that there is a logical relationship between both classes. By using an association, you specify an attribute of type of class B in class A, meaning that there is a technical relationship between A and B manifested in the attribute, representing one association’s end.
But I think you have to study some simple “Hello World”-Examples… there are a lot of UML tuts. Just google for it.
Regards
Timothy
vinay kr
Can you please help me I want to learn UML from scratch.
How to design class diagram ,object diagram in UML.
Can you please suggest any source over internet from where i can learn UML language othet than from basic
other than
www.uml.org/
www.omg.org/
Thanks
Vinay
Please help me then I would be thankful to you
Ken Lloyd
From: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com] On Behalf Of vinay kr
Sent: Monday, July 12, 2010 6:04 AM
To: umlf...@googlegroups.com
Subject: Re: [UML Forum] Primitive Type musn't be a DataType
Ken Lloyd
sanja...@wipro.com
Hi Ken,
I know about the relationships categorized as following.
• association
• aggregation
• composition
• generalization
• dependency
What I want to know is precise definitions of each and when to use that kind of relationship (scenario). I read some UML documents, but still not clear about when to use dependency and when to use association.
Following is a simple example which I have asked in my previous email. Can you tell me it indicates dependency or association? As per my understanding it is dependency. If so, what is association?
Class A {
B b = new B();
String name = b.name();
}
Class B {
private String name() {
return “sanjay”;
H. S. Lahman
> Hi Ken,
>
> I know about the relationships categorized as following.
>
> � association
>
> � aggregation
>
> � composition
>
> � generalization
>
> � dependency
>
> What I want to know is precise definitions of each and when to use
> that kind of relationship (scenario). I read some UML documents, but
> still not clear about when to use dependency and when to use association.
>
It is confusing because they model different things so they can overlap
for the same classes. The first four describe relationships between
n-ary relations in relational theory. Dependency describes physical
coupling at the 3GL level. That is, dependency describes what one object
must know about another to collaborate with it. More specifically, what
a 3GL compiler or interpreter must know to generate correct object code
for the client. Note that dependency is not relevant for generalization
in an OO context because a single object instantiates the entire tree.
Also note that in UML one can turn any of the first three into a
dependency by simply using a dashed line and adding an arrowhead, thus
recognizing the overlap.
Therefore, using association vs. dependency in many situations becomes a
judgment call about what is more important to the problem solution. [It
is also a context issue. In OOA/D physical coupling is not an issue so
one does not need dependencies at all. (The MDA profile I use for OOA
does not include them.) However, it is critically important to OOP
coding so if one is doing something like reverse engineering from an
OOPL, one will tend to use dependencies everywhere.]
<aside>
FWIW, I have never seen a reason for including dependencies in UML, even
when modeling OOPL code. In fact, any relationship navigation for
collaboration will involve a dependency of some kind because of 3GL type
systems and the need for compilers/interpreters to map directly to
hardware computational models. So they are really kind of redundant at
that level of modeling.
The reason dependencies are important to OOP is that during dependency
management refactoring one strives to reorganize the code so that it
forms a directed, acyclic graph of dependencies. That is, dependencies
are unavoidable, but the code will be more maintainable if they are only
one-way. So modeling them in UML just identifies directionality. But it
does so only after one has resolved directionality during OOP. IOW, it
is just a sanity check; if you need to put an arrowhead on both ends
that means your OOPL code is poorly formed.
Trying to ensure a DAG in OOA/D prior to OOP is, IMO, overspecification
of OOP. The reason is that two of the important tools for decoupling
during OOP are generalization and polymorphic dispatch. Generally one
introduces far more of these during OOP than one needs to unambiguously
describe the software design during OOA/D. Such modification of the
OOA/D model to resolve a pure 3GL problem is not a good idea.
</aside>
> Following is a simple example which I have asked in my previous email.
> Can you tell me it indicates dependency or association? As per my
> understanding it is dependency. If so, what is association?
>
> Class A {
>
> B b = new B();
>
> String name = b.name();
>
> }
>
I know you are just trying to provide a simple example, but I need to
point out that what you are doing here is bad OOA/D practice. A.name is
semantically identical to B.name and that is a violation of 3rd Normal
Form. 3NF can be paraphrased as: an attribute must be dependent on the
object identity, only the object identity, and nothing but the object
identity. For the same name to be dependent on two different object
identities is a no-no. In an OO context, this also applies to behavior
responsibilities; objects of different classes cannot have the same
behaviors.
As for whether this is a dependency or not, that depends on the OOPL. In
a language like C++ that supports embedded objects, this would probably
be modeled as a composition because it is embedded. That means it is
part of A and A controls its life cycle.
In contrast, in a language like Java, 'b' would be a reference and all
one is doing is instantiating a simple 1:1 association between A and B.
In this case, since one is modeling an implementation language, one
would probably use a dependency to model that in UML. That is because A
must know what type B is and that it has a specific attribute, 'name'.
More to the point, to write the assignment object code for A a
compiler/interpreter must know what the hardware representation of
B.name is.
Timothy Marc
Responding to Sanjay…
Your snippet represents neither an association nor a dependency. As I mentioned in my previous mail, a dependency is more or less a meta-concept, indicating that a class is using another class. For my understanding a dependency would result in the javadoc of class A.
Look to a similar snippet of your’s:
Class A {
B b;
}
Class B {
private String name() {
return “sanjay”;
}
}
This would result in an association between A and B, indicating that A owns a reference to B, but it is not instantiated yet. B of type B is an attribute of class A. This is exactly the level of information an association is made for.
An instantiation and operation call can be done by connecting A and B within an CompositeStructureDiagram. These connections can be used to describe Activities or Interactions, where you’re able to call operations.
HTH, Timothy
Ps. To all UML purist: I know, a composite structure diagram is not equivalent to an instantiation, but It is close to.
Ken Lloyd
"A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s)."
-- UML 2.2 SuperstructureTo: umlf...@googlegroups.com
Subject: [UML Forum] Understanding Relationships for Class Diagram
Bob Tarling
sanja...@wipro.com
Thanks all for your inputs.
My question is very simple.
- I have a class named A
- I have a class named B
- I am creating an instance of class B inside class A
- I am calling a method of class B inside class A after creating an instance of class B
- I am using an output of the operation of B in class A for further processing
While creating an UML class diagram, do I need to draw dependency from A to B ? If not, is it an association?
What are the precise (perfect) definition of all the relationships in terms of class diagram?
I hope now I may get precise answers J
Regards,
Sanjay Amin
Bob
H. S. Lahman
> My question is very simple.
>
And it was answered in my previous message. Evidently I was not clear
enough, so I will try again...
>
>
> - I have a class named A
>
> - I have a class named B
>
> - I am creating an instance of class B inside class A
>
This *sounds* like composition; B is part of A's implementation and
therefore A control's B's disposition (life cycle). But, as I explained
in my previous message, it depends on the OOPL you are modeling (i.e.,
whether 'new' yields a reference in that particular create context). And
even then it may not be modeled that way in a UML OOA/D model.
The problem is that code examples often confuse the issue. The OOPLs are
all 3GLs and they make serious compromises with the hardware
computational models. For example, in the OOPLs there is no distinction
between message and method; the method signature is the message. But in
OOA/D where UML is used that distinction is critically important and it
is one of the defining characteristics of the OO paradigm.
What you are doing here is asking how to model OOPL code. But OOPLs are
intended to implement OOA/D designs so that is very much like the tail
wagging the dog. In fact, the OOPLs are actually a rather poor place to
learn what the OO paradigm is about because of their compromises. Thus
reverse engineering models in UML of OOPL code generally tend to be poor
models from the perspective of OOA/D. One reason is that design
information about the problem domain is lost by the time one gets to
OOPL code so such models are often ambiguous or even incorrect about
what is really going on in the customer's problem space. That is, such
models do not separate customer requirements from design decisions.
So when you ask how to model an OOPL code fragment in UML, the answer is
often quite ambiguous. Composition is a good example. In C++ one can
embed one problem space object in another. That approach is the most
obvious way to implement UML composition when coding in C++. But the C++
developer might have had some other reason in mind when choosing to
embed the object that had nothing at all to do with logical Whole/Part.
Then modeling that code with composition in the UML model would be
incorrect.
IOW, the semantics of the OOA/D model is driven by the problem space.
When one tries to model OOPL code, one is in the computing domain rather
than the customer's problem domain. So trying to work backward to the
customer's problem domain is inherently ambiguous.
</aside>
> - I am calling a method of class B inside class A after
> creating an instance of class B
>
> - I am using an output of the operation of B in class A for
> further processing
>
That means that A is dependent on what B does. More relevant to UML
dependency, it means that the compiler needs to know how B implements
the output at the hardware level in order to generate the correct object
code for A. As I also explained in my previous message, that physical
knowledge that the compiler needs to know about B is what determines
dependency.
>
>
> While creating an UML class diagram, do I need to draw dependency from
> A to B ? If not, is it an association?
>
IMO, you never *need* to draw a dependency in an OOA/D model. There may
be times in certain contexts where it may be useful to do so to provide
good communication of the design. That depends entirely on the modeling
context and there is no hard rule for when to use dependencies, other
than Whatever Works.
In addition, you seem to feel that dependency and association are
mutually exclusive. They are not. You should think of a dependency as a
qualification of a particular type of association.
>
>
> What are the precise (perfect) definition of all the relationships in
> terms of class diagram?
>
>
>
> I hope now I may get precise answers J
>
Good luck with that. UML is simply a modeling notation. What you model
is a matter of problem space and modeling methodology. The UML metamodel
provides a generic semantics for the model elements. But how and whether
they are used in a design depends on the problem context and the design
methodology.
Timothy Marc
As mentioned, this depends on how your code is structured.
If you’re creating a global attribute of Class B within Class A, this can be achieved by an association. But an association doesn’t indicate the calling of an operation. Therefore, you must make use of a behavioral description in the classifier behavior. Within classifier behavior you’re able to describe the steps, that should be executed after the classifier is instantiated.
If the operation call of Class B is done within an operation of Class A, you could make use of dependencies, indicating that A calls B somehow.
You must be aware, that a dependency is very informal kind of relationship, whereas an association always results in an attribute in the associated classes, as long as the other association is navigable.
So, if you’re just want to indicate that A can call B, the association is enough. Is you want to model the dynamic behavior of A, you need behavioral descriptions for this. I would recommend an activity for this.
Cheers,
Timothy
sanja...@wipro.com
Regards,
Sanjay Amin
Wipro Technologies
+91-20 30 96 02 07 (O) | +91-95 27 00 27 37 (M) | 8540207 (VOIP)
-----Original Message-----
From: umlf...@googlegroups.com [mailto:umlf...@googlegroups.com] On
Behalf Of H. S. Lahman
Sent: Wednesday, July 14, 2010 8:47 PM
To: umlf...@googlegroups.com
Subject: Re: [UML Forum] Understanding Relationships for Class Diagram
Responding to sanjay.amin...
--