Re: Help with design please
From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/31/04
- Next message: Nick Hounsome: "Re: Should 'public virtual' always become 'private virtual'? & using private inheritance"
- Previous message: Uncle Bob (Robert C. Martin): "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Danny: "Re: Help with design please"
- Next in thread: Uncle Bob (Robert C. Martin): "Re: Help with design please"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 31 Jan 2004 18:18:58 GMT
Responding to Danny...
>>Your high level description says you are reporting on ... machines and
>>processes. However I see no Machine class. If it is important enough
>>to mention in a one-sentence problem description, I would expect it to
>>show up in the model.
>
>
> Well I decided to call it a process, for want of a better tern, this
> was because the process may involve several machines or a persons
> task, such as packing.
Which sounds like a Process is something different than a Machine. What
you are saying here is:
1 <role> defines tasks of 0..*
[Process] ---------------------------------- [Person]
| 1
| <role>
|
|
| involves
| 0..*
[Machine]
ignoring Tasks and the likely relationship that Person may control a
Machine.
>
>
>>I think you are overusing aggregation. An Operator is part of a
>>Process?!? Aggregation and composition are special associations that
>>describe Whole/Part semantics.
>
>
> A machine has an operator, and packing is carried out by a person. The
> idea of the program is to give some idea of who is doing what amd when
> on the factory floor, therefore I thought I may as well encapsulate
> the operator in the process, as the factory thinks in processes
> related to shifts and products.
That's fine. But you are using the aggregation association symbol.
Aggregation describes a Whole/Part semantics which is not in evidence in
your description.
As far as operators and processes are concerned, they seem to be
different entities. If you encapsulate a Person in a Process, that
hides a significant problem space entity and it trashes the cohesion of
Process. An important goal of OOA/D is to abstract recognizable
entities from the problem space that are cohesive. What you describe
here indicates the problem space is structured something like:
1 employed as
[Job] --------------------------- [Person]
A defines role of * | *
| | composed of
+----------------+-------------+ |
| | |
[Operator] [ShippingClerk] |
| 1 | 1 |
| controlled by | packed by |
| | |
| | |
| assigned to | ships |
| 1 fabricated by * | 0..* |
[Machine] --------------------- [Stuff] |
1 created by | |
| | assigned to
| * is assigned | 1
[Process] ---------------------- [Shift]
executed during 1
This is not intended to be a solution. For example, it doesn't deal
with the likely situation that processes are executed across shifts and
the Stuff is a product of multiple machines and processes. My point
here is simply that one should look at the problem space entities that
stand out in the problem statement and abstract them as a starting
point. IOW, look for more classes to separate concerns rather than less
initially. If is easy to eliminate trivial classes that don't add
anything but it can be messy to refactor god classes that are too complex.
>
>
>>You have roles on only some of your relationships and even then only for
>>one end. Roles enhance the understanding of a Class Diagram enormously,
>>especially when the roles on each end of a relationship capture
>>different aspects of the participation semantics.
>
>
> Lazyness on my part i'm afraid.
A bad habit. My model above is unlikely to fit your problem space.
However, with the roles you will have a much easier time determining
where the fit is incorrect.
The real value in defining good roles, though, lies in forcing one to
think about the abstractions. When you develop models as a team effort
you will find that getting roles correct often uncovers significant
disconnects in how the solution is viewed by different team members.
The value lies in getting everyone on the same semantic page.
>
>
>>I assume the arrows with solid arrows and no multiplicity are subclass
>>relationships with the arrow on the superclass end. If so, all your
>>superclasses have only one subclass. That's a no-no. In the is-a
>>relationship the union of subclass members must be a complete set of the
>>immediate superclass members. So a single subclass must contain all the
>>members of its superclass, which would make it redundant with the
>>superclass.
>
>
> Sorry, don't know what youre saying. Do you mean that I should show
> all the derived classes from the base in the diagram?
You should show all those subclasses that are relevant to the problem.
Consider my [Job] class. There may be a gazillion job titles in the
company. But if only [Operator] and [ShippingClerk] are relevant to
your problem, then the set of relevant Jobs only includes only those
that are Operators or ShippingClerks. That set is a complete set of
Jobs _relative to the problem in hand_.
SImilarly, if [Operator] is the only set of Jobs relevant to the
problem, one doesn't need the [Job] superclass. Any common properties
of [Job] can be rolled into the [Operator] class that represents /this/
problem's view of a job title.
What if someone has already developed a big, honking subclassing
hierarchy for [Job] and you want to reuse it but you only access
[Operator] members? How do you account for the common properties that
are defined in the [Job] superclass? The short answer is: Don't worry
about reuse.
Such reuse is a pure OOP issue that is not of concern in the OOA/D. In
the application OOA/D you focus on what you need to solve the problem in
hand. So you would write up the [Operator] definition as you need it
(i.e., a simple class that includes Job properties). Whoever does the
OOP implementation (presumably you) can note the fit to the pre-existing
is-a and insert the appropriate boilerplate for the inheritance into the
code.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
(888)-OOA-PATH
- Next message: Nick Hounsome: "Re: Should 'public virtual' always become 'private virtual'? & using private inheritance"
- Previous message: Uncle Bob (Robert C. Martin): "Re: TDD: Test-Driven Design or Test-Driven Development?"
- In reply to: Danny: "Re: Help with design please"
- Next in thread: Uncle Bob (Robert C. Martin): "Re: Help with design please"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
