Project: StudentBear Giles | December 10, 2013
I’ve been working on a sample project for the blog that follows a UI-inward approach. The idea is that the REST interface is critical for the front-end developers so I develop the project from the REST service down instead of from the business layer out or persistence layer up. (Obviously this is only pertinent for very small teams. Larger teams can work in parallel.)
The steps are:
- create a “hello, world!” webapp that can be deployed or run in integration tests. It should do nothing but serve a single static page that shows that the webapp is running.
- implement REST service that returns trivial results. Getting an object returns 404, getting a list returns an empty list, etc.
- implement REST client that is used for integration tests.
- implement integration tests that set up test instance and exercise each REST call.
- optionally create a simple dev webapp that calls the REST service. This webapp can be much easier for a backend dev to use than making REST calls directly. There can be analogous webapps that talk directly to the business or persistence layers for the same reason.
- implement business layer stub. We only define the interface required by the REST client and provide the minimal subset of data used in the current REST service stub.
- implement unit tests for business layer.
- replace REST service stubs with calls to (injected) business layer.
- implement persistence layer stub.
- implement unit and integration tests for persistence layer.
- replace business service stubs with calls to (injected) persistence layer.
- implement actual persistence layer.
There are two approaches. The first is breadth-first – all of the REST API is implemented, then all of the business layer stubs, etc. The benefit is that FE devs are free to work on anything but the drawback is that it will take longer to discover unexpected integration problems.
The second approach is depth-first – all of the REST API is implemented but then a single concept is fully implemented. E.g., the REST calls to create, edit, delete or list a “course” is fully implemented even though everything else is stubbed. The benefit is that you’ll discover integration issues quickly but the drawback is that even “simple” concepts can be pretty complex in practice.
The Project: Business Entities
The sample project is a class registration app. The business entities:
Term: Academic term, e.g., “Spring Semester 2014″.
Course: A specific course, e.g., CompSci 101. A course is a timeless entity and there should be no significant differences between Calculus 101 in 1994 and Calculus 101 30 years later. This model breaks down a bit in some fast-moving fields, e.g., CompSci 101 in 1994 looks very different from CompSci 101 in 2014, but even here the overarching concept (Introduction to modern concepts in computer science) will remain unchanged.
Section: A specific instance of a popular course. A specific section can only occur in a single term but a term can have multiple sections of popular courses. In addition a course can have sections in multiple terms. (This model does not consider subsections such as labs, discussion groups, etc.) There is a one-to-many relationship with terms and a many-to-one relationship with courses.
Classroom: A physical room on campus at a specific time that can be used exclusively by a section. For simplicity I assume it will be “Classroom E3-105, MWF, 10-11, Term S14″ instead of explicitly listing every day in the term. There is a many-to-one relationship with terms and a many-to-many relationship with sections with the constraint that a classroom cannot be associated with more than one section. (It’s not a many-to-one relationship with sections though since a section will typically have 2 or 3 classrooms.)
Instructor: A professor or graduate student. Each Section must have at least one instructor. Each instructor can teach zero or more sections. There is a many-to-many relationship with sections.
Student: A student enrolled in a class. There is a many-to-many relationship with sections.
I’m debating whether to model the fact that an instructor is often a student himself (e.g., a graduate student). Graders are not in the model but they’re similar to instructors.
The Project: Business Operations
We can quickly list a number of obvious business operations:
- add term.
- add or edit course. (For historical reasons we never want to delete a course.)
- add or edit a section.
- remove a section. This will impact instructors and students.
- list sections for a course.
- list courses without any sections.
- add or edit a classroom.
- remove a classroom, e.g, due to necessary maintenance. This will impact sections.
- assign or release a classroom to/from a section.
- list classrooms assigned to a section.
- list available classrooms
- assign or release an instructor to/from a section.
- list instructors assigned to a section.
- (with add’l information) list available instructors.
- enroll or drop a student from a section.
- list enrolled students.
The Project: Next Steps
I’ll post articles discussing various aspects of this project. I still plan to (largely) implement it in the order described my blog entries will probably bounce around a bit due to other constraints.