On Fri, Aug 09, 2002 at 10:25:17AM -0600, Chris Fedde wrote:
> On Fri, 9 Aug 2002 10:09:36 -0500  Garrett Goebel wrote:
>  +------------------
>  | From: Rocco Caputo
>  | > I keep looking at UML, but nothing on the web has made much of an
>  | > impression with me.  Is there a good book about UML?
>  | 
>  | UML Distilled: www.amazon.com/exec/obidos/ASIN/020165783X
>  | 
>  | > POE users should not be required to know UML.
>  | 
>  | It its done well, consumers of UML diagrams hardly have to know UML... That
>  | is to say Keep It Simple Stupid (KISS) can work for UML diagrams as well.
>  +------------------
> 
> I find much of UML very useful in the design process.  But the
> diagram->code parts of Rose seem like the smallest, least important
> part of the effort.  There are better approaches for Perl projects,
> XP, and CRC come to mind.   Casual use of ERD, lifecycle, and other diagrams
> can help illuminate a design, but it seems to me that developers spend an
> inordanate ammount of time making their "diagrams pretty" when that time
> would be better spent writing design stories and test cases.

UML should work with several software engineering processes (XP and all the
other lifecycle models). I'd like use cases more than CRC. ERD is more
data-centric than what you probably need in OO programs.

I agree that people tend to make nice looking diagrams without content. But
I don't see how one could do hat with standard UML. There is no real
way to decorate without expressing content (apart from notes). So it might
be wrong but there should be a good content ratio :)

I don't think that the intention behind UML is to enable people to
visualize design _after_ they created the design. It should be used as
notation _during_ design, replacing handwritten comments, thoughts, and
all these not so portable way.

So having a know notation with a fixed meaning that everybody agrees one
certainly makes other people's design notes more readable and can
be treated as a part of the components contract.

You are right when saying that code generation is not so important. But
the more the object system knows about the components the more it can do.
Basic Perl modules don't carry that information anymore, it is hidden
in the private design notes of the developer, the ambiguous documentation
(unless in mathematical form) and the code. POE cannot extract it from there,
and it is hard for other developers as well.


torvald

Reply via email to