OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML publishing frameworks and software methodologies

[ Lists Home | Date Index | Thread Index ]

We are RFP-driven, and this is reasonably analogous to 
use-case driving.  Because our resources are always 
limited, we do not add modules (think level of QBE-forms) 
to the system until we have seen them clearly required 
in some number of RFPs and so can establish that the 
customer base at large wants this functionality.  Then 
we have to decide if it is strategic for our system 
to have this or if it is better to open an API for 
systems of that class so they can buy best-of-breed.

Once the decision is made to build, then we take 
the sets of requirements of the active customers 
and attempt to generalize these into a single design 
that can meet their requirements.   This is where 
the use cases are both helpful and dangerous.  A 
customer will have a fixed idea for what they 
want to see, and they will vary by customer.  The
challenge is to provide functionality that they 
instantly recognize as applicable to their problem 
and yet which applies to all of their problems. 
That is the art of systems design and it isn't 
easy and it takes a practiced team to do it well. 
No methodology or framework, IMO, are a sufficient 
substitute for practice.

Note:  if a functionality is deemed strategic, it 
is provided free of charge as part of a standard 
release.  If a customer insists on their own version 
or a non-strategic feature, they pay for its development. 
This is a workable incentive for convergence and 
in most markets, convergence is the process that 
leads to commodization and standardization which 
works to everyone's advantage.

Again, data objects on the X, operations on the Y, 
and users/uses/use cases on the Z.  That is a robust 
visualization.  The marketingHead looks at that 
and sees market forces.  The developer sees design 
tradeoffs.  The system manager sees a real time 
visualization of the application network.


From: Henrik Martensson [mailto:henrik.martensson@bostream.nu]

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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS