Re: [UML Forum] valid to use both an aggregation and dependency connector between 2 classes?
Scott Finnie
On 16/04/13 21:21, dotnetguy wrote:
> Hello I have 2 classes in a parent child relationship.
Why is it a "parent-child" relationship? What Domain facts does the
relationship represent? It's a good idea to ensure you understand that
before deciding on how to represent it. How would you describe the
relationship as a pair of sentences?
For example:
- Each Order consists of one or more OrderLines
- Each OrderLine forms part of exactly one Order
>
> The parent has the child, so this indicates the need for an
> aggregation relationship.
What do you mean "has the child"? See above.
>
> However, the parent also sets properties on the child, so I want to
> clearly indicate this in UML as well.
>
> I thought about connecting the parent to the child with an aggregation
> connector as well as a dependency (dotted arrow) connector.
Notwithstanding question above, nothing you've said so far needs
anything more than a simple binary association. If you need to express
that the parent can 'see' (navigate to) the child then put an arrow on
the relationship in that direction. That would enable the parent to set
properties on the child. What about the other way though: can the child
'see' the parent? If it's navigable in both directions then you don't
need any arrows.
>
> Does this seem like a reasonable approach for this scenario or would
> you do this differently?
I doubt you need two relationships. A simple binary, with the meaning
of the relationship expressed in both directions, is more likely to
communicate the purpose of the relationship better. So I'd start there.
If you want to go further, ask:
1. Is the parent responsible for creating and deleting child instances?
2. Once created, can a child be updated to point to a different parent?
If the answer to both is 'yes' then you could use a Composition
relationship instead of the straight binary. As for Aggregation: I
never use it personally. It offers no useful semantics over and above a
simple binary(*).
hth.
--
(*) There is one case where an Aggregation has clearly different
semantics over a straight binary. If you have a recursive relationship,
Aggregation doesn't allow loops in the object graph. However that's a
pretty obscure property that you'd most likely have to point out
anyway. So it's simpler just to stick with simple binaries.
>
> --
> --
> You received this message because you are subscribed to the Google
> Groups "UML Forum" group.
> Public website: www.umlforum.com
> 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?hl=en
>
> ---
> You received this message because you are subscribed to the Google
> Groups "UML Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to umlforum+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Remy Fannader
http://caminao.wordpress.com/how-to-implement-symbolic-representations/patterns/functional-patterns/connector-patterns/
Hello I have 2 classes in a parent child relationship.
The parent has the child, so this indicates the need for an aggregation relationship.
However, the parent also sets properties on the child, so I want to clearly indicate this in UML as well.I thought about connecting the parent to the child with an aggregation connector as well as a dependency (dotted arrow) connector.
Does this seem like a reasonable approach for this scenario or would you do this differently?
H. S. Lahman
> Hello I have 2 classes in a parent child relationship.
>
> The parent has the child, so this indicates the need for an
> aggregation relationship.
(Data Modeling) or subclassing (OOA/D). Either way it would be a
generalization relationship in UML. There are some other contexts, like
modeling hierarchical trees, where the notion of parent/child is
relevant without generalization, so you need to put some words around
what you think a parent/child relationship is in your problem space.
Also, aggregation implies a Whole/Part semantics. It is hard to think of
a context where a Child is a part of a Parent except during pregnancy
and then it would still be a stretch.
>
> However, the parent also sets properties on the child, so I want to
> clearly indicate this in UML as well.
>
> I thought about connecting the parent to the child with an aggregation
> connector as well as a dependency (dotted arrow) connector.
>
> Does this seem like a reasonable approach for this scenario or would
> you do this differently?
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
Imagine how much more difficult physics would be if electrons had feelings
-- Richard Feynman
Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared.
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
software book: Model Based Development, Addison-Wesley, 2011
geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972
Scott Finnie
On Apr 18, 2013 5:08 PM, "dotnetguy" <andrew.d....@gmail.com> wrote:
>
> Composition is 1:1 whereas a repeater will by definition have many rows which indicates aggregation.
No, Composition is 1:Many.
>
> Using the dotted dependency arrow in addition to the aggregation symbol shows that the parent actively sets properties on the child.
>
> This is a very effective visual metaphor that effectively illustrates the relationship for a casual viewer of the diagram.
>
> However, this may violate proper UML conventions. Not sure if there is a proper way to do this in UML that illustrates the relationship and interaction as well to the casual viewer?
Define "proper" :-)
It's probably not how most people would do it (from what you've said, Composition would cover it).
However: the purpose is communication. If using your convention works for you and your stakeholders then don't be a slave to the language police. As long as you both/all understand the same thing from the diagram then don't be afraid to step outside convention. That said, you're going to have some extra work and perhaps some increased visual noise if the diagram gets big.
Personally i'd probably go with composition from what you've told us. Provided of course all parties interpreted it the same way. But if your idiom works for you & yours then stick with it.
Hth.
- Scott.
>
>
>
> On Tuesday, April 16, 2013 1:21:31 PM UTC-7, dotnetguy wrote:
>>
>> Hello I have 2 classes in a parent child relationship.
>>
>> The parent has the child, so this indicates the need for an aggregation relationship.
>>
>> However, the parent also sets properties on the child, so I want to clearly indicate this in UML as well.
>>
>> I thought about connecting the parent to the child with an aggregation connector as well as a dependency (dotted arrow) connector.
>>
>> Does this seem like a reasonable approach for this scenario or would you do this differently?
>>
H. S. Lahman
I'm guessing some of you guys are familiar with .NET WebForms.
My condolences. How to Learn Bad OO Practices in 2000 Easy Lessons.
I'm working on a WebForm that has a user control with a repeater. And that repeater has a child user control that the parent sets property values on.
I agree with Wright. Webforms is an implementation technology while UML encodes OOA/D. Figure out what the user wants to do with the UI and model that. Then figure out if and how you might want encode it in WebForms during OOP.
(Caveat: Given this is a UI, if you want to make the UI reusable, then the UI paradigm becomes the problem space. In that case, you might want to model notions like Control, Repeater, and Row explicitly. However, such a design probably would not be portable to a system without WebForms.)
You might want to look at the GoF Composite design pattern.
Gus Nkwocha
It sounds to me as though the appropriate UML construct to use in this situation is to depict the repeater as an association class connecting the user control on the WebForm with the child control.
This is conditional on whether the modelling tool you use supports this and avoids the need to create two relationships. The other plus is that it is valid UML.
Sent from my smartphone
Gus Nkwocha