What I wouldn't mind is a simple overview of several possible angles of attack to drafting a software project. I'm by no means new at development, but I usually write out what I want to do in text and go from there. This has been sufficient until this year, when I worked myself into designing and deploying a framework. I've read GOF design patterns and memorized the ones I need, written down way too much design theory, and haven't slept very much in over a month getting this thing hammered out.
I started with a class diagram which actually demonstrated several flaws in my design to myself, which allowed me to rethink it. But I found recently that begining with a Sequence diagram might be the way to go, to show interaction between objects and also provide a nice outline of flow.
Then again, I could start with the use cases, but a framework is bloody abstract, and diagraming the variety of possible inputs gets dicey; that leaves me with taking it up to a 10,000 foot view. Eventually, however, those use cases come back down to the same detailed class diagrams.
So you see, my predicament is really figuring out the best method to approach piecing together the framework (I don't even need every attribute plotted, I just need the layout to promote extensibility). It's a "where do experienced CASE/OOP designers typically start, and what do they do second, and what's the last thing they do?"
I can see the value in creating your classes first within the model view if you already know the major ones, and then dragging them into a diagram later.
