[
Lists Home |
Date Index |
Thread Index
]
Henrik Martensson <henrik.martensson@bostream.nu> writes:
> >
> > 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.)
Ok, I'll bite: I disagree. Part of the rational (at least our rational)
for doing use cases is to document what the test case results should be.
This may be dependant on who's doing the teaching, but I've always
encountered an emphasis on test case driven development associated with
use case driven design. There are test driven methodologies where the
emphasis is even stronger, but I think those are associated more with
physical models and implementation than with requirements and design
modeling?
>
> 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 favor of test driven
> methodologies, and i consider use-cases an essential tool in
> my methodology toolkit.
There you go; two different tools, two different purposes...
> >
> > 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
>
|
