Tip:
Highlight text to annotate it
X
Returning to our car rental example. This is the SSD for renting a car from a couple of weeks ago
here's our domain model from last week
and what we want to do is look at the system operations, these operations that are being called on system
start rental, input customer, select dates, select insurance, select vehicle, approve cost
NOT check driver record, charge credit because these are outgoing calls, so not system operations
So it's these ones here we're looking at
So if we choose select vehicle, we want to write a contract for select vehicle
we look at the context of our domain model and say" what should happen in response to selecting a vehicle?"
a vehicle, instance v, was created
so if I'm selecting a vehicle I expect the vehicle I select to be an object
and vehicle v was associated with a vehicle description
and v.rental was set to true, so if a vehicle is available or not is important, so I'm going to say there's a boolean, I imagine
that says whether it's availble or not, and after renting I want to change that variable which implies
that there's a method on vehicle called rented that I can set to true
vehicle, v, was associated with reservation
We see that vehicle office are reserved in a reservation so we have to make that connection
inventory.availableCars was updated so that the inventory knows the car is unavailable
reservation.cost was calculated so we know that there is a cost associated with different types of vehicle
a bill instance was created
and the bill was associated with the contract
so we are seeing which of our
domain concepts should be involved in the interaction responding to an incoming system event like select vehicle
So we are looking inside the black box of system to see which domain concepts are meaningful affected
So let's go one step further
looking at the select vehicle
system operation and we have our contract
looking at the list of things here we know it relates to this portion of our domain model
so let's look at forming an interaction diagram
so I have customer; the actor that's initiating this event. And I'm just looking at select vehicle
obviously this would be much larger for the full system
So slect vehicle is coming in to something, but haven't decided yet
on what should be the controller. I haven't applied the controller pattern yet
so I'll leave that as unknown
I do know that the reservation
and the vehicle have to be associated and the vehicle has to be created. So I have to make a decision about how creates the vehicle
Looking at the creator pattern I have a few choices. Vehicles is reserved in the reservation
and the inventory contains the vehicle
So I'l choose reservation
I'll show how we set it to be rented once it's been reserved
and I'll update the inventory to say it's been removed
this presents a little bit of a problem
Inventory contains vehicles
Yet I have here a message going from vehicle to inventory
that would mean I'm definitely going to have a cyclic relationship here
and I'm going to break another heuristic not yet convered in this course, but it's there all the same
that things in a container should not know about the container
So we have a whole-part relationship here
Whole and part
and the whole necessarily knows about the parts
but we do not want the parts to know about the whole
because this creates a cycle of dependency and we dont like cycles in dependencies
so this create a bit of a problem.
so we can go back to the creator pattern and look at what alternatives we might have
inventory contains vehicle and so is a candidate for creation
so inventory should really do the creation
so now I have reservation calling upon inventory
we'll say select a vehicle from inventory
inventory will create the vehicle, update its list of available vehicles
and it will pass it back
so this is breaking
protected variations, in particular the Law of Demeter -don't talk to strangers.
and it's also produced a high coupling situation
so it's breaching the low coupling pattern
but this is an example of a tradeoff. We have to decide which is the most appropriate approach
the most appropriate class for creating vehicle instances is inventory because they are contained in the inventory
we previously didnt have a relationship between the reservation and inventory, and now there is one. But I maintain the relationship between
reservation and vehicle because that's obviously a meaningful association. So now I have an additional
aspect to it
I will see that reflected in the DCD later on
But now if i think about it
it's probably an association that I missed in my domain model
when I'm creating a reservation
I'm selecting a vehicle from the vehicles that are available
i.e. I'm searching through the inventory, or browsingm or selecting from the inventory a car. So I should have had that relationship already
now I'm saying that the reservation knows the vehicle is rented, so it calls for the vehicle to set its status to rented
and
then continue with the rest of the contract
Get cost because we need to know the vehicle cost for the contract
the contract will create the bill again looking at the domain model and how those relationships should be formed
the last thing I want to do here is look at the front end
so what's the controller here?
my options here are: customer service rep, terminal, reservation, customer
since those are the central concepts
We don't have Rental System as a concept - that's a horrible concept of have in a domain model
So I've chosen here to use Terminal
I might have chosen to use reservation
since that is clearly central to this system
It is a central concept within the domain
But, it's clearly a transient object.
It respresents the transaction involved in a particular reservation
And a Controller has to be a permanent object that can always recieve external system events
So for that reason I've selected Terminal
So hopefully you can see the decisions I've gone through. I've used the Controller pattern, I've used the Expert pattern to determine who
should maintain when a vehicle is rented, what vehicles are available, what the cost of the vehicle is
those are the expert pattern at work
we used the Creator pattern, who should be responsible for creating other objects
and we've seeing the impact that decision can make
So all-in-all we're seeing that our interaction diagram is
filling out based upon our contract that was written for our system operation
and used our domain model
So the next step is to take that interation diagram
to feed that back into our domain model, which will then transition into our design class diagram
and we see here that I've now added the additional association
that didnt exist before between reservation and inventory and you'll note that now I have
navigability on my associations so reservation contains a reference attribute to the inventory, inventory contains reference attributes to the
vehicles it contains. Once it passes that vehicle back to the reservation
once it's been selected the reservationthen has a reference attribute to that vehicle
we can also see reference attributes between the reservation and contract, and contract and bill
And we see some methods added here.So we have select vehicle
as a public method
we see up here that it calls update available vehicle on the inventory, so right now that is a private method
and I see no other reason why anyone else should know about that method, so it's private
we see in this vehicle class rented
get cost
and therefore a rented attribute, a weekly and daily cost attribute. All private to maintain encapsulation
and I've also added this isRented method because I've decided that I've got a boolean
relating to the state of the vehicle and I know that I'll want to interrogate or query that in the future, so
it's good convention to have an isRented method that would
return my current state
Hopefully you can see again the translation between
the calls
so reservation is calling rented on vehicle so vehicle must have the method rented
vehicles is being called get cost, so it must have the method could getCost
contract has vehicle costs so it must have the method vehicleCost
so we see the direct translation between the interaction diagram and the design class diagram
we can see the connection between all the models and diagrams as we progress through analysis and into design
If you have any questions please feel free to contact me