Due:
Monday, March 9, 2020 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 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.
Add a couple of dynamic model artifacts to your third
deliverable. This could be in the form of a few sequence
diagrams or activity diagrams or state diagrams. Just a
couple will do. We want you to have some experience with
dynamically modeling in addition to all your class diagrams you've
been working on. Remember, dynamic models focus on collaborating
objects at runtime.
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
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.
Click here for a General Description of the Problem Domain