Développement d'un module logiciel. Programmation structurée. PM.01. Développement de modules logiciels pour systèmes informatiques Développement de programmes de modules de modules logiciels

Annotation du programme de travail du module professionnel

nom du module professionnel

1. Portée du programme

Le programme de travail du module professionnel fait partie du programme de formation pour les spécialistes de niveau intermédiaire conformément à la norme éducative de l'État fédéral du SPO 09.02.07 Systèmes d'information et programmation, qui fait partie du groupe élargi de spécialités 09.00.00 Informatique et informatique

et compétences professionnelles pertinentes (PC) :

Le programme de travail du module professionnel peut être utilisé dans le cadre de la formation des spécialistes du cours « Développement de modules logiciels Logiciel pour les systèmes informatiques "sur la base de l'enseignement général de base. Aucune expérience de travail requise.

Le programme de travail est établi à temps plein, à temps partiel, à temps partiel avec des éléments de technologies d'enseignement à distance, des formes d'enseignement.

2. Buts et objectifs du module - exigences pour les résultats de la maîtrise du module

A la suite de la maîtrise de la partie obligatoire du module, l'étudiant doit avoir une expérience pratique :

Développement d'un algorithme pour la tâche et sa mise en œuvre au moyen de la conception assistée par ordinateur ;

Développement de code produit logiciel basé sur une spécification prête à l'emploi au niveau du module ;

Utilisation d'outils au stade du débogage du produit logiciel ;

Tester un module logiciel selon un scénario précis.

À la suite de la maîtrise de la partie obligatoire du module, l'étudiant devrait être capable de :

Réaliser le développement du code du module de programme sur langues modernes la programmation;

Créer un programme selon l'algorithme développé en tant que module séparé ;

Déboguer et tester le programme au niveau du module ;

Rédiger la documentation des logiciels ;

Utilisez des outils pour automatiser la paperasse.

À la suite de la maîtrise de la partie obligatoire du module, l'étudiant doit savoir :

Les principales étapes du développement d'un logiciel ;

Principes de base de la technologie de programmation structurée et orientée objet ;

Principes de base du débogage et du test des produits logiciels ;

Méthodes et outils pour l'élaboration de la documentation technique.

6. Développement de code de programme à l'aide d'une programmation structurée

7. Développement du code du programme à l'aide de détails étape par étape

8. Développement de code de programme en utilisant la programmation modulaire

9. Initialisation des tableaux

10. Implémentation de structures dynamiques utilisant des tableaux

11. Développement de code de programme à l'aide de structures

12. Développement de code de programme à l'aide de fonctions

13. Développement de code de programme en utilisant le déréférencement de pointeur

14. Mise en œuvre des entrées-sorties

15. Implémentation de flux de fichiers

16. Implémentation des données de chaîne

17. Développement de classes statiques

18. Développement de classes dynamiques

19. Développement de classes abstraites

20. Développement de modèles de classe

21. Exécution du code du programme de débogage

22. Effectuer un tri à bulles

23. Exécution du tri par insertion

24. Effectuer le tri par la méthode de Hoare

25. Réalisation de tests de code de programme selon le principe de la « boîte blanche »

26. Effectuer des tests de code de programme selon le principe de la « boîte grise »

27. Réalisation de tests de code de programme selon le principe de la « boîte noire »

28. Mise en œuvre de l'optimisation du code du programme

29. Mise en œuvre de l'optimisation des moteurs de recherche du code du programme

30. Rédaction de la documentation technique

31. Élaboration d'algorithmes pour travailler avec des graphiques

32. Initialisation du système graphique

33. Travailler avec des fenêtres et des coordonnées

34. Travailler avec des primitives graphiques

35. Créer une image animée

36. Rédaction de la documentation utilisateur

MINISTÈRE DE L'ÉDUCATION ET DES SCIENCES

RÉPUBLIQUE POPULAIRE DE DONETSK

PROFESSIONNEL D'ETAT

ÉTABLISSEMENT D'ENSEIGNEMENT

« COLLÈGE INDUSTRIEL ET ÉCONOMIQUE DE DONETSK »

PROGRAMME DE TRAVAIL

Pratique pédagogique UP.01

module professionnel PM.01 Développement de modules logiciels pour systèmes informatiques

dans la spécialité 09.02.03 "Programmation dans les systèmes informatiques"

Compilé par:

Volkov Vladimir Aleksandrovich, professeur de disciplines informatiques de la catégorie de qualification "spécialiste de la catégorie la plus élevée", établissement public d'enseignement public "Donetsk Industrial and Economic College"

Le programme a été approuvé par : Vovk Pavel Andreevich, directeur de "Smart IT Service"


1. PROGRAMME PASSEPORT DE PRATIQUE
2. RÉSULTATS DE LA PRATIQUE
3. STRUCTURE ET CONTENU DE LA PRATIQUE
4. CONDITIONS D'ORGANISATION ET D'EXERCICE
5. CONTRLE ET ÉVALUATION DES RÉSULTATS DE LA PRATIQUE

1 PASSEPORT DE LA PRATIQUE ÉDUCATIVE PROGRAMME UP. 01

1.1 Lieu de stage UP.01

Programme pratique UP.01 du module professionnel PM.01 "Développement de modules logiciels pour systèmes informatiques" spécialité 09.02.03 "Programmation en systèmes informatiques » groupe élargi 09.00.00 « Informatique et technologie informatique », en termes de maîtrise du type principal d'activité professionnelle (VPA) :

Développement de modules logiciels pour systèmes informatiques et compétences professionnelles associées (PC) :

	Développer des spécifications pour les composants individuels.
	Mettre en œuvre le développement du code du produit logiciel basé sur des spécifications prêtes à l'emploi au niveau du module.
	Déboguer les modules logiciels à l'aide d'un logiciel spécialisé.
	Effectuer des tests de modules logiciels.
	Optimisez le code de programme du module.
	Développer des composants de conception et de documentation technique à l'aide de langages de spécifications graphiques.

Le programme de pratique pédagogique UP.01 du module professionnel PM.01 "Développement de modules logiciels pour systèmes informatiques" peut être utilisé dans l'enseignement professionnel complémentaire et la formation professionnelle des travailleurs pour les spécialités 09.02.03 Programmation dans les systèmes informatiques en présence de secondaire formation générale (complète). Aucune expérience de travail requise.

1.2 Buts et objectifspratique d'entraînement UP.01

Afin de maîtriser le type d'activité professionnelle spécifié et les compétences professionnelles correspondantes, l'étudiant en cours de pratique pédagogique UP.01 doit :

avoir une expérience pratique :

développement d'un algorithme pour la tâche et sa mise en œuvre au moyen de la conception assistée par ordinateur ;

développement d'un code de produit logiciel basé sur une spécification prête à l'emploi au niveau du module ;

utilisation d'outils au stade du débogage du produit logiciel ;

tester le module logiciel selon un scénario spécifique ;

être capable de:

développer le code du module logiciel dans les langages de programmation modernes ;

créer un programme selon l'algorithme développé en tant que module séparé ;

déboguer et tester le programme au niveau du module ;

rédiger la documentation des logiciels ;

utiliser des outils pour automatiser l'exécution de la documentation ;

savoir:

les principales étapes du développement logiciel ;

principes de base de la technologie de programmation structurée et orientée objet ;

principes de base du débogage et du test des produits logiciels ;

méthodes et outils pour l'élaboration de la documentation technique.

1.3 Nombre de semaines(les heures) maîtriser le programmepratique d'entraînement UP.01

Seulement 1,5 semaines, 54 heures.

2 RÉSULTATS DE LA PRATIQUE

Le résultat de la pratique de formation UP.01 du module professionnel PM.01 « Développement de modules logiciels pour systèmes informatiques » est le développement de compétences générales (GC) :

	Nom du résultat de la pratique
	-
OK 2. Organisez vos propres activités, choisissez des méthodes et des manières standard d'effectuer des tâches professionnelles, évaluez leur efficacité et leur qualité.
OK 3. Prendre des décisions dans des situations standard et non standard et en être responsable.
OK 4. Rechercher et utiliser les informations nécessaires à l'accomplissement efficace des tâches professionnelles, au développement professionnel et personnel.
OK 5. Utiliser les technologies de l'information et de la communication dans les activités professionnelles.
OK 6. Travailler en équipe et en équipe, communiquer efficacement avec les collègues, la direction, les consommateurs.
OK 7. Assumer la responsabilité du travail des membres de l'équipe (subordonnés), du résultat des missions.	-
	qualifications
OK 9. Naviguer dans des conditions d'évolutions fréquentes des technologies dans les activités professionnelles.

compétences professionnelles (PC) :

Activité professionnelle		Nom des résultats de la pratique
Maîtriser le principal type d'activité professionnelle		utilisation des ressources des réseaux informatiques locaux et mondiaux; gestion de fichiers de données sur des dispositifs de stockage locaux amovibles, ainsi que sur des disques d'un réseau informatique local et sur Internet; l'impression, la duplication et la copie de documents sur une imprimante et d'autres équipements de bureau. suivi sous forme de rapport pour chaque TP. examen de qualification mod.
		alphabétisation et précision du travail dans les programmes appliqués : éditeurs de textes et graphiques, bases de données, éditeur de présentations ; la vitesse de recherche d'informations dans le contenu des bases de données.
		précision et alphabétisation des paramètres E-mail, logiciel serveur et client : la vitesse de récupération des informations à l'aide des technologies et des services Internet ; l'exactitude et la maîtrise de la saisie et de la transmission d'informations à l'aide des technologies et des services Internet.
		alphabétisation dans l'utilisation des méthodes et moyens de protection de l'information contre l'accès non autorisé; justesse et précision Réserver une copie et récupération de données ;
		alphabétisation et précision de travail avec les systèmes de fichiers, divers formats de fichiers, programmes de gestion de fichiers ;
		tenue de la comptabilité et de la documentation technique.

3 STRUCTURE ET CONTENU DU PROGRAMMEPRATIQUE ÉDUCATIVE UP.01

3.1 Plan thématique

Codes de compétence

Nom du module professionnel

La quantité de temps, mettre de côté pour la pratique

(en semaines, les heures)

date de la

CP 1.1 - CP 1.6

PM.01 "Développement de modules logiciels pour systèmes informatiques"

1,5 semaines,

54 heures

3.2 Contenu de la pratique

Activités	Types d'emplois		Nom des disciplines académiques, cours interdisciplinaires indiquant des sujets, assurer l'exécution de types de travaux	Nombre d'heures (semaines)
"Maîtriser le principal type d'activité professionnelle »	Sujet 1. Introduction. Algorithmes pour résoudre des problèmes. La structure de l'algorithme linéaire. La structure de l'algorithme cyclique. Algorithme d'un sous-programme (fonction).	Connaissances formées sur les bases de la création d'objets spéciaux
	Thème2 . Mercredi Skratch (Scratch).	Connaissances formées sur les bases des outils d'automatisation de processus Connaissances formées sur les bases des effets d'animation sur les objets ; utilisation d'hyperliens et de boutons ; personnalisation de démonstration ; présentation enregistrée dans différents formats.	MDK.01.01 "Programmation système"
	Thème 3 ... Création d'un programme de formation (leçon du sujet).	Connaissances formées sur les bases de l'analyse de données à l'aide de fonctions de processeur	MDK.01.02 "Programmation appliquée"
	Sujet 4. Développement d'un programme de jeu.	Connaissances formées sur les bases du calcul des caractéristiques finales	MDK.01.01 "Programmation système"
	Sujet 5. Langage de programmation graphique LabVIEW.	Connaissances formées sur les bases de la création d'un test de processeur.	MDK.01.02 "Programmation appliquée"
	Thème 6. Créez une application à l'aide de LabVIEW.	Connaissance des bases du dialogue de l'utilisateur avec le système	MDK.01.02 "Programmation appliquée"
	Thème 7 Réutiliser un fragment de programme.	Connaissance approfondie des opérateurs et des fonctions du système.	MDK.01.02 "Programmation appliquée"
	Thème 8 Atelier LabVIEW. Protection du travail lors du travail avec un ordinateur sur le lieu de travail de l'utilisateur.	Connaissances formées sur le calcul des fonctions élémentaires. Connaissances acquises sur la protection du travail.	MDK.01.02 "Programmation appliquée". OP.18 « Protection du travail »
	Thème 9 Conclusion. Rédaction d'un rapport de pratique.	Compétences d'analyse formées la technologie informatique, les compétences de résolution de problèmes sont formées.	MDK.01.01 "Programmation système" MDK.01.02 "Programmation appliquée" MDK.04.01 "Logiciel bureautique"

4 CONDITIONS D'ORGANISATION ET DE CONDUITE

PRATIQUE ÉDUCATIVE UP. 01

4.1 Exigences en matière de documentation, nécessaire à la pratique:

Le programme de travail de la pratique de formation UP.01 du module professionnel PM.01. "Développement de modules logiciels pour systèmes informatiques" fait partie du programme de formation des spécialistes de niveau intermédiaire de l'établissement d'enseignement professionnel d'État "Donetsk Industrial and Economic College" conformément à la norme d'enseignement de l'enseignement secondaire professionnel dans la spécialité 09.02.03 "Programmation en Systèmes Informatiques", fondée sur le cursus de la spécialité, programme de travail sur les disciplines MDK.01.01 "Programmation système", MDK01.02 "Programmation appliquée", recommandations méthodologiques pour l'enseignement et accompagnement méthodologique de la pratique des élèves, maîtrise des programmes pédagogiques de l'enseignement secondaire professionnel.

4.2 Exigences pour le soutien pédagogique et méthodologique de la pratique:

une liste des travaux approuvés par type de travail, des lignes directrices pour les étudiants sur l'exécution des travaux, des recommandations pour la mise en œuvre des rapports sur la pratique.

4.3 Exigences logistiques:

l'organisation de la pratique industrielle nécessite la présence de salles de cours et d'un laboratoire.

Matériel de bureau et lieux de travail :

places assises selon le nombre d'élèves (table, ordinateur, chaise) ;

lieu de travail de l'enseignant (table, ordinateur, chaise);

armoire pour ranger du matériel didactique et des supports d'information;

devoirs pour une approche individuelle de l'enseignement, organisation de travaux et d'exercices indépendants, un étudiant sur un ordinateur;

littérature de référence et méthodologique;

un ensemble de systèmes, d'applications et de programmes de formation pour PC sur supports optiques et électroniques ;

journal d'instruction des étudiants sur la protection du travail;

un ensemble de supports pédagogiques.

Supports techniques de formation :

tableau de classe;

ordinateur personnel avec logiciel sous licence;

imprimante laser;

PC éducatifs;
ensemble d'équipements interactifs (projecteur, écran, haut-parleurs);
moyens d'extinction d'incendie (extincteur).

L'équipement du bureau et des lieux de travail d'outils de développement : ordinateurs personnels (moniteur, unité centrale, clavier, souris), un ensemble de documentation pédagogique et méthodologique, des logiciels conformes au contenu de la discipline (shell langages de programmation).

Tous les ordinateurs de la classe sont réunis en un réseau local, ont accès au stockage d'informations en réseau et ont accès à Internet.

Équipement de communication:

adaptateurs réseau;

câbles réseau;

Équipement sans fil Wi-Fi.

Composants pour l'installation de réseaux, équipements pour l'installation.

4.4 Liste des publications pédagogiques, Ressources Internet, littérature supplémentaire

Sources principales:

Olifer V.G. Systèmes d'exploitation réseau : manuel pour les universités / V.G.Olifer, N.A.Olifer. - 2e éd. - Saint-Pétersbourg : Peter, 2009,2008. - 668 p. :

E. Tanenbaum. OS. Développement et mise en œuvre. SPb. : Pierre, 2006 .-- 568 p.

Pupkov K.A. Maîtriser le système d'exploitation Unix / K.A. Pupkov, A.S. Chernikov, N.M. Yakusheva. - Moscou : Radio et communication, 1994 .-- 112 p.

L. Beck Introduction à la programmation système - M. : Mir, 1988.

Grekul V.I., Denischenko G.N., Korovkina N.L. Conception des systèmes d'information / Moscou : Binom, 2008. - 304 p.

Lipaev, V.V. Génie logiciel. Fondements méthodologiques [Texte] : Manuel. / V. V. Lipaev ; État un-t - École supérieure d'économie. - M. : TEIS, 2006 .-- 608 p.

Lavrischeva E. M., Petrukhin V. A. Méthodes et moyens du génie logiciel. - Cahier de texte

Ian Somerville. Génie logiciel, 6e édition .: Per. de l'anglais M. : Maison d'édition "Williams", 2002. ― 624 p.

Excel 2010 : programmation professionnelle en VBA. : Per. de l'anglais - M. : SARL « I.D. Williams », 2012. - 944 p. : malade. - Parallèle. mésange. Eng

Fowler M. Refactoring : amélioration du code existant ― Per. De l'anglais ― SPb : Symbol-plus, 2003. 432 p.

Sources supplémentaires :

Volkov V.A. INSTRUCTIONS METHODOLOGIQUES pour la mise en œuvre Travaux pratiques dans la discipline "Programmation système", Donetsk : DONPEK, 2015.

Volkov V.A. Instructions méthodiques pour la mise en œuvre du projet de cours, Donetsk : DONPEK, 2015.

L'Internet- Ressources:

Programmation système [ressource électronique] / Mode d'accès : http://www.umk3.utmn.ru.

Logiciels et ressources Internet : http://www.intuit.ru

Littérature disciplinaire - http://www.internet-technologies.ru/books/

Manuel électronique "Introduction to Software Engineering" - http://www.intuit.ru/studies/professional_skill_improvements/1419/info

Manuel électronique "Technologie de programmation" -http://bourabai.kz/alg/pro.htm

4.5 Exigences pour les chefs de pratique d'un établissement d'enseignement et d'une organisation

Exigences pour les chefs de pratique d'un établissement d'enseignement :

personnel ingénieur et enseignant : diplômés - enseignants des filières interdisciplinaires et des disciplines professionnelles générales. Une expérience professionnelle dans des organisations du domaine professionnel concerné est requise.

Master de formation industrielle : la présence de 5-6 diplômes avec un stage obligatoire dans des organismes spécialisés au moins une fois tous les 3 ans. Une expérience professionnelle dans des organisations du domaine professionnel concerné est requise.

5 CONTRLE ET ÉVALUATION DES RÉSULTATS

PRATIQUE ÉDUCATIVE UP. 01

Formulaire de rapport sur la pratique éducative UP.01 - un rapport sur la pratique, établi conformément aux exigences des recommandations méthodologiques.

résultats (compétences professionnelles maîtrisées)	Principaux facteurs résultat de la préparation	Formes et méthodes contrôler
PC 1.1. Réaliser l'élaboration des spécifications pour les composants individuels	Développement d'un algorithme pour la tâche et sa mise en œuvre au moyen de la conception assistée par ordinateur	Observation et évaluation expertes de l'activité de l'étudiant dans le processus de maîtrise du programme pédagogique en cours pratiques, tout en réalisant des travaux sur la pratique pédagogique et industrielle.
PC 1.2. Mettre en œuvre le développement du code du produit logiciel basé sur des spécifications prêtes à l'emploi au niveau du module.	Connaître les principes de base de la technologie de programmation structurée et orientée objet. Développer le code d'un module logiciel dans les langages de programmation modernes.
CP 1.3. Déboguer les modules logiciels à l'aide d'un logiciel spécialisé	Déboguez et testez le programme au niveau du module.
PC 1.4. Effectuer des tests de modules logiciels.	Créez un programme selon l'algorithme développé en tant que module séparé.
PC 1.5. Optimiser le code programme du module	Développement d'un code produit logiciel basé sur une spécification prête à l'emploi au niveau du module.
PC 1.6. Développer des composants de conception et de documentation technique à l'aide de langages de spécifications graphiques	Connaître les méthodes et moyens d'élaboration de la documentation technique. Rédiger la documentation du logiciel. Utilisez des outils pour automatiser la paperasse.

Les formes et les méthodes de suivi et d'évaluation des acquis d'apprentissage devraient permettre de vérifier non seulement la formation de compétences professionnelles chez les étudiants, mais aussi le développement de compétences générales et des aptitudes qui les fournissent.

résultats (compétences générales maîtrisées)	Principaux indicateurs d'appréciation du résultat	Formes et méthodes de contrôle et d'évaluation
OK 1. Comprenez l'essence et la signification sociale de votre future profession, montrez-y un intérêt constant.	Démonstration d'un intérêt constant pour la future profession; - la validité de l'application des compétences professionnelles maîtrisées ;	Observation et évaluation d'experts dans la formation pratique lors de l'exécution de travaux sur la pratique industrielle ;
OK 2. Organisez vos propres activités, déterminez les méthodes et manières d'accomplir les tâches professionnelles, évaluez leur efficacité et leur qualité.	Justification de l'établissement d'objectifs, sélection et application de méthodes et méthodes de résolution de problèmes professionnels ; Introspection et correction des résultats de son propre travail	Évaluation en formation pratique lors de l'exécution des travaux ; Observation pendant la pratique; Introspection
OK 3. Résoudre des problèmes, évaluer les risques et prendre des décisions dans des situations non standard.	Efficacité de la prise de décision pour les tâches professionnelles standard et non standard pendant un certain temps ; L'efficacité du plan pour optimiser la qualité du travail effectué	Interprétation des résultats de l'observation des activités de l'élève en cours de réalisation des tâches
OK 4. Rechercher, analyser et évaluer les informations nécessaires à la définition et à la résolution de problèmes professionnels, de développement professionnel et personnel.	Sélection et analyse des informations nécessaires pour une mise en œuvre claire et rapide des tâches professionnelles, développement professionnel et personnel	Expertise en cours de travail ; Maîtrise de soi au cours de la pose et de la résolution de problèmes
OK 5. Utiliser les technologies de l'information et de la communication pour améliorer l'activité professionnelle.	la capacité d'utiliser les technologies de l'information et de la communication pour résoudre des problèmes professionnels	évaluation des missions
OK 6. Travailler en équipe et en équipe, assurer sa cohésion, communiquer efficacement avec les collègues, la direction, les consommateurs.	Capacité à interagir avec un groupe, enseignants, maître de formation industrielle
OK 7. Fixer des objectifs, motiver les activités des subordonnés, organiser et contrôler leur travail avec la prise en charge du résultat des missions.	- introspection et correction des résultats de son propre travail et du travail de l'équipe	Observer l'avancement des travaux d'un groupe en cours de formation pratique
OK 8. Pour déterminer de manière indépendante les tâches de développement professionnel et personnel, s'engager dans l'auto-éducation, planifier consciemment le développement professionnel.	Organisation du travail indépendant pour former une image créative et professionnelle; Organisation du travail sur l'auto-éducation et l'amélioration qualifications	Observation et évaluation dans le processus de pratique industrielle; Analyse réflexive (algorithme des actions des élèves) ; Journal de pratique ; Analyse du portefeuille des étudiants
OK 9. Soyez prêt à changer de technologie dans l'activité professionnelle.	Analyse des innovations dans le domaine des procédés technologiques pour le développement et la fabrication de vêtements	Évaluation des solutions aux tâches situationnelles ; Jeux d'apprentissage commerciaux et organisationnels; Observation et évaluation en formation pratique, en cours de pratique industrielle

ESSAI

Travaux de conception d'essais PM.01 "Développement de modules logiciels pour systèmes informatiques". Établissement d'enseignement professionnel budgétaire de l'État de la République de Crimée "Feodosia Polytechnic College". 2015 -20 pp., illustrations 7, annexe 1, sources bibliographiques 3.

L'outil logiciel « Actions sur matrices » a été conçu et mis en œuvre, une interface graphique a été développée pour cela dans l'environnementMicrosoft Visual Studio Ultimate 2013 C#. Le produit logiciel vous permet d'étudier la structure et la syntaxe des nouveaux langages de programmation.

OUTIL LOGICIEL, TERMES DE REFERENCE, TESTS FONCTIONNELS, TESTS D'EVALUATION, TESTS STRUCTURELS, ENVIRONNEMENT DE DEVELOPPEMENT, DEBOGAGE, ALGORITHME, INTERFACE

INTRODUCTION

1 DÉVELOPPEMENT D'UN ALGORITHME POUR LE PROBLÈME ÉNONCÉ ET MISE EN UVRE DE SES MOYENS DE CONCEPTION AUTOMATISÉE

1.1 Analyse de la tâche

1.2 Choix des méthodes et développement des algorithmes de base pour la résolution

2 DEVELOPPEMENT DU CODE PRODUIT LOGICIEL SUR LA BASE D'UNE SPECIFICATION PRETE AU NIVEAU DU MODULE

3. UTILISATION DES OUTILS AU STADE DE DEBOGAGE DU MODULE LOGICIEL

4 TEST DU MODULE LOGICIEL POUR UN SCÉNARIO SPÉCIFIQUE

5 ENREGISTREMENT DE LA DOCUMENTATION SUR LE LOGICIEL

LISTE DE RÉFÉRENCES

ANNEXE A

INTRODUCTION

Chaque produit logiciel se compose de modules. Le module peut être développé séparément et ainsi mettre à niveau le logiciel pour améliorer ses fonctionnalités.

Le but du travail est :

Consolidation des connaissances théoriques obtenues dans les disciplines Programmation appliquée, Programmation système, Théorie des algorithmes, Fondamentaux de la programmation et des langages algorithmiques" ;
Collecte, analyse et synthèse de matériaux pour la préparation d'un rapport sur la pratique.

Les tâches du travail sont déterminées par une tâche individuelle :

analyse de la tâche ;
sélection de méthodes et développement d'algorithmes de résolution de base ;
choix de la technologie et de l'environnement de programmation ;
la construction d'un cadre d'application et la conception d'une interface utilisateur ;
développement d'un code de produit logiciel basé sur une spécification prête à l'emploi ;
le choix d'une stratégie de test et le développement de tests ;
utiliser les outils de débogage fournis par l'interface utilisateur ;
tester un module logiciel selon un scénario précis ;
enregistrement de la documentation d'un outil logiciel.

Le travail est divisé en cinq sections.

La première section décrit le développement d'un algorithme pour la tâche et sa mise en œuvre au moyen de la conception assistée par ordinateur.

Dans la deuxième section, le choix de la technologie de l'environnement de programmation est justifié, l'interface utilisateur conçue est décrite et le code du produit logiciel est développé.

La troisième section décrit comment utiliser les outils pendant la phase de débogage d'un module de programme.

La quatrième section décrit les tests du module logiciel, décrit les tests fonctionnels, structurels, évaluatifs.

La cinquième section est consacrée à la conception de la documentation de l'outil logiciel.

1 DÉVELOPPEMENT D'UN ALGORITHME POUR LE PROBLÈME ÉNONCÉ ET MISE EN UVRE DE SES MOYENS DE CONCEPTION AUTOMATISÉE

1.1 Analyse de la tâche

Il est nécessaire d'écrire un programme qui effectuera des actions sur les matrices : multiplication, addition, soustraction, transposition. Le programme doit résoudre la matrice entrée manuellement dans le formulaire. Pour la commodité de l'utilisateur, le programme doit avoir une interface intuitive.

1.2 Choix des méthodes et développement des algorithmes de base pour la résolution

Le programme utilise l'algorithme de travail suivant : le programme a des formulaires dans lesquels les éléments de la matrice sont entrés, les éléments sont traduits de Type de chaîne en entier ... Ensuite, vous devez appuyer sur le bouton de l'action correspondante. L'algorithme de résolution des matrices est exécuté et le résultat est affiché dans l'élément DataGridView.

Pour construire des schémas fonctionnels, nous avons utilisé le programme Microsoft Office Visio 2013. Avec son aide, vous pouvez établir divers diagrammes et schémas, y compris des schémas fonctionnels.

Figure 1.1 - Schéma fonctionnel de la lecture et de l'écriture de données depuis l'écriture dans un tableau

Figure 1.2 - Vérifier l'accessibilité pour l'entrée

Figure 1.3 - Schéma fonctionnel de la saisie des données dans zone de texte et comparaisons avec un tableau existant

Figure 1.4 - Appel de méthode Vizov avec paramètres

2 DEVELOPPEMENT DU CODE PRODUIT LOGICIEL SUR LA BASE D'UNE SPECIFICATION PRETE AU NIVEAU DU MODULE

Le calculateur matriciel est implémenté dans le langage de programmation C # dans l'environnement de programmation Microsoft Visual Studio Ultimate 2013. Le choix du langage C # est dû au fait qu'il s'agit d'un langage de programmation orienté objet moderne et populaire, et le langage Microsoft Visual L'environnement Studio Ultimate 2013 est un outil puissant qui vous permet de créer rapidement un programme avec une interface graphique fenêtrée.

La disposition des fenêtres est illustrée à la figure 2.1.

Figure 2.1 - Interface fenêtre de la future application

Il y a 3 éléments sur le formulaire DataGridView , ils contiendront des matrices. Aussi 4 Bouton pour effectuer des actions sur les matrices.

3. UTILISATION DES OUTILS AU STADE DE DEBOGAGE DU MODULE LOGICIEL

Lors du débogage d'un produit logiciel, utilisez la commande de menu Déboguer (Fig. 3.1). Il existe un certain nombre de commandes dans le menu de débogage, dont le but est indiqué ci-dessous.

Figure 3.1- Fenêtre du menu Déboguer

Windows - Ouvre la fenêtre Points d'arrêt dans l'EDI, qui donne accès à tous les points d'arrêt de la solution. Affiche la fenêtre de sortie dans le framework.

La fenêtre de sortie est un journal en cours d'exécution de nombreux messages émis par le framework, le compilateur et le débogueur. Par conséquent, ces informations ne s'appliquent pas seulement à la session de débogage, mais ouvrent également la fenêtre Interpréter dans le framework, qui vous permet d'exécuter les commandes :

démarrer le débogage - démarre l'application en mode débogage ;
attacher au processus - vous permet d'attacher un débogueur à un processus en cours d'exécution ( fichier exécutable). par exemple, si l'application s'exécute sans débogage, vous pouvez alors vous attacher à ce processus en cours d'exécution et commencer le débogage ;
Exceptions - ouvre la boîte de dialogue Exceptions, qui vous permet de choisir comment arrêter le débogueur pour chaque état exceptionnel ;
step with entry - lance l'application en mode débogage. pour la plupart des projets, choisir la commande step-in signifie appeler le débogueur sur la première ligne de l'application qui est exécutée. ainsi, vous pouvez saisir l'application à partir de la première ligne ;
étape de contournement - lorsque vous n'êtes pas dans une session de débogage, la commande d'étape de contournement démarre simplement l'application de la même manière que le ferait le bouton d'exécution ;
point d'arrêt - active ou désactive le point d'arrêt sur la ligne actuelle (active) du code de l'éditeur de texte. cette option est grisée s'il n'y a pas de fenêtre de code active dans le framework ;
créer un point d'arrêt - active la boîte de dialogue Créer un point d'arrêt vous permettant de spécifier le nom de la fonction pour laquelle vous souhaitez créer un point d'arrêt ;
supprimer tous les points d'arrêt - supprime tous les points d'arrêt de la solution actuelle ;
effacer toutes les indications de données - désactive (sans supprimer) tous les points d'arrêt de la solution actuelle ;
Options et paramètres - Abandonnez l'exécution lorsque des exceptions franchissent la limite du domaine d'application ou la limite entre le code managé et le code natif.

4 TEST DU MODULE LOGICIEL POUR UN SCÉNARIO SPÉCIFIQUE

Tests d'évaluation, également appelés « tests du système global »dont le but est de tester la conformité du programme aux exigences de base. Cette étape de test est particulièrement importante pour les produits logiciels.Comprend les types suivants :

tests d'utilisabilité - vérification cohérente de la conformité du produit logiciel et de sa documentation avec les principales dispositions des termes de référence ;
tester à des volumes maximum - vérifier les performances du programme sur les plus grandes quantités de données possibles, par exemple, des volumes de textes, des tableaux, un grand nombre de fichiers, etc.
tester à des charges maximales - vérifier l'exécution du programme pour la capacité de traiter une grande quantité de données reçues dans un court laps de temps;
tests d'utilisabilité - analyse des facteurs psychologiques qui surviennent lors de l'utilisation de logiciels ; ce test permet de déterminer si l'interface est conviviale, si la couleur ou l'accompagnement sonore est gênant, etc.;
tests de sécurité - vérification de la protection, par exemple, contre l'accès non autorisé aux informations ;
test de performance - détermination du débit pour une configuration et une charge données ;
tester les besoins en mémoire - déterminer les besoins réels en RAM et en mémoire externe ;
test de configuration matérielle - vérification des performances du logiciel sur différents matériels ;
test de compatibilité - vérification de la continuité des versions : dans les cas où la prochaine version du système modifie les formats de données, elle doit prévoir des convecteurs spéciaux permettant de travailler avec des fichiers créés la version précédente systèmes;
test de facilité d'installation - vérification de la facilité d'installation ;
tests de fiabilité - tests de fiabilité utilisant des modèles mathématiques ;
tests de récupération - tester la récupération de logiciels, tels qu'un système qui comprend une base de données, après des pannes matérielles et logicielles ;
test de maintenance - vérification des outils de maintenance inclus dans le logiciel ;
test de la documentation - une vérification approfondie de la documentation, par exemple, si la documentation contient des exemples, alors tous doivent être essayés ;
test de procédure - vérification des processus manuels supposés dans le système.

Naturellement, le but de toutes ces vérifications est de trouver des écarts avec les termes de référence. On pense que ce n'est qu'une fois tous les types de tests terminés que le produit logiciel peut être présenté à l'utilisateur ou pour être mis en œuvre. Cependant, dans la pratique, tous les types de tests d'évaluation ne sont généralement pas effectués, car ils sont très coûteux et prennent beaucoup de temps. En règle générale, pour chaque type de logiciel, sont effectués les types de tests les plus importants pour lui. Ainsi, les bases de données sont nécessairement testées à des volumes maximaux, et les systèmes en temps réel - à des charges maximales.

5 ENREGISTREMENT DE LA DOCUMENTATION SUR LE LOGICIEL

Le produit logiciel créé est destiné à effectuer des opérations arithmétiques sur des matrices.

Pour exécuter le programme, vous devez exécuter l'application.

Afin de créer des matrices, il est nécessaire d'entrer les dimensions de la matrice et de cliquer sur les boutons "Construire". Saisissez ensuite les données dans la matrice et sélectionnez l'action souhaitée.

Figure 5.1 - Application en cours d'exécution

Le programme a interface conviviale et offre la possibilité de résoudre facilement des matrices de dimensions arbitraires.

CONCLUSION

Au cours des travaux, une tâche individuelle a été réalisée :

analyse du sujet;
l'algorithme de solution choisi et développé est justifié ;
certaines technologies et certains environnements de programmation ;
le cadre de l'application a été construit et l'interface utilisateur a été conçue ;
le code du module logiciel a été développé ;
les outils de débogage utilisés lors des tests sont décrits ;
le module logiciel a été testé selon un scénario précis ;
ajouté un élément de menu avec une brève description de la façon de travailler avec le programme.

Les objectifs fixés ont été atteints.

LISTE DE RÉFÉRENCES

1 CyberForum [Ressource électronique] : http://CyberForum. ru

2 Développeur Microsoft [Documentation officielle Microsoft pour C #] ttps : // msdn. microsoft. com

3 http://programming-edu.ru/ C # Blog d'aide pour les débutants

ANNEXE A

Code de programme

MaMatrice. cs

en utilisant le système ;

en utilisant System.Linq ;

en utilisant System.Text ;

en utilisant System.Windows.Forms ;

Matrice d'espace de noms

Classe MaMatrice

Int [,] a = nouvel int;

// passer des valeurs

Public void Set (int i, int j, int znach)

A = znach ;

// une addition

Opérateur MyMatrix statique public + (Matrix matrix1, MyMatrix matrix2)

Pour (int i = 0; i< 3; i++)

Pour (int j = 0; j< 3; j++)

NouvelleMatrice.a = matrice1.a + matrice2.a;

Retour NewMatrix;

// sortie matricielle

Chaîne publique Visual (int i, int j)

Retourne a.ToString ();

// sortie tout à la fois. Xd

Public DataGridView FullVisual (DataGridView dt)

Pour (int i = 0; i< 3; i++)

Pour (int j = 0; j< 3; j++)

Dt.Lignes [j] .Cellules [i] .Valeur = a;

Retour dt;

// soustraire

Opérateur MyMatrix statique public - (Matrix Matrix1, MyMatrix matrix2)

MaMatrice NouvelleMatrice = nouvelle MaMatrice ();

Pour (int i = 0; i< 3; i++)

Pour (int j = 0; j< 3; j++)

NouvelleMatrice.a = matrice1.a - matrice2.a ;

Retour NewMatrix;

// transposition

Publique MyMatrix Trans ()

MaMatrice NouvelleMatrice = nouvelle MaMatrice ();

Pour (int i = 0; i< 3; i++)

Pour (int j = 0; j< 3; j++)

NouvelleMatrice.a = a;

Retour NewMatrix;

// multiplication

Opérateur MyMatrix statique public * (Matrix matrix1, MyMatrix matrix2)

MaMatrice NouvelleMatrice = nouvelle MaMatrice ();

Pour (int i = 0; i< 3; i++)

Pour (entier k = 0; k< 3; k++)

// entier a = 0;

Pour (int j = 0; j< 3; j++)

// a + = matrice1.a * matrice2.a;

NouvelleMatrice.a + = matrice1.a * matrice2.a;

//NouvelleMatrice.a = a;

Retour NewMatrix;

// remplir

Vide public Zapoln (grille DataGridView)

Pour (int i = 0; i< 3; i++)

Pour (int j = 0; j< 3; j++)

A = Convert.ToInt32 (grid.Rows [j] .Cells [i] .Value);

Form1.cs

en utilisant le système ;

en utilisant System.Collections.Generic ;

en utilisant System.ComponentModel ;

en utilisant System.Data;

en utilisant System.Drawing;

en utilisant System.Linq ;

en utilisant System.Text ;

en utilisant System.Windows.Forms ;

Matrice d'espace de noms

Classe partielle publique Form1 : Form

Formulaire public1 ()

InitializeComponent ();

Vide privé Form1_Load (expéditeur d'objet, EventArgs e)

Pour (int i = 0; i< 3; i++)

DataGridView1.Rows.Add ();

DataGridView2.Rows.Add ();

DataGridView3.Rows.Add ();

//dataGridView1.Rows [] [i] .Cells.Value = i.ToString ();

Private void button1_Click (expéditeur d'objet, EventArgs e)

MaMatrice matrice3 ;

Matrice3 = (matrice1 + matrice2) ;

Private void button2_Click (expéditeur d'objet, EventArgs e)

MaMatrice matrice1 = nouvelle MaMatrice ();

MaMatrice matrice2 = nouvelle MaMatrice ();

MaMatrice matrice3 ;

Matrix1.Zapoln (dataGridView1) ;

Matrix2.Zapoln (dataGridView2) ;

Matrix3 = (matrice1 - matrice2) ;

Matrix3.FullVisual (dataGridView3) ;

Private void button3_Click (expéditeur d'objet, EventArgs e)

MaMatrice matrice1 = nouvelle MaMatrice ();

MaMatrice matrice3 ;

Matrix1.Zapoln (dataGridView1) ;

Matrice3 = matrice1.Trans ();

Matrix3.FullVisual (dataGridView3) ;

Private void button4_Click (expéditeur d'objet, EventArgs e)

MaMatrice matrice1 = nouvelle MaMatrice ();

MaMatrice matrice2 = nouvelle MaMatrice ();

MaMatrice matrice3 ;

Matrix1.Zapoln (dataGridView1) ;

Matrix2.Zapoln (dataGridView2) ;

Matrix3 = (matrice1 * matrice2) ;

Matrix3.FullVisual (dataGridView3) ;

PAGE \ * FUSION FORMAT 3

J. Hughes, J. Micht. Une approche structurée de la programmation. - M. : Mir, 1980. - p. 29-71.

V. Toursky. Méthodologie de programmation. - M. : Mir, 1981.-- p.90-164.

E.A. Jougolev. Fondements technologiques de la programmation modulaire // Programmation, 1980, no. - pages 44-49.

R.C. Holt. Structure des programmes informatiques : Une enquête // Actes de l'IEEE, 1975, 63 (6). - p. 879-893.

G. Myers. Fiabilité du logiciel. - M. : Mir, 1980. - p. 92-113.

I. Pylé. ADA est le langage des systèmes embarqués. M. : Finances et statistiques, 1984. - p. 67-75.

M. Zelkovets, A. Shaw, J. Gannon. Principes de développement logiciel. - M. : Mir, 1982, p. 65-71.

A.L. Fuksman. Aspects technologiques de la création systèmes logiciels... M. : Statistiques, 1979. - p. 79-94.

Cours 8. Développement d'un module logiciel
La procédure de développement d'un module logiciel. Programmation structurée et détails étape par étape. Comprendre le pseudo-code. Contrôle du module de programme.
8.1. La procédure de développement d'un module logiciel.
Lors du développement d'un module logiciel, il est conseillé de respecter l'ordre suivant :
étudier et vérifier la spécification du module, choisir la langue
la programmation;
choix de l'algorithme et de la structure des données ;
programmation de modules;
polir le texte du module ;
vérification des modules ;
compilation du module.
La première étape du développement d'un module logiciel est dans une large mesure un contrôle contigu de la structure du programme par le bas : en étudiant la spécification d'un module, le développeur doit s'assurer qu'elle est claire pour lui et suffisante pour le développement de ce module. A l'issue de cette étape, un langage de programmation est sélectionné : bien que le langage de programmation puisse déjà être prédéfini pour l'ensemble du système logiciel, dans certains cas (si le système de programmation le permet) un autre langage peut être choisi plus adapté à la mise en œuvre de ce module (par exemple, le langage assembleur).
Lors de la deuxième étape du développement d'un module logiciel, il est nécessaire de savoir si des algorithmes sont déjà connus pour résoudre le problème posé et ou s'en rapprochent. Et si un algorithme approprié est trouvé, il est alors conseillé de l'utiliser. Le choix des structures de données appropriées qui seront utilisées lorsqu'un module exécute ses fonctions prédétermine largement la logique et les indicateurs de qualité du module en cours de développement, il doit donc être considéré comme une décision très responsable.
A la troisième étape, le texte du module est construit dans le langage de programmation sélectionné. L'abondance de toutes sortes de détails qui doivent être pris en compte lors de la mise en œuvre des fonctions spécifiées dans la spécification du module peut facilement conduire à la création d'un texte très confus contenant beaucoup d'erreurs et d'inexactitudes. Trouver des erreurs dans un tel module et y apporter les modifications nécessaires peut prendre beaucoup de temps. Par conséquent, il est très important d'utiliser une discipline de programmation technologiquement solide et éprouvée dans la pratique pour construire le texte du module. Pour la première fois, Dijkstra a attiré l'attention sur ce point, en formulant et en justifiant les principes de base de la programmation structurée. De nombreuses disciplines de programmation largement utilisées dans la pratique sont basées sur ces principes. La discipline la plus courante est le raffinement incrémentiel, qui est discuté en détail dans les sections 8.2 et 8.3.
L'étape suivante du développement du module est associée à la mise en forme complète du texte du module conformément à la spécification de la qualité du logiciel. Lors de la programmation d'un module, le développeur se concentre sur la mise en œuvre correcte des fonctions du module, laissant des commentaires incomplets et permettant certaines violations des exigences du style du programme. Lors du polissage du texte du module, il doit éditer les commentaires dans le texte et, éventuellement, y inclure des commentaires supplémentaires afin d'assurer les primitives de qualité requises. Dans le même but, le texte du programme est édité pour répondre aux exigences stylistiques.
L'étape de vérification du module est une vérification manuelle de la logique interne du module avant de le déboguer (à l'aide de son exécution sur un ordinateur), met en œuvre le principe général formulé pour la technologie de programmation discutée, sur la nécessité de contrôler les décisions prises à chaque étape de développement de logiciels (voir leçon 3). Les méthodes de validation de module sont décrites à la section 8.4.
Enfin, la dernière étape du développement d'un module consiste à terminer la vérification du module (à l'aide du compilateur) et à procéder au débogage du module.
8.2. Programmation structurée.
Lors de la programmation d'un module, il convient de garder à l'esprit que le programme doit être compréhensible non seulement pour un ordinateur, mais également pour une personne : à la fois le développeur du module et les personnes qui vérifient le module et les textualistes qui préparent les tests pour le débogage. le module, et les mainteneurs du PS qui apportent les modifications requises au module devront démonter à plusieurs reprises la logique du module. Il existe suffisamment d'outils dans les langages de programmation modernes pour obscurcir cette logique autant que vous le souhaitez, ainsi, rendent le module difficile à comprendre pour les humains et, par conséquent, le rendent peu fiable ou difficile à maintenir. Par conséquent, il est nécessaire de prendre des mesures pour sélectionner les outils de langage appropriés et suivre une discipline de programmation spécifique. Pour la première fois, Dijkstra a attiré l'attention sur cela et a proposé de construire un programme comme une composition de plusieurs types de structures de contrôle (structures), ce qui peut grandement augmenter la compréhension de la logique du programme. La programmation utilisant uniquement de telles constructions était appelée structurelle.
Les constructions de base de la programmation structurée sont : le suivi, le branchement et la répétition (voir Figure 8.1). Les composants de ces constructions sont des opérateurs généralisés (nœuds de traitement) S, S1, S2 et une condition (prédicat) P. Un opérateur généralisé peut être soit un opérateur simple du langage de programmation utilisé (opérateurs d'affectation, d'entrée, de sortie, d'appel de procédure) , ou un fragment de programme , qui est une composition de constructions de contrôle de programmation structurées de base. Il est essentiel que chacune de ces structures n'ait qu'une entrée et une sortie pour le contrôle. Ainsi, l'opérateur généralisé n'a qu'une entrée et qu'une sortie.
Il est également très important que ces constructions soient déjà des objets mathématiques (ce qui, en substance, explique la raison du succès de la programmation structurée). Il est prouvé que pour chaque programme non structuré, il est possible de construire un programme structuré fonctionnellement équivalent (c'est-à-dire résolvant le même problème). Pour les programmes structurés, vous pouvez prouver certaines propriétés mathématiquement, ce qui vous permet de détecter certaines erreurs dans le programme. Une conférence distincte sera consacrée à cette question.
La programmation structurée est parfois aussi appelée "programmation sans GO TO". Cependant, le point n'est pas dans l'instruction GO TO, mais dans son utilisation désordonnée. Très souvent, lors de l'implémentation de la programmation structurée dans certains langages de programmation (par exemple, en FORTRAN), l'opérateur de transition (GO TO) est utilisé pour implémenter des constructions structurées sans compromettre les principaux avantages de la programmation structurée. Ce sont précisément les opérateurs de saut « non structurels » qui perturbent le programme, en particulier le saut vers l'opérateur situé dans le texte du module au-dessus (plus tôt) de l'opérateur de saut en cours d'exécution. Néanmoins, une tentative d'éviter l'opérateur de branche dans certains cas simples peut conduire à des programmes structurés trop lourds, ce qui n'améliore pas leur clarté et contient le risque d'erreurs supplémentaires dans le texte du module. Par conséquent, nous pouvons recommander d'éviter l'utilisation de l'opérateur de saut dans la mesure du possible, mais pas au détriment de la clarté du programme.
Des cas utiles d'utilisation de l'opérateur de saut incluent la sortie d'une boucle ou d'une procédure par une condition spéciale qui "en avance" termine le travail d'un cycle donné ou d'une procédure donnée, c'est-à-dire mettant fin au travail d'une unité structurelle (opérateur généralisé) et ne violant ainsi que localement la structuration du programme. De grandes difficultés (et la complication de la structure) sont causées par la mise en œuvre structurelle de la réaction à l'émergence de situations exceptionnelles (souvent erronées), car cela nécessite non seulement une sortie précoce de l'unité structurelle, mais aussi le traitement nécessaire (exclusion) de cette situation (par exemple, la délivrance d'une information de diagnostic adaptée). Le gestionnaire d'exceptions peut se trouver à n'importe quel niveau de la structure du programme et il est accessible à partir de différents niveaux inférieurs. La mise en œuvre « non structurelle » suivante de la réaction aux situations exceptionnelles est tout à fait acceptable du point de vue technologique. Des gestionnaires d'exceptions sont placés à la fin de telle ou telle unité structurelle, et chacun de ces gestionnaires est programmé de telle sorte qu'après avoir terminé son travail, il quitte l'unité structurelle à la fin de laquelle il est placé. L'appel à un tel gestionnaire est effectué par l'opérateur de transition à partir de l'unité structurelle donnée (y compris toute unité structurelle imbriquée).
8.3. Détaillant étape par étape et le concept de pseudocode.
La programmation structurée fournit des directives sur la façon dont le texte du module doit être. La question se pose de savoir comment un programmeur doit agir pour construire un tel texte. Parfois, la programmation d'un module commence par la construction de son schéma fonctionnel, qui décrit la logique de son fonctionnement. mais technologie moderne la programmation ne recommande pas de faire cela. Si les schémas fonctionnels permettent de représenter très clairement la logique de fonctionnement du module, lorsqu'ils sont encodés dans un langage de programmation, une source d'erreurs bien particulière apparaît : la mise en correspondance de structures essentiellement bidimensionnelles, telles que les schémas fonctionnels, à un le texte linéaire représentant un module contient le danger de déformer la logique de fonctionnement du module, d'autant plus que psychologiquement il est assez difficile de maintenir un haut niveau d'attention lors de son réexamen. Une exception peut être le cas lorsqu'un éditeur graphique est utilisé pour construire des diagrammes et qu'ils sont formalisés de manière à générer automatiquement du texte dans un langage de programmation à partir de ceux-ci (comme par exemple, cela peut être fait en technologie R).
En tant que méthode principale de construction du texte du module, la technologie de programmation moderne recommande des détails étape par étape. L'essence de cette méthode est de décomposer le processus de développement d'un texte de module en un certain nombre d'étapes. À la première étape, le schéma général du fonctionnement du module est décrit sous une forme textuelle linéaire observable (c'est-à-dire en utilisant de très grands concepts), et cette description n'est pas complètement formalisée et est axée sur la perception humaine. Sur chaque L'étape suivante l'un des concepts est raffiné et détaillé (nous l'appellerons raffiné), utilisé (en règle générale, pas formellement) dans toute description développée dans l'une des étapes précédentes. À la suite de cette étape, une description du concept raffiné sélectionné est créée soit en termes de langage de programmation de base (c'est-à-dire le module choisi pour la présentation), soit sous la même forme que dans la première étape en utilisant de nouveaux concepts raffinés. Ce processus se termine lorsque tous les concepts raffinés sont finalement exprimés dans le langage de programmation sous-jacent. La dernière étape consiste à obtenir le texte du module dans le langage de programmation de base en remplaçant toutes les occurrences des concepts raffinés par leurs descriptions données et en exprimant toutes les occurrences de constructions de programmation structurées au moyen de ce langage de programmation.
Le détail pas à pas est associé à l'utilisation d'un langage partiellement formalisé pour représenter les descriptions spécifiées, appelé pseudocode. Ce langage vous permet d'utiliser toutes les constructions de programmation structurées qui sont formalisées, ainsi que des fragments informels en langage naturel pour représenter des opérateurs et des conditions génériques. Les fragments correspondants dans le langage de programmation de base peuvent également être spécifiés en tant qu'opérateurs et conditions généralisés.
La description principale en pseudocode peut être considérée comme la conception externe du module dans le langage de programmation de base, qui
le début d'un module dans la langue de base, c'est-à-dire la première phrase ou titre (spécification) de ce module ;
section (ensemble) de descriptions dans le langage de base, et au lieu de descriptions de procédures et de fonctions - uniquement leur conception externe;
désignation informelle de la séquence d'opérateurs du corps du module comme un opérateur généralisé (voir ci-dessous), ainsi que désignation informelle de la séquence d'opérateurs du corps de chaque description d'une procédure ou d'une fonction comme un opérateur généralisé ;
la dernière phrase (fin) du module dans la langue de base.
L'apparence d'une description d'une procédure ou d'une fonction est similaire. Cependant, si vous suivez Dijkstra, il est préférable de présenter la section des descriptions ici avec une désignation informelle, la rendant détaillée sous la forme d'une description séparée.
La désignation informelle d'un opérateur généralisé en pseudocode est faite en langage naturel par une phrase arbitraire qui en décrit le contenu. La seule exigence formelle pour la conception d'une telle désignation est la suivante : cette proposition doit occuper une ou plusieurs lignes graphiques (imprimées) dans son intégralité et se terminer par un point.
Pour chaque opérateur généralisé informel, une description distincte doit être créée qui exprime la logique de son fonctionnement (détaillant son contenu) en utilisant la composition des structures de base de la programmation structurée et d'autres opérateurs généralisés. Le titre d'une telle description doit être la désignation informelle de l'opérateur générique détaillé. Les structures de base de la programmation structurée peuvent être représentées sous la forme suivante (voir Fig. 8.2). Ici, la condition peut être explicitement définie dans le langage de programmation de base en tant qu'expression booléenne, ou elle peut être représentée de manière informelle en langage naturel par un fragment décrivant la signification de cette condition. Dans ce dernier cas, une description séparée doit être créée détaillant cette condition, indiquant la désignation de cette condition (un fragment en langage naturel) comme titre.
Riz. 8.2. Constructions de base de la programmation structurée en pseudocode.
Riz. 8.3. Cas particuliers de l'opérateur de transition en tant qu'opérateur généralisé.
En tant qu'opérateur généralisé sur le pseudocode, on peut utiliser les cas particuliers ci-dessus de l'opérateur de transition (voir Fig. 8.3). Une séquence de gestionnaires d'exceptions (exceptions) est spécifiée à la fin d'un module ou d'une description d'une procédure (fonction). Chacun de ces gestionnaires ressemble à ceci :
EXCEPTION nom_exception
opérateur_générique
TOUTES LES EXCEPTIONS
La différence entre un gestionnaire d'exceptions et une procédure sans paramètres est la suivante : après l'exécution de la procédure, le contrôle revient à l'opérateur suite à l'appel qui lui a été fait, et après l'exécution de l'exception, le contrôle revient à l'opérateur suite à l'appel au module ou procédure (fonction), à la fin de laquelle ( laquelle) cette exception est affichée.
Il est recommandé à chaque étape de détailler de créer une description suffisamment significative, mais facilement visible (descriptive), afin qu'elle soit placée sur une page de texte. Typiquement, cela signifie qu'une telle description doit être une composition de cinq ou six constructions de programmation structurées. Il est également recommandé de placer les structures imbriquées avec un décalage vers la droite de plusieurs positions (voir Fig. 8.4). De ce fait, il est possible d'obtenir une description de la logique de travail en termes de clarté, ce qui est assez compétitif avec les schémas fonctionnels, mais présente un avantage non négligeable - la linéarité de la description est préservée.

SUPPRIMER LES ENREGISTREMENTS DU FICHIER AVANT LE PREMIER,

FILTRE SATISFAISANT :

SET FICHIER DEBUT.

SI L'ENTRÉE RÉGULIÈRE SATISFAIT

FILTRER À

SUPPRIMER L'ENTRÉE RÉGULIÈRE DU FICHIER.

TOUS SI

AU REVOIR

SI LES ENREGISTREMENTS NE SONT PAS SUPPRIMÉS ALORS

IMPRIMER « LES ENTRÉES NE SONT PAS SUPPRIMÉES ».

IMPRIMER "SUPPRIMÉ n ENREGISTREMENTS".

TOUS SI

Riz. 8.4. Un exemple d'une étape d'exploration en pseudocode.

Dijkstra est parfois crédité de l'idée de détailler étape par étape. Cependant, Dijkstra a proposé une méthode fondamentalement différente de construction du texte du module, qui nous semble plus profonde et plus prometteuse. Tout d'abord, parallèlement à la clarification des opérateurs, il a proposé d'affiner (détailler) progressivement (pas à pas) les structures de données utilisées. Deuxièmement, à chaque étape, il proposait de créer une machine virtuelle pour détailler et, dans ses termes, de détailler tous les concepts raffinés pour lesquels cette machine permet de le faire. Ainsi, Dijkstra a proposé, en substance, de détailler par couches horizontales, ce qui est un transfert de son idée de systèmes en couches (voir leçon 6) au niveau de développement de modules. Cette méthode de développement de modules est actuellement prise en charge par les packages de langage ADA et les outils de programmation orientés objet.
8.4. Contrôle du module de programme.
Les méthodes suivantes de contrôle du module logiciel sont appliquées :
vérification statique du texte du module ;
suivi de bout en bout ;
preuve des propriétés du module de programme.
Lors de la vérification statique du texte d'un module, ce texte est lu du début à la fin afin de trouver des erreurs dans le module. Habituellement, pour un tel contrôle, en plus du développeur du module, un ou même plusieurs programmeurs sont impliqués. Il est recommandé que les erreurs détectées lors d'un tel contrôle ne soient pas corrigées immédiatement, mais à la fin de la lecture du texte du module.
Le suivi est un type de contrôle de module dynamique. Il implique également plusieurs programmeurs qui font défiler manuellement l'exécution du module (opérateur par opérateur dans la séquence qui découle de la logique du module) sur un certain ensemble de tests.
Le prochain cours est consacré à la démonstration des propriétés des programmes. Il faut seulement noter ici que cette méthode est encore très rarement utilisée.
Littérature pour le cours 8.
8.2. E. Dijkstra. Notes sur la programmation structurée // W. Dahl, E. Dijkstra, K. Hoore. Programmation structurée. - M. : Mir, 1975.-- S. 24-97.
8.3. N. Virt. Programmation systématique. - M. : Mir, 1977.-- S. 94-164.
Cours 9. Preuve des propriétés du programme
Le concept de justification du programme. Formalisation des propriétés du programme, triade de Hoor. Règles de définition des propriétés de l'opérateur d'affectation, des opérateurs conditionnels et composés. Règles pour établir les propriétés d'un opérateur de boucle, le concept d'invariant de boucle. Complétude de l'exécution du programme.
9.1. Justification des programmes. Formalisation des propriétés du programme.
Pour améliorer la fiabilité du logiciel, il est très utile de fournir aux programmes des informations supplémentaires, grâce auxquelles vous pouvez augmenter considérablement le niveau de contrôle du logiciel. Ces informations peuvent être spécifiées sous la forme d'énoncés informels ou formalisés liés à divers fragments de programmes. Nous appellerons de telles déclarations la justification du programme. Les justifications informelles des programmes peuvent, par exemple, expliquer les motifs de certaines décisions, ce qui peut grandement faciliter la recherche et la correction des erreurs, ainsi que l'étude des programmes tout en les maintenant. Les justifications formalisées permettent de prouver certaines propriétés des programmes à la fois manuellement et de les contrôler (définir) automatiquement.
L'un des concepts actuellement utilisés pour la justification formelle des programmes est l'utilisation des triades de Hoor. Soit S un opérateur généralisé sur l'environnement d'information IS, P et Q - des prédicats (instructions) sur cet environnement. Alors la notation (P) S (Q) est appelée triade de Hoor, dans laquelle le prédicat P est appelé la précondition, et le prédicat Q est appelé la postcondition par rapport à l'opérateur S. L'opérateur (en particulier, le programme) S est dit avoir la propriété (P) S (Q) si à chaque fois qu'avant l'exécution de l'opérateur S le prédicat P est vrai, après l'exécution de cet opérateur S le prédicat Q sera vrai.
Exemples simples de propriétés de programme :
(9.1) (n = 0) n : = n + 1 (n = 1),
(9.2) (n
(9.3) (n
(9.4) (n > 0) p : = 1 ; m : = 1 ;
PENDANT que m / = n FAIRE
AU REVOIR
Pour prouver la propriété du programme S, on utilise les propriétés des opérateurs simples du langage de programmation (ici on se limitera à l'opérateur vide et à l'opérateur d'affectation) et les propriétés des structures de contrôle (compositions), à l'aide desquelles un programme est construit à partir d'opérateurs simples (nous nous limiterons ici à trois compositions de base de programmation structurée, voir huitième leçon). Ces propriétés sont généralement appelées règles de vérification de programme.
9.2. Propriétés des opérateurs simples.
Pour un opérateur vide, ce qui suit est valable
Théorème 9.1. Soit P un prédicat sur l'environnement d'information. Alors la propriété (P) (P) est vérifiée.
La preuve de ce théorème est évidente : un opérateur vide ne change pas l'état de l'environnement d'information (conformément à sa sémantique), donc sa précondition reste vraie même après son exécution.
L'opérateur d'affectation satisfait
Théorème 9.2. Soit l'environnement d'informations IS composé de la variable X et du reste de l'environnement d'informations RIS :
Puis la propriété
(Q (F (X, RIS), RIS)) X : = F (X, RIS) (Q (X, RIS)),
où F (X, RIS) est une fonction à valeur unique, Q est un prédicat.
Preuve. Soit le prédicat Q (F (X0, RIS0), RIS0) avant l'exécution de l'opérateur d'affectation, où (X0, RIS0) est un état arbitraire de l'environnement d'information IS, puis après l'exécution de l'opérateur d'affectation le prédicat Q (X, RIS) sera vrai, alors comment X obtiendra la valeur F (X0, RIS0) et l'état RIS n'est pas modifié par cette instruction d'affectation, et donc après l'exécution de cette instruction d'affectation dans ce cas
Q (X, RIS) = Q (F (X0, RIS0), RIS0).
Du fait de l'arbitraire du choix de l'état de l'environnement informationnel, le théorème est démontré.
L'exemple 9.1 est un exemple de la propriété d'un opérateur d'affectation.
9.3. Propriétés des structures de base de la programmation structurée.
Considérons maintenant les propriétés des structures de base de la programmation structurée : succession, embranchement et répétition.
Les propriétés de succession s'expriment par
Théorème 9.3. Soit P, Q et R des prédicats sur l'environnement d'information, et S1 et S2 des opérateurs généralisés avec les propriétés
(P) S (Q) et (Q) S2 (R).
Alors pour l'opérateur composé
S1 ; S2<.blockquote>
la propriété détient
(P) S1 ; S2 (D).
Preuve. Soit le prédicat P vrai pour un certain état de l'environnement d'information avant l'exécution de l'opérateur S1. Ensuite, en vertu de la propriété de l'opérateur S1, après son exécution, le prédicat Q sera vrai. Donc, après l'exécution de l'opérateur S2, de par sa propriété, le prédicat R sera vrai, et comme l'opérateur S2 termine l'exécution de l'opérateur composite (conformément à sa sémantique), le prédicat R sera vrai après l'exécution de cet opérateur composite, qu'il fallait prouver.
Par exemple, si les propriétés (9.2) et (9.3) sont vérifiées, alors il a
emplacement et propriété
(n
La propriété de branchement exprime ce qui suit
Théorème 9.4. Soit P, Q et R des prédicats sur l'environnement d'information, et S1 et S2 des opérateurs généralisés avec les propriétés
(P, Q) S1 (R) et (`P, Q) S2 (R).
Alors pour l'opérateur conditionnel
SI P ALORS S1 SINON S2 TOUS SI
la propriété détient
(Q) SI P ALORS S1 SINON S2 TOUS SI (R).
Preuve. Soit le prédicat Q vrai pour un certain état de l'environnement d'information avant l'exécution de l'opérateur conditionnel. Si le prédicat P est également vrai, alors l'exécution de l'opérateur conditionnel conformément à sa sémantique est réduite à l'exécution de l'opérateur S1. Grâce aux propriétés de l'opérateur S1, après son exécution (et dans ce cas, après l'exécution de l'opérateur conditionnel), le prédicat R sera vrai.Si, avant l'exécution de l'opérateur conditionnel, le prédicat P est faux (et Q est toujours vrai), alors l'exécution de l'opérateur conditionnel conformément à sa sémantique se réduit à l'exécution de l'opérateur S2. En vertu de la propriété de l'opérateur S2, après son exécution (et dans ce cas - et après l'exécution de l'opérateur conditionnel), le prédicat R sera vrai, ainsi le théorème est complètement démontré.
Avant de passer à la propriété de la construction de répétition, il convient de noter qu'elle est utile pour
Théorème 9.5. Soit P, Q, P1 et Q1 des prédicats sur l'environnement d'information pour lequel les implications sont valables
P1 => P et Q => Q1,
et laissez la propriété (P) S (Q) vraie pour un opérateur S. Alors la propriété (P1) S (Q1) est vraie.
Ce théorème est aussi appelé théorème d'affaiblissement des propriétés.
Preuve. Soit le prédicat P1 vrai pour un état de l'environnement d'information avant l'exécution de l'opérateur S. Alors le prédicat P sera aussi vrai (en vertu de l'implication P1 => P). Par conséquent, grâce à la propriété de l'opérateur S, après son exécution, le prédicat Q sera vrai, et donc le prédicat Q1 (d'après l'implication Q => Q1). Cela prouve le théorème.
La propriété de répétition exprime ce qui suit
Théorème 9.6. Soit I, P, Q et R des prédicats sur l'environnement d'information pour lequel les implications sont valables
P => I et (I, `Q) => R,
et soit S un opérateur généralisé de propriété (I) S (I).
Alors pour l'opérateur de boucle
ALORS QUE Q FAIT TOUT PENDANT
la propriété détient
(P) PENDANT QUE Q FAIT TOUT ENCORE (R).
Le prédicat I est appelé l'invariant de l'opérateur cycle.
Preuve. Pour prouver ce théorème, il suffit de prouver la propriété
(I) PENDANT QU'Q FAIT TOUT PENDANT (I, `Q)
(par le théorème 9.5 sur la base des implications dans les conditions de ce théorème). Soit le prédicat I vrai pour un état de l'environnement d'information avant l'exécution de l'opérateur de cycle. Si, dans ce cas, le prédicat Q est faux, alors l'opérateur de cycle sera équivalent à l'opérateur vide (conformément à sa sémantique ) et, d'après le théorème 9.1, après l'exécution de l'opérateur cycle, l'énoncé (I , `Q). Si, avant l'exécution de l'opérateur cycle, le prédicat Q est vrai, alors l'opérateur cycle, conformément à sa sémantique, peut être représenté comme un opérateur composé S ; ALORS QUE Q FAIT TOUT PENDANT
En vertu de la propriété de l'opérateur S, après son exécution, le prédicat I sera vrai, et une situation initiale se présente pour prouver la propriété de l'opérateur cycle : le prédicat I est vrai avant l'exécution de l'opérateur cycle, mais déjà pour un autre (modifié) état de l'environnement d'information (pour lequel le prédicat Q peut être vrai ou faux). Si l'exécution de l'opérateur de cycle se termine, alors en appliquant la méthode d'induction mathématique, en un nombre fini d'étapes, nous arriverons à une situation où l'énoncé (I, `Q) sera vrai avant son exécution. Et dans ce cas, comme cela a été prouvé ci-dessus, cette déclaration sera également vraie après l'exécution de l'opérateur de boucle. Le théorème est démontré.
Par exemple, l'opérateur de boucle de l'exemple (9.4) a la propriété
m : = m + 1 ; p : = p * m
TOUT ENCORE (p = n.!}
Ceci résulte du théorème 9.6, puisque l'invariant de cet opérateur de cycle est le prédicat p = m! et les implications sont vraies (n> 0, p = 1, m = 1) => p = m ! et (p = m !, m = n) => p = n!
9.4. Complétude de l'exécution du programme.
L'une des propriétés du programme, qui peut nous intéresser, afin d'éviter d'éventuelles erreurs dans le SS, est son exhaustivité, c'est-à-dire son caractère complet. l'absence de bouclage avec l'une ou l'autre des données sources. Dans les programmes structurés que nous avons considérés, seul le construit de répétition peut être source de bouclage. Par conséquent, pour prouver la complétude d'un programme, il suffit de pouvoir prouver la terminaison d'un opérateur de cycle. Ce qui suit est utile pour cela.
Théorème 9.7. Soit F une fonction entière qui dépend de l'état de l'environnement informationnel et satisfait aux conditions suivantes :
(1) si le prédicat Q est vrai pour un état donné de l'environnement d'information, alors sa valeur est positive ;
(2) il diminue lorsque l'état de l'environnement d'information change à la suite de l'exécution de l'opérateur S.
Ensuite, l'exécution de l'opérateur de boucle
LORSQUE Q DO S TOUT PENDANT que se termine.
Preuve. Soit est l'état de l'environnement informationnel avant l'exécution de l'opérateur cycle et soit F (est) = k. Si le prédicat Q (est) est faux, alors l'exécution de l'instruction de boucle se termine. Si Q (is) est vrai, alors par l'hypothèse du théorème k> 0. Dans ce cas, l'instruction S sera exécutée une ou plusieurs fois. Après chaque exécution de l'opérateur S, selon l'hypothèse du théorème, la valeur de la fonction F diminue, et puisqu'avant l'exécution de l'opérateur S le prédicat Q doit être vrai (selon la sémantique de l'opérateur cycle), la valeur de la fonction F à cet instant doit être positive (selon les conditions du théorème). Par conséquent, en raison de la valeur entière de la fonction F, l'opérateur S dans cette boucle peut être exécuté plus de k fois. Le théorème est démontré.
Par exemple, pour l'exemple de l'opérateur cycle considéré ci-dessus, les conditions du théorème 9.7 sont satisfaites par la fonction f (n, m) = n-m. Puisqu'avant d'exécuter l'opérateur de boucle m = 1, le corps de cette boucle sera exécuté (n-1) fois, c'est-à-dire cette instruction de boucle se termine.
9.5. Un exemple de preuve d'une propriété d'un programme.
Sur la base des règles éprouvées de vérification de programme, il est possible de prouver les propriétés de programmes constitués d'opérateurs d'affectation et d'opérateurs vides et en utilisant les trois principales compositions de la programmation structurée. Pour ce faire, en analysant la structure du programme et en utilisant ses pré- et post-conditions spécifiées, il est nécessaire d'appliquer une règle de vérification appropriée à chaque étape de l'analyse. Dans le cas de l'utilisation d'une composition de répétition, vous devrez choisir un invariant de boucle adapté.
A titre d'exemple, démontrons la propriété (9.4). Cette preuve comprendra les étapes suivantes.
(Étape 1). n> 0 => (n> 0, p - tout, m - tout).
(Étape 2). Se produit
(n> 0, p - tout, m - tout) p: = 1 (n> 0, p = 1, m - tout).
Par le théorème 9.2.
(Étape 3). Se produit
(n> 0, p = 1, m - tout) m : = 1 (n> 0, p = 1, m = 1).
Par le théorème 9.2.
(Étape 4). Se produit
(n> 0, p - tout, m - tout) p : = 1; m : = 1 (n > 0, p = 1, m = 1).
Par le théorème 9.3, au vu des résultats des étapes 2 et 3.
Montrons que le prédicat p = m! est un invariant de cycle, c'est-à-dire (p = m m:=m+1; p:=p*m {p=m!}.!}
(Étape 5). Il a lieu (p = m m:=m+1 {p=(m-1)!}.!}
D'après le théorème 9.2, si l'on représente la précondition sous la forme (p = ((m + 1) -1).!}
(Étape 6). Il a lieu (p = (m-1) p:=p*m {p=m!}.!}
D'après le théorème 9.2, si l'on représente la précondition sous la forme (p * m = m.!}
(Étape 7). L'invariant de cycle tient
(p = m m:=m+1; p:=p*m {p=m!}.!}
Par le théorème 9.3, au vu des résultats des étapes 5 et 6.
(Étape 8). Se produit
(n> 0, p = 1, m = 1) ALORS QUE m / = n FAIRE
m : = m + 1 ; p : = p * m
TOUT ENCORE (p = n.!}
D'après le théorème 9.6, grâce au résultat de l'étape 7 et en gardant à l'esprit que (n> 0, p = 1, m = 1) => p = m !; (p = m !, m = n) => p = n !.
(Étape 9). Se produit
(n> 0, p - tout, m - tout) p : = 1; m : = 1 ;
PENDANT que m / = n FAIRE
m : = m + 1 ; p : = p * m
TOUT ENCORE (p = n.!}
Par le théorème 9.3, au vu des résultats des étapes 3 et 8.
(Étape 10). La propriété (9.4) tient par le théorème 9.5 par les résultats des étapes 1 et 9.
Littérature pour le cours 9.
9.1. S.A. Abramov. Éléments de programmation. - M. : Nauka, 1982.S. 85-94.
9.2. M. Zelkovets, A. Shaw, J. Gannon. Principes de développement logiciel. - M. : Mir, 1982.S. 98-105.
Cours 10. Tester et déboguer des logiciels
Concepts de base. Stratégie de conception de tests. Commandes de débogage. Débogage et test hors ligne d'un module logiciel. Débogage et test complexes d'outils logiciels.
10.1. Concepts de base.
Le débogage d'un système logiciel est une activité visant à détecter et à corriger les erreurs dans un système logiciel à l'aide des processus d'exécution de ses programmes. Le test d'un système logiciel est le processus d'exécution de ses programmes sur un certain ensemble de données, pour lequel le résultat de l'application est connu à l'avance ou les règles de comportement de ces programmes sont connues. L'ensemble de données spécifié est appelé un test ou simplement un test. Ainsi, le débogage peut être représenté sous la forme de répétitions multiples de trois processus : le test, à la suite duquel la présence d'une erreur dans le système logiciel peut être constatée, trouver la place de l'erreur dans les programmes logiciels et la documentation du logiciel, et éditer les programmes et la documentation afin d'éliminer l'erreur détectée. En d'autres termes:
Débogage = Test + Recherche d'erreurs + Édition.
Dans la littérature étrangère, le débogage est souvent compris uniquement comme un processus de recherche et de correction des erreurs (sans test), dont le fait est établi lors des tests. Les tests et le débogage sont parfois considérés comme synonymes. Dans notre pays, les tests sont généralement inclus dans le concept de débogage, nous suivrons donc la tradition établie. Cependant, l'examen conjoint de ces processus dans cette leçon rend l'écart indiqué moins significatif. Il convient toutefois de noter que les tests sont également utilisés dans le cadre du processus d'attestation de PF (voir leçon 14).
10.2. Principes et types de débogage.
Le succès du débogage est largement déterminé par l'organisation rationnelle des tests. Lors du débogage, ce sont principalement les erreurs détectées dans le système logiciel qui sont détectées lors des tests et sont éliminées. Comme déjà noté, les tests ne peuvent pas prouver l'exactitude du SE, au mieux, ils peuvent démontrer la présence d'une erreur dans celui-ci. En d'autres termes, il ne peut être garanti qu'en testant le système logiciel avec un ensemble de tests réalisables dans la pratique, il soit possible d'établir la présence de chaque erreur dans le système logiciel. Par conséquent, deux tâches se posent. La première consiste à préparer un tel ensemble de tests et à leur appliquer le logiciel afin d'y trouver le plus d'erreurs possible. Cependant, plus le processus de test (et le débogage en général) dure longtemps, plus le coût du logiciel augmente. D'où la deuxième tâche: déterminer le moment de la fin du débogage du système logiciel (ou de son composant séparé). Un signe de la possibilité de terminer le débogage est l'exhaustivité de la couverture des tests passés par le PS (c'est-à-dire les tests auxquels le PS est appliqué) de nombreuses situations différentes qui surviennent lors de l'exécution des programmes PS, et la manifestation relativement rare d'erreurs dans le PS dans le dernier segment du processus de test. Ce dernier est déterminé conformément au degré requis de fiabilité du PS spécifié dans sa spécification de qualité.
Pour optimiser la suite de tests, c'est-à-dire Pour préparer un ensemble de tests qui permettrait, pour un nombre donné de tests (ou pour un intervalle de temps donné alloué aux tests), de détecter un plus grand nombre d'erreurs, il faut, dans un premier temps, planifier cet ensemble à l'avance et, d'autre part, d'utiliser une stratégie de planification rationnelle (conception) des tests. La conception des tests peut commencer dès que l'étape est terminée description externe PS. Il existe différentes approches pour développer une stratégie de conception de tests, qui peuvent être placées graphiquement de manière conditionnelle (voir Figure 9.1) entre les deux approches extrêmes suivantes. L'approche extrême gauche est que les tests sont conçus uniquement sur la base de l'étude des spécifications du système logiciel (description externe, description de l'architecture et spécification du module). Dans ce cas, la structure des modules n'est en aucun cas prise en compte, c'est-à-dire ils sont considérés comme des boîtes noires. En fait, une telle approche nécessite une énumération complète de tous les ensembles de données d'entrée, car lorsque seule une partie de ces ensembles est utilisée comme tests, certaines parties des programmes PS peuvent ne fonctionner sur aucun test et, par conséquent, les erreurs qu'ils contiennent. n'apparaîtra pas. Cependant, tester des systèmes logiciels avec un ensemble complet d'ensembles de données d'entrée est pratiquement impossible. La bonne approche extrême est que les tests sont conçus sur la base de l'étude des textes des programmes afin de tester tous les modes d'exécution de chaque logiciel. Si l'on prend en compte la présence de boucles avec un nombre variable de répétitions dans les programmes, alors il peut y avoir un très grand nombre de manières différentes d'exécuter des programmes PS, de sorte que leur test sera également pratiquement impraticable.
La stratégie de conception de test optimale est située dans l'intervalle entre ces approches extrêmes, mais plus près du bord gauche. Il comprend la conception d'une partie significative des tests selon le cahier des charges, sur la base des principes : pour chaque fonction ou opportunité utilisée - au moins un test, pour chaque région et pour chaque frontière de changement de toute variable d'entrée - au moins un test, pour chaque cas particulier ou pour chaque exception spécifiée dans les spécifications est au moins un test. Mais cela nécessite aussi la conception de certains tests et des textes de programmes, basés sur le principe (au moins) : chaque commande de chaque logiciel doit passer par au moins un test.
La stratégie de conception de test optimale peut être concrétisée sur la base du principe suivant : pour chaque document de programme (y compris les textes de programme) inclus dans le système logiciel, leurs propres tests doivent être conçus afin d'identifier les erreurs dans celui-ci. Dans tous les cas, ce principe doit être respecté conformément à la définition des systèmes logiciels et au contenu du concept de technologie de programmation en tant que technologie permettant de développer des systèmes logiciels fiables (voir leçon 1). À cet égard, Myers définit même différents types tests en fonction du type de document de programme sur la base duquel les tests sont construits. Dans notre pays, il existe deux principaux types de débogage (y compris les tests) : le débogage autonome et le débogage complexe. Le débogage autonome signifie tester uniquement une partie du programme inclus dans le système logiciel, rechercher et corriger les erreurs corrigées lors des tests. Il s'agit en fait de déboguer chaque module et de déboguer l'appariement des modules. Le débogage complet signifie tester le système logiciel dans son ensemble en trouvant et en corrigeant les erreurs enregistrées pendant les tests dans tous les documents (y compris les textes des systèmes logiciels) liés au système logiciel dans son ensemble. Ces documents comprennent la définition des exigences pour le logiciel, la spécification de qualité du logiciel, la spécification fonctionnelle du logiciel, la description de l'architecture logicielle et les textes des programmes logiciels.
10.3. Commandes de débogage.
Cette section fournit des directives générales pour l'organisation du débogage. Mais d'abord, il faut noter un certain phénomène qui confirme l'importance de prévenir les erreurs aux étapes précédentes de développement : à mesure que le nombre d'erreurs détectées et corrigées dans un système logiciel augmente, la probabilité relative d'erreurs non détectées augmente également. Cela est dû au fait qu'avec une augmentation du nombre d'erreurs détectées dans un système logiciel, notre compréhension du nombre total d'erreurs commises dans celui-ci, et donc, dans une certaine mesure, du nombre d'erreurs encore non détectées, est également raffiné. Ce phénomène confirme l'importance de la détection précoce des erreurs et la nécessité d'un contrôle minutieux des décisions prises à chaque étape du développement logiciel.
Commandement 1. Envisagez de tester une tâche clé du développement logiciel, confiez-la aux programmeurs les plus qualifiés et les plus doués ; il n'est pas conseillé de tester votre propre programme.
Commandement 2. Un bon test est celui pour lequel il y a une forte probabilité de détecter une erreur, et non celui qui démontre le bon fonctionnement du programme.
Commandement 3. Préparez des tests pour les données correctes et incorrectes.
Commandement 4. Éviter les tests non reproductibles, documenter leur passage par l'ordinateur ; étudier en détail les résultats de chaque test.
Commandement 5. Connectez chaque module au programme une seule fois ; ne modifiez jamais le programme pour le rendre plus facile à tester.
Commandement 6. Ignorez à nouveau tous les tests liés à la vérification du fonctionnement de tout programme PS ou de son interaction avec d'autres programmes, si des modifications y ont été apportées (par exemple, à la suite de la correction d'une erreur).
10.4. Déboguer un module hors ligne.
Dans le débogage autonome, chaque module est en fait testé dans un environnement de programmation, à moins que le programme en cours de débogage ne se compose d'un seul module. Cet environnement se compose d'autres modules, dont certains sont des modules du programme en cours de débogage, qui sont déjà débogués, et certains sont des modules qui contrôlent le débogage (modules de débogage, voir ci-dessous). Ainsi, lors du débogage autonome, un certain programme est toujours testé, construit spécifiquement pour tester le module en cours de débogage. Ce programme ne coïncide que partiellement avec le programme en cours de débogage, sauf dans le cas où le dernier module du programme en cours de débogage est en cours de débogage. Au fur et à mesure que le débogage du programme progresse, de plus en plus de l'environnement du prochain module débogué sera composé de modules déjà débogués de ce programme, et lors du débogage du dernier module de ce programme, l'environnement du module débogué sera entièrement composé de tous les autres modules (déjà débogués) du programme en cours de débogage (sans aucun) modules de débogage, c'est-à-dire dans ce cas, le programme en cours de débogage lui-même sera testé. Ce processus de création d'un programme débogué avec des modules débogués et débogués est appelé intégration de programme.
Les modules de débogage inclus dans l'environnement du module en cours de débogage dépendent de l'ordre dans lequel les modules de ce programme sont débogués, sur quel module est en cours de débogage et, éventuellement, sur quel test sera ignoré.
Lors des tests ascendants (voir leçon 7), cet environnement contiendra toujours une seule unité de débogage (sauf dans le cas où la dernière unité du programme en cours de débogage est en cours de débogage), qui sera la tête du programme en cours de test et qui est appelé le maître (ou pilote). Le module de débogage principal prépare l'environnement d'information pour tester le module en cours de débogage (c'est-à-dire qu'il forme son état requis pour tester ce module, en particulier, il peut entrer des données de test), adresse le module en cours de débogage et, après son achèvement, émet les messages nécessaires. Lors du débogage d'un module, différents modules de débogage maîtres peuvent être compilés pour différents tests.
Pendant les tests descendants (voir leçon 7), l'environnement du module débogué en tant que modules de débogage contient des simulateurs de tous les modules auxquels le module débogué peut accéder, ainsi que des simulateurs de ces modules auxquels les modules débogués du programme peuvent accéder. débogués (inclus dans cet environnement), mais qui ne sont pas encore débogués. Certains de ces simulateurs peuvent changer pour différents tests lors du débogage d'un seul module.
En fait, dans l'environnement du module en cours de débogage, dans de nombreux cas, les deux types de modules de débogage peuvent être contenus pour les raisons suivantes. Les tests ascendants et descendants ont leurs avantages et leurs inconvénients.
Les avantages des tests ascendants comprennent
facilité de préparation des tests et
la capacité de mettre pleinement en œuvre le plan de test unitaire.
Cela est dû au fait que l'état de test de l'environnement d'information est préparé immédiatement avant d'accéder au module en cours de débogage (par le module de débogage leader). Les inconvénients des tests ascendants sont les suivants :
les données de test ne sont généralement pas préparées sous la forme prévue pour l'utilisateur (sauf dans le cas où le dernier module principal du programme en cours de débogage est en cours de débogage);
une grande quantité de programmation de débogage (lors du débogage d'un module, vous devez souvent composer de nombreux modules de débogage principaux pour différents tests) ;
la nécessité de tests spéciaux des modules d'interface.
Les avantages des tests descendants sont les suivants :
la plupart des tests sont préparés dans un format convivial ;
dans de nombreux cas, une quantité relativement faible de programmation de débogage (les simulateurs de modules sont généralement assez simples et chacun convient à un grand nombre, souvent tous, de tests) ;
il n'est pas nécessaire de tester l'appairage des modules.
L'inconvénient des tests descendants est que l'état de test de l'environnement d'information avant d'accéder au module en cours de débogage est préparé indirectement - c'est le résultat de l'application de modules déjà débogués pour tester des données ou des données émises par des simulateurs. Ceci, d'une part, rend difficile la préparation des tests, nécessite des qualifications élevées de l'ingénieur de test, et d'autre part, cela rend difficile voire impossible la mise en œuvre du plan de test complet du module en cours de débogage. Cet inconvénient oblige parfois les développeurs à appliquer des tests ascendants même dans le cas d'un développement descendant. Cependant, certaines modifications des tests descendants sont souvent utilisées, ou une combinaison de tests descendants et ascendants.
Partant du fait que les tests descendants sont en principe préférables, attardons-nous sur les techniques qui permettent, dans une certaine mesure, de surmonter ces difficultés. Tout d'abord, il est nécessaire d'organiser le débogage du programme de manière à ce que les modules effectuant la saisie des données soient débogués le plus tôt possible - ensuite les données de test peuvent être préparées sous une forme conçue pour l'utilisateur, ce qui facilitera grandement simplifier la préparation des tests ultérieurs. Cette saisie n'est en aucun cas toujours réalisée dans le module de tête ; il faut donc tout d'abord déboguer les chaînes de modules menant aux modules réalisant la saisie spécifiée (comparer avec la méthode d'implémentation constructive intentionnelle du cours 7) . Tant que les modules d'entrée ne sont pas débogués, les données de test sont fournies par certains simulateurs : elles sont soit incluses dans le simulateur en tant que partie de celui-ci, soit injectées par le simulateur.
Lors des tests descendants, certains états de l'environnement d'information, dans lesquels il est nécessaire de tester le module en cours de débogage, peuvent ne pas se produire pendant l'exécution du programme en cours de débogage pour les données d'entrée. Dans ces cas, il serait possible de ne pas tester du tout le module en cours de débogage, car les erreurs détectées dans ce cas n'apparaîtront pas lors de l'exécution du programme en cours de débogage pour aucune donnée d'entrée. Cependant, il n'est pas recommandé de le faire, car lorsque le programme en cours de débogage change (par exemple, lors de la maintenance du système logiciel), les états de l'environnement d'information qui n'ont pas été utilisés pour tester le module débogué peuvent déjà apparaître, ce qui nécessite des tests supplémentaires de ce module (et cela n'aurait pas pu être fait avec une organisation rationnelle du débogage si moi-même ce module n'a pas changé). Pour tester l'unité déboguée dans ces situations, des simulateurs appropriés sont parfois utilisés pour créer l'état requis de l'environnement d'information. Le plus souvent, ils utilisent une version modifiée du test descendant, dans laquelle les modules en cours de débogage sont pré-testés séparément avant d'être intégrés (dans ce cas, un module de débogage leader apparaît dans l'environnement du module en cours de débogage, ainsi que des simulateurs de modules auxquels le module en cours de débogage peut accéder). Cependant, une autre modification des tests descendants semble être plus opportune : après l'achèvement des tests descendants du module débogué pour les états de test réalisables de l'environnement d'information, il doit être testé séparément pour le reste des états requis du environnement informationnel.
Une combinaison de tests ascendants et descendants, appelée méthode sandwich, est également souvent utilisée. L'essence de cette méthode réside dans la mise en œuvre simultanée de tests ascendants et descendants, jusqu'à ce que ces deux processus de test se rencontrent sur un module quelque part au milieu de la structure du programme en cours de débogage. Cette méthode permet, avec une approche raisonnable, de profiter des avantages des tests ascendants et descendants et de neutraliser largement leurs inconvénients. Cet effet est une manifestation d'un principe plus général : le plus grand effet technologique peut être obtenu en combinant des méthodes descendantes et ascendantes de développement de programmes de PF. C'est pour soutenir cette méthode que l'approche architecturale du développement logiciel est destinée (voir leçon 7) : une couche de modules savamment développés et minutieusement testés facilite grandement la mise en œuvre d'une famille de programmes dans le domaine correspondant et leur modernisation ultérieure.
Il est très important pour le débogage hors ligne de tester l'appariement des modules. Le fait est que la spécification de chaque module de programme, à l'exception du module principal, est utilisée dans ce programme dans deux situations : d'une part, lors de l'élaboration du texte (parfois on dit : le corps) de ce module et, d'autre part, lors de la rédaction d'un appel à ce module dans d'autres modules du programme. Dans les deux cas, à la suite d'une erreur, la conformité requise avec la spécification de module spécifiée peut être violée. De telles erreurs doivent être détectées et éliminées. C'est le but du test de l'interface des modules. Dans les tests descendants, des tests d'appariement sont effectués en cours de route avec chaque test ignoré, ce qui est considéré comme le plus grand avantage des tests descendants. Pendant les tests ascendants, l'adresse du module débogué n'est pas établie à partir des modules du programme en cours de débogage, mais à partir du débogueur maître. A cet égard, il existe un danger que le dernier module puisse s'adapter à certaines "erreurs" du module débogué. Ainsi, lors du démarrage (en cours d'intégration du programme) du débogage d'un nouveau module, il faut tester chaque appel à un module préalablement débogué afin de détecter une incohérence de cet appel avec le corps du module correspondant (et il est possible qu'un module précédemment débogué est à blâmer pour cela). Ainsi, il est nécessaire de répéter partiellement le test d'un module précédemment débogué dans de nouvelles conditions, alors que les mêmes difficultés se présentent que dans le test descendant.
Il est conseillé d'effectuer un test hors ligne d'un module en quatre étapes séquentielles.
Étape 1. Sur la base de la spécification du module en cours de débogage, préparez un test pour chaque possibilité et chaque situation, pour chaque limite des plages valides de toutes les entrées, pour chaque plage de modifications de données, pour chaque plage invalide de toutes les entrées et chaque état invalide.
Étape 2. Vérifiez le texte du module pour vous assurer que chaque direction de n'importe quelle branche réussira au moins un test. Ajouter les tests manquants.
Étape 3. Assurez-vous, selon le texte du module, que pour chaque boucle, il existe un test pour lequel le corps de la boucle n'est pas exécuté, un test pour lequel le corps de la boucle est exécuté une fois et un test pour lequel le corps de la boucle est exécuté au maximum. nombre de fois. Ajouter les tests manquants.
Étape 4. Vérifiez dans le texte du module sa sensibilité aux valeurs spéciales individuelles des données d'entrée - toutes ces valeurs doivent être incluses dans les tests. Ajouter les tests manquants.
10.5. Débogage de logiciels complexes.
Comme mentionné ci-dessus, lors d'un débogage complexe, le système logiciel est testé dans son ensemble et des tests sont préparés pour chacun des documents logiciels. Le test de ces documents est effectué, en règle générale, dans l'ordre inverse de leur développement (la seule exception est le test de la documentation de l'application, qui est développée selon une description externe parallèlement à l'élaboration des textes du programme ; il est préférable de effectuer ce test après avoir testé la description externe). Le test avec débogage complexe est l'application d'un système logiciel à des données spécifiques qui, en principe, peuvent provenir de l'utilisateur (en particulier, tous les tests sont préparés sous une forme conçue pour l'utilisateur), mais éventuellement sous une forme simulée (et non sous réel) environnement. Par exemple, certains périphériques d'entrée et de sortie qui ne sont pas disponibles dans le débogage complexe peuvent être remplacés par leurs simulateurs logiciels.
Test de l'architecture PS. Le but des tests est de trouver un décalage entre la description de l'architecture et l'ensemble des logiciels. Au moment où l'architecture PS commence à tester, le débogage autonome de chaque sous-système doit être terminé. Les erreurs dans la mise en œuvre de l'architecture peuvent être principalement associées à l'interaction de ces sous-systèmes, en particulier, à la mise en œuvre des fonctions architecturales (le cas échéant). Par conséquent, je voudrais vérifier tous les modes d'interaction entre les sous-systèmes du PS. Mais comme ils peuvent être trop nombreux, il serait souhaitable de tester au moins toutes les chaînes d'exécution des sous-systèmes sans rentrer dans ces derniers. Si une architecture donnée représente un PS comme un petit système de sous-systèmes dédiés, alors le nombre de telles chaînes sera assez visible.
Test des fonctions externes. Le but des tests est de trouver des écarts entre la spécification fonctionnelle et l'ensemble des logiciels. Malgré le fait que tous ces programmes ont déjà été débogués de manière autonome, les écarts indiqués peuvent être, par exemple, dus à l'incohérence des spécifications internes des programmes et de leurs modules (sur la base desquels le test autonome a été effectué) avec la spécification fonctionnelle externe du système logiciel. En règle générale, le test des fonctions externes est effectué de la même manière que le test des modules à la première étape, c'est-à-dire comme une boîte noire.
Tester la qualité du PS. Le but des tests est de trouver des violations des exigences de qualité formulées dans la spécification de qualité du système logiciel. C'est le type de test le plus difficile et le moins étudié. Il est seulement clair que toutes les primitives de qualité logicielle ne peuvent pas être testées par des tests (à propos de l'évaluation de la qualité du logiciel, voir la prochaine conférence). L'exhaustivité du PS est déjà vérifiée lors du test des fonctions externes. A ce stade, le test de cette primitive de qualité peut être poursuivi s'il est nécessaire d'obtenir une estimation probabiliste du degré de fiabilité du PS. Cependant, la méthodologie pour de tels tests doit encore être développée. La précision, la robustesse, la sécurité, l'efficacité temporelle, dans une certaine mesure l'efficacité de la mémoire, l'efficacité de l'appareil, l'évolutivité et, en partie, l'indépendance de l'appareil peuvent être testées. Chacun de ces types de tests a ses propres spécificités et mérite une considération distincte. Nous nous limiterons ici à leur énumération. La facilité d'application du PS (un critère de qualité qui comprend plusieurs primitives de qualité, voir leçon 4) est évaluée en testant la documentation pour l'application du PS.
Documentation d'essai pour l'application de la PS. Le but des tests est de trouver des incohérences entre la documentation de l'application et l'ensemble des logiciels, ainsi que les inconvénients liés à l'utilisation du logiciel. Cette étape précède immédiatement la connexion de l'utilisateur à l'achèvement du développement du logiciel (test des exigences du logiciel et attestation du logiciel), il est donc très important que les développeurs utilisent d'abord le logiciel de la même manière que l'utilisateur le fera. fais-le. Tous les tests à ce stade sont préparés uniquement sur la base de la seule documentation pour l'application de la PS. Tout d'abord, les capacités du système logiciel doivent être testées comme cela a été fait lors du test des fonctions externes, mais uniquement sur la base de la documentation de l'application. Tout point obscur de la documentation doit être testé, ainsi que tous les exemples utilisés dans la documentation. De plus, les cas d'application du PS les plus difficiles sont testés afin de détecter une violation des exigences de la relativité de la facilité d'application du PS.
Tester la définition des exigences pour le PS. Le but des tests est de déterminer dans quelle mesure un système logiciel ne répond pas à la définition énoncée des exigences pour lui. La particularité de ce type de test est qu'il est réalisé par l'organisation d'achat ou l'organisation utilisatrice du système logiciel comme l'un des moyens de surmonter la barrière entre le développeur et l'utilisateur (voir leçon 3). Habituellement, ces tests sont effectués à l'aide de tâches de contrôle - des tâches typiques pour lesquelles le résultat de la solution est connu. Dans les cas où le système logiciel développé doit remplacer une autre version du système logiciel, qui résout au moins une partie des tâches du système logiciel développé, les tests sont effectués en résolvant les problèmes courants en utilisant à la fois l'ancien et le nouveau système logiciel avec une comparaison ultérieure des les résultats obtenus. Parfois, comme forme de test, ils utilisent l'exploitation d'essai d'une PS - une application limitée d'une nouvelle PS avec une analyse de l'utilisation des résultats dans la pratique. Essentiellement, ce type de test a beaucoup de points communs avec le test d'une EP pendant son attestation (voir leçon 14), mais il est effectué avant l'attestation, et parfois à la place de l'attestation.
Littérature pour le cours 10.
10.1. G. Myers. Fiabilité du logiciel. - M. : Mir, 1980.-- S. 171-262.
10.2. D. Van Tassel. Programmes de style, de conception, d'efficacité, de débogage et de test. - M. : Mir, 1985.-- S. 179-295.
10.3. J. Hughes, J. Micht. Une approche structurée de la programmation. - M. : Mir, 1980.-- S. 254-268.
10.4. J. Fox. Logiciel et son développement. - M. : Mir, 1985.-- S. 227-241.
10.5. M. Zelkowitz, A. Shaw, J. Gannon. Principes de développement logiciel. - M. : Mir, 1982.-- S. 105-116.
10.6. Miam. Bezborodov. Débogage individuel des programmes. - M. : Nauka, 1982.-- S. 9-79.
10.7. V.V. Lipaev. Tester les programmes. - M. : Radio et communication, 1986. - S. 15-47.
10.8. E.A. Jougolev. Introduction à la technologie de programmation (notes de cours). - M. : " DIALOGUE-MGU ", 1994.
10.9. E. Dijkstra. Notes sur la programmation structurée. // U. Dahl, E. Dijkstra, K. Hoore. Programmation structurée. - M. : Mir, 1975.-- S. 7-13.
Cours 11. Assurer la fonctionnalité et la fiabilité du logiciel
11.1. Fonctionnalité et fiabilité comme critères obligatoires pour la qualité du logiciel.
Dans le cours précédent, nous avons examiné toutes les étapes du développement d'un logiciel, à l'exception de sa certification. Dans le même temps, nous n'avons pas abordé les questions d'assurer la qualité du PS conformément à sa spécification de qualité (voir leçon 4). Certes, lors de la mise en œuvre de la spécification fonctionnelle du PS, nous avons ainsi discuté des principaux problèmes d'assurance du critère de fonctionnalité. Après avoir déclaré la fiabilité du système logiciel comme son attribut principal (voir leçon 1), nous avons choisi la prévention des erreurs comme approche principale pour assurer la fiabilité du système logiciel (voir leçon 3) et discuté de sa mise en œuvre à différentes étapes du développement logiciel. Ainsi, la thèse sur la fonctionnalité obligatoire et la fiabilité du système logiciel en tant que critères de sa qualité s'est manifestée.
Cependant, la spécification de qualité du système logiciel peut contenir des caractéristiques supplémentaires de ces critères, dont la fourniture nécessite une discussion particulière. Cette conférence est consacrée à ces questions. L'assurance d'autres critères de qualité sera discutée dans la prochaine conférence.
Ci-dessous, nous discutons de la fourniture de primitives de qualité logicielle qui expriment des critères pour la fonctionnalité et la fiabilité du logiciel.
11.2. S'assurer de l'exhaustivité de l'outil logiciel.
L'exhaustivité du PS est une primitive générale de la qualité du PS pour l'expression à la fois de la fonctionnalité et de la fiabilité du PS, et pour la fonctionnalité c'est la seule primitive (voir leçon 4).
La fonctionnalité d'un système logiciel est déterminée par sa spécification fonctionnelle. L'exhaustivité du PS en tant que primitive de sa qualité est une mesure de la manière dont cette spécification est mise en œuvre dans le PS donné. Fournir cette primitive dans son intégralité signifie mettre en œuvre chacune des fonctions définies dans la spécification fonctionnelle, avec tous les détails et fonctionnalités qui y sont spécifiés. Tous les flux de travail discutés précédemment montrent comment cela peut être fait.
Cependant, dans la spécification de la qualité du système logiciel, plusieurs niveaux d'implémentation de la fonctionnalité logicielle peuvent être définis : une certaine version simplifiée (initiale ou initiale) peut être définie, qui doit être implémentée en premier lieu, et plusieurs des versions peuvent également être définies. Dans ce cas, une tâche technologique supplémentaire se pose: l'organisation de l'augmentation des fonctionnalités du PS. Il est important de noter ici que le développement d'une version simplifiée du système logiciel n'est pas le développement de son prototype. Le prototype est en cours de développement afin de mieux comprendre les conditions d'utilisation du futur PS, d'éclairer sa description externe. Il est conçu pour des utilisateurs sélectionnés et peut donc différer considérablement du système logiciel requis non seulement dans les fonctions exécutées, mais également dans les caractéristiques de l'interface utilisateur. Une version simplifiée du système logiciel requis doit être conçue pour une utilisation pratique par tous les utilisateurs auxquels elle est destinée. Par conséquent, le principe principal pour garantir la fonctionnalité d'un tel logiciel est de développer le logiciel dès le début de manière à ce que le logiciel soit entièrement requis, jusqu'à ce que les développeurs traitent les parties ou les détails du logiciel, dont la mise en œuvre peut être ajourné selon la spécification de sa qualité. Ainsi, tant la description externe que la description de l'architecture du PS devraient être développées dans leur intégralité. Vous ne pouvez reporter la mise en œuvre que des sous-systèmes logiciels définis dans l'architecture du système logiciel développé, dont le fonctionnement n'est pas requis dans la version initiale de ce système logiciel. La mise en œuvre des sous-systèmes logiciels eux-mêmes est mieux réalisée par la méthode de mise en œuvre constructive ciblée, en laissant dans la version initiale du logiciel les simulateurs appropriés de ces modules logiciels, dont le fonctionnement n'est pas requis dans cette version. Une implémentation simplifiée de certains modules logiciels est également acceptable, en omettant l'implémentation de certains détails des fonctions correspondantes. Cependant, d'un point de vue technologique, ces modules sont mieux considérés comme une sorte de leurs imitateurs (bien que très avancés).
En raison des erreurs dans le système logiciel développé, l'exhaustivité atteinte tout en assurant sa fonctionnalité (conformément à la spécification de sa qualité) peut en réalité ne pas être celle attendue. Nous pouvons seulement dire que cette complétude a été atteinte avec une certaine probabilité déterminée par le volume et la qualité des tests effectués. Afin d'augmenter cette probabilité, il est nécessaire de continuer à tester et à déboguer le système logiciel. Cependant, l'estimation d'une telle probabilité est une tâche très spécifique (compte tenu du fait que la manifestation de l'erreur dans le PS est fonction des données initiales), qui attend toujours les études théoriques correspondantes.
11.3. Assurer l'exactitude du logiciel.
La fourniture de cette primitive est associée à des actions sur des valeurs de types réels (plus précisément, sur des valeurs représentées avec une certaine erreur). Fournir la précision requise lors du calcul de la valeur d'une fonction particulière signifie obtenir cette valeur avec une erreur qui ne dépasse pas les limites spécifiées. Les mathématiques computationnelles traitent des types d'erreurs, des méthodes de leur estimation et des méthodes permettant d'atteindre la précision requise (calculs dits approximatifs). Ici, nous ne ferons attention qu'à une certaine structure de l'erreur : l'erreur de la valeur calculée (erreur totale) dépend
sur l'erreur de la méthode de calcul utilisée (dans laquelle on inclut l'imprécision du modèle utilisé),
de l'erreur dans la présentation des données utilisées (de l'erreur dite fatale),
de l'erreur d'arrondi (imprécisions dans l'exécution des opérations utilisées dans la méthode).
11.4. Assurer l'autonomie du logiciel.
Cette primitive de qualité est fournie au stade de la spécification de la qualité en prenant une décision sur l'utilisation de tout logiciel de base approprié dans le logiciel développé ou de ne pas utiliser de logiciel de base dans celui-ci. Dans ce cas, il faut prendre en compte à la fois sa fiabilité et les ressources nécessaires à son utilisation. Avec des exigences accrues en matière de fiabilité du système logiciel développé, la fiabilité du logiciel de base à la disposition des développeurs peut s'avérer insatisfaisante, par conséquent, son utilisation doit être abandonnée et la mise en œuvre de ses fonctions dans le volume requis doit être inclus dans le système logiciel. Des décisions similaires doivent être prises avec des restrictions strictes sur les ressources utilisées (selon le critère d'efficacité du PS).
11.5. Assurer la stabilité du logiciel.
Cette primitive de qualité est fournie par ce que l'on appelle la programmation défensive. De manière générale, la programmation défensive est utilisée pour améliorer la fiabilité du PS lors de la programmation d'un module au sens large. Comme le soutient Myers, « la programmation défensive est basée sur une prémisse importante : le pire qu'un module puisse faire est d'accepter une entrée incorrecte, puis de renvoyer un résultat incorrect mais plausible. Afin d'éviter cela, le texte du module inclut des contrôles de ses données d'entrée et de sortie pour leur exactitude conformément à la spécification de ce module, en particulier, le respect des restrictions sur les données d'entrée et de sortie et les relations entre elles spécifié dans la spécification du module doit être vérifié. Si la vérification échoue, une exception correspondante est levée. À cet égard, des fragments du deuxième type sont inclus à la fin de ce module - les gestionnaires des exceptions correspondantes, qui, en plus de fournir les informations de diagnostic nécessaires, peuvent prendre des mesures soit pour éliminer les erreurs dans les données (par exemple, pour nécessitent leur rentrée), soit pour affaiblir l'effet de l'erreur (par exemple , arrêt progressif des dispositifs commandés par le PS afin d'éviter leur panne en cas d'arrêt d'urgence de l'exécution du programme).
L'utilisation d'une programmation défensive des modules conduit à une diminution de l'efficacité du PS à la fois en temps et en mémoire. Par conséquent, il est nécessaire de réguler raisonnablement le degré d'application de la programmation défensive en fonction des exigences de fiabilité et d'efficacité du système logiciel, formulées dans la spécification de qualité du système logiciel en cours de développement. Les données d'entrée du module en cours de développement peuvent provenir soit directement de l'utilisateur, soit d'autres modules. Le cas d'utilisation le plus courant pour la programmation défensive est son application pour le premier groupe de données, ce qui signifie la mise en œuvre de la stabilité du logiciel. Cela doit toujours être fait lorsque la spécification de qualité du PS contient une exigence pour assurer la stabilité du PS. Utiliser une programmation défensive pour le deuxième groupe d'entrées signifie essayer de détecter une erreur dans d'autres modules lors de l'exécution d'un module en développement, et pour la sortie d'un module développé, une tentative de détecter une erreur dans ce module lui-même lors de son exécution. Essentiellement, cela signifie une mise en œuvre partielle de l'approche d'auto-détection d'erreurs pour assurer la fiabilité du logiciel, qui a été discutée dans la leçon 3. Ce cas de programmation défensive est utilisé extrêmement rarement - uniquement lorsque les exigences de fiabilité du logiciel sont extrêmement élevés.
11.6. Assurer la sécurité des logiciels.
Il existe les types suivants de protection logicielle contre la distorsion des informations :
protection contre les pannes matérielles ;
protection contre l'influence d'un programme « étranger »;
protection contre les échecs du programme "propre" ;
protection contre les erreurs de l'opérateur (utilisateur) ;
protection contre les accès non autorisés ;
protection contre la protection.
La protection contre les pannes matérielles n'est actuellement pas un problème très pressant (compte tenu du niveau de fiabilité atteint des ordinateurs). Mais il est toujours utile de connaître sa solution. Ceci est assuré par l'organisation des soi-disant « erreurs de calcul double-triple ». Pour cela, tout le processus traitement de l'information, déterminé par le PS, est divisé dans le temps en intervalles par les "points de contrôle". Cet intervalle ne doit pas dépasser la moitié du MTBF de l'ordinateur. Une copie de l'état de la mémoire modifié dans ce processus pour chaque point de contrôle est inscrite dans la mémoire secondaire avec une certaine somme de contrôle (un nombre calculé en fonction de cet état) dans le cas où l'on considérera que le traitement des données du point de contrôle précédent à celui-ci (c'est-à-dire une "erreur de calcul") est correcte (sans plantage de l'ordinateur). Afin de le découvrir, deux de ces "erreurs de calcul" sont faites. Après la première « erreur de calcul », la somme de contrôle spécifiée est calculée et stockée, puis l'état de la mémoire pour le point de référence précédent est restauré et la deuxième « erreur de calcul » est effectuée. Après la deuxième "erreur de calcul", la somme de contrôle spécifiée est à nouveau calculée, qui est ensuite comparée à la somme de contrôle de la première "erreur de calcul". Si ces deux sommes de contrôle correspondent, le deuxième calcul est considéré comme correct, sinon la somme de contrôle du deuxième « calcul » est également mémorisée et le troisième « calcul » est effectué (avec une restauration préliminaire de l'état de la mémoire pour le point de référence précédent). Si la somme de contrôle de la troisième « erreur de calcul » correspond à la somme de contrôle de l'un des deux premiers « erreurs de calcul », alors la troisième erreur de calcul est considérée comme correcte, sinon une vérification technique de l'ordinateur est requise.
La protection contre l'influence d'un programme « étranger » se réfère principalement aux systèmes d'exploitation ou aux programmes qui remplissent partiellement leurs fonctions. Il existe deux types de cette protection :
protection contre les pannes,
protection contre l'influence malveillante d'un programme « étranger ».
Lorsqu'un mode de fonctionnement multiprogramme d'un ordinateur apparaît dans sa mémoire, plusieurs programmes peuvent être simultanément en phase d'exécution, recevant alternativement le contrôle à la suite d'interruptions survenant (l'exécution de programme dite quasi-parallèle). L'un de ces programmes (généralement : le système d'exploitation) gère la gestion des interruptions et la multiprogrammation. Des défaillances (erreurs) peuvent se produire dans chacun de ces programmes, ce qui peut affecter les performances des fonctions d'autres programmes. Par conséquent, le programme de contrôle (système d'exploitation) doit se protéger et protéger les autres programmes d'une telle influence. Pour ce faire, le matériel informatique doit mettre en œuvre les capacités suivantes :
protection de la mémoire,
deux modes de fonctionnement de l'ordinateur : privilégié et fonctionnel (utilisateur),
deux types d'opérations : privilégiées et ordinaires,
bonne exécution des interruptions et démarrage initial du calculateur,
interruption temporaire.
La protection de la mémoire signifie la possibilité de définir par programmation pour chaque programme des zones de mémoire qui lui sont inaccessibles. En mode privilégié, toutes les opérations peuvent être effectuées (à la fois ordinaires et privilégiées), et en mode de fonctionnement, uniquement des opérations ordinaires. Une tentative d'exécution d'une opération privilégiée, ainsi qu'un accès à la mémoire protégée en mode de fonctionnement, provoque une interruption correspondante. De plus, les opérations privilégiées comprennent les opérations de changement de protection de la mémoire et de mode de fonctionnement, ainsi que l'accès à l'environnement d'information externe. La mise sous tension initiale de l'ordinateur et toute interruption doivent activer automatiquement le mode privilégié et annuler la protection de la mémoire. Dans ce cas, le programme de contrôle (système d'exploitation) peut se protéger totalement de l'influence d'autres programmes, si tous les points de transfert de contrôle lors de la mise sous tension initiale et les interruptions appartiennent à ce programme, s'il ne permet à aucun autre programme de fonctionner en mode privilégié (lors du transfert du contrôle à un autre, le programme n'activera que le mode de fonctionnement) et s'il protège complètement sa mémoire (contenant notamment toutes ses informations de contrôle, y compris les vecteurs dits d'interruption) des autres programmes . Ensuite, personne ne l'empêchera d'exécuter des fonctions de protection d'autres programmes mis en œuvre dans celui-ci (y compris l'accès à l'environnement d'information externe). Pour faciliter la solution de ce problème, une partie d'un tel programme est placée en mémoire permanente, c'est-à-dire indissociable de l'ordinateur lui-même. La présence d'une interruption temporaire permet au programme de contrôle de se protéger du bouclage dans d'autres programmes (sans une telle interruption, il pourrait simplement perdre la capacité de contrôle).
La protection contre les échecs du "propre" programme est assurée par la fiabilité de ce programme, qui est au centre de toutes les technologies de programmation abordées dans ce cours.
La protection contre les erreurs de l'utilisateur (en plus des erreurs de données d'entrée, voir assurer la stabilité du système logiciel) est assurée par l'émission de messages d'avertissement concernant les tentatives de modification de l'état de l'environnement d'information externe avec l'obligation de confirmer ces actions, ainsi que la capacité de restaurer l'état des composants individuels de l'environnement d'information externe. Ce dernier est basé sur l'archivage des changements d'état de l'environnement d'information externe.
La protection contre les accès non autorisés est assurée par l'utilisation de mots secrets (mots de passe). Dans ce cas, chaque utilisateur dispose de certaines informations et ressources procédurales (services), dont l'utilisation nécessite que le PS présente un certain mot de passe préalablement enregistré dans le PS par cet utilisateur. En d'autres termes, l'utilisateur, pour ainsi dire, « accroche un verrou » sur les ressources qui lui sont allouées, dont seul cet utilisateur possède la « clé ». Cependant, dans certains cas, des tentatives persistantes peuvent être faites pour briser une telle protection, si les ressources protégées sont d'une valeur extrême pour quelqu'un. Dans un tel cas, vous devez prendre des mesures supplémentaires pour vous protéger contre le piratage.
La protection contre le piratage de la protection est associée à l'utilisation de techniques de programmation spéciales dans le PS qui rendent difficile le dépassement de la protection contre les accès non autorisés. L'utilisation de mots de passe réguliers est insuffisante lorsqu'il s'agit d'un désir extrêmement persistant (par exemple de nature criminelle) d'accéder à des informations précieuses. Premièrement, parce que l'information sur les mots de passe est utilisée par un PS pour se protéger contre les accès non autorisés, le « cracker » de cette protection peut relativement facilement obtenir s'il a accès à ce PS lui-même. Deuxièmement, à l'aide d'un ordinateur, il est possible d'effectuer une énumération suffisamment large de mots de passe possibles afin de trouver celui qui convient pour accéder aux informations d'intérêt. Vous pouvez vous protéger contre un tel piratage comme suit. Le mot secret (mot de passe) ou simplement un entier secret X n'est connu que par le propriétaire de l'information protégée, et pour vérifier les droits d'accès, un autre nombre Y = F (X) est stocké dans l'ordinateur, qui est uniquement calculé par le PS pour chaque tentative d'accès à ces informations sur présentation du mot secret. Dans ce cas, la fonction F peut être bien connue de tous les utilisateurs du PS, cependant, elle a une telle propriété que la restauration du mot X à partir de Y est pratiquement impossible : avec une longueur suffisamment grande du mot X (par exemple, plusieurs cent caractères), cela demande un temps astronomique. Un tel nombre Y sera appelé signature électronique (informatique) du propriétaire du mot secret X (et donc de l'information protégée).
Un autre type de protection est associé à la protection des messages envoyés sur les réseaux informatiques, la distorsion délibérée (ou malveillante). Un tel message peut être intercepté aux points de « transbordement » du réseau informatique et remplacé par un autre message de l'auteur du message intercepté. Cette situation se présente principalement lors de la réalisation d'opérations bancaires à l'aide d'un réseau informatique. En substituant un tel message, qui est un ordre du propriétaire d'un compte bancaire d'effectuer une certaine opération bancaire, l'argent de son compte peut être transféré sur le compte du "cracker" de protection (une sorte de braquage de banque informatique). La protection contre une telle violation de la protection peut être mise en œuvre comme suit. A côté de la fonction F, qui détermine la signature informatique du propriétaire du mot secret X, que le destinataire du message protégé connaît (si seulement son propriétaire est client de ce destinataire), le PS définit une autre fonction Stamp, selon laquelle l'expéditeur du message doit calculer le nombre S = Stamp (X, R ), en utilisant le mot secret X et le texte du message transmis R. La fonction Stamp est également considérée comme bien connue de tous les utilisateurs du PS et possède une telle propriété qu'il est pratiquement impossible soit de récupérer le nombre X de S, soit de récupérer un autre message R avec la signature informatique correspondante. Le message transmis lui-même (avec sa protection) doit avoir la forme :
de plus, Y (signature informatique) permet au destinataire d'établir la véracité du client, et S, pour ainsi dire, lie le message protégé R avec une signature informatique Y. A cet égard, nous appellerons le numéro S un ) joint. Le PS définit encore une fonction Notaire, selon laquelle le destinataire du message protégé vérifie la véracité du message transmis :
Ceci permet d'établir sans ambiguïté que le message R appartient au propriétaire du mot secret X.
Une protection contre la protection est nécessaire dans le cas où l'utilisateur a oublié (ou perdu) son mot de passe. Dans un tel cas, il devrait être possible pour un utilisateur spécial (administrateur PS) responsable du fonctionnement du système de protection de supprimer temporairement la protection contre les accès non autorisés pour le propriétaire du mot de passe oublié afin de lui permettre de fixer un nouveau mot de passe .
Littérature pour la conférence 11.
11.1. EST. Berezin, N.P. Zhidkov. Méthodes de calcul, vol. 1 et 2. - Moscou : Fizmatgiz, 1959.
11.2. NS. Bakhvalov, N.P. Zhidkov, G.M. Kobelkov. Méthodes numériques. - M. : Nauka, 1987.
11.3. G. Myers. Fiabilité du logiciel. - M. : Mir, 1980.S. 127-154.
11.4. UN. Lebedev. Sécurité de l'information bancaire et cryptographie moderne // Problèmes de sécurité de l'information, 2 (29), 1995.
Cours 12. Assurance qualité du logiciel
12.1. Caractéristiques générales du processus d'assurance de la qualité des outils logiciels.
Comme déjà noté dans la leçon 4, la spécification de qualité définit les principales directives (objectifs) qui, à tous les stades du développement logiciel, affectent d'une manière ou d'une autre le choix d'une option appropriée lors de la prise de diverses décisions. Cependant, chaque primitive de qualité a ses propres caractéristiques d'une telle influence, garantissant ainsi sa présence dans le système logiciel peut nécessiter ses propres approches et méthodes pour développer le système logiciel ou ses parties individuelles. De plus, l'incohérence des critères de qualité du PS et des primitives de qualité les exprimant a également été constatée : une bonne fourniture de l'une quelconque des primitives de qualité du PS peut compliquer considérablement ou rendre impossible la fourniture d'une autre de ces primitives. Par conséquent, une partie essentielle du processus d'assurance qualité de SP consiste à trouver des compromis acceptables. Ces compromis devraient être déjà partiellement déterminés dans la spécification de qualité PS : le modèle de qualité PS devrait spécifier le degré requis de présence dans le PS de chacune de ses primitives de qualité et déterminer les priorités pour atteindre ces degrés.
L'assurance qualité est réalisée dans chaque processus technologique : les décisions qui y sont prises, à un degré ou à un autre, affectent la qualité du système logiciel dans son ensemble. En particulier, parce qu'une partie importante des primitives de qualité est associée non pas tant aux propriétés des programmes inclus dans le système logiciel, mais aux propriétés de la documentation. En raison de l'incohérence notée des primitives de qualité, il est très important de respecter les priorités sélectionnées dans leur fourniture. Mais dans tous les cas, il est utile de respecter deux principes généraux :
tout d'abord, il est nécessaire d'assurer la fonctionnalité et la fiabilité requises du PS, puis d'amener les critères de qualité restants à un niveau acceptable de leur présence dans le PS ;
il n'est pas nécessaire et peut même être préjudiciable d'obtenir un niveau de présence dans le service PS d'une quelconque primitive de qualité supérieur à celui défini dans la spécification de qualité du service PS.
La garantie de la fonctionnalité et de la fiabilité du PS a été abordée dans la conférence précédente. Ce qui suit traite de la fourniture d'autres critères pour la qualité de la PS.
12.2 .. Assurer la facilité d'utilisation de l'outil logiciel
Le logiciel P-documenting détermine la composition de la documentation utilisateur
Dans le cours précédent, nous avons déjà évoqué la mise à disposition de deux des cinq primitives de qualité (stabilité et sécurité), qui déterminent la facilité d'utilisation du logiciel.
La P-documentation et le caractère informatif déterminent la composition et la qualité de la documentation utilisateur (voir le cours suivant).
L'interopérabilité est assurée par la création d'une interface utilisateur appropriée et la mise en œuvre appropriée des exceptions. Quel est le problème ici?
12.3. Assurer l'efficacité du logiciel.
L'efficacité du système logiciel est assurée par la prise de décisions appropriées à différentes étapes de son développement, à commencer par le développement de son architecture. Le choix de la structure et de la présentation des données affecte particulièrement fortement l'efficacité du système logiciel (notamment en termes de mémoire). Mais le choix des algorithmes utilisés dans certains modules logiciels, ainsi que les spécificités de leur implémentation (notamment le choix d'un langage de programmation) peuvent affecter de manière significative l'efficacité d'un système logiciel. En même temps, il est constamment nécessaire de résoudre la contradiction entre efficacité temporelle et efficacité mémorielle. Par conséquent, il est très important que la spécification de qualité indique explicitement le rapport quantitatif entre les indicateurs de ces primitives de qualité, ou au moins fixe des limites quantitatives pour l'un de ces indicateurs. Et pourtant, différents modules logiciels ont des effets différents sur l'efficacité du système logiciel dans son ensemble : à la fois en termes de contribution aux coûts totaux du système logiciel en termes de temps et de mémoire, et en termes d'effet sur la qualité différente primitives (certains modules peuvent fortement influencer l'atteinte de l'efficacité temporelle et n'ont pratiquement aucun effet sur l'efficacité de la mémoire, tandis que d'autres peuvent affecter de manière significative la consommation globale de mémoire sans avoir d'effet notable sur le temps de fonctionnement du PS). De plus, cette influence (principalement liée à l'efficacité temporaire) en amont (avant la fin de la mise en œuvre du PS) est loin d'être toujours possible à évaluer correctement.
vous devez d'abord développer une PS fiable, et seulement ensuite atteindre l'efficacité requise conformément aux spécifications de qualité de cette PS ;
pour augmenter l'efficacité du système logiciel, utilisez tout d'abord un compilateur d'optimisation - cela peut fournir l'efficacité requise ;
si l'efficacité atteinte du PS ne répond pas à la spécification de sa qualité, alors trouver les modules les plus critiques en termes d'efficacité requise du PS (dans le cas de l'efficacité temporelle, cela nécessitera d'obtenir la répartition par les modules du PS temps de fonctionnement du PS au moyen de mesures appropriées pendant l'exécution du PS); ces modules et essayer de les optimiser d'abord en les retravaillant manuellement ;
n'optimisez pas le module s'il n'est pas nécessaire pour atteindre l'efficacité requise du PS.
12.4. Assurer la maintenabilité.
La C-documentation, l'informativité et la compréhensibilité déterminent la composition et la qualité de la documentation de maintenance (voir le cours suivant). De plus, les recommandations suivantes peuvent être faites concernant les textes des programmes (modules).
utiliser des commentaires dans le texte du module qui clarifient et expliquent les caractéristiques des décisions prises ; Si possible, incluez des commentaires (au moins sous forme abrégée) au tout début de l'élaboration du texte du module ;
utilisez des noms significatifs (mnémotechniques) et persistants (la longueur optimale du nom est de 4 à 12 lettres, chiffres à la fin), n'utilisez pas de noms et de mots-clés similaires ;
soyez prudent lorsque vous utilisez des constantes (une constante unique ne doit avoir qu'une seule occurrence dans le texte du module : lorsqu'elle est déclarée ou, dans les cas extrêmes, lorsqu'une variable est initialisée en tant que constante) ;
n'ayez pas peur d'utiliser des parenthèses facultatives (les parenthèses sont moins chères que les erreurs ;
ne placez pas plus d'un opérateur par ligne ; pour clarifier la structure du module, utilisez des espaces supplémentaires (indentation) au début de chaque ligne ;
éviter les astuces, c'est-à-dire telles techniques de programmation lorsque des fragments d'un module sont créés, dont l'effet principal n'est pas évident ou caché (voilé), par exemple, les effets secondaires des fonctions.
L'extensibilité est assurée par la création d'un installateur approprié.
La structuration et la modularité facilitent à la fois la compréhension des textes du programme et leur modification.
12.5. Assurer la mobilité.
Littérature pour la conférence 12.
12.1. Ian Sommerville. Génie logiciel. - Addison-Wesley Publishing Company, 1992. P.
12.3. D. Van Tassel. Programmes de style, de conception, d'efficacité, de débogage et de test. - M. : Mir, 1985.S. 8-44, 117-178.
12.4. Documentation utilisateur du logiciel / Norme ANSI / IEEE 1063-1987.
Cours 13. Documenter les logiciels
13.1. Documentation créée lors du développement du logiciel.
Lors du développement d'un système logiciel, une grande quantité de documentations diverses est créée. Il est nécessaire comme moyen de transfert d'informations entre les développeurs de logiciels, comme moyen de gestion du développement de logiciels et comme moyen de transfert d'informations aux utilisateurs nécessaires à l'application et à la maintenance des logiciels. La création de cette documentation représente une part importante du coût du PS.
Cette documentation peut être divisée en deux groupes :
Documents de gestion du développement logiciel.
Documents qui font partie du PS.
Les documents de gestion du développement logiciel (documentation des processus) enregistrent les processus de développement et de maintenance du logiciel, fournissant des connexions au sein de l'équipe de développement et entre l'équipe de développement et les responsables - personnes gérant le développement. Ces documents peuvent être des types suivants :
Plans, devis, échéanciers. Ces documents sont créés par les managers pour prévoir et gérer les processus de développement et de maintenance.
Rapports d'utilisation des ressources pendant le développement. Créé par les gestionnaires.
Normes. Ces documents prescrivent aux développeurs quels principes, règles, accords ils doivent suivre dans le processus de développement de logiciels. Ces normes peuvent être à la fois internationales ou nationales, et spécialement créées pour l'organisation qui développe ce logiciel.
Documents de travail. Ce sont les principaux documents techniques qui assurent la communication entre les développeurs. Ils contiennent une fixation des idées et des problèmes survenant dans le processus de développement, une description des stratégies et des approches utilisées, ainsi que des versions de travail (temporaires) des documents qui devraient être inclus dans le PS.
Notes et correspondance. Ces documents documentent divers détails de l'interaction entre les gestionnaires et les développeurs.
Les documents inclus dans la PS (documentation du produit) décrivent les programmes PS à la fois du point de vue de leur utilisation par les utilisateurs et du point de vue de leurs développeurs et mainteneurs (conformément à l'objectif de la PS). Il convient de noter ici que ces documents seront utilisés non seulement au stade de l'exploitation du système logiciel (dans ses phases d'application et de maintenance), mais également au stade de développement pour gérer le processus de développement (avec les documents de travail) - dans tous les cas, ils doivent être vérifiés (testés) pour leur conformité avec les programmes PS. Ces documents forment deux ensembles aux finalités différentes :
Documentation utilisateur PS (documentation P).
Documentation de support de sous-station (documentation C).
13.2. Documentation utilisateur des outils logiciels.
La documentation utilisateur du système logiciel (documentation utilisateur) explique aux utilisateurs comment ils doivent procéder pour appliquer ce système logiciel. Il est nécessaire si le PS implique une interaction avec les utilisateurs. Cette documentation comprend les documents qui guident l'utilisateur lors de l'installation du PS (lors de l'installation du PS avec les paramètres appropriés pour l'environnement d'application du PS), lors de l'utilisation du PS pour résoudre ses problèmes et lors du contrôle du PS (par exemple, lorsque ce PS interagit avec d'autres systèmes). Ces documents abordent partiellement les problèmes de support logiciel, mais n'abordent pas les problèmes liés à la modification des programmes.
À cet égard, il convient de distinguer deux catégories d'utilisateurs du PS : les utilisateurs PS ordinaires et les administrateurs PS. Un utilisateur ordinaire du PS (utilisateur final) utilise le PS pour résoudre ses problèmes (dans son domaine). Cela peut être un ingénieur concevant un appareil technique, ou un caissier vendant des billets de train à l'aide d'un PS. Il peut ne pas connaître beaucoup de détails de l'ordinateur ou des principes de programmation. L'administrateur du PS (administrateur système) gère l'utilisation du PS par les utilisateurs ordinaires et maintient le PS qui n'est pas lié à la modification des programmes. Par exemple, il peut réguler les droits d'accès au PS entre utilisateurs ordinaires, rester en contact avec les fournisseurs de PS, ou effectuer certaines actions pour maintenir le PS en état de fonctionnement, s'il fait partie d'un autre système.
La composition de la documentation utilisateur dépend des publics d'utilisateurs auxquels s'adresse ce logiciel, et du mode d'utilisation des documents. Le public ici est compris comme le contingent d'utilisateurs de PS qui ont besoin de certaines documentations d'utilisateur de PS. Un document utilisateur réussi dépend essentiellement de la définition précise du public auquel il est destiné. La documentation utilisateur doit contenir les informations requises pour chaque public. Le mode d'utilisation d'un document fait référence à la manière qui détermine comment le document est utilisé. Typiquement, un utilisateur de systèmes logiciels suffisamment volumineux a besoin soit de documents pour étudier PS (utilisation sous forme d'instructions), soit pour clarifier certaines informations (utilisation sous forme de référence).
Conformément aux travaux, la composition suivante de la documentation utilisateur pour un PS suffisamment grand peut être considérée comme typique :
Description fonctionnelle générale du PS. Donne une brève description de la fonctionnalité du PS. Il est destiné aux utilisateurs qui ont besoin de décider combien ils ont besoin de ce logiciel.
Manuel d'installation PS. Conçu pour les administrateurs système. Il doit prescrire en détail comment installer des systèmes dans un environnement particulier. Il doit contenir une description du support lisible par machine sur lequel le PS est fourni, les fichiers représentant le PS et les exigences pour la configuration matérielle minimale.
Instructions pour l'utilisation de PS. Conçu pour les utilisateurs ordinaires. Contient les informations nécessaires sur l'application du PS, organisées sous une forme pratique pour son étude.
Manuel d'utilisation de PS. Conçu pour les utilisateurs ordinaires. Contient les informations nécessaires sur l'application du PS, organisées sous une forme pratique pour la recherche sélective de pièces individuelles.
Guide de gestion PS. Conçu pour les administrateurs système. Il doit décrire les messages générés lorsque le service PS interagit avec d'autres systèmes et comment répondre à ces messages. De plus, si la MS utilise du matériel système, ce document peut expliquer comment entretenir ce matériel.
Comme mentionné précédemment (voir chapitre 4), le développement de la documentation utilisateur commence dès que la description externe est créée. La qualité de cette documentation peut déterminer de manière significative le succès de la COP. Il doit être assez simple et convivial (sinon, ce PS, en général, n'aurait pas dû être créé). Par conséquent, alors que les ébauches (esquisses) des documents utilisateur sont créées par les principaux développeurs du logiciel, des rédacteurs techniques professionnels sont souvent impliqués dans la création de leurs versions finales. En outre, pour garantir la qualité de la documentation utilisateur, un certain nombre de normes ont été développées (voir, par exemple,), qui prescrivent la procédure d'élaboration de cette documentation, formulent des exigences pour chaque type de documents utilisateur et déterminent leur structure et leur contenu. .
13.3. Documentation de maintenance logicielle.
La documentation du système décrit le système logiciel du point de vue de son développement. Cette documentation est nécessaire si le système logiciel implique l'étude de son agencement (conception), et la modernisation de ses programmes. Comme indiqué, la maintenance est un développement continu. Par conséquent, s'il est nécessaire de moderniser le poste, une équipe spéciale de développeurs de support est impliquée dans ces travaux. Cette équipe devra traiter la même documentation qui a défini les activités de l'équipe de développement logiciel d'origine (principale), à la seule différence que cette documentation pour l'équipe de développement du mainteneur sera, en règle générale, étrangère (elle a été créée par un autre équipe). Les responsables de l'équipe de développement devront étudier cette documentation afin de comprendre la structure et le processus de développement du système logiciel mis à niveau, et apporter les modifications nécessaires à cette documentation, en répétant dans une large mesure les processus technologiques avec lesquels le logiciel d'origine a été créé. .
La documentation pour le support du PS peut être divisée en deux groupes :
(1) la documentation qui définit la structure des programmes et des structures de données des systèmes logiciels et la technologie pour leur développement ;
(2) la documentation pour aider à apporter des modifications au système d'exploitation.
La documentation du premier groupe contient les documents finaux de chaque étape technologique du développement logiciel. Il comprend les documents suivants :
Description externe du SS (Document des exigences).
Description de l'architecture du système, y compris la spécification externe de chacun de ses programmes.
Pour chaque programme PS - une description de sa structure modulaire, y compris la spécification externe de chaque module qui y est inclus.
Pour chaque module - sa spécification et la description de sa structure (description de la conception).
Textes de module dans le langage de programmation sélectionné (listes de code source du programme).
Documents de validation décrivant comment la validité de chaque programme d'AC a été établie et comment les informations de validation ont été liées aux exigences d'AC.
Les documents permettant d'établir la validité des systèmes logiciels comprennent, tout d'abord, la documentation sur les tests (schéma de test et description d'un ensemble de tests), mais peuvent inclure les résultats d'autres types de tests logiciels, par exemple, la preuve des propriétés du programme.
La documentation du deuxième groupe contient
Le guide de maintenance du système, qui décrit les problèmes connus avec le logiciel, décrit quelles parties du système dépendent du matériel et du logiciel, et comment le développement du logiciel est pris en compte dans sa structure (conception).
Un problème courant avec le maintien d'un COP est de s'assurer que tous ses points de vue se maintiennent (restent cohérents) lorsque le COP change. Pour cela, les liens et les dépendances entre les documents et leurs parties doivent être capturés dans la base de données de gestion de configuration.
Littérature pour la conférence 13.
13.1. Ian Sommerville. Génie logiciel. - Addison-Wesley Publishing Company, 1992. P.
13.2. ANSI / IEEE Std 1063-1988, norme IEEE pour la documentation utilisateur des logiciels.
13.3. ANSI / IEEE Std 830-1984, IEEE Guide for Software Requirements Specification.
13.4. ANSI / IEEE Std 1016-1987, Pratique recommandée IEEE pour la description de la conception de logiciels.
13.5. ANSI / IEEE Std 1008-1987, norme IEEE pour les tests unitaires logiciels.
13.6. ANSI / IEEE Std 1012-1986, norme IEEE pour les plans de vérification et de validation des logiciels.
13.7. ANSI / IEEE Std 983-1986, Guide IEEE pour la planification de l'assurance qualité des logiciels.
13.8. ANSI / IEEE Std 829-1983, norme IEEE pour la documentation des tests logiciels.
Cours 14. Certification des outils logiciels
Objectif de la certification du logiciel. Tester et évaluer la qualité des logiciels. Types de tests et méthodes d'évaluation de la qualité des logiciels.
14.1. Objectif de la certification du logiciel.
La certification PS est une confirmation officielle de la qualité PS. En règle générale, une commission représentative (attestation) d'experts, de représentants des clients et des représentants des développeurs est créée pour la certification PS. Cette commission réalise des tests PS afin d'obtenir les informations nécessaires à l'appréciation de sa qualité. Par test PS, nous entendons le processus de réalisation d'un ensemble de mesures qui étudient l'adéquation du PS pour son bon fonctionnement (application et maintenance) conformément aux exigences du client. Ce complexe comprend la vérification de l'exhaustivité et de l'exactitude de la documentation du logiciel, l'étude et la discussion de ses autres propriétés, ainsi que les tests nécessaires des programmes inclus dans le système logiciel et, en particulier, la conformité de ces programmes avec la documentation disponible.
Sur la base des informations obtenues lors des tests du PS, il convient tout d'abord d'établir que le PS exécute les fonctions déclarées, et il convient également d'établir dans quelle mesure le PS dispose des primitives et des critères de qualité déclarés. Ainsi, l'évaluation de la qualité du PS est le contenu principal du processus de certification. L'appréciation de la qualité du PS effectuée est consignée dans la décision correspondante de la commission d'attestation.
14.2. Types de tests logiciels.
Les types de tests PS suivants sont connus aux fins de la certification PS :
test des composants PS;
tests du système ;
tests d'acceptation;
essais sur le terrain;
essais industriels.
Le test des composants PS est un contrôle (test) de l'opérabilité des sous-systèmes PS individuels. Ils ne sont effectués que dans des cas exceptionnels par décision spéciale de la commission d'attestation.
Les tests système d'un PS sont un contrôle (test) du PS dans son ensemble. Il peut inclure les mêmes types de tests que dans le débogage complexe de systèmes logiciels (voir leçon 10). Elle est réalisée par décision de la commission d'attestation, en cas de doute sur la qualité du débogage par les développeurs du système logiciel.
Les tests d'acceptation sont le principal type de tests pour la certification PS. C'est avec ces tests que la commission de certification commence ses travaux. Ces tests commencent par une étude de la documentation fournie, y compris la documentation pour tester et déboguer les systèmes logiciels. Si la documentation ne contient pas les résultats suffisamment complets des tests du PS, le comité de certification peut décider d'effectuer des tests du système du PS ou de mettre fin au processus de certification en recommandant au développeur d'effectuer des tests PS supplémentaires (plus complets). De plus, lors de ces tests, les tests développeurs peuvent être sélectivement ignorés, ainsi que les tâches de contrôle utilisateur (voir leçon 10) et les tests complémentaires préparés par le panel pour évaluer la qualité du logiciel certifié.
Le test sur le terrain d'un PS est une démonstration du PS, ainsi que du système technique qui est contrôlé par ce PS, à un cercle restreint de clients dans des conditions réelles, et une observation attentive du comportement du PS est effectuée. Les clients devraient avoir la possibilité de définir leurs propres cas de test, en particulier, des issues aux modes de fonctionnement critiques du système technique, ainsi que le déclenchement de situations d'urgence dans celui-ci. Il s'agit d'essais complémentaires effectués par décision de la commission d'attestation uniquement pour certains PS maîtrisant certains systèmes techniques.
Le test industriel du PS est le processus de transfert du PS pour un fonctionnement permanent aux utilisateurs. C'est une période d'exploitation pilote de l'aéronef (voir leçon 10) par les utilisateurs avec la collecte d'informations sur les caractéristiques du comportement de l'aéronef et ses caractéristiques opérationnelles. Il s'agit des tests finaux de la PS, qui sont effectués selon la décision de la commission de certification, si des informations complètes ou fiables insuffisantes ont été obtenues lors des tests précédents pour évaluer la qualité de la PS certifiée.
14.3. Méthodes d'évaluation de la qualité des logiciels.
L'évaluation de la qualité du PS pour chacun des critères se réduit à l'appréciation de chacune des primitives associées à ce critère de la qualité du PS, conformément à leur spécification, faite dans la spécification qualité de ce PS. Les méthodes d'évaluation des primitives de la qualité des systèmes logiciels peuvent être divisées en quatre groupes :
mesure directe d'indicateurs d'une primitive de qualité;
traitement de programmes et documentation de PS avec des outils logiciels spéciaux (processeurs);
test des programmes PS;
expertise basée sur l'étude des programmes et la documentation du PS.
La mesure directe des indicateurs de la primitive de qualité est effectuée en comptant le nombre d'occurrences d'unités, d'objets, de structures, etc. caractéristiques, dans un document de programme particulier, ainsi qu'en mesurant le temps de fonctionnement de divers appareils et la quantité de la mémoire de l'ordinateur occupée lors de l'exécution des cas de test. Par exemple, une mesure de l'efficacité de la mémoire peut être le nombre de lignes de code dans un langage de programmation, et une certaine mesure de l'efficacité du temps peut être le temps de réponse des requêtes. L'utilisation de tout indicateur pour les primitives de qualité peut être définie dans la spécification de qualité du système logiciel. La méthode de mesure directe des indicateurs d'une primitive de qualité peut être combinée avec l'utilisation de programmes de test.
Pour établir la présence de certaines primitives de qualité dans le logiciel, certains outils logiciels peuvent être utilisés. De tels outils logiciels traitent des textes de programmes ou de documentation logicielle afin de contrôler d'éventuelles primitives de qualité ou d'obtenir certains indicateurs de ces primitives de qualité. Pour évaluer la structuration des programmes PS, s'ils étaient programmés dans un dialecte structurel approprié du langage de programmation de base, il suffirait de les passer par le convertisseur de programmes structurés, qui effectue un contrôle syntaxique et sémantique de ce dialecte et traduit le les textes de ces programmes dans la langue d'entrée du traducteur de base. Cependant, de cette manière à l'heure actuelle, il n'est possible de contrôler qu'un petit nombre de primitives de qualité, et même alors dans de rares cas. Dans certains cas, au lieu d'outils logiciels qui contrôlent la qualité des systèmes logiciels, il est plus utile d'utiliser des outils qui transforment la présentation des programmes ou la documentation des logiciels. Tel est, par exemple, un formateur de programme qui donne aux textes de programme une forme lisible - le traitement des textes de programme PS avec un tel outil peut automatiquement garantir la disponibilité d'une primitive de qualité appropriée dans le PS.
Le test est utilisé pour évaluer certaines primitives de la qualité du service PS. Ces primitives comprennent, tout d'abord, l'exhaustivité du PS, ainsi que sa précision, sa stabilité, sa sécurité et d'autres primitives de qualité. Dans un certain nombre de cas, les tests sont utilisés en combinaison avec d'autres méthodes pour évaluer les primitives individuelles de la qualité des systèmes logiciels. Ainsi, pour évaluer la qualité de la documentation pour l'application d'un système logiciel (P-documentation), le test est utilisé en combinaison avec une expertise de cette documentation. Si, lors du débogage complexe du système logiciel, un test suffisamment complet a été effectué, les mêmes tests peuvent être utilisés pour l'attestation du système logiciel. Dans ce cas, le comité de certification peut utiliser les protocoles de tests réalisés lors de débogages complexes. Cependant, même dans ce cas, il est nécessaire d'effectuer de nouveaux tests ou au moins de réexécuter certains des anciens. Si les tests au cours d'un débogage complexe sont jugés insuffisamment complets, il est alors nécessaire d'effectuer des tests plus complets. Dans ce cas, une décision peut être prise de tester les composants ou les tests système du PS, ainsi que de renvoyer le PS aux développeurs pour révision. Il est très important qu'afin d'évaluer le système logiciel selon le critère de facilité d'utilisation, des tests complets aient été effectués (lors du débogage et de l'attestation du logiciel) à l'aide de tests préparés sur la base de la documentation de l'application, et selon les critère de maintenabilité - selon des tests préparés pour chacun des documents proposés pour la maintenance.
Pour l'évaluation de la plupart des primitives de la qualité des systèmes logiciels, à l'heure actuelle, seule la méthode des expertises peut être utilisée. Cette méthode consiste en ce qui suit : un groupe d'experts est désigné, chacun de ces experts, à la suite de l'étude de la documentation soumise, se fait sa propre opinion sur la possession du PS avec la primitive de qualité requise, puis l'évaluation de la La primitive de qualité PS requise est établie par vote des membres de ce groupe. Cette évaluation peut se faire à la fois selon un système en deux points (« possède » - « ne possède pas »), et aussi prendre en compte le degré de possession du PS par cette primitive de qualité (par exemple, elle peut être faite selon un système en cinq points). Dans ce cas, le groupe d'experts doit s'inspirer de la spécification de cette primitive et d'une indication de la méthode pour son évaluation, formulée dans le cahier des charges qualité de la PS certifiée.
Littérature pour la conférence 14.
14.2. V.V. Lipaev. Tester les programmes. - M. : Radio et communication, 1986.-- S. 231-245.
14.3. D. Van Tassel. Programmes de style, de conception, d'efficacité, de débogage et de test. - M. : Mir, 1985.-- S. 281-283.
14.4. B. Shneiderman. Psychologie de la programmation. - M. : Radio et communication, 1984.-- S. 99-127.
Cours 15 Approche objet du développement logiciel
15.1. Objets et relations en programmation. L'essence de l'approche objet du développement logiciel.
Le monde qui nous entoure se compose d'objets et des relations entre eux. Un objet incarne une essence et a un certain état qui peut changer avec le temps en raison de l'influence d'autres objets qui sont en relation avec l'objet donné. Il peut avoir une structure interne : il peut être constitué d'autres objets qui sont également entre eux dans une certaine relation. Sur cette base, vous pouvez construire une structure hiérarchique du monde à partir d'objets. Cependant, pour chaque considération spécifique du monde qui nous entoure, certains objets sont considérés comme indivisibles (« point »), et selon les objectifs de la considération, ces objets (indivisibles) peuvent être pris à différents niveaux de la hiérarchie. La relation relie certains objets : on peut supposer que l'union de ces objets a une propriété. Si une relation relie n objets, alors une telle relation est appelée n-aire (n-aire). A chaque endroit de l'union d'objets qui peuvent être reliés par une relation spécifique, il peut y avoir des objets différents, mais bien définis (dans ce cas, on dit : des objets d'une certaine classe). Une relation à une place est appelée propriété d'un objet (de la classe correspondante). L'état d'un objet peut être étudié par la valeur des propriétés de cet objet ou implicitement par la valeur des propriétés d'unions d'objets associées à telle ou telle relation.
Dans le processus de connaissance ou de changement du monde qui nous entoure, nous prenons toujours en considération l'un ou l'autre modèle simplifié du monde (le monde modèle), dans lequel nous incluons certains des objets et certaines des relations du monde qui nous entoure et , en règle générale, un niveau de la hiérarchie. Chaque objet avec une structure interne peut représenter son propre monde modèle, qui comprend les objets de cette structure et les relations qui les relient. Ainsi, le monde qui nous entoure peut être considéré (dans une certaine approximation) comme structure hiérarchique mondes modèles.
Actuellement, dans le processus de connaissance ou de changement du monde qui nous entoure, la technologie informatique est largement utilisée pour traiter divers types d'informations. À cet égard, une représentation informatique (informationnelle) des objets et des relations est utilisée. Chaque objet peut être représenté de manière informationnelle par une structure de données qui reflète son état. Les propriétés de cet objet peuvent être définies directement en tant que composants séparés de cette structure, ou par des fonctions spéciales sur cette structure de données. Les relations n-aires pour N> 1 peuvent être représentées soit sous une forme active, soit sous une forme passive. Dans la forme active, une relation N-locale est représentée par un fragment de programme qui implémente soit une fonction N-locale (qui détermine la valeur d'une propriété de l'union d'objets correspondante), soit une procédure qui modifie les états de certains des les en fonction de l'état des représentations des objets liés par la relation représentée. Sous une forme passive, une telle relation peut être représentée par une certaine structure de données (qui peut inclure des représentations d'objets connectés par cette relation), interprétée sur la base de conventions acceptées pour des procédures générales qui ne dépendent pas de relations spécifiques (par exemple, une base de données relationnelle). Dans tous les cas, la vue des relations définit certaines des activités de traitement des données.
Lorsqu'il explore le monde des modèles, un utilisateur peut recevoir (ou vouloir recevoir) des informations d'un ordinateur de différentes manières. Avec une approche, il peut être intéressé à obtenir des informations sur les propriétés individuelles des objets qui l'intéressent ou les résultats de toute interaction entre certains objets. Pour ce faire, il ordonne le développement de l'un ou l'autre système logiciel qui exécute les fonctions qui l'intéressent, ou de quelque système d'information capable de fournir des informations sur les relations qui l'intéressent, à l'aide de la base de données appropriée. Dans la période initiale du développement de la technologie informatique (avec une puissance des ordinateurs insuffisamment élevée), cette approche de l'utilisation des ordinateurs était tout à fait naturelle. C'est lui qui a provoqué l'approche fonctionnelle (relationnelle) du développement des systèmes logiciels, qui a été discutée en détail dans les conférences précédentes. L'essence de cette approche consiste en l'utilisation systématique de la décomposition de fonctions (relations) pour construire la structure du PS et les textes des programmes qui y sont inclus. Dans le même temps, les objets eux-mêmes, auxquels les fonctions ordonnées et implémentées étaient appliquées, étaient présentés de manière fragmentaire (dans la mesure nécessaire pour exécuter ces fonctions) et sous une forme pratique pour la mise en œuvre de ces fonctions. Ainsi, une représentation informatique intégrale et adéquate du monde modèle intéressant l'utilisateur n'a pas été fournie : le mapper sur le SS utilisé pourrait être une tâche plutôt laborieuse pour l'utilisateur, des tentatives d'augmenter légèrement le volume et la nature des informations sur le modèle monde intéressant pour l'utilisateur. reçus de ces sous-stations, pourraient conduire à leur modernisation sérieuse. Cette approche du développement logiciel est supportée par la plupart des langages de programmation utilisés, allant des langages d'assemblage et langages procéduraux (FORTRAN, Pascal) aux langages fonctionnels (LISP) et langages de programmation logique (PROLOGUE) .
Avec une autre approche de l'étude du monde modèle à l'aide d'un ordinateur, l'utilisateur peut être intéressé à observer le changement d'état des objets en raison de leurs interactions. Cela nécessite une représentation assez intégrale dans l'ordinateur de l'objet qui intéresse l'utilisateur, et les composants logiciels qui mettent en œuvre les relations auxquelles cet objet participe lui sont explicitement associés. Pour mettre en œuvre cette approche, il a été nécessaire de construire un logiciel qui simule les processus d'interaction des objets (monde modèle). Avec les outils de développement traditionnels, cela s'est avéré être une tâche plutôt fastidieuse. Certes, des langages de programmation sont apparus spécifiquement axés sur une telle modélisation, mais cela n'a que partiellement simplifié la tâche de développement des systèmes logiciels requis. L'approche objet du développement de systèmes logiciels répond le mieux à la solution de ce problème. Son essence réside dans l'utilisation systématique de la décomposition des objets dans la construction de la structure du PS et des textes des programmes qui y sont inclus. Dans ce cas, les fonctions (relations) remplies par un tel PS étaient exprimées à travers les relations d'objets de différents niveaux, c'est-à-dire que leur décomposition dépendait de manière significative de la décomposition des objets.
En parlant de l'approche objet, il faut aussi bien comprendre de quel type d'objets on parle : objets du monde modèle de l'utilisateur, leur représentation informationnelle, objets de programme à l'aide desquels le système logiciel est construit. De plus, il faut distinguer les objets propres (objets « passifs ») et les sujets (objets « actifs »).
15.2. Objets et sujets en programmation.
15.3. Approches objet et subjective du développement logiciel.
Descartes a noté que les gens ont généralement une vision du monde orientée objet (en).
On pense que la conception orientée objet est basée sur les principes suivants :
mettre en évidence des abstractions,
Limitation d'accès,
modularité,
hiérarchie,
dactylographie,
parallélisme,
durabilité.
Mais tout cela peut être appliqué avec une approche fonctionnelle.
Il est nécessaire de distinguer les avantages et les inconvénients de l'approche objet générale et son cas particulier, l'approche orientée sujet.
Avantages d'une approche objective générale :
Cartographie naturelle du monde réel à la structure du PS (perception humaine naturelle des capacités du PS, il n'est pas nécessaire « d'inventer » la structure du PS, mais d'utiliser des analogies naturelles).
L'utilisation d'unités structurelles suffisamment significatives du PS (un objet comme l'intégrité des associations non redondantes, des modules d'information forte).
Réduire la complexité du développement de systèmes logiciels en utilisant un nouveau niveau d'abstractions (en utilisant une hiérarchie d'abstractions « non-programmatiques » dans le développement de systèmes logiciels : la classification des objets dans le monde réel, la méthode des analogies dans la nature) comme un nouveau niveau d'héritage .
15.4. Une approche basée sur les objets pour le développement d'une description externe et d'une architecture d'un outil logiciel.
Conception orientée objet - Une méthode utilisant la décomposition d'objets ; l'approche orientée objet a sa propre notation et offre un riche ensemble de modèles logiques et physiques pour la conception de systèmes très complexes. ...
L'analyse orientée objet (OOA) a rendu l'approche objet. OOA vise à créer des modèles plus proches de la réalité en utilisant une approche orientée objet ; c'est une méthodologie dans laquelle les exigences sont formées sur la base des concepts de classes et d'objets qui composent le vocabulaire du domaine. ...
Caractéristiques de la programmation orientée objet.
Objets, classes, comportement des objets, propriétés, événements.
Littérature pour la conférence 15.
15.1. K. Fuchi, N. Suzuki. Langages de programmation et circuits VLSI. - M. : Mir, 1988.S. 85-98.
15.2. Ian Sommerville. Génie logiciel. - Addison-Wesley Publishing Company, 1992. P.?-?
15.3. G. Booch. Conception orientée objet avec exemples d'application : par. de l'anglais - M. : Concorde, 1992.
15.4. V. Sh. Kaufman. Langages de programmation. Concepts et principes. M. : Radio et communication, 1993.

Développement d'un module logiciel. Programmation structurée. PM.01. Développement de modules logiciels pour systèmes informatiques Développement de programmes de modules de modules logiciels

INTRODUCTION

1 DÉVELOPPEMENT D'UN ALGORITHME POUR LE PROBLÈME ÉNONCÉ ET MISE EN UVRE DE SES MOYENS DE CONCEPTION AUTOMATISÉE

1.1 Analyse de la tâche

1.2 Choix des méthodes et développement des algorithmes de base pour la résolution

2 DEVELOPPEMENT DU CODE PRODUIT LOGICIEL SUR LA BASE D'UNE SPECIFICATION PRETE AU NIVEAU DU MODULE

3. UTILISATION DES OUTILS AU STADE DE DEBOGAGE DU MODULE LOGICIEL

4 TEST DU MODULE LOGICIEL POUR UN SCÉNARIO SPÉCIFIQUE

5 ENREGISTREMENT DE LA DOCUMENTATION SUR LE LOGICIEL

CONCLUSION

LISTE DE RÉFÉRENCES

ANNEXE A

Cours 8. Développement d'un module logiciel

8.1. La procédure de développement d'un module logiciel.

8.2. Programmation structurée.

8.3. Détaillant étape par étape et le concept de pseudocode.

8.4. Contrôle du module de programme.

Littérature pour le cours 8.

Cours 9. Preuve des propriétés du programme

9.1. Justification des programmes. Formalisation des propriétés du programme.

9.2. Propriétés des opérateurs simples.

9.3. Propriétés des structures de base de la programmation structurée.

9.4. Complétude de l'exécution du programme.

9.5. Un exemple de preuve d'une propriété d'un programme.

Littérature pour le cours 9.

Cours 10. Tester et déboguer des logiciels

10.1. Concepts de base.

10.2. Principes et types de débogage.

10.3. Commandes de débogage.

10.4. Déboguer un module hors ligne.

10.5. Débogage de logiciels complexes.

Littérature pour le cours 10.

Cours 11. Assurer la fonctionnalité et la fiabilité du logiciel

11.1. Fonctionnalité et fiabilité comme critères obligatoires pour la qualité du logiciel.

11.2. S'assurer de l'exhaustivité de l'outil logiciel.

11.3. Assurer l'exactitude du logiciel.

11.4. Assurer l'autonomie du logiciel.

11.5. Assurer la stabilité du logiciel.

11.6. Assurer la sécurité des logiciels.

Littérature pour la conférence 11.

Cours 12. Assurance qualité du logiciel

12.1. Caractéristiques générales du processus d'assurance de la qualité des outils logiciels.

12.3. Assurer l'efficacité du logiciel.

Littérature pour la conférence 12.

Cours 13. Documenter les logiciels

13.1. Documentation créée lors du développement du logiciel.

13.2. Documentation utilisateur des outils logiciels.

Littérature pour la conférence 13.

Cours 14. Certification des outils logiciels

14.1. Objectif de la certification du logiciel.

14.2. Types de tests logiciels.

14.3. Méthodes d'évaluation de la qualité des logiciels.

Cours 15 Approche objet du développement logiciel

15.1. Objets et relations en programmation. L'essence de l'approche objet du développement logiciel.

15.2. Objets et sujets en programmation.

15.3. Approches objet et subjective du développement logiciel.

15.4. Une approche basée sur les objets pour le développement d'une description externe et d'une architecture d'un outil logiciel.

Littérature pour la conférence 15.