When we analyzed our use cases for the order processing procedure, in the previous chapter, we identified a few of our business services components: Orders, Customers and Products. When we developed our sequence diagram we added two more components: the DB Business Logic object (enabling other objects to communicate with the database) and the Interface object (visual interface of the system). These sequence diagrams mapped out the communication between components and showed the services these components will need to perform. With this information, combined with that in our use cases, we can start to identify the components of the system and their public properties and methods.
Let's have another look at our Create Customer sequence diagram:
From this diagram we identified two methods for our Customers object: AddNew and Save. Our Update Customer sequence diagram must include a request to return an existing customer. Thus we identified the need for methods to navigate through the collection of existing customers to select the appropriate one: Move Previous, Move Next, Move First and Move Last, Get Item, along with an Edit method. In addition we will need a Delete method (we did not discuss the Delete Customer use case since this was not a valid goal in the order entry clerk role).
We are building the customer component so that it has the ability to return a customer object thus the component must contain all of the properties of a customer - Name, address etc. - that we defined in the previous chapter.
OK, we have identified methods and properties for our Customers component using our sequence diagrams and use cases. We have to stop and think here. The first question we must ask ourselves is: "Does it make sense to put all of these methods and properties into one class, say clsCustomers?" The answer, as I'm sure you knew, is no.
For example, our Customers component needs to perform the service of returning an empty Customers object when requested to create a new customer, that is, it must execute the AddNew method. If the AddNew method were part of our clsCustomers class, we would first have to create the clsCustomers object and then we would need to call the AddNew method in this object to make a new clsCustomers object. We would be asking the customer object to make itself once it already existed!
Another property we might like to have is a Count property that gives us the total number of customer objects in the Customers collection. Once again, it would make little sense to add the property to clsCustomers. Each object in the Customers collection should be independent of any other object. If an object has no knowledge of the other objects then it cannot perform a count. What we need to do here is put all of these sorts of methods into a separate class: we need to create a class hierarchy.
Was this article helpful?