FIT2001 Week 10: object oriented design

So week 10 was a bit of a nightmare, with the Assignment 1b due for FIT2001 kicking things off, followed closely by Project Management 1b and 1c due (thankfully extended from Monday to Thursday) and a large essay due for Critical Theory (extended from Wednesday to Monday) as well as a Girls Brigade camp (horse-riding in Daylesford) that I was going at the weekend! I had to write the essay while on camp (and into the wee hours of the morning as Sunday turned into Monday.) I enjoyed writing in the country air, it was actually kind of fun. To top all that busyness off some inconsiderate soul had ventured into public while infected with a cold (ARGH) and I happened to pick it up. (Seriously people, take one for the team and stay home if you’re sick.)

Hence my blog post (and catching up with the lecture) for this week have been pushed back, and now I have to do double time to catch up.

Thoughts about Lecture

To be honest I wasn’t blown away with the lecture this week, perhaps because I’m not in the routine of listening having skipped a week, or perhaps because it actually wasn’t that exciting. It boiled down to Object Oriented (OO) stuff we’ve covered before and System Sequence Diagrams which we’ll need for the assignment. I suppose the OO stuff would be very exciting if you hadn’t encountered it before, but we’ve been steeped in OO since we walked into the first Computer Science (sorry, Faculty of IT) lecture.

The system sequence diagrams look logical which is good- I’m a bit anxious because POD says we should practice them or they won’t make sense, but hopefully I can squeeze some practice in.

Design is about taking the abstract stuff we made in the analysis phase and turn it something more concrete that we can give to a programmer. This means that the design document will be much more technical than the Functional Requirements Specification.

UML (aka ugly messed up language) uses the same kind of diagram for the class diagram for both the analysis and design phase, with slight variations on how you use it. Use caution when you’re looking up examples that you’re looking at Design examples.

Focus on the Use Cases, take each one on in turn. Packages make the diagram prettier, but have a purpose. We divide out the view layer and the data-access layer from the domain layer, these will probably be implemented separately anyway. In the real world often people just glue interfaces to databases and don’t focus too much on the domain layer.

The Tutorial
Well, I was sick, so didn’t make it in.

The Quiz
I know the OO stuff (with just the new wrinkle of Navigation Visibility) which is no big surprise.
POD didn’t refer to guillemets by name, they’re those angle bracket pairs. << >> Easy process of elimination there for the quiz- “I know what all the others are, must be this one!” guillemets indicate << entity >> << control >> << boundary >> << data access >> stereotypes and of course we saw guillemets before with << includes>>.
Lots of UML notation to learn here, which is a bit depressing.

On to the assignment, the other assignment, the other assignment, or the week 11 lecture!

May 21, 2010 | |



Comments RSS

Leave a Reply