This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
The design and implementation of the application is shown in Appendix A. This simplified class diagram shows the classes, their most important methods (common methods such as new or initialise for creating a new object instance of a class are not shown) and connections showing interactions between classes. Whether a class is a singleton (there is only ever a single object instance of this class) is also shown. Currently developed classes have a white background and future planned classes for development are shaded.
The application begins by creating a generator class that starts the application by creating the main User object. This design choice was made to separate the initialisation of the User object from the class definition of user allowing the class definition to be more easily understood and different sets of data to be used in its initialisation without placing all of this information in the User object. This arrangement does potentially cause a problem as the planned user interface will have to interact with the Generator class in order to save and edit the user settings and exit the application but I think it is worth changing my original plan for the user interface to only interact with the main user object.
The User object stands at the top of pyramid of objects making method calls down to the AddressBook and Contact classes to perform the actions of adding and removing contacts and contact addresses as well as sending messages and arranging the contacts inside the AddressBook. The original plan was to allow the user to group contacts according to themes and then allow the user to send messages to these groups. As I developed the application I was inspired by developments in file explorers, email and note taking services to instead implement the same requirement in a more flexible manner with a tagging system. Currently each contact contains an array of tags denoting membership of groups (allowing multiple memberships by a single contact) as well as additional information such as which communication service to use (twitter or email). I plan to expand the use of tags to store any future data the applications may need to assign to contacts. However, this storage of sometimes conflicting metadata may require a checking as the tags not denoting groups are altered requiring checking of the tags before changes are made to ensure they are correct. For example, a user may wish to create a group ¿½twitter¿½ that also contains contacts they wish to send emails too which could cause problems if the send to twitter tag is the same as the group tag.
1.2 Additional Resources
Since submitting TMA02 I have made use of the Open University Course Library at Foxcombe Hall in Oxfordshire. There I was able to study the course materials for M256 Software Development with Java. In Unit 11 of M256 ISO 9241 specifies ¿½The extent to which a product can be used by specified users to achieve specified goals [tasks] with effectiveness, efficiency and satisfaction in a specified context of use.¿½ Although this ISO definition was written for use in the design of applications for office terminals it applies more generally and I have taken this as a basis from which to plan usability testing and as a model to re-examine and re-factor the design of the application overall. Units 11, 12 and 13 of M256 each covers a particular aspect of user interface design and are useful for my development of my user interface plan.
Overall my plan has progressed satisfactorily. Learning how to implement user interfaces in wxRuby and studying the principles behind a simple and effective has taken longer than I anticipated but I have made good progress on other parts of the project in lieu of this.
In expanding upon the most basic features of the application I have encountered some problems. For example I have started to explore the possibility of using CSV address book data generated by a range of mail websites and applications such as Google Mail and Microsoft Outlook. I believe that the application would be more useful if it could automatically accept and parse these CSV files and use the data to construct contact details. However the built in libraries for dealing with CSV files in Ruby have very strict parsing algorithms and require CSV files to be more 'well-formed' or strict than the test data generated from Google Mail and Microsoft Outlook. I believe my project plan can allow for me to write my own simple parser to extract the necessary data as only the name and email address fields have to be extracted in a reliable manner for the purposes of this project.
As this project involves interaction with the Twitter communication service provided by a third party I have monitored the future developments made public by Twitter and have learned that they will be moving from simple RESTful authorisation to the more secure OAuth open protocol standard for authorisation over the summer of 2010. OAuth removes the need for a user to give their service log in details to a third party and instead prompts the user to authorise the service to give a token to the third party application allowing the application to contact the service in a controlled manner. The main advantage of this process is that a third party application does not need to store log in details. Fortunately the application was designed and implemented in a modular fashion with interaction between the application at the Twitter service separated from the main application engine and user interfaces. This modular design will allow me to change the Twitter Contact class and Twitter Settings class with no other changes to the application and make the application meet the project requirements after the change of service.
3 Planning and preparation
My original title for this project was ¿½A system to allow the broadcasting of messages to a group of contacts through several different communications services¿½. As in my previous TMA I believe this title describes the project well and I see no reason to alter it.
3.1 Testing and improving the current data model
Currently data collected by the application such as contact details, saved messages and user settings is stored in flat files in the YAML (in the Unix tradition YAML is a recursive acronym for ¿½YAML Ain't Markup Language) format which can be easily translated by the Ruby standard library into data objects at runtime (this is not exactly a flat file database because the files themselves also contain data definitions similar to XML that allows the interpreter to create data objects from them). This data is loaded into the application's memory in the form of data objects when the application starts so that it can be immediately used to fill the user interface. This approach was taken as a working system could be quickly created and the use of human-readable text files made it easy to check that the data was being stored correctly.
There are possible problems with this system for data storage. As the number of contacts and stored messages increases the amount of memory necessary to store them will also increase. To test how the application performs under these conditions a test unit (a test program that will interact with the application automatically and produce performance data) will need to be written that automatically produce a series of test data objects and load them into flat files. Another test unit would then load this data into memory measuring the time this loading process takes and how much memory is used. Useful metrics generated by this process would include time taken to load a single data object on average and time taken to load all the data objects. To be useful these metrics would have to generated for different sizes of flat files. The sizes of these flat files would be determined by a survey of possible use cases, examining how many contacts and messages are typical for these use cases. It is likely that beyond a certain size of flat file the time taken to complete data loading and the memory necessary to store that data during runtime would make the application unusable.
A likely solution to the problem of excess memory use would be to only load the necessary identifying or index data that the application needs to provide the user with information through the user interface. Complete objects would be loaded when an operation on that data is necessary and the files updated when the object is destroyed. If the tests reveal unacceptable memory usage I would implement this solution and test to see if it is successful. This solution may prove to solve possible memory problems but present difficulties in retrieving the data objects from the files in a timely manner. This is likely as a parser would have to search the files in a serial fashion. This problem may be solved in a number of ways from generating an index of objects to converting the whole data storage system to an application based database such as SQLite, a self-contained and server-less database engine that takes care of the data storage methods itself and allows interaction with the database using SQL commands. My research has briefly covered these options to allow me to plan ahead in the project development and ensure that the development will not be faced with major problems at any review and testing stage of the V-Model of development plan I am using in this project.