Operational Concept Description

Team 16

October 29, 1997

CS 577A

---

Table of contents

1. System Architecture Overview

2. List of Documents

3. Domain Description

4. System Analysis

5. System Design

6. Glossary

 

 

1. System Architecture Overview

Please refer to OCD 1.0

2. List of Documents

Operational Concept Definition
System and Software Requirements Description
System and Software Architecture Definition
Software Development Plan (Life Cycle Plan)
Prototype

3. Domain Description

3.1. Description of Current System

Please refer to OCD 3.

3.2. Change to Current System and Rational

Please refer to OCD 3.2 and 4.

3.3. Stakeholders and Responsibilities

Please refer to OCD 5.2.

3.4. Stakeholder and Operational Entities

Please refer to OCD Attachment 2.

3.5. Activity Model

Please refer to OCD 5.1 and 6.

4. System Analysis

4.1. System Objectives

Please refer to OCD 1.1.

4.2. Product Requirements

Please refer to OCD 5.6, SSRD 6, 8 and Project Plan 2, 5.

4.3. System Requirements

Please refer to OCD 4.1.

4.4. Component Model

Fig. 4.4.1 (class.logical.main.gif) shows the component model of this system, which simply consists of three parts, namely, people, interfaces and sites. People use the interfaces to access the sites. (excluding the superusers, which will be described in operations model)

Fig. 4.4.1

4.5. Behavior Model

This system is basically a teaching/ learning model on the web, consisting of two parts: student site and instructor site. The teaching model is to provide intructors an easy way to distribute class-related material to the stdudents.

Thus basically, student site is just a common web site, with an authentication (Teaching is not free), and the instructor site is an easy-to-use web editor. As everyone can guess, the operational concept is: The instructor(s) edit the student site to add some class-related materials for teaching, while the students browsing the web site for learning.

Specially, this project is concerned a language course. Thus the system should include some kind of translation scheme.

Communication between students and instructors is also necessary. Bulletin boards for both students and instructors are provided to fit this goal.

Fig. 4.5.1 (class.usecase.main.gif) shows the class diagram of behavior model.

Fig 4.5.1

 

4.6. Enterprise Model

* Authentication Model

Fig. 4.6.1 (class.people.gif) shows the authentication model. Authentication mainly takes username and password as parameter and check if it is valid. Also, if it is valid, authentication futher check if the username represents an instructor. This will affect the privilege of using some part of the system (cf. operaions model: authentication). This is related to Taxonomy 1.2 (Authentication).

Fig 4.6.1

* Interface Model

Fig. 4.6.2 (class.interface.gif) shows the interface model, which describe the interfaces of student site and instructor site. The instructor site can be accessed by one user at a time, while the student site can be accessed by many users. This is related to Taxonomy 2.1 to 2.5 (under Capabilities), and 3 (Interface).

Fig 4.6.2

* Site Model

Fig. 4.6.3 (class.site.gif) shows the site model, which describe the sites in this system. Remote Site here refers to remote ftp site. which is correspond to fetching ducoment. Translation site is not a web site. It is mainly for translation, and consists of only a translation program. The input of this site (program) is the text to be translated, and the output of this site (program) is the French translation and the English translation of the original input. This model is related to Taxonomy 2.1 (Authentication), 2.5.4 (Fetch), and 2.2.2.1 (Translation), and is somewhat related to Taxonomy 2 (Capabilities).

Fig 4.6.3

5. System Design

5.1. Product Definition

Please refer to Feasibility 3

5.2. Product Capabilities

Please refer to Feasibility 3.3.3, 3.3.4, 4.1

5.3. System Capabilities

Please refer to SSRD 4, 5, 7 and Feasibility 3.3.1, 3.3.2, 3.4.

5.4. Object Model

The following collaboration diagrams (Fig 5.4.1 to 5.4.9.) describe the details of operations and interactions of objects. These diagrams provide an interaction views of objects and will let the system more understoodable. See operations model for more detailed explanations.

Fig. 5.4.1 Search collaboration diagrams

Fig 5.4.2 Posting message to student bulletin board

Fig 5.4.3. Viewing student bulletin board

 

Fig 5.4.4. Translation

Fig 5.4.5. Web page authoring

Fig 5.4.6. Create a page.

Fig 5.4.7. Posting messages to instructor site.

Fig 5.4.8 Viewing instructor bulletin board

Fig. 5.4.9. Fetch a file.

The following state diagrams (Fig. 5.4.10) describe the state and the transition of between states. We have mentioned that the instructor site can be accessed by one user at a time. This can be done by one of the locking mechanisms under unix.

Fig 5.4.10. State diagram of the system.

 

5.5. 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:

- Searching

- Posting to the student bulletin board

- Selecting stduent messages

- Translating

- Authoring web pages

- Posting to the instructor bulletin board

- Selecting instructor messages

- Fetching documents

 

a. Searching:

Fig. 5.5.1 sequence diagram of search.

Fig. 5.5.1 (seq.search.gif) shows a scenario of searching site pages by keywords:

- Step 1, 2, 3: cf. Common Scenario.

- Step 4: Select search. This leads the user to the search form.

- Step 5: Complete the search form and the system will search pages in the 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.

- Step 8: The user is led to the page she/he want.

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.

Fig. 5.5.2. Sequence diagram of posting messages to the student bullentin board.

b. Posting to the student bulletin board:

Fig. 5.5.2 (seq.post.userbb.gif) 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.

Fig 5.5.3 Sequence diagram of viewing user bulletin board.

c. Select student messages:

Fig. 5.5.3 (seq.view.userbb.gif) 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.

Fig 5.5.4. Sequence diagram of translation.

d. Translation:

Fig. 5.5.4 (seq.trans.gif) 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.

Fig. 5.5.5. Sequence diagram of web page authoring.

e. Web page authoring:

This function is to allow instructor to edit web pages easily.

Fig. 5.5.5 (seq.author.gif) shows a scenario of web page authoring:

- Step 1, 2, 3: cf. Common Scenario.

- Step 4: The instructor opens instructors site.

- Step 5: The instructor select a web page by page number.

- Step 6: The instructor select a edit command to edit the selected web page.

- Step 7: The system on instructor site update the corresponding dummy web page.

- Step 8: The instructor feel everything's OK, and want this newupdated pages to replace the corresponding pages in student site.

- Step 9: The system translate the updated pages by the translation site.

- Step 10: Translation site returns the translated pages.

- Step 11: The system on the instructor site update the changes to the student site.

-- Remark: In Step 6, 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.

Fig. 5.5.6. Sequence diagram of creating a new page.

f. Create new pages:

Fig. 5.5.6 (seq.create.page.gif) 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 create a new dummy web page.

- Step 6: The system create a new dummy web page.

- Step 7: The system update management information of dummy pages.

- Step 8: The instructor feel everything's OK, and want this new updated dummy pages to replace the corresponding pages in the student site.

- Step 9: The system translate the updated pages by the translation site.

- Step 10: Translation site returns the translated pages.

- Step 11: The system on the instructor site update the changes to the student site.

Remark: In step 8, the instructor may want to authoring the dummy page before update the pages. If so, just jump to Step 5 of section e. web page authoring, and follow that scenario.

Fig 5.5.7. Sequence diagram of posting messages to instructor bulletin board.

g. Posting to the instructor bulletin board.

Fig. 5.5.7 (seq.post.instrbb.gif) 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.

Fig. 5.5.8. Sequence diagram of viewing instructor bulletin board.

h. Select instructor messages:

Fig. 5.5.8 (seq.view.instrbb.gif) 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.

Fig 5.5.9 Sequence diagram of fetching document.

i. Fetching documents

Fig. 5.5.9 (seq.fetch.gif) 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.

 

j. 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.

 

5.6. Class Model

The following class model, Fig. 5.6.1, (class.classmodel.gif) shows the class inherent for design use.

Fig 5.6.1 Class Model

6. Glossary

Please refer to OCD 1.0.