Iteration
4 Details for MPCS 51210
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 and email it to John.
Iteration 4
Due: 5:00 pm, Monday, November 14, 2016
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 thrid "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.