FIT 2011 Week 10

Lecture

So blogger was down yesterday so I couldn't blog...Interesting and also my SVN repository is down as well for another subject...bah it will get better.....

Anyway Test Cases....This is so important....Since I am doing FIT 2024 I can see a huge correspondence here with that subject and I like the Test case combination table...The one with all the test cases showing their paths. I am going to implement that into my report as a summary of my test cases for FIT 2024.

Its great when you can apply something you learnt from another unit into another unit. A big correlation and love that. Anyway test cases are so useful for the programmer...How do you know if something is to specification? Test it....How can you be sure the system will work according to requirements? Test it....

Without testing one cannot prove quality.

3 kinds of testing stage

1. Unit Testing
2. Integration Testing
3. System Testing

In Object Oriented(OO) Design I believe one can't test every procedural statement so testing state changes seems to be the best way to conduct unit testing but since OO's smallest unit is a Class / Module it would be better to call it Class / Module testing. Hence why the Use Cases can generate test scenario's for OO easily since it flows naturally of behaviors of an Object..

Integration testing should be done based on what the system needs...Like System needs a purchase order, allright lets integrate that now, and then now needs to confirm the order, lets integrate that now. Based on number of threads. Why this is done? Because if you think about it, if I have tested my unit cases why should I worry if the system would break on integration? The reason why it would break on integration would be many other comnponents and modules do not necessarily communicate with each other well... High coupling or low cohesion problems tend to show up during Integration testing.

System testing, is when everything is integrated lets make sure the system works. Smoke tests are tests runned daily so that the system is exercised daily.

Turotial

Writing Test cases is not easy. There are many paths to consider. This does looks like the cyclomatic complexity flow graph though but the cyclomatic complexity is to determine the maximum number of test cases needed to test all states through the class. Anymore then that would mean, there are too many test cases and thus wasting time.

In the same way the test cases applied in FIT 2001 takes the Use case as the stepping stone to creating test cases. I suppose if I were to start a process to generate test cases...

I would first get the basic flow....Like a tree and make all the alternative connections at each step... When I have completed my tree then I can evaluate the test cases I need and then start constructing them and then testing them the moment code has been implemented..

Allright need to go and finish another assignment....

FIT 2001 Week 9

Lecture

I didn't realise I made it to blog of the week until today...Shows how much time I invest into this subject reading other peep's blogs.

Hmm....Request For Proposals(RFP)....I remember doing something about this in FIT 2008 for Networks. What was I doing....ah right I remember now....Good to have an archive of it... we were playing vendors for RFP's and had to work a Project requirement Brief based on the Scope of Work and Objectives of the RFP.

An RFP goes out and vendors will ussually, in some way, bid for it via offers. Then the client with all these offers will ussually choose the solutions based on the multitude of alternatives available unless the client is already decided on developing in-house and thus only has one solution already in mind. Ussually client's will use a matrix with weights on it. Engineering disciplines use a similar table to check alternatives for alternative solutions. The way we do it is just weighing requirements and checking how well the system being develop is meeting this requirements.

It is better to have alternatives, just like a backup plan in case anything goes wrong, but if you only have 1 plan, don't spend too much effort thinkingof another plan of action. Just follow through and iteratively remodel the plan and if a new plan does come out and then you can iterate again and examine. In other words iterate in the small, don't commit too far into the plan....Divide and conquer...Explore opportunities as they arise..You can get stuck in planning stage for a long time.

Tutorial

Converting class diagrams to relationships

1. Create a table (or entity) for each class
2. Choose a primary key for each table (invent one if needed)
3. Add foreign keys to represent one-to-many associations
4. Create new tables to represent many-to-many associations
5. Represent classification hierarchies
6. Define referential integrity constraints
7. Evaluate schema quality and make adjustments
8. Choose appropriate data types and value restrictions for each field.

Seems like a tedious amount of steps....

I think all it means is just converting class diagrams into ERD diagrams....Why are the lines in the solution dashed....I thought ERD was solid lines....hmm.....I am going to assume it is suppose to be solid...

Blogger was down yesterday and yes this post is long overdue....I will upload Week 10 very soon

FIT 2001 Week 8

 Lecture 

Its been awhile since I kept up with blogging on FIT 2001... I was swamped that week with loads of assignments. Its just crazy when suddenly in that one week you have more then 4 assignments due...

Anyway on to the business at hand...

Design Use Case Realization...Wow this topic had a huge bunch of information to take in, for a two hour lecture...

The 4 symbols for entity, control , boundary and data access can be used in a Robustness diagram which shows the initial system design.

• Entity – Seems like domains of the problem to me
• Boundary – System wall boundary between user and system
• Control – between view layer and domain layer there is this message flow that needs to be manage and the control does that
• Data access –Accessing data

The above is what I took from the lecture on it....The lectures provide a more formal definition but I needed something more intuitive.

Coupling is the measure of how the classes are linked.

Cohesion is the measure of consistency of functions in a single class.


Coupling and cohesion are very important. Its best to have low coupling so most classes are independent...It is reducing dependencies. Also good practice to have classes of high cohesion then a single low cohesion class.

Examples that I would use would be a car has many coupled parts like driveshaft and gearbox but it has high cohesion means that the gear box does it's function to switch gears and the driveshaft is just to transmit power to a differential and then to the wheels. If dependencies could be reduced then the car would run even more efficiently and maintenance will be easier. Less moving parts.

Same for an information system.You want to reduce as many dependencies as possible.

To get to the Package diagram which shows the 3 different view of objects. The robustness diagram is used to develop the first cut sequence diagram, and then the more complete sequence diagram using the additional view layer and data access objects are added on and then the final class diagram inclusive of methods and visiblity will lead to the package diagram.

Tute

Took me a long time to understand what was going on regarding the work involve. But once the robustness diagram is figured out, it is so much simpler to progress towards the package diagram.

I found that the Use Case Narrative can be described as an Activity Diagram. I only just started reading the SJB text book and I find that I should continue if its not too late to start reading it in detail because concepts like this aren't obvious to me.

Also the solutions are for review questions on page 430 but the questions are for page 474...Very interesting.....