Fog Creek Software
Discussion Board

Software Design

I was just reading Design By Contract's definition on the Wikipedia ( and I began to think about software design in general. How do you write the specification of an app? When you know exactly what you want it to do, you do you break it down in smaller chunks? How do you implement the formalized rules DBC demands when you're still designing the app?

Thursday, July 8, 2004

It appears (I've never used it before) that DBC would happens somewhere between the formal UML diagrams and the flow/interaction diagrams.

It's not at the point when you're doing early stage development, but once you start deciding how things will actually work together.

Thursday, July 8, 2004

well, i think it is the same as software project management and software development.The fundasmentall ingridient must be leadership and creativity/originality.I doubt whether one can do it alone, you must be a group or else otherwise you loose your head.

Thursday, July 8, 2004


There is an excellent presentation from Eiffel Software about how to use DBC here:

Also, take a look at the Bon-Method as described in "Seamless Object-Oriented Software Architecture."  The book is avaliable for free download.

Bon (Business Object Notation) is a lightweight alternative to UML that is built around DBC.  The Case Studies are very informative.

Finally, code with Eiffel.  In Eiffel the documentation itself is built upon DbC.  You soon grow to appreciate it.

Ged Byrne
Thursday, July 8, 2004


You can start using DbC in the very first stages.  They can start off as plain english and then become more formalised.

For example, if you are designing your log on component you can start at the very beginning with:

User has valid username and password
The system is available

User has access to the system appropriate to their level of access.

No user has access to the system unless they have provided a valid username and password.
No user has access to the system that is inappropriate to their level of access.

Ged Byrne
Thursday, July 8, 2004

The richness of the verifiable aspects of your contracts is mainly governed by the programming system you use. (language, etc.)  The essential ideas are applicable to any programming effort though, regardless of language or tool support.  Java, for example, could use a major overhaul of its libraries and especially its library documentation by somebody skilled in DBC.  Meyer's Eiffel obviously has very strong features for doing design-by-contract -- he's the principal purveyor of the idea.  If you're interested in this, go to the source: Meyer's Object Oriented Software Construction, 2nd edition.

Hell, even if you're not especially compelled by popular descriptions of design-by-contract, that book is required reading for every serious programmer.  It's big.  No, BIG.  But really juicy too.

Thursday, July 8, 2004

OOSC2 changed my life.

Ged Byrne
Thursday, July 8, 2004

Totally agree with Ged about OOSC, but I prefered the first edition to the second. It's a bit more concise...

Jeff Kotula
Thursday, July 8, 2004


Yeah, good point.  It makes sens to base the DbC requirements from your original use cases if you can.

Point taken, thanks.

Thursday, July 8, 2004

I can't pass up a chance to rcommend The Pragmatic Programmer ( ).  It has a nice survey of DBC.

Regarding spec creation, my opinion is that there is an intersect of the domain of specs and DBC, but they are not interchangeable.  Check out Joel's series on writing specs.

Thursday, July 8, 2004

Design by ContractTM (DbC) is a formal way of using comments to incorporate specification information into the code itself. Basically, the code specification is expressed unambiguously using a formal language that describes the code's implicit contracts.

Friday, July 9, 2004

*  Recent Topics

*  Fog Creek Home