Software architecture document
Software Architecture Document
This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.
This Software Architecture Document provides an architectural overview of the C-Registration System. The C-Registration System is being developed by Wylie College to support online course registration.
This Document has been generated directly from the C-Registration Analysis & Design Model implemented in Rose. The majority of the sections have been extracted from the Rose Model using SoDA and the Software Architecture Document template.
See the Glossary .
Applicable references are:
- Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
- Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
- Vision Document of the C-Registration System, WyIT387, V1.0, 1998, Wylie College IT.
- Glossary for the C-Registration System, WyIT406, V2.0, 1999, Wylie College IT.
- Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
- Use Case Spec – Login, WyIT401, V2.0, 1999, Wylie College IT.
- Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
- Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
- Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
- Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
- Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
- Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
- Software Development Plan for the C-Registration System, WyIT418, V1.0, 1999, Wylie College IT.
- E1 Iteration Plan, WyIT420, V1.0, 1999, Wylie College IT.
- Supplementary Specification, WyIT400, V1.0, 1999, Wylie College, IT.
- The existing legacy Course Catalog System at Wylie College must be accessed to retrieve all course information for the current semester. The C-Registration System must support the data formats and DBMS of the legacy Course Catalog System .
- The existing legacy Billing System at Wylie College must be interfaced with to support billing of students. This interface is defined in the Course Billing Interface Specification .
- All student, professor, and Registrar functionality must be available from both local campus PCs and remote PCs with internet dial up connections.
- The C-Registration System must ensure complete protection of data from unauthorized access. All remote accesses are subject to user identification and password control.
- The C-Registration System will be implemented as a client-server system. The client portion resides on PCs and the server portion must operate on the Wylie College UNIX Server. 
- All performance and loading requirements, as stipulated in the Vision Document  and the Supplementary Specification , must be taken into consideration as the architecture is being developed.
This document presents the architecture as a series of views; use case view, logical view, process view and deployment view. There is no separate implementation view described in this document. These are views on an underlying Unified Modeling Language (UML) model developed using Rational Rose.
There are some key requirements and system constraints that have a significant bearing on the architecture. They are:
A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.
The C-Registration use cases are:
- Register for Courses
- Maintain Student Information
- Maintain Professor Information
- Select Courses to Teach
- Submit Grades
- View Report Card
- Close Registration.
These use cases are initiated by the student, professor, or the registrar actors. In addition, interaction with external actors; Course Catalog and Billing System occur.
Diagram Name: Architecturally Significant Use-Cases
Brief Description:This use case allows
a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.
Brief Description:This use case describes how a user logs into the Course Registration System. The actors starting this use case are Student, Professor, and Registrar.
Brief Description:This use case allows the registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system. The actor of this use case is the Registrar.
Brief Description:This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester. The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.
Brief Description:This use case allows a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Billing System is notified of all registration updates. The Course Catalog provides a list of all the course offerings for the current semester. The main actor of this use case is the student. The Course Catalog System is an actor within the use case.
Brief Description:This use case allows a student to view his/her report card for the previously completed semester. The student is the actor of this use case.
Brief Description:This use case allows a professor to submit student grades for one or more classes completed in the previous semester. The actor in this use case is the Professor.
Brief Description:This use case allows the registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system. The actor for this use case is the Registrar.
A description of the logical view of the architecture. Describes the most important classes, their organization in service packages and subsystems, and the organization of these subsystems into layers. Also describes the most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams may be included to illustrate the relationships between architecturally significant classes, subsystems, packages and layers.
The logical view of the course registration system is comprised of the 3 main packages: User Interface, Business Services, and Business Objects.
The User Interface Package contains classes for each of the forms that the actors use to communicate with the System. Boundary classes exist to support login, maintaining of schedules, maintaining of professor info, selecting courses, submitting grades, maintaining student info, closing registration, and viewing report cards.
The Business Services Package contains control classes for interfacing with the billing system, controlling student registration, and managing the student evaluation.
The Business Objects Package includes entity classes for the university artifacts (i.e. course offering, schedule) and boundary classes for the interface with the Course Catalog System.
This application layer has all the boundary classes that represent the application screens that the user sees. This layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier.