Class diagram
[298 byte] By [al0701] at [2007-9-27 21:23:53] 
I would like to know that if I have a constructor of class or some methods which declare new instance of the other class, the first class will be associated with the other class.For exampleclass A{A(int tmp){ B b = new B();}} class
Yes it is associated.(Ignoring a lot of unknowns there such as different types of associations and whether the example provides to much detail for design, etc.)
jschell at 2007-7-7 3:18:49 >
> Yes it is associated.
>
> (Ignoring a lot of unknowns there such as different
> types of associations and whether the example provides
> to much detail for design, etc.)
But then on a very top level you might not want to go into that much of the details during the first iteration.
nome02 at 2007-7-7 3:18:49 >
> > Yes it is associated.
> >
> > (Ignoring a lot of unknowns there such as different
> > types of associations and whether the example
> provides
> > to much detail for design, etc.)
>
> But then on a very top level you might not want to go
> into that much of the details during the first
> iteration.
Eh? First iteration of the design? Are you saying that you should create both classes but not associate them on the first pass?
jschell at 2007-7-7 3:18:49 >
You must understand that UML is supposed to give you views of things that are important at a particular perspective. If in a view you do not require to show the details - then by all means do not. However, all the information of the classes must be captured somewhere, otherwise your model incomplete. I suggest you make a model of high granularity and show all the important relationships. As you go into models or rather finer aspects - elide certain coarse grained relation. You shall have to excercise your judgement on that one :D
Ironluca
Ironluca at 2007-7-7 3:18:49 >
The way to show that one class is associated with another is to create an association between the 2 classes in the class diagram. Normally constructors are not shown in class diagrams.
If you wish to be more explicit - you can show the construction in your sequence diagram.
Basically with UML diagrams you hide what is irrelevant and show what needs to be shown.
Regards,
Fintan
CelticPhantom at 2007-7-7 3:18:49 >
> You must understand that UML is supposed to give you
> views of things that are important at a particular
> perspective. If in a view you do not require to show
> the details - then by all means do not. However, all
> the information of the classes must be captured
> somewhere, otherwise your model incomplete.
If the classes do not contain information relevant to the design then it is incomplete. Not all information is relevant to the design however.
jschell at 2007-7-7 3:18:49 >
>If the classes do not contain information relevant to the design then >it is incomplete. Not all information is relevant to the design however.
Replace "design" with "view" (not to be confused with "views" of a model) and I am with you. Otherwise, I beg to differ as "design" is "view" at a "model" level - much more detailed than the usage of "view" (as explained above).
Ironluca
Ironluca at 2007-7-7 3:18:49 >
> >If the classes do not contain information relevant to
> the design then >it is incomplete. Not all information
> is relevant to the design however.
>
> Replace "design" with "view" (not to be confused with
> "views" of a model) and I am with you. Otherwise, I
> beg to differ as "design" is "view" at a "model" level
> - much more detailed than the usage of "view" (as
> explained above).
>
Design is a common generic term and my usage of it is correct.
Now you might be referring to a specific usage for a specific design methodology (although I have not seen that usage before.) If so you will need to provide the context to me so I can understand to what you are referring.
jschell at 2007-7-7 3:18:49 >
> > >If the classes do not contain information relevant
> to
> > the design then >it is incomplete. Not all
> information
> > is relevant to the design however.
> >
> > Replace "design" with "view" (not to be confused
> with
> > "views" of a model) and I am with you. Otherwise, I
> > beg to differ as "design" is "view" at a "model"
> level
> > - much more detailed than the usage of "view" (as
> > explained above).
> >
>
> Design is a common generic term and my usage of it is
> correct.
>
> Now you might be referring to a specific usage for a
> specific design methodology (although I have not seen
> that usage before.) If so you will need to provide
> the context to me so I can understand to what you are
> referring.
>
>
Yep Design is a common generic term but as per UML you design a system. A system has subsystems. A model is a simplification of reality, an abstraction of a system, created in order to better understand the system. A view is a projection of a model, which is seen from one perspective or vantaeg point. What seems relevant in one view might seem otherwise in another though they are both in the same design. The view knows about the model but the model doesnt know about the view. So the idea is just to bring forward the difference b/w the two.
nome02 at 2007-7-7 3:18:49 >
>
> Yep Design is a common generic term but as per UML you
> design a system.
Ok.
But my first comment applied to design in general not specifially to UML. There are other design methodologies and this forum is not directed solely at UML. And other design methodologies use associations.
> A system has subsystems. A model is
> a simplification of reality, an abstraction of a
> system, created in order to better understand the
> system. A view is a projection of a model, which is
> seen from one perspective or vantaeg point. What
> seems relevant in one view might seem otherwise in
> another though they are both in the same design. The
> view knows about the model but the model doesnt know
> about the view. So the idea is just to bring forward
> the difference b/w the two.
>
Secondly, repeating what I said again.
If the classes do not contain information relevant to the design then it is incomplete. Not all information is relevant to the design however.
Now in UML it is certainly true that one view might contain information that another view does not.
But then I wasn't referring to views. I was referring to designs.
And designs, regardless of the numbers of components in the design, do not need to reflect every specific in the implementation. And designs that do so are either wrong or are doing so because the design tool supports code generation and their implementation phase is being done using the design tool. But that still makes it part of the implementation and not part of the design.
jschell at 2007-7-7 3:18:49 >
>
> Yep Design is a common generic term but as per UML you
> design a system.
nome02 has quite eloquently supplied the context which you asked for - I shall not further elaborate it.
>But my first comment applied to design in general not specifially to >UML. There are other design methodologies and this forum is not >directed solely at UML. And other design methodologies use >associations.
Please let it be noted that the original question contained "class diagram" - which necessarily makes it inclined towards UML (no further comment on that).
>Secondly, repeating what I said again.
>If the classes do not contain information relevant to the design then >it is incomplete. Not all information is relevant to the design >however.
Corrective Editing:
If the classes do not contain information relevant to the [design] a view then it is incomplete (if a piece of information is not relevant to a view - refer the 2nd line). Not all information is relevant to the [design] view however.
The above is in spirit with UML.
If design is taken to be a broader term, then the following apply
If the classes do not contain information relevant to the design [somewhere (in a diagram, in a document or in any other form - it need not be only in diagram)] then it is incomplete. Not all information is relevant to the design however.
Awaiting comments
Ironluca
Ironluca at 2007-7-7 3:18:49 >
> I would like to know that if I have a constructor of
> class or some methods which declare new instance of
> the other class, the first class will be associated
> with the other class.
> For example
> class A{
> A(int tmp){
>B b = new B();
> }
> }
> class B{
> }
Hi
This is a particular type of association: composition.
For implementation:
In Association, i declare an attribute b of B type, and a method: set<Method>(B b) in A.
In Aggregation i declare an attribute b of B type, and a constructor for A(B b).
For Composition i declare an attribute b of B type, and a constructor for A().
In the implementation of this constructor i set b.
If i use b as argument in methods of A life cycle, then i can choose to clone b in b2, and use b2 as argument, or use b.
The choice to clone depends to the life cycle of objects implied.
Hi
Alex
montefusco at 2007-7-7 3:18:49 >
yes they are associated.
take it as a thumb rule,inheritence>association.
u have,dpending on the context decide whether its association or aggregation..
What is the difference between an aggregation and an association? The difference is one of implication.
Aggregation denotes whole/part relationships whereas associations do not. However, there is not likely to be much difference in the way that the two relationships are implemented. That is, it would be very difficult to look at the code and determine whether a particular relationship ought to be aggregation or association. For this reason, it is pretty safe to ignore the aggregation relationship
altogether. As the amigos said in the UML 0.8 document: ?..if you don齮 understand [aggregation] don齮 use it.?br>Aggregation and Association both correspond to the Has-by-reference relationship from the
Booch-94 notation.
clear?
thanx,,
kumar
kumar_tbs at 2007-7-7 3:18:49 >
yes they are associated.
take it as a thumb rule,inheritence>association.
u have,dpending on the context decide whether its association or aggregation..
What is the difference between an aggregation and an association? The difference is one of implication.
Aggregation denotes whole/part relationships whereas associations do not. However, there is not likely to be much difference in the way that the two relationships are implemented. That is, it would be very difficult to look at the code and determine whether a particular relationship ought to be aggregation or association. For this reason, it is pretty safe to ignore the aggregation relationship
altogether. As the amigos said in the UML 0.8 document: ?..if you don齮 understand [aggregation] don齮 use it.?br>Aggregation and Association both correspond to the Has-by-reference relationship from the
Booch-94 notation.
clear?
thanx,,
kumar
kumar_tbs at 2007-7-7 3:18:49 >
Hi
Thanks Kumar for your comment.
If i design a system from scrach, then i use (in the RUP analysis phase) only association.
Then i choose (in the RUP design phase) between association, aggregation and composition.
At the end (in the RUP implementation phase) i write the code depending from this last choice.
In particular this code is described in my last reply.
But this is an example of reverse engineering (i have the code).
In particular this is the code that i use when implement composition.
Motivation: in the example B is created by A, is only used by A, and when A is destroied, also B is destroied.
Note that if we have another use of B in A (for ex. argument of a method) i don't have sufficient info to decide between aggregation and composition. In fact if i pass B to another object, i can destroi A but B can not be destroied. In this case i have an aggregation because the B object is part of A (is created in A, and whit A) but can not be destroied whit A.
I remember that the book of the tre amigos said that the differenciation between comoposition and aggregation ( is demanded at the last phases of project. But the motivation is that there is not comprension for this choice at the begin.
The difference in the code implementation depends from language used.
I think that my java implementation of aggregation, composition, and aggregation are conforms to UML specifications.
Note that A can be a list, hashtable...
Replay for comments please.
montefuscoa at 2007-7-18 16:03:46 >
Sorry:Note that B can be a list, hashtable...and notNote that A can be a list, hashtable...
montefuscoa at 2007-7-18 16:03:46 >
Other Topics New Topic
Other Topics Hot Topic
Other Topics
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding