Due:

Tuesday  February 6, 2018 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:  First Iteration of Use Case Model, User Story Map

Considering the functional and technical requirements of the REGIE system described here, understand the high level requirements and determine the preliminary landscape of use cases and produce a use case model depicting that landscape using the use case modeling notation in UML.  Based on the functional requirements of the system, and at a high level, what is your system going to need to do?  What activities are your users going to want to accomplish as they use your system? Your model is to be prepared interactively ("whiteboarding/napkining") and formally documented and delivered as a zipped Visual Paradigm (or other, see below**) use case model (Visual Paradigm Community Version can be downloaded here).   This model should show all the use cases you have identified as well as all the actors (again, we are talking about a picture with named circles and named stick figures).

As a general guideline, if you are short of at least 20 use cases, your use case model survey is probably not sufficiently worked out.

Additionally, you are to produce a user story delivery map (aka "story map") that shows the same functionality outlined by the use cases from the model but breaks them out into user stories organized by planned iterations (there will be three more iterations (2 through 4, including the final project deliverable)).  You should lay out your user stories for delivery according to the iterations of the project (iterations 2, 3, and 4).  Examples of User Story Maps are covered during the lectures.

Additionally, you are responsible (in this first iteration) for delivering two Essential Use Cases fleshed out from the use case model, along with dependent user stories.  These will detail user intentions as well as system responsibilities.  The verbiage should be a simple, general, abstract, technology-free and implementation-independent description of each key task or interaction of the system you envision.  Try your best to avoid any inherent assumptions about the underlying technology implementation yet to be designed. This will come in later iterations.  Your use cases should be based on the intentions of a user in a particular context, rather than on the concrete implementation by which the purpose or intention might be carried out.  Your use case description should be both meaningful and descriptive from the point-of-view of users in some role or set of roles as they derive value from a system that will embody the purpose or intentions underlying the user interaction. 

You can find a quick index to UML diagrams here.

**You may use the Community Edition of Visual Paradigm or ArgoUML or OpenModelSphere or Dia to produce your drawings. 

Further Reading and helpful information:

What is an Essential Use Case?

http://www.mountaingoatsoftware.com/agile/user-stories

http://www.agilemodeling.com/artifacts/userStory.htm

http://www.alexandercowan.com/best-agile-user-story/

http://www.ibm.com/developerworks/library/ws-tip-essentialuse/

Cockburn:  Writing Effective Use Cases

Deliverable Two:  High Level Architecture

Based on your use case survey and and story map 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 Three:  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 Four: Using your requirements analysis of the domain within a single bounded context, prepare some CRC cards

Deliverable Five: 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:

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