This week I was reminded of the best and worst of university. The best: being inspired and excited by ideas. The Identity 2.0 presentation at the end of POD’s lecture was great. (Claytonites and other non-Caulfielders: you can find all the videos on the Caulfield Resource page in Moodle.) Of course, the worst of university comes with a lot of work and not much time. I neglected my “learning” a little this week, leaving listening to the lecture to when I was tired and grumpy on Saturday night (yes, I have no life. During uni, anyway) and focused on getting my assignment (the first of 8 due in the next 3 weeks) finished. I finished it off, even having some fun with a letterhead and fake signature for my cover letter. Still, working on assignments is not a process I look forward to.
This week is important to know but not to do, which is nice. We might encounter some dinosaurish systems that are based on Structured Design, or we might encounter some dinosaurs as our bosses who think that Structured Design is the best way to design software. In any case, Object Oriented Design appears to have evolved out of Structured Design, so it might be good to start understanding stuff here.
The old: “jargon means you get paid more” theory has resurfaced, with Cohesion, Coupling (misheard as “cuddling” the first few times on the recording), flags, central transform, and afferent and efferent data flow!
The key concepts
Our goal with design is to take the analysis and build software that does what we want it to do in a way that works and works really well. Hopefully the analysts have done a good job and we can use the existing diagrams and reports to build our design documents. The big things we need to do in Structured Design are:
- System Flow Charts
- Structure Charts, and
There are two ways of doing this: Transaction Analysis and Transform Analysis.
In Transaction Analysis, we draw an Automation boundary and work out what transactions are happening- what data is going in and out of the system. (We can also break this down and look at what data is being sent over subsystem boundaries.) A nice thing here is that we can know what interfaces are needed and send them off to dedicated design teams and so divide up the labour (getting things done quickly by doing them in parallel) because we know what data they need to get and display.
In Transform Analysis, we take the diagrams and turn the bubbles into squares. We don’t get paid much for saying that, so we call it the CENTRAL TRANSFORM (cue booming voice, thunder roll). Basically we take a high level DFD (not the context diagram, DFD level 0) and turn it into a design diagram.
Modules = procedures = functions, it just depends on what you learnt and who taught you. These are the squares with names in them in the diagram. While we’re talking about modules, let’s talk about cohesion and coupling. We want low coupling and high cohesion. Coupling means when modules rely on each other, so if you change one module it affects the other. This can lead to nasty and unforeseen consequences when you make changes, so it’s a good idea that the modules are as lowly coupled as possible. Cohesion is talking about internal cohesion, not the cohesion between objects. Basically it means that we want each module to focus on one thing and only one thing, and be solely responsible for that thing. Low coupling, high cohesion. (Think school camps- we had a policy on school camps of “joyful glances only” – it was a conservative school. Low coupling. High cohesion- everyone responsible for their own selves but getting along nicely.)
On the cohesion note, I’ve heard some coding style guides suggest that methods should be a screenful size, to help with understandability and also the “just one thing” idea.
Control flags are variables that are booleans. (0 or 1, true or false) lots of them can indicate poor quality code, but they can be useful.
While analysis carefully separates out the different data stores needed, the Designer can simply things by lumping them all in a database. It’s good to have modules that deal only with handling the SQL. Colour coding is good to indicate the 3 Layers. When writing pseudocode try and think what language you’re going to use to implement this so that you don’t make life hard on yourself. Write pseudo-java, pseudo-lisp, pseudo-C, pseudo-PHP, etc, so that you can easily convert it into real code when the time comes.
I found this week’s tutorial really interesting, not that we looked at the actual tutorial all that much- I guess we’ll have to catch that up as we’ll be using it for our assignments. It was good looking around the room and seeing everyone working on their assignments, seeing some diagrams like mine, and others that weren’t. I find the questions that others ask really useful to my own thinking. I also really really appreciate the dedication of my tutor who had a Clayton consultation and also helped me out with my understanding in the tutorials- it was good to say “is this what we’re supposed to do” especially because Visual Paradigm doesn’t have 100% matching with the names of the diagrams. Having a two phase process of asking what I needed to do and then checking I had got it right was important. I put a lot of effort into a high level DFD and had to cut it right back for the context diagram: but I’ve held on to the high level diagram and hopefully I’ll be able to use it in my second assignment. Fingers crossed that things don’t get changed totally for OO Design. I’m pretty happy with my assignment, just have to wait two weeks until I get my marks! However hopefully I’ll get some good feedback from my tutor before then.
The quiz showed that this week is all about vocabulary, as it caused me to stumble a bit. I think I’ve covered everything that threw me in in the lecture and reflection, so I’m pretty happy to leave this until revision time. These are the words that I didn’t know:
- central transform
- control couple flag
- module cohesion (means internal cohesion)
- afferent data flow
- efferent data flow
- data couple (example: global variable)
The great Moodle Incident!
It all started with an unhappy student who missed the simple left hand navigation bar. A complaint on twitter made me start to notice. A forum post about the South African weather meant that POD posted a quick screen cast on how to minimise campus information. Bingo- our screens were different. Clayton students didn’t have a quick navigation tab system, just a long plain page of html. Screenshots, twitter comments and a bug-fixing POD all helped to get us our tabs. Why didn’t we complain in week 1? I found the site usable, a sight better than Blackboard, and didn’t know there was anything missing. I’m guessing the frustration with an interface builds when you are actually trying to use it for something important: in this case, Assignments. I guess a screenshot of what Moodle should look like would have helped test the system more extensively (Clayton students missed out, but all staff and Caulfield students had the tabs, but no one knew there was anything wrong.)
This blog post complete, I’ve now caught up to my usual schedule. Three big assignments still due next week (one is really a two-part assignment because both are due at the same time) and an icky essay that still needs to be tackled (involving an expedition to the library (Matheson) to hear the hum of the books!) so I won’t be devoting too many brain cycles to FIT2001 until next week. Thoughts with all the people still cranking away at their assignments, if you’re procrastinating by reading this post: get back to work!
Still reading? Well, being born only a few years before Dilbert was started, we haven’t had a chance to enjoy some of the earlier strips. The dinosaur image in this blog post is actually Bob the Dinosaur, who wasn’t extinct, he was hiding in Dilbert’s house. Start here at 17th of July 1989, and read about the next 7 to 10 comics. Be warned though, Dilbert is very addictive. Maybe finish off that assignment first.