Iteration 4 Details for MPCS 51205

Each iteration will deliver an incremental accretion of work toward the final project deliverable.  Generally (see specifics within each Iteration), each student will be responsible for delivering some piece of the work (documentation, code, etc.).

See the syllabus for information on grading.  Turning in Iteration assignments is required.  Submit your assignments as a tarball to the subversion repository according to the directions on the syllabus page.

Iteration 4   Due: 5:00 pm, Tuesday, November 27, 2018

Continuation of Design, Code, and Test:

Consider the functional and technical requirements of the system, and your design of the high level architecture and initial domain model.  Based on the functional requirements of the system and your use cases, user stories and current domain model your requirement for this iteration is more code and tests that implement more of your domain model.  At the conclusion of this iteration, your domain model should be fairly well fleshed out in terms of the model itself.  You are to work collaboratively in developing your code and tests, whiteboarding (and documenting) various design alternatives, continuing to use CRC cards, finally delivering an updated UML class model that will represent your "fourth iteration model" and code.  Your code base should now be beginning to mature, and your tests should be running and verifying that fact.

If there are any Essential Use Cases and stories left undefined, each member of the team is responsible for (like in the first iterations) individually delivering one additional Use Case and dependent stories  fleshed out from the model.  Note that we would expect for additional use cases and stories to be identified with each new iteration, although this is not a requirement.  These will detail user intentions as well as system responsibilities.  As in the previous iterations, the verbage should be a simple, general, abstract, technology-free and implementation-independent description of one task or interaction of the system you envision.  Try your best to avoid any inherent language about the underlying technology implementation and the user interface as you write the use cases and stories (note of course that this is not the same thing as saying you have no idea or plans on what those underlying technolgies might be...we expect you do...nonetheless, you want to avoid that terminology in your description of what the system will do).  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 continue to 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.

High Level Architecture and Domain Model: 

You will have two weeks to produce this fourth iteration.  You are to work together as a team on these deliverables except when you are instructed to individually deliver something.

Considering the functional and technical requirements of the system, revisit your high level architecture and list of candidate classes. 

Deliverable One:  High Level Architecture--Fourth Iteration:

As a team, continue your development of your high level architectural model of your proposed solution.  This model will be a continuation of the "rough sketch" of your "current architectural approach", becoming much more refined during this iteration.  Your depiction should enhance the UML model you produced in the third iteration, preferably in Visual Paradigm.  Your architecture rendition should continue to include more key components and  interactions as your architecture takes on more form. It should also become more "realizable".  We would expect that protocols and technologies (ActiveMQ, RMI, sockets, TCP/IP, SOAP, REST, etc.) would begin to be identified in your model.  In the fourth deliverable below, "Code", you will want to begin integrating whatever additional technologies you wish to include (i.e., such as ActiveMQ, etc.).

Deliverable Two:  Continue to convert your developing List of Candidate Classes and CRC Cards into a Class Design Model in UML

Based on the functional requirements of the system and your developing use cases and stories, enhance Candidate Class List and initial CRC cards with additional classes  you have discovered and expand your domain model depicting the main domain classes, their key attributes, and the relationships between these classes, depicted in several UML Class Diagrams developed in Visual Paradigm.  This class model, like the previous iteration, does not need to be complete (or final), but it does need to depict your understanding at the moment of this fourth (and penultimate) iteration of the classes you've identified, their responsibilities, and relationships.  You are to work collaboratively in producing this inital model, whiteboarding various design alternatives, finally documenting the current state of the class model in UML in Visual Paradigm.  You may find it helpful to begin to break up your Visual Paradigm model into multiple packages, so that different aspects of your architecture are packaged separately (and logically).

Deliverable Three:  Fourth Iteration of Use Case Model, Revised User Story Map & Revised Iteration Plan

Modify your team use case/story models to reflect the planning changes you have encountered.  Additionally, each member of the team is responsible for (as in the first several iterations) individually delivering one new Essential Use Case  fleshed out from the model, along with dependent user stories.  These will detail user intentions as well as system responsibilities.  As in the first three exercises, the verbage should be a simple, general, abstract, technology-free and implementation-independent description of one task or interaction of the system you envision.  Try your best to avoid any inherent assumptions about the underlying technology implementation and the user interface yet to be designed.  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.

Deliverable Four:  Code

You should continue the serious task of coding your solution with this fourth (and penultimate) iteration.  Ask yourself how you wish to approach this construction activity.  Continue whatever risk-based approach you have identified works for you and your team.  You will want to also produce some tests (coded by hand or developed using an existing harness such as junit, etc.) that verify that your code is producing the results you wish (we will discuss Test Driven Development and Tools in a future iteration). 

Continue to look at your use cases, story map, and class models, and decide which of the remaining (and newly identified) classes you should develop with this iteration.  The goal in two weeks is to demonstrate before the class what your code is doing (an interface, however fledgling, may be demonstrated).  You should continue to enhance the code that you developed for the second iteration.

Your new code is not intended to be the final version of any of the classes you choose to implement.  Feel free to stub out whatever functionality you don't yet have time for or understand.  This third "code release" is intended to represent a significant incremental expansion of core and supporting classes.

Deliverable Five:  High Level Dynamic Model

At this point, you should begin to think about the dynamic model of the system, detailing your designs with sequence diagrams, collaboration diagrams, state and activity diagrams in order to describe and document the major dynamic activities of your system.  Pick a couple of major interactions between components and/or classes, and describe those interactions using sequence, collaboration, state and activity diagrams to clarify both your understanding as well as your intent.  For the statechart diagram, you will need to identify a "state machine" in your design.  These should be developed as a group activity and then documented using UML (in a tool such as Visual Paradigm).
You can find a quick index to UML diagrams here.