A set of current messages must be maintained: new messages can be added, the message set can be displayed on the display board, and at the end of each day a purge is performed – each message has its remaining days reduced and the client's credit. reduced by the price of the message and all messages that have expired or if the client has no more credit are deleted from the message set. By looking at the CRC maps we can see that :- .. the constructor for Client will be able to create a new Client object. ClientBook has the ability to add a client and .. ClientBook can contain the IDs associated with each client.
Below are three CRC maps to describe the Message and MessageSet classes and the DisplayBoardControl interface. The last scenario we want to run here is the message cleanup scenario. At the end of the day when messages have been displayed, the remaining days of the message must be reduced and the message will have to be deleted if a) the message's days run out or b) the customer's credit runs out.
Documenting the design using UML
With a sorted dictionary, adding and deleting items will be slower as the process is more complex, but retrieving items will be faster. While the classes above will form the heart of the system, an additional class will be needed to run and manage the system as a whole. This will be the GUI that runs the system and this will allow the user to interact with the system by adding clients, messages, etc.
This will again be driven from the interface, but the body of the code will be passed to the appropriate classes.
Prototyping the Interface
At the end of the day, the ClientBook and MessageSet details will need to be saved to file. This data will need to be retrieved the next time the system is run as the shop owner will not want to enter the details of all the customers every time they run the program. From left to right these are a) an area for adding new customers, b) and area for adding new messages and c) an area for buttons dedicated to other essential operations.
Revising the Design to Accommodate Changing Requirements
However, in this case there are no unique features of a regular message – messages have an associated cost, the cost and text can be accessed and new messages can be created. An urgent message is just the same as a normal message with the text and the cost slightly changed. So UrgentMessage is a type of Message and can inherit ALL features of Message with the cost and text methods being overridden.
The Message and UrgentMessage classes are thus related as shown below, where UrgentMessage inherits all the values and methods associated with Message, but overrides the GetCost() and GetText() methods to reflect the different costs and text that is associated with urgent messages. Thanks to the operation of polymorphism, this change will not affect any other part of the system at all. Looking at the class diagram above, we can see that MessageSet stores and manages a set of messages (DummyBoard also stores a set of messages - once they have been uploaded for display).
Therefore, without making any changes to MessageSet, MessageSet can maintain a set of all messages to be displayed (both urgent and ordinary). Furthermore, when the DailyPurge() method is called, it calls the GetCost() method on a Message object so that the client can be charged for that message. MessageSet requires messages, but thanks to the implementation of polymorphism and method overriding, MessageSet will happily treat any Message subtype as if it were a Message object.
So in this application we can extend the system with the capability for urgent messages by adding just one class and making a small change to the interface. Without the application of polymorphism we would have had to make additional changes to other parts of the system, namely MessageSet and DummyBoard.
Packaging the Classes
When the AddMessage() method is called inside the MessageSet, it requires an object of type Message, ie. If we later decide to create new message types, such as a Christmas or Valentine message, the MessageSet could handle these as well without changing a single thing. line of code. Not surprisingly, the main package, which houses the system interface, is linked to all other packages—this is because the interface calls functionality throughout the system.
In the first phase, a basic system will be implemented which will allow the creation of messages and clients, the details written to the file and the display of messages. In the second phase, the functionality of the system will be expanded to allow the deletion of customers and to allow the increase of their credit. This will be done in a way to allow the demonstration of Test Driven Development (as described in Chapter 10).
Programming the Message Classes
Only the 'Cost' property and the ToString() methods are overwritten because UrgentMessages cost more and change the text to be displayed. Note: To override the Cost property, we need to mark it as virtual in the message class. The MessageSet class needs an instance variable to hold the set of messages and needs access to a ClientBook object, as it needs access to the clients during daily cleanup.
Today, SKF's innovative knowledge is already crucial for running many of the world's wind turbines. The above code shows the creation of a typed collection of 'Messages' called Messages and methods to add and display messages. The message display method requires an object of type DisplayBoardControl to be passed as a parameter.
A DummyBoard object is initially provided, but if a real display board is purchased, this object will replace the DummyBoard object. This does not affect the code within the Display() method as both objects are of the more general type DisplayBoardControl. The DailyPurge() method has been excluded from the above code, so we could now focus on this method.
If the message has expired or if the customer runs out of credit, then set the DaysReamining for that message to zero. Note that it is possible that a client could not be found - hence the try-catch block in the code above.
Programming the Client Classes
The code above shows the constructors to create a ClientBook object that is a sorted dictionary of ClientID, Client objects, and the other methods required by the ClientBook class.
Creating and Handling UnknownClientException
Under the appropriate condition, we call the constructor of the exception using the 'new' keyword and pass a string message required by the constructor. To be helpful, the string specifies the method from which this exception was generated and the client ID for which a client was not found. The DailyPurge() method should catch this exception and hopefully handle it to prevent a crash situation.
The final step is to catch and handle the UnkownClientException within the DailyPurge() method – as shown in section 11.8 (Programming the Message Classes). However, in this case we have chosen to be more careful because we simply do not know how we came across a 'spurious' message. We have therefore decided that if the message does not have a recognized client, we will take no action other than reporting the error.
If an unknown message has expired, of course we should remove it from the display group.
Programming the Interface
Note that this includes buttons to increase customer credit and delete customer - functionality we realized we needed some time ago, but functionality that was not added to the first version of this system. Notice how with just four lines of code above we can create the appropriate output stream and store all of the customer book and message sets data - this includes details of all customers and all messages.
EXPERIENCE THE POWER OF FULL ENGAGEMENT…
RUN FASTER
- Using Test Driven Development and Extending the System
- Generating the Documentation
- The Finished System
- Running the System
- Conclusions
Assuming a client object is returned, the ToString() method is then called to obtain a string representation of the client and it is passed as a parameter to the MessageBox.Show() method (which displays the details of the client with that represents ID). If GetClient() fails to find a client with the specified ID, an UnknownClientException is thrown. This will be captured here and an appropriate message will be displayed. We need a method to increase a customer's credit - this should be placed in the Customer class.
Of course, we may need a series of test cases to make sure the method has all the essential features it needs. Even if we are not developing our system using TDD, we should define a broad set of test cases for all classes in the system. This will ensure that we can perform regression testing every time we improve or adjust the system to meet the future and ever-changing needs of the client.
The 'Show Messages' button shows each of the messages on the screen using the DummyBoard class. This can be tested by running Find Client before and after a daily purge – this should show that the clients credit is decreasing. This will involve 1) loading the DLL for the actual display board 2) creating an object of the real display board in place of the dummy display board 3) passing this object when the Display() method is called .
Load the MessageManagerSystem.sln file into Visual Studio, view the code, and run it within Visual Studio. When you view Solution Explorer in Visual Studio, you will see all packages, all classes, and you should be able to view all code with associated comments (see below.). Partly to overcome this we have shown many of the test cases in this chapter.
If you install Sandcastle Help File Builder (available for free from http://shfb.codeplex.com/) you will be able to load the file MessageManagerSystem.shfbpro which is available as part of the Message Manager system download.
