Practicum I:  First Modeling Iteration:  Analysis Modeling and CRC


Due:

Monday, February 10, 2020 by 5:00 pm.  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 here, understand the high level requirements.  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://guide.agilealliance.org/guide/crc.html

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

http://css.dzone.com/articles/crc-cards-primer


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

Taking the requirements analyses you've done (use case model and use cases and story map from Deliverables 1 and 2 above), along with the analysis model you created in Deliverable Three for the particular bounded context you chose, and using techniques for class identification using noun-phrase analysis, produce some Class, Responsibility, Collaboration cards (discussed in class) for the classes that you anticipate will populate your Domain Model in the chosen bounded context.  Your goal here is to begin the process of thinking through the classes that will form the domain models in the bounded contexts.  Think deeply about the vocabulary of the REGIE problem domain in preparing your cards.  You should create as many cards (~ 10-20) as you can think of focusing on the particular bounded context you've identified.

Example CRC Cards for an ATM Machine
Instructions for drawing CRC cards using Visual Paradigm
Scott Ambler on Agile Modeling with CRC Cards
You may find this (simple) online tool helpful for creating CRC cards/formats
Elizabeth Wirfs-Brock 2009 Discussion of CRC Cards
Nice video walk-through on creating 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 Cookbook
JUnit FAQ
JUnit tutorial from Vogella.com
JUnit Tutorial from DZone
O'Reilly's Test Driven Development in Python text
Scott Ambler's Introduction to TDD
Robert Martin's Three Laws of TDD
Example Code from Freeman and Pryce's Growing Object-Oriented Software, Guided by Tests
Wikipedia article on Test Driven Development
TutorialsPoint Tutorial on JUnit

Deliverable Five: Write a proposal for your prototype and deliver it for approval to Professor Shacklette by email.  CC TAs.

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 five 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 10, 2020.  Professor Shacklette will respond quickly as to whether your proposed subset is too broad or too narrow or acceptable.

Deliverables

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