Due:

Tuesday  February 20, 2018 by 5:00 pm.  For delivery see the Deliverables section below.

Purpose:

The purpose of this laboratory is to become comfortable with the continued use of our requirements and classification techniques as we turn our focus to writing code.  Building on Laboratory I, the purpose of this practicum is to become comfortable the exchange that takes place between coding and design.  The design revolves around the requirements for a university course registration system.  This type of system is highly instructive from a structural modeling standpoint, as there are several decisions that need to be made as regards inheritance, aggregation, and various associations between classes.  Make sure you understand the project requirements.

At this point, you should be thinking through in depth the requirement for Deliverable Six of Practicum I.  Practicum II and Practicum III all depend on the focused subset of overall requirements you will have chosen to implement.  Remember, 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 the code for a prototype that represents a solid subset of those requirements, and deliver code and tests for that prototype as your final project deliverable.  This practicum and the third practicum are all focused on that solid subset you have chosen.

Strategy:

1. Create a subdirectory called "Practicum2".

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:  Second Iteration of Requirements Analysis

At this point, you should focus on beginning to realize your design in code for the subset of requirements you plan to deliver for your final project.  Choose to proceed forward doing either a Use Case Model Survey + Essential Use Cases, OR, to move forward with a Story Map + User Stories.  This decision is completely up to you and should be based on whichever requirements analysis discipline you find (a) most helpful and (b) most expressive and (c) with which you feel you are most comfortable.  In this lab, we will refer to either the Use Case Model Survey or the Story Map as your "Summary Survey/Map", and we will refer to your Essential Use Cases or User Stories as "Narratives."  So just remember when you see "Narratives" below, just understand that that can mean either Essential Use Cases or User Stories, whichever you have chosen to continue working with, and when you see "Summary Survey/Map" below, just understand that that can mean either your Use Case Model Survey or the Story Map, whichever you have chosen to continue working with.

Modify your Summary Survey/Map (again, either your Use Case Model or your Story Map) to reflect any changes you have made in your understanding since your first Practicum.  You will continue to do this as you further understand the requirements and your solution that satisfies those requirements.

Additionally, as in the first iteration, you are responsible for delivering five or more new Narratives fleshed out from your Summary Survey/Map.  These will detail user intentions as well as system responsibilities.  As in the first exercise, the verbiage should be a simple, general, abstract, technology-free and implementation-independent description of one task or interaction of the system you envision.  Your Narratives 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 may find the following online resources helpful as you work together to produce these deliverables:

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:  Second iteration of your model, tests, and code (MTC) of your system.

As we have said, developing a solution in code for the entire system as specified in the requirements is not possible.  Update your Context Map (not your Summary Survey/Map) with any new Bounded Contexts have you have identified, if any.

Focus on a few of these bounded contexts you have identified in your High Level Architecture, among the bounded contexts you plan to delivery in your prototype.  Your decision to focus on one, two, or three or even more bounded contexts will depend on the contexts themselves and how much "work" you think will be involved in delivering the implementation for them.  Using tools from your modeling toolbox (Analysis Models, Context Map, High Level Architecture, CRC Cards, UML Class diagrams, etc.), clarify your work as you begin to actually write the code for your classes and the tests to ensure that your code is doing what you intend.  Experiment further trying to write tests prior to actually coding your classes.  Do not feel, however, as if your main deliverables here are models.  Your main deliverables here are code and tests.  However, when you get stuck in coding your classes, do leverage analysis methods and class modeling techniques to help you clarify your thinking.

As you begin your coding, you might want to start coding the classes for the tests your wrote in Practicum I. 

As you begin to write more code, try to do it strategically.  Is there a particular part of the model (a particular bounded context, for instance) that you think would be "low hanging fruit"...that is, easy to pull off quickly and easily.  Or you might want to focus on a particular class hierarchy or aggregate that you think you understand well (Instructor/TA/Student, e.g.).  You might want to start there.  Another approach might be to think of the part of the model that would yield the most "bang for the buck," that is, that would move you furthest along in the delivery of your system.  Only you can make these decisions as to where to start and what to continue.

Remember, your intent (evidenced in your deliverables) should be to demonstrate that you have THOUGHT DEEPLY about the problem and your software solution should be intellectually rich.  Your solution should demonstrate sound object-oriented design principles and patterns.  Your code and design should be S.O.L.I.D.  You will be graded on how well you COMMUNICATE that deep thinking through your models, tests and code (MTC).

As for details in your models, I do NOT expect a thoroughly detailed class diagrams for every class you plan to implement in your prototype.  I certainly don't expect ALL constructors, accessors, modifiers, and arguments for EVERY method for EVERY class.

Having said that, you should make sure you have thought through the problem well enough so that you have all of the salient classes you will need and their supporting classes, and have defined the interface on those classes sufficiently well for a reader of your model to determine from the class diagram what responsibilities are being handled by the class.  You should comment your code so that we understand the responsibilities of the class.  Model adornments such as stereotypes, etc., should be used when necessary to clarify your intent. 

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

http://guide.agilealliance.org/guide/crc.html

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

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

Deliverable Three:  Begin to integrate MySQL into your solution.

Go here and download a copy of MySQL for your system (if you do not already have it installed on your system).  Installation instructions may be found here.  If you are on a Mac, you may find that you also wish to install Sequel Pro, which you can find here and documentation for Sequel Pro can be found here.  A tutorial on using MySQL can be found here.  This assumes that you will be using the MySQL shell from your command prompt.  Those on Macs may prefer to use Sequel Pro. 

As this is not a course in database design, your database design will not be graded.  Try your best to keep things very simple.  There will not be enough data to cause performance problems, so any way you choose to design your database should be "good enough".  Create tables that will support your system, and write a JDBC program (can be stand-alone) that will query data from your database table and return values, similar to JdbcTest.java demonstrated in class and available on the cluster.  Submit your JDBC program as part of your deliverables for Practicum II along with all SQL create/insert/update statements used to create and populate your initial database.

Examples of common queries can be found here.  You may feel free to use any relational mapping frameworks if you are familiar with them (e.g. Hibernate, Spring, etc.).  You may wish to start with MySQL's sample employee database, which can be obtained here.

You may find the following online resources helpful as you work together to produce these deliverables:
TutorialsPoint on MySQL
50 Best Websites to Learn MySQL
MySQL Basics
MySQL Tutorials
Quick Little Tutorial

Deliverables

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