System Specifications for Catalyst

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

System Specifications for Catalyst.gsm.uci.edu

Walt Scacchi
()

GSM271/FEMBA290A
Latest Revision:15:20, 15 October 2000
Fall 2000

This document represents a high-level view of the specifications of the UCI GSM Catalyst system (catalyst.gsm.uci.edu) in terms of the following types of information:

People roles: who uses Catalyst (Role hierarchy)

Processes or workflows: what do they do (Process hierarchy)

Inputs: what information do they put into Catalyst

Outputs: what information can they get out of Catalyst

Relations: who does what with which inputs to realize which outputs

System Components: what are the major software components of Catalyst (Components hierarchy)

This document does NOT specify mid-level or low-level system features or operations. Thus, this is not a complete specification of the current implementation of Catalyst. As such, when examining this system specification, if you identifying any system items of the type below that are missing or misstated, please bring this to the attention of the author of this document.

People (stakeholders, actors, agents/ etc.) roles for Catalyst

Guidelines/Notes:

Identify roles as named objects (in boldface) and organize roles in a hierarchical abstraction.
Provide a brief narrative description of what people do in each role.
Optional: Identify concerns/issues for people in each role.

UCI Graduate School of Management (GSM): UCI GSM provides the overall enterprise setting and workplace associated with the development, use, and evolution of Catalyst. The Dean's Office serves as the Executive that has committed resources to support Catalyst and to encourage its routine usage among the other people at UCI GSM.
MBA students:
Download GSM course content and other GSM event information from Catalyst
Create and upload (Discussion Forum, Course Chat) messages and (personal) biographic information

Concerns:

MBA students are suppose to use Catalyst to download course content, communicate and discuss course content with other MBA students and GSM faculty as a way to learn more about course content
Faculty:
Create content for course(s), then send it to GSM staff for edit and upload into Catalyst
Create content for course(s), then upload it into Catalyst
Download existing content for course(s) from Catalyst, edit it, then upload edited course content back into Catalyst

Concerns:

GSM faculty are encouraged to use Catalyst to create, upload, edit and download content for GSM courses.
Dean's Office:
Promote usage of Catalyst by GSM faculty, MBA students, GSM staff.
Create/edit content guidelines for GSM faculty or students

Concerns:

Fund the development, usage and maintenance of Catalyst at UCI GSM.
Delegate responsibility to manage Catalyst operations to UCI GSM computing and system development staff.
Promote the existence and capabilities of Catalyst to GSM Alumni and business press to bring more recognition, funding, and student applications to UCI GSM.
GSM staff (admin.):
Receive content for courses from GSM faculty (via email, fax or paper), edit if needed, then upload content into Catalyst
Check content for all GSM courses to see if minimum content (a course syllabus) has been entered.

Concern: Assist faculty in getting course content into Catalyst

GSM system development staff:
Develop, operate and maintain the Catalyst system hardware, software and (data) network services Develop, operate and maintain the logical and physical data models and repository that organize, store and retrieve course content as part of Catalyst.

Concerns:

Organize and provide centralized IS support and online content management services for Catalyst users.
Help GSM faculty, students, staff and Dean's office in their use of Catalyst and its components.

Processes or workflows for Catalyst

Guidelines/Notes:

Identify processes/workflows as named objects (in boldface) and organize processes in a hierarchical abstraction.
Provide a brief narrative description of how the process is performed.

Use Catalyst to Manage GSM Course Content: GSM MBA students, faculty, staff (administration) and system development staff to access, browse/download, edit/update content associated with GSM courses.
Create Content, Edit and Upload it into Catalyst: GSM faculty create high-quality course content that they edit/upload into Catalyst for access by students or others at GSM.
Edit, Upload and Check Content for Faculty: GSM staff edit and upload course content that faculty have created and forwarded to them to post in Catalyst.
Download Content for Examination or Review: MBA students, GSM staff, and faculty regularly browse/download content for courses posted in Catalyst. The Dean's Office and System Development staff infrequently download content from Catalyst.
Upload Messages or Chat: MBA students are encouraged to upload/post messages to Discussion Forums or Chat that can be browsed/downloaded by others. Faculty may also upload messages in this same manner.
Develop, Manage, and Maintain Catalyst: The Catalyst System Development staff are responsible for developing, testing, and investigating reports of system anomalies from users of Catalyst at UCI GSM.

Inputs for Catalyst

Guidelines/Notes:

Identify type of Input as named objects (in boldface)
There are many types and kinds of information content managed by Catalyst. I identify those Inputs/Outputs that I have created, used, or seen. Subsequently, as this specification is not complete, then there may be other Inputs/Outputs for Catalyst that are unknown or unfamiliar to me .

Syllabi -- description of the content for a specific course at GSM
Descriptions -- narrative that describes the overall scope and general topics for a course
Events -- items like exams, assigned readings or case studies, other assignments, and the like which are associated with a specific calendar date associated with the quarterly, weekly and daily schedule for a course.
Topics -- narrative items that address subjects likely to be addressed in a class meeting on a scheduled date, perhaps corresponding to a specified event.
Books -- titles, authors, publisher and ISBN number for texts (or reprint collections from the UCI bookstore) that are required or recommended for purchase by students at faculty request.
Web links -- URLs or hyperlinks that point to course related materials specified by a course faculty that are accessed from the Web.
Cases -- case studies entered by faculty (or via admin staff) are generally narrative documents (but might be multi-media files, like a .mov, .avi, or .mpg movie) that are intended to be read/reviewed according to a scheduled course event.
Quizzes -- small, online quizzes with a limited number of questions and answers for selection can be created and administered online through Catalyst. Course exams (e.g., mid-term exams) that require more input from students beyond selection of answers from those provided are generally not administered through Catalyst.
Grades -- faculty for a course can enter grades for students for their coursework. Students can individually access their grades for each course, if available.
Messages -- MBA students and faculty can engage in asynchronous or synchronous communication through Catalyst. Asynchronous messaging is supported through a service called, Discussion Forum. Forum supports the upload, posting, and download/browsing of messages in the order they are received, along message threads. Synchronous messaging is supported through a Chat service based on IRC.
Student personal information -- students can enter and update a designated set of personal information about them (e.g., course enrollments, phone number, URL hyperlinks to personal Web pages) that is managed by Catalyst. Items like personal web pages or work-related web pages are not stored within Catalyst, but can be accessed on the Web via Catalyst.
User navigation commands -- Users navigate through by selecting (e.g., "mouse-clicking") items visible as hyperlinks or pull-down selection menus displayed in client program's user interface.
Developer-only inputs -- Catalyst developers can enter information that create, insert, update or delete schemas or content from the Catalyst Repository, or its internal database. Similarly, they can create, insert, update or delete data entry forms (described in HTML or XML) and data presentation displays (using one or more of Active Server Pages (ASP), HTML, XML, Java, etc.) visible through a client program user interface. Last, developers also input, upload and install application programs (e.g., CGI programs on the Apache Web server, SQL programs on the Repository database management system, and Java applets that are downloaded to a user client on demand). Finally, system developers control the access/upload of digital photograph images of MBA students and faculty.

Outputs for Catalyst

Guidelines/Notes:

Identify types of Output as named objects (in boldface)

All Input items are also available to users as Outputs, though access may be restricted by user role.
Outputs are always formatted and presented in a manner that is consistent with the look-and-feel associated with Catalyst, and its participation in reinforcing the UCI GSM brand.
Client program invocations -- Catalyst can respond to a user input or navigational selection by invoking an application program on the user's computer. For example, Email and JChat are invoked as outputs from Catalyst.

Relations for Catalyst

Guidelines/Notes:

Identify relations as named objects (in boldface) describe which inputs, processes, outputs, roles or system components that are associated by the relation.

Create Content, Edit and Upload it into Catalyst: GSM faculty create high-quality course content that they edit/upload into Catalyst for access by students or others at GSM.
Inputs: Syllabi, descriptions, events, topics, books, Web links, cases, quizzes, grades, Catalyst user navigation commands.
Processes: create content; edit content; upload (and save) content.
Outputs: Catalyst display screens on user client with selected Inputs in view.
Roles: Faculty
Edit, Upload and Check Content for Faculty: GSM staff edit and upload course content that faculty have created and forwarded to them to post in Catalyst.
Inputs: Course content received via email, fax or paper from faculty
Processes: Edit and enter/upload course content into Catalyst; Check to see if faculty have uploaded course content on their own.
Outputs: Catalyst display screens on user client with selected Inputs in view.
Roles: GSM staff (administration).
Download Content for Examination or Review: MBA students, GSM staff, and faculty regularly browse/download content for courses posted in Catalyst. The Dean's Office and System Development staff infrequently download content from Catalyst.
Inputs: User navigation commands (e.g., menu selections visible on user client display). Choice of commands or menu selections is determined by user role (MBAstudents, faculty, staff, etc.)
Processes: Browse and select course content to download, examine/review, iterate or exit.
Outputs: Catalyst display screens on user client with selected Inputs in view.
Roles: All
Upload Messages or Chat: MBA students are encouraged to upload/post messages to Discussion Forums or Chat that can be browsed/downloaded by others. Faculty may also upload messages in this same manner.
Inputs: Narrative text messages uploaded into a Discussion Forum; Narrative text messages uploaded on demand into a Chat session; Upload personal biography information stored in Catalyst.
Processes: select, invoke, and participate in a Discussion Forum with other students or faculty in a course; select, invoke, and participate in a real-time Chat session with other students or faculty in a course.
Outputs: Forum message postings; Chat message postings.
Roles: MBA students (primarily) and faculty (less frequently).
Develop, Manage, and Maintain Catalyst: The Catalyst System Development staff are responsible for developing, testing, and investigating reports of system anomalies from users of Catalyst at UCI GSM.
Inputs: All available
Processes: develop, test, upload and install system code, database schemas (SQL), data entry forms (in HTML/XML), user-selection output/presentation displays (using ASP or HTML), test-data on servers; receive, investigate, and log reports of Catalyst usage anomalies from users;
Outputs: All available
Roles: Catalyst System Developers at GSM.

System Components for Catalyst

Guidelines/Notes:

Identify components as named objects (in boldface) and organize in a hierarchical abstraction.
We will limit our attention here to the main software components of the operational system. Software tools, programs or platforms employed to support ongoing development, testing and maintenance of Catalyst are not included. Furthermore, there exists some hardware configuration that operates the Catalyst server and content repository, but those are unknown to me, at this time. User clients generally operate on a user's PC, laptop, or workstation, whether running at home, work or at UCI.
Optional: a brief description of each component is included.

User Clients

Web browser -- generally Internet Explorer, Version 4.0 or later (there are some known usage bugs at present in using Catalyst with either IE Version 5.0 and 5.5)
Chat -- Catalyst invokes a Internet Relay Chat (IRC) program implemented in Java (operating as an applet) that provides its own window user interface, outside of the Web browser.
Email -- Catalyst allows users to select another known individual user or group identified (e.g., all students registered in a GSM course) to send email. Once selected, Catalyst can invoke the email program registered with the Web browser as the one to launch (invoke) to subsequently send/receive email. Email thus runs as in a separate window (aka, a "control thread"). Catalyst does not directly import or manage user email messages.

Content Server

Apache, an open source web server (available for use on Windows, Unix, Linux, MacOS, and other operating systems on networked computers), replies to requests from a user client for content through Catalyst by accessing a content repository, or by accessing content external to Catalyst via the Web. GSM development staff have custom-coded common gateway interface (CGI) programs that co-operate with Apache to determine whether to access the database manager within the Content Repository. Otherwise, the request goes to the Web for accessing remote Web content (e.g., following a URL hyperlink that displays the ISBN number for a course textbook that in turn retrieves a Web page from amazon.com for the selected book). When Catalyst retrieves content from the Web, it drops its connection to the user client. The user must then go back and refresh/reload the last page served by Catalyst to resume their Catalyst session. If a sufficient delay before refresh occurs, Catalyst times out the connection to the user client, and must then establish a new user session with Catalyst.

Content Repository

This repository encapsulates a SQL database when the primary content for courses and information about MBA students, faculty and staff is kept. An ER data model describes the database schemas that define and logically structure this content. Exceptional or unusual content (e.g., large software application programs used in a class that must be downloaded by students) are not necessarily stored within the database, but instead may be stored on a file server that is visible only to the Catalyst Content Server. Thus the content repository incorporates one/more databases, and one/more file systems (not including the Web or remote networked file servers).