Due:
Monday, February 24, 2020 by 5:00 pm. For delivery see the Deliverables section below.
Purpose:
The purpose of this laboratory is to become comfortable with the
continued use of our requirements and classification techniques as
we turn our focus to writing code. Building on Laboratory I,
the purpose of this practicum is to become comfortable the
exchange that takes place between coding and design. The
design revolves around the requirements for a university course
registration system. This type of system is highly
instructive from a structural modeling standpoint, as there are
several decisions that need to be made as regards inheritance,
aggregation, and various associations between classes. Make
sure you understand the project
requirements.
At this point, you should be thinking through in depth the requirement for Deliverable Six of Practicum I. Practicum II and Practicum III all depend on the focused subset of overall requirements you will 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 and the third practicum are all focused on that solid subset you have chosen.
Strategy:
1. Create a subdirectory called "Practicum2".
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:
Second 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.
Focus on a few of these bounded contexts you have identified in
your High Level Architecture, among the bounded contexts you plan
to delivery in your prototype. Your decision to focus on
one, two, or three or even more bounded contexts will depend on
the contexts themselves and how much "work" you think will be
involved in delivering the implementation for them. Using
tools from your modeling toolbox (Analysis Models, Context Map,
High Level Architecture, CRC Cards, UML Class diagrams, etc.),
clarify your work as you begin to actually write the code for your
classes and the tests to ensure that your code is doing what you
intend. 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.
As you begin your coding, you might want to start coding the
classes for the tests your wrote in Practicum I.
As you begin to write more code, try to do it strategically.
Is there a particular part of the model (a particular bounded
context, for instance) that you think would be "low hanging
fruit"...that is, easy to pull off quickly and easily. Or
you might want to focus on a particular class hierarchy or
aggregate that you think you understand well
(Instructor/TA/Student, e.g.). You might want to start
there. Another approach might be to think of the part of the
model that would yield the most "bang for the buck," that is, that
would move you furthest along in the delivery of your
system. Only you can make these decisions as to where to
start and what to continue.
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).
As for details in your models, I do NOT expect a thoroughly
detailed class diagrams 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.
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
comment your code so that we understand the responsibilities of
the class. 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 Two:
Begin to integrate MySQL into your solution.
Deliverables
The deliverables for each iteration should be placed in the appropriate sub-directory of the pre-existing "practicum2" directory inside your repo. Submit everything using Subversion before the date and time due.
Click here for a General Description of the Problem Domain