June 8, 2010 7 Comments
I didn’t make these, but Nida has kindly made a summary for software engineering and asked me to publish it, so here it is! Read more of this post
So, this is it. This is the post that ties all the previous three together! That is:
So lets have a look then shall we at Object-Oriented Modelling 🙂
Hey everyone it’s Badgerati again 😀 Sorry i haven’t exactly posted anything in 3 weeks… But if everything goes to plan, there should be 3 updates tonight!
So, lets get them all started with Class Modelling! 🙂
November 26, 2009 2 Comments
Domain Modelling is a way of representing the context in which the software must operate – to understand the software better. However, one must remember that you’re not modelling the software to be built!
A better description would be:
A Domain Model in Software Engineering can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relations.
Now for the moment you’ve all been waiting for, an example! 😀 Sadly a Domain Model doesn’t have any stick people in it, so there’ll be no awesome stick people of awesomeness 😦
Lets say we have the following information for a basic Student Library System:
Courses may have recommended items of Reading Material, which may be either complete Books or individual Chapters. Items of Reading Material may also allows a user or floppy for every NFA there is i for for have Reviews associated with them.
Now with this we need to identify 5 classes, can you see what they are?
Hint: i cheated a little, they’re in italics…. 😛
So, yeah… we have the 5 classes of:
And with this, this is what the Domain Model looks like:
Before I start to explain what this shows, lets explain the arrows and numbers:
Alternatively we can also say that one (1) Course provides zero or more (0..*) Reading Material.
As a note, remember that we can only use these numbers on plain relation lines and contains relations. we do NOT use them on inheritance relations! 🙂
And i think that’s it for Domain Models 😀 , sorry for doing this one a little late, i had some issues with the diagram above. However, many thanks to James Bedford, Daniel Lyon 😀
November 24, 2009 Leave a comment
The fundamental rule of testing is that ‘a successful test is one that causes the software to fail.
You can have a testing team who didn’t write the software do this.
An agile solution would be to write the tests before the code. This helps to clarify requirements too. Read more of this post