Kirk, There is another dimension to printers and jobs that is not
appropriately captured by either a component or an aggregation
relationship. If a printer goes down, then its current execution of a
job is lost - but the job itself could be sent to another printer.
Therefore, I would not have used the component relationship at all, but
perhaps a dependency.
BTW, within Cisco, we have a concept of a Collection with a property
that indicates if it is explicit (by explicit reference) or implicit (by
virtue of execution of a query). This has worked well for us, so far.
Andrea
> -----Original Message-----
> From: Wilson, Kirk D [mailto:]
> Sent: Monday, June 06, 2005 1:13 PM
> To:
> Subject: [wsrf] Modeling Potential Service Groups
>
> All,
>
> Just an additional thought on the problems we were discussing
> on the use of Service Groups to model various "real" things
> like printers and shopping carts:
>
> While the discussion focused on the difference between
> collections by value and collections by reference, there's
> another dimension to the issue (of collections by reference)
> that may be being ignored in the Service Group specification
> but which inevitably enters into the discussion. And that
> dimension is the semantics of the membership
> (part/whole) relationship itself. UML 1.0 had struggled with
> this problem (some would perhaps say, not too successfully)
> in its distinction between aggregation and composition. But
> the same issues came up in the conference call. For example,
> the relationship between a printer and its jobs might be
> modeled in UML 1.0 as composition because of the lifetime
> dependency implications of the relationship. Arbitrary
> containership, which characterizes the relationship between a
> shopping cart and its contents, would constitute yet a third
> semantics (which UML apparently did not feel was important
> enough to provide built-in modeling).
>
> It seems to me, in just reading the spec, that the intended
> relationship is rather loose. Which implies that we can't
> expect it to model every (any - ??) part/whole relationship
> with accuracy. And it may be necessary to explicitly
> acknowledge the semantics "mismatch" in things that are
> modeled as Service Groups. We need to answer the questions:
> "What is the expected semantics of the SVG membership relationship?"
> and "How do real world relationships differ from it?"
>
> Kirk Wilson
> Office of the CTO
> 603 823 4023
>
>
>
