Requests: The key to operations
The concept of characterizing all behavior of the system as a series of requests is one of the most difficult for the new MDSD practitioner to grasp, so its purpose and conceptual basis bears a bit more explanation here. When we think about
the idea of a system performing some action, it is tempting to think of this in a vacuum, that is, with no reference to any other element. So the car unlocking is
something that the car does, and that is enough said. This leads us to think of systems as composed of elements each performing some set of functions.
When we model a system in this way, we are tempted to produce something akin to process flow diagrams (or block diagrams) that simply show the order in which functions are performed. What it leaves out, is precisely how these functions are made to perform in sequence, and how the parts of the system collaborate to produce desired behavior. Tacit in these diagrams is some kind of master control flow that causes things to happen. If the master controller is made explicit, and shown as controlling or collaborating with other pieces of the system, fine; but often the controller is implicit in the control flow, and we have found implicit designs or assumptions to be problematical. Systems in reality are not so mysterious. Behavior happens as a result of parts of the system interacting with each other and the world, not through some hidden, unspecified master controller, as some process diagrams imply.
In MDSD, we characterize systems as collections of elements that communicate with each other by, in essence, if not literally, making requests of each other. So instead of describing the unlocking of the car as the action of the driver (unlock the car) and the action of the car (unlock), we describe this behavior as the driver requesting the car to unlock. Sometimes the request is not so easy to determine. If the behavior I am trying to describe is a home owner sending in a mortgage payment, it is tempting to think of this as the homeowner’s action (send mortgage payment). Instead, we ask, what is the homeowner requesting the mortgage company to do here? If we were to read ahead a bit in such a use case, we would find that the next thing that happens is that the mortgage company receives the payment and applies it to the homeowner’s mortgage account.
Instead of describing this as series of actions taken by actors and elements (send, receive, apply) we can describe this behavior as the homeowner requesting the mortgage company to apply their mortgage payment. Apply mortgage payment, when shown as a request the homeowner makes of the mortgage company, is a much more concise and specific description of the behavior. It has the added benefit of speaking directly to a purpose of the system. Systems do not exist to send and receive data. They exist to do things such as applying mortgage payments.
Chapter 3. | 57 |
