I think I have it: "method/component implementations."

(An older term might be "function bodies" but in the object-oriented world they no longer talk about "functions" so this should be considered obsolete.)

I am familiar with this stuff because I've studied object-oriented programming languages such as Java, C++ and C# for years - I just wasn't used to hearing the French terminology! The term "codes métiers" refers to the notion of encapsulation, which is a way of separating specifications (declarations of function/method signatures, which are publicly advertised to callers) from implementations (definitions or bodies, which are often private, which means they can be re-implemented in different ways, provided they adhere to the publicly advertised specification).

I should emphasize that "codes métiers" is NOT something which is *contrasted* with "données réelles" - they are different things, but they are not opposites. Of course, "données réelles" is "real/actual" data - this is something that is supplied at run-time to test the software. In a similar fashion, "codes métiers" can also be supplied at run-time.

But they are not data - they are the implementations or definitions (or bodies, using older terminology) of functions or methods.

These functions or methods have already been "declared" or "specified" in the program (ie, their "signature" has been given, which means that the programmer has merely stated the type and number of arguments, plus the type of the return value). Later on, an implementation/definition of the function must be written. This is the "code métier" - it is the "innards" of a function/method, which accepts arguments of the type declared in the function/method signature, and computes and returns an actual return value, which will be of the return type declared in the function/method signature.

Here are some citations:

http://rainbow.i3s.unice.fr/~mosser/doku/tutoriels:sca:myfir...
Notice that what they're defining here is the method "CurrencyConverterImpl" which *implements* the Java 'interface' "CurrencyConverter." The 'interface' was declared earlier (this declaration merely stated the type(s) of the argument(s) any method implementing CurrencyConverterImpl would be required to accept) and the type of the return value. Now the programmer is defining an implementation (code métiers) which accepts a String, a String and a float and returns a float - and the implementation code defines exactly WHICH float is returned for given input String, String and float values.

Here's another example:
"Fractal respecte la notion de 'séparation des préoccupations' et
sépare les codes métiers (implémentation des composants)..."
PDF! http://jacquard.lifl.fr/modules/secure/biborb/bibs/jacquard/...
Doesn't provide too much explanation, but the bit in parentheses "implémentation des composants" (component implementations) is basically a definition of the term "codes métiers".
The term 'séparation des préoccupations' means 'separation of concerns' and it is closely related to the concept of encapsulation.

This suggests another synonym you could use: "component implementations."

Here's another example:
"On peut cependant citer le rechargement dynamique de classes, qui permet aux serveurs de servlets de mettre à jour rapidement et facilement - sans même arrêter le serveur - les codes métiers."
("One could however cite dynamic class reloading as an example, which allows servlet servers to rapidly and easily update **method/component implementations** without even stopping the server.")
http://nicolas.delsaux.free.fr/web/Java/classes_et_classload...



--------------------------------------------------
Note added at 2 hrs (2008-04-11 02:12:57 GMT)
--------------------------------------------------

TYPO (sorry) - should have been:
method/component implementations/definitiOns

--------------------------------------------------
Note added at 2 hrs (2008-04-11 02:15:42 GMT)
--------------------------------------------------

Another TYPE (in the first citation) - the letter "s" should be deleted so it reads:
"Now the programmer is defining an implementation (code métier_)"

--------------------------------------------------
Note added at 2 hrs (2008-04-11 02:23:01 GMT)
--------------------------------------------------

I guess the intuition in the French is that "code métier" is the "work code" (although this term is NEVER used in English).

The declaration/signature/specification (or in Java, an 'interface') of a function/method merely states how many parameters the function/method must be given, and what their types are - but it doesn't do any real computational work.

Then the method/function/component implementation/definition ("code métier") does the actual computation, accepting arguments (which must be of the type specified in the declaration) and returning a return value (which will also be of the type specified in the declaration).

For this reason, it is easy to see that there may be SEVERAL different "codes métiers" for a given specification/declaration/signature of a method/function/component (or for a Java 'interface'). All the different "codes métiers" should produce the same answer - but they may go about their work in different ways. We don't really care how they do their work (and this is what is meant by "encapsulation") - we just want the right answer, and it is also convenient, as time goes on, to be allowed to improve the "code métier" by perhaps writing a more efficient version, and to be able to "transparently" update an old "code métier" with a new one without "breaking" any of the existing code. This is what they are talking about in the source text - this is why they are able to provide the "codes métiers" so late in the process, along with the "données réelles."

Sorry to talk at such length about this - I'm just really into this stuff and I want to share!

--------------------------------------------------
Note added at 5 hrs (2008-04-11 04:37:51 GMT)
--------------------------------------------------

I am puzzled by Michael Tovbin's "neutral" comment claiming he had "not found any" hits discussing testing a solution using method implementations.

In fact, the third link given ("On peut cependant citer le rechargement dynamique de classes, qui permet aux serveurs de servlets de mettre à jour rapidement et facilement - sans même arrêter le serveur - les codes métiers." - "One could however cite dynamic class reloading as an example, which allows servlet servers to rapidly and easily update **method/component implementations** without even stopping the server.") specifically talks about using different method/component implementations/definitions, updating them and swapping them at runtime (dynamically). This underscores the fact that a given method/component may have various implementations/definitions, and that it is very easy to switch them -- and it would also of course be quite natural to test them against each other as well.

It is actually quite easy to find 20,000 Google hits about the topic "method implementation" and "test":

http://www.google.com/search?num=100&hl=en&q="method impleme...
(Not ALL these hits are 'a propos' of course, but a good many are.)

To summarize again: a programmer can start with a method/component/function declaration/signature/specification/interface (specifying only the number and type(s) of argument(s) the method/component/function expects as input, plus the type of the output or return value - e.g., integer, float, string, date), and then provide different implementations/definitions/(bodies) for this method/component/function declaration/signature/specification/interface.

WHAT each of these implementations/definitions does must be identical, but HOW they do it can vary widely, in terms of the actual steps used inside the body of the method implementation/definition.

But HOW a method/component/function computes its result "inside" its implementation/definition/body is largely irrelevant to the caller of said method/component/function, as long as every implementation returns the same answer/output, of the type advertised in the method/component declaration/signature/interface.

(Sorry about all the alternative terminology - I would not offer all these alternatives if I were writing an actual text - I am just giving them here so you can see the different choices available! My top preference for the target term would be "component implementation" or "method implementation".)

This is the meaning of encapsulation (where HOW a function does its work internally is irrelevant, as long as WHAT it returns for given inputs is always the same) which is the key concept in object-oriented programming.

This leads us to the situation where a programmer may have available various implementations/definitions for a given method/component/function, and so it is quite natural to want to test these different implementations/definitions in order to compare them (usually in terms of how fast they are, and how much memory they consume), which is the scenario the source text is talking about.

The source text uses the term "code metier" to refer to the implementation/definition of a method/component/function.

It might be easier to understand if the source text used a more direct translation from English, such as "implantation de methode." In fact, this direct translation also used sometimes:

http://www.google.com/search?num=100&hl=en&q="implantation d...
http://www.google.com/search?num=100&hl=en&q="implantation d...

-- just not in the given source text!

This is a topic which is discussed a lot more in English than in French.

--------------------------------------------------
Note added at 5 hrs (2008-04-11 04:59:36 GMT)
--------------------------------------------------

Another example! Based on this example, the term "implementation code" might be suitable also. Sorry about the accents - Adobe Acrobat butchered them.

The important thing to note here is that it talks about "evolution" of the "code metier." Again, this emphasizes the idea that different "codes metiers" can be developed which do the same thing, but perhaps faster or using less memory - which is why we want to test the different "code metiers" to see which one is fastest and/or uses the least amount of memory.

PDF! http://stephane.ducasse.free.fr/Teaching/CoursAnnecy/0506-M1...

S´eparer l’interface du ***code m´etier***

La structure sugg´er´ee pour l’exercice pr´ec´edent n’est pas tr`es propre. En effet, un mˆeme objet prend en charge `a la fois le traitement (***code m´etier***: incr´ementer/d´ecr´ementer, modification de l’incr´ement, ) et l’interface utilisateur. Ce choix de conception rend difficile les ´eventuelles ´evolutions ou r´eutilisation. En particulier, si l’on souhaite changer d’interface utilisateur, voire de mod`ele de communication distante.

Dans cet exercice, on se propose de faire la s´eparation entre ***code m´etier*** et code d’interface et en illustrer l’utilit´e `a l’aide d’un exemple simple. Cet exemple tourne autour d’une calculatrice arithm´etique. Vous d´efinirez tout d’abord la classe Calculatrice qui dispose de deux champs qui repr´esentent respectivement l’op´erande gauche et l’op´erande droite. Munissez la classe d’accesseurs en lecture ´ecriture `a ces deux
champs, ainsi que de 4 m´ethodes pour r´ealiser les 4 op´erations arithm´etiques. Bien entendu, ces quatre m´ethodes :

• ne prennent pas de param`etres,

• effectuent le calcul en utilisant les champs repr´esentant les deux op´erandes,

• et retournent le r´esultat du calcul

D´efinissez ensuite la classe CalculatriceWeb sous-classe de WAComponent qui repr´esente une application Seaside. CalculatriceWeb permet l’utilisation `a travers le web des op´erations fournies par Calculatrice.

Son interface s’apparente `a celle donn´ee par la figure 7.2.

Vous allez maintenant exploiter la s´eparation entre ***code m´etier*** et code d’interface utilisateur. En effet, vous allez r´eutiliser la classe Calculatrice pour faire un nouveau compteur accessible via le web.
L’interface devra ˆetre identique `a celle du compteur de l’exercice pr´ec´edent.