Please refer to Section 1 of the Operational Concept Definition.
Function: Creates new web pages.
Description: The instructor user clicks on the new page button which internally creates a new HTML file and assigns a new page number to the page. The previous page is moved off the screen and the blank page is displayed to the user along with its assigned page number.
Input: The "new page" button is pressed.
Source: The user who wants to create a new page.
Output: A new HTML file.
Destination: The student site where the new file is stored.
Requires: A user who wants to create a new page and disk space to store the web pages.
Pre-Condition: The user wants to create a new page on the student site.
Post-Condition: A new HTML file is created which is ready to be edited.
Side Effect: If too many web pages are created, or if the student site becomes too big, a large amount of disk space will be required.
Function: Modifies web pages.
Description: The instructor can edit pages on the site from the instructor user page. First, the instructor selects the web page he or she wants to edit by either clicking on forward/backward arrows, or by typing in the page number and pressing a select page button. The page selected will appear in a text editor on the instructor user page, which is implemented as a java applet. The text editor is also referred to as a "dummy page." The "dummy page" is actually a preview page which the instructor can edit that reflects how the modified page would look if it is saved to the student site. The instructor can edit the dummy page/text editor, and is allowed to add or delete links or images. To add a link, the user either highlights some text and clicks on the link button or just clicks on the link button which would require that the user enter the name of the link. The user then needs to specify where the link points to by entering either the URL of a remote site or the page number of a local web page. If the user wants to add an image, the user clicks on the image button which brings up a wizard/screen with a list of the available images on the server. When the user is satisfied with the way the "dummy page" looks, the instructor clicks on save, and the student site is updated with the contents of the "dummy page." Note that only one instructor can edit a web page at any given time. If a professor is editing a page, and a second instructor tries to acquire the lock, an error message will be displayed to the second user saying that the site is currently being updated. The second instructor will not be allowed to edit the site until the first professor finishes making his changes.
Input: The text inside the editor, particularly what was highlighted, and which button was pressed.
Source: The contents from the text editor and the operation desired.
Output: An updated web page on the student site.
Destination: The student site.
Requires: Input from the user and a web authoring program.
Pre-Condition: The user wants to edit a web page on the site.
Post-Condition: Updated web page on the student site.
Side Effect: None.
Function: To select which web page the instructor wants to modify.
Description: When the instructor edits pages on the student site, he must first specify which page he wants to modify. The page number of the page currently being displayed in the text editor/"dummy page" is clearly indicated on the screen. The instructor can select a different page on the site by using left and right arrow buttons which cycle through the pages on the student site. There is also a small box where the instructor can type the page he wants to edit. Then, if the professor hits the "go to page" button, the desired page will be brought up in the "dummy page" where the instructor can edit it.
Input: The left and right arrow buttons, or the "go to page" button and the page number entered.
Source: The user who wants to select a different page.
Output: The desired page.
Destination: The text editor/"dummy page" on the instructor site.
Requires: Input from the instructor who wants to select a different page.
Pre-Condition: The instructor user wants to select a web page to edit on the student site.
Post-Condition: The selected web page is displayed in the text editor where it can be modified.
Side Effect: None.
Function: To translate a web page from French to English or English to French.
Description: We need to have the student site's web pages available in both English and French. When a web page is created or modified, it is sent to the translator site where a French and English version of the web page is created. Thus, each web page on the student site has three versions: an English version, a French version, and the Original version which could be composed of a mixture of French and English. At the top of every web page on the student site, there are links to the three versions: the English version, the French version, and the Original version. To see a certain version, the user simply selects the desired link and the appropriate version will be loaded.
Input: The web pages that compose the student site.
Source: The web pages of the student site and a French/English translator.
Output: Three different versions of the web page: an English version, French version, and the Original version.
Destination: The three versions are saved on the student site. The translation is displayed to the client screen upon request.
Requires: The web pages on the student site and a translator.
Pre-Condition: We have a newly created or modified web page.
Post-Condition: We have three versions of the created or modified web page.
Side Effect: Translation time and disk space at server to store translations.
Function: To prevent unauthorized users from accessing particular parts of the system.
Description: We will require all users of the system to have an account with UCS. To enter the system, a user will enter their login name and password. If the login name and password are legal, and the login name belongs to someone who is enrolled in the class, then the user will be allowed to access the student site. Another reason for having a login system is so that we know who uses the system and to have a way of identifying the people that post messages on the bulletin board. Authorized instructors can access the instructor site by selecting the correct link from the student site.
Input: A username and password.
Source: A username, password, and the authentication module.
Output: The student user site is loaded if the login is valid, otherwise an invalid login message is displayed.
Destination: The user's monitor.
Requires: The input parameters from the user.
Pre-Condition: The user needs to enter a login name and password.
Post-Condition: Either the user is presented with the home page for the site, or an invalid login page is displayed.
Side Effect: None.
Function: To provide a form of communication between users of the site.
Description: A bulletin board will serve as a pseudo-live communications forum by which students and instructors can communicate with one another. It is important to note that the bulletin boards on each page are disjoint. Students will have the ability to read and post messages only on the student bulletin board and instructors will have the capacity to read and post on both bulletin boards. The username, the date, and the time will be posted along with each user's message to ensure integrity and proper identification. Furthermore, each bulletin board will possess a sorting mechanism based on date. In other words, a user should be able to select a month and year, and retrieve all the messages that were posted during that time period.
Input: The user's message and the selection of the "post" button.
Source: The user.
Output: An updated bulletin board.
Destination: The message is saved in the server. The modified bulletin board appears on the web browser.
Requires: The user's message and disk space to store the messages.
Pre-Condition: The user needs to enter text into the designated message area on the student or professor user page and click the "post" button.
Post-Condition: The message is saved and the bulletin board is updated with the user's name and a time stamp appearing under the message.
Side Effect: Disk space to save the messages.
Figure 4.6.1 Posting to Student Bulletin Board Sequence Diagram
Figure 4.6.2 Selecting Student Bulletin Board Messages Sequence Diagram
Figure 4.6.3 Posting to Instructor Bulletin Board Sequence Diagram
Figure 4.6.4 Selecting Instructor Bulletin Board Messages Sequence Diagram
Function: To search for keywords.
Description: A student might want to perform a search on a particular keyword. The student user enters the keyword(s) into the search text field and clicks on the search button to process the query. A list of query results are then returned to the user.
Input: The French or English keywords the user wants to search for.
Source: The input of the user from the search form.
Output: A list of links to pages and documents on the site that contain words which match the user's query.
Destination: The user's screen.
Requires: The user's query, a search engine, and the course site web pages which the search is done on.
Pre-Condition: The query is submitted from the search form on the search page.
Post-Condition: All links, if any, that match the user's query are shown on the screen.
Side Effect: Cost of a good search engine.
Function: To fetch a file.
Description: This operation uses FTP to retrieve a file from a remote site. The instructor user then clicks on the fetch button which prompts the user to enter the name and the ftp address of the desired file. If the filename or address location are incorrect, then the system will inform the user appropriately; otherwise, the file is stored on the server for future insertion into a student web page.
Input: The ftp address of the file to be fetched.
Source: The user and the ftp address submitted.
Output: The retrieved file.
Destination: The file will be stored on the server.
Requires: The file's ftp address.
Pre-Condition: The ftp address provided exists.
Post-Condition: The document, if found, is saved on the server.
Side Effect: If a lot of files are retrieved, or if the retrieved files are large (i.e. a video or audio clip), they may require a large amount of disk space on the server.
Function: To time stamp web pages.
Description: At the top of each web page created on the site, there will be a date and time printed which states when the page was last modified. This time stamp should automatically be updated whenever a page is edited.
Input: An updated web page, the date, and the time.
Source: The updated web page and system clock.
Output: A web page with a time stamp at the top that relects the last time the page was changed.
Destination: The source file of the web page.
Requires: The date and time and a modified site web page.
Pre-Condition: A web page is updated.
Post-Condition: At the top of the modified page, there is a date and time printed which states when the page was most recently modified.
Side Effect: None.
Function: To allow users to send email to the professor.
Description: An email link to the instructor(s) will be provided to email questions or comments to the professor. Although this feature is intended primarily to be used as a means of communication between students and professors, instructors may also want to copy and paste text, such as bulletin board messages, into the email body and send the messages to themselves to either store or print them. When an email is sent to a professor, two copies of the message are sent: one to the professor and one to the student who sent it.
Input: An email address and message.
Source: The message from the user and the email address.
Output: A sent email message.
Destination: The mailbox of the instructor.
Requires: A user who wants to send a message to a professor.
Pre-Condition: The system is ready to send email messages.
Post-Condition: The email is sent to the professor.
Side Effect: None.
Function: To have a log that reflects the changes made to a web page on the course site.
Description: Whenever an instructor adds something to the site, it would be convenient for students to be able to look at a log listing all changes made to particular page so that they can find out what the most recent modifications were (i.e. what images and links have been added or deleted and when).
Input: A professor's name, the changes they made, and the date/time they were made.
Source: A change made by the instructor user to a web page on the student site.
Output: An updated log showing all the changes made to that web page.
Destination: The log for the modified page.
Requires: A modification to a web page on the student site.
Pre-Condition: An instructor finishes editing a web page on the site.
Post-Condition: The modification log for the page is updated.
Side Effect: Disk space to store the log.
Figure 4.11.1 Updating The Modification Log Sequence Diagram
Function: To have a log that records the number of times that a web page on the student site has been accessed, and the number of times that each student has logged into the system.
Description: The instructor might want a way to tell which pages on the student site are getting accessed the most, and which students are using the system on a regular basis.
Input: The student's name and the date/time they accessed a page.
Source: A student who has logged into the system and is browsing pages on the student site.
Output: An updated log showing that a student accessed a particular page.
Destination: The statistical log.
Requires: A student accessing the site.
Pre-Condition: A student accesses a page on the student site.
Post-Condition: The statistical log is updated.
Side Effect: Disk space to store the log.
Figure 4.12.1 Updating The Statistical Log Sequence Diagram
Function: To prevent more than one instructor from modifying web pages on the student site at any given point in time.
Description: We do not want to allow more than one instructor to update the student site at the same time, otherwise we will run into concurrency problems.
Input: The "modify site" button is pressed.
Source: The web authoring module.
Output: A flag which indicates whether or not the lock was acquired.
Destination: The web authoring module.
Requires: A professor who wants to edit a page on the student site, and a locking module which handles the acquiring and releasing of locks.
Pre-Condition: An instructor wants to modify a page on the student site.
Post-Condition: If the lock is free, it is acquired and the web page authoring module is informed that it has the lock. Otherwise, the locking module informs the web page authoring module that the lock was already acquired by another user.
Side Effect: None.
Function: To provide a convenient way for users to find information about how to use the system.
Description: We want to provide an on-line FAQ about the system so that students and instructors can easily find information to questions that they have about using the system.
Input: The user clicks on the help link.
Source: The user.
Output: The main page of the help site is displayed.
Destination: The user's screen.
Requires: A help site and a user who needs help.
Pre-Condition: A user needs help and selects the help link.
Post-Condition: The main page of the help site is displayed to the user on the screen.
Side Effect: None.
The International Cross-Cultural Teaching model is designed to be a semi-autonomous system that interfaces with a web server. Moreover, the ICTM interfaces with its users through web browsers. The user interfaces must be user-friendly. The system's translation module interfaces with a translator, which must be on-line in order to guarantee accessibility to all users. If the translator is not provided on-line, each user will have to install translators on their own computers, which would seriously impair the availability and usability of the system.
A student or instructor can access the system through the Web. A user first must log into the system by entering their user name and password. Following a successful login, the student user page is displayed, where links to documents and other French web sites are shown. Furthermore, there is a link to the search page where the user can enter a query in either French or English, and receive a list of documents and web pages on the site that match on the specified keywords. Located at the top of each page is a time stamp which indicates the date and time that the page was last modified. The time stamp is also a link to a modification log which lists exactly what changes were made to the page and when. In the communications window (used for the bulletin board and email), there's a message area where the student can type a message, and post it to the student bulletin board. When someone submits a message, it appears on the bulletin board along with the user's login name, the date, and the time that it was posted. This is done to hold students accountable for the messages that they write. In addition, the messages can be sorted by date. Both students and instructors can post to the bulletin board on the student page. By clicking on the "email" link, an email form appears in the communications window. Here the user can type in a subject and a message, and send it to the professor. The person who sends the message also receives a copy of it.
From the student page, there is a link to the professor page. If the user is registered as an instructor, clicking on the link will allow the professor to go to the instructor page. On the instructor page, there is a bulletin board which is identical to the student bulletin board, except that it is for instructor use only. On the left side of the instructor page is a series of buttons that perform the operations of acquiring the lock to edit the page, link/image addition and deletion, new web page creation, fetching, and saving (updating the student site). There are also buttons that allow the user to cycle through all the web pages created on the site, and to go to a web page directly. Also on the instructor user page is a text editor/"dummy page" where instructors can edit their web page, and see how the changes will look before updating the student site with the modified page.
The user types their message into the bulletin board text editor and then submits it. This data item is a buffer to temporarily store the item as it is passed through the system.
Similar to the bulletin board messaging system, we need a buffer to hold the email message the user types into the email text editor. The message is stored in this data item, and is used to transfer the message to the email server.
This is a buffer to hold the subject of the email message.
Our student site consists of web pages that the instructor creates. This data item is simply an html text file. Each page on the student site has three versions: an English version named epageX.html, a French version named fpageX.html, and the original version named opageX.html, where X = the next available page number. For example, if our student site has two pages (2 pages * 3 versions = 6 site pages total), then the next available page number would be three. Hence, the next page created would have three versions called epage3.html, fpage3.html, and opage3.html.
When a web page is edited by an instructor, we copy the page he wants to modify into a dummy page. This dummy page is a temporary file that the modifications are made to until the instructor decides that he/she is satisfied with the changes. When the professor clicks on update, the dummy page is sent to two locations. It gets sent to the translation module where a French and English version is created. The dummy page is also sent to the student site where it is saved on the server.
When a page is modified, it is sent to the translation site where an English and French version are created. This data item refers to the translated files. The naming of the created files is as follows: if the original file received is opageX.html, then the French version will have the name fpageX.html and the English version will have the name epageX.html, where X = the number associated with the page. So if the input page is opage2.html, then the French version created will be named fpage2.html, and the English version will be called epage2.html. The "f" at the beginning of fpageX.html stands for "French" and the "e" at the beginning of epageX.html stands for "English."
Messages are displayed according to the month and year that the user selects. So if the user wants to see all the messages for November 1997, he selects the appropriate month and year from the menu displayed above the bulletin board, and presses "Get messages." This data item contains the month and year that the user requests, and is passed to the bulletin board module.
The bulletin board messages for each month will be stored in a file. The name of the file will be based on the month and year that the messages were posted: bb-[month]-[year].html. For example, the file containing messages posted in November 1997 will have the name bb-11-1997.html.
Messages are displayed according to the month and year that the user selects. So if the user wants to see all the messages for November 1997, he selects the appropriate month and year from the menu displayed above the bulletin board, and presses "Get messages." This data item contains the month and year that the user requests, and is passed to the bulletin board module.
When a user wants to add a link, two things must be specified: the type of link that will be added (edittype), and the name or location of the document that the link will point to (addstr). If the user wants to add an image, only the name of the image must be entered (addstr).
addstr = a URL if edittype = 1
addstr = a page number (in ASCII) if edittype = 2
addstr = a file name if edittype = 3 or edittype = 4
The user needs to specify information to perform the fetch. The data items used are: username which stands for user name, password which stands for password, rfname which stands for remote file name, and lfname which stands for local file name. file name.
When deleting a link or an image we need to specify what we want to delete. This data item specifies the item to be deleted, such as a URL, file name, or student site page number.
At the Instructor Site, the professor needs to specify what page they want to modify. The user enters the page number which is used to acquire the lock and retrieve the file.
After receiving a lock request, the locking module sends a message back to the instructor site saying whether the lock was acquired or not.
The help FAQ(user's guide) is stored in an ordinary file.
When we update the modification log, we have to pass it the name of the file that was modified, the name of the user who edited it, the date/time, and the modification (create, add, delete) that was made. We pass this data using four separate character buffers.
To update the statistical log, we have to pass it the name of the file that was accessed, the name of the user who looked at it, and the date/time it was viewed. We pass this data using three different character buffers.
6. Quality Attribute Requirements
In addition, another performance issue is the amount of time that it takes to process a search query. Our system supports searches only within the course web pages and the documents they contain. Therefore, since all searches are restricted to files that are stored locally on the server, query processing should take less than 10 seconds to complete 85% of the time.
In addition, under normal operating circumstances, the system should be available 7 days a week, 24 hours a day. The only time the system should go down is if the server crashes or is shut down for maintenance.
1. The system is being designed so that it is platform independent. Thus, any type of computer can be used (Mac, PC, Sun) as long as it has a web browser. The server and memory space will be provided by USC.
2. The developer should be very familiar with HTML. It might also be helpful if the developers understand French.
3. The customer will be provided training on how to use the software. If the users have trouble using the system, the customer will be responsible for helping them.
4. The system should be capable of handling up to 100 users at any given time in order to ensure easy accessibility of the system. If the server is constantly overloaded, usage of the system may decline.
5. To use the system, it is recommended that a computer with at least 16 Megabytes of RAM and 8 Megabytes of free hard disk space is used to facilitate good performance from the web brower which runs during interaction with the ICTM.
8. Evolution Requirements
The product has been designed to account for the following issues:
Scalability:
We want the system to be able to handle up to 100 users at a time.
Later, we might also want to add mirror sites.
Modification:
If more functions are added, we want to do it as early in the developmental
process as possible. Also, any extra functions added should not require
modification of the operation concept definition.
Modifying the system to do translations in other languages such as Italian, German, and Spanish is possible, although it would be difficult to adjust the ICTM to work with languages that use different character sets such as Japanese, Chinese, and Korean. These types of modifications will be dealt with if and when the user requests them.
Link updating-the process by which obsolete or outdated links were automatically updated by the system - was originally considered as an optional feature of the ICTM; however, it was found infeasible to actually implement such a function due to time constraints. Instead, it was agreed that the system administrator could update links on a periodic basis. Incorporating an automatic link updating feature into the system is a possible idea for future evolution of the system.
Performance:
To reduce the overhead of translation time, documents and web pages will be
translated and saved in the server as they are updated or added to the
system. Since searches are restricted to pages and files located on the
server, query processing should require no longer than ten seconds. Better
hardware and fast network conditions would also improve execution time.
Authentication:
We will require all users of the system to have an accountbwith UCS. To enter the system, a user will enter their login name and password.
If the login name and password are legal, and the login name belongs to someone
who is enrolled in the class, then the user will be allowed to access the student
site.
9. Notes
1. The system is being designed for use by students and professors who have very little technical knowledge. Hence, it is crucial that the system is easy to use.
2. This system is being designed specifically for use by French classes.
3. The cost of the translator should be as low as possible, preferrably a free one available on the web.
10. Glossary
Authentication: The verification of the identity of a person or process. In our proposed system, authentication verifies that a user is a registered instructor and/or student.
Authoring web pages: The modification of a web page. In our ICTM system, the editing operations that an instructor can choose from are adding and deleting links and images. The authoring of a web page typically consists of creating an HTML file and editing it directly by hand. Our system will shield the instructor user from having to know HTML, will create HTML files, and allow the addition/deletion of links and images by merely clicking on a few buttons and entering some simple commands.
Bulletin Board: In reference to a physical piece of board on which people can pin messages written on paper for general consumption - a "physical bboard"), a bulletin board is a computer and associated software which typically provides an electronic message database where people can log in and leave messages. Any registered user may submit or read any message in these public areas.
FAQ: A guide containing answers to Frequently Asked Questions.
FTP: Stands for file transfer protocol. This command is used to retrieve files from remote sites.
GIF: Graphics Interchange Format: A standard for compressed digitized images.
GUI: Graphical User Interface: The use of pictures rather than just words to represent the input and output of a program. A program with a GUI runs under some windowing system (e.g. The X Window System, Microsoft Windows, Acorn RISC OS, NEXTSTEP). The program displays certain icons, buttons, dialogue boxes etc. in its windows on the screen and the user controls it mainly by moving a pointer on the screen (typically controlled by a mouse) and selecting certain objects by pressing buttons on the mouse while the pointer is pointing at them.
HTML: Stands for Hypertext Markup Language. A Hypertext document format used on the World-Wide Web. Built on top of SGML. "Tags" are embedded in the text. A tag consists of a "<", a "directive" (case insensitive), zero or more parameters and a ">". Matched pairs of directives, like "" are used to delimit text which is to appear in a special place or style.
Java: A simple, object-oriented, robust, secure, portable, architecture-neutral, general-purpose programming language developed by Sun Microsystems. Java supports programming for the internet in the form of platform-independent Java "applets"
JPEG: Joint Photographic Experts Group: Standard image compression algorithm that is designed for compressing either full-color or grey-scale digital images of "natural", real-world scenes.
Perl: Practical Extraction and Report Language General purpose language, often used for scanning text and printing formatted reports. It provides extensive support for regular expression matching, dynamically scoped variables and functions, extensible run-time libraries, exception handling and packages, provide/require.
Translator: In the context of our project, a translator is a computerized software module that translates words or phrases from one linguistic language (English/French) to another.
