[
Lists Home |
Date Index |
Thread Index
]
On Thu, 2004-02-19 at 13:33, Oleg Dulin wrote:
>
> The problem with use-case driven development is that very little focus
> is placed on the architecture of the application, forcing developers to
> deliver functionality and resulting in unmaintainable complex code.
This is wrong. For example, RUP is use-case driven, and places a lot of
emphasis on architecture.
The fact that a methodology is use-case driven does not impair the
architecture of applications in any way. On the contrary, use-cases are
a great help in understanding what an application is supposed to do, and
thus supports the design of a good architecture. Whether you use Design
Patterns, TDD, CRC, UML, DRY, Simple Design, or some other design tools,
use-cases will be an extremely valuable help.
There is a problem that _may_ crop up with use-case driven development:
it does not emphasize testing enough. (My personal opinion, and I don't
expect anyone else to buy it right off the bat. Also, it depends on who
is doing the use-case driven development, of course.)
However, this is not the same thing as saying there is a problem with
use-cases. Use-cases are a great tool and in most cases they capture
requirements much better than traditional requirement specifications.
Personally, I am rather strongly in favour of test driven methodologies,
and i consider use-cases an essential tool in my methodology toolkit.
>
> With Cocoon and XSL I found that most of the architecture is already
> provided by the framework itself, meaning that you can focus on the
> functionality. The problem of refactoring and reuse manifests itself in
> XSLT, though, but it is not nearly as complex to refactor XSLTs as it is
> to maintain reusable component-based Java code.
>
> Anyway, what do you think ? Given XML-pipeline frameworks such as
> Cocoon, can we focus on functionality and pay little attention to the
> architecture (assume that Cocoon does its job well), or is architecture
> still an important part of the methodology ?
With the complexity of the applications we make today, architecture is
more important than ever. Using a framework of some sort does not reduce
the need to pay close attention to the architecture of the code we write
ourselves. Messy code written on top of a good framework will result in
a bad system
/Henrik
|
