Hi,
This is kinda OT, but I'm doing it the context of CSLA objects, so...
My use case is like this. The situation is that a 911 operator receives a 911 call, and needs to dispatch resources to a call location.
The 911 operator communicates with resources over the radio. The resource is identified by a radio number. What's a little tricky is that a radio number is not always assigned to a police officer or fireman. For example, if there are two officers in a car, a message to radio number "101" - the car, is considered a message to both officers. When they get out of the car they'll each have their own radio number.
In addition, radio numbers are not permanently assigned. I may have radio number 101 today and radio number 102 tomorrow, perhaps because I'm patrolling a different area.
All this radio traffic gets typed into the system, and needs to be retrieved for reports later. Reports may be "Radio Traffic by Officer" or "Radio Traffic by Car".
Is there a pattern or some guidance that would help me out?
Thanks,
Mike
Yes, both would be assigned at the beginning of the shift. The officer may tell the dispatcher the radio number, or the dispatcher may assign to the officer, but the dispatcher is the one who inputs it into the system.
Mike
So, if I understand you correctly, one of your objects should have a method that returns a collection of officers associated with a given radio number at a given moment in time. Ditto for the cars associated with a radio number (assuming a group of cars can be associated with a "radio number", much like an emailing list group).
public static OfficerInfoList GetOfficersByRadioNumber
(int radioNumber, SmartDate asOfDateTime)
public static CarInfoList GetCarsByRadioNumber
(int radioNumber, SmartDate asOfDateTime)
or
public static CarInfo GetCarByRadioNumber
(int radioNumber, SmartDate asOfDateTime)
In fact, the above could simply be the standard factory methods for populating a Csla business object collection with the appropriate parameters...
your ER model would have to conform to the following statements of fact:
Entities could be:
Hope that helps!
David,
I just wanted to say thanks for your detailed response. Much appreciated, and it makes sense.
In my head, I'm still digesting, and trying to figure out the classes as well as the DB schema. I'm thinking now that an officer or car "is a" Radio Number rather than "has a" Radio Number.
In the application that I inherited, an officer "has a" Radio Number. I'm not quite sure yet what the end result will be, but I can say that the current design has been brittle, fragile, not to to mention that it plain doesn't work for some clients - meaning that they buy someone else's software.
I have the freedom now to re-create from scratch, so I'd like to do it properly.
Thanks again,
Mike
Michael Hildner:
In my head, I'm still digesting, and trying to figure out the classes as well as the DB schema. I'm thinking now that an officer or car "is a" Radio Number rather than "has a" Radio Number.
Officers are *not* Radio Numbers. They may be a Radio Broadcast Recipient.
More accurately, they are Message Recipients, as there is no need to lock your application design into "Radio" when other communication technologies may supplant it.
Entities:
Vehicle and Vehicle Assignment (and if "Big Operations" are envisioned: Task Force and Task Force Assignment) would be used as a shorthand way to determine what Message Recipients to record.
I have the freedom now to re-create from scratch, so I'd like to do it properly.
A nice feeling, isn't it?
Check out:
The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises
Ready-to-go data models applicable to most industries.
The Data Model Resource Book, Vol. 2: A Library of Data Models for Specific Industries
More specific industries covered here.
Data Model Patterns: Conventions of Thought
Some higher-level, less detailed models applicable to most industries, but also covers the thought processes as to why the model is one one and not another.
The Trial and Death of Socrates: Four Dialogues (Dover Thrift Editions)
The last one displays the Socratic Method for getting to the true nature and meaning of things. Best book on how to actually think thru what you are trying to model I've ever found. The Socratic Method is an "intellectual hot knife thru butter" for understanding your entities/objects true meaning/purpose.
![Smile [:)]](/emoticons/emotion-1.gif)
Wow, that's a lot for me to think about - cool.
I appreciate the responses and the references - I've got some reading to do.
Thanks,
Mike
Ths IS-A test is a dangerous one. Replace the IS-A test with a BEHAVES-AS-A test. Does an officer or car behave as a radio number? I hope not.
Here's where my confusion/curiosity lies, and perhaps Mike can provide the clarification for me. I am trying to look at this from a behavior-based perspective and, to me, the radio number is simply an arbitrary value that is used to reference either a vehicle or an officer. But, to make true sense of this, I think there is another entity that needs to be included: the radio. Afterall, it is the radio that handles the behavior that is being depicted - the messaging.
Do I think that there needs to be a Radio class, not necessarily. Only that the thing that a vehicle and an officer have in common is the radio, the thing that has the number is the radio and the thing handling the communication between the dispatcher and the recipient in the radio. Afterall, in the real world, the reason the call number changes when the officers get out of the car is because they are now being called on their personnal radios instead of the in-car radio.
One other thing to look at, from a behavioral point-of-view, is what the dispatcher is actually doing. If the radio number is an arbitrarily assigned, then it stands to reason that the dispatcher is not making a call based solely on the radio number but is actually using some other basis for calling the selected vehicle or officers. That criteria is probably something like location and availability. The radio number is what the dispatcher uses to identify the recipient when making the call - presumably because this is an open-band radio rather than a direct connection to the selected radio. So, this further emphasizes that the radio number is simply a tag and not a behavioral element.
From all of this, it seems to me that there needs to be some sort of MessageRecipient or RadioOwner base class or interface that exposes the behavior aspects of the model plus a RadioNumber property that can be used by the dispatcher to identify who is being called. Both the Vehicle and Officer classes would inherit from this class or implement the interface. The RadioNumber property would allow the temporary assignment and reassignment of the arbitrary numbers via the set accessor or separate AssignRadioNumber method (there can also be validation to ensure that the assignment is unique and throw an error if the number is being used elsewhere). Additional properties and methods would be defined to handle the messaging aspects including all required logging, such as a Call method. I suggested a base class to encapsulate the functionality, but if an interface works better, I would create a Radio helper class that both objects delegate to that provides the required functionality so that it is encapsulated and abstracted from the Vehicle and Officer classes.
Looking back at the original problem statement, it is clearly stated that it is the calls ByOfficer and ByVehicle that matter. They are not concerned with ByRadio or ByRadioNumber. By selecting the Officer or Vehicle, inheriting RadioOwner (or whatever) from the list, the dispatcher has identified the true object being used in the dispatch.
I hope I've explained that clearly enough. It certainly makes sense in my head. Let me know if not.
Hope that helps.
Afterall, in the real world, the reason the call number changes when the officers get out of the car is because they are now being called on their personnal radios instead of the in-car radio.One other thing to look at, from a behavioral point-of-view, is what the dispatcher is actually doing. If the radio number is an arbitrarily assigned, then it stands to reason that the dispatcher is not making a call based solely on the radio number but is actually using some other basis for calling the selected vehicle or officers. That criteria is probably something like location and availability. The radio number is what the dispatcher uses to identify the recipient when making the call - presumably because this is an open-band radio rather than a direct connection to the selected radio. So, this further emphasizes that the radio number is simply a tag and not a behavioral element.
That's exactly the case. Radio numbers change because of people getting out of the vehicle and are now using their personal radio. Some agencies might use radio number 101 for the Sheriff, 102 for the undersheriff etc., others will assign radio numbers based on the officer's "beat" or patrol area. So whoever is patrolling beat #3 will alwasys have radio number 202.
What makes this difficult for me is that different agencies do different things. One agency may always have the sheriff as 101, whether s/he's in a vehicle or not. Some assign by beat #. An ambulance may always have the same radio number. If 8 guys get out of a fire truck, now you've got 8 radio numbers instead of 1 for the truck.
I'd like to design this system so I can sell to multiple agencies. However the radio number gets assigned, it is, like you said, a tag to identify the recepient. The recepient's tag changes over time, although for some agencies it is infrequent (years) and other agencies it changes on every shift.
Thanks,
Mike
I think you are covered even if 8 guys are getting out of a truck or the numbers rarely change.
Because the RadioNumber is a tag, is can change as often or as infrequently as needed on a record-by-record basis. In other words, you can have the chief with number 101 for a year and the next record correspond to Engine 1 which has its RadioNumber change every day. As long as you build in logic to prevent duplicate numbers - or have the routine reset the previous owner's number to zero or something invalid - you are safe.
As for the 8 guys versus 2 getting out of the truck, etc. The responsibility for reaching the recipient is ultimately on the dispatcher. If all 8 guys have gotten out of the truck and the dispatcher selects the row corresponding to the truck, it doesn't matter what number is assigned, their gonna be calling the truck. If the dispatcher expects to reach FireFighterA and knows he/she is out of the truck, then the dispatcher will have to select FireFighterA's row in the list.
Nice thing about this is that you can take advantage of data-binding in your interface(s), selecting an item from the list corresponds to the concrete Officer/FireFighter/Vehicle so that logging can provide the necessary traceability using that Officer's badge number (or whatever is used).
I think you're covered.
That's exactly the case. Radio numbers change because of people getting out of the vehicle and are now using their personal radio. Some agencies might use radio number 101 for the Sheriff, 102 for the undersheriff etc., others will assign radio numbers based on the officer's "beat" or patrol area. So whoever is patrolling beat #3 will alwasys have radio number 202.
What makes this difficult for me is that different agencies do different things. One agency may always have the sheriff as 101, whether s/he's in a vehicle or not. Some assign by beat #. An ambulance may always have the same radio number. If 8 guys get out of a fire truck, now you've got 8 radio numbers instead of 1 for the truck.
I'd like to design this system so I can sell to multiple agencies. However the radio number gets assigned, it is, like you said, a tag to identify the recepient. The recepient's tag changes over time, although for some agencies it is infrequent (years) and other agencies it changes on every shift.
Thanks Rocky,
Seems a lot simpler now <g> Makes sense to me.
Regards,
Mike
Yes, both would be assigned at the beginning of the shift. The officer may tell the dispatcher the radio number, or the dispatcher may assign to the officer, but the dispatcher is the one who inputs it into the system.
Copyright (c) Marimer LLC