Filter
Top Products
Chapter 3. Black-box thinking: Defining the system context 57
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.