Due:

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

Purpose:

The purpose of this laboratory is to become comfortable with dynamic modeling as we turn our focus to writing more tests and code in preparation for final delivery of our projects.  Building on Practicums I and II, the purpose of this practicum is to become comfortable with the exchange that takes place between coding and design, particularly as regards messaging between your system's objects.  The design revolves around the requirements for a university course registration system.  This type of system is highly instructive from a structural as well as a dynamic modeling standpoint, as there are several decisions that need to be made as regards inheritance, aggregation, and various associations between classes on the one hand, and processes on the other.  Make sure you understand the project requirements.

At this point, you should be thinking through in depth the focused subset of overall requirements you 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 is all focused on that solid subset you have chosen.

Strategy:

1. Create a subdirectory called "Practicum3".

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

At this point, your focus should be on the realization of your design in code for the subset of requirements you plan to deliver for your final project.  As with the second Practicum, choose to proceed 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 or additions you have made in your understanding since your first and second Practicums.  You should 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 whatever new Narratives fleshed out from your Summary Survey/Map that remain for your prototype.  We will need to see all Narratives that pertain to your prototype subset delivered with your final project.  These will detail user intentions as well as system responsibilities.  As in the first and second exercises, 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:  Third 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.  Revise your detail as necessary.

Focusing on those bounded contexts you have identified in your High Level Architecture that you plan to delivery in your prototype, and using tools from your modeling toolbox (Analysis Models, Context Map, High Level Architecture, CRC Cards, UML Class diagrams, etc.), clarify your work as you continue to write the code for your classes and the tests to ensure that your prototype is doing what you intend.  Continue to 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, and show this work to us in your deliverable.

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).  In particular, begin to think what parts of your system would benefit from a purposeful focus on single responsibility, interface segregation and dependency inversion.

As for details in your models, I do NOT expect a thoroughly detailed class diagram 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.  Communicate whatever you feel needs communicating, so we can all understand what you're doing.

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 make sure processes and other communications and messaging are represented in your model (via sequence diagrams, activity diagrams, etc.)  You should comment your code so that we understand the responsibilities of the class.  Even better you should write code that is so beautiful and clear that comments are unnecessary.  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:

What is an Essential Use Case?

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:  Become comfortable with dynamic modeling

You are to look at the classes you have defined in your class model and code, as well as their relationships, and now turn your focus to fleshing out the operations required on those classes, by concentrating on the messages that will be passed among classes in their collaborations in runtime scenarios.  Define clearly the responsibilities of each class that you have, and decide if further abstraction (i.e., new classes) is necessary (it almost certainly will be). Think about single responsibilities.

To guide you in this endeavor, think through the various collaborations that objects will engage in during run-time, especially the sequence of these communications.  Use UML sequence and (optionally) collaboration diagrams to help your thought process on this.  The activity will be a recursive effort at identifying sequences of interactions and at the same time identifying new operations that will be needed to support the various collaborations.

Think about public versus private interfaces.  Public methods should only appear on your class definitions when you intend those methods to be part of the public interface of your class, that is, part of the interface your client objects will be dependent upon.  Everything else should be non-public.

You will undoubtedly discover that you need new classes (with smaller scope) to facilitate these object-object interactions.  You should begin to think of introducing Interfaces and/or Abstract classes strategically (cf. interface segregation) if you find parts of your code are too dependent on concrete classes (don't go crazy here, but hopefully you will discover some opportunities to make your life easier). You may find it useful to develop helper classes to control the various system activities and object interactions. Of particular use here would be Abstract Factories for object creation.

As you revisit your models and code, think of individual patterns that you have learned that might be applicable in a given context, with a view to simplifying either the static class structure or dynamic interactions among objects.  The design patterns you should have in your arsenal by the delivery date include Singleton, Class and Object Adapters, Template Method, Mediator, Observer, Abstract Factory, Composite, Iterator and State, Proxy, and Visitor.  Not a small arsenal.

You should create several UML sequence, collaboration, state, and activity diagrams which detail your understanding of how the objects based on your current model will interact and collaborate at run-time.  These diagrams should show your interpretation of the dynamic behavior of your model at run-time.

Your grade for this deliverable will be determined on the depth of insight you have brought to the creation of a dynamic representation of your static model.

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

Sparx Systems help on Dynamic Modeling
TutorialsPoint on Dynamic Modeling
Excellent reminder of core concepts in Dynamic Modeling (Youtube)
Good overview on UML diagrams

Deliverable Four:  Continue to integrate MySQL into your solution.

Deliverables

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