Team 16 December 8, 1997 CS 577A
Table of contents
1. System Architecture Overview
3.1. Description of Current System
3.2. Change to Current System and Rational
3.3. Stakeholders and Responsibilities
6. Glossary
This system is mainly to provide a web-based application that allows instructors of course French 400 in University of Southern California to distribute class-related material to the students. The system will also provide communication futures that allow the students and the instructors to share their thoughts. In addition, translations between English and French will be provided in the system. For more detail, please also refer to OCD 1.0
Operational Concept Definition
System and Software Requirements
Description
System and Software Architecture Definition
Software Development Plan (Life Cycle
Plan)
Prototype
3.1. Description of Current System
Currently, the system is only a web site created by a student assistant. The system requires an experienced web page creator or maintainer to modify the web site. Usually, an instructor is not a good web page creator. Thus when an instructor want to modify something, she/he ask the student assistant to do so. For detail, please refer to OCD 3.
3.2. Change to Current System and Rational
Since current system requires an experienced web page maintainer to modify the class web site, the instructor who is usually naive web page maintainer, has difficulty to modify the class web site directly. Thus a new system with more flexibilities is required. This system should provide easy web page modification functionalities. Also, the customer require some communication functionality for both student-to-student and instructor-to-instructor. For detail, please refer to OCD 3.2 and 4.
3.3. Stakeholders and Responsibilities
There are several stakeholders.
Student users are mainly the learner, which browse the web site as a supplementary learning besides the lectures.
Intructor users can act like students. However, the instructors are mainly the information provider, which add information to the web site for the students to learn.
Both students and instructors can communication with other students or instructors by the communication functionality provided by the proposed system. Communication between instructors are private to the group of instructors, while communication between students are public to all students and all instructors.
Operators is the system maintainer, who maintains this system. Operators have full access of the system, and is responsible for obtaining system training, filling the description, protecting the user privacy and image copyright, operating the system, backing up the system files.
Service maintainer is the software maintainer, who is responsible for updating the system.
For more detail, please refer to OCD 5.2.
3.4. Stakeholder and Operational Entities
Please refer to OCD Attachment 2.
As we can see in the shortfalls in OCD 3.2, our system is to provide an easy way for the instructors to distribute course related materials to the students via a web site.
In addition, intructors and students want to communicate with each other. Some communication funtionality should be included in the system.
Search funiction should be provided, since it's most convinient way to get right information.
Also, this course is a language course. Thus translations are also required.
Other functionalities like authentications (keep unenrolled out), and locking mechanism (for multiple instructors to modify web pages) should be also provided.
For detail, please also refer to OCD 1.1.
Keep in mind that we have multiple instructors in this course. Explicitely, the web site should provide some basic functionalities:
* Authentication- to filter out unauthorized from visiting the site
* Web authoring (instructors only)- to modify (add/delete) web site. Assuming that instructors are naive web maintainer/developer, we want to keep the web authoring functions simple, basic, and easy.
* Searching- searching text on this site. The system will ask for a short description or keywords to be attached to non-text media (images, videos, audios, ..., etc.) for searching.
* Email- Just for convinience.
* Communication (broadcast only)- Intructors and students should have a communication on the web site for course related discussion. Specifically, students can broadcast to all students and all instructors publicly, while instructors can broadcast to instructors privately (students can't hear).
* Translation- All texts in this site should be translated, both English to French and French to English. Both translation should be accessible by all students and all instructors.
Implicitely, we should have a locking mechanism or a merging mechanism when multiple intructors want to modifly the site at the same time. Locking mechanism is chosen rather than merging mechanism, since it's easier and more feasible.
For more detail on performance, reliability, availability, usability, mainatainability, protability, adaptability, and reusability requirement, please refer to SSRD 6, 8 .
For other details please refer to OCD 5.6, and Project Plan 2, 5.
Most requirement concerning architecture are straightforward in OCD 4.1., except the "Collaborative Component". Collaborative component will require a locking mechanism or a merging mechanism, to lock the web pages for one modification at a time or to merge the modification later when multiple instructors modify the web pages simutanously. Locking mechanism is chosen rather than merging mechanism, since it's easier and more feasible.
Essential-
* Authentication: To login, users should provide a valid username and password pair to the system. A login is valid if and only if the username appear in a database D (describe later), and the username and password pair is valid against University Computing Service (UCS) authentication. The database D contains two fields: username, access right. Username is the account name, and access right has two values: `Instructor', which indicates the account has the right of instructor, `Student', which indicates the account has the right of student. A valid instructor login is a valid login with its corresponding access right field valued `Instructor'. A valid student login is a valid login with its corresponding access right field valued `Student'. A valid instructor login can access the instructor site later, in which web pages modification is allowed in the site on line. Invalid logins should be rejected by showing an error message.
* Search: Users should be able search strings in the texts in the local web pages on the server. The search result should be listed as web pages, and by following one of the link on the web pages, the user will go to a web page that contains the key phrase searched. A search result web page should contain at most 25 links. Results containing more than 25 items should be separated into two or more search result web pages. A search result page should have a link to next search result page, if there is more searched items to be displayed. Follow the link of a search result only brings the user to the HTML file containing the search string. To locate the position of the search string in the web page (= HTML file), the user should use the search function provided by the browser. (For example, Netscape web browser provides Edit/Find function to search words in current web page.)
* Translation: Users should be able to select and view the translated HTMP pages of the HTMP pages that the users can select and view on the server. The selected HTML pages are to be sent to a translation site and the translation site returns back to the translated HTMP pages.
* Bulletin Board: This system has two bulletin boards. One is insctructor bulletin board, the other is student bulletin board. Intructors should be able to post messages and select messages to read on the instructor bulletin board, which is private to the instructors. Students should be able to post messages and select messages to read on the students bulletin board. When a user posts a message, the username, date and time should be automatically generated and attached at the end of the message by the system. Users should be able to edit messages on the site before posting her/his messsages to the bulletin boards.
* Web page creation: Instructors should be able to create web pages.
* Web page selection: Instructors should be able to select a web page for preview purpose on the instructor site. The web pages on the site should be numbered. Each page will be assinged to a file name, which is tranparent to the instructor. Instructors only know the page numbers. The system should provide a function allowing instructors to select a certain web page by providing the number of the page. Also, the system should provide a function allowing instructors to traverse pages in the acending and decending order of the page numbers. Also, the traverse order should be wrapped around, when end page reaches.
* Web page authoring Instructors should be able to edit web pages, including only the following actions: a) Add a link to a URL on current dummy page, b) Delete a link to a URL on current dummy page, c) Add a link to a local page on current dummy page, d) Delete a link to a local page on current dummy page, e) Add a link to a local file on current dummy page, f) Delete a link to a local file on current dummy page, g) Add image at the cursor position on current dummy page, h) Delete a chosen image on current dummy page, i) Insert a character, j) Delete a character, k) Delete a string of characters.
* Web page updating: Instructors should be able to update web pages. This will be done by replacing old web pages by dummy pages, which is done by file copy operations.
* Locking: The system should have a locking mechanism to prevent multiple instructors to modify web pages at the same time. A lock file will be created on the server when an instructor request to modify web pages on the server. If the lock file already exists, a instructor's request to modify web pages will fail, and an error message will be displayed. The instructor holding the lock can release the lock at any time. If the instructor have modified something without updating, a pop-up window will be displayed to ask for confirmation when the instructor release the lock. Before getting the lock, the instructor can not do web page updating, web page authoring, and web page creation. Lock has expire time. System should provide a daeman program to detect if time expires. If so, system automatically releases the lock. The time is now set to 1 day, assuming that the network fault occurs seldom. The system should allow administrator to adjust the expire time.
* Fetching: Instructors should be able fetch files via FTP from remote site, by providing the system the FTP address, the path to the file, and the local file name to be saved. The system will check conflict on the local file names, and show an error message if a file name conflict occurs.
Desirable-
* Email: Users should be able to email to the instructors, by selecting instructors, and providing body of the email to the system. The System should automatically generate the sender's name and return email address attached to the end of the body and send it to the selected instructors. The system should automatically send a copy of the mail to the sender.
* Old Messages on the Bulletin Board Removal: System will delete any mesages that is out-of-date, on both bulletin board. The expiration time (out-of-date) is set to 3 months as required by the customer. However, system should allow the administrator to adjust the expiration time. This job is to be done on the daily basis. It will be scheduled at 3:00 AM.
* Time Stamping: The last modification time should be stamped on the first page (the page after passing the authentication process) of student site.
* On-line help: The system should provide an on-line manual pages for using this site. A link to the manual pages should be on the menu bar of the first page (the page after passing the authentication process).
Optional-
* Statistical log: The system should provide a tracking mechanism on the following statistics: - Total number of times each user loging in, which is counted once when a user pass the authentication. - Total number of visit of the web site, which is easily derived by adding all counts of the previous staticstics. - Total number of visit for each page, which is counted once when a page is visited. This statistics will be loged on a file, which is accessible by the adminstrator only.
* Modification log: The system should keep a log of modification. The log should show what files are modified by whom at what date and time. This log is only accessible by the adminstrator. This feature doesn't apply on those modification done by the administrator, since we assume the administrator know the system well, and can backup all modification she/he did.
* Link updating: Usually, when a web site moves, the old page will show a brief message indicating the new site URL. On the web pages, the system should regularily check all links that links to a moved site. If the system detects a moved site, it automatically update the link to the new site. This is done by a C program on the server in a monthly manner. If the server is a system allowing to run scheduled program (like Unix), it is sufficient to register a monthly scheduled program to do this. If not, the program should always run, which just sleep a month and wake to do this job again and sleep a month again ... . To determine if a site is moved is not easy. In fact, we can not garentee 100% determining rate, since it envolves a nature language understading, which is difficult. The following simple algorithm is proposed: string Is_Site_Moved() { if size of HTML file > 2500 then return false; parsing the HTML file, find substring "is moved to", "be moved to", "are moved to", "new site is", "new URL is", if found return the URL string after the above keywords, else return NULL. } The returned string containning new URL is then used to update the link.
Fig. 4.4.0 shows the component model of the proposed system. This reflects to the system requirements. For more detailed behavior, please refer the the next section: Behavior Model.
This figure (use case diagram) shows the relation between use cases. The following sequential diagrams show the detailed behaviors.
Figure 4.5.1 shows the behavior of creating a web page.
Figure 4.5.2 shows the behavior of web page authoring.
Web Page Development is to allow instructors to develop web pages on line. This includes the following behaviors: add an image, add a link, create a page, delete a char, delete a string, delete a link, insert a char, select a page, and update,
Figure 4.5.3 shows the behavior of selecting a web page for page authoring.
Figure 4.5.4 shows the behavior of translation.
Figure 4.5.5 shows the behavior of authentication.
Figure 4.5.6.1 and Figure 4.5.6.2 shows are sequential diagrams for reading bulletin board, for instructor bulletin board and student bulletin board repectively.
Figure 4.5.6.3 and Figure 4.5.6.4 shows the behavior of posting on bulletin boards.
Figure 4.5.7 shows the behavior of search functionality.
Figure 4.5.8 shows the behavior of fetching a file back for future web page development.
Figure 4.5.9 shows the behavior of time stamping.
Figure 4.5.10 shows the behavior of emailing to instructor.
Figure 4.5.11 shows the behavior of modification log.
Figure 4.5.12 shows the behavior of statistical log.
Figure 4.5.13 shows the behavior of the locking functionality.
Figure 4.5.14 shows the behavior of getting online help.
Figure 4.5.15 shows the behavior of browsing web page. This function is fully supported by the browser. Thus we don't have to code it. However, this can be viewed as part of our system.
Figure 4.5.16 shows the behavior of playing an audio or video file. Many formats of video and audio files are fully supported by the browser. We don't add other new video or audio formats, thus we don't have to code this. However, this can be viewed as part of our system.
Figure 4.5.17 shows the behavior of maintaining a menu of hardlink. This is done by the administrator, who is expected to be an UNIX user. She/he will maintain the hardlink by UNIX command. Thus we don't hae to code this.
Fig. 4.6.0 shows enterprise model of the proposed system.
Please refer to Feasibility 3
Please refer to Feasibility 3.3.3, 3.3.4, 4.1
* Authentication-
Except some introductory web pages, all users should first pass the authentication to access the real contents. The authentication will be a form-base web page, in which users type valid username and password pair to login. Authentication automatically identify if the user is an instructor. Later on, if the user is an instructor, she/he can go to the instructor site to modify web pages or access the instructor bulletin board.
This authentication is implemented as a CGI script to validate the username and password pair against UCS authentication. We also keep a file indicating usertype of a certain user. Usertype can be INVALID_USER, STUDENT_USER, or INSTRUCTOR_USER.
* Web authoring (instructors only)-
For instructors (naive web page maintainers/developers), functions for authoring web pages should keep simple, basic and easy. The following functions are chosen:
0) Create a new page.
a) Add a link to a URL on current dummy page.
b) Delete a link to a URL on current dummy page.
c) Add a link to a local page on current dummy page.
d) Delete a link to a local page on current dummy page.
e) Add a link to a local file on current dummy page.
f) Delete a link to a local file on current dummy page.
g) Add image at the cursor position on current dummy page.
h) Delete a chosen image on current dummy page.
i) Insert a character.
j) Delete a character.
k) Delete a string of characters.
The 0) function will be discussed separately in the operations model, others will be discussed together, and called "Web authoring" at operations model. All the opertaions will be implemented by JAVA applet, which is the only way to accomplish this requirement.
* Searching-
Phrase searching can be easily performed by `grep' program, which is a common ultility on UNIX or even PC. This only need a CGI program to handle the interface with `grep'. Please also see `grep' manual page on a UNIX system.
This choice can be easily upgraded to regular expression phrase search, since `grep' program support regular expression search.
Search results can be any pages in the class web site, which is corresponding to file names on the web site.
Search results are displayed as links on the web pages. Users can follow the link to the resulting pages.
The search engine is responsible to find the file (web page) containing the keyword(s) only. User can follow the link to the web page and use the `find' functionality provided by the web browser.
* Email-
Email is just a simple link to email funtionality of web browser. This is easily implemented by HTML.
* Communication (broadcast only)-
We will implement text fields and a submit button for editing messages and submiting it to the bulletin boards. Instructor bulletin board should be on the instructor site, to prevent students from seeing it.
Two bulletin boards are required. One is for the instructors, and the other is for the students. Note that the instructors can act like a students, i.e., instructors can read student bulletin board, but the converse is not true.
* Translation-
All texts in this site should be translated in a translation site, which is not included in this system. Input to this site can be English or French, and output from this site is English translation and French translation.
This can be implemented as a CGI script to handle the input and the output and the format of the translated text.
* Locking mechanism- This is implemented by creating a lock file on the system when receiving a web page modification request. The lock file creation is non-overwrite. Thus if the creation fails, there must be a lock file on the system, and the system will notify the user (instructor) that someone is modifying the web pages (hold the lock), and the user can not modify it util the lock is released. A page update automatically release the lock, by deleting the lock file.
For more details, please refer to SSRD 4, 5, 7 and Feasibility 3.3.1, 3.3.2, 3.4.
Figure 5.4.0 shows the object model of the proposed system. This diagram provides an overview of the system design. For detailed operations, refer to the operations model.
* Overview
In this model, we will first describe the authentication and common scenario, since they are related to everything discuss here, except the superuser. Then, we will introduce some basic scenarios by the scenario diagrams. At last, we will describe how to combine these basic scenarios into more complex practical scenarios. Anything regarding superuser will be discussed at the end of this model.
* Authentication
Except the superuser (operator, administrator, or maintainer), we have two kinds of authentication: authentication of instructor (also called privilege of instructor), authentication of student (also called privilege of student). we will call a holder of authentication of instructor an 'instructor', and call a holder of authentication of student a 'student'. Any one of them will be called a 'user'.
What instructors can do will be described in the basic and the combined scenarios, with the actor `instructor' in the diagram. For other users are similar, with the actor `user' in the diagram. Normally, a real world instructor holds the authentication of instructor and a real world student holds the authentication of student.
* Common Scenario
A user can only login and use this system by first browsing the system URL by a web browser, and then providing the system her/his username and password. This is required to filter out unauthorized persons to use this system. Thus in each of the following figures of scenarios, we can see the first three actions are login(), verifyID(), and openStudentSite(). We call these three actions common scenario. Note that after the first two actions, the program can determine whether the user is an instructor or is a student, as described in enterprise model:authentication. If the user is an instructor, she/he will get the privilege of instructor. Otherwise, the user will get only the privilege of student. Note that an instructor can do everything that a student can do.
* Basic Scenarios
The system have the following basic scenarios:
* Create a new page
* Authoring web pages
* Selecting a web page for web page authoring
* Translation
* Authentication
* bulletin board
- Posting to the student bulletin board
- Selecting stduent messages on instructor bulletin board to read
- Posting to the instructor bulletin board
- Selecting instructor messages on instructor bulletin board to read
* Searching
* Fetching documents
* Time stamping
* Email to instructor
* Modification log
* Locking
* Online help
a. Create new pages:
Fig. 5.5.1. shows a scenario of creating new pages:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The instructor opens instructors site.
- Step 5: The instructor issue a command to request modifying a page.
- Step 6: The instructor site acquire a lock.
- Step 7: Assuming no one is modifying the page, we get the lock.
- Step 8: The instructor issue a command to add a page.
- Step 9: The system create a new dummy web page.
- Step 10: The system update management information of dummy pages.
- Step 11: The instructor feel everything's OK, and want this new updated dummy pages to replace the corresponding pages in the student site.
- Step 12: The system translate the updated pages by the translation site.
- Step 13: Translation site returns the translated pages.
- Step 14: Stamp modification time on first web page.
- Step 15: Add modification log (who/date/time).
- Step 16: The system on the instructor site update the changes to the student site.
- Step 17: Release the lock.
Remark: In step 11, the instructor may want to authoring the dummy page before update the pages. If so, just jump to Step 5 of section b. web page authoring, and follow that scenario.
b. Web page authoring:
This function is to allow instructor to edit web pages easily.
Fig. 5.5.2 shows a scenario of web page authoring:
This scenario is similar to the previous. The only difference is that Step. 8-10 in previous scenario are substituted by Step 8-14 in this scenario.
-- Remark: In Step 12, the edit command can be either of the followings:
a) Add a link to a URL on current dummy page.
b) Delete a link to a URL on current dummy page.
c) Add a link to a local page on current dummy page.
d) Delete a link to a local page on current dummy page.
e) Add a link to a local file on current dummy page.
f) Delete a link to a local file on current dummy page.
g) Add image at the cursor position on current dummy page.
h) Delete a chosen image on current dummy page.
i) Insert a character.
j) Delete a character.
k) Delete a string of characters.
c. Select a web page for web page authoring:
This function is to allow instructor to select a web page as current page to edit it.
Figure 5.5.3 shows a scenario of web page selecting. This scenario is a sub-scenairo of previous senario.
d. Translation:
Fig. 5.5.4 shows a scenario of translation:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The user select a translation (either orignal, English, or French), and the system lead the user the the translated page.
e. Authentication:
Figure shows
Please also refer to the basic scenario described above.
f. Bulletin Board:
f.1. Posting to the student bulletin board:
Fig. 5.5.5.1 shows a scenario of posting messages to the student bulletin board:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The user type some text and submit it (postMessage()).
- Step 5: The bulletin board display the message.
f.2. Select student messages:
Fig. 5.5.5.2 shows a scenario of viewing student bulletin board:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The user select a date to view the messages.
- Step 5: The system display the messages to the user.
f.3. Posting to the instructor bulletin board.
Fig. 5.5.5.3 shows a scenario of creating new pages:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The instructor opens the instructor site.
- Step 5: The instructor type some text and submit it (postMessage()).
- Step 6: The bulletin board display the message.
f.4. Select instructor messages:
Fig. 5.5.5.4 . shows a scenario of viewing instructor bulletin board:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The instructor opens the instructor site.
- Step 5: The instructor select a date to view the messages.
- Step 6: The system display the messages to the instructor.
g. Searching:
Fig. 5.5.6 shows a scenario of searching site pages by keywords:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: Complete the search form and the system will search pages in the student site.
-Step 5: Search on student site.
- Step 6: Students site return the search results.
- Step 7: The user Sees the search result page, and select an item in the search results.
Remark: The user may find that the page is not what she/he want. She/He may search again or push back button on the web browser to go back to the search result page, and select another item in the search results.
h. Fetching documents
Fig. 5.5.7 shows a scenario of viewing instructor bulletin board:
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: The instructor opens the instructor site.
- Step 5: The instructor issue a command to fetch some document file from some ftp site.
- Step 6: The system connect the ftp site and get the file.
- Step 7: The remote ftp site returns the file to the system.
i. Time Stamping
Figure 5.5.8 shows a scenario of time stamping. Refer to scenario a. (Create a page) Step 14, which is almost the same. Thus this leaves nothing to be explained.
j. Email to instructor
Figure 5.5.9 shows a scenario of emailing to instructor. This scenario is easy, and leaves nothing to be explained.
k. Modification log
Figure 5.5.10.1 shows a scenario of updating the modification log.
Please refer to Step 15, in scenario a. (creat a page), which is almost the same to this scenario. Thus this leaves nothing to be explained.Figure 5.5.10.2 shows a scenario of viewing the modification log.
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: User request to view the modification log.
- Step 5,6: Student site get the log from modification log.
- Step 7: Student site display the log.
l. Statistical log
Figure 5.5.11.1 shows a scenario of updating the statistical log.
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: Browse a web page.
- Step 5: system (student site) automatically update the statisticall log.
Figure 5.5.11.2 shows a scenario of viewing the statistical log.
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: User request to view the statistical log.
- Step 5,6: Student site get the log from statistical log.
- Step 7: Student site display the log.
m. Online help
Figure 5.5.12 shows a scenario of online help.
- Step 1, 2, 3: cf. Common Scenario.
- Step 4: User request to get online help.
- Step 5,6: Student site get the online manual from help component.
- Step 7: Student site display the help.
n. Traverse between student site and instructor site
We don't include a diagram for this, since this is simple. Whenever an instructor want to go to student site, just do "open the student site", and if an instructor want to go to the instructor site, just do "open the instructor site"
* Combined Scenarios
For more practical scenarios, a user can combine some basic scenarios into one big scenario, without login again. That is, if a user want to do some combination of basic functions (scenarios), she/he can just login once, and do whatever combination of basic functions she/he wants, as long as she/he has the reqired permission (authentication) for each basic functions she/he does. The combined scenarios will look like the followings:
- Step 1: Basic scenario 1
- Step 2: Basic scenario 2, with common scenario trancated.
- Step 3: Basic scenario 3, with common scenario trancated.
- Step 4: Basic scenario 4, with common scenario trancated.
- Step 5: Basic scenario 5, with common scenario trancated.
....
* Superuser (web maintainer, operator, administrator)
a. functionality
Superuser is the maintainer of the web sites. She/He should have some basic unix knowledge.
b. privilege
All access right to all files in the site.
* This indicate that superuser can do everything that a instructor can do.
c. responsibility
* Editing the enroll list of the students (Normally, the students can only be a user) in a certain format for the system. The format is for a program to determining the enrollment of a student.
* Email the enrolled students to ask them send back an email in a certain format for requesting adding an account.
* Use a program (included in this package) to parse the email, check if the student is in the enroll list. If so, and if the student haven't have an account, the program will add an account for the student.
* Deleting unused files by request of an instructor. cf. Scenarios A.
* Administrate any abuse use of the system, like dumping garbages to the bulletin boards to cause the file system full.
Figure 5.6.1 shows the class inherent digram for design use.
Please refer to OCD 10
