Talk:Precondition
![]() | This article is rated Stub-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||
|
How do Preconditions differ from Prerequisites?
Security problems can arise due to incorrect preconditions - e.g. a section of code that has the precondition that the input is correct, when it may not be.
This isn't really an example; it doesn't make it any clearer to me what kind of security problems may arise. Also, "the precondition that the input is correct" is sort of redundant. Galaxiaad 01:10, 14 Dec 2004 (UTC)
Merge?
[edit]Would it make sense to merge postcondition and precondition? --Abdull 13:01, 2 August 2006 (UTC)
Preconditions: Necessity and Sufficiency
[edit]Uncharacteristically, for a mathematician of Meyer's rigour, the treatment of pre-conditions in Chapter 11 of Object Oriented Software Construction omits an essential analysis and design element: sufficiency. The present article states,
If a precondition is violated, the effect of the section of code becomes undefined and thus may or may not carry out its intended work.
While true, the statement draws attention away from a more subtle occurrence. While obviously violation of any pre-condition in a given list is sufficient to guarantee (not 'may' or 'may not') that the code guarded by the pre-conditions will not work, (after all, they are 'necessary' conditions), what will happen when the pre-condition specification is insufficient due to the non-presence of other necessary conditions? Should these unstated conditions be satisfied for a given execution thread, all will be well and the user "rewarded" with the post-conditions, the contract having been satisfied. However, should one or more of the unstated pre-conditions be violated, the post-conditions will not be achieved. Worse, debugging will be complicated by the need to discover these unstated assumptions by the eventual identification of some kind of internal inconsistency in the values of code variables.
The unfortunate choice of the word require to delimit pre-condition clauses in Eiffel suggests that an incomplete set of necessary conditions will suffice to ensure the success of the desired outcome. But as the author states, pre-conditions are the caller's portion of the contract which, if satisfied, are rewarded with the post-conditions. What this clearly implies is that the pre-conditions must be complete, that is, sufficient to ensure the code completes successfully.
Insufficiency is a common fallacy, especially pernicious in the everyday application of Jacobson's method of use cases. Pre- and post-conditions are standard parts of use case templates, but both are more often honoured in the breach than their observance. I've never heard of a use case training class that makes this point explicitly, and supplies students with exercises to practice it. Yet, it should be manifestly clear that all necessary conditions must be found and stated for the desired state of happiness to be achieved. This all means 'everything necessary, but nothing further: nothing unnecessary'; only then can the contract's guarantee be expected.
Do not dismiss this as an idle splitting of hairs, because it suddenly imposes a far higher degree of formality on the requirements specification, and the consequent application of additional diligence for the full identification of requirements. Now, the requirements analyst must not get the specification merely 'right', but she must also make it 'complete', and provably so. With practice, designers become accustomed to such diligence but, for those not accustomed to formal methods of analysis and design, it's a struggle at first. The interested reader might want to contemplate how this standard boilerplate in contract drafting: "For good and valuable consideration, the receipt and sufficiency of which are hereby acknowledged..." is relevant to design-by-contract in software construction.
I would also like to point out that this discussion of pre-condition sufficiency does not introduce anything new to object-oriented software design and development. Sufficiency is assumed in most discussions of design-by-contract as in, for example, Design by contract. There, the idea is deeply embedded in the discussion of DbC, but it's always tacit. If the original author is still maintaining the DbC article, or indeed this one, I would recommend that a brief mention of pre-condition sufficiency be added to either or both articles.
--Edgeorge99 (talk) 17:34, 4 April 2018 (UTC)Duncan George, Whitchurch-Stouffville, Canada
Start a discussion about improving the Precondition page
Talk pages are where people discuss how to make content on Wikipedia the best that it can be. You can use this page to start a discussion with others about how to improve the "Precondition" page.
- Stub-Class Computing articles
- Low-importance Computing articles
- All Computing articles
- Stub-Class Computer science articles
- Mid-importance Computer science articles
- WikiProject Computer science articles
- Stub-Class software articles
- Low-importance software articles
- Stub-Class software articles of Low-importance
- Unknown-importance Computing articles
- All Software articles