-
-
- Visitors - a list of people in the visiting group -
- Possible times - a list of time intervals in which the visitors are available on the visit day -
- Day - the calendar day for which the visit has been scheduled with the campus visit office -
- DecidedTime - the time at which the faculty member has agreed to meet for this visit -
- DecidedGuide - the faculty member who has agreed to conduct this visit -
- Status - the current status of this visit: +
- Possible times - a list of time intervals in which the visitors are available on the visit day +
- Day - the calendar day for which the visit has been scheduled with the campus visit office +
- DecidedTime - the time at which the faculty member has agreed to meet for this visit +
- DecidedGuide - the faculty member who has agreed to conduct this visit +
- Status - the current status of this visit:
-
-
- proposed - the visit is known to the department, but no faculty is assigned -
- assigned - a faculty member has agreed to do the visit at a decided time -
- confirmed - the secretary has informed the Campus Visit office of the decidedGuide and decidedTime -
- completed - the decidedGuide has conducted the visit -
- canceled - the visit has been canceled before it could be conducted +
- proposed - the visit is known to the department, but no faculty is assigned +
- assigned - a faculty member has agreed to do the visit at a decided time +
- confirmed - the secretary has informed the Campus Visit office of the decidedGuide and decidedTime +
- completed - the decidedGuide has conducted the visit +
- canceled - the visit has been canceled before it could be conducted
- - Notes - other information pertaining to the visit that would be useful to the decidedGuide +
- Notes - other information pertaining to the visit that would be useful to the decidedGuide
-
-
- Name - actual name -
- Role - the type of visitor: prospective student, parent, or guest (other). -
- Antipicated start semester - the start semester, as reported by the CV office -
- Antipicated majors, minors - desired major(s) and minor(s), from the CV office -
- Type - category (for prospective students only): high school, transfer, or non-traditional -
- Hometown - name of city and state of origin +
- Name - actual name +
- Role - the type of visitor: prospective student, parent, or guest (other). +
- Antipicated start semester - the start semester, as reported by the CV office +
- Antipicated majors, minors - desired major(s) and minor(s), from the CV office +
- Type - category (for prospective students only): high school, transfer, or non-traditional +
- Hometown - name of city and state of origin
-
-
- Level - possible values for involvement are: unknown, cannot, prefer not, can do +
- Level - possible values for involvement are: unknown, cannot, prefer not, can do
Queries
-Unless stated otherwise, these queries can be performed by any user.
+
Queries
+Unless stated otherwise, these queries can be performed by any user.
-
-
- Q1 - List visits. Parameters: startDate, endDate, assignedFaculty, currentStatus (any or all of these can be omitted, and assignedFaculty may be “none” to search for unassigned visits). Result: For each visit matching all of the parameters given: list student name(s), day, possibleTimes, decidedTime, decidedGuide, and status. Sorted by visit day. -
- Q2 - View visit. Parameters: visitID. View all attributes for the given visit, and also the associated committment level for each faculty member in the system. -
- Q3 - View faculty stats. Parameters: startDate, endDate. For each faculty f, list the number of visits v for which v.decidedGuide = f and also the number of visits v for which v.decidedGuide = f and v.status = completed. For both of these sums, the visits are restricted to startDate <= v.day <= endDate. -
- Q4 - List users. Parameters: none. This query is available for admin and coordinator only. For each user u in the system, list u.name, u.roles, u.availableTimes (if u.roles includes faculty), and email. +
- Q1 - List visits. Parameters: startDate, endDate, assignedFaculty, currentStatus (any or all of these can be omitted, and assignedFaculty may be “none” to search for unassigned visits). Result: For each visit matching all of the parameters given: list student name(s), day, possibleTimes, decidedTime, decidedGuide, and status. Sorted by visit day. +
- Q2 - View visit. Parameters: visitID. View all attributes for the given visit, and also the associated committment level for each faculty member in the system. +
- Q3 - View faculty stats. Parameters: startDate, endDate. For each faculty f, list the number of visits v for which v.decidedGuide = f and also the number of visits v for which v.decidedGuide = f and v.status = completed. For both of these sums, the visits are restricted to startDate <= v.day <= endDate. +
- Q4 - List users. Parameters: none. This query is available for admin and coordinator only. For each user u in the system, list u.name, u.roles, u.availableTimes (if u.roles includes faculty), and email.
Events
-There are a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.
+Events
+There are a few problem domain events of interest. For each of these a source is listed, which is how this event is made known to the system.
-
-
- VisitRequest - the Campus Visit office contacts the department secretary with information pertaining to a new campus visit. Parameters: date, possible times, student name, other visitor names, and majors/minors of interest. Source: department secretary keys in the data (coordinator role). -
- ClaimVisit - a faculty member decides to do a visit. Parameters: visit, decidedGuide, decidedTime. Source: faculty member or coordinator. NOTE: If the coordinator claims a visit for a faculty member, then the faculty member must receive a notification (unlike the case where a faculty member claims a visit for himself). -
- ConfirmVisit - the department secretary contacts the Campus Visit office that someone has taken the visit. Parameters: visit’s decidedGuide and decided time. Source: department secretary (coordinator role). -
- CancelVisit - the campus visit office notifies the department secretary that the visit has been cancelled by the student. Parameters: Visit. Source: department secretary (coordinator role). -
- AbaondonVisit - some circumstance has caused the faculty member to vacate the guide position for a visit. Parameters: Visit. Source: faculty member. -
- VisitTimePassed - the decidedTime for the visit plus an hour has passed in Eastern Time. -
- AdjustNotificationFrequency - Parameters: Visit, numberOfDays. Sets the frequency for periodic notifications to the given number of days. Source: department secretary (coordinator role) -
- SetCommittmentLevel - a faculty member sets (or clears) their committment level for a particular visit. Parameters: faculty, visit, level. Source: faculty. Invariant: The committment level must always be “can do” for the assigned guide, if any. -
- EditAvailableTimes - Parameters: faculty, subset of daytime hours for each weekday. Sets the available times for that faculty member. -
- CreateUser - Parameters: name, email, password, roles. -
- EditUser - Parameters: user, plus one or more of: name, email, password, roles. -
- ChangePassword - Parameters: user, password. -
- SetEmailLinkTimeout - Parameters: numberOfDays. Indicates the number of days which email links remain active, after which the link gives an error message. +
- VisitRequest - the Campus Visit office contacts the department secretary with information pertaining to a new campus visit. Parameters: date, possible times, student name, other visitor names, and majors/minors of interest. Source: department secretary keys in the data (coordinator role). +
- ClaimVisit - a faculty member decides to do a visit. Parameters: visit, decidedGuide, decidedTime. Source: faculty member or coordinator. NOTE: If the coordinator claims a visit for a faculty member, then the faculty member must receive a notification (unlike the case where a faculty member claims a visit for himself). +
- ConfirmVisit - the department secretary contacts the Campus Visit office that someone has taken the visit. Parameters: visit’s decidedGuide and decided time. Source: department secretary (coordinator role). +
- CancelVisit - the campus visit office notifies the department secretary that the visit has been cancelled by the student. Parameters: Visit. Source: department secretary (coordinator role). +
- AbaondonVisit - some circumstance has caused the faculty member to vacate the guide position for a visit. Parameters: Visit. Source: faculty member. +
- VisitTimePassed - the decidedTime for the visit plus an hour has passed in Eastern Time; the visit is assumed to be completed. +
- AdjustNotificationFrequency - Parameters: Visit, numberOfDays. Sets the frequency for periodic notifications to the given number of days. Source: department secretary (coordinator role) +
- SetCommittmentLevel - a faculty member sets (or clears) their committment level for a particular visit. Parameters: faculty, visit, level. Source: faculty. Invariant: The committment level must always be “can do” for the assigned guide, if any. +
- EditAvailableTimes - Parameters: faculty, subset of daytime hours for each weekday. Sets the available times for that faculty member. +
- CreateUser - Parameters: name, email, password, roles. +
- EditUser - Parameters: user, plus one or more of: name, email, password, roles. +
- ChangePassword - Parameters: user, password. +
- SetEmailLinkTimeout - Parameters: numberOfDays. Indicates the number of days which email links remain active, after which the link gives an error message.
Notifications
-R1 - The system notifies faculty via email under any of the following circumstances:
+
Notifications
+R1 - The system notifies faculty via email under any of the following circumstances:
-
-
- A new visitRequest is made -
- The faculty member is the decidedGuide for a visit which is scheduled for tomorrow -
- Periodic reminders for faculty members who have an unknown committment level for one or more proposed visits. +
- A new visitRequest is made +
- The faculty member is the decidedGuide for a visit which is scheduled for tomorrow +
- Periodic reminders for faculty members who have an unknown committment level for one or more proposed visits.
R2 - The system notifies coordinators via email under any of the following circumstances:
+R2 - The system notifies coordinators via email under any of the following circumstances:
-
-
- Periodic reminders for visits that are in the proposed state. -
- A time conflict has been detected between two different visits. +
- Periodic reminders for visits that are in the proposed state. +
- A time conflict has been detected between two different visits.
R3 - Both faculty and coordinators are notified if a faculty member has claimed or abandoned a visit (except for a faculty member who changed his own status)
-Platform
-R4 - All users can log into the system as a web app to perform actions suitable to their role(s).
-R5 - Notifications are delivered via email, with embedded unguessable links so that likely actions pertaining to the notification can be performed in one click without logging in.
-User permissions
-Users act in different roles with regard to editing the system’s internal model of campus visits.
+R3 - Both faculty and coordinators are notified if a faculty member has claimed or abandoned a visit (except for a faculty member who changed his own status)
+Platform
+R4 - All users can log into the system as a web app to perform actions suitable to their role(s).
+R5 - Notifications are delivered via email, with embedded unguessable links so that likely actions pertaining to the notification can be performed in one click without logging in.
+User permissions
+Users act in different roles with regard to editing the system’s internal model of campus visits.
Legend:
+
Legend:
✔ = The action is allowed by this user role.
✔* = The action can be performed by the coordinator, acting on behalf of a faculty member.
✔+ = The admin can change any user’s password (other users can only change their own).
Security
-R6 - The web app portal is password-protected and served over HTTPS, exclusively.
-R7 - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.
-Preferences
-Unnecessary email should be minimized. Within notification frequency, it would be preferable to have a single email containing notifications for all relevant visits rather than receiving a separate email for each notification.
-Likely changes
-Rules guiding notification frequency are likely to change. The coordinator has limited control over this, but experience with the system will help to understand how to best give the coordinator more granular control.
+Security
+R6 - The web app portal is password-protected and served over HTTPS, exclusively.
+R7 - Embedded email links pertaining to user actions are long, unguessable strings which expire after a certain number of days (which can be set by an admin). Following an expired link shows an error message.
+Preferences
+Unnecessary email should be minimized. Within notification frequency, it would be preferable to have a single email containing notifications for all relevant visits rather than receiving a separate email for each notification.
+Likely changes
+Rules guiding notification frequency are likely to change. The coordinator has limited control over this, but experience with the system will help to understand how to best give the coordinator more granular control.
\ No newline at end of file diff --git a/Day 20 (UI specification)/Campus visits.html b/Day 20 (UI specification)/Campus visits.html new file mode 100644 index 0000000..34a5dc4 --- /dev/null +++ b/Day 20 (UI specification)/Campus visits.html @@ -0,0 +1,42 @@ +Campus visit user interface specification
+Prepared by: Michael Kowalczyk
+Revision date: 10/3/2024
Overview
+A prototype for the software is available, and there is only one developer on this project, so this document will only go into detail on those aspects that are unclear or unspecified in the prototype.
+The system will be deployed as a web app with a dedicated email address for sending notifications. Users can sign in directly or use links from emails to perform certain actions without logging in.
+Event responses
+Event responses are simple: most of the events in this system are concerned with bringing the internal data model up to date with what is going on in the problem domain. This is true for VisitRequest, ClaimVisit, ConfirmVisit, CancelVisit, AbaondonVisit, VisitTimePassed, SetCommittmentLevel, EditAvailableTimes, CreateUser, EditUser, and ChangePassword.
+Internally, the system is going to model Visits, Users, and User Committments in a similar way as described in the requirements document. The main difference is that internally, the software will keep visitor data as part of the visit itself. There is little practical need to separate these, as repeat visits with the same visitor are rare; having both stored together simplifies the program and only costs a few extra keystrokes for the coordinator on rare occasions. Also, many of the attributes can be folded together. The result is indicated in the following internal data model.
+
AdjustNotificationFrequency and
+SetEmailLinkTimeout are administrative tasks with simple internal representations.
Screens
+In general, the screens should behave as in a standard single-page web app: hitting the tab key should cycle through interactable user interface elements in top-to-bottom order and the browser back/forward buttons are deactivated.
+Login
+/clickable%20prototype/pages/login.png "Login screen")
The login screen should display an error message on failed login, and should also provide the option to do password reset by email.
+User
+/clickable%20prototype/pages/users.png "Users screen")
Tab order on this screen is left-to-right per row. The New user button creates a new row with all blanks. A name and email must be provided before hitting “Save changes”. Otherwise, a modal dialog will point out the omission. If a password is left blank for a user, then they aren’t able to log into the system but can still use email links. Only faculty have editable/viewable availability. It is possible to have a user with no roles. Trying to close the browser or switch to the visits tab before saving will issue a warning about changes being lost (ok / cancel).
+Visits
+/clickable%20prototype/pages/visits.png "Visits screen")
Proposed visits are highlighted in red on the faculty screen. Proposed and assigned visits are highlighted in red on the coordinator screen (because the visit must still be confirmed with the Campus Visit office). Any edit to the filter criteria immediately updates the list. Results can be sorted increasing or decreasing by clicking on columns: visit number, date, student, times, guide, or status.
+Email click confirmation screens
+/clickable%20prototype/pages/confirmnonvolunteer.png "Confirm volunteer screen")
The prototype doesn’t show it, but the message should imply what choice was recorded, i.e. You have choosen "I am able to do it, but I'm not volunteering (yet). If you change your mind, you can select a different email link or log in to volunteer for this visit".
Shared states
+There are no shared states or files with other software systems.
+File formats
+No files are held in common with other systems or with the user. Internally used file formats and/or database tables will be commented on in the architectural design stage.
+New protocols
+No unique protocols will be necessary.
+Administrative tasks
+See requirements document.
+Operating procedures
+It is required that all users of the system check their email frequently (at least once every day or two) and respond to campus visit requests promptly. Meeting the expectation of a quick turnaround time on campus visits relies crucially on this.
+Installation procedures
+This section will be deferred to the architectural design stage, since it relies on decisions not made yet.
+Preferences
+The system may be simple enough that keyboard shortcuts would have little use. The plan is to develop the first version of this software and let users determine if such functionality would be useful enough to add subsequently.
+ \ No newline at end of file diff --git a/Day 20 (UI specification)/User Interface Specification.md b/Day 20 (UI specification)/User Interface Specification.md new file mode 100644 index 0000000..68ec277 --- /dev/null +++ b/Day 20 (UI specification)/User Interface Specification.md @@ -0,0 +1,79 @@ + +# Campus visit user interface specification + +Prepared by: Michael Kowalczyk +Revision date: 10/3/2024 + +## Overview + +A [prototype for the software is available](<../Day 13-14 (prototyping)/clickable prototype/index.html> "Clickable prototype"), and there is only one developer on this project, so this document will only go into detail on those aspects that are unclear or unspecified in the prototype. + +The system will be deployed as a web app with a dedicated email address for sending notifications. Users can sign in directly or use links from emails to perform certain actions without logging in. + +[In larger projects, explain here how each requirement is met.]:: + +## Event responses + +Event responses are simple: most of the events in this system are concerned with bringing the internal data model up to date with what is going on in the problem domain. This is true for VisitRequest, ClaimVisit, ConfirmVisit, CancelVisit, AbaondonVisit, VisitTimePassed, SetCommittmentLevel, EditAvailableTimes, CreateUser, EditUser, and ChangePassword. + +Internally, the system is going to model Visits, Users, and User Committments in a similar way as described in the requirements document. The main difference is that internally, the software will keep visitor data as part of the visit itself. There is little practical need to separate these, as repeat visits with the same visitor are rare; having both stored together simplifies the program and only costs a few extra keystrokes for the coordinator on rare occasions. Also, many of the attributes can be folded together. The result is indicated in the following internal data model. + + + +AdjustNotificationFrequency and SetEmailLinkTimeout are administrative tasks with simple internal representations. + +## Screens + +In general, the screens should behave as in a standard single-page web app: hitting the tab key should cycle through interactable user interface elements in top-to-bottom order and the browser back/forward buttons are deactivated. + +### Login + +/clickable prototype/pages/login.png> "Login screen") + +The login screen should display an error message on failed login, and should also provide the option to do password reset by email. + +### User + +/clickable prototype/pages/users.png> "Users screen") + +Tab order on this screen is left-to-right per row. The *New user* button creates a new row with all blanks. A name and email must be provided before hitting "Save changes". Otherwise, a modal dialog will point out the omission. If a password is left blank for a user, then they aren't able to log into the system but can still use email links. Only faculty have editable/viewable availability. It is possible to have a user with no roles. Trying to close the browser or switch to the visits tab before saving will issue a warning about changes being lost (ok / cancel). + +### Visits + +/clickable prototype/pages/visits.png> "Visits screen") + +Proposed visits are highlighted in red on the faculty screen. Proposed and assigned visits are highlighted in red on the coordinator screen (because the visit must still be confirmed with the Campus Visit office). Any edit to the filter criteria immediately updates the list. Results can be sorted increasing or decreasing by clicking on columns: visit number, date, student, times, guide, or status. + +### Email click confirmation screens + +/clickable prototype/pages/confirmnonvolunteer.png> "Confirm volunteer screen") + +The prototype doesn't show it, but the message should imply what choice was recorded, i.e. `You have choosen "I am able to do it, but I'm not volunteering (yet). If you change your mind, you can select a different email link or log in to volunteer for this visit"`. + +## Shared states + +There are no shared states or files with other software systems. + +## File formats + +No files are held in common with other systems or with the user. Internally used file formats and/or database tables will be commented on in the architectural design stage. + +## New protocols + +No unique protocols will be necessary. + +## Administrative tasks + +See requirements document. + +## Operating procedures + +It is required that all users of the system check their email frequently (at least once every day or two) and respond to campus visit requests promptly. Meeting the expectation of a quick turnaround time on campus visits relies crucially on this. + +## Installation procedures + +This section will be deferred to the architectural design stage, since it relies on decisions not made yet. + +## Preferences + +The system may be simple enough that keyboard shortcuts would have little use. The plan is to develop the first version of this software and let users determine if such functionality would be useful enough to add subsequently. diff --git a/Day 20 (UI specification)/dataModel.png b/Day 20 (UI specification)/dataModel.png new file mode 100644 index 0000000..7fc9ec7 Binary files /dev/null and b/Day 20 (UI specification)/dataModel.png differ diff --git a/Day 20 (UI specification)/dataModel.puml b/Day 20 (UI specification)/dataModel.puml new file mode 100644 index 0000000..1b83edf --- /dev/null +++ b/Day 20 (UI specification)/dataModel.puml @@ -0,0 +1,37 @@ +'Created with https://www.planttext.com/ + +@startuml + +skin rose + +title Internal data model + +class User { + name + email + password + roles + availableTimes +} + +class Visit { + studentInfo + otherVisitors + hometown + day + possibleTimes + decidedTime + status + notes + notificationFrequency +} + +class Committment { + level +} + +Visit "*\ndecided guide →" -right- "0..1\n← visits" User : " " +Visit " 1" -up- "*" Committment +User "1" -up- "*" Committment + +@enduml diff --git a/Day 21 (lifecycle models)/notes.md b/Day 21 (lifecycle models)/notes.md index f71adc3..7bf2989 100644 --- a/Day 21 (lifecycle models)/notes.md +++ b/Day 21 (lifecycle models)/notes.md @@ -15,7 +15,7 @@ In iterative development one iterates through the whole process (requirements Spiral is a type of incremental and iterative development where risk assessment occurs at the start of each cycle. ## Agile -Agile is a form of incremental and iterative development with emphasis on frequent face-to-face communication, high customer visibility, adaptability to change, and minimizing non-software work products. +Agile is a form of incremental and iterative development with emphasis on frequent face-to-face communication, high customer visibility, adaptability to change, and minimizing non-software work products. For example, Extreme Programming (XP) is an agile methodology based on the principles of communication, simplicity, feedback, courage, and respect. ## Evolutionary In an evolutionary model, deliverables are given to the customer frequently and incrementally. The focus is on high-value features first and getting customer feedback early and often. diff --git a/Day 22-23 (architecture)/Programming language selection.txt b/Day 22-23 (architecture)/Programming language selection.txt new file mode 100644 index 0000000..ccd6593 --- /dev/null +++ b/Day 22-23 (architecture)/Programming language selection.txt @@ -0,0 +1,16 @@ + +Using a familiar programming language leads to significant productivity increases over an unfamiliar language. + +Using a high-level programming language leads to huge (many factor) productivity increases over low level languages, both in terms of development speed and lines of code (table copied from "Code Complete 2", by Steve McConnell). + +Language Program size compared to C +-------- -------------------------- +C 1.00 +Fortran 95 0.50 +C++ 0.40 +Visual Basic 0.22 +Java 0.17 +Python 0.17 +Smalltalk 0.17 + +Main takeaways: Know your tools. Using the right tool for the right job is a great benefit, and this is true for libraries as well. Among relatively equal choices, it is may be best to go with what is familiar. diff --git a/Day 22-23 (architecture)/SystemArchitecture.md b/Day 22-23 (architecture)/SystemArchitecture.md new file mode 100644 index 0000000..14769aa --- /dev/null +++ b/Day 22-23 (architecture)/SystemArchitecture.md @@ -0,0 +1,42 @@ + +# Campus visit system architecture + +## Technology selection + +### Client side: Vue, HTML, CSS, TypeScript + +The client-side application is envisioned as a single-page web app, which will run in Vue 3. The two main alternatives (Angular and React) were ruled out because of lack of developer familiarity with these. The complexity of this application rules out JQuery; it will take much less code to develop in Vue. + +According to some cursory research, TypeScsript is much better suited over JavaScript when developing in Vue 3, and should only take a few hours to learn, given familiarity with JavaScript. Of course, HTML and CSS go with the territory. + +### Server side: Node.js, Express, SQLite + +Speed and developer familiarity were the main rationale for selecting Node.js and Express. Website files and AJAX requests can both be handled fine with these technologies. + +For a database engine, SQLite was compared with MySQL, as both are free. According to the SQLite documentation, it should be able to handle upwards of 100,000 hits per day for a web application. The main speed limitation in SQLite is with write transactions (especially concurrent ones), but given the small number of users (no more than a dozen) and infrequent requests (estimated at less than 100 per day), SQLite would be well within performance bounds and will probably outperform MySQL due to its simpler structure. It is also expected to be simpler to configure and deploy. Thus, SQLite was chosen over MySQL. + +#### Backups + +SQLite works based on a single database file, so it will be straightforward to schedule automatic backups. For simplicity of deployment, the plan is to implement this in the Node.js server script itself. + +### Client-server data communication: JSON over AJAX + +JSON will be used for client-server data communication (e.g. visit and user data). It is standard and integrates easily between Node/Express and client-side JavaScript. AJAX is choosen as a default over WebSockets because server pushes are not strictly necessary. For example, although it would be nice for a faculty committment to appear immediately on the coordinator's screen, it may not be worth the extra development time and email already serves this purpose. + +## Feasibility + +## File formats + +## Major database tables + +## Performance + +## Scalability + +## Internationalization + +## Security + +## Error processing + +## Fault tolerance