OT Design of App I am building

[Steve Green]

Even though I intend to write the app in Java this is a design related
question. I would have posted this to an OOP group (I just like the sound of
that ... OOP Group), but there doesn't seem to be a design group. Please let
me know if I am wrong.

About my design ...

I am the sole developer of this application. I don't have users, subject
matter experts or other developers to rely on. I am currently reading a UML
intro to object oriented design and patterns and the book says to leave out
artifacts that that are just busy work, but the author would probably have a
heart attack if I suggested that use cases are busy work. Should I go to
the trouble of creating use cases or would that be a waste of time? Should I
just jump to class diagrams and sequence diagrams as these are more natural
things to me?

Where is the app now ...

I am currently making a list of features and have already created a
functioning prototype or poof of concept, but the prototype is ugly in its
GUI design and implementation. I have a batch programming background and not
much GUI experience. It was a hack created without an overall design in
mind; I just had a general direction in mind and just implemented different
aspects that I felt like doing at the time.

Given that I already have a functioning application I am leaning toward
doing the design in a waterfall approach rather than the Unified Process
because I have a very good idea of the features I want it to implement and
want to do a design for the complete application. Given that the unified
process follows a short design and implementation cycle it doesn't seem to
fit where I am now. What are your thoughts on this?

Thanks,

Steve

 

[Symz]

Hi Steve

My two cents

"...and the book says to leave out
artifacts that that are just busy work, but the author would probably have
a
heart attack if I suggested that use cases are busy work. Should I go to
the trouble of creating use cases or would that be a waste of time? "

Create use cases. I'm not sure I understand "busy work", but if it's related
to granularity, I think you should just abstract your use case until you're
out of the "busy work" level. The use cases will test your knowledge of your
system as well as document interdependencies of functions/sub systems
(depending on your granularity-choice).

"...Should I just jump to class diagrams and sequence diagrams as these are
more natural
things to me?"

Use the class diagrams to define your logical model. Your use cases should
drive your class diagrams as well.The shouldn't just represent tables in
your db for example, but the OO design you've chosen. Perhaps your use cases
will depict candidates for design patterns?

Where is the app now ...

" I am currently making a list of features and have already created a
functioning prototype or poof of concept, but the prototype is ugly in its
GUI design and implementation. I have a batch programming background and
not
much GUI experience. It was a hack created without an overall design in
mind; I just had a general direction in mind and just implemented different
aspects that I felt like doing at the time."

Well use cases take the hack out of the equation pretty well and tie
together seemingly unrelated functions. They can become a list of features
with relationship info.

" Given that I already have a functioning application I am leaning toward
doing the design in a waterfall approach rather than the Unified Process
because I have a very good idea of the features I want it to implement and
want to do a design for the complete application. Given that the unified
process follows a short design and implementation cycle it doesn't seem to
fit where I am now. What are your thoughts on this?"

Again, documenting tests your design and understanding and hopefully gives
you clues on how to implement your functions more appropriately. Your hacks
might be candidates for design patterns, e..g Singleton, factory and
strategy usually come up. Your class diagram should document this logical
design and move you forward. You might be ahead of the normal UP process, so
see this as a refactoring excercise. UP might be overkill, but good design
and refactoring is usefull in every process, e.g. RAD, UP, Waterfall. If
nothing else it will give you practice in OO and UML and a nifty set of
documentation for future reference.

Cheers
Simon