Pixel : a Photography Asset Management System (PAM) Design Review for SATS

Transcription

1 Pixel : a Photography Asset Management System (PAM) Design Review for SATS Jeffrey Jacob, Ian Lau, Howell Li, Ben Schwaid March 28, Summary Version 1.0 The majority of this design review refers to the initial design document and takes into consideration important revisions in the second version of the group s design proposal. The initial document details a system architecture that seems to suffer from the inefficiency of redundant classes. This can cause a list of dependencies and relations that are quite fragmented which makes it in general harder to understand even for a competent programmer. Many of the other warnings detailed in this review stem from this central issue especially testing plans using the Make file, XML messaging systems, and debugging with such a convoluted architecture. As a note, the second version of the design document does streamline these subsystems. The other major consideration is the hazards posed in synchronization between the client-server hierarchies. Questions that arise include that of creation of groups; in particular in terms of one machine serving two groups, the problems when updating a group schedule, and the practical limitations of a SATS server, and database limitations of an XML system. 2 Questions 1. In the initial setup of the design document there seems to be no consideration to the practical problems posed as users try to access scheduling information from different computers since information should suffice portability requirements. This is answered in the latest revision with XML messaging systems but this contradicts the testing plans in place. It would seem security testing in terms of the messaging system, along with inconsistent, odd data being sent in would be more important than simple load testing, and authorization testing. The majority of load testing would be applicable to apply stress to a MySQL database rather than a more streamlined XML system. The other major problem is synching group data with the XML system in place since it does not have primary keys. If the XML is to supplant the generic database of MySQL allocation of dynamic IP addresses in NetworkConnector creates issues of multiple users attempting to access shared data. Moreover, how does the NetworkBroadcaster update users who are offline with real-time data changes? 1

2 In addition, with the amount of indirection among the subsystems how cohesive will testing be? Is it possible to separate integration testing without security considerations posed by the XML system? 2. DTDs for the XML files should be included. How are the two types different? Also, it is unclear how and when the XML files will be updated and loaded. Is the whole file going to be loaded and parsed every time? This may cause scalability problems and should be discussed in the Document. The parsing method for the XML files should also be specified in the document (SAX? DOM?). Some arrows in the class diagram are not labeled. It may be a good idea to indicate to which subsystem each class belongs. Classes such as RecurrentRule, FilterRuleInterpreter, Scheduler, and TimeTaskHandler are missing data members, therefore, it is unclear what each instance represents. 3. A. Requirements: In reference to SATS Requirements & Specification Document : B. Design: (a) p. 2: "User can set his own computer as the main server that others connect to." How do other users specify who to connect to (e.g. IP address)? (b) Use Cases 2-4: What permissions are imposed on these actions? For instance, can anyone in the group see anyone else's statistics? (c) Use Case 5: The Alert only works if SATS is already open? Can it be running in the background (is there a background mode)? (d) Use Case 7: SATS must be open to act as a server? Again, can it be running in the background? In reference to SATS Design & Planning Document : (a) How would the System Architecture Diagram change if you were to release a version that was incapable of connecting to a group? In other words, if ScheduleServer and Database were disabled, could SATS still be used locally? (b) I'm having trouble understanding exactly what the difference between Database and LocalDatabase is. Is there any scenario in which they would hold duplicate data? Is Database holding any more data than it needs to (could lead to security concerns)? If I'm a member of Group A, served by Database 1 (which presumably resides on some server machine 2

3 somewhere else), and my LocalDatabase is fully synced, is there any difference between the data in LocalDatabase and the group Database? (c) If my machine is the server for my group, is there any notion of a ForeignDatabase? (d) "If bool group = true then the ownerid refers to the groupid, if it is false then ownerid refers to the userid." This seems like a very complex scheme, with a number of possibly unintended ramifications. For instance, can a task have no ownership within a group? Does every group task belong to the group at large? What if my group has 500 people? I need some way to impose scope in the tasks. These limitations, it seems to me, would make the program much less powerful. (e) "If a recurrent task is modified Scheduler calls createsingle() to obtain a single instance of that recurrent task with the new information." I do not understand this statement. Does this mean that if I make a change to a recurrent task, it becomes a singleton task? Do I have to make a new recurrent task to get one with properties slightly different from one I already have? (f) "The Alerter is a thread that sleeps and wakes to check the time. On start it will ask the Scheduler for a Schedule of tasks for that day and the next." Why will it request a Schedule by day? Why not the next x upcoming tasks? Is there a scenario by which the Alerter could miss an alert if it receives the daily list at 11:59 on Day 1, sees nothing to alert, does not check again until 12:30 on Day 2, and misses an alert it was supposed to issue at 12:01 on Day 2? (g) "It will wake up every minute to check the time and when it is time to alert the user it will." Why not look ahead to the next alert time, and wake the thread when (next_alert_time == current_time)? (h) "Also, if we don t want to have it wake every minute we can have it check how long until the next alert and sleep until half the time is up (e.g. half a day), check time, then sleep for half that time, etc. waking in smaller and smaller increments until it checks every minute." What is the goal here? Wake as rarely as possible while not missing a task? Why not wake exactly when it needs to make an alert (see h above), and also wake whenever a new task is created to check if it needs to add that new task to the alert queue? 3

4 (i) "We cannot disallow the users from changing their information offline because some users may want to use SATS solely for single user mode." If a user is using SATS in group mode, can s/he make changes offline? How do you reconcile contradictory changes by different group members? (j) Are there any permissions regarding which users can remedy synchronization discrepancies? Could a malicious user toast the group's schedule by inserting nonsense tasks? Could a stupid user? Can anyone delete tasks? (k) In my opinion, there is a massive problem when dealing with updates to a group schedule. If the client is online, the server database is updated, then the local database is updated. Presumably the server is checking for conflicts, creating unique IDs, etc. But if the user is offline, the local database is immediately updated and the server database is updated at next sync. This implies that all the work the server database does before allowing the client to update the local database if the client is online is not necessary. How can the client update the local database if it has to wait for unique IDs from the server database? (l) Along the same lines, are there any limitations as to how often the client must sync with the server? If one is allowed to go any length of time without syncing, the databases could become catastrophically conflicted. (m) A possible solution to these concerns is to not allow the client to make changes to the group schedule while offline. The client would act either in a read-only mode, or it could allow updates to the personal schedule. BUT due to d above, there's no notion of a Group vs. Personal task/schedule, so that means the user would not be allowed to make any changes. (n) With the proposed implementation of the Group and User tables, a given group can have only one member. You need to store GroupID in the User table. (o) What is the database field User.Contact? If it's for storing contact info, then to conform to 1st Normal Form, you should have separate fields for User , UserPhone, etc. (p) With the proposed implementation of SingleTask and RecurrentTask, you can only store the most recent ModifiedBy's and ModifiedOn's. This may or may not be important -- you may want to keep a history of the last x modifications. (q) With the proposed implementation of RecurrentTask, Date must contain ALL times that this task will recur. You do note that "Date is a 4

5 multi-valued attribute," but wouldn't this list be infinite-length for most RecurrentTask's? For a given weekly task, you'd need 52 values just to cover a year. And what if it was an every-15-minutes task? Instead, why not store an OriginalDate and a Period. Then it would recur whenever (current_time - original_date) % period == 0. (r) Can files (to which the Filename's refer) be stored on the server for group tasks? If not, users have to exchange files out-of-band, which could be a hassle. Is there any way to make retrieval of these files (whether remote or local) seamless (e.g. you click a widget and a window pops up and asks what program you want to use to open the file)? (s) What practical limitations does a machine used as a SATS server have (e.g. must the machine always be turned on)? (t) Must the same machine always be used as the SATS server for a given group? If so, how does a machine that has never before acted as the server get the Database (which includes information on who is in the group) if the usual server machine is not connected? (u) Can one machine serve two different groups? Simultaneously? (v) Can one machine be a client in two different groups? Serve one and be a client in another? Etc. If so, how does this affect the user experience? Does the user invoke a new instance of the program for each group? 4. Since recurrent tasks and nonrecurring tasks are stored in different files, there would be problem if the user would like to change a task from recurring to nonrecurring, or vice versa. In NetworkConnector class, one cannot just store the IP because the address may be dynamically allocated. (DHCP). XML files have no "primary keys." 5. Running tests during every Make may make building the project very, very slow. I think to adequately try to break the database; you need to do more than just send lots of data. Try odd combinations of records, see if there's any way to break many-one relations, etc. Just sending a lot of data only stresses the database server (e.g. MySQL). Will you do anything special to test remote access? 6. The current targeted platforms on which the application will be deployed for this project seems to be very stable and reliable systems for this type of dayplanner-type application. However, I would like to note that because XML is a very unsafe way to keep data, there might be issues with the customer if s/he wants to have protected personal data. Malicious users can simply open an XML file in notepad or emacs locally and be able to retrieve all the data s/he desires. Also, there are various security concerns regarding WinXP systems during the server/client connection stage. The new release of Service Pack 2 has many 5

6 firewall and added security limitations that might be of concern during implementation of the second release. 7. The plan appears very reasonable in terms of workload distribution and time concerns. However, since the core of the application, the Schedule class, will be worked on by everyone, how will that workload be distributed evenly so that it will result in a consistent and stable class? Since it is such an important part of the program, it would probably be better off if one person work on it (because it is only an facade class), and let others know how they can access it, rather than everyone adding something to it, which might confuse as well as slow down the overall progress of the stage when all the parts need to be fused together. It should be one of the first parts to be completed, so that no hindrance can result as all the parts near completion. 8. There seem to be some inefficiency in terms of the designing of the different classes that handle certain tasks. One example is the TimeTaskHandler class. This class can be united with the Alerter Thread if it just takes times at different instances of each task (This is what the Alerter does anyway -- goes through tasks and checks time). Perhaps they can be merged into a more general class, or perhaps the TimeTaskHandler can even be a part of the Task class if it is only used to time certain tasks. In short, there seems to be a large fragmentation of small classes that either needs to be sorted into a more organized hierarchy or compounded into more efficient components. A Final Note: It should be noted that the majority of this design review has been completed in correlation with the initial version 1.0 of March Since then there has been a revised design 2.0 of March 24, 2005 which may answer some of the inconsistencies we have proposed. However, for reasons of uniformity in terms of a partisan review we focused on the initial design for questions of inconsistency, testing, and issues of implementation while external issues of environment, etc. being general were reviewed with the second document in mind. 6