post to see what this is all about and to set the stage.)
I had an enjoyable chat with Kelly last Friday about the problem that
she needs solving. Also present in the interview was Larry, the IT
Manager for the District Attorney's office, who was very interested in
the eXpressApp Framework (XAF) technology I would be using.
Kelly leads a department of 13 staff, of which 6 are Victim Advocates.
Although the department comes under the aegis of the DA's office,
legally it's separate. They are there for the victims of felony
violent crime (for non-US readers, a felony crime is one that will
generally involve jail time if found guilty, whereas a misdemeanor
crime will usually just involve fines and/or community service and
other such), vehicular homicide (that is, a driving accident involving
death, sadly most often also involving alcohol), and domestic violence. They
also deal with victim compensation to aid with medical bills and the
like arising out of the crime, and restitution for victims from convicted
criminals. The Victim Advocates provide victims with information on
the criminal justice system, court case updates, referrals and court
accompaniment, as well as emotional support. Having watched my wife,
who's a Senior Deputy District Attorney, prosecute a couple of nasty
cases involving child victims, I can well attest to the work these Victim Advocates do.
It seems that the DA's office here in El Paso County deals with about 5000 felony cases a
year, and the Victim/Witness Section gets involved in about 2000 of
them. The staff at the DA's office make well over 6000 contacts
(mostly phone calls, but also face-to-face meetings, emails, and
letters) with the victims of these cases, say about 3 contacts per
case. Kelly does note though that the current system that tracks all
this is not 100% reliable so there may be other contacts being made
that are not getting tracked properly. Anyway, it does give us a sense
of the scale of the data input and reporting.
According to the Colorado Victim Rights Act, departments like Kelly's
must log and report on the number of victim contacts made by their associated DA's
office every year. These numbers must be broken down in various
categories, for example by date range, by the type of crime, and so
In chatting with Kelly, I made lots of notes about the goals she
needed to attain, and how the current Access system didn't fulfill
those goals, resulting in extra manual work for the staff in the
department. Back in my office, I made an attempt to work out the
various entities and attributes that my notes exposed. I'm using a
pretty standard methodology to analyze my notes here to build up an
entity model, but one of the things we're seeing already with XAF is
that some developers haven't had the training or experience to
understand how to do this formally. There are several books that describe how to distill an entity model (or a domain model, if you follow the Domain-Driven Deisgn methodology) out of a series of interview notes, and I'll have to write a post that describes those I've used in the past.
If you get the entity model
wrong, it's not the end of the world when using XAF, but it can make things a little more difficult later on. So bear with me as
I describe what I found.
Rereading my notes, I identified several things or entities that I should track in
the new system. The four big ones, if I may call them that, are:
Victim, Defendant, Case, and Contact.
A Case embodies the DA's view of the crime. Although
there can be an awful lot of information related to a Case (such as
police reports, medical reports, motions, evidence lists, and so on,
so forth), for this system we can get away with just a few basic attributes. The most important one is the victim, of course, but Kelly
did note that sometimes there may be more than one victim in a crime, so we'll need to maintain a list of Victims.
Next up is that a Case has a defendant. Again usually there's one such
but sometimes there may be more than one. There is an exception to the
rule here as well: in the very early stages of a case, the crime has
been committed and we know who the victim is, but there may not be a
defendant yet. Maybe the police are still trying to identify one, but
that doesn't mean that the victim won't be contacted. I've already
mentioned in passing that a Case must be of a certain type (say,
Domestic Violence, Vehicular Homicide, etc). There's also a small set
of attributes we'll also need to track as part of a Case: the court
division it's in, the DA in charge (this can change throughout the
life of the Case, but for this system we only need to track the
current DA), the Victim Advocate currently assigned to the case.
Finally we need to track the case number allocated to the case.
A Victim embodies the information about a victim of
the crime. Mostly this is the usual type of information you'd store
about a person: name, address, phone numbers (there may be more than
one), email addresses (ditto). Kelly said she'd like to be able to
store some freeform notes about a victim as well. This is something
I'm a bit leery about -- there have been systems I've worked on where
I was writing reports that selected records based on some values in
the middle of such freeform fields, but at the moment I'll go along
with the request and have asked Kelly to let me know if she's going to
track some particular kind of information that might be better served
as another separate field. The Victim also has a list of Cases,
hopefully only one.
A Defendant is pretty simple (by that I really mean
the Defendant entity in the system is pretty simple; I'm not making a
judgment call on the intelligence of defendants involved in violent
crimes): we need to know the name, maybe some freeform notes, and a
list of Cases. I'd like to add "hopefully only one" here too, but
recidivism is always a problem. Of course, the Victim/Witness Section
aren't going to be contacting the defendant any time soon, but at the
very least they need to know who it is.
Finally, a Contact embodies the information about a
particular contact made by someone in the DAs office (prosecutor,
advocate, paralegal, investigator, etc) to a victim in a case. We need
to know: the Victim, the Case, the person doing the contacting (I'm
calling this the "contactor"), the date and time of the contact, the
type of the contact (email, letter, phone call, etc), and some
freeform notes about the contact.
(We had a little discussion about the "time" part of the contact. It's
not currently tracked at the moment, the contact date being the more
important part of the data. I made the case that, if I made it easy to
enter some kind of time information (for example, not the exact time,
but something like morning, midday, afternoon, evening), it might be
helpful in the future. We'll see: at present it's not an important
part of the Contact entity.)
From these descriptions, I'm sure you can see lots of other smaller
entities that are making themselves known. For example,
PhoneNumber, EmailAddress, and so
on. And I'm sure that you can identify some of their attributes too
(and that some won't have any attributes apart from a name, since
they're essentially enumerations).
Note that, in describing these entities, I'm not describing any behavior for either them or the system as a whole. At the moment, the system is panning out to be a data-driven system rather than a behavior-driven system, but maybe we'll discover some behavior as we proceed through some prototypes.
Next time, we'll start building the business object model.