Software Engineering Terminology - What does "Inconsistency" and "Incompleteness" really mean [closed]

Closed. This question needs to be more focused. It is not currently accepting answers开发者_如何转开发.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 5 years ago.

Improve this question

In terms of designing software what does "Inconsistency" and "Incompleteness" really mean?

E.g. - Creating Specifications

Usage of Formal Methods of Software Engineering are said to be less "inconsistent" and "incomplete" than other less formal methods such as Object Orientated Design when creating specifications.

---

The question title indicates software eng. but the body specifies software design. These two terms are not equivalents.

Regarding inconsistency and incompleteness, there are many areas in which these apply. Just to name a few of them:

Incompleteness:

• of code what makes it not well-formed or syntactically complete, so not compilable, interpretable, executable
• of implementation - an algorithm can be incomplete, not handling possible cases properly
• of functionality - a software does not include all features ordered by a client or planned in a team

Inconsistency

• of conventions and coding style
• of design on implementation - interface of functions, classes and algorithms designed in inconsistent way (i.e. sort for vector expects vector to be passed, sort for list accepts two iterators)
• of design of user interface in terms of interactions - on one dialog user is supposed to hit ENTER to accept but on another dialog OK button is displayed for this action
• of look and feel of graphical user interface - various windows have completely different look; or command line interface - one option is given as -v value but another one as --v=value
• of licensing - imagine Visual Studio product is licensed on BSD, but .NET Framework on GPL :-)

---

Inconsistency and incompleteness are both originally terms from formal logic, where they are used to describe logical systems.

The full definitions depend on the exact context, but inconsistency normally means something like "for some X, you can prove both X and !X", and incompleteness means something like "for some X, you can't prove X and you can't prove !X".

So, for specifications, I'd understand "inconsistent" to mean something like "cannot be implemented, because it is self-contradictory in some way", and "incomplete" to mean "underspecified - for some inputs, the outputs are not clearly defined".

---

In database systems, a consistent transaction is one that does not violate any integrity constraints during its execution. If a transaction leaves the database in an illegal state, it is aborted and an error is reported.

In algorithms, the notion of completeness refers to the ability of the algorithm to find a solution if one exists, and if not, reports that no solution is possible.

In computational complexity theory, a problem P is complete for a complexity class C, under a given type of reduction, if P is in C, and every problem in C reduces to P using that reduction. For example, each problem in the class NP-complete is complete for the class NP, under polynomial-time, many-one reduction.

In software testing, completeness has for goal the functional verification of call graph (between software item) and control graph (inside each software item). The concept of completeness is found in knowledge base theory.

You could go on and on with such definitions... maybe make the question less vague?

And if I had a bad day, I'd link to "Goedels incompleteness theorems", as it would definitively be on topic ;)

---

One meaning of consistency and completeness (and their respective negations) in the context of formal systems is the following. Roughly, a system is consistent iff it's not possible to derive a contradiction from it. A system is complete iff it's possible to generate all of the truths about the underlying model. The ideal is to come up with a reasonable set of axioms that's able to "capture" all and only the truths about some given domain.

---

They can mean so many things, I'll just throw some examples here:

Inconsistency:

• Having an abstract class that was inherited by several classes but with inconsistent/conflicting implementations
• Using different design patterns on several similar implementations/models

Incompleteness:

• Not having holistic exception handling, only obvious ones are implemented
• Not covering entire scope of user required functionalities/features

The lists go on and on...

---

It's possible, based on context, that Formal Methods is referring to mathematical techniques for proving the correctness of programs. In that context, the use of mathematical proof would ensure that specifications are not inconsistent (no logical contradictions) or incomplete (there is a formal proof of the validity of the specification).

---

In the context of the example you provided, they simply mean that the imposition of a formal process -- one that has an end-to-end documented approach, methodology, set of deliverables, defined roles and responsibilities, will produce a better product than an ad-hoc approach to the same issue. In other words, formal systems that describe a complete software engineering process used consistently and applied throughout the lifetime of that project will produce better results than systems that do not provide this support framework.

It's the same as building a house. Yes, you can just run out and start nailing boards together and you might be able to build something you can live in, but if you instead study architecture, construction materials and techniques, define a workflow, etc., you'll end up with a better house. Even better than that, though, you'll be able to build that same house, or a similar one, again with a significantly higher probability of success.