Separation Of Declarative

Separation of the Declarative from the Imperative part of the software

This is similar to separating the data from the object (ObjectsAndDataAreSeparate). The idea is that declarative languages are easier to explain to non-programmers, have fewer bugs, and if we can separate it from the imperative/functional part, we can incorporate ExpertUsers or BusinessProfessionals to the development process, and have fewer bugs.

I've seen only a few projects that use it. One of them was a learnware that was partially written in Prolog. That part was done by school teachers, with no programming background, who learned Prolog for the sake of the project. Later on, a new version was written in C++, which didn't do all the functions of the first one, and was impossible to change.

It is one of the major TgpPrinciples of the TgpMethodology. The TgpArchitecture divides between the declarative and the imperative parts of the software. It creates a declarative framework which is incrementally shaped and used by both BusinessProfessionals and developers. The declarative part can be easily presented and adjusted using the VisualSharedModel. The separation of the declarative also promote the cooperation of BusinessProfessionals in the OrganicTesting.

TGP suggests a well-defined development process to incrementally separate the declarative part. It can be also regarded as an incremental process of modeling the domain (TgpProcess). Expanding the TGP VisualSharedModel, Types are added and refactored, ProfileTemplates and Profiles are added and extended.

The way TgpArchitecture separates the modular declarative part from the imperative part of the software is presented in the following figure:

-- ShaiBenYehuda and OriInbar

Discussion

Note that such separation tends to go against OOP philosophy, for good or bad.

Maybe the real point is preserving locality and encapsulation. Hence, gaining simplicity, flexibility, and extendibility of the system. If the declarative part is a shared repository (knowledge DB) that can be accessed by any procedural component, I agree it somehow contradicts the principles of encapsulation and information hiding. However, TGP suggests that the declarative part itself has an object model, and this object model is identical (almost) to the object model of the software (should say imperative part). Doing that, encapsulation can be preserved by encapsulating "ProfileTemplates" and "Profiles" with the generic classes, and encapsulating "Types" with interfaces (TgpArchitecture). -- ShaiBenYehuda

Says who? Perhaps that's true in some languages like PythonLanguage, where essentially everything is imperative - a class definition is treated like a procedure that happens to construct an object, rather than a specification of one which is reasoned on by some external machine. On the other hand, languages like CeePlusPlus, JavaLanguage, CsharpLanguage, or EiffelLanguage have a very strong declarative component. Any sort of StaticTyping is fundamentally declarative (though in some cases it's inferred). Preconditions/postconditions (contracts) in Eiffel are declarative.

There is some confusion here. Maybe you mean "Declarative" is the sense of method declaration vs method implementation. The SeparationOfDeclarative is about writing the software in two different languages - a procedural language (like C, Java, etc) and a declarative language (xml, prolog). The idea is that programmers deal better with procedural, but non-programmers deal better with the declarative, and Tgp aims to find a way of incorporating both into the development process -- Moddy Te'eni.

CategoryAgileMethodology