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:
JUnit CookbookAlthough 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