Studying about OOAD I've found a simple workflow based on five steps. I don't work with a team, so what I'm interested in is a workflow that can be used by a developer working alone. The workflow I found is:

  1. Gather requirements for the application
  2. Describe the application with use cases
  3. Based on the use cases identify the main objects
  4. Identify the relationships between the objects found
  5. Write a class diagram

Now, there are two things about this workflow that makes me a little confused: first it seems oversimplified, and second it seems to deal only with the domain layer, but I'm not sure.

So, my questions are:

  1. Is this workflow ok, or is it oversimplified?
  2. If that's the case, which more information could be added to it in order to make it more clear the way to proceed from the requirements all the way to the class diagram?
  3. Am I right in that this is all about the domain model?
  4. When we do OOAD do we include on the model and on the class diagrams other classes that might be needed to connect the domain model to the technologies? Or on this step we are just concerned with modeling the domain of the application?
  • Yup. The first thing I thought when I read through your workflow is that it only focused on the Domain model.
    – MetaFight
    Feb 11, 2015 at 13:40
  • I would suggest you write a prototype of the main classes before writing any kind of diagram that takes more than 30s to sketch.
    – Wilbert
    Feb 11, 2015 at 13:51
  • You asked about analysis and design, while your steps are for data modeling only. You still have to sketch out a GUI and / or any reports that your system will produce. Since you're working alone, you don't have to follow any set of steps in order. You can draw a GUI, then see what objects you need to hold the GUI information, then maybe build enough of the GUI to do some user interface testing. Feb 11, 2015 at 16:57

1 Answer 1


This work flow does seem rather simplistic and in some ways unhelpful to me:

  1. It assumes that all requirements of your application can be captured as use cases, but use cases are abstract descriptions of operations that need to be performed on stored data that (a) do not describe user interface and (b) do not describe storage mechanisms. I would, along with the use cases, produce a user interface sketch and a data storage plan, as these will influence the design of your solution too.

  2. I rarely see the benefit in producing a class diagram before code. Class diagrams are useful to describe a system to other people, but when working alone or in small teams that communication tends not to be needed until much later, and the design usually changes enough to render diagrams produced before code obsolete before they're useful. Go straight to code.

  3. Your work flow appears to assume you can analyse and then implement the entire application in a single pass. For anything other than the simplest of applications, this is unrealistic. Design and implement a portion of it, then repeat until finished.

  • Thanks @Jules, now about 3, where I found this workflow, there's also the recommendation of doing it in small iterations rather than everything at a single time. I also heard sometimes about a "product backlog" which is a collection of user stories representing features to be implemented. The idea then would be pick a subset of the product backlog, and then perform those steps, and do it again and again? Feb 11, 2015 at 19:39
  • Yes. The common suggestion is to pick 1-2 weeks worth of work at a time, but as far as I can see the reason for this length of time is that it gives a team time to synchronise their efforts... for an individual programmer there's really no reason not to work one feature at a time.
    – Jules
    Feb 11, 2015 at 19:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.