Arved, I'd love to help out with the Perl prototyping if you have any pieces
that make sense to break off. I hear you about the UML. I think on some
projects it's more about control than functional necessity. 

I'm protyping an HTML ad-hoc query builder right now. Once I get the user
interface signed off, I just start fleshing the thing out until I get to the
database. Here's the sequence I'm planning--HTML mockup->add JavaScript
(button, form manipulation)->move to JSP->add Java code->add live
Data->factor out from JSP the things that make sense into the Java middle
layer (beans, maybe taglibs, output servlet, obvious things like Database
Manager and value objects may be factored out sooner). I'm at stage 3, I'll
let you know how it comes out. IMO, developing in JSP sure beats recompiling
and bouncing the web app every time (although I just discovered how to do
that w/o rebooting Weblogic). And I'll take some logic in my JSP over HTML
in my Java classes any day.

I realize this doesn't work on huge projects. And I think on things like
workflow, modeling makes a lot of sense. But I believe there's some
threshold, where the bulk of the complication is in the presentation, beyond
which UML becomes more of a burden than a help. On my project, the mockup IS
80-90% of the model. I'm sure there are some top-down project manager
Rational Unified Process/PEP types shuddering at the thought of a cowboy
developer like me using the above process. I get the exact same shudder
thinking about this project if we were starting design at the middle layer
with a bunch of UML that mandates solutions (EJB, Design Patterns) before we
clearly see the problem.

I'm also on this new kick where I'm really big on breaking the logic into
pieces and dispersing them over as many different technologies as possible
(where it makes sene of course). Ideally when this little query tool is
done, we will have user interface presentation logic in JavaScript/CSS/JSP,
business and utility logic in middle-tier Java classes, data extraction and
security logic in SQL stored procedures, and output presentation logic in
XSLT (forked to HTML, PDF, XML, CSV). Now we have built-in modularity and
multiple simple-interface "pinch-off" points w/o having to spend time
contriving modularity schemes to force on the design.

Very little of this relates to FOP by the way. I just like to ramble, it
helps me think.


> -----Original Message-----
> From: Arved Sandstrom [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 28, 2002 3:03 AM
> Subject: RE: XMLSpy - FOP
> -----Original Message-----
> From: Peter B. West [mailto:[EMAIL PROTECTED]
> Sent: February 27, 2002 11:47 PM
> Cc: fop-dev
> Subject: Re: XMLSpy - FOP
> [ SNIP ]
> Let me just strongly endorse Arved's comment about the oxymoronic "UML
> design", as in "design by UML".  What a bizarre idea.  It must be
> something consultants do.
> -----End Of Original Message-----
> I should add, I attempted and rejected the use of UML in this 
> particular
> instance. As I look back at it, this was more the fault of 
> trying to use UML
> modelling tools on a 17" screen; by the time all the menus 
> and side windows
> and toolbars have occupied screen real-estate you have a little
> quarter-screen window where you can visualize about 2 entire 
> classes or a
> third of a reasonably useful sequence diagram. :-) So I gave 
> up...the tools
> and my monitor failed, not the notation. I suspect that if I 
> had used pencil
> and bristol board and/or a whteboard then UML would have 
> worked out better.
> I consider prototyping in a high-level language to be detailed design
> anyway, which is what I really wanted to get at. I don't 
> think there are too
> many mysteries about the high-level design of an XSL 
> formatter anyway; you
> draw a couple of blocks and label them Formatter, Renderer, 
> etc etc. :-) OK,
> OK, maybe not quite that simplistic, but by the time you get 
> down to the
> problem areas in an XSL formatter it's detailed design.
> I don't discourage the use of UML but to be honest I've not 
> seen it used
> much in real life for anything except class diagrams, or capturing
> requirements, and fairly abstract at that. I will likely end 
> up describing
> the final prototype with class diagrams and some dynamic diagrams for
> documentation purposes, but I (personally) gain little from 
> using UML over a
> prototype.
> Where the UML will come in most likely is when I look at the "final"
> prototype and make a determination as to how to port its 
> lessons to C or
> C++. Right now I am leaning towards C.
> Regards,

Reply via email to