SDSM:Index

This document consists of multiple parts; for a directory to all of the parts, see SDSM:Index.

Name

SDS Modernization (SDSM) - Modernization of SMUS School Data System

RETURN

Description

This document describes an active effort running through 2024 to modernize the School Data System (SDS) of St. Michaels University School (SMUS).

RETURN

Audience

The intended audience of this document is individuals who are savvy with electronic computer hardware and software, its use, installation, and maintenance. In particular, it is for individuals that are capable of writing, maintaining, integrating, testing software code, or installing and maintaining deployments of software on internet servers. Or it is for those individuals who directly communicate with or manage such people and technical projects, and have some understanding of technology.

This document is mainly for individuals who would be involved with the SDS Modernization (SDSM) effort, or who would be maintaining SDS afterwards, or who would be managing the people who do these things, or who want to be more informed about how SDS works.

This document is not specifically for those who are just end users of SDS, or for those who make higher level management decisions and are less technically savvy, but they might glean useful information from it. For these kinds of users, other derived or supplementary documentation may be better suited to their needs, or this document can be re-interpreted for them in other forms that better suit them.

RETURN

Overview

School Data System (SDS) is an electronic records management system that empowers a school's fundamental operations by managing the school's records of its students and related data and business processes. This includes tracking students' identities, enrolment, classes, and marks. SDS is used directly by students, their parents, their teachers, and other staff of a school having various roles.

SDS is meant in principle to be usable by any school, but first and foremost to meet the specific needs of St. Michaels University School (SMUS). SMUS is the only school actually using it as of 2024, but SDS may be made available to other schools later. Historically, SDS was also used by Brentwood College School.

SDS has a client-server architecture, hosted on a network as a web server, and used by way of a web client. SDS should be compatible with all modern web clients, including Mozilla FireFox, Google Chrome, Microsoft Edge, and Apple Safari; it should be usable with all modern client devices and operating systems.

SMUS hosts all of its SDS instances, production and testing, on premises on network servers located at its Richmond Road campus. They are not hosted by a third party, whether "cloud" or otherwise.

See https://sds.smus.ca for the production instance.

SDS has 2 alternative versions in April of 2024, older and newer.

The older SDS version (SDS Gavintech), is actively in use in production, and its development is mostly frozen, with minimal updates only.

The newer SDS version (SDS Laravel or SDS API), is not currently used in production, and is incomplete; nearly all current development work is on this version, and it is intended to replace the older version in production once it is sufficiently complete.

The newer SDS version is meant to have essentially the same outward-facing or user-visible feature set, behavior, and appearance as the older version. The newer version also uses essentially the same SQL database schema as the older version, and they actively share a database, which makes for a more seamless migration as the database doesn't have to be "converted". Within these constraints of looking the same to users and having the same database, the new version is almost completely different internally, with a new internal code structure that is a lot more modern.

Each SDS version is written in the PHP programming language and uses a MySQL database. The newer version uses the Laravel PHP application framework, while the older version uses the Gavintech PHP framework. Both versions' production instances are on servers running the Ubuntu operating system and are behind an Apache web server. While Gavintech is essentially abandoned, very non-modern, and bespoke, all of the other named dependencies are actively maintained, modern, and very popular.

RETURN

Structure and Dependencies

SDS itself is a web application written mainly in the PHP programming language (https://www.php.net). Some portions are also written in the JavaScript programming language, though it is intended that these will be replaced with PHP code, mostly if not entirely. Some portions are also written in the MySQL DBMS (https://www.mysql.com) dialect of the SQL programming language, but these are being replaced with PHP code that uses a DBMS abstraction instead of literal SQL.

SDS specifically uses PHP major version 8.1, which was first released for general production use on 2020 Nov 26 (https://www.php.net/ChangeLog-8.php); PHP 8.1 stopped receiving active support by its principal maintainers on 2023 Nov 25, and then for critical security issues it will only be supported by them until 2025 Dec 31 (https://www.php.net/supported-versions.php).

SDS specifically uses MySQL major version 8.0, which was first released for general production use on 2018 Apr 19 (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-11.html); MySQL 8.0 will stop receiving LTS support by its principal maintainers in 2026 April.

SDS can run on a variety of server environments and operating systems, same as PHP and MySQL do. However, its canonical (and also its Canonical) runtime environment is the Ubuntu operating system (https://ubuntu.com), which SMUS runs its production and shared testing deployments in.

Those production SDS deployments specifically use Ubuntu major version 22.04 LTS, which was first released for general production use on 2022 Apr 21; it will stop receiving standard support in 2027 and end of life support in 2032 (https://wiki.ubuntu.com/Releases).

SMUS uses the specific versions of PHP and MySQL that are provided with the Ubuntu version it uses, so the former are only updated when the latter is updated. Most notable is that SDS is constrained to using PHP 8.1 for as long as it is run on Ubuntu 22.04. While their principal maintainers may stop supporting those versions sooner, Ubuntu themselves would continue to provide critical security and bug fixes to MySQL and PHP bundled with their LTS releases, but not new major versions.

SDS Laravel PHP Library Dependencies

Directly Used By Name In PHP Source Files

The PHP source code files of SDS Laravel contain direct references to a variety of third-party PHP classes, most instances of which are parts of the Laravel framework, and some that aren't. Often their fully-qualified names only appear on the form of use statements but other times those names don't appear in use statements and in the main body of PHP code instead.

This SDSM document sub-section enumerates the third-party PHP classes that are directly referenced by name in the SDS Laravel PHP source code, which is the strongest indicator that those classes are actually-used dependencies of it, rather than declared dependencies that are not actually used.

Directly used by name in about 800 app PHP files:

• Illuminate\*
• Auth aka Illuminate\Support\Facades\Auth
• DB aka Illuminate\Support\Facades\DB
• Mail aka Illuminate\Support\Facades\Mail
• Redirect aka Illuminate\Support\Facades\Redirect
• URL aka Illuminate\Support\Facades\URL

Directly used by name in app/Models/File.php and app/Http/Controllers/Admin/Migration/ImportPhotosController.php only:

• Image aka Intervention\Image\ImageServiceProvider

Directly used by name in about 70 app PHP classes:

• Carbon\Carbon
• Carbon\Exceptions\InvalidFormatException

Directly used by name in 10 app PHP classes:

• LdapRecord\*

Directly used by name in 9 app PHP model classes:

• GoldSpecDigital\LaravelEloquentUUID\Database\Eloquent\Uuid

Directly used by name in 5 app PHP classes related to Blackbaud or Bambora:

• GuzzleHttp\Client
• GuzzleHttp\Exception\ClientException
• GuzzleHttp\Exception\GuzzleException

Directly used by name in app/Models/Finance/Bambora.php or app/Http/Controllers/Api/UserProfileController.php only:

• Beanstream\ApiException
• Beanstream\Exception
• Beanstream\Gateway

Directly used by name in 11 php files mostly database/factories/*.php:

• Faker\Generator

Directly used by name in app/Models/User.php only:

• Lab404\Impersonate\*

Directly used by name in app/Providers/AppServiceProvider.php only:

• Dotenv\Dotenv

Directly used by name in app/Models/Pivot/FormCampaignPerson.php only:

• Staudenmeir\EloquentHasManyDeep\HasRelationships

Directly used by name in app/Http/Middleware/TrustProxies.php only:

• Fideloper\Proxy\TrustProxies

Directly used by name in app/Http/Middleware/AuthTimeoutMiddleware.php and app/Http/Kernel.php only:

• JulioMotol\AuthTimeout\Middleware\AuthTimeoutMiddleware

Directly used by name in app/Exceptions/Handler.php only:

• Symfony\Component\HttpFoundation\Response

Directly used by name in config/logging.php only:

• Monolog\Handler\*

Directly used by name in tests/Unit/ExampleTest.php only:

• PHPUnit\Framework\TestCase

Directly referenced by name COMMENTED-OUT in app/Http/Kernel.php only:

• Fruitcake\Cors\HandleCors

Appendices

Proposed Layout of SDSM by Chetan Sondagar

Chetan Sondagar proposed, on 2024 April 10, the following layout for this SDS Modernization (SDSM) document. The actual document layout ended up being different, and the proposal is shown here for posterity. But while the actual document was in development and had substantial missing content, the proposal also served to illustrate what was missing.

1. Introduction
   • System Overview: Brief description of the system, its main components, and its purpose.
   • Purpose and Scope: Clarify the intended use of the documentation and its intended audience.
   • Audience of the Documentation: Specify who the documentation is written for (e.g., developers, system administrators, end-users).
2. System Architecture
   • High-Level Architecture: Overview of the system's architecture, including major components and how they interact.
   • System Components and Interactions: Detailed description of each system component and its role.
   • Network Diagrams: Visual representations of network and system architecture, if applicable.
3. Environment Setup
   • Hardware Requirements: Specifications for necessary hardware.
   • Software Requirements: Required software and versions.
   • Environment Configuration: Instructions for setting up development, testing, and production environments.
   • Client Requirements: Required software and versions.
4. Database Documentation
   • Database Schema: Detailed diagrams and descriptions of database tables, fields, data types, and relations.
   • Data Dictionary: Detailed definitions of all database elements.
   • Entity-Relationship Diagrams: Visual representation of data entities and relationships.
   • Database Performance Metrics: Information on database performance and optimization.
5. Codebase Overview
   • Languages and Frameworks: Information about programming languages and frameworks used.
   • Repository Structure: Description of the code repository structure.
   • Coding Standards and Conventions: Guidelines followed in the codebase.
   • Repository Access: Instructions to access code repository.
6. API Documentation
   • List of Endpoints: Detailed list of API endpoints and their functions.
   • Request/Response Formats: Specifications of request and response formats.
   • Authentication and Authorization: Methods used for API security.
7. User Interface Documentation
   • Screenshots and Descriptions: Visuals and descriptions of key interfaces.
   • User Flow Diagrams: Diagrams showing user navigation through the system.
8. Security Protocols
   • Data Security Measures: Techniques used for securing data.
   • Network Security Configurations: Network security tools and configurations.
9. Installation and Deployment
   • Installation Guide: Step-by-step installation instructions.
   • Deployment Procedures: Process for deploying updates or new releases.
   • CI/CD Practices: Continuous integration and deployment methodologies used.
10. Testing and Quality Assurance
    • Testing Procedures: Overview of testing strategies and methodologies.
    • Test Case Descriptions: Examples of key test cases.
    • Automated Testing Frameworks: Description of automated testing setup.
11. Performance and Optimization
    • System Performance Benchmarks: Key performance indicators and benchmarks.
    • Optimization Strategies: Techniques and practices for optimizing system performance.
12. Backup and Recovery
    • Backup Procedures and Schedules: How and when backups are conducted.
    • Disaster Recovery Plan: Steps and procedures for system recovery in case of a disaster.
13. Access Control
    • User Roles and Permissions: Description of different user roles and their access levels.
    • Access Management Procedures: How user access is managed and controlled.
14. System Integration
    • External System Integration: Details of integration with external systems or services.
    • Data Exchange Protocols: Protocols used for data exchange with external systems.
15. Localization and Internationalization (if applicable)
    • Supported Languages: List of languages the system supports.
    • Cultural Adaptations: Adjustments made for different cultural or regional needs.
16. Scalability and Future Development
    • Scalability Strategies: Plans and techniques for scaling the system.
    • Expansion Plans and Roadmap: Future development plans and system evolution roadmap.
17. Customization and Extensibility
    • Customization Options: Options available for system customization.
    • API Documentation for Extensibility: Documentation for APIs available for extending the system.
18. Operational Best Practices
    • System Maintenance Guidelines: Best practices for maintaining the system.
    • Security Best Practices: Guidelines for maintaining security.
    • Audit Trails and Logging: Information on system logging and audit trails.
19. Feedback and Continuous Improvement
    • Feedback Mechanisms: How users can provide feedback.
    • Improvement Processes: How feedback is incorporated into system improvements.
20. Appendices
    • Glossary of Terms: Definitions of technical terms used.

RETURN

Authors

Primarily written by Darren Duncan.

Includes portions written by or derived from sources written by:

• Chetan Sondagar

RETURN

License and Copyright

Copyright © 2024, St. Michaels University School.

RETURN