General musings on programming languages, and Java.

Wednesday, April 06, 2005

Requirement Orientated Development

For a long time I have thought that most software solutions are too far removed from the problem they attempt to solve. The simple answer seems to be to identify the use cases and base the system around those. However, normal software development seems to move away from the use cases, so I have created a new development model, called Requirement Orientated Development, or ROD, which aims to make the use case part of the code. A system consists of a number of UseCases. Each UseCase has a number of Actions which can take inputs and give outputs, and can do some processing. A UserInterface (e.g., ServletUserInterface, SwingUserInterface, AtmUserInterface, UnitTestUserInterface) works out the possible Actions at any particular time and gives the user those to choose from. I have not yet dealt with use cases which can loop, and branching is done with duplication, so it is still quite naive, but I aim to make this progress. Am I reinventing old concepts, simplifying matters too much, or have I come across something worth following up? Let me know your thoughts. I'll post some code in another blog post sometime.


Shane Isbell said...

Most software processes, such as RUP, move away from use cases for good reasons. Since use cases consist of a series of steps, your ROD methodology would produce a system that is sequential and non-object orientated in nature.

Ricky Clarkson said...

I wouldn't have thought that object-orientation was a goal in itself.

The fact that my systems are sequential is, I think, a good thing.

The surface code that sets up the use cases might seem pretty sequential, but the actual implementation of the Actions could quite easily be non-sequential, and as object-orientated as any other code.

So that this will work fine for tasks that take a long time, an Action has an invoke which returns immediately, and a CompletionListener which gets told when the Action has finished.

I'd like to keep the solution as close to the problem as possible, and problems aren't always better expressed in terms of objects. A lot of the time people are more concerned with identifying the actions involved. That's my thoughts anyway.

Blog Archive

About Me

A salsa dancing, DJing programmer from Manchester, England.