The Case Studies

The case studies have been an interesting experience for me. I say this because I am one for whom the case studies were not necessarily a new thing. I have thought about what goes on in a library during a conversion, and I have done data analysis, and I have process analysis.

For here things get a little strange.

It has been a while since I've done data analysis in quite this way. My most recent programming job had me doing web programming, and I did need to explain the data model to another person. However, generally the data model I used was close to the SQL code, and the one I explained to the other person was the data as it would appear on the screen (in a form). Since I needed to think about the form anyway, this was actually a useful prototype.

The last classes that I taught were VB and C++. These are rapid prototyping languages, and they are object oriented languages. This sort of made the data models tilt in a particular direction. The rapid prototyping part meant that the models tended to start as sketches of the screen, if I could get students to think about what they were doing. The objects we created tended to have lists of properties, and the other things they had going on were not easily graphed.

There were times that diagrams came into play, for lists, trees and so forth.

The process diagrams, flowcharts, are something I've done also. However, I haven't done flowcharts as such for some time. When I did FORTRAN, we did flowcharts. I even had one of the little plastic flowchart template thingies. I don't have one currently.

When I taught VB and C++ I normally didn't teach the flowcharting. Particularly with the VB, the nature of the language tends to make any one piece of code rather short. A flowchart and psuedocode wouldn't look that different for most sections of code. So, it was just simpler to look at psuedocode as a good option. The other thing is that to complete either, you have to be able to see the end from the beginning. Generally, my students needed to get to a certain point to see the problems. That's when the discussion happened about how to do something.

Sometimes, the students would be able to see farther and farther into the process. When they could look and see problems before they happen, that was a real success. When they could look all the way to the end of the project, that was something else again.

As for my experience making the case studies, I found that openoffice worked well for making the flowcharts, and I used an org chart (in Power Point) to make the data model. I don't know if either was the easiest, but they were at least manageable.

I'm thinking that I could have made either flowchart about twice as detailed, but nothing huge comes to mind that I left out. If I actually had to code it, I'd be looking through things with a fine toothed comb looking for what wasn't there. Mostly this would be details that the librarian doesn't see. But they're there.