Re: UML Question (Object <-> ObjectFinder?)

On Sat, 25 Jun 2005 17:03:19 GMT, "H. S. Lahman"
<h.lahman@xxxxxxxxxxx> wrote:

>Responding to Martin...

>>>Let's try getting specific. Name one feature of SM that you feel is
>>>oriented more towards SA/D than a corresponding feature of OO
>>>development.
>>
>> Let's start with the notation. ER diagrams, Data flow diagrams, and
>> state machines.
>
>That's what I suspected. The official notation for SM today is a subset
>of UML. It doesn't even use any stereotypes that aren't defined in UML.

So are you saying that SMOOA has only recently become separated from
SA/SD by adopting UML? Or are you saying that SMOOA found a way to
use a subset of UML to replace the older notation of ER diagrams, Data
Flow Diagrams, and State Machines?

> Are you contending that UML was not developed as a notation for OOA/D?

UML was developed as a marketing strategy to attract business for
Rational. It is possible, of course, to denote OO systems with UML.
It is also possible to denote any other kind of system with UML,
including systems that cannot be built.

The use of a notation does not mean you are following any particular
kind of discipline. I can use the English language to write Rap or
Shakespear.

> More specifically...
>
>They aren't ERDs!!!! They are UML Class Diagrams with exactly the same
>semantics (except SM /requires/ attributes to be ADTs and places more
>constraints on things like subclassing). When SM moved to UML all that
>had to change were cosmetic things like the arrowheads and 'c' on
>relationship ends going to 0..*.

They are ERDs, and always have been. That's not a bad thing. ERDs
are very useful.

Now I will agree to a certain extent that they are more behavior
models than data models. (Although that point was very difficult to
detect in Steve and Sally's first book "Modeling the world in
objects".) I will also agree that being behavioral models is something
that they have in common with OO models.

On the other hand, the tie back to SA/SD is very clear. Again, this
is not pejorative, SA/SD was, and still is, a very powerful technique,
and Mellor managed to add some powerful semantics to it. But the
roots are clear.
>
>SM never used DFDs per se. It used a special form of DFD called Action
>Data Flow Diagram for describing methods.

Not quite methods. They described the actions executed by FSMs.
There is a difference.

>The ADFD maps exactly into a
>UML Activity Diagram with the same semantics.

I'd like to see a side by side comparison. I think that there are
some differences.

>(It just doesn't use the
>object elements because the processing was at the method implementation
>level.)

I'm not sure what a sequence diagram is, if you don't have objects in
it.
>
><Aside>
>Where do you think the action semantic meta model that was introduced in
>v1.5 came from? It was mainly due to pressure by the translation people
>who pointed out that lack of an execution model was a major hole in UML
>for using either ADs or AALs.

Yes, I know. Actually I think the adoption of an action syntax in UML
is unfortunate, or at least a distraction. There are too many tool
vendors involved with the definition of UML, and it shows. Everybody
is trying to figure out the next generation tool, and they are pushing
their ideas into UML as a way to fertilize the field. Too few people
are thinking about the current needs of the industry.

>> OK.
>>
>> void Payroll::payCycle() {
>> foreach Employee e in EmployeeDataBase {
>> pay(e);
>> }
>> }
>>
>> Payroll::pay(Employee e) {
>> if (e.TodayIsPayday()) {
>> Money pay = e.CalculatePay();
>> e.DeliverPay(pay);
>> }
>> }
>>
>> ThreadedPayroll::pay(Employee e) {
>> fork(
>> Payroll::pay(e)
>> }
>> }
>> }
>>
>> Now we have to implementations of Payroll. One that is sequential,
>> and the other that is parallel. The main algorithm has no idea which
>> is in play.
>
>And you rewrote it, too, by moving pay(). B-)) The prosecution rests.

Rest all you like, but I now have a system that is decoupled from
sequential execution. And I didn't have to do it with SMOOA. If such
decoupling is important, then it can easily be achieved.

>> No, we *aren't* telling it exactly what to do. That's really the
>> whole point behind OO. All we are doing is sending a message. The
>> relieving object decides what to do. The fact that the messages are
>> named is the way we distinguish one message from another.
>
>Au contraire. As an experienced OO developer /you/ may think of it as a
>message because you know that they are separated in OOA/D and understand
>the implications of that separation. But at the OOPL level there is no
>distinction between message and method; lexically they /must/ map 1:1.
>So one is invoking a method, not sending a message.

That's incorrect. Messages map 1:N to methods in any OO language.
This is fundamental. Given two objects that both respond to the 'f'
message, each can implement a different method. The sender (i.e. the
module invoking o.f) does not know which method will be invoked
because it does not know the type of o.


>>>And it is all
>>>defined in a single class definition for all clients to see.
>>
>> Only in static languages like C++. In smalltalk, ruby, or python the
>> clients see nothing.
>
>Actually, I think they do. The definition clearly must exist in some
>form to support dynamic type checking.

The definition exists, but in python and ruby it can only be checked
at runtime.

>> So long as the subclasses are substitutable, there is no LSP problem.
>> Disparate behaviors are not the issue. We *want* disparate behavior.
>> It's just that the behavior can't confuse the caller. That's really
>> all that LSP means.
>
>I agree, but that isn't the issue. Suppose one has:
>
> 1 attacks 1
>[Predator] --------------- [Prey]
> + run()
> A
> |
> +--------+---------+
> | |
> [Anteater] [Impala]
>
>everything is fine because even though an Anteater lumbers when it runs
>while an Impala bounds, the behavior is still running. Nor is the
>client confused _if it expects the Prey to run_. So your point is
>satisfied.
>
>But now add [Quail] as a subclass where the response is to take flight
>rather than running away. The tree is broken because the subclasses
>must all implement a run() behavior. There wouldn't be a problem if the
>OOPLs separated message and method because the superclass message could
>always be attack() and the subclasses could respond with lumber(),
>bound(), and takeFlight(), respectively. But you can only do that at
>the OOA/D level, not in OOPLs.

Balderdash. The message could be 'evade'.

BTW, I agree with your original OO instructor. Half a day is too
much. The package diagram is volatile. It changes frequently over
time. Trying to define it up-front is a losing proposition.



-----
Robert C. Martin (Uncle Bob) | email: unclebob@xxxxxxxxxxxxxxxx
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
.

Relevant Pages

  • Re: Humble opinion on UML
    ... I am not a real developer, but I use it sporadically since 1998 and I ... Even if one decides to employ OO techniques for a small application, it is even less likely that UML would be worthwhile for anything other that informal communication or sketching out design ideas. ... Activity Diagrams have been largely replaced by Abstract Action Languages because they are much easier to modify. ...
    (comp.object)
  • Re: UML: Associations between classes and packages
    ... >diagrams in UML. ... UML does not put a constraint upon this. ... >to the swing package. ... You drive the notation, don't let the notation drive you. ...
    (comp.object)
  • Re: Is UML appropriate for embedded systems ?
    ... Sequence diagrams are a good help in specifying ... The company I work for uses Rose for smartcard operating systems (a few ... The use of UML for our purpose is not obvious. ... usecases, but IMHO not for OSes or VMs ...
    (comp.arch.embedded)
  • Re: UML: Is it allowed to introduce custom stereotypes on classes? What about methods?
    ... >{enumeration} after the class name. ... I know UML knows such things as, ... >modelling methods as abstract or even static, ... understand these diagrams, understands the diagrams. ...
    (comp.object)
  • Re: Class Design Tools?
    ... you draw diagrams of your code ... light understanding of UML class diagrams. ... I do not answer questions on behalf of my employer. ... >> programmer helping programmers. ...
    (microsoft.public.dotnet.general)