Due:

Monday, February 8, 2021 by 5:00 pm CST.  For delivery see the Deliverables section below.

Purpose:

The purpose of this laboratory is to become comfortable with use case and user story creation, granularity, and high level architectural descriptions including CRC and Analysis Modeling.  Make sure you have understood the project requirements.

Strategy:

1. Create a subdirectory called "Practicum1".

2. Create further subdirectories for each of the Deliverables below.  Note you may need to copy over files (say from your Visual Paradigm directory, or from your Eclipse directory, etc.) into these subdirectories.

Deliverable One:  High Level Architecture

Considering the functional and technical requirements of the REGIE system described in the project requirements, come to an understanding of the high level requirements. Based on your understanding of the overall requirements, prepare a Use Case Model Survey (just ovals and stick figures) depicting the first draft vision of the use cases you believe will be in the system (Register for Class, Drop Class, etc.) and the actors that will be involved (Students, Faculty, etc.). Pick one (1) use case from your Use Case Model Survey and flesh it out in terms of (at a minimum) the Primary Flow of Events. Feel free to add any Alternative Flow of Events or Exceptional Flow of Events as you feel may be necessary. 

Additionally, based on your understanding so far, produce a draft context map of the bounded contexts that you can identify in the system problem space.  This model will be necessarily high level (you don't know enough yet) and will be a rough sketch of your "current conceptual approach towards a strategic architecture".  You can depict this in terms of boxes or non-intersecting circles.  No technologies need be indicated for a bounded context, but if you have some ideas, feel free to put them into the bounded contexts.  The main requirement is for us to see what high-level bounded contexts you have identified.  Remember, your goal here is to communicate your conceptual architecture.   We are looking for bounded contexts you have identified.  Ubiquitous language analysis and domain models will follow.  That said, if you wish to produce a draft of a domain model within a given bounded context, by all means feel free to do so, but you are not (yet) required to do so.

Your goal here is to identify all the bounded contexts in the overall problem domain.  You are not required to identify, at this stage, any necessary relationships between the bounded contexts.  That will come at a later stage of analysis.

You may find the following online resources helpful as you work together to produce these deliverables:

Domain-Driven Design Reference

Domain-Driven Design Quickly

GitHub References Points on Domain-Driven Design

Deliverable Two:  First pass analysis of the domain model within a single bounded context

Focusing on one particular bounded context from your High Level Architecture, you are also to produce a first-draft Analysis Model (AKA a "Robustness" diagram) showing analysis classes you envision in the domain model of that context.  This is a high-level analysis.  A given analysis class (say, a controller) may eventually be realized by two or more actual classes and interfaces.  This is fine.  We are not focusing, at this point, on the concrete classes, but rather, the high-level analysis of the particular chosen domain.  If your analysis classes need to collaborate with analysis classes from another bounded context, this is fine, just show them "outside" the box for the bounded context.

You may find the following online references useful:

http://agilemodeling.com/artifacts/robustnessDiagram.htm

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/robustness-analysis-tutorial/

https://online.visual-paradigm.com/knowledge/robustness-analysis-diagram/what-is-robustness-analysis-diagram/

Deliverable Three: Using your requirements analysis of the domain within a single bounded context, prepare some CRC cards

Deliverable Four: Using your analysis model and CRC cards of the domain within a single bounded context, code some tests

Taking the analysis model you created in Deliverable Three for the particular bounded context you chose along with the CRC cards you developed in Deliverable Four, and using techniques from Test Driven Development discussed in class (and in the resources below), write some tests that will test the eventual functionality of the code within that domain.  Note of course that your actual classes and code for the functionality is not yet developed.  You're writing tests that will fail.  You will likely need to create mock classes or classes that return dummy data in order to run the tests (a class that doesn't exist is problematic in testing).  Reflect on how (and whether) the proactive development of these tests helps form your thinking around the behavior and structure of your code design.

You may find the following online references useful:

Although you are to do requirements analysis for the system as a whole in this first Laboratory as described in the project requirements, your coded project prototype will be a focused subset of these overall requirements.  You will be able to stub out, or mock, whatever services, systems, and classes you have opted not to code out fully.  Leveraging and reflecting upon the outputs from your first four deliverables above, pick out a combination of use cases/stories/domains that you will actually CODE AND DELIVER as your final project.    You are not required to deliver the code for the entire system as specified in the General Description of the Problem Domain here.  Rather, you are to produce a proposal for a prototype that represents a solid subset of those requirements, and deliver code and tests for that prototype as your final project deliverable.  Note that your proposal for your prototype is due to Professor Shacklette by Monday, February 8, 2021.  Professor Shacklette will respond quickly as to whether your proposed subset is too broad or too narrow or acceptable.

The deliverables for each iteration should be placed in the appropriate sub-directory of the pre-existing "practicum1" directory inside your repo. Submit everything using Subversion before the date and time due.

Click here for a General Description of the Problem Domain