Monday, 8 December 2008

Realisations

I've been reading about classes, not just for System Design but also for the Software Engineering module. It just dawned on me that, in the IT Computers case study, I've been getting mixed up between the Customer actor and the Customer class, especially when I was making the CRC card.

The Customer actor is a person who initiates use cases such as "cancel order". But the Customer class is a way to store information about real life customers. The information about a particular customer is stored in the attributes of a Customer object and that information can be changed by calling the methods of the Customer class. It sounds obvious now, but somehow it wasn't as clear to me a month ago!

I also now understand why there is no direct relationship between the Order and Address classes - it's because the Address class is part of the Customer class. I did put the aggregation relationship in, but I'm now starting to think about what this might mean in terms of the code. Maybe the Address class can be considered as an attribute of the Customer class, even though it's a class in its own right?

1 comment:

Anonymous said...

The basic issue here is the consideration of how a customer and an address object may be used by the system. A customer object must always have at least one address object linked to it. Each address object may be linked to only one "address owner" type object(usually a customer)