DELTA 50 0 1110 SVNvKvMNBiA-Rp3p usepackage[nofancy]{svninfo} \title{Architecture} \author{Andrew La Motte-Mitchell, Adrian Sampson, and Stephon Striplin} \date{\svnToday} \begin{document} \svnInfo $Id$ \maketitle \section{Importer} The purpose of the \textsc{Importer} component is to allow the user to import documents, notes, weblinks and classcasts into the database. This compoment comes from requirements CR1, CR5, and CR8. There will be two types of importing: static importing and dynamic importing. Static importing includes files and scanning, where the source of content is not expect to change. Dynamic importing includes weblinks and classcasts, where the soruce of content is expected to change and information will be handled with updates. \\ The \textsc{Importer} will interact with the \textsc{DBController} by first processing all documents, notes, and classcasts with the \textsc{ContentAnalyzer}. For each source (file, scanned document, weblinks, classcast) the importing will be handled differently. Below are descriptions of the subclasses for each type of importing. Note that they also come about from the same requirements as the \textsc{Importer}. \subsection{StaticImporter} The \textsc{StaticImporter} handles the non-web and non-classcast links. Either files will come from the computer the user is currently working with, or it will come from a scanner. The files imported will be processed by the \textsc{ContentAnalyzer} before being sent to the \textsc{DBController} to be stored. Below we describe in more detail the FileImporter and the ScanImporter classes. \subsection{FileImporter} The \textsc{FileImporter} handles all documents and notes that come directly from the computer. It will allow the user to select a document or a number of documents to import into the database. The file will be processed by the \textsc{ContentAnalyzer} before being sent to the \textsc{DBController} to be stored. \subsection{ScanImporter} The \textsc{ScanImporter} handles all documents and notes that come through the scanner. The ScanImporter will convert the scanned version of the document or notes into either a pdf document or a user-specified format. The converted document will be processed by the \textsc{ContentAnalyzer} before being sent to the \textsc{DBController} to be stored. \subsection{DynamicImporter} The \textsc{DynamicImporter} handles all weblinks and classcasts. It has been subdivided into two classes, \textsc{WebImporter} and \textsc{ClasscastImporter}, which will be further described below. \subsection{WebImporter} The \textsc{WebImporter} handles all weblinks. The website will be processed by the \textsc{ContentAnalyzer} for course information and possible assignments. If any course information is found it will be created as tags and passed along with the weblink to the \textsc{DBController} to be stored. \subsection{ClasscastImporter} The \textsc{ClasscastImporter} handles all classcasts. The classcast will be sent the \textsc{ContentAnalyzer} to be processed for initial course information and assignments. The classcast will then be passed to the \textsc{DBController} to be stored. \section{Exporter}After a few iterations, we feel that the following subcomponents are distinct enough to warrant segregation. Those that are very similar have been grouped together. The changes we made are detailed in those components that were modified. Please note that each of these components has \subsection{Email Exporter} The purpose of the \textsc{EmailExporter} component is to allow users to quickly and easily share documents with team members via e-mail. This feature is a direct response to requirements CR12 and CR30. A key aspect of this feature is that the user can easily send a message to a group of people without typing each e-mail address individually. Given a group name and a list of members of that group, Cue will open the users default mail program and create a new message with each group member's e-mail address in the recipient section. If specified by the user, Cue will automatically attach files to this message. In addition to the interaction with the user and database, this component must have a way of interacting with the default mail program, as well as an address book that may be internal or external. We were unsure if this component deserved to be in the \textsc{Exporter} category. We were concerned that the storing of group mailing lists and interaction with the mail program warranted a special category. However, upon further consideration, we agreed that this feature's main purpose is to export data so we decided to keep it in the \textsc{Exporter} category. \subsection{iPod Exporter} The purpose of the \textsc{iPodExporter} is to allow the user to export documents to an iPod. This feature is a direct response to requirement CR25. This component should be able to dynamically update files. For example, if a file is more recently modified on the iPod than on the main machine, Cue will update the file on the main machine. New files should be automatically recognized and added accordingly. An appropriate file type, that allows easy viewing on the iPod, must be carefully selected. In addition to interacting with the database, this component must interact with the user in special ways. The user should decide if she would like an absolute sync of all files, or if she prefers to manually chose which files are exported to the iPod. If the latter is true, the user must specify a destination for those files she wishes to transfer to the iPod. Additionally, this component must be able to dynamically transfer data with the iPod. \subsection{File Exporter} The file exporter allows multiple Cue users to share files. The format of these files does not need to be specific to cue, but it must be consistent. When a document is transferred from one computer to another, it should have the same properties on the new computer as the original. This feature is a direct response to requirement CR29. This component will interact with the database in the same way the other components do, but it will require special input from the user. Specifically, it will need to know where to export the file, and in what format (if this is an option). Also, this component must be able to interact with the user's operating system in order to save the file in the proper location. If a file with the same name already exists in the specified location, Cue must alert the user of the problem, and then allow the user to chose a reasonable course of action: replace the file, change the name, or cancel the action. \subsection{Printer} The purpose of the \textsc{Printer} component is to allow users to create hard copies of their documents. This feature is a direct response to requirement CR28. It is important that documents are formatted in a way to fit easily (with reasonable and customizable margins) on a page of variable size. In addition to interacting with the database, this component must be able to interact with a printer. It must be able to communicate with the printer to determine the size of the paper being used. The \textsc{Printer} component will also require special input from the user. The user should have a variety of print formatting options that are presented in a logical and consistent manner. \subsection{Publisher} The purpose of the \textsc{Publisher} component is to allow the user to post their documents to specific programs. This component has two important subcomponents, detailed below. Each component has a unique interface requirement, so we will not attempt to generalize their needs here. Our original architecture did not include the \textsc{Publisher} component. We added it because we felt that the \textsc{ClassCast} and \textsc{Calendar} features were similar enough that they should be grouped together. Also, these features are distinct from the rest of the \textsc{Exporter} components, further justifying this separation. \subsection{ClassCast Publisher} The \textsc{ClasscastPublisher} allows users to share assignment information and documents with fellow users of Cue. A user can publish her documents on a public server, and let other users subscribe to this \textsc{ClassCast}. The most important aspect of this feature is that \textsc{ClassCasts} update automatically; whenever the administrator of a \textsc{ClassCast} makes a change, the server is automatically updated. The subscribers to this \textsc{ClassCast} will see this change the next time they open Cue. This component was created to satisfy requirement CR27. This component must be able to communicate dynamically with a server. When the user makes a change to a document that has been marked as a \textsc{ClassCast}, Cue will automatically update the server's version of this file. This component must also allow the user to specify which files to add to a \textsc{ClassCast}. It must annotate this file in a way that reflects which \textsc{ClassCast} it belongs to. \subsection{Calendar Publisher} The \textsc{CalendarPublisher} component allows users to use their favorite calendar program to view their upcoming assignments, classes, and other events. This feature is a direct response to requirement CR26. This component must allow dynamic communication between the database and a third party calendar program. When a change is made to an assignment or task in Cue, this change must be reflected in the calendar automatically.\footnote{We considered making this relationship bidirectional - having changes made in the calendar program reflected in Cue's database - but this did not seem feasible. After researching the way current calendar programs interface with each other, we found that a unidirectional relationships are already supported, but bidirectional relationships do not seem to be. Also, this presents an importing challenge that seems to be more trouble than it is worth. If there is sufficient user demand, this feature may be interesting for later releases. } The user must interact with Cue to select the calendar program she wishes to share data with. Cue will publish the data in an appropriate format, and then the user must configure the calendar program appropriately. \section{Database} As an implementation of the ``repository'' design pattern, this central database is the natural solution to a situation in which several relatively independent components need access to the same data. Using a single controller class will allow arbitration of access and provide consistency of interface if the underlying data store is changed or replaced. A ``smart'' database was briefly considered: under this model, the database would be responsible for content analysis and detection of connections between documents. A more conventional, straightforward controller was chosen because no significant benefits of the smart database could be ascertained, good implementations of conventional databases already exist, and integrating content analysis with data storage violates some principles of modularity. \subsection{DBController} The \textsc{DBController} provides the connecting interface between Cue's data and its input, output, and manipulation components. It is responsible for storing data units (described below) and supporting queries of the data. In particular, methods are provided to fetch, store, delete, and modify \textsc{Document}s (both \textsc{Note}s and \textsc{Assignent}s) and \textsc{Courses}. The presence of the \textsc{DBController} and all the database classes (listed below) supports nearly every one of Cue's requirements. The presence of such a database was presumed \emph{a priori} before the requirements were written (see the introduction paragraph to the requirements document). \subsection{Document} A \textsc{Document} object represents any information artifact stored in Cue's database. Primarily, it has one large field for the document's data. The data is of arbitrary type and may be a text or binary file. Additionally, the object exposes a basic set of metadata fields, including document title, creation and modification dates, and an optional association with a \textsc{Course} object. \subsection{Notes} As the most basic subclass of \textsc{Document}, the \textsc{Notes} class serves mainly to differentiate reference documents from coursework. A \textsc{Notes} object includes one additional metadata field: a date indicating that of the lecture from which the notes were taken. \subsection{Assignment} An \textsc{Assignment} is a kind of \textsc{Document} that the user considers a task. The document data is assumed to fully describe the task to the user, but additional metadata is exposed for querying and manipulating \textsc{Assignment}s, including due date, start date, completion progress, assignment type (problem set, project, final...), priority, and a list of pointers to \textsc{Assigment}s that represent subtasks of the current \textsc{Assignment}. In addition to the general support afforded by the database, this delineation of an \textsc{Assignment} was dictated by requirements CR20, CR5, CR6, CR28, CR26, CR16, and CR27. \subsection{Course} \textsc{Course} objects provide a way for information about a student's classes to be stored independently of individual documents. A \textsc{Course} exposes references to all the \textsc{Document}s associated with it and a set of metadata: professor name, class times, office hours, and course URL. Additionally, an ``archived'' bit will be exposed indicating whether associated documents should be excluded from most searches. The presence of a distinct \textsc{Course} object supports requirements CR14, CR19. \section{Views} User interfaces are provided to allow viewing and manipulation of the documents stored in Cue's database. These are represented as distinct objects to increase modularity and to clearly distinguish between different methods of presenting Cue's database. \subsection{Searcher} A \textsc{Searcher} is a user interface element (a window or tab, for instance) responsible for allowing arbitrary queries of the database and presentation of the results. It keeps a reference to the shared \textsc{DBController} interface to perform its queries. It also exposes a list of criteria, represented as field/pattern pairs that are used to formulate the database query. Methods for addition, modification, and removal of criteria are provided; when such a method is invoked, the query is rerun if necessary and relevant UI elements are updated. A similar interface is provided to the \textsc{Searcher}'s sorting key. \textsc{Searcher} supports requirements CR21, CR22, CR23, and CR24. \subsection{Viewer} A \textsc{Viewer} is a constrained kind of \textsc{Searcher}. Instead of exposing methods to directly manipulate search criteria, a \textsc{Viewer} only exposes a ``type'' attribute; the type of the \textsc{Viewer} will determine a predefined set of relevant search criteria. Types include: \begin{itemize} \item \textbf{By due date}: query the database for \textsc{Assignment} objects that have not been completed; sort by due date \item \textbf{By priority}: query the database for \textsc{Assignment} objects that have not been completed; sort by priority \item \textbf{By course}: a \textsc{Course} must also be selected; sort all associated \textsc{Document}s by date \item \textbf{By term}: display all \textsc{Documents} associated with all \textsc{Course}s from a given term \item \textbf{By project}: a \textsc{Assignment} must also be selected; sort all subtasks of the \textsc{Assignment} by due date \end{itemize} \textsc{Viewer} was initially considered a separate class from \textsc{Searcher}, but, during early architecture discussions, it was determined that the two had nearly identical functionality. A ``view,'' as it was discussed during the development of requirements, is most easily implemented as a specialized, constrained searching interface. A view is, however, distinct from a search in most users' minds, so the two are not entirely indistinguishable. This class supports requirements CR17, CR18, CR19. \subsection{Scheduler} The \textsc{Scheduler} is a user interface element that supports streamlined manipulation of due dates and subtask relationships. Such an object will associate with a set of \textsc{Assignment} objects; these tasks will be placed on a calendar-like interface. It will keep a reference to the \textsc{DBController} in order to fetch and create \textsc{Assignment}s. The \textsc{Scheduler} will need to be much more clearly specified before implementation; a UI prototype could help. A \textsc{Scheduler} is required by CR16. \section{Content Analyzer} % Not done! \end{document} ENDREP id: 13.0.r63/16826 type: file pred: 13.0.r58/1636 count: 8 text: 63 0 16803 17867 841907811c87ff17ecab38f4b9183af0 props: 51 208 29 0 ff5c3c1f7bdb48ba0201950780ae7e31 cpath: /project3/architecture.tex copyroot: 0 / PLAIN K 20 architecture.graffle V 19 file 10.0.r47/14098 K 16 architecture.tex V 19 file 13.0.r63/16826 K 19 component_specs.tex V 16 file 14.0.r61/41 K 21 individual_components V 16 dir 15.0.r62/428 K 16 project_plan.odt V 17 file z.0.r48/7520 K 11 svninfo.sty V 18 file 12.0.r49/5199 END ENDREP id: y.0.r63/17339 type: dir pred: y.0.r62/868 count: 21 text: 63 17042 284 284 a39f5258e920a00e420a9ee5ba83ec59 cpath: /project3 copyroot: 0 / PLAIN K 8 project2 V 16 dir x.0.r41/3433 K 8 project3 V 17 dir y.0.r63/17339 END ENDREP id: 0.0.r63/17571 type: dir pred: 0.0.r62/1094 count: 63 text: 63 17483 75 75 1708878b9373bf2b6b08907f17843eca cpath: / copyroot: 0 / 13.0.t62-1 modify true false /project3/architecture.tex 17571 17706