Despite repeating it in my courses every year, I end up getting this error from at least 10 – 20% of the students at each exam session.
When drawing the class diagram of a software application, they invariably add a User class (call it the role you want: customer, admin, professor, director, clerk and so on) and then they add the list of actions that the user can perform in that class, instead of putting them in the classes they pertain to.
So, for instance if you want a method for paying a ticket of a flight, the payTicket() method ends up in the user class!
If you have any doubt that this is correct just think that then:
- you should put all the method triggered by user choices, in user classes
- to invoke that action from a caller method you should do it through the user class. Something like: JohnDoe.buyTicket()
While the right approach should be: myTicket.buy()
Attribution of actions / objectives to users is something you do at requirement specification level (e.g., when defining goal diagrams, use cases or scenarios), not at design level.
Today I had a project work review session with my students. This one made me jump on my chair. A student is reporting on the problems he has on his software development project work, and finally here he comes with this small concern:
“I was serializing the data we needed and suddenly Java sent out a warning about not to serialize the classes implementing the UI. Why is that?”
I was going to suggest to serialize his project work and ship it to another university.
To learn more about serialization of object in OO see: http://en.wikipedia.org/wiki/Serialization.
Here is what I read in an exam essay regarding the definition of functional and non-functional requirements:
- Functional requirements are those features that are needed for making your system function.
- Non-functional requirements are features that prevent the system from functioning.
Ok, what to say? Maybe you should add some functional requirements to your mind…
As a reference, you could simply go on wikipedia and find out the actual difference between functional and non-functional requirements.
It took me a while before deciding to start this diary, but given that the trip has been long and it’s likely to be, I finally opted to share some of my experiences.
Don’t expect to find enlightening findings here. I basically want to share the most hilarious and embarrassing situations I stumbled upon while teaching Software Engineering and Advanced Software Engineering at undergrad and graduate level in Politecnico di Milano.
I think you may get some good time from this diary, and at the same time I hope this will contribute to software engineering education (much alike an anti-pattern list).
So, enjoy and feel free to share your funny stories on software engineering too!