Computer Science is Cool Again is a recent article I ran across. Basically, enrollment in Computer Science classes is up significantly after years of downturn. According to the article, this is due to the economic slow down and the opportunities available to computer science graduates.
Personally, I find that hard to believe – I’m not sure many freshmen or sophomores at a university are picking their major based purely on economics following graduation. Sure, some are looking at that, but I think more are looking at the ‘cool’ factor. As the article points out, Web 2.0 and the iPhone are cool.
Speaking of the iPhone, Apple announced plans for the 3.0 software. It looks great – we finally get copy & paste, there is a push for better application integration, etc. But, beyond the enhanced features, the biggest opportunity with the new software is micro-transactions. You know, the things that let you purchase add-ons like new songs in Guitar Hero or new levels for your first person shooter. This is going to continue to push the economic strength of the iPhone as a gaming platform, and I suspect it’s going to mean even further dominance within the smart-phone category until someone else can replicate what Apple is doing with the device / iTunes combo.
I had a great conversations with a delivery team today on the use of Context Diagrams vs. Use Case Diagrams. I’m a big proponent of starting off any software engineering activity with a context diagram so that I can understand the major users of a system, the major systems I have to interface with and the overall scope of what the system needs to provide.
But, why context diagrams and not use case diagrams? In the past, I’ve taught several object-oriented analysis & design classes at both community colleges, universities and for clients. When reviewing use-case diagrams, I often make fun of how silly they look and that I would never deliver something that looked like on in a professional engagement. (This is part tongue-in-cheek, but it is more-or-less true.) The problem with a use case diagram itself is that it’s trying to solve a number of problems all at the same time: 1) who are the major actors of the system, 2) what are the major interfaces and 3) how can I break down the system scope into digestible chunks. I think trying to achieve all of that in a single diagram causes it to be way too confusing and difficult to effectively achieve.
So, in comes context diagrams. They are really only focused on #1 and #2 above – who uses the system and what are their needs? I’m not trying to worry about functional decomposition, and I’m not even focused on the internal guts in any way.
Additionally, context diagrams work really well for packaged applications since they make no pretense on how the software will solve my problem. In the case of a use case diagram, I’m assuming that the package has a clean set of steps for achieving any of the use cases.
So, if you haven’t looked at context diagrams, I highly recommend that you take the time to understand how they can work for you.
