DELTA 50 0 1110 SVNvLIMNBiA-3p{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} \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. Depending on the options selected 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. \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. \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 the 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. \ \\ --- BI-DIRECTIONAL UPDATING/EDITING???? -- \\ 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. 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. \end{document} ENDREP id: 13.0.r55/8836 type: file pred: 13.0.r54/2994 count: 4 text: 55 0 8813 9932 1e3d3ff0bcd774e49b740ff0599210cf 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 18 file 13.0.r55/8836 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.r55/9249 type: dir pred: y.0.r54/3406 count: 13 text: 55 9049 187 187 4375db6edfb8596188c3a4b7675ddd92 cpath: /project3 copyroot: 0 / PLAIN K 8 project2 V 16 dir x.0.r41/3433 K 8 project3 V 16 dir y.0.r55/9249 END ENDREP id: 0.0.r55/9479 type: dir pred: 0.0.r54/3635 count: 55 text: 55 9392 74 74 d82d62170ab740a30f59ff609d4177d0 cpath: / copyroot: 0 / 13.0.t54-1 modify true false /project3/architecture.tex 9479 9612