If you're specifying classes and methods in boxes and connecting classes together with lines to show inheritance, etc. you're almost certainly doing UML diagrams. See
Wikipedia's entry.
This is one of those things that is changing over time, and CS departments tend to lag behind production environments. Back in the day (and this is still the case for critical software systems like Mars rover code), code was documented and justified in excruciating detail with reams and reams of text and pictures and stuff like that. However, over time, coders have come to realize that we need a more "plastic" environment to create software in, since our ideas of "good design" change as we start writing the code.
There's a good article on this I found recently:
Hackers and Painters.
Here's a relevant quote:
For example, I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way. I found that I liked to program sitting in front of a computer, not a piece of paper. Worse still, instead of patiently writing out a complete program and assuring myself it was correct, I tended to just spew out code that was hopelessly broken, and gradually beat it into shape. Debugging, I was taught, was a kind of final pass where you caught typos and oversights. The way I worked, it seemed like programming consisted of debugging.
For a long time I felt bad about this, just as I once felt bad that I didn't hold my pencil the way they taught me to in elementary school. If I had only looked over at the other makers, the painters or the architects, I would have realized that there was a name for what I was doing: sketching. As far as I can tell, the way they taught me to program in college was all wrong. You should figure out programs as you're writing them, just as writers and painters and architects do.
My coding style has evolved over time, but this is more or less how I tackle problems nowadays:
1. Figure out what you want to do in broad terms.
2. Write some throwaway code to get a sense of how it might work.
3. Write some very specific tests that pass/fail and especially test edge cases.
4. Get the throwaway code to start passing tests.
5. Get disgusted with the code, throw it out, and start over.
6. (Optional) Repeat step 5.
It almost sounds sort of crazy, but lots of very good code comes from this approach. To solve a problem well in code, you have to have solved it before, which means to write good code you have to write some horrible, terrible code and then scrap it and start over (often more than once).
...
All that said, if you're doing a CS degree you
have to drink your professor's koolaid. There's time to become disenchanted with the whole process later.