Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, la technologie ou de la langue sans un cahier des charges est inutile. Un cahier des charges sans testsuite est dangereux. Une suite de tests, sans majoration et de tests est impossible. Ce processus est assez complexe. Toutefois, il existe des moyens de simplifier l'étape de balisage.
Quant à la spécification en langage Java (JLS) et (JVM) elles sont écrites dans FrameMaker. Ensuite spec est exporté au format HTML et PDF. Le balisage est incorporé dans la version html. Mon opinion est que des informations de marquage doivent être placés dans (ou en relation avec) le texte d'origine. Dans notre cas, il s'agit d'un document FrameMaker. Je ne suis pas sûr que cela est possible à tous, mais je pense qu'il est. Si non, peut-être FrameMaker n'est pas la meilleure solution. En conséquence, nous permettra de réduire considérablement la quantité de temps et les efforts nécessaires pour le transfert de balisage ancien et le marquage de nouveau texte. En outre, durant l'écriture de la prochaine révision de la spécification de l'auteur avec l'équipe de tck devrait balisage tous les chenged et de nouvelles affirmations. Je dirais que la meilleure façon, c'est quand la rédaction de spécifications et les processus de balisage sont fait en même temps. Il est raisonnable pour l'auteur de souligner les développeurs à tester les états financiers qui doivent être testés.
Il est très important d'avoir un bon processus tout en écrivant la suite de test. Je vais parler de celui qui a été utilisé pour JLS.
Comme mentionné avant que le produit final est le nombre de tests. Il existe une relation entre les tests et le cahier des charges. Le processus axé sur l'affirmation donne une idée de ce que chaque groupe d'analyses effectivement des contrôles dans le cahier des charges. En utilisant cette relation le développeur peut calculer la couverture, obtenir la liste des affirmations sur lequel les essais n'ont pas été écrites, etc
L'affirmation est une déclaration d'un cahier des charges qui peuvent être testés. Et la première étape consiste à identifier toutes les affirmations contenues dans le cahier des charges. Après que le développeur peut écrire des tests.
Exemple d'affirmations de la Java Specification Language:
Une erreur de compilation se produit si le modificateur même apparaît plusieurs fois dans une déclaration d'interface.
Le nom de l'exécutable d'un type de membre se compose du nom de son binaire immédiatement joint type, suivi par $, suivi par le simple nom du membre.
Une instruction continue peut se produire que dans un certain temps, faire, ou pour la déclaration.
Il pourrait y avoir de nombreuses déclarations qui ne sont pas vérifiables ou qui impliquent l'incertitude. Parfois, de telles déclarations comprennent des termes comme «possible» ou «peut-être». Il n'est pas vrai que si une phrase a un mot «peut», il n'est pas vérifiable, mais habituellement il en est ainsi.
Exemples de déclarations non vérifiables:
Nous ne recommandons pas cette "notation mixte» pour les déclarations de tableau.
Les situations où la classe d'un objet n'est pas statique connu peut conduire à des erreurs de type run-time.
Toutefois, si l'évaluation d'une expression lève une exception, alors l'expression est dit pour terminer brusquement.
Il ya de nombreuses discussions et les différends au sujet des affirmations. Certains disent que les exemples ne doivent pas être traités comme des affirmations. D'autres disent que chaque instruction est une des affirmations et il ya deux sortes d'entre eux: vérifiables et non vérifiables. Mon opinion personnelle est que l'affirmation est certainement quelque chose de vérifiable. Et dans la plupart des cas sont des exemples affirmations simplement parce que le test peut être écrite vérifier l'exemple particulier.
Le processus d'identification des affirmations contenues dans le cahier des charges est appelée majoration. Il existe plusieurs approches. Mais en tout cas, l'utilisateur doit être en mesure d'obtenir des informations indiquant si la déclaration est une affirmation et en quelque sorte distinguer une affirmation d'un autre. Il pourrait y avoir un dépôt séparé avec la cartographie d'affirmations et de leur carte d'identité à des déclarations. J'aime l'idée d'intégrer le balisage dans le cahier des charges. Cette approche a été choisie pour la région de langue de la version Java SE suite de test. Le JLS a été écrit dans FrameMaker. Avec des mécanismes d'exportation du format PDF et HTML ont été créés. La version html a été utilisé lors de la création de la suite de test.
En JLS et JLS 2 quelques ancres spéciales identifié le début et la fin d'une affirmation. informations complémentaires ont été l'assertionID et bref résumé de la déclaration. La fin d'ancrage était une image et un lien vers le test. L'affichage HTML et la vue de code sont indiqués sur les illustrations correspondantes. L'affirmation d'identité sont arr033, arr034, arr020, etc
L'idée générale peut être décrite comme suit:
<a name=assertionID> <! - description shord en commentaire html -> déclaration affirmation ici <img href="path <a src="pics/assert.gif"> à test"> ID d'essai qui est le même que l'affirmation d'identité </ a>
Si des états distincts dans différentes parties du cahier des charges sont testées par un test de la première balise sera quelque chose comme arr033_0, arr033_1, arr033_2.
Ce type d'architecture a été utilisée pour JLS et JLS 2. Il a été légèrement modifiée pour JLS3, mais l'idée principale a été conservée. Je connais des exemples d'approches avec les identifiants de l'affirmation de non-statique conservés dans un dépôt séparé, où ID est une valeur de hachage calculée en fonction du contenu. Pour diverses raisons, il a montré à ne pas être une très bonne solution. Il ya toujours un processus difficile la migration vers la nouvelle version de la spécification. Mais, à mon avis, il est beaucoup plus facile avec l'ID statique est-elle intégrée dans le cahier des charges.
Parfois, tous ces termes semblent assez confus. Ou il est préférable de dire qu'ils en général ou même toujours. Surtout quand différentes personnes et les entreprises à comprendre la situation autour d'eux de différentes manières. Commençons donc dès le début.
Il ya beaucoup de spécifications ou des normes qui nous entoure. Le dictionnaire de Webster décrit comme quelque chose de standard établi par l'autorité, la coutume ou le consentement général comme un modèle ou un exemple. Donc, fondamentalement, c'est la liste des règles, qui ont d'autres lors de l'utilisation d'obéir.
Nous allons créer un langage informatique. Tout d'abord le cahier des charges est nécessaire, qui décrira le modèle de concept, les développeurs dire ce qui peut être écrit comme un programme, comment il se comportera, ce qui sera compilé, et exécuté etc Après avoir créé tous ces documents nécessaires - c'est ça, on peut s'arrêter là. Si l'idée est assez bonne plusieurs autres entreprises peut-être envie de créer leur mise en œuvre: des compilateurs et des environnements d'exécution Fe. Mais ils doivent obéir à la spécification. Sinon, les mêmes programmes qui seront exécutées sur un seul et courir différemment ou même échouer sur la mise en œuvre d'autres. Respect par une mise en œuvre de toutes les exigences spécifiées est appelé conformité.
Pourquoi est-il si important? Eh bien, disons que ce nouveau langage a été utilisé pour créer un programme de bourse. Imaginez qu'il a été écrit aux États-Unis, bien testé et utilisé au NYSE. Il était si bon, que d'autres pays partout dans le monde ont acheté une licence et a commencé à l'utiliser sur leur mise en œuvre de ce nouveau langage. Si une mise en œuvre n'a pas obéi à la spécification, le même programme peut faire des choses différentes avec l'argent des clients. Fondamentalement ce programme d'échange d'actions pourrait vendre lorsque l'agent commercial a poussé le bouton "acheter", ou acheter de l'acier au lieu de fruits.
La bonne question pourrait être: «Pourquoi implémentations différentes? Nous allons créer un et de l'utiliser. ". Il ya des réponses différentes. Plusieurs entreprises pourraient vouloir utiliser cette langue sur les différentes plateformes (Solaris, Linux, Windows) et les dispositifs (ordinateurs, téléphones portables, PDA, calculatrice des étudiants, etc.) D'autres veulent optimiser les algorithmes à leurs besoins, leur mise en œuvre de Fe de sorte que le programme de grande base de données sera 10 fois plus rapide.
Le point essentiel est que plusieurs implémentations différentes doivent travailler exactement de la même façon et selon les spécifications. S'ils le font, ils sont appelés compatible. La mauvaise partie est que personne ne peut en être sûr. C'est pourquoi le mécanisme de vérification est nécessaire. Habituellement il s'agit d'une suite de test qui vérifie la conformité et de compatibilité. Et dans ce cas, il est faux de dire que quelque chose est presque compatible ou 99% compatible. Il pourrait y avoir ni oui ni non.
Passons à un exemple. Sun Microsystems inventé le langage Java. Pour être plus précis plusieurs versions de Java pour les différents marchés ont été créés. Les plus célèbres sont , Java SE et . Et pour chacun d'eux il ya une spécification séparée. Sun Microsystems a sa propre implémentation, ce qui est le plus couramment utilisé. Toutefois, la langue est si bon, qu'il ya assez peu d'entreprises d'autres et de leurs implémentations. Pour assurer la compatibilité et la conformité des fins il ya TCKs (Test de conformité Kit). TCK est un produit qui comprend un certain nombre de tests, qui vérifier si une mise en œuvre est correcte selon les règles de la spécification.
Mon intention était de donner une idée de ce cahier des charges, la conformité, la compatibilité et TCK sont et pourquoi ils sont si importants.
Spécification est important - cette déclaration est clair pour tout le monde. Un produit largement utilisé, la technologie ou de la langue sans un cahier des charges est inutile. Un cahier des charges sans testsuite est dangereux. Une suite de tests, sans majoration et de tests est impossible. Ce processus est assez complexe. Toutefois, il existe des moyens de simplifier l'étape de balisage. 
