3 Details for MPCS 51221
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.).
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.
Due: 5:00 pm, Tuesday, November 14, 2017
Continuation of Design, Code, and Test:
Consider the functional and technical requirements of the
system, and your design of the high level
architecture. Based on the functional
the system and your initial use cases, use stories and current domain model your second requirement for this iteration is some
actual code and tests that implement some portion of your domain
You are to work collaboratively in developing your models,
whiteboarding (and documenting) various design alternatives, finally
delivering an updated high level microservices architecture and
supporting domain models that will represent your
"updated model" and code. Your code base should just now be beginning to take fundamental shape, 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
iterations) individually delivering one additional Use Case and dependent stories fleshed out from the model. These will detail user intentions as well as system
responsibilities. The verbage should be a simple, general,
abstract, technology-free and implementation-independent description of
one task or interaction of the system you envision. In writing your use cases and stories, try your best
to avoid any inherent assumptions about the underlying technology
implementation and the user interface. Your use cases should be based
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.
High Level Architecture and Initial Domain Model:
You will have two weeks to produce this third 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 (to be named by the class as a whole), envision the high level
microservices architecture and domain models.
Deliverable One: Microservices Architecture Blueprint
Leveraging your Context Map and Domain Vision Statement and your first
pass at a high-level architecture, produce a draft of a Microservices
Architecture Blueprint. This is a draft-only drawing of the
Microservices that you envision (at this point in your thinking) in the
final system. This can and should be quite high-level, and
shouild look something like this snippet:
As a team, continue your development of your high level
microservices architecture 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 become formal at this point and
be produced in UML, in something like Visual Paradigm or whatever tool
you've chosen, along with the artifact drafts I've mentioned in class (see below). Your
should continue to include more key components and interactions
as your architecture takes on more form. It should also become
more "realizable". Specifically, your architecture should
now demonstrate your plan for incoroporating microservices and in
particular messaging. You should include technologies that you
enivion will come into play within the different microservices (the technology stacks).
Notice that each microservice has its own datastore, and its own
technology stack. There is nothing wrong with using several
common frameworks and tools within the microservices. Your goal
is neither to produce a polyglot Tower of Babel nor a singular
technology stack reproduced across all microservices, but rather,
choosing the right stack for the right job (ie. microservice as a bounded context implementing a core business capability).
Deliverable Two: Define Your Messages & Services Model
Based on the functional
the system and your developing use cases and stories, use Visual
Paradigm (or whatever you've chosen) and the following artifacts from Lecture 5:
Microservice Architecture Catalog
Service Operation Analysis
Service Operation Decomposition
Technology Stack Decomposition
to follow the API-FIRST principle and describe the central messages that will be passed between
the various services and services and components in your model.
Feel free to modify the five artifacts above to suit your team's needs. They are intended to help you as a team think and communicate about what you are going to build.
Specifically, what messages will be passed from one service to another
asychronously over RabbitMQ? What messages should be passed in a
synchronous fashion, perhaps via RPC/RMI/gRPC or a RESTful
interface? What patterns might you leverage in your communication
(e.g., Request/Reply)? This messaging model does not need to be
complete (or final), but it does need to depict your understanding at
the moment of the services you have identified along with their
and relationships. You are to work collaboratively in producing
this inital model, whiteboarding various design
alternatives, finally documenting the current state of your model
in UML in Visual Paradigm and the above artifacts.
Deliverable Three: Third 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 encounter. Additionally, each member of the team is responsible for (as in the first
and second 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 two 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 begin the serious task of coding some aspect of your solution with this
third iteration. Ask yourself how you wish to approach this
construction activity. Do you want to do a "risk-based" approach
where you code out the riskier parts of the system? Or do you
want to do a "value-first" approach that attempts to deliver the code
that you consider to be the most valuable to the customer (Professor
Shacklette)? 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.
Your approach should be first to determine whether your planning will
be risk-based or value-based. Then, look at your use cases, story
map, and any class models you may have already designed, and decide
which microservices you should focus on and begin to develop with
this iteration. Next, again looking at your use cases, story
map, and developing class models, begin
to design the domain model within one or more microservices. Decide which supporting classes you should
this iteration, and which microservice they belonng to. These
classes may be focused on your user interface, or they may be focused
on some other domain model from some other microservice you've decided
upon. The goal in two weeks is to demonstrate before
the class what your code is doing (an interface, however fledgling, may
be demonstrated, or a messaging microservice). You may also continue to enhance any code that
you developed for the second iteration.
One approach might be to code what "is easiest that you know best at
the moment." This might be the front-end user interface.
For this you might consider runninng an httpd docker conainer and
coding the HTML interface in that microservice. By the time we
have covered RMI, RabbitMQ and MySQL, you will have all the building
blocks (with the exception of MongoDB) necessary to begin produce a
Your new code is not intended to be the final version of any of
the microservices or classes you choose to implement. Feel free to stub out
whatever functionality you don't yet have time for or do not yet understand.
This "code release" is intended to represent an incremental expansion of central classes and supporting classes.
You can find a quick index to UML diagrams here.