Applications of DBC
From: Daniel Parker (danielaparker_at_spam?nothanks.windupbird.com)
Date: 12/19/03
- Previous message: Michael N. Christoff: "[OT] Re: Phil, in here please."
- Next in thread: Jan Ploski: "Re: Applications of DBC"
- Reply: Jan Ploski: "Re: Applications of DBC"
- Reply: H. S. Lahman: "Re: Applications of DBC"
- Reply: S Perryman: "Re: Applications of DBC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Fri, 19 Dec 2003 00:08:41 -0500
I'm a little new to thinking in terms of DBC, so I'd appreciate any
feedback.
I've tended to rely on unit test cases for validation, but recently there
arose an issue with one of my apps where it appeared that a payment in a
recovery situation had been sent twice. It turned out that this was due to
an error introduced by manual intervention, not the app. But when I was
studying what could have happened, the fact that I had a lot of unit tests
that all passed only suggested that the app was highly reliable, it didn't
rule out the _possibility_ that the problem was due to the app, or mean that
I could go home yet. Reasoning about the app's event model gave more
comfort, because the model suggested that the problem couldn't happen, and
visual inspection of the code seemed to indicate that the code was in
conformance with the model. But then I started to become aware that
conformance really implied that the code satisfy a fair number of
invariants. And it would have been even more comforting to know with
certainty that they had all been satisfied at the time the problem with the
duplicate payment occurred.
Now, suppose I have a method that does something like this (my real world
counterpart is less trivial but analogous)
Start a database transaction
Update a batch header status for a given batch id.
Update the status in the database of all messages in a certain stage of
processing that are associated with the batch
Perform a rollback if any exception is thrown, otherwise commit all the
changes.
Now, suppose I want to introduce some invariants. After the batch header is
updated, the number of rows updated must be one. After the update statement
is performed on the messages, the number of rows updated must equal the
number of messages belonging to the batch.
Now, I could place asserts into the body of the code to inforce these
invariants There are already a fair number of asserts like that strewn
through the code, although in this app these exceptions need to be handled,
the discards logged, users notified, but processing of the next batch
continued.
But adding asserts doesn't sound enough like DBC. Presumably we could start
by breaking up the method into sub methods, and defining contracts for them.
That would add a lot of methods to a service class. I suppose we could
encapsulate the sub method and methods expressing pre and post conditions in
a (Java) inner class. Now the code would start to look a little different
than it would in a procedural model, and I'm not sure that's good or adds to
readability.
I would be interested if somebody who is experienced in DBC could comment on
how they would structure something like this. Everything here is at a level
of granularity that is only accessible within the module, within a
transaction actually, and not outside.
Regards,
Daniel Parker
- Previous message: Michael N. Christoff: "[OT] Re: Phil, in here please."
- Next in thread: Jan Ploski: "Re: Applications of DBC"
- Reply: Jan Ploski: "Re: Applications of DBC"
- Reply: H. S. Lahman: "Re: Applications of DBC"
- Reply: S Perryman: "Re: Applications of DBC"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|