|
|
|
USER Task #1 – View Data  |
USER Task #2 – Scroll Data  |
USER Task #2a – Refresh View  |
USER Task #3 – Update Server Data  |
USER Task #4 – Sort View  |
The above flow diagrams show the desired client functionality for viewing a subset of the data (a to-be-determined amount of data, open issue). The Broadcast function is expected to be via an Observer Pattern combined with a Proxy pattern for communications between Client and Server. The Observer Pattern is used twice, once for the external datasource to announce updates to the Server side CacheManager (although this maybe out of scope), and once to update the ClientManager to changes that have occurred to the CacheManagers held data. The primary idea is to maintain a collection of caches on the CacheManager (implemented onto a server connected to the external data feed) for each Client. These caches may be implemented as indexes into a primary cache to conserve memory space (as opposed to multiple caches, one for each client). The indexes will allow each client to maintain a specific order to the data in the collection (see the last user task – Sort). The update function is not well defined and in fact may not need to have any kind of locking (if collisions occur the last to update wins). The broadcast mechanism will ensure that all clients are informed of a datachange and will order a refresh of the current view.
The Proxy pattern is used to encapsulate the communications path between the client and the server; this needs to support the correct communications protocol (out of scope for this design). We assume a mechanism to broadcast and receive messages between the server and client platforms.
Class diagrams are provided on a separate sheet.