Les bases du génie logiciel : Apprendre le cycle de développement logiciel pour mieux programmer

1. Vidéo d'introduction: Bonjour à tous, tous, et bienvenue au partage de compétences et à ce cours de logiciel. Dans ce cours, nous discuterons principalement du cycle de développement logiciel. Donc, le cycle de développement de logiciels est vraiment juste un ensemble de différentes étapes que vous pouvez prendre pour concevoir de meilleurs logiciels. Si vous concevez, par exemple, une petite calculatrice, vous n'avez pas besoin de beaucoup de pratique préalable et de comprendre les détails. C' est une petite application. Ça pourrait être, vous savez, peut-être 100 lignes de code. Peut-être que c'est plus grand et c'est, vous savez, 1000 lignes de code ou même 10 000 lignes de code. Ces projets ne nécessitent pas beaucoup de planification pour réussir, car une fois que vous avez conçu les 10 000, vous pouvez tout avoir en tête. Vous pouvez revenir en arrière et vous pouvez le retravailler, améliorer les choses, et ce ne sera pas trop difficile. Ce qui commence à devenir problématique, c'est quand vous entrez dans plus grand que cela. Si vous avez 100 000 lignes de code, soudainement il y a beaucoup de choses qui interagissent les unes avec les autres. Les bugs commencent à entrer en jeu que vous ne vous attendiez pas, et ces bugs commencent à être vraiment, vraiment complexes au lieu d'un bug qui contacte simplement un autre endroit. Disons que dans une application plus petite, vous avez un bug qui se propage comme ça, c'est facile à suivre. Tu sais, c' est toi qui commence ici. Vous regardez ce morceau de code. Vous regardez ce morceau de code, vous corrigez le bug quand vous obtenez les plus gros morceaux. grands programmes ont soudainement des bugs qui ressemblent à ceci où tout se parle les uns aux autres. Et si vous n'avez pas de plan ni de diagramme, un bug peut ressembler à 100 endroits différents, et vous devez être capable de trouver des trucs comme ça. Vous devez également comprendre comment le concevoir afin que vous puissiez l'étendre plus tard. Si vous voulez agrandir votre projet, vous avez besoin d'une banque pour qu'il soit dans un état où vous pouvez l'ajouter facilement. Et c'est ce que tout cela va détailler. Nous allons donc commencer, ce qui est en train de passer par le cycle de développement logiciel. Nous allons ensuite parler des exigences et des spécifications. Cette étape est vraiment juste de comprendre ce que nous essayons de construire, et ensuite comment nous allons le construire. Nous allons ensuite dans l'architecture, ce qui est en quelque sorte vraiment, vraiment grande vue vers le bas. Quels sont les modèles qui allaient utiliser ? Quelles sont les différentes façons de connecter réellement les différentes parties ? Comment pourrions-nous le briser pour qu'un tas de gens puissent y travailler ? Ils allaient regarder la conception du logiciel. Une fois que nous avons rompu en une partie, nous devons comprendre comment chacune de ces pièces va être construite. C' est là que vous commencez à concevoir des choses. Vous commencez à regarder quelles boucles ? Quelles bibliothèques. Quelles sont les différentes façons de stocker les données dont vous avez besoin pour chacune de ces parties ? Ensuite, nous allons entrer dans la mise en œuvre. C' est à ce moment que tu as vraiment transmis les orteils. Les développeurs et les développeurs commencent à le coder. Donc nous regardons quelque chose comme ça où nous avons un gros problème et qu'ils le décomposent en, disons, un tas de boîtes de ce genre. Ensuite, nous décomposons ces boîtes encore plus loin. Et puis maintenant, nous commençons à mettre des développeurs sur chacune de ces boîtes pour commencer à le construire . Ensuite, nous examinons le déploiement. Une fois que nous avons tout cela ensemble, comment pouvons-nous en faire une grande unité cohésive et ensuite comment prendre cette unité cohésive et l'amener dans le monde réel pour construire une application iPhone ? Comment on l'emmène dans le magasin ? Si nous construisons un ordinateur de bureau, comment pouvons-nous l'obtenir pour que les gens puissent l'acheter ? Donc le déploiement est important et enfin, les tests et ces deux types de choses vont et viennent ? Les tests sont généralement effectués avant le déploiement, mais beaucoup de fois que nous déployons dans le monde d'aujourd'hui déploiera un produit minimum viable ou quelque chose qui est rapide recevra des commentaires, détectera des bugs et des erreurs, puis nous allons les corriger par la suite et garder ce genre de boucle de , de déploiement, test, de déploiement,de test ou en fait être une sorte de test, puis revenir au sommet jusqu' au sommet. Et vous allez en quelque sorte dans ce cycle de refonte et de mise à jour continue et maintenance de votre logiciel. Donc, dans ce cours, c'est ce que nous allons apprendre. Nous apprenons toutes ces étapes sur la façon de construire de meilleurs logiciels, comment organiser votre logiciel et, dans l'ensemble, comment nous assurer que lorsque vous construisez quelque chose de volumineux, cela finit par fonctionner. En fin de compte 2. 1-1 Pourquoi utiliser des modèles: parlons de l'importance du cours en général. Pourquoi utilisons-nous des modèles logiciels et de l'ingénierie logicielle ? Pourquoi ne pas simplement coder le truc ? Pourquoi ne pas entrer et faire le projet ? Eh bien, cela devient plus évident quand on pense à un autre projet, quelque chose qui est dans le monde physique. Parlons de construire un pont. Imaginez si vous construisez un pont et que vous commencez de chaque côté. Donc vous avez, genre, cette rivière et vous commencez à construire du côté gauche et du côté droit et vous rejoignez au milieu. Beaucoup de ponts sont créés comme ça parce que vous pouvez le créer deux fois plus vite au lieu d'avoir à construire à partir de la droite et à traverser tout le chemin. Vous pouvez réellement commencer des deux côtés avec deux équipes de construction et juste se rencontrer au milieu. Au Japon, la balle forme les grands vieux chemins de fer. En fait, il a commencé dans huit ou neuf endroits différents, et ils se contentent de connecter la fin. Imaginez, cependant, si ce pont ici, si elle se connectait au milieu et il était comme 10 pieds les uns des autres, Donc, au lieu de ce pont droit parfait, nous avons maintenant une partie des voies sur le droite et une partie des voies sur la gauche qui en fait juste aller tout droit dans l'océan. Ce serait une catastrophe. Ce pont serait rendu inutile. Nous ne serions pas en mesure de travailler avec elle. Et l'ingénierie logicielle, on pourrait considérer ces deux côtés. Ah, Bug. Ah, assez gros insecte. Mais juste un insecte. Et de gauche et de droite, peut-être en haut. Peut-être qu'à l' arrière, il pourrait sembler que le pont fonctionne. Cependant, la structure n'est pas saine. Pas sur Lee. Pourrait-il tomber à cause de ça ? Mais aussi, il pourrait y avoir ce problème où les gens conduisent juste dans l'océan. C' est une catastrophe pour l'entreprise de construction, car maintenant, non seulement ils doivent payer pour construire le pont la première fois, mais ils doivent aussi payer pour le déconstruire et reconstruire le pont correctement. Et ça a coûté beaucoup d'argent. Et peut-être que la société de construction est en panne. Il doit être abandonné. Et maintenant, nous avons juste ce pont qui va pourrir. Et nous n'avons pas vraiment de solution pour le problème. On essaie de réparer. Voilà donc quel est l'importance de toute cette planification. Ils ont raté un seul plan. Accepté. Ça coûte des millions. Beaucoup de gens ne pensent pas que cela puisse arriver. Et l'ingénierie logicielle je vais juste le réparer plus tard. C' est tout du code. Affaiblir, supprimer et réécrire. Cependant, chaque fois que vous entrez dans des millions de lignes de code, cela devient un problème. Amazon, par exemple, je pense, a plus de 10 millions de lignes de code ou même plus de même avec Facebook et toutes ces grandes entités. Ils ont tout ce code. Imaginez si vous avez créé un bug là-dedans qui se représente sur, par exemple, sur Facebook sur la page des amis. Mais c'est en fait quelque chose à voir avec le flux de chronologie. Imaginez à quel point ce serait difficile à déboguer. C' est quelque chose qu'on appelle la dette technique. C' est ma définition. Ah, pauvre difficile à comprendre la mise en œuvre hacky, qui devra re remboursé avec intérêt plus tard. Donc, cela se résume vraiment à couper des coins au début, ne pas vraiment planifier quelque chose et juste sauter dedans. On dirait que ça marche maintenant que tu as fait un petit test rapide. n'y a pas d'insectes, donc, vous savez, économisez une heure ou deux de planification, et maintenant vous pouvez passer à la prochaine chose. Cependant, cela pourrait vous coûter 20 heures plus tard. Imaginez que c'est juste une petite ligne dans un fichier et que vous le mettez là et que vous ne documentez pas et il n'y a pas de plans d'orteils. Pourquoi tu l'as mis là-dedans ? Aussi pas de commentaires pour expliquer pourquoi vous l'avez mis là maintenant, 68 mois plus tard. 68 mois. Peut-être que c'est trois ans plus tard, en fait, cette ligne que vous mettez là crée un bug. Un autre programmeur vient essayer de le réparer. Il doit non seulement trouver la ligne originale que vous mettez là, mais peut-être qu'il ne met pas de bug dans ce fichier. Peut-être qu'il crée réellement un bogue sur une partie complètement différente du serveur. Il doit donc passer par tout le processus de traçage pour revenir à cette ligne de code. Et puis une fois qu'il le voit, oui, pour comprendre ce qu'il était censé dio chercher la bonne façon de le faire, documenter la bonne façon de le faire, puis fixer la ligne. C' est beaucoup plus de travail que vous le faites au tout début, où vous comprenez déjà comment cette chose est construite et vous venez de mettre la bonne ligne de code là-dedans. Donc, avec cet exemple, vous pouvez voir rapidement comment les coûts pourraient aller et monter en flèche plus longtemps qu'ils attendent, car il n'y a peut-être que 10 fichiers ici. Et dans quatre mois, il y a peut-être jusqu'à 400 fichiers. Et quand nous entrons dans le développement, peut-être que nous avons quelque chose comme 1000 fichiers différents à vérifier. Et cette petite ligne un manteau devient de plus en plus difficile, de plus en plus difficile à trouver, surtout s'il y a de mauvaises pratiques de programmation ailleurs dans la production. Et ce genre de chose peut réellement mener à ça. Ce nombre 80 des 20% des projets échoués. C' est une statistique réelle. J' oublie de quelle étude provenait, mais elle était semi récente et imaginez toutes ces entreprises qui créent des logiciels qui peuvent coûter des millions de dollars. Cela signifie que 20% de ces logiciels de 1 000 000$ sont juste qu'ils échouent. La société vient de gaspiller leur argent et ne doit rien récupérer. n'y a pas de r a y, pas de retour sur investissement du tout. C' est vraiment, vraiment mauvais pour l'entreprise. Selon une étude récente, ce coût est de 85 milliards de dollars par année. Et cela se résume généralement à cela. C' est un développeur typique, Spence. 13,5 heures sur cette dette technique, puis 3,8 heures sur la correction ou le débogage de code incorrect supplémentaire ou même l'ajout de code plus mauvais. Donc, vous savez que vous êtes assis ici et que vous dépensez tout ce temps et cet argent pour corriger vieilles erreurs, et vous pourriez même mettre en œuvre des erreurs MAWR plus tard. Et c'est un gros coût. C' est pour un développeur qui paie 50$ de l'heure. Ça pourrait être, tu sais, c'est environ 700$ par semaine pour chaque développeur que tu gaspilles parce que les gens coupent des virages au tout début. Donc, l'ingénierie logicielle dans son ensemble nous permet de nous réunir, créer un plan central et d'empêcher un grand nombre de ces bugs regardant ce code, c'est juste un exemple très rapide. Donc vous pouvez voir juste quelque chose de physique à regarder est imaginer. Vous êtes tombé sur cette ligne de code et vous vouliez savoir ce qu'elle fait maintenant. Typiquement, ce n'est pas vous savez, ce n'est pas trop dur, mais ça pourrait être vraiment, vraiment, vraiment difficile si quelqu'un venait de sortir du fond dans, tu sais, revêtement de cette chose. Mais en ce moment, nous devons regarder ça. Nous devons comprendre ce que cela fait. Et donc on pourrait même devoir, comme, tu sais, prendre un petit bout de papier et être comme, OK, vrai. D' accord. Faux données. Oh, ok. Cette ligne de code est complètement équivalente à ce bloc entier, et cela peut être nous jeter hors. Peut-être que ça perdra 10 minutes de notre temps à réparer, même si ce n'est que 10 minutes. Si nous payons 50$ de l'heure, c'est quelques dollars de temps d'entreprise. Et pas seulement cela, mais disons que tout le fichier ou chaque fois que le programmeur voulait le faire ici, il y a juste une vérification pour savoir si a et B sont les deux notes Knoll. En même temps, il a ajouté ceci chaque fois qu'un programmeur rencontre va perdre ce temps, et cela augmente la dette technique encore et encore et encore. Donc, en fin de compte, ce que j'essaie de dire, c'est que la partie importante de ce cours est d'apprendre que le design est important. Si vous voulez créer quelque chose qui est, vous savez, plus grand qu'un petit ajout ou un petit jeu ou quelque chose comme ça, puis le concevoir pour qu'il puisse être étendu, il pourrait être collaboré sur, et il ne crée pas ces situations vraiment mauvaises plus tard est important. Et c'est que nous allons aller sur ce cours est comment faire. Tout cela, c'est comment élaborer un plan et comment se joindre à une équipe et comprendre de quoi ils parlent. 3. Cycle de développement logiciel: Nous allons donc entrer dans le genre de cycle de développement de logiciels, la façon dont nous concevons des logiciels avec des logiciels. Il y a un tas de différentes façons que vous pouvez le faire et ces modèles généralement appelés, et c'est ainsi que vous implémentez réellement ce genre de cinq étapes. Cependant, ces cinq étapes sont généralement cruciales pour mettre un logiciel en conformité avec des normes qui sont, vous savez, très fiables. Avec cela, vous remarquerez également que ceux-ci peuvent être appliqués à vraiment toutes les pratiques d'ingénierie de ce genre lors la dernière conférence. Quand je parle de construire un pont, ça pourrait être utilisé pour ça aussi. Nous passerions en revue les exigences et la conception, la mise en œuvre et la vérification et entretien avec un pont. Donc, si nous voulons y penser comme ça pendant que nous traversons ça, ça pourrait le faire coller un peu mieux. La première chose dont nous voulons parler est que nous voulons parler de quelque chose appelé exigences, sorte que les exigences sont assez simples. Les exigences sont ce que nous construisons ? Donc, les exigences sont le quoi ? Qu' est-ce qu'on va construire ? Nous voulons être en mesure de faire en sorte que personne ne puisse faire face à ce que nous construisons . Ce que je veux dire par là, c'est que nous ne voulons pas qu'un groupe de huit personnes construise tout cela avec une idée différente de ce que sera le produit final. On ne veut pas qu'ils pensent que, vous savez, peut-être qu'une personne pense qu'elle va utiliser huit serveurs. On pense que ça va être un serveur local. On pense que là où ça va être un business run, comme ça va être utilisé principalement par des gens d'affaires. Alors que quelqu'un d'autre pense que ça va être utilisé principalement par les consommateurs. Ce serait un gros problème si vous essayez d'obtenir comme un tas de personnes pour travailler ensemble sur un projet que tout le monde construirait dans une direction différente et qu'il s'effondrerait . Donc, avec les exigences, ce que nous essayons d'obtenir, c'est ce que nous construisons ? Et il y a un tas de différents petits pas dans chacun d'entre eux, et c'est le genre de ce cours qui va faire sauter dans le Donc c'est juste une vue de haut en bas et je vais faire une plongée profonde, un peu plus tard. Donc, de toute façon, les exigences sont 1er 2ème est la conception. design est le Comment alors comment allons-nous le construire ? Qu' est-ce qu'on va utiliser ? Quel genre de technologies qu'on va mettre en place ? Comment avec le serveur va être installé ? Comment le front va-t-il être mis en place ? Le front end faire ceci ou cela ? C' est là que le design entre en jeu et que le design est très important. Beaucoup de gens ignorent cette étape. Ah, beaucoup de gens vont faire les exigences, mais ils vont faire les exigences, mais alors ils ne vont pas vraiment aller au design. Ils sont juste en quelque sorte sauter directement dans la mise en œuvre. Donc tu sais, ils seront comme, OK, on a une bonne idée de ce qu'on va construire. Sautons dans la mise en œuvre. Et cela pourrait être dangereux parce que encore une fois, il y a encore quelques variables ici, et il y a encore des choses que nous voulons nous assurer de travailler avant de les implémenter. Parce que, par exemple, disons que vous avez construit un chef-d'œuvre géant à huit serveurs ou au moins vous pensez que c'est un chef-d'œuvre. Et puis quand vous cliquez, vous connaissez le bouton de lecture, vous le faites enfin fonctionner. Tu réalises, Oh, ça ne marche pas avec huit serveurs. Il ne fonctionne qu'avec le service. Cela ne fonctionne qu'avec ce genre de technologie. Je vais devoir redémarrer et commencer dès le début. C' est le genre de choses que vous voulez travailler dans la partie design. La partie comment Après que vous allez concevoir, nous sauterons dans la mise en œuvre et tout le monde sait ce qu'est la mise en œuvre. La mise en œuvre est que vous construisez la chose. Donc tu as fait toute la planification. Tout le monde est sur la même page. Maintenant tu vas le diviser en peut-être que tu as des équipes. Peut-être que c'est juste un groupe de trois personnes. Peut-être que c'est juste toi-même, et tu vas juste entrer dans certaines et tu vas juste entrer dans certaines tâches et jalons. Mais la partie d'implémentation est la partie de construction que vous allez construire le produit, vous allez créer ce que vous avez prévu de créer, puis l'étape suivante est la vérification. Donc, avec la vérification, ce que nous faisons est quelque chose qui s'appelle le test. Nous essayons donc de trouver ici une question cruciale. Ce que nous avons construit, c'est ce que nous voulions construire ? C' est souvent des fois ah, couple des choses différentes. Ainsi, par exemple, ce que nous avons construit ce que nous voulions construire est ce que nous avons construit. Ce que notre client voulait que nous construisions, c'est ce que nous avons construit pour fonctionner correctement. Est-ce que c'est l'entrée en jeu ? Et c'est, vous savez, créer la bonne sortie. Et c'est pourquoi le test vient dans un jeu, et généralement avec les tests, vous devez connaître les exigences. Vous devez savoir ce qu'il était censé faire et ensuite avec le test Utkan contre cela ne fait pas ce qu'il était censé dio. C' est donc une étape très importante. Et c'est un autre qui est souvent une sorte de fois pour obtenir. Si le temps crunch les gens comme, Oh, non, ne vous inquiétez pas des tests fera juste quelques tests majeurs rapides et ensuite on passera à autre chose. Et ça pourrait être un gros problème parce que vous avez ces bugs géants dans votre programme. Peut-être qu'ils ne se manifestent pas avant quelques années, et ensuite cela mène à une violation géante de la sécurité des données. Ou peut-être que c'est juste quelque chose de très petit au fil du temps. Peut-être que toutes les données qui entrent dans la base de données sont désactivées d'une seule, et cela va en quelque sorte fausser vos données, et alors cela coûtera beaucoup plus tard dans la phase de maintenance, qui est cette phase juste ici pour finir par les réparer. La vérification et les tests sont donc importants. Nous aborderons certaines techniques à ce sujet et certaines des façons dont vous devriez tester. Et enfin, ce que nous avons, c'est que nous avons de l'entretien. Et c'est ce genre de cycle de fin où vous allez réparer des bugs. Vous allez aussi être en quelque sorte peut-être même faire plus de tests peut être implémenter d'autres choses , peut-être reconcevoir des choses. trucs de maintenance sont en quelque sorte la façon dont cela remonte beaucoup de fois. Si, par exemple, vous développez une fonctionnalité supplémentaire, vous retournerez en fait jusqu'aux exigences, puis recommencerez ce processus . Mais le cycle de maintenance est généralement juste de corriger des bogues, en s'assurant que, comme de petits ajustements pour le rendre plus conforme aux exigences et le garder en cours d'exécution pour me faire ne pas faire de mises à jour de serveur et mettre à jour cette technologie dans ce technologie. La maintenance est donc importante et la maintenance peut être très, très difficile si vous ne faites pas toutes ces étapes. Donc, il pourrait y avoir une tonne de bogues si vous n'avez pas tous ces bogues, et surtout s'il n'y a pas de documentation là-dedans. Donc tu n'as rien écrit ? Tu n'avais pas tout ce plan écrit. Ensuite, cela pourrait être très difficile parce que vous ne pouvez pas vraiment amener d'autres programmeurs. Il leur faudra six mois pour apprendre le code basé, etcetera, etc. Mais de toute façon, c'est la vue de haut en bas du cycle de développement logiciel typique. Maintenant, tout au long du reste , bien sûr, nous allons commencer à les décomposer un peu à peu, puis plonger en profondeur dans chacun d'eux et ensuite regarder des choses soignées comme des modèles qui sont tous, Comme, comment vous combinez ces différentes étapes la meilleure façon de le faire, vous savez ? Tu le fais comme un V où tu mets un peu de ça de chaque côté ? Est-ce que tu le fais ? Il y a ces choses appelées Scrum dans la chute d'eau signifiaient que ça va aller sur tout ça. Mais le cycle de développement logiciel, euh, vraiment bon à savoir. Et tu vas le voir beaucoup 4. Exemple de cycle logiciel: Passons un petit exemple pour aider à soumettre ceci juste un peu plus avant de commencer la plongée profonde dans chacun de ces domaines. Examinons un exemple ici. L' exemple va être simple. Ce sera juste comment construire un formulaire. Ou surtout ce que nous faisons, c'est que nous avons cet objectif. On veut construire un formulaire, il va avoir une adresse e-mail, et il va y avoir un lieu de commentaires et c'est tout. On veut juste voir ce qui s'est passé. On le fait. La conception des exigences, la mise en œuvre, etc. Sur. C' est un exemple très basique. Vous pourriez vraiment obtenir vraiment en profondeur et en fait venir avec un gros documents pour quelque chose d'aussi petit. Mais je veux juste passer en revue les bases. Alors, tu comprends quoi ? Comment chacun de ces domaines fonctionne un peu plus. Donc, le premier domaine que nous voulons examiner est les exigences. Alors, qu'est-ce qu'on veut que ce formulaire soit dio ? Nous voulions collecter des courriels, des adresses et des messages. C' est ce que nous voulons que le formulaire original fasse. Il va collecter une adresse e-mail et un message, puis a péché, aussi, aussi, et stocker dans une base de données. Il envoie donc ces informations sur Internet dans notre base de données. Et puis nous voulons empêcher l'utilisateur de mauvaise entrée dans ce moyen dans l'adresse e-mail, mettre tous ces symboles aléatoires et ne pas réellement créer une adresse e-mail dans la section commentaire . Vous savez, essayer d'insérer du code ou de faire une attaque par injection SQL ou quelque chose comme ça empêcherait ce genre de choses. Donc trois exigences de base ici, alors nous allons entrer dans notre conception. Que faire Comment pouvons-nous concevoir cela maintenant, avec la conception, vous pouvez venir avec un document ou vous pouvez réellement en quelque sorte le dessiner. Beaucoup de fois, vous avez besoin d'une extrémité frontale et arrière dans la conception. Donc, tu sais, peut-être qu'on a juste une boîte rapide. Ici, nous avons le lieu de courriel, puis le plus grand lieu de commentaire, et puis quand nous le dessinons, nous irons, Oh, en fait besoin d'un bouton pour soumettre cela. Alors peut-être voulons-nous mettre cela dans nos exigences. Nécessite un bouton. Exactement. Donc tu sais, juste quelque chose d'orteil. Tu pourrais toujours aller et retours entre les exigences du design, en fonction de l'utilisation du modèle et on en parlera plus tard. Tu pourrais toujours aller et retours entre les exigences du design, Mais avec notre conception, nous voulons utiliser HTML et CSS pour construire les cadres du formulaire. Donc, nous voulons construire le genre de ce que nous considérons en fait comme HTML et CSS. Ensuite, nous voulons utiliser JavaScript pour la vérification de l'entrée. Et puis nous voulons utiliser Jake fatigué dans mon SQL pour contacter le backend et Jake étaient vous n'avez pas entendu parler. C' est juste JavaScript, mais en quelque sorte ajusté. Ainsi, vous pouvez envoyer une sorte de requêtes de publication à une base de données, puis mon SQL est juste une base de données. La partie suivante est la mise en œuvre, et c'est vraiment, vraiment facile. C' est juste du code et du document. Le travail sera facile. En ce sens, ce sera en fait l'endroit où la plupart du temps est passé. Après avoir fait ces deux choses, c'est juste une sorte de travailler tout, mettre en place un serveur, mettre en place le front end et le JavaScript etcetera. Maintenant dans la vérification Beaucoup de fois la vérification, le test est juste une sorte d'extension des exigences. Nous posons des questions sur les exigences, alors collectez des adresses e-mail et des messages. Est-ce qu'un formulaire recueille des informations ? Nous créons donc un test pour tester les informations collectées, vous envoyer et stocker dans une base de données. Est-ce que le formulaire envoie ces informations à une base de données ? On pourrait faire des tests là-dessus. On peut voir, tu sais, dans, mettre à l'avant et ensuite aller vérifier notre base de données et s'assurer qu'il est dans le back-end. Faites peut-être des cas de coin en essayant d'insérer 100 navigateurs différents en même temps, ou en essayant de les insérer tous dans l'ordre, peut-être une demi-seconde l'un après l'autre. Peut-être qu'il y a une file d'attente qui est surchargée ou quelque chose, donc ce genre de tests aidera à s'assurer que vous ne perdez pas d'informations et ensuite empêcher l'utilisateur de frapper. Mais essayez de faire une attaque par injection SQL sur vous-même. Essayez de mettre des caractères vraiment aléatoires tout au long. Ce ne serait pas vraiment un message, peut-être même la prévention du spam. Peut-être que nous voulons construire une chose de prévention du spam ici, et nous devons mettre cela dans une exigence de conception. Mais nous testons cela aussi, et enfin nous avons la maintenance, qui est juste de créer un plan de cycle de vie et de corriger les bugs. jeu du cycle de vie pourrait être simple comme vérifier tous les six mois pour s'assurer que toute la technologie utilise le plus à jour et même avec la base de données mise à jour tous les six mois. Vérifiez tous les bogues, peut-être le mettre à jour tous les six mois. Ou peut-être que vous avez un horaire hebdomadaire de la façon dont les bugs entrent dans votre entreprise ou autre chose. Mais une maintenance est juste une sorte de trouver un plan pour s'assurer que nous pouvons l'ajuster exigences afin de répondre à ce que nous voulions faire et aussi pour s'assurer qu'elle n'est pas vulnérable. Et là, nous avons juste un exemple très, très simple de la façon dont vous pourriez passer par ces étapes, comment vous pourriez en quelque sorte catégoriser simplement la construction d'un formulaire simple. Maintenant, dans ces prochaines conférences, nous allons commencer à sauter dans la partie vraiment en profondeur où vous pouvez réellement utiliser certains des outils que nous parlons de construire pour faire ça. Mais pour quelque chose de bien, beaucoup plus grand à l'échelle 5. Définition des exigences en 2-1: commençons notre plongée profonde dans les exigences. Le premier que je vais examiner est la définition des exigences, quelque chose avec lequel nous sommes tous sur la même page. Donc, nous comprenons tous ce que je veux dire par exigences. Les exigences sont donc un moyen de déterminer les spécifications exactes de ce que le logiciel devrait faire. Vous pouvez penser à des exigences comme une définition. Vous définissez ce que le logiciel devrait faire. C' est comme si vous étiez à la recherche dans un livre et vous êtes capable de lire exactement ce que le logiciel devrait dio. C' est important. Nous n'essayons pas de comprendre comment il devrait être créé. Nous essayons juste de comprendre ce qu'il devrait faire à la fin. Si l'utilisateur interagit avec lui ici ou pour, vous savez, et que l'utilisateur interagit avec lui, que va-t-il se passer ? Qu' est-ce qu'on veut que les orteils arrivent ? Quel est le but de ce système ? C' est pourquoi il s'agit d'un processus pour déterminer les objectifs d'un système. Donc, à la fin, les exigences essaient juste de trouver les objectifs du système. Ce que nous voulions accomplir cela reflète le quoi et non la façon dont c'est important, c'est que nous essayons juste de comprendre ce qui n'est pas comment nous essayons de le créer. Le comment est pour le design. Beaucoup de gens pourraient venir avec une exigence de va utiliser C, S S et HTML pour construire le front end. Et ce n'est pas une exigence. C' est trois. Comment c'est ce que nous allons utiliser pour construire le front end. conséquent, Parconséquent, cela fait partie de l'exigence de conception. Peut-être. Utilise un champ d'adresse e-mail pour capturer l'adresse e-mail. Ou nous voulons capturer l'adresse e-mail et un commentaire. Donc on ne dit pas comment on va faire ça. Nous n'essayons pas de définir la technologie sur la façon dont nous essayons de le faire. Nous disons juste, Que voulons-nous que l'utilisateur puisse faire ? Qu' est-ce qu'on veut ? L' objectif final à être ? Et dans l'ensemble, les exigences créent généralement un document qui expose tous ces détails. D' habitude, il y a des listes de puces ou il y a, vous savez, s'il est vraiment officiel, vous avez s'il est vraiment officiel, vous avez besoin de deux A ou quelque chose comme ça. Mais souvent, si vous travaillez juste pour des entreprises comme, moyennes ou petites, ce sera juste une sorte de liste des choses que vous voulez accomplir et des cas d'utilisation que vous voulez faire avec les utilisateurs. Alors parlons de l'importance des exigences. Pourquoi avons-nous utilisé les exigences ? Quoi ? Qu' est-ce qui nous sauve en fin de compte ? On dirait que, tu sais, on passe juste plus de temps. On pourrait bien recouvrir avec toute l'ingénierie. Et c'est important. C' est de l'ingénierie ? Vous dio n'importe quelle ingénierie vous dio vous avez ce genre de règle d'or et la règle d'or est que passer du temps stratégiquement à l'avance réduit le coût et le temps plus tard. Maintenant, ce sont des données d'une étude qui ont montré que si vous avez passé du temps stratégique à partir de la raison pour laquelle je dis stratégique, c'est pas seulement parler, vous savez, avant qu'on ne conçoive la chose juste pour parler, Vous savez, 40 heures nous voulons être, vous savez, vous savez, travail ciblé ici, le concevoir, trouver des problèmes potentiels, trouver tous les cas d'utilisation possibles, vous savez, créer fondamentalement le code avant même de toucher le code. C' est de ça que je parle. Donc, passer du temps stratégiquement à l'avance réduit les coûts et le temps plus tard, et c'est une sorte de tendance ici. Non, Lotus, que la tendance est un peu comme cette tendance de perte de temps. Donc, il y a un moment où cela ne vous aide pas à utiliser plus de temps d'avance. Donc, vous savez, si nous allons à moins de 50 % de tous les temps, ça ne changera pas beaucoup ici. Cela ne va pas vraiment réduire le coût de dépassement. Vous remarquez que cela ne descend pas à zéro. C' est parce que la plupart des projets dépassent toujours plus de 40%. Le budget est en quelque sorte la norme, et souvent il se lève en grand nombre parce que les gens ne planifient pas en conséquence. Mais cela ne fait que dire du temps total ici. Donc, c'est le temps total. Ce dont nous parlons, c'est si nous passons 0% de notre temps, donc nous ne passons absolument pas de temps à l'avance. Le coût standard est de 200 %. Si nous dépensons environ 3 % et 5 %, nous avions 100 % et 50 % alors nous avons été 5 % de tout notre temps très, très peu de temps, vous savez, s'il a passé 100 heures, nous parlons de 5 heures à l'avance, Je passe juste sur ce truc. Nous pouvons nous épargner 150% de dépassement supplémentaire. Et cela coûte plus cher en dollars et dans le temps. C' est donc aussi ce sont les deux habituels parce que les deux vont de pair l'un avec l'autre. Si ça prend plus de temps, ça va coûter plus cher. Vous payez à vos ingénieurs votre paiement pour les soins de santé, votre peine pour les impôts. Tu paies tout ça. Et plus il te faudra de temps pour commencer à te faire de l'argent, plus ça va coûter. Et puis si on va de 10 à 20 %, on obtient cette zone dorée où on obtient juste les 40 % de dépassement. Et donc tu sais, quelle est la différence entre ça ? Disons que nous dépensons 0% à l'avance et que le produit aurait dû prendre 200 heures. Eh bien, c'est juste un simple calcul ici va avoir un dépassement de 200%, ce qui signifie qu'on cherche 100 au total sera 400 donc 200 % de plus sur ce sera environ 600 heures pour terminer ce projet alors qu'il n'aurait fallu que 200 C'est géant saut géant juste là du temps qu'il aurait dû prendre où si on mettait juste 5%. Donc, dans ce 200 notre projet, si nous venons de désigner 5 % ou 10 heures, alors nous serions sur Lee à un dépassement de 50 %, ce qui signifie que notre total serait de 300 heures. Donc, avec 10 heures d'efforts ici, nous nous sommes réellement épargnés 300 heures de problèmes back-end. Et c'est juste un peu comme le pouvoir de tout cela, c'est que passer du temps à l' avance aide à répondre aux besoins. Document est l'une de ces choses à passer le temps à l'avance et même avec le document de conception . Mais ces deux éléments sont très importants. Ils nous mettent sur la même page et ils nous font travailler efficacement. 6. Les exigences en 2-2 et les spécifications: Il y a quelques catégories différentes chaque fois que nous parlons de toute l'étape d'arche des exigences. Et ces catégories ont défini différents aspects du système que nous essayons de construire dans cette conférence. Ce dont nous parlons, ce sont les exigences et les spécifications, donc il y a une différence majeure entre les deux et vous verrez au début qu'elles ressemblent assez . Mais chaque fois que vous commencez à plonger dans ce genre de choses, vous comprenez qu'il y a une importance entre les deux. Le verset dont on va parler sera les exigences. Donc, avec les exigences, quelles seront nos exigences. Une exigence est une définition non technique de quelque chose que l'utilisateur exige du système . Ce que cela signifie, c'est qu'il est mis en termes profanes. Il devrait être compris par n'importe qui. Donc pas de jargon. Ce genre de jargon ne parle pas d'informatique, pas de jargon de programmation. Si vous faites comme un formulaire médical, vous connaissez notre quête de forme de traitement. Vous pouvez mettre en jargon dans le domaine médical ou dans le domaine de la construction dans l' exigence de l'utilisateur , parce que notre public sera, vous savez, le domaine médical du domaine de la construction ou l'application Domaine de développement. C' est parfaitement OK. Cependant, nous ne voulons pas mettre dans est jargon comme mon SQL ou Jason quelque chose que cela devrait pouvoir être lu par le directeur de la construction ou par, vous savez, le directeur de l'usine automobile. Il devrait pouvoir lire cela et comprendre. Oui, c' est ce qu'on veut dans notre système. Donc, avec les exigences, nous ne voulons pas de jargon informatique. Ainsi, par exemple, une exigence pourrait être la capacité de soumettre une demande de formulaire médical de traitement. Savez-vous ce qu'est un formulaire de demande de traitement ? Pas vraiment ? Ça n'a pas d'importance pour nous. Ce que nous savons, c'est que nous avons parlé au client et ils disent qu'ils veulent la possibilité de soumettre une demande de traitement, formulaire médical et avec cette affaiblir Demander à ce sujet plus tard. Mais nous savons que ce serait un formulaire médical, donc il devrait y avoir une certaine sécurité là-dedans. Ça va être une sorte de formulaire de contact de la demande de traitement, et ça va être notre exigence pour cette étape. Et puis, comme je l'ai dit plus tard, nous pourrons clarifier avec eux exactement ce qu'ils signifient. Ensuite, nous avons ces spécifications, donc les spécifications sont essentiellement des notes techniques, notes sur ce qui doit être fait pour répondre à l'exigence. Donc, dans cette situation, c'est une définition technique de ce qui est exigé du système. On va rester simple. Nous n'essayons pas de le concevoir ici. C' est très important. C' est la plus grosse erreur que vous n'avez pas essayé de concevoir. Ce que nous essayons de faire est juste, fondamentalement, bien que quelques mots-clés de haut niveau ici. Nous comprenons donc l'importance de certains aspects de l'exigence. Donc, dans cette situation qui sort de cette exigence, une spécification pourrait être d'envoyer A s à 56 données de formulaire cryptées de l'interface frontale au serveur principal. Vous remarquerez qu'on a un peu de jargon là-dedans. On est arrivés à l'avant et on est rentrés. Nous avons un S C 2 56 crypté, mais rien de tout cela ne définit la technologie. On n'utilisera rien de tout ça en disant qu'on va le prendre et le passer comme ça à travers ce médium, comme, tu sais, une sorte d'explication très profonde. Vous remarquerez que c'est l'erreur. C' est ce que nous avions mis dans le document de conception que nous allons utiliser encryption, qui est une technologie pour crypter les données dans JavaScript pour envoyer A S à 56 crypté. Jason s'est formé à nouveau. C' est une façon de se former. Nous n'avons pas besoin de connaître exactement la technologie que nous utilisons formée à partir de JavaScript. C' est une technologie pour mon serveur SQL, etcetera, etc. Il y a trop de jargon là-dedans. Il y a trop de choses qui définissent la façon dont le projet va être construit. Ce n'est pas le but de cette phase. Tout ce que nous essayons de dire, c'est qu'il nous faut des données cryptées. Nous préférerions que ce soit le Secure A es 2 56 Et vous savez, aujourd'hui c'est probablement nous voudrions utiliser une technologie différente, mais c'est juste pour l'exemple. Mais de toute façon, nous voulons utiliser A S à 56 nous voulons le prendre de l'extrémité frontale, où l'utilisateur peut se connecter au back-end. Plus besoin d'informations après cela. Lorsque nous arrivons à l'ensemble de conception, nous pouvons commencer à introduire les technologies que nous allons utiliser. Alors passons en revue quelques exemples ici. premier exemple est de retourner dans le monde réel. Parlons de la création d'un pneu VUS. Et avec ce pneu VUS, ce dont nous allons parler est fondamentalement juste une exigence simple et dans certaines spécifications qui pourraient aller avec cette exigence afin que nous puissions à nouveau voir la différence entre les deux. Typiquement, chaque fois que nous parlons de ce truc, nous allons dire les exigences de l'utilisateur et le système Sessa vacances. Ce que cela signifie, c'est que c'est en quelque sorte le définir. Donc, tout le monde est sur la même page chaque fois que nous parlons des exigences était de parler ce que l'utilisateur veut être en mesure de dio. Jamais. Nous parlons des spécifications du système. Nous parlons de la façon dont le système devrait fonctionner fondamentalement, de sorte que certaines contraintes certaines des exigences avec le système lui-même. Donc, l'exigence de l'utilisateur disait que le pneu doit fonctionner sur une automobile de type SUV. Ou peut-être que l'utilisateur doit être capable de mettre le pneu sur une automobile de type SUV. Tout avertissement de cela capture le point. Nous avons un utilisateur. Il veut pouvoir prendre ce pneu et le mettre sur une automobile. C' est ça. Maintenant, les spécifications. Qu' est-ce que ce pneu a à faire ? Qu' est-ce que ça veut dire ? pour prendre un pneu et le mettre sur une automobile de type SUV. Et encore une fois, vous voyez, c'est un tout petit peu de jargon, mais c'est bon parce que nous sommes dans l'industrie automobile. Par conséquent, nous pouvons utiliser le jargon de l'industrie automobile ici. On ne parle rien de spécifique tant qu'on n'arrive pas à cette partie. Donc ce que nous allons juste dire, c'est que le pneu doit pouvoir supporter jusqu'à 7500£ de pression à la baisse. Le pneu doit s'adapter à tous les points standards pour le montage du pneu doit s'adapter à toute la sécurité de la poussière. Euh point normes de sécurité et le pneu doit avoir du thé ou une meilleure qualité de vitesse. Vous n'avez pas besoin de savoir ce que l'un d'entre vous sait que cela signifie, mais ce que vous pouvez voir, c'est que nous avons ici l'exigence très fondamentale. Et ici, nous spécifions juste certaines des choses que le pneu devrait dio. On ne parle pas de la chimie exacte du caoutchouc qui devrait être utilisé. Nous ne parlons pas de la pression d'air à l'intérieur du pneu pour acquérir les 7500£ de pression d'air . On ne parle pas de design. Il ne s'agit que de certaines contraintes, de certaines choses que nous devons mettre en œuvre dans ce pneu. Enfin, revenons un peu trop dans le monde de la technologie. Nous avons donc maintenant cette autre exigence. Les utilisateurs devraient être en mesure de télécharger une vidéo sur le site Web. Nous avons ce grand site web. Il y a 100 de ces exigences et ce n'est qu'une des exigences. Ceux-ci devraient être en mesure de télécharger une vidéo sur le site Web. Donc maintenant, nous avons juste quelques spécifications ici. Que devrait accepter l'utilisateur ? H 0.264 déplacer et fichiers mpg pour le téléchargement Ces catégories seulement. On ne dit pas comment ils vont être, sauf qu'on ne dit pas la technologie qu'on doit utiliser pour les accepter. Comment vont-ils ? Que devrions-nous être en mesure d'accepter ? Ce que nous entendons par vidéo. Et donc nous sommes en quelque sorte de spécifier qu'avec cela juste un peu, puis le chargement du chargeur haut devrait compresser la vidéo et enregistrer trois copies différentes le serveur à nouveau. Ce n'est pas quelque chose que le nouvel utilisateur a vraiment besoin de savoir. C' est juste quelque chose que nous, concepteurs de ce site, regardons et disons tard, que nous allons vouloir prendre cette vidéo et l'utiliser de certaines façons. Nous devrions le compresser et le sauvegarder à nouveau sur le serveur. Nous ne mentionnons pas le type de serveur. Nous ne mentionnons pas les dimensions des trois vidéos. Juste il devrait avoir la capacité de le faire. Et puis, enfin, un lien vers la vidéo compressée dépend de la façon dont nous voulons qu'elle soit. Doit être envoyé par e-mail à l'utilisateur après l'achèvement. Encore une fois, nous ne parlons pas des serveurs de messagerie ou de la façon dont nous allons formater l'e-mail ou vous savez à quoi le lien devrait ressembler. Comment le lecteur vidéo, n'importe quoi de ces trucs. On ne parle pas de ça. Nous parlons juste d'un cahier des charges ici. Le lien, fois qu'il est fait, doit être envoyé à l'utilisateur. Et bien sûr, ce n'est peut-être pas tout à fait inclusif. Il pourrait y avoir d'autres choses que nous devons nous asseoir et commencer à marquer un peu plus. Ceci et peut-être que nous avons une autre exigence. Par conséquent, nous avons besoin d'encore plus de spécifications, etcetera, etcetera. Mais j'espère que dans l'ensemble, vous aurez l'idée de ce que la différence entre une exigence et les spécifications est exigence traite avec l'utilisateur. C' est très basique. C' est en termes de profane, quelque chose qu'un client peut regarder et aller. Oui, le programme devrait certainement être capable de le faire ou non, Peut-être que cela ne définit pas exactement ce que nous voulons. Et puis les spécifications du système sont comme nos notes. C' est comme les notes du développeur disaient, Ok, donc l'utilisateur veut que Bill le fasse, et ce qu'il veut vraiment, c'est qu'il puisse télécharger ces types de fichiers. Il doit être en mesure de le faire avec les besoins des pneus pour répondre à ces normes, et c'est à cela que les spécifications du système se réfèrent. 7. 2-3 fonctionnel et non fonctionnel: les deux autres catégories dont nous devons vraiment discuter lorsqu'on parle d'exigences sont les vers non fonctionnels, les exigences fonctionnelles. Alors, quelle est la différence entre ces deux-là ? Les exigences fonctionnelles sont-elles des exigences et des spécifications relatives à la fonction du programme ? C' est le mot clé ici. C' est la fonction du programme ici. Donc, ce dont nous parlons, c'est de quoi le système devrait être dû ? En fin de compte, ce que le système devrait pouvoir accomplir était de construire un formulaire. Nous descendons la liste des choses que le formulaire devrait être capable de dio Il devrait recueillir des données. Il devrait envoyer des données qu'il devrait protéger contre l'entrée. Il devrait le faire. Il devrait le faire maintenant. Non fonctionnel sont les exigences et les spécifications relatives aux objectifs à atteindre. Par exemple, la sécurité. Quel devrait être le formulaire maintenant chiffré ou coûter ? Comment le temps est-il limité ? Peut-être combien de temps le formulaire devrait-il prendre pour le soumettre ? Donc peut-être que le formulaire devrait soumettre des données au serveur et ici dans l' exigence non fonctionnelle . En plus de cela, il devrait soumettre des données dans un délai de 500 millisecondes. Disons que ce n'est pas quelque chose que ce que le système dans son ensemble fait donc, ce n'est pas fonctionnel. C' est quelque chose qui est une contrainte. C' est quelque chose qui a besoin orteil arriver avec la fonctionnalité ici, nous pouvons jeter un oeil à non examiné qui a passé plus tôt. Alors rappelez-vous le Send A à 56 crypté formé à partir de yada yada. On peut décomposer ça pour en faire un peu fonctionnel et non fonctionnel. Ainsi, le 1er 1 est péché, formé à partir de l'avant et d'un serveur back-end. Qu' est-ce que ça fait ? Eh bien, c'est une fonction. Ça prend des données, et ça lui envoie sa définition. Que sont exactement les produits devraient faire ? Et donc pour celui-ci, nous parlons d'une exigence fonctionnelle. Maintenant, le bas est un non fonctionnel. Vous pouvez voir que j'ai pris toute la partie de cryptage de ceci pour en quelque sorte les briser et vous verrez que chaque fois que vous avez raison les exigences, les choses ont un peu de désordre peuvent réellement se combiner à, et ce n'est pas une science exacte. Cependant, passant par elle, vous pourriez être en mesure d'assommer certaines de ces choses et la figure Attendre, Nous devrions les mettre dans deux catégories distinctes. Une sorte de choses. N' importe quel espoir. La partie inférieure. La partie de chiffrement est non fonctionnelle, non fonctionnelle. Beaucoup de fois est référé à son gouvernement non fonctionnel NFR, et c'est le fr. Beaucoup ont dû décoller les sont si non fonctionnels, euh, euh mais de toute façon, ce n'est pas quelque chose que le programme devrait faire. Ce n'est pas une opération. Ce n'est pas quelque chose que l'utilisateur fait que vous connaissez. S' il ne peut pas le faire, il y a quelque chose qui ne va pas avec le produit. C' est une exigence. C' est quelque chose qui devrait se produire avec les exigences fonctionnelles. Donc, l'exigence fonctionnelle est l'envoi des données du formulaire. Et puis l'exigence non fonctionnelle est qu'il devrait être chiffré qu'il ne prenne que 500 millisecondes, qu'il devrait l'envoyer à trois serveurs différents avant qu'il n'arrive à notre serveur. Pour une raison quelconque, c'est le non-fonctionnel derrière ça maintenant. Non fonctionnel a également quelques petites catégories différentes, et ce que ces catégories sont fondamentalement quelques-unes des différentes sortes de larmes de non-fonctionnel, et vous commencerez à les comprendre juste un peu ici. Plus le 1er 1 est les exigences du produit, quelque chose que le produit doit faire à nouveau. Ce n'est pas quelque chose que ce produit agit, vous savez, avec l'environnement sans changer quelque chose. C' est juste une façon de concevoir le produit, une façon de l'intégrer au monde. Et disons que vous avez un client qui est, peut-être qu'il loue la capacité de créer ce logiciel, mais à la fin, il veut le maintenir lui-même. Par conséquent, il en a besoin revêtu dans un langage spécifique. Java. On ne parle pas de design ici. n'y a pas d'aller-retour. C' est une exigence. C' est quelque chose qu'il dit. Le programme doit être codé en Java. C' est ça. n'y a pas de discussion sur ce point. Par conséquent, cela devient une exigence maintenant. Est-ce la façon dont le problème fonctionne ? Par exemple, nous pourrions créer une page Web qui a un formulaire que nous pourrions créer en Java ou CSS et HTML et JavaScript, ou peut-être même python ou ruby. Nous pouvons créer dans tous ces différents, donc peu importe le langage de codage. Cela ne fait pas partie de la fonction du programme qui n'est pas une exigence fonctionnelle, quelque chose que nous devons faire. Mais le programme ne réagit pas à cause de cela. Par conséquent, nous avons ce non fonctionnel et c'est une exigence du produit. Ensuite, nous abordons les exigences organisationnelles, et cela se résume généralement aux politiques et aux normes, aux styles et aux règles de l' organisation dans laquelle vous travaillez et avec laquelle vous travaillez. Ainsi, par exemple, l'organisation avec laquelle vous travaillez est peut-être une organisation militaire. Et ils disent que chaque fois que les données changent de mains, doivent être cryptées. Peu importe si son interne ou externe, il doit être crypté. Par conséquent, l'un de nos crimes organisationnels. Ce serait les données du produit doivent être cryptées par ES 2 56 Et encore une fois, je l'utilise tout le temps. C' juste parce que c'est un algorithme de cryptage facile, bien sûr, norme militaire. Il y aura probablement quelque chose bien plus fort, mais peu importe. C' est la technologie ici. Ce dont je parle, c'est qu'ils nous disent qu'on doit utiliser ça. Ou peut-être que c'est notre propre politique d'entreprise. Quoi qu'il en soit, il ne s'agit pas de la fonction du programme et de la façon dont il interagit avec le monde qui l' entoure. Il s'agit de la façon dont il devrait être élaboré et de ce qui devrait se passer dans le cadre du programme. Et enfin, pour l'organisation que nous avons, le projet sera développé à l'aide de la méthodologie mêlée. Nous sommes dans une entreprise qui utilise de la mêlée et il n'y a aucune dispute à ce sujet. On ne parle pas de ça, donc quand on arrive à la phase de conception, ce n'est pas une question qui n'est pas quelque chose que des ingénieurs se réunissent pour trouver . Par conséquent, c'est une exigence. On est dans une entreprise. Il utilise de la mêlée. donc C' estdoncune exigence. Et il ne parle pas de la façon dont le programme interagit avec le monde, ce que je dis sans cesse, mais j'essaie de forer cette maison. Par conséquent, il s'agit d'une exigence non fonctionnelle. Ensuite, nous entrons enfin dans les exigences externes et c'est juste quelque chose. Chaque fois que nous parlons de choses externes qui poussent en quelque sorte notre produit et cela pourrait être des lois ou des règlements externes ou même des tendances que nous devons suivre et donc ce que nous avons c'est que nous avons ces lois qui se réunissent pour répondre à ces exigences. Par exemple, disons que l'U l'Union européenne a une loi, vous savez, la loi sur la liberté, article 1, section 2, qui stipule que toutes les données doivent utiliser ce genre de cryptage SSL cryptage entre les points de données ou autre. Ça doit être une exigence, parce que si on veut concevoir, c'est un logiciel qu'on vend au U, ça doit correspondre à ça. Sinon, personne ne l'achètera. Et s'ils le font, nous serons poursuivis par le gouvernement, et notre produit sera essentiellement une responsabilité envers nous au lieu d'un actif. Et on ne veut pas ça. C' est donc une exigence externe. Il pourrait y avoir aussi certaines tendances. Peut-être y a-t-il une certaine tendance en matière de sécurité ou une certaine tendance, comme la page Web doit pouvoir se charger en deux secondes. Beaucoup de gens quitteront les pages Web s'ils ne se chargent pas dans les deux secondes. Cela ne montre pas quelque chose qui n'est pas exactement, ah, la loi ou la réglementation, mais c'est une tendance. C' est quelque chose que nous devrions avoir de la faute. C' est quelque chose qui devrait être mis en œuvre dans notre programme si nous voulons être concurrentiels sur le marché afin que nous puissions établir ici et aussi des exigences externes. Mais c'est la dernière classification des exigences ici. On a ces non fonctionnels. On a ces exigences fonctionnelles. Rappelez-vous juste une exigences fonctionnelles comment le programme interagit avec le monde qui l'entoure . Ça change quelque chose. Ça bouge quelque chose. L' utilisateur est capable de faire quelque chose en raison de cette exigence. Alors que les exigences non fonctionnelles sont les choses que le programme devrait être en mesure de faire leurs choses qui n'ont pas nécessairement interagi avec le monde. Mais ils nous contraignent. Ils nous obligent à faire quelque chose. Par conséquent, ils doivent être inclus dans leurs documents d'exigences. 8. Introduction à ce modèle WRSPM: Alors passons dans le premier modèle du cours, et ce sera un modèle qui encapsule en quelque sorte l'ensemble de la production de logiciels . C' est quelque chose qu'on appelle le modèle W. R S P M ou, en bref, le modèle mondial de la machine. Et ce que ce modèle, les photos, c'est l'interaction entre l'environnement et le système. Et c'est important parce que vous devez comprendre qu'il y a beaucoup d'aspects différents qui entrent dans un logiciel que beaucoup de choses différentes que vous pourriez ne pas penser à qui vous devez penser lors de la conception d'un logiciel. Par exemple, chaque fois que vous avez une application sur votre ordinateur, vous devez disposer d'un périphérique d'entrée et de sortie pour communiquer avec cette application. Donc, par exemple, si nous utilisons quelque chose comme un logiciel de retouche photo pour modifier réellement les photos, nous devons non seulement faire le programme lui-même, mais nous avons également surmonté le matériel sur lequel il fonctionne, qui va être votre ordinateur personnel, et vous devez avoir des périphériques d'entrée. Donc, par exemple, un clavier et une souris, et puis en plus de cela, vous devez avoir l'être humain qui interagit réellement avec tout cela et comprend comment tout utiliser. C' est donc une façon de catégoriser cela afin que nous puissions examiner les exigences d'un système et voir si nous manquons quelque chose pour le regarder. Et est-ce qu'on manque une hypothèse qui était censée faire ? Y a-t-il un élément particulier que nous ne prenons pas dûment en compte ? Cela nous permet juste de mettre ceux qui finissent au bon endroit. Donc, le côté gauche de ce diagramme de Venn est quelque chose appelé l'environnement, et c'est là que le système va fonctionner à l'esprit. Par exemple, une équipe est quelque chose qui est utilisé assez souvent pour catégoriser cela. Donc, par exemple, nous avons une machine A T. M ici, et si vous vivez dans un autre pays, c'est un distributeur d'argent. Je connais différents pays appelés des choses différentes en Amérique. Ça s'appelle un guichet automatique T M. Fondamentalement, vous y allez et vous obtenez de l'argent. Assez simple, mais vous devez penser que c'est une équipe. Il fonctionne dans le monde, la sphère du monde, et puis il y a un programme à l'intérieur. Il y a un petit programme en cours d'exécution, puis il se connecte à quelque chose à l'extérieur. Peut-être qu'il va à un grand serveur ou à des banques ou quelque chose comme ça. Mais il y a tous ces différents éléments qui entrent dedans. Le côté gauche de l'environnement. Dans quoi fonctionne notre système ? Et ici, nous avons deux sortes de zones différentes ou deux choses différentes que nous regardons et le 1er 1 est W. Et le W est que nous allons voir que nous allons passer par toutes ces lettres. Voici le monde. C' est le W juste ici. Donc, le monde, cela se résume généralement à des hypothèses que nous devons faire chaque fois que nous fabriquons un logiciel. Et cela pourrait être vraiment, vraiment une sorte de simple et presque citer des hypothèses stupides sans citer. Mais ils doivent être faits,par exemple, par exemple, au sein d'une équipe que nous devons faire. Une des hypothèses mondiales est qu'il ya une banque de l'autre côté qui a de l'argent que cela il ya un but à cela une équipe qu'il ya une entité qui est en fait garder trace de ces transactions, et donc l'équipe a but. L' une des hypothèses pourrait donc être qu'il y a des banques, que l'argent existe, que leur argent est une sorte d'entité. Maintenant, bien sûr, vous pourriez ne pas être en mesure de terminer, vous savez, une meilleure façon de concevoir votre programme avec cette hypothèse. Mais en mettant l'hypothèse là-dedans, vous commencez à comprendre le programme un peu mieux. Et puis vous arrivez à des choses importantes, comme l'équipe A. Doit-on avoir l'hypothèse que l'équipe A où cette machine sera toujours connectée à l'électricité Maintenant, c'est une chose importante, parce que vous pourriez penser que vous voulez la mettre dans ah city qui a peut-être pas le meilleur réseau électrique. Peut-être qu'il s'allume et s'éteint toutes les 30 secondes sont 30 minutes. Peut-être, tu sais, un ou deux jours par semaine. Il a une coupure de courant d'une heure ou plus. C' est une hypothèse à laquelle tu dois penser. On veut que l'équipe A s'arrête ? Voulons-nous avoir une batterie de secours ? Voulons-nous que le programme soit réinitialisé ? Qu' est-ce qu'on veut faire de tout ça ? Et c'est donc très important. Chaque fois que vous passez en quelque sorte ce truc est de comprendre ces hypothèses, sorte que vous ne manquez aucune exigence, et c'est la partie suivante est les exigences. Donc le système est une sorte de ce côté des choses. Et avant de construire le système, nous devons comprendre dans une idée conceptuelle, Qu'est-ce que nous construisons ? Que fait ce système ? Quel est le but ? Qu' est-ce qu'il essaie d'accomplir ? Quel problème résolve-t-il ? Et c'est là que les exigences entrent en jeu. Cela fait partie de l'environnement, parce que l'environnement a créé un problème. L' environnement a généré un problème, ce soit juste un problème passif, quelque chose que nous pensons, Hey, cela pourrait être corrigé ou si c'est un problème réel, quelque chose où étaient quelque chose que les humains ont peut-être créé ou que la société a créé des heures supplémentaires et donc nous travaillons. Nous créons nos exigences. Ensuite, l'étape suivante est que nous entrons dans ce genre de mélange entre l'environnement et le système, et c'est là que nous entrons dans les spécifications. On a mis le S ici. Les spécifications vont sur le genre de, euh, les détails du système. Donc on est toujours dans ce truc d'environnement. Nous sommes encore dans la résolution du problème, cependant, étaient également la construction du système étaient également de déterminer ce que la meilleure chose pour le système est. Nous obtenons des détails techniques, donc c'est là que nous construisons le mélange. Cette partie est beaucoup de fois appelée l'interface étaient la construction de la branche entre l'environnement et le système, le terminal pour connecter le monde à ce programme. Et cela, bien sûr, nous amène au prochain ici, qui est le programme. Et maintenant, nous sommes dans le système. Donc, le programme est le code lui-même. Le programme est ce qui est en cours d'exécution. C' est les déclarations if else. Il contrôle le matériel. Il saisit les données. Il envoie les données. C' est ce que le programme est. Il n'y a rien à avancer là-dessus, mais c'est en quelque sorte la plus grande partie du développement logiciel est en fait de créer le programme , et c'est pourquoi nous allons en parler essentiellement pour le reste du cours, et enfin, nous avons la machine, et c'est important parce que nous devons comprendre sur quel matériel fonctionne-t-il ? La machine est l'équipe A elle-même. Il voit l'entité réelle Ah, le ram, le CPU les câbles réseau, les serveurs du fournisseur de services Internet. C' est tout ça. C' est l'entité physique sur laquelle le programme va s'exécuter. Et c'est important de savoir, parce que peut-être nous dissoudre le programme qui a besoin d'utiliser un Internet. C' est, je ne sais pas, peut-être 100 mégaoctets par seconde. Et nous nous rendons compte que nulle part ne transporte cet Internet pour un t. M. Donc nous devons retravailler nos exigences. Peut-être que nous devons ajouter une exigence où elle doit être inférieure à 10 mégaoctets par seconde, des choses comme ça. Donc c'est juste important à considérer tout au long de ce maintenant est aussi une autre petite catégorie ici, et nous pouvons créer ces autres petits cercles comme ça. Et ce qu'on a avec ça c'est qu'on a quelque chose appelé E h E V. Et puis on a, euh SV S H Et alors quoi ? Ce sont ils signifient juste environnement, environnement caché, logiciel visible visible et logiciel caché. Donc environnement, environnement caché, logiciel visible ou système visible caché. Et ce qu'ils sont, c'est juste qu'ils ont déterminé un peu plus en sorte de classer l'environnement. Donc, avec l'environnement caché, nous avons des choses comme des idées et des morceaux de données que ah, humain sait par exemple, e h serait un numéro de pin. C' est une donnée. C' est un concept. C' est quelque chose que nous devons incorporer. Quoi qu'il soit caché, il ne sera pas vraiment disponible pour. L' utilisateur n'est pas posté sur le côté de l'A T. M. C'est quelque chose sur Lee. Un être humain sait dans son esprit. Par conséquent, il s'agit d'une variable d'environnement, qui est cachée. Ensuite, nous avons l'environnement visible. Un environnement visible est les choses qui sont réellement exposées au monde réel. Chaque fois que vous entrez réellement ce numéro de broche dans le système, il devient désormais visible. Il devient citation sans citation d'acier à base de plantes. Quelqu' un pourrait regarder par-dessus ton épaule et prendre ça. Donc, beaucoup de fois l'environnement visible est les données qui sont réellement entrés dans ce genre de concepts dans votre esprit quand ils sont réellement entrés dans le système. Et puis vous avez quelque chose connu un système visible, et c'est assez simple. Ce sont les parties visibles du système. Ce sont les choses avec lesquelles nous interagissons sur un ordinateur qui seraient le clavier et la souris sur une machine A T M. C' est l'endroit où vous insérez la carte. C' est le stylo. C' est la façon de le traverser. Donc, c'est le genre de l'extérieur de l'interface, la façon dont nous nous connectons avec les choses. Et c'est pourquoi vous pouvez voir que tout cela fait partie de cette interface. Ici, nous avons des données qui sortent de l'abstrait, ce qui signifie, comme pas concrètes. C' est juste des informations stockées dans nos esprits ou peut-être sur un autre appareil entrant dans l'interface. Et avec cela, nous entrons dans la partie visible de la machine. Donc c'est, vous savez, la partie visible, la partie visible de la machine. Donc, par exemple, ce serait dans cette petite zone où il a entré les choses. Et puis nous avons des logiciels cachés et des logiciels cachés ou continuons à dire des logiciels. Mais le système caché est le backend. C' est ce bélier à l'intérieur. Nous n'avons pas besoin de connaître le fonctionnement interne d'un A t. M. Nous appuyons sur un bouton. Les travaux internes de l'équipe A font ce qu'ils sont conçus pour dio. Même avec beaucoup de logiciels. Nous, vous savez, si nous prenons deux côtés d'une image qu'ils lisaient dans une image et nous le voulons. L' image ressemble à ceci, et nous voulons faire pivoter l'image vers la droite. Nous cliquons sur n'importe quel bouton dans notre logiciel qui, vous savez , a peut-être, comme ce bouton fléché dessus, et il tourne. Nous n'avons pas besoin de connaître le code qui va dans ça. On n'a pas besoin de le savoir. Prendre tous les zéros et appliquer une formule et faire tout ça. C' est la partie cachée. Le système visible est ce bouton que nous pouvons appuyer. Et donc ces choses air à nouveau que vous voulez considérer chaque fois que vous créez ces variables ou juste, ah, ces exigences ou le genre de portée de problème est juste vouloir comprendre Quel est l' environnement Caché ? Quel est l'environnement visible ? Quel est le système visible ? Quel est le système caché ? Tu fais un gros logiciel. Ces choses sont vitales pour comprendre le nôtre complet du problème. Ensuite, les conférences étaient en train de se dérouler. On va continuer à plonger là-dedans, alors continuons. 9. 2-5 Plonger en profondeur avec WRSPM: Maintenant, nous avons une meilleure compréhension du modèle de PM WRS peut être une sorte de compréhension approximative de celui-ci. Jumentons dans quelques exemples et expliquons plus en détail chacun de ces domaines. Donc, ils étaient tous sur la même page ici, et nous pourrions peut-être implémenter cela si jamais nous devions faire un document d'exigences . Donc, nous allons sauter dans chacune des catégories et voulons juste les définir un peu . Nous avons le monde, et comme je l'ai dit, le monde est fondamentalement les hypothèses, les hypothèses sur ce que nous développons. Ils pourraient être quelque chose de très, très basique , comme l'électricité est fournie. Ou ils pourraient être quelque chose d'assez pas basique. Par exemple, avec une voiture, il se peut que les humains sachent conduire des voitures ou que les humains sachent utiliser une pédale et un système de freinage. Ce serait une hypothèse que nous devons savoir, parce que si nous gonflons un nouveau système, peut-être devrions-nous y ajouter un tutoriel. Peut-être que nous supposons trop de la part de l'utilisateur, et cela va faire échouer notre produit parce que nous ne passons pas vraiment du temps développer un système ou un tutoriel. Peut-être que cela doit être une exigence. Un didacticiel approprié qui est testé est présenté à l'utilisateur. C' est très important pour de nouveaux logiciels qui sont assez complexes. Si vous n'avez pas un bon ensemble de tutoriels, même si cela peut faire des choses étonnantes, personne ne l'utilise. Alors le 1er 1 est le monde. Les hypothèses sur ce que nous développons la prochaine. D' autres exigences définissant notre problème en termes génériques et faciles à comprendre. Nous devons savoir quel est notre problème. On pourrait dire qu'il nous faut un guichet automatique. On pourrait dire qu'il fallait obtenir de l'argent en ne allant pas à la banque. C' est un grand problème de vue d'ensemble. Mais maintenant, nous devons définir. Ce que cela veut dire ne veut pas dire que nous avons besoin d'installer des gens autour de la ville où nous pourrions aller parler. Obtenir de l'argent ne veut pas dire qu'on veut le faire. Automatisé ne veut pas dire que nous voulons l'avoir, vous savez, extrêmement sécurisé. Peut-être que nous voulons utiliser l'accès. Plus important encore, nous devons définir le problème. Quel est le problème ? Quelle solution pensons-nous est la meilleure pour résoudre les spécifications du problème est la prochaine étape de celui-ci. Nous définissons les détails plus techniques de l'interface où le bâtiment. Donc, nous sommes en train de définir cette interface, où avec les spécifications, nous avons ce genre de problème défini. Nous savons quel est le problème. Nous savons quelles sont les hypothèses, et maintenant nous examinons comment connecter l'utilisateur au programme ? Quelle est la façon dont on fait ça ? Quelles technologies devrions-nous utiliser ? Quelles technologies devons-nous utiliser ? Quels sont les détails les plus techniques sur la façon dont tout cela fonctionne ? Ensuite, nous arrivons au programme, quel est le cadre de code et le processus de développement ? Le programme que vous pourriez définir comme le reste de ce cours en passant par les documents de conception , passant par les aspects de codage réels, la maintenance de celui-ci, les façons que vous pouvez développer, que c'est en quelque sorte l'aspect du programme. Et puis la machine est le matériel physique de voleur fonctionnant sur. À un moment donné, si nous construisons une nouvelle technologie comme dans une TM, nous pourrions en fait devoir l'envoyer à un fabricant et à un ingénieur électrique pour mettre en place les rouages internes de cette chose. Sinon, nous avons juste ce programme qui serait plutôt cool. Mais il n'y a rien pour l'exécuter, donc nous devons comprendre la machine aussi. Est-ce que leur technologie actuelle existe, ou devons-nous développer nous-mêmes cette technologie ? Alors passons un peu d'exemple ici. Donc, ce que nous avons est une station d'impression photo smartphone. On a vu ça à Walmart. Peut-être que si vous ne les avez pas vus, je vais le décrire un peu. C' est comme un A T M, sauf que c'est un peu différent. Vous avez ce genre de , machine ici, et vous pouvez monter, et vous pouvez soit insérer une clé USB dans un petit port, soit vous pouvez vous connecter via Bluetooth avec votre smartphone. Et fondamentalement, ce que vous faites, c'est que vous transférez des photos sur la machine. Il y a une grande interface qui, avec , tu sais, peut-être comme un clavier ou des boutons ici, et quand les photos vont là-bas, tu les édites, et à la fin, c' est imprime réellement les photos en bas presque en temps réel. Donc, cela vous permet de Si jamais vous êtes allé en vacances, vous avez pris un tas de photos sur votre téléphone. Tu peux y aller. Vous pouvez payer. Il y a généralement un créneau de paiement ici, comme avec de l'argent ou avec une carte de crédit. Vous payez, vous obtenez les photos et vous êtes prêt à y aller. C' est la machine dont on parle ici. Maintenant, je vous recommande fortement de mettre la vidéo en pause ici et de passer par là. Je ne parle pas. Tu dois définir tout ça. Je veux dire, ça prendrait une équipe, peut-être quatre ou cinq jours pour être capable de comprendre chaque petite idée de ce que ça a besoin de dio. Je parle. Passez en revue chacun de ceux-ci et posez quelques choses où certaines des hypothèses que nous devons faire. Quel est le problème que nous essayons d'évaluer ? Que doit faire l'utilisateur ? Qu' est-ce que la machine devrait être capable de dio ? Quelles sont certaines des spécifications ? Comment la machine devrait-elle contacter les choses ? Le programme et la machine. Je vais vous donner un indice. Il y a la machine est juste ceci et le programme est le logiciel que nous développons pour nous. Vous n'avez pas vraiment besoin de vous concentrer sur ce que nous sommes vraiment concentrés est le premier dépôt de 3 ans va au-dessus de ça ? Et comme je l'ai dit, je le recommande fortement et ensuite je vais passer en revue mes réponses à. J' ai espéré que vous l'arrêtiez et que vous avez revu vos réponses. Je ne peux pas m'habiller. C' est assez. Plus vous mettrez dans le cours, plus vous sortirez. Alors s'il vous plaît, juste si vous voulez apprendre autant que possible, faites juste un peu et cela vous aidera beaucoup parce que vous pouvez réellement commencer à implémenter cette chose. Tu te souviendras mieux. Quoi qu'il soit, jetons là-dedans. Alors, le monde, quelles hypothèses avons-nous besoin de faire ? Eh bien, ce que j'étais Certaines des hypothèses que j'ai formulées sont très basiques et certaines choses que nous pourrions considérer comme acquises. Donc, les gens ont un formats de photos standardisés, l'impression qui est très important. Imaginez s'il n'y avait pas de normes ou si les gens viennent avec vraiment, vraiment aléatoire. Peut-être que chaque iPhone ou chaque téléphone avait une façon différente de stocker des photos. Ce serait qu'il n'y aurait aucun moyen de créer cela. Nous ne pouvions pas avoir, Ah, système qui vous décode pas 800 types de photos. Ça ne marcherait pas. Donc, je fais l'hypothèse qu'il existe des formats de photos très standard à partir desquels imprimer. Les gens pourront lire les invites et le tutoriel. Euh, ont les humains sont fondamentalement alphabétisés. C' est en quelque sorte ce à quoi cela arrive, c'est qu'il y aura dans une langue que les gens peuvent lire et comprendre. Si vous êtes allé dans une partie plus analphabète du monde, peut-être quelque part où il n'y a pas beaucoup d'éducation ou de connaissances en lecture. Peut-être que c'est un problème pour toi. Peut-être qu'il y a un autre moyen que vous pouvez implémenter cela avec des images ou quelque chose qui les aiderait mieux. Maintenant, volontiers. Tu sais, sévèrement un peu, des parties du monde disparaissent avec l'éducation, mais c'est quelque chose que tu voudras garder dans la tête. Hum, la prochaine est que les histoires vont re d'autres matériaux. Nous supposons que quelqu'un va aller dans ça et remplir les encres, le papier et des trucs comme ça. Nous supposons que nous allons les mettre dans des magasins où les gens le font réellement, sinon il faudrait trouver une solution et un réseau de distribution pour s'assurer que cet air est toujours rempli. Donc c'est une bonne hypothèse. C' est quelque chose que nous aurions vraiment besoin de nous assurer. Est-ce une hypothèse appropriée ou, eh bien, nous devons développer quelque chose comme ça. Les gens ont des cartes de débit qui fonctionnent avec la technologie de carte de débit standard ou dans cette carte de crédit ou toute technologie de carte ou de l'argent. Dans ce cas, il y aura une monnaie commune que nous pouvons utiliser sur cette machine qui fonctionnera. Il y aura de l'électricité facilement disponible, ce qui est important. Sans électricité, cette machine ne fonctionnerait pas et ils seront disponibles. INTERNET. Peut-être que cette machine doit contacter les serveurs. Peut-être qu'il n'a pas le matériel sur lui pour effectuer les modifications de photo et envoie réellement à un serveur serveur. Est-ce que la photo modifie et puis il renvoie les données. C' est en fait assez commun de nos jours, donc dans cette situation peut-être nous avons besoin d'Internet. Et si nous gérons un pays comme l'arrière pays qui pourrait ne pas fonctionner, nous pourrions ne pas avoir d'Internet disponible là-bas, et nous pourrions soit avoir à mettre un peu de puissance de traitement secondaire, un peu de puissance de traitement secondaire, et cela juste au cas où il n'a pas Internet, il peut essayer de le faire ici. Ça prendra juste un peu de temps. Ou peut-être qu'il y a d'autres solutions que nous pouvons trouver. C' est une hypothèse importante pour reconnaître la prochaine partie des exigences. Quelle est la chose supposée dio ? Donc, c'est un utilisateur peut connecter un smartphone au système. Et si vous remarquez que vous voulez passer en revue les exigences avant de sauter dans le monde, peut-être que vous voulez en quelque sorte définir le problème et ensuite comprendre une sorte de travail à partir de cela et voir, genre, quelles sont certaines des hypothèses que j'ai faites en établissant les exigences qui pourraient être un bon ensemble à ces choses pourraient être faites de bien façons différentes. Juste quelques idées ici, toute façon, les exigences de l'utilisateur peut connecter un smartphone au système. Le smartphone dans les images de transfert sur l'utilisateur peut éditer des photos. Les photos peuvent être imprimées à la machine, et l'utilisation peut payer pour le service. En général, si vous avez un jour des doutes sur les exigences, passez simplement sur un cas d'utilisation, essentiellement une façon d'utiliser la machine. Si vous marchez jusqu'à cette machine, comment voudriez-vous l'utiliser. Et comment voudriez-vous que les choses interagissent ? C' est une excellente façon de commencer avec les exigences à chaque étape. Il suffit de l'écrire et ensuite vous pourriez en quelque sorte construire à partir de là les spécifications de la pièce suivante . Donc, maintenant, nous avons ce genre d'idée ici de certaines des exigences. Maintenant, nous allons dans un peu plus de la nitty gritty. Comment pouvons-nous nous y connecter ? Will bleu à la technologie ? Donc un smartphone se connecte. C' est le moyen le plus populaire de se connecter. Donc Bluetooth serait une bonne idée. Et nous avons besoin d'un bon protocole de transfert Bluetooth pour être installé et pour sécuriser la transaction afin que personne d'autre ne puisse sauter là-dedans. Nous avons besoin d'un bon ou le système aura une suite d'édition de l'émulation des données photo. C' est important. Nous devons définir notre suite d'édition. Voulons-nous l'acheter à quelqu'un d'autre qui veut le concevoir nous-mêmes ? Ce système utilisera la technologie de chiffrement et de puce pour contacter les serveurs financiers. C' est une bonne chose à savoir. Comment ça va contacter les banques ? Comment ça va l'utiliser ? Nous utilisons ce cryptage et cette technologie de puce. Nous spécifions donc la manière exacte de procéder aux transactions financières. Et puis le système aura un dispositif d'impression standard pour l'impression de photos. Il va y avoir un moyen d'imprimer les photos. Nous serons peut-être en mesure de définir cela encore plus en profondeur une fois que nous commencerons à le développer. Et puis enfin, nous avons le programme, que je l'ai dit juste code système et machine, ce qui est juste les spécifications du système , le ram , le processeur, etc. Dans l'ensemble, cependant, c'est une sorte de ce que vous faites avec World Model en juste ce que je veux dire, cela m'a pris peut-être 10 minutes. Nous avons en fait une sorte de plan pour ce que nous voulons faire de cette chose que nous avons dans une idée générale. Personne ne va partout avec la façon dont il devrait être construit. Tout le monde pourrait se mettre sur la même page, et nous pourrions le présenter et travailler encore plus loin. Nous pourrions vraiment commencer à parcourir ces choses et réellement développé, comme un peu de documentation, peut-être comme une chose de 20 pages définissant le problème pour trouver comment nous voulons résoudre le problème définissant les spécifications la technologie qui a besoin et peut-être même les spécifications du système de ce qu'il serait à partir de ce que nous pourrions élaborer un budget. Nous pourrions développer ce que les équipes doivent être sur elle. C' est un excellent point de départ, et tout cela est très important pour les exigences pour trouver notre problème. mettre en place, puis se préparer à passer à la phase suivante, c'est comme la conception et le revêtement de la chose. 10. Exemple de 2 ou 6 exigences: Donc, terminons cette section avec un autre exemple d'exemples sont vraiment importants parce qu'ils nous permettent de se salir les mains et de faire la chose pour réellement passer par certaines exigences. C' est très utile, car beaucoup de ces informations peuvent en quelque sorte aller dans une oreille et dans l'autre. Mais si vous faites un exemple, alors vous pouvez vraiment cimenter cela dans votre esprit. Et chaque fois que quelque chose se produira, vous vous souviendrez peut-être pas tous les éléments des exigences et des définitions entre les deux Mais vous vous souvenez assez que vous laissez la caution pour faire une recherche Google intelligente pour elle, . ou vous serez en mesure de faire un plan et ensuite rechercher peut-être d'autres choses que vous devriez inclure dans la documentation de vos exigences. Donc avec cet exemple, ce que nous allons dio, c'est que nous allons juste prendre, genre, un scénario du monde réel et juste travailler avec ces exemples. Rappelez-vous, nous n'essayons pas d'y aller à 100%. On n'essaye pas. Pensez à toutes les possibilités imaginables dans le monde réel que vous pourriez, mais cela prend généralement des semaines pour le faire dans ces choses étaient juste essayer de sortir. Les 80 % ont essayé d'assommer, vous savez, les 80 % des exigences qui pourraient entrer dans ce domaine et ensuite, vous savez, si vous le voulez vraiment, vous pouvez vous asseoir plus tard et faire le reste. Ou nous pourrions simplement aller de l'avant et en quelque sorte construire dessus au fur et à mesure que nous avançons. Donc, ce que nous avons est que nous n'avons pas déjà construit application d'échecs. Donc, disons que nous avons un téléphone et où nous avons été chargés d'une application, essentiellement la poitrine. Donc tu sais, échecs, le jeu d'échecs. Si vous ne savez pas ce qu'est les échecs, venez avec n'importe quel jeu que vous connaissez. Et donc nous avons une application de jeu, et nous voulons monétiser cette application pour commencer à gagner de l'argent. Donc, c'est notre objectif est de prendre cette application quoi que ce soit, mais cela fonctionne, Peut-être qu'il y a. Peut-être que c'est un en ligne à. Peut-être que c'est vraiment n'importe quoi. Nous allons prendre ce jeu et nous allons commencer à monétiser, donc nous devons réfléchir aux autres mesures que nous devrions prendre. Comment devrions-nous définir le problème et ce qui profitera à la fois au client et aux utilisateurs et avec tout cela, nous pouvons utiliser à nouveau ce modèle mondial. Souviens-toi, on va chercher le monde. Donc, les hypothèses que nous allons chercher pour les exigences. Donc ce qui est exactement nécessaire de cette application, et ensuite nous allons chercher ces spécifications. Alors, quels sont les détails techniques de la façon dont nous voulons mettre en œuvre cela à quelles sont certaines des limites que nous devons respecter ? Disons que l'application précédente est construite en Java et que le client veut le garder de cette façon. Donc c'est là que les contraintes que je peux vous donner aussi, toute façon, il serait très bénéfique pour vous de mettre la vidéo en pause et de passer en quelque sorte ces trois ici. Et si vous remarquez que nous n'avons pas parlé de la façon de monétiser la sortie. Alors, venez avec quelque chose venir avec une idée sur la façon dont vous pourriez le monétiser. Peut-être qu'il n'y a pas de publicités dedans et que vous voulez ajouter des annonces Peut être votre idée de cette application. Est-ce déjà des annonces Hades Et vous voulez ajouter un modèle d'abonnement ? Ou peut-être que vous voulez créer une version payante. Qu' est-ce qui irait dans la version payante venir avec une idée sur une application et ensuite comment vous pourriez faire avancer cette application et ensuite sorte de venir avec les hypothèses, les exigences et les spécifications à ce sujet. Et encore une fois, c'est un exercice. Juste être créatif, amusez-vous un peu avec elle, peut-être passer cinq minutes dessus et ensuite revenir et vous pouvez voir comment je suis allé avec. On peut comparer, euh, voir les différences sur la façon dont ça et vous voyez aussi qu'il y a un tas de façons différentes de faire tout ça, déposer des vidéos, faire ça et d'être de retour. D' accord, donc j'espère que tu l'as fait parce que je pense que le faire tout seul et la revoir ce sera un excellent moyen de cimenter cette information dans ta tête. Donc, la première chose que je suis allé sur les hypothèses du monde, Les choses que nous supposons à propos de cette application, les hypothèses sont importantes car il nous permet de définir les exigences avec les hypothèses ont alors été en mesure de comprendre que nous ne Nous n'avons pas à définir, vous savez, exigences stupides comme les téléphones existent ou quelque chose comme ça. Nous allons avoir besoin de créer un téléphone qui peut supporter l'abside avec des hypothèses. Nous supposons que le monde est une certaine façon et qu'il nous permet de mettre ces choses dans une boîte ailleurs et de travailler sur les choses qui nous aideront. Donc, dans cette situation, nous avons qu'il y a un moyen de payer sur les smartphones. Il doit y avoir un service financier sur les smartphones. Pour que nous puissions effectuer ces transactions, il y a des moyens de gagner de l'argent à partir d'une APP. Il doit y avoir une technique de marketing viable pour gagner de l'argent à partir d'une APP. Si ces deux-là n'existent pas, alors on va devoir inventer tout ça nous-mêmes. Et cette tâche devient soudainement vraiment, vraiment énorme parce que maintenant les exigences vont devoir détailler comment vous savez ce qu' est le marché , quels sont les risques potentiels, choses comme ça. Mais si on peut supposer que ces deux choses existent, alors on doit penser à Ok, quelles sont les meilleures façons de le faire, alors ? L' application est extensible. Peut-être que la base de code est si mauvaise qu'il n'y a aucun moyen que nous puissions étendre l'application à autre chose, donc nous allons supposer que c'est extensible. Sinon, ce projet va juste, tu sais, arrêter dans l'eau. Ça n'ira nulle part. Il y aura une possibilité de contacter Internet et l'institution financière. Donc, le téléphone a à nouveau des capacités Internet. Nous n'avons pas besoin de définir une nouvelle façon pour les téléphones de se connecter à Internet. On va supposer qu'il a des capacités Internet. L' effacement de la transaction pourrait être rendu assez sûr. On va supposer qu'il y a un moyen de sécuriser les transactions. Les gens le font partout avec différentes transactions, donc il y a probablement un moyen de les sécuriser. Le téléphone aura la puissance de traitement pour traiter la demande. Nous espérons que ces demandes seront bas de gamme et que la puissance de traitement sera là. Si ce n'est pas le cas, nous devons attendre la nouvelle technologie. Différentes devises pourront être acceptées. Nous avons une application mondiale. Alors peut-être que nous espérons qu'il y aura des devises du monde entier qui pourront être transférées d'une manière ou d'une autre. Peut-être, par exemple, il Disons que le marché ne nous a accepté que des dollars. Cela changerait notre approche d'une tonne. Mais si nous supposons qu'il existe un moyen d'accepter des devises du monde entier, alors nous n'avons même pas à y penser. Espérons que le marché le fera lui-même, et alors il est légal d'accepter le paiement par téléphone. C' est important parce qu'il y a peut-être un pays où il n'est pas légal d'accepter le paiement sans qu'ils soient en personne ou quelque chose comme ça. Donc nous devons comprendre les lois pour ne pas avoir de problèmes juridiques. Nous devons comprendre que tout ce que nous faisons est un processus juridique que nous n'avons pas besoin d'impliquer les abaissés. Nous n'avons pas besoin de changer les lois ou de remplir certains formulaires pour la rendre légale. Donc, c'est un important à supposer et quelque chose que vous devriez penser avec les exigences juste au cas où. Par exemple, si vous envisagez de collecter des données, vous devez peut-être vous assurer qu'il existe une politique de confidentialité. Peut-être que cela doit entrer dans vos exigences est qu'il est légal avec une politique de confidentialité, Donc maintenant vous devez mettre dans cette exigence. Donc nous le savons alors nous avons nos hypothèses mondiales. Ensuite sont les exigences. Alors je suis allé faire des choses que je pensais marcherais. Je viens de penser à une application qui avait déjà des publicités. Et puis un modèle d'abonnement supprimerait les annonces Quelque chose de très, très simple. Donc, la fonctionnalité pro a supprimé les annonces pour l'utilisateur que je suis en train de définir. Quelles sont exactement les fonctionnalités pro ? Je vais faire quelque chose de simple. Il va juste supprimer, ajouter Donc ça va être notre fonctionnalité pro juste là. Donc, l'étape suivante est que la fonctionnalité doit accepter le paiement d'un utilisateur. C' est assez important s'il n'accepte pas le paiement d'un utilisateur qu'il n'y a aucun moyen que nous puissions les facturer là où il n'y a nulle part où nous sommes amis. Par conséquent, nous ne devrions pas donner à l'utilisateur quoi que ce soit. La fonctionnalité doit fournir des fonctionnalités pro en cas de transaction réussie. Nous pourrions accepter l'argent de la personne et ne rien faire dans l'APP. Ensuite, notre application va probablement être fermée dans l'APP Store, donc nous devons être en mesure de fournir les fonctionnalités pro sur un succès et c'est important une transaction réussie. Nous devons vérifier si c'est réussi ou non. L' enseignant doit à nouveau effectuer les transactions de manière sécurisée. Nous ne voulons pas de violations de données. C' est mauvais pour tout le monde. C' est mauvais parce que ça permet aux autres d'être exploités et c'est mauvais parce que ça nous fait paraître mauvais. La fonctionnalité ou vote pro fonctionnalités une fois qu'un abonnement devient invalide. Donc, si quelqu'un arrête de payer, nous devrions supprimer les fonctionnalités. Sinon, quelqu'un va juste le faire la première fois et puis juste ne jamais payer à nouveau et toujours obtenir toutes les fonctionnalités pro. La fonctionnalité fournira un bouton d'annulation dans l'APP. Ce n'est pas quelque chose que tu dois faire. Peut-être de nos jours, dans le genre d'application qui commence à devenir quelque chose que vous avez à dio. Mais peut-être avec notre application, nous apprécions la confiance dans notre entreprise. Donc nous allons avoir ce bouton d'annulation dans l'application qui enverra un signal qui annule l'abonnement pour tous les mois à venir. L' habitude s'étend sur la base de code existante. Nous ne voulons pas reconcevoir cette application, donc nous allons essayer de l'étendre à partir de la base de code actuelle. La fonctionnalité ne doit pas ajouter plus de cinq mégaoctets à la taille globale du téléchargement. Peut-être que c'est quelque chose que le patron général a dit. Ou peut-être que c'est quelque chose que le client a dit que notre application est déjà très grande et les gens se plaignent à ce sujet, donc cela ne peut pas dépasser cinq mégaoctets, quelque chose qui pourrait arriver. Donc, je l'ai jeté là, et la fonctionnalité doit terminer la transaction en temps opportun. Nous ne voulons pas que ce soit une fonction très, très lente. Donc, nous avons cette idée qu'il devrait être complété en temps opportun et ensuite avec leurs spécifications, nous pouvons en quelque sorte aller là-dedans un peu plus en profondeur. Maintenant, nous avons les hypothèses du monde. Nous avons les exigences, et maintenant nous avons les spécifications. La fonctionnalité sera codée en Java avec le langage APS existant. Rappelez-vous, ce dont nous avons parlé est que l'APP a été codée en Java, donc c'est une spécification à la technologie. Lorsque vous visualisez est le langage APS existant, nous n'aurions peut-être pas besoin de spécifier le travail dans cette spécification. Nous pourrions simplement dire le langage APS existant, mais j'aime être un peu contondant et vraiment, vraiment transparent et ce genre de documents, la fonctionnalité utilisera le magasin de jeu Android pour ses transactions. C' est quelque chose que vous savez, il y a un tas de façons différentes que vous pouvez accepter le paiement. Vous pourriez, par exemple, implémenter quelque chose appelé stripe, qui est une technologie qui accepte les paiements. C' est un logiciel de transaction. Mais pour cette situation, ce que nous allons faire est que nous voulons utiliser le Android Play Store pour faire toutes les transactions sur. Si nous voulions faire cela est arrivé, peut-être IOS aussi bien. On utilise le magasin de pommes là-bas. La vérification Futural pour l'abonnement actif quotidien en utilisant Google fourni un P I. C'est très technique, mais quelque chose qui est important quelque chose que les développeurs ont besoin de savoir est à quelle fréquence voulons-nous vérifier pour voir si un l'abonnement est toujours valide ? disais qu'on va utiliser le Googles AP I pour vérifier tous les jours. Si la description est valide, ne faites rien de ce qui est invalide. Retirez les privilèges. Ou peut-être mettre une période de grâce. Quelque chose comme ça. La fonction s'éteint. Ajouter la foule. Une fois que la clé d'abonnement devient valide, ajouter mob est un moyen de publicité à l'intérieur de votre APS. Il pourrait passer à une nouvelle technologie au moment où vous regarderez ça. Peut-être que c'est une technologie qui sorte de défunte que personne n'utilise plus, mais c'est OK, Tout ce que je dis c'est que nous avons cette technologie dans notre application, et nous disons qu'une fois que la clé d'abonnement devient valide, nous supprimer ce genre de. Nous supprimons cette technologie de l'application afin que l'utilisateur dispose de ces fonctionnalités pro. Et puis c'est le dernier, celui ici en temps opportun. Disons que nous, pour une raison quelconque, nous avons un minuteur qu'il doit pouvoir terminer en 500 millisecondes. Une fois que vous cliquez à nouveau sur le bouton OK, peut-être que cela est transmis par le client. Ou peut-être que c'est juste quelque chose que votre entreprise aime faire. Ils ont ce genre d'idée de la solidité et ils veulent la définir. Donc, dans cette situation, nous avons l'exigence qu'il devrait être en temps opportun dans les spécifications. Nous donnons en quelque sorte l'exactitude de cela et de ceci. Comme je l'ai dit, ce n'est pas un exemple à 100% ici, mais imaginez si vous aviez juste ce document pour sortir, et que quelqu'un vous a remis ce document et a dit, je veux que vous codiez ceci. Vous avez soudainement une direction très forte de ce que vous voulez faire. Et vous avez aussi maintenant la possibilité de poser des questions. Ils ont défini 85 %. Et peut-être que vous venez dans une situation où, comme, il n'y a rien ici et maintenant vous pouvez réellement poser les questions appropriées à votre client ou à votre entreprise de Hey, quelle couleur les boutons devraient être, ou quelque chose comme ça qui n'a pas été défini nulle part ici ? Est-ce quelque chose que je devrais choisir ? C' est quelque chose que vous voulez choisir, etcetera. Donc, à venir avec ce document de configuration requise, c'est un excellent moyen de construire un logiciel. Ensuite, nous allons entrer dans le visage du design. Donc, une fois que nous aurons tout cela, il est temps de vraiment descendre un peu dans le minutieux et de commencer à revoir comment , exactement nous voulons construire n'importe quel logiciel que nous essayons de construire. 11. Introduction en architecture 3-1: Commençons par le plus haut niveau de conception et par le plus haut niveau, je veux dire le moins spécifique. Ainsi, par exemple, si vous concevez une ville, vous pouvez commencer par zoner les différentes zones. On veut un quartier résidentiel par ici. On veut de la pub ici. Nous voulons de l'industrie ici, rien d'autre. C' est juste un plan très, très basique sur le fonctionnement de la ville. Et c'est comme ça que se passe l'architecture. Nous le prenons à partir des exigences et maintenant en fait sorte de venir avec une idée sur la façon dont l'application devrait fonctionner. C' est pourquoi l'architecture est le plus haut niveau, ou le plus haut niveau de design. Les architectes sont le lien entre l'idée et la réalité, sorte que les architectes sont des personnes qui mettent en œuvre l'architecture. Disons que vous avez un bâtiment que vous allez construire avant de commencer. Avant même d'avoir une idée ou des personnes sur place pour construire ce bâtiment, vous allez trouver des plans. Il y aura essentiellement des ingénieurs qui testent les différentes parties, comme dire qu'on a besoin d'au moins un ibeam de 15 pieds ici ou nous avons besoin de ce type de construction ici et vous allez utiliser fondamentalement ce plan pour construire le bâtiment. Rien n'est en train d'être mis en œuvre. C' est juste un design, et c'est ce que fait l'architecte. Quelqu' un avait une idée pour un immeuble. L' architecte prend cette idée, et ils élaborent un plan pour la mettre en réalité. C' est pour ça qu'ils sont le lien entre ça. Ce ne sont pas en fait ceux qui l'ont créé, et ce ne sont pas ceux que vous avez habituellement inventés. L' idée. Ce sont eux qui construisent ce lien entre les deux afin qu'une équipe de construction puisse le construire, et la personne qui a eu l'idée peut le voir construire. C' est donc l'importance des architectes et de l'ingénierie logicielle. Beaucoup de fois, nous devons devenir les architectes, donc nous devons prendre notre document sur les exigences, et nous devons le transférer dans un plan sur la façon de le construire réellement afin que nous puissions encore fois avec un programmeur logiciel aussi. Nous pouvons mettre en œuvre l'idée. C' est l'importance de l'architecture qui fournit ce lien. Maintenant, l'architecture est importante. C' est quelque chose qui ne peut pas être corrigé, une fois mis en œuvre ou dans le rôle de logiciel dans le monde qui ne peut pas être réparé et l' ingénierie logicielle Il pourrait juste être vraiment, vraiment, vraiment, vraiment difficile à corriger, mais une sorte de l'afficher comme quelque chose qui ne peut pas être corrigé. Une fois implémenté dans un logiciel, mauvaise architecture est quelque chose qui ne peut pas être corrigé avec une bonne programmation. Si vous concevez mal l'architecture d'une application, peu importe la qualité de vos programmeurs, cela va toujours apparaître comme un produit pauvre qui prend beaucoup trop de temps à maintenir, et c'est très difficile à étendre et à améliorer au fil du temps. Imaginez essayer de réparer les fondations d'un gratte-ciel après qu'il ait atteint 20 étages de haut. Disons qu'ils ont commencé la construction de ce gratte-ciel et qu'ils sont à peu près aussi haut. Tu sais, ils sont toujours des grues en train de construire le truc, mais ils réalisent qu'il y a un problème fondamental. La chose sur laquelle le gratte-ciel est construit a un problème. Qu' est-ce que tu fais pour réparer ça ? C' est tellement plus difficile de le réparer quand tu as 20 étages, alors quand tu as juste le fond de teint, regarde-le aller. En fait, cette fondation ne va pas marcher. Détruisons et reconstruisons très rapidement. Ce sera un temps d'exécution très rapide ici, bien que vous devez concevoir un moyen de réparer les fondations tout en ne détruisant pas le gratte-ciel. Ou peut-être que la seule façon de le réparer est que vous devez tout arracher avant de pouvoir le construire à nouveau. C' est beaucoup de fois ce qui se passe et l'ingénierie logicielle aussi. Nous devons abandonner un projet et recommencer à zéro. L' architecture est donc très importante. Allons en quelque sorte décomposer cela et simplement sauter dans peut-être un peu plus d'un exemple orienté logiciel . Disons que nous avons ce serveur ici qui prend dans notre application. Disons que nous avons un composant ici, quelque chose que notre application fait, et qu'il contacte ce taux de serveur comme ça. Et disons que nous avons un autre composant ici, et qu'il contacte l'administrateur. Il reçoit des commentaires, et puis on en a un autre ici contacte celui-ci. Il contacte ça, et puis ça sort et entre ici, et celui-ci monte là-haut et vous savez, donc on obtient ce genre d'application très complexe qui n'a pas beaucoup de et puis ça sort et entre ici, et celui-ci monte là-haut et vous savez, donc on obtient ce genre d'application très complexe qui n'a pas beaucoup dechoses. Il y en a beaucoup, comme des barres transversales qui peuvent aller et autour. Et donc vous pouvez voir que l'architecture, cette application pourrait ne pas être le meilleur. Et pourquoi ne serait-ce pas le meilleur ? Eh bien, disons que nous avons un problème avec notre interface principale, notre serveur principal, que la façon dont nous l'avons conçu, c' est peut-être non sécurisé. Peut-être qu'il y a un moyen facile pour les hackers de pirater cela, et la seule façon de le réparer sera de remplacer le serveur et de changer tous les protocoles. Eh bien, avec une architecture comme celle-ci, imaginez enlever ce composant et en mettre un nouveau à cause de la façon dont il est lié à tout ici, nous allons devoir re-programmer chacun de ces composants petits pas chaque sorte de Lupin ici qui contacte ce serveur central. Nous ne pouvons pas échanger à chaud le serveur. Nous devons re-programmer notre application entière. Chaque composant unique a plusieurs domaines que nous devrions essentiellement re programme pour fonctionner correctement à nouveau. Donc, dans ce seul, nous devrions peut-être programme routier trois ou quatre paramètres différents, et puis quand ils viennent ici et sortent, l'autre côté devrait re-programmer que la façon dont ces données reçoivent, comment ces données reçoivent, elles pourraient devenir très, très complexe. Et vous arrivez à un point où vous regardez le logiciel et vous partez, il n'y a aucun moyen de changer cela non plus. On va devoir rester avec un logiciel non sécurisé ou juste le détruire et recommencer complètement ou abandonner le logiciel et ne le supporte plus. Cela arrive un montant décent aussi. Donc l'architecture, très, très important. On va passer en revue certaines façons de trouver l'idée de l' architecture et de l'affiner. Donc vous avez au moins une bonne compréhension de ce genre de choses. 12. Présentation d'architecture 3-2 et exemple: Commençons notre discussion sur l'architecture avec la raison que nous voulons la couvrir. Et c'est l'architecture logicielle. Comment l'architecture s'applique-t-elle au processus de développement logiciel ? L' architecture logicielle consiste à diviser les systèmes de plus grande taille en systèmes plus petits et ciblés. Cela nous donne beaucoup d'avantages différents, non seulement pour réduire les coûts, mais vous contribuez à le rendre facile à développer pour aider à le faire. Nos ingénieurs ne sont pas prêts à attendre les autres, les gens et tant d'autres choses différentes. Donc, les quelques aspects clés ici sont que la bonne architecture est difficile. Ce n'est pas quelque chose de facile que nous pouvons tous faire. Et c'est pourquoi beaucoup de gens évitent de faire cette partie parce qu'il faut de la réflexion, de la créativité pour trouver une bonne architecture. Et beaucoup de gens veulent juste y entrer et commencer à coder pour ne même pas penser à l'architecture. Et quand vous faites cela, vous construisez quelque chose qui est connu un code spaghetti où vous commencez à construire un fichier puis vous construisez un autre fichier et vous êtes comme, Attendez, qui a besoin d'un lien là-bas. Alors nous avons un autre fichier et, comme, oh, ça doit être lié là aussi. Mais il doit également se connecter à ce fichier. Et lentement, vous commencez à obtenir ce web, ce web spaghetti de code va ensemble et au lieu d'avoir cette belle architecture, vous savez, vous savez, peut-être organisée où peut-être tout contacte un serveur central ou il y a ah , page de constantes qui a tout. Donc, si nous voulons changer quelque chose, nous n'avons qu'à le changer. Un seul endroit. Vous commencez à obtenir ce web vraiment étrange d'appels et de choses comme ça et devient très difficile à retracer les problèmes parce que peut-être le problème commence ici, et il appelle la mauvaise fonction ici, ce qui le fait briser un aspect ici ce qui le fait revenir dans l'ici et appeler une autre mauvaise fonction, aller à ici et puis par ici. Donc c'est là que l'insecte est. Et maintenant, nous devons le retracer à travers tous ces appels pour comprendre que Oh, non, c'était en fait une ligne de code ici. On est par ici. Nous avons moins de liens, et peut-être que la rupture est là. Ou peut-être que le frein est là et qu'il se manifeste ici, on peut faire un regard rapide en arrière et on voit qu'il est juste là. Maintenant, bien sûr, ces airs comme des choses très hypothétiques. Mais cela arrive. Beaucoup, c'est que si nous avons une architecture très propre, les pauses sont faciles à trouver. Une bonne architecture permet également un développement plus rapide et une allocation plus intelligente des tâches. C' est important parce qu'il et puis dire que c'est le point que cela va nous faire économiser de l'argent au fil du temps. Si nous pouvons diviser notre architecture en quelque chose comme ça, alors nous pouvons dire que nous aurons un ingénieur sur une tâche ici, un ingénieur pour un ingénieur. 34 et cinq. Nous obtenons cinq tâches différentes se développant à la fois où si nous avons juste un fichier géant, ou peut-être même, comme seulement deux fichiers géants qui communiquent entre eux, comment nous allions faire travailler cinq ingénieurs différentes tâches. Eh bien, nous pourrions les avoir, vous savez, peut-être tous travailler sur le même fichier en même temps, mais cela provoquerait généralement des conflits de fusion, ce qui signifie, comme j'ai travaillé sur le code ici, il a travaillé sur le code ici, mais pour obtenir son code orteil ici. Il ou elle a dû aller de l'avant et changer quelque chose ici. Alors maintenant je pousse mon code, il pousse son code, et soudain il y a ce grand conflit. Je change de code. Il change de code, et on doit se réunir et aller ligne par ligne pour le réparer. C' est un processus très douloureux. Donc, dans cette situation, ce qui se passe beaucoup de fois, c'est que si nous avons tous les deux besoin de travailler sur le même code, vous devez juste attendre. Donc, vous savez, l' ingénieur 1 termine sa tâche, conçu pour terminer sa tâche. Et maintenant l'ingénieur 3 peut enfin sauter là-dedans et commencer à terminer sa tâche. Donc, c'est quelque chose qui réduit le temps d'inactivité global. Si nous obtenons une bonne architecture et permet à l'entreprise également décider où acheter et où construire . Si nous avons quelque chose comme ça et que nous étions comme, nous n'avons peut-être que quatre ingénieurs, eh bien, peut-être qu'il y a une bonne solution là-bas, et nous n'avons pas besoin de passer tout le temps à le développer peut-être qu'il y a une bonne solution là-bas, et nous n'avons pas besoin de passer tout le temps à le développer. Il suffit de dire OK, nous allons travailler dessus et nous allons juste aller de l'avant et acheter quelque chose qui correspond à ça. Peut-être que c'est comme un formulaire ou quelque chose comme ça. Il y a beaucoup, beaucoup de grandes choses de forme en ligne forme de petits projets que nous pourrions acheter et intégrer dans notre logiciel qui nous permet de construire des chaussures d'orteil l'acheteur. Et puis dans l'ensemble, nous devons toujours nous rappeler que les erreurs d'architecture sont presque impossibles à corriger une fois le codage commencé. Une fois que nous commençons, il est impossible de prendre cela et de le rendre impossible. Je ne veux pas dire que ce n'est pas possible. n'y a aucun moyen que tu puisses le faire. Ce que je veux dire, c'est que cela coûterait du temps et de l'argent à Maurin, que ce serait de construire un nouveau produit comme celui-ci. Donc, par exemple, si nous avions un produit existant juste ici pour le faire comme ça, nous devrions dépenser plus d'argent qu'il ne faudrait pour tout recommencer à supprimer et commencer à partir de nouveau. Et c'est ce que je veux dire quand je dis impossibles affixes qui coûtent désespoir Insee entre les deux. Alors passons comme un petit exemple ici, quelque chose dont on peut juste avoir une idée. Disons que nous créons un site Web, et donc nous commençons par cette mauvaise architecture au début. Donc, nous avons une seule page Web qui contient peut-être 1000 lignes de code. Ou pour cet exemple, c'est lui. Il y a 10 000 lignes de code dedans. Si je vous avais chargé de trouver un élément ici, à quel point pensez-vous que ce serait facile ? Combien d'appels différents pensez-vous ? Où tu devrais aller d'ici, en bas, à ici. Pensez-vous qu'il se produirait chaque fois que vous allez à un document de 10 000 lignes ? Et c'est un petit site web ? Je veux dire, sont leurs sites Web qui ont 100 000 lignes de code. Imaginez qu'ils sont tous sur un seul. Comment diviser ça pour que je ne sache pas, peut-être que 15 ingénieurs puissent travailler là-dessus. Pensez à ça. Disons que la prochaine étape est correcte. On ne veut pas tout notre site Web sur une seule page, alors au lieu de ça, on va être comme quoi ? On a besoin de A, disons, d'un front. Donc nous avons le front end, et ensuite nous avons besoin d'un retour. Alors maintenant, nous créons des fichiers folkloriques. Nous avons l'avant et l'arrière, et ils communiquent les uns avec les autres pour un peu mieux. Maintenant, on peut remettre un ingénieur ici, un avant et un ingénieur. Et si nous avons, par exemple, un bouton apparaît comme la mauvaise couleur, nous savons peut-être que nous allons regarder ce dossier au lieu de ce dossier. Tu sais, celui-ci a peut-être 5000 lignes ou dans cette situation, 50 000 lignes. Et celui-ci a 50 000 lignes. Cela rend juste un peu plus facile à découvrir. Nous n'avons pas à passer par 50 000 lignes de choses qui n'ont pas d'importance. Nous n'avons que de l'avant et des trucs. Et maintenant, nous pouvons commencer à le briser et le faire au lieu de juste front end. Peut-être que nous avons les pages Web brisées, donc nous avons une page Web principale ici. Nous avons peut-être la page de connexion ici, et ensuite nous avons le formulaire ici. Et peut-être que le formulaire est sur Lee Ah, 100 lignes. Et puis la page principale est, vous savez, peut-être 49 000 lignes et ensuite la page de connexion est quelque chose comme, vous savez, peut-être, 900 lignes. Donc c'est toujours ces 50 000 lignes, mais on l'a fait et on va juste garder la fin. Voici le backend. Ouais, ça aurait dû être de retour et pas juste fin eso front end backend. Donc nous avons le back-end ici qui communique toujours. Mais maintenant, nous avons un peu mieux une idée de la façon dont il communique avec les choses. Maintenant, nous avons ceci rompu juste un peu plus. Donc, nous avons la possibilité que si nous disons que la couleur du bouton est fausse, nous pouvons aller dans le fichier plus comme, Eh bien, c'est sur la page du formulaire. Allons voir la page du formulaire. On a lu les 100 lignes juste là, on fait le changement. Donc vous voyez, à mesure que nous brisons mawr et de plus en plus, nous commençons à être en mesure de maintenir ce projet un peu plus, et nous commençons à être en mesure de créer fondamentalement un meilleur produit que nous pouvons développer dans le avenir. Donc maintenant, nous avons juste une idée très, très générale de ce que nous faisons avec l'architecture. En brisant les choses, commençons à passer en revue quelques modèles qu'ils appelaient des modèles ou des modèles de différentes façons que vous pouvez prendre votre projet et le briser et certaines des méthodes éprouvées et vraies faire. 13. Motif de 3 tuyaux et de filtre: Regardons notre premier modèle architectural. Donc, les modèles architecturaux il n'y a jamais vraiment une approche de taille unique, ce qui signifie que nous ne pouvons pas regarder un modèle et développer chaque morceau de logiciel avec ce modèle. Donc, avec ces modèles, ce que nous créons ici, c'est que nous créons une boîte à outils dont nous pouvons tirer parti. Donc, si nous comprenons, peut-être cinq ou six modèles populaires chaque fois que nous arrivons à un problème comprendront exactement comment nous devrions y arriver, ou du moins une direction générale de ce que nous devrions faire. Et puis pour ce problème spécifique. Nous pouvons en fait développer une architecture pour cela. Donc, ne pensez pas que vous pourriez simplement appliquer ces modèles, vous savez complètement et totalement orteil un projet. Ils le sont encore. Ce sont des idées, leur façon de faire les choses. Et vous pourriez penser à un problème. Sois comme, oh , ouais, je vais utiliser un tuyau et un filtre, puis un serveur client et ensuite, vous savez, le lier avec ma propre architecture. Donc juste avec cette petite clause de non-responsabilité, commençons là-dessus. Le 1er 1 comme je l'ai dit, est le modèle de tuyau et de filtre les tuyaux sont les connexions de données. Et les filtres sont des choses comme ça. Comme divisible par 10. Même bizarre. Donc, par exemple, si nous avions un petit ensemble de données ici, si nous avons, genre, un petit ensemble de données de 357, nous pourrions l'envoyer à notre premier filtre, notre deuxième filtre. Et puis peut-être que c'est la sortie. Donc voici les tuyaux. Donc ici, c'est le tuyau, et voici les filtres. Maintenant, il y a un aspect important que nous devons examiner. Il y a quelque chose de très important avec ces tuyaux et filtres. L' entrée doit correspondre à la sortie. Et ce que je veux dire par là, c'est que je ne veux pas dire que, tu sais, 357 doit aller dans tous les filtres, et ensuite 357 doit sortir. Ce que je veux dire, c'est que le même type d'entrée doit sortir de chacun d'entre eux afin que nous puissions rendre l'affaiblir complètement et totalement sorte d'intermix à base de plantes. Prends ça et mets celui-là. On peut prendre ça et mettre celui-là. On peut en ajouter cinq autres. On ne pouvait en faire qu'une. C' est la partie importante. Donc, par exemple, si nous avons 357 et qu'il entre dans un, c'est par exemple, Times 10, ça va sortir avec un exemple de 30 50 70. Et puis ça va aller dans le filtre suivant. Tu as remarqué que c'est exactement la même chose ? C' est juste un autre ensemble de chiffres, peut-être pour celui-ci au lieu de fois. Ted, on dit qu'Onley veut peut-être mettre un autre numéro ici pour que ça marche. On ne veut que bizarre. Donc ça sort et maintenant ça va être 357 et ça va aller dans le prochain. La taille change. C' est parfaitement bien. Mais le type est resté le même. Ils sont toujours juste sens numérique, et encore une fois, je vais continuer à conduire cette maison. C' est le tuyau et le filtre est tout au sujet. Vous prenez un certain type, vous le mettez à travers un filtre et vous obtenez un certain type de retour à l'autre extrémité. Et puis avec le tuyau et le filtre, nous pouvons également appliquer des actions. Et ce qu'ils sont, c'est qu'ils prennent les données et ils font quelque chose avec eux, puis ils retournent exactement les mêmes données. Donc, par exemple, a dit le patron, peut-être que nous avons le 357 Nous l'avons mis dans. Judy, envoie le patron, alors il l'a mis dans le patron. Ça va prendre que ça va lui envoyer. Mais quoi ? Qu' est-ce que c'est ? La sortie affiche à nouveau la séquence de numéros. 357 pour que nous puissions l'envoyer au patron, multiplier par 10 et ensuite l'envoyer aux clients ou quelque chose comme ça. Donc, l'inaction est parfaitement bien comme un filtre, car il fera quelque chose. Ça prendra les données. Peut-être qu'il l'enverra à un serveur. Peut-être qu'il fera un calcul et définira une autre variable. Mais la partie importante est que la sortie doit être l'exacte de l'entrée si elle est dans. Si c'est une action, je veux dire que vous pourriez changer dans l'action et la faire sortir différemment, mais il doit y avoir une sortie avec laquelle nous pouvons travailler. Alors passons en revue quelques petits exemples ici et comment vous pourriez l'utiliser. Disons que vous avez une société d'investissement et que vous travaillez avec, vous savez, des actions qui ont augmenté et diminué. Donc vous avez cette liste de profits et de pertes sur vos actions alors peut-être le 1er 1 Peut-être qu'ils sont tous en dollars. Vous avez le 1er 1 est un 10 positif, puis peut-être un négatif 30 et puis peut-être un 11 positif puis négatif 15. Disons que ce ne sont que les chiffres avec lesquels vous travaillez. Donc maintenant, ce que nous pouvons faire, c'est en quelque sorte de construire un modèle pour nous aider avec cela. Nous voulons donc prendre tout ce qui est supérieur à zéro. Donc on va prendre le plus grand que 01 ici. Et puis on veut envoyer ça aux clients. Nous voulons montrer aux clients que nous faisons du bien, que nous faisons de très bonnes choses ici. Donc quelque chose de plus grand que zéro que nous allons envoyer aux clients et ensuite quelque chose de moins que zéro nous allons envoyer au patron comme So ? Donc on va attraper ça, on va l'envoyer au patron. Et maintenant ce qu'on va dio, c'est qu'on prend ces données et on les met dans. Donc si on met ces données ici, ça va aller plus loin que zéro. Et ce qui va sortir, c'est seulement les 10 et les 11 qui seront adoptés dans les clients du Sénat . Ils vont être envoyés aux clients, et ensuite ça va passer une sortie. Il ne reste plus rien, ce qui s'arrête juste là, et ensuite nous le passons aussi en moins de zéro. Et puis on envoie ça au patron, comme ça, et ensuite c'est tout ce qui va être. Voici négatif 30, puis négatif 15. Donc les clients ont ce qui se passe bien, et notre patron a ce qui va mal. Peut-être qu'il peut aider à corriger la situation. Et beaucoup de fois, le tuyau et les filtres le feront. Nous aurons cette architecture où vous sortirez et vous aurez une sorte de briser dans ces choses distinctes et peut-être même les données reviennent ensemble, et ça continue de fonctionner. Peut-être que tout ça commence leurs propres petites chaînes ou quelque chose comme ça. Mais le tuyau et le filtre nous permettent juste de prendre les mêmes données et de les jeter de la manière que nous voulons. Par exemple, encore une fois, juste pour l'amour de la clarté. Cela fera un peu moins depuis, mais disons, au lieu d'envoyer les clients pour une raison quelconque, nous voulons seulement envoyer des numéros impairs. Donc on prend les clients du centre et on le déplace ici, puis on monte ici et on dit qu'on veut seulement utiliser des nombres impairs. Et encore une fois, c'est un exemple bizarre, mais cela fonctionne parfaitement bien. Le code fonctionne parce qu'il y a des petites boîtes noires. Tant que ses chiffres arrivent, peu importe comment tu as arrangé ça. Donc maintenant, il va attraper tous les nombres supérieurs à zéro va alors seulement prendre les chances. Donc ça veut dire qu'on ne restera qu'avec 10 ici, et ensuite ça va les envoyer aux clients. Et encore une fois, vous pouvez les mélanger de n'importe quelle façon, forme ou forme. Mais c'est sur toute l'approche des tuyaux et des filtres. Un membre des points clés ici sont que l'entrée doit correspondre à la sortie. Donc, si vous avez un ensemble de nombres et que vous devez sortir comme un ensemble de nombres, si vous avez un ensemble de chaînes qui devaient sortir comme un ensemble de chaînes ou de quelque façon que cela fonctionnerait avec le même type de types ici et puis aussi, euh, même si vous utilisez une action, vous devez également afficher cette action. Tout doit être personnalisable où vous pouvez les glisser et les déposer dans l'ordre que vous voulez, et ils fonctionneront parfaitement avec cet ordre. 14. Motif client-serveur 3-4: Parlons maintenant du modèle de serveur client. Ceci est également parfois appelé modèle de serveur client. Mais le modèle de serveur client est un modèle que nous avons tous utilisé auparavant, et beaucoup d'entre vous pourraient regarder cela et être comme, Attends, c'est un modèle. C' est quelque chose que nous pouvons apprendre à propos de ça qui ressemblait à des connaissances communes. Mais oui, c'est un modèle. C' est une façon de mettre les choses en place. Donc, avec le modèle de serveur client, ce que nous avons, c'est que nous avons un serveur central. Donc, par exemple, aura nous allons garder avec un schéma de couleurs de cette petite image sur la droite ici. Donc, nous avons un serveur ici, et ensuite nous avons des clients qui contactent le serveur pour obtenir des informations, donc nous avons de petits clients ici et là. Encore une fois, allons-y avec le schéma de couleurs ici. Nous avons donc des clients client client, et ils ont tous demandé au serveur pour des informations. Le serveur distribue ensuite ces informations à ce point affaiblir aux clients, sorte que les requêtes entrent et le serveur distribue les requêtes de retour, et c'est ainsi que fonctionne essentiellement l'ensemble de l'Internet. Si vous allez sur facebook dot com. Vous contactez le serveur Facebook. Donc, cela, par exemple, pourrait être Facebook. Vous contactez le serveur Facebook, vous lui demandez tout un tas d'informations, et il vous donne toutes les informations qu'il vous donne. Par exemple, les dernières mises à jour de votre chronologie. Il vous donne le code HTML afin que vous puissiez charger la page Web. Il vous donne toutes les images, vous indique où se trouve tout, et il vous envoie réellement ces données. Et chaque fois que vous mettez à jour une page chaque fois que vous accédez à une nouvelle page, une nouvelle demande est envoyée au serveur et une nouvelle réponse revient du serveur. Et alors quoi ? C' est pourquoi c'est un modèle, c'est parce que c'est un moyen que nous pouvons tous nous connecter à un élément central de données ou à un hub central d'informations. Disons que Ah, loin une bonne façon d'expliquer que c'est sur un serveur de jeu. Si, par exemple, vous jouez à un jeu en ligne comme Call of duty ou joueurs terrains de bataille inconnus ou quinzaine, tous ces jeux que vous jouez tous sur exactement la même heure sur le même serveur, et c'est là que beaucoup de gens comprennent. Ils ont déjà entendu le serveur de mots. Donc vous avez tous ces gens et ils jouent tous le jeu exactement en même temps. Maintenant, ce que le serveur fait, c'est qu'il calcule tout. Il prend une information, donc ça prend chaque seconde peut-être, ou peut-être même toutes les 10 fois par seconde. Je ne sais pas combien de fois il met à jour le serveur. Votre client. Votre ordinateur envoie au serveur votre emplacement, vitesse de déplacement, les éléments que vous avez. Et le serveur met à jour son petit journal de données avec tous ces trucs. Il n'a pas pris ces données, et il les envoie à chacun des clients tous les X nombre de millisecondes ou de secondes. De cette façon, lorsque vous jouez à votre jeu, si quelqu'un entre dans. Donc, par exemple, disons que c'est la carte dans le jeu. Tu es juste là. Si quelqu'un entre dans votre vision, vous obtenez un message qui indique à votre ordinateur où ses emplacements à cette aide, car cela permet maintenant à votre ordinateur de rendre ou de montrer cette autre personne en temps réel afin que vous demandiez qu'il vous envoie demande qu'il envoie et il y a 100 ou 200 personnes qui le font exactement en même temps. Et c'est ce qui construit la carte et permet à tout le monde de courir. Maintenant, si vous avez un retard de serveur, s'il y a un retard dans le jeu, c'est parce que cela prend trop de temps. Vous avez demandé des données, puis au moment où les données vous reviennent, cette personne a déjà beaucoup avancé. Maintenant, votre ordinateur essaie de les afficher ici. Et puis il reçoit un autre message que non, la personne est en fait là, donc ils sont en retard sur l'écran, et c'est une panne courante de vos serveurs. Pour ralentir, c'est que les clients ne peuvent pas obtenir l'information. Mais le modèle de serveur client est un modèle assez simple que nous utilisons encore une fois tous. Il a juste un serveur central, et vous avez tout un tas de clients qui ont peut-être un logiciel client qui contacte le serveur, qui a généralement un logiciel serveur. Donc, il y a généralement deux types. Vous avez le logiciel serveur, puis ici vous avez le logiciel client sur chacun de ces, données de requête de Clement et dans les données sont renvoyées 15. Motivateur d'esclave Master-Slave: Notre prochain modèle dont nous voulons parler est quelque chose connu sous le nom de modèle maître esclave . Donc, comme la description va en quelque sorte, il y a deux éléments à cela. Tant le maître, qui est généralement représenté au sommet d'une sorte de hiérarchie, puis en dessous, tout un tas d'esclaves. Donc, nous avons dans cette situation va juste créer trois esclaves différents ici, Donc il pourrait y avoir trois. Il pourrait y en avoir six. Il pourrait y avoir 1000 esclaves différents. Peu importe ce que tout cela compte, c'est que ce genre de contrôle est unidirectionnel, qui signifie que disons que cette couleur ici sont les commandes. Les commandes de Lee descendent. Donc le maître dit toujours aux esclaves quoi dio Les esclaves ne sont jamais, en fait, en quelque sorte. Ils ne contrôlent pas le maître. Ils ne le disent pas comme ça. Ça devrait faire quelque chose. Un exemple de ceci est pour, um avec la réplication de base de données. Disons que c'est notre base de données principale sur nos principaux contacts de base de données. Disons que notre serveur, ainsi que nos contacts serveur. Une base de données inversement, puis notre serveur livre les données sur le web. Donc avec le maître, c'est toujours celui qui sera le plus à jour. Il va apporter des données à jour, envoyer des données maintenant avec les esclaves. Les esclaves doivent dupliquer les données du maître . Donc, le capitaine dit qu'il peut être à minuit ou 3 heures du matin pour se mettre à jour. Donc, il enverra une commande à l'esclave un ici qui dit esclave un. Commencez à copier mes données dans vos données. Et ça va le prendre. Il saisira tous les nouveaux changements, et il se mettra à jour. Et puis l'esclave se calmera. Il ne fera rien tant qu'il n'aura pas été commandé à nouveau par le maître. Uh, les clés USB ou les périphériques utilisent aussi. Donc, disons que nous avons un ordinateur ici et que nous avons, vous savez, vous savez, le CPU central et puis le ram et etcetera, etcetera, etcetera, etcetera. Mais ce que nous avons, c'est qu'on branche une clé USB ici. La clé USB agit comme un esclave. Il ne dit pas le processus ou quoi dio le processeur. Dans cette situation, nous avons le taux de processeur ici, n'écoute jamais cette clé USB. Il n'écoute pas, vous savez, vous savez, ce sont des commandes ou quoi que ce soit. Le processeur contacte la clé USB et lui dit, OK, OK, faites n'importe quelle tâche nous de la science. Disons que nous copions des données. Il dit, Ok, prenez vos données et déchargez-le, aussi, sont disque dur. Donc, le lecteur USB hors chargé sur le disque dur, puis le processeur continue à faire ses autres tâches. Et chaque fois que nous devons réellement contacter la clé USB, il le fait exactement. Il le contacte, puis l'U. S. B. Drive fait tout ce qu'il lui dit. USB Drive n'essaie jamais de contrôler quoi que ce soit d'autre à moins qu'il ne devienne un virus. Dans ce cas, le maître esclave tombe en panne. Mais dans cette situation avec un lecteur USB normal, le lecteur USB est un esclave dans cette situation. Et donc ça. Tu sais, on parlait de matériel, mais avec le logiciel, on peut le faire aussi. Typiquement, nous faisons cela avec quelque chose appelé un contrôleur. Donc, le contrôleur est toujours celui qui va contacter toutes les petites pièces et leur dire quoi dio. Donc, avec ce genre d'architecture, nous n'avons pas de communication entre nos petits morceaux comme ça qui n'arrive jamais. Donc, avec un contrôleur et un patron esclave maître, ce que nous avons est ce contrôleur qui donne des ordres. Donc le contrôleur donne les ordres. Ensuite, nous avons des messages qui reviennent pour que les messages reviennent. Et ensuite, si des données doivent être ajoutées à ces données, c'est le contrôleur qui le fait lui-même. Donc, fondamentalement, c'est une sorte d'isoler chaque unité ici, chaque module, isolant complètement l'un de l'autre pour que nous puissions soit affaiblir, les échanger. Nous pourrions les étiqueter ou les échanger et, si cela le permet, nous n'avons pas cette communication croisée ici, où il est très difficile de retracer le flux d'informations. Nous savons que s'il y a de mauvaises informations qui viennent ici, ça doit venir du contrôleur. Le contrôleur doit avoir une erreur, ou il doit y avoir une chaîne, et cela nous permet de sorte de backtrack. Ça change un peu mieux au lieu d'avoir comme ça semble un peu compliqué, mais imaginez s'il est communiqué. Tu sais, comme ça où il y a juste des communications ici et ici que celle-ci vient ici . C' est impossible à suivre. Donc ce que nous aimons beaucoup de fois c'est que les orteils ont cette manette. Donc, le maître esclave est un modèle très important. Il est utilisé beaucoup, et l'une des personnes ne se rend même pas compte qu'ils utilisent ce modèle. Mais c'est très bon de s'attaquer à Ah, tout un tas de problèmes différents. 16. Motif en 3-6 calques: Notre modèle suivant est le motif en couches. Donc, le motif en couches est fondamentalement juste que c'est un tas de couches différentes et ce doux pour Rome. Cela signifie que nous avons ces couches de technologie, de sorte que les couches de technologie ne communiquent qu'au sein de leurs propres couches. Ainsi, par exemple, il s'agit d'une couche, et c'est une couche, et c'est une couche. Ce qu'on n'a pas, c'est qu'on n'a pas de communication croisée. On n'a pas ça qui essaye d'appeler des informations de là comme ça. Ce que nous avons, c'est que nous avons la capacité de communiquer d'avant en arrière sur la capacité de communiquer d'avant en arrière. Et puis ces Onley appellent dans leurs couches respectives afin que vous puissiez voir que peut-être un léger inconvénient est que si vous avez quelque chose ici, il pourrait devoir filer vers une autre couche. Vous devrez peut-être passer par quelques dossiers supplémentaires, non ? Un peu de code supplémentaire. Ce qu'il fait, c'est classer les données de sorte que si on cherche, disons que, euh, vous savez, nous avons ceci est notre front end. C' est notre backend, et c'est le lien entre les deux. Si nous avons un problème de retour, nous savons que nous examinons, vous savez, le programme dans cette couche. Et donc c'est toujours assez abstrait, donc c'est en fait passer par un petit exemple ici. exemple que je veux parcourir est unmodèle en couches très populaire, modèle en couches très populaire, et vous pourriez appeler celui-ci un modèle parce que c'est une chose réelle que vous pouvez implémenter. Donc, il s'appelle le contrôleur de vue du modèle. Donc, par exemple, nous allons mettre le contrôleur juste ici et sur le côté droit nous allons mettre la vue et le côté gauche. Nous allons mettre le modèle de sorte que le contrôleur de vue modèle brise les trois aspects différents ici sur le côté droit. Comme je l'ai dit, nous avons le point de vue. La vue est ce qui est montré à l'utilisateur. La vue est ce que nous pouvons cliquer sur, ce que nous pouvons interagir avec. Donc, dans cette situation, disons que nous avons une page de profil, donc vous savez qu'il y a l'image de profil, et ensuite nous avons un petit formulaire ici pour mettre à jour le profil. Donc nous avons ah, boîte une boîte et ensuite la possibilité de soumettre cette boîte. Et peut-être qu'on change le nom ici. Donc, c'est ce que nous allons essayer de changer le nom et l'e-mail maintenant avec le contrôleur de vue du modèle. Ce que nous avons sur le côté gauche, c'est le modèle. Donc c'est la base de données. C' est notre base de données qui a l'utilisateur ici. Donc il va avoir la ligne pour l'utilisateur, puis son nom et son adresse e-mail. Donc, nous avons le nom d'utilisateur et puis l'adresse e-mail juste là. Et, tu sais, il y en a tout un tas. Un tas de noms d'utilisateur email, nom d'utilisateur , email , etcetera , etc. C' est le modèle. Il s'agit de l'entité elle-même. Donc, sur le côté gauche, nous avons le modèle, l'entité. Souvent, c'est la base de données où le type de données est réellement stocké. Maintenant, nous ne voulons pas avoir cette communication croisée est cette capacité pour la vue de parler au modèle ? Donc, ce que nous faisons est de créer quelque chose au milieu appelé le contrôleur. Donc, au milieu, ce que nous avons, c'est que nous avons le contrôleur et le contrôleur gère toute la communication . Ainsi, le modèle contactera le contrôleur et le Cullen Trollen contactera la vue, puis vice versa. La vue contacte un contrôleur et le contrôleur contacte le modèle. Ainsi, par exemple, nous avons cliqué sur le bouton Soumettre ici. Les données que nous avons mises à jour vont aller au contrôleur. Le contrôleur ne va pas avoir une fonction comme peut-être que ce sera une fonction appelée utilisateur de mise à jour. Et puis avec cette fonction, il va ensuite appeler au modèle. Le modèle va récupérer toutes les informations qui ont été mises ici et il va mettre à jour l'utilisateur. Qu' est-ce que ça fait ? Qu' est-ce que cela nous aide à accomplir ? Ça nous aide à comprendre où sont les problèmes. Nous avons cette couche de base de données sur la gauche, et nous avons cette couche de contrôleur au milieu. Et puis nous avons cette couche de vue sur la droite. Maintenant, nous sommes en mesure de comprendre les problèmes. Nous avons le front end. Il s'agit du script Java dans le HTML. Donc, euh, le genre de vue des choses. Et si quelque chose est foiré ici, nous regardons juste le HTML. Nous regardons le site lui-même. Si nous avons un problème avec les données qui sont entrées ici, et qu'elles ne parviennent pas au modèle. Ce qu'on sait, il y a un problème avec le contrôleur. Donc, nous regardons dans la classe contrôleur. Nous regardons la chose principale qui est en fait de contrôler ces deux côtés, puis si la base de données est foirée, si nous avons cela arrive, nous savons que le contrôleur fait bien. Mais certains, pour une raison quelconque, le modèle ne se met pas à jour correctement. Ce que nous savons pour aller regarder les bases de données pour regarder le my SQL, les différents types de façons des bases de données stockant des choses. Il nous permet cette couche. Il nous permet de classer et de construire des éléments différents. Nous pouvons avoir avant et les développeurs ici, nous pourrions avoir des développeurs intermédiaires. Ici. Nous revenons dans les développeurs ici. Habituellement, ces deux classes sont couvertes par retour dans les développeurs, mais vous pouvez aussi avoir un peu de chevauchement où les développeurs frontaux savent un peu ici aussi. ensemble, cependant, le modèle en couches est utilisé beaucoup pour classer nos programmes, pour les séparer afin qu'ils puissent être facilement maintenus afin qu'il n'y ait pas tout un tas de code spaghetti et qu'il est logique pour toutes les personnes impliquées 17. Motif en génie logiciel: alors faites tout cela. Nous essayons de créer le processus d'architecture logicielle, le processus par lequel nous pouvons trouver une architecture pour un problème pour un programme que nous essayons de concevoir. Maintenant, c'est une tâche assez difficile et qui était très loin dans le monde de la création ici. Ce que je veux dire par là, c'est qu'il ne va pas y avoir un exposé x y Z première étape deuxième étape. Troisième étape de ce processus, nous allons devoir faire preuve de créativité. On va penser à notre problème. Nous allons penser à d'autres problèmes qui ont été réglés, et ils ont en quelque sorte tiré de cela et ont conçu une solution unique pour ce que nous essayons de faire . Donc en ce sens, au lieu d'avoir un processus 123, nous avons en quelque sorte une liste d'objectifs que nous essayons atteindre avec notre architecture, et cela pourrait obtenir aussi en profondeur ou aussi haut que nous le voulons afin que nous puissions faire cela très un dans profondeur. Et par là, je veux dire, c'est juste un plan général. Nous pouvons obtenir des informations très détaillées sur la façon dont exactement chaque élément de données va être communiqué. Habituellement avec des projets de plus grande envergure et des grandes entreprises. Vous allez obtenir la profondeur de Maurin et avec une sorte de sociétés en mouvement plus rapide ou des startups plus rapides de la Navy. Nous ne passons pas autant de temps ici, ce qui est d'essayer de faire sortir le produit. Et puis nous décidons de ces choses plus tard, ce qui pourrait être très coûteux. Ou cela pourrait fonctionner pour votre projet, selon la façon dont tout est configuré. Mais de toute façon, ce que nous essayons de faire, c'est de contrôler comment un programme est décomposé et comment il interagit avec lui-même et avec le monde extérieur. C' est important pour le monde extérieur aussi. Nous essayons donc de comprendre comment le programme va se passer. Ce sont des petites connexions. Et aussi comment communique-t-il avec les utilisateurs ? Comment communique-t-il avec d'autres systèmes logiciels ? Comment fait-il cela aussi ? Et nous essayons de comprendre comment il s'intègre fondamentalement dans le monde ? Et puis comment construire cela aussi ? Comment structurer cela de manière à ce qu'il fonctionne correctement et nous essayons également de modéliser comment le contrôle ou nous essayons de modéliser la structure de contrôle du système et comment il se comportera . La structure de contrôle est une sorte de tous ces modèles que nous avons fait. On va avoir une structure de contrôle, ce qui est un peu comme, tu sais, peut-être que ça ou on aura peut-être cet esclave maître esclave où on quelque chose comme ça, on va avoir le tuyau dans le filtre structure de contrôle où nous allons continuer à mettre des données et ensuite les filtrer sur une ligne ? Ou peut-être que nous allons avoir quelque chose comme ça où nous avons en quelque sorte ces sous-systèmes tous assemblés. On va avoir un tuyau dans le filtre. Ça va aller chez un maître esclave. Les maîtres esclaves ne vont pas devenir un peu comme un contrôleur de vue de modèle, etcetera, etcetera. Donc, nous prenons tout cela en quelque sorte et nous essayons de le combiner en une manière qui fonctionne pour notre solution. Et comme je l'ai dit, il n'y a pas de coupure claire. Les problèmes sont une solution. On pourrait avoir une équipe d'ingénieurs. Une autre équipe d'ingénieurs et une autre équipe d'ingénieurs essaient tous de trouver la meilleure architecture pour notre projet. Et ils vont tous être complètement différents. Certains d'entre eux peuvent être complètement, complètement différents. Peut-être que ces gars pensent ce qu'on devrait utiliser un tuyau et un filtre. Ces gars sont comme, non, non, non, le maître esclave. Plus ceci et ce modèle comment nous le faisons. Ces gars ont une façon complètement différente de le faire, et c' est l'importance de l'architecture fondamentalement. C' est ça ? Une sorte de quelque chose que nous devons concevoir par nous-mêmes. faut qu'on le découvre. C' est un processus créatif , c'est pourquoi beaucoup de gens l'ignorent. C' est dur. C' est très difficile à concevoir. Eh bien, la prochaine étape que nous devons faire est de briser le projet dans les sous-systèmes et les modules. Si vous pouvez simplement faire cette étape, vous êtes dans une bonne situation pour votre architecture. Donc, ce que je veux dire par ceci, c'est que nous avons les deux choses qui subsistent, euh, et le module et le sous-système est un système indépendant qui détient une valeur indépendante. Et ce que je veux dire par ceci, c'est que vous pourriez prendre ce système et vous pourriez le brancher dans un autre programme et cela fonctionnerait correctement. Ou vous pourriez même vendre ce système. Quelqu' un pourrait vouloir acheter le système parce qu'il a une sorte de valeur indépendante Ah, . module, cependant, est un composant d'un sous-système qui ne peut pas fonctionner comme un autonome ou s'il fonctionne comme un autonome. C' est très insignifiant. Il n'y a rien de révolutionnaire. Donc, disons que nous avons, par exemple, un petit module qui divise par 10 puis ajoute 30 puis multiplie par 62 un petit module bizarre ici. Et la raison pour laquelle j'utilise le module est la cause. Pensez à ça. C' est un élément d'information. Nous pouvons maintenant nous évanouir dans cela et le distribuer et il obtient un nouveau numéro. Il a une certaine importance pour nous, et nous pouvons le combiner et peut-être un moyen important. Mais pensez-vous que quelqu'un achèterait ça ? C' est très spécifique, et il n'accomplit pas vraiment une tâche en soi. n'y a pas de tâche que nous avons. Peut-être qu'il accomplit une très petite tâche dans un grand système de tâches, mais en soi, il n'a pas de valeur indépendante. Maintenant, disons que nous avons tout un tas de ces petits modules d'équation mathématique, donc nous en avons un ici, un ici, un. Ici, nous avons tous ces petits modules qui fonctionnent, et maintenant ils sont tous des communications croisées, quelle que soit la structure de ce sous-système. Et nous avons maintenant ce sous-système construit et disons que ce sous-système calcule peut-être nos impôts. Donc ce sous-système est maintenant assez bon qu'avec toutes ces petites équations mathématiques Donc sont tout ce que vous savez, comme les fois 10, vous savez, moins 62. Et peut-être que ça calcule notre assurance hypothécaire, etcetera. Vous savez, toutes ces petites équations folles qui vont ensemble ici, et ensuite ça donne enfin combien vous devez en impôts. Donc, il y a peut-être votre revenu, peut-être votre revenu ou quelque chose de quelque chose, et ensuite ce que vous devez en impôt. C' est un module important. C' est quelque chose que nous pourrions utiliser. C' est quelque chose qu'on pourrait vendre à quelqu'un qu'il ne veut peut-être pas passer le temps développer. Cela a une valeur commerciale. Il a une valeur indépendante. Il est composé d'un tas de composants qui n'ont aucune valeur par eux-mêmes. Je veux dire, nous le calcul, vous savez, votre hypothèque hypothécaire pourrait peut-être avoir un peu de valeur, mais quand vous le mettez dans ce contexte géant, nous arrivons à la capacité que nous pouvons en fait, vous savez, arrivez au point de le vendre. Et disons que ce ne sont que nos impôts personnels. Ici, nous avons exactement la même chose. Nous avons tout un tas de petits modules ici et vous l'importez. Et maintenant, vous avez peut-être l'impôt sur les affaires. Et donc vous importez des affaires, faites du taxi sur les affaires portuaires et maintenant, ça va devenir un peu bâclé ici, mais je veux juste ramener ce point à la maison maintenant. Ce que nous avons, c'est que nous avons en fait ce sous-système de sous-systèmes. Donc, dans ce cas, nous avons presque tout notre logiciel. Ou peut-être que notre logiciel est comme tout un truc de finance personnelle, donc il pourrait y en avoir d'autres aussi. Mais nous avons un autre système que nous pourrions vendre aux gens aussi. Donc, cela pourrait être un sous-système entier, et chacun d'entre eux pourrait être plus de sous-systèmes à nouveau. Vous pouvez concevoir cela de toute façon que vous voulez, mais juste une sorte d'essayer de piloter le composant de modules d'accueil de points d'un sous-système qui ne peut pas fonctionner seul. Donc, s'il y a ces petites équations ou des offs qui ne peuvent pas vraiment être vendus, alors ce sera probablement un module. Et puis aussi ce que nous avons, c'est que nous avons le sous-système, qui est à ce module quand ils sont tous assemblés et vendus. Et même avec ce petit peu de réflexion et de planification, nous avons maintenant un moyen de diventer peut-être même. équipes Howard travaillent. On va travailler en équipe du côté des affaires. On va travailler en équipe sur le côté fiscal des particuliers. On va avoir un travail d'équipe ici, un travail d'équipe sur celui-ci, un travail d'équipe sur celui-ci. Peut-être qu'une équipe travaillera sur cette section et qu'une équipe travaillera sur cette section et vous pouvez voir nous avons déjà la capacité de diviser la tâche et de devenir plus efficaces. Et enfin, avec le processus d'architecture logicielle, nous devons garder tout un tas de choses à l'esprit. Et vous pourriez voir que cette liste est vraiment, vraiment, vraiment difficile. C' est en fait de Wikipédia, ce site, si vous ne le mettez pas pour jeter un oeil à ce à quoi ces liens vont, mais ce sont tous ces termes que nous voulons penser. Peut-être voulons-nous seulement penser à cinq ou six de ces termes vraiment, vraiment en profondeur. Mais nous voulons nous assurer que nous réfléchissons à des choses comme, vous savez, est-ce fiable ? La fiabilité de cette architecture ? Quelle est l'efficacité de la résolution de notre projet ? Quelle est la durabilité ? Peut-être qu'on résistera à l'épreuve du temps. Sera-t-il cassé avec plus de données ? Euh, peut-être qu'on veut examiner la capacité de reproduction. Est-ce que ce sera facile de copier à nouveau à un autre problème ? Peut-être que nous avons abordé le même problème encore et encore. Alors peut-être que nous voulons concevoir une solution qui peut être reproduite plusieurs fois dans différentes parties. La vulnérabilité. À quel point est-il sécurisé ? Est-ce que ça va être hackable ? Est-ce que ce sera quelque chose qui comporte déjà un risque connu ? Chacun de ces consort pose de nouvelles questions qui nous permettent peut-être de revenir en arrière et d'affiner un peu notre architecture. La section suivante, nous allons en quelque sorte sauter dans la couche suivante d'architectures. Alors peut-être que nous avons conçu juste un peu de la façon dont notre projet fonctionne et a un contrôle . Full flow fonctionne et le prochain Maintenant, nous allons commencer à sauter dans juste un peu de la conception, aller un peu plus en profondeur pour sorte de hacher ces modules et les différentes parties et comment ils devraient interagir sauf 18. Processus de conception logicielle: notre prochaine étape dans le cheminement de l'ingénierie logicielle sera la conception de logiciels . Donc, nous avons traversé les exigences. Nous avons fait les exigences, les exigences naturellement dans les spécifications, qui sont encore une fois en quelque sorte plus des exigences techniques des spécifications . Nous passons ensuite à l'architecture. Nous avons une sorte d'idée avec les spécifications des exigences. Nous essayons donc de trouver un grand plan de jeu. Comment sont ces modules géants ? Comment vont-ils interagir les uns avec les autres ? Comment les sous-systèmes vont être divisés. Mais à travers cela, nous n'avons pas vraiment parlé de choses comme, quel code allons-nous utiliser ? Quel logiciel nous allons utiliser, quel logiciel de base de données nous allons utiliser. Et c'est là que la prochaine étape intervient, et ça va être le design. Le design est donc une étape où nous commençons à appliquer notre plan et notre idée aux solutions du monde réel. Donc, ce que je veux dire par Riel Rose Solutions, c'est que nous commençons à trouver comment prendre notre architecture, architecture,notre plan global et comment la concevoir ? Comment trouver différentes solutions pour créer cette architecture ? Donc, si notre architecture par exemple, appelait un retour et un serveur. Donc, nous allons faire comme un symbole de serveur là. Et puis nous avons en face de cela, nous avons peut-être une sorte de classe de contrôleur et ensuite peut-être une page Web. Peut-être que c'est comme ça que notre truc est. On fait comme, une sorte de contrôleur de vue modèle. Alors, quelles technologies allons-nous utiliser ? Qu' est-ce qu'il va être de retour en cours d'exécution sur un système d'exploitation basé sur Peut-être Lennox  ? Et à partir de là, notre serveur va faire fonctionner une base de données ? Peut-être que quelque chose comme mon SQL est Quel sera notre milieu ? Est-ce que ça va être Ah, est-ce que ça va être le JavaScript ? Est-ce que ce sera peut-être sur le serveur lui-même, peut-être quelque chose comme PHP ou qui est en quelque sorte sur ces deux, est pourquoi c'est généralement une chose du milieu. Il peut être sur la page Web, mais il exécute effectivement la commande serveur. Donc peut-être que c'est une classe de contrôleur PHP sur notre page Web va être HTML. Ça va être un cadre ? Peut-être que nous utilisons quelque chose comme, si vous en avez entendu parler, WordPress, qui est ce genre de cadre ? C' est comme un dragon dans le créateur ou même, ah, ah, compagnie comme Wicks. W I. X est une entreprise où vous pouvez en quelque sorte glisser et déposer et concevoir vos solutions, mais elle couvre tout cela aussi bien. Alors peut-être que c'est une idée. Donc vous pouvez voir que nous avons un peu mis au point ce plan général de la façon dont nous voulions mettre place les choses, même si c'est plus compliqué avec, vous savez , tout un tas de boîtes bougent de différentes manières et et maintenant il est temps de regarder dans chacune de ces boîtes et de déterminer quelle est la solution du monde réel qui va résoudre cela maintenant à nouveau, tout comme dans les exigences où nous ne voulions pas dépasser nos limites et accidentellement entrer dans la conception de la conception a une limitation à. Nous ne voulons pas entrer accidentellement dans la mise en œuvre, ce qui est la prochaine étape ici. Le design n'est pas codage et le codage n'est pas conçu, ce qui signifie que nous ne commençons pas par construire le framework ou quoi que ce soit du genre. Tout ce que nous essayons de faire, c'est de trouver les solutions du monde réel qui existent. Qu' avons-nous besoin de créer, quelle technologie nous allons utiliser pour créer cela. Et quel genre de plan de jeu pour faire ça ? C' est le design. Maintenant, bien sûr, vous faites un peu de codage exploratoire ici et là. Voyez si une idée fonctionne, c'est comme , oui , vous savez, ces trois lignes de code ici, ils font ce que je pense. Donc on va mettre ça un design. Il n'y a pas delimite stricte ici, mais ce qu'on dit, c'estde ne pas sauter directement dans le revêtement de cette étape. limite stricte ici, mais ce qu'on dit, c'est Ce n'est pas ce qu'est le design. Um, le design est purement à venir avec un plan plus détaillé de l'architecture. Et aussi, chaque fois que nous parlons de design, nous devons aussi comprendre qu'il a une sorte de double signification ici. Le design est à la fois l'activité et le produit. Donc, l'activité travaille à concevoir un logiciel comme où vous avez une équipe de personnes et ils travaillent tous activement, vous savez, à trouver comment ce logiciel devrait interagir. Donc, les gens ici, comment ces offres devraient interagir. Maintenant, le produit est aussi la conception. C' est le document de conception. C' est donc un nom, ce qui signifie que c'est le document lui-même. C' est le produit final, quelque chose que vous pourriez gérer à la maison et ils comprendraient exactement comment fonctionne votre logiciel . Donc, quand nous parlons de conceptions, nous pouvons parler, ces deux choses étaient à la fois la conception du produit, et nous créons un design pour le produit. L' étape suivante, nous allons commencer à entrer dans les étapes de la conception en passant par les questions que nous devons poser les problèmes que nous devons résoudre. 19. 4-2 étapes de conception: passons un ensemble général d'étapes de conception pour les logiciels. Donc, la raison pour laquelle je dis cela, a dit le général c' est que ce n'est pas une solution unique. Il pourrait y avoir un autre ensemble de principes de conception à l'entreprise A Uses par rapport à l'entreprise B. Cependant, si c'est votre introduction au design, c'est un bon début, un bon endroit pour commencer chaque fois que vous pensez au design. Nous avons donc huit étapes ici, et ces étapes pourraient être aussi détaillées ou non détaillées que vous le souhaitez. quelque sorte. Ce que vous mettez, c'est ce que vous obtenez quand vous faites quelque chose comme ça. Si vous passez plus de temps ici, vous passerez moins de temps et de mise en œuvre et de revêtement. Cela dépend donc vraiment de ce que vous voulez faire. Parce que beaucoup de fois, vous trouverez en fait des bugs, des problèmes architecturaux et des problèmes de conception dans la conception ici que vous ne trouverez pas tant que vous n'avez pas déjà couvert la chose jusqu'à ce que vous ayez déjà passé, vous savez, 400 heures de revêtement et puis vous réalisez que vous devez revenir en arrière et refaire quelque chose, donc si vous passez beaucoup de temps ici, vous pouvez beaucoup de temps gagner beaucoup de temps à l'avenir. Donc, nos pas fonctionnent comme ça d'abord, c'est que nous allons briser le plus gros problème en petits problèmes. Si nous concevons, par exemple, Amazon si nous le voulons. Si nous avons cette idée de cette société appelée Amazon et que nous voulons développer ce site Web où ce sera un commerce électronique en ligne et que les gens peuvent, vous savez, envoyer leurs produits à nous et à un tas d'entreprises et venir à Yada, Yada, etcetera il y aura beaucoup de problèmes dans leur. C'est un problème qui va avoir une tonne de problèmes généraux. Et à partir de ces problèmes généraux, nous allons avoir des problèmes plus petits et plus petits jusqu'à ce que nous ayons quelque chose d'un peu plus gérable. Si nous allons avec un exemple légèrement plus petit, cependant, par exemple, dire celui avec le travail, qui crée un site Web, disons que l'un de nos problèmes est la base de données la façon de stocker nos données dans le back-end. Et donc avec ça, c'est notre problème. Ça va être le gros problème l'a divisé en un problème plus petit, qui est comment faire la base de données ? Que faisons-nous pour mettre la base de données en marche ? Donc, dans cette situation, nous l'avons décomposé en un problème de conception de base de données. Maintenant, nous devons comprendre chacun de ces problèmes. Donc, par exemple, si nous faisons cela, nous pouvons le faire un par un. Ou on peut le diviser en un tas de petits problèmes, puis passer à l'étape 2. Et une fois que nous l'avons décomposé plus loin, nous pourrions passer à l'étape 3, etc. Je vais juste faire une sorte de réunion de but ou d'approche de haut en bas, nous allons avoir un problème peut être l'un des nombreux problèmes, par exemple, et puis nous allons juste descendre, étape par étape, sur et plus comme ça. Alors nous en avons besoin. Maintenant, comprenez ce problème ? Quel est le but de ce problème ? Pourquoi avons-nous ce problème ? Le document sur les exigences pourrait être utile ici parce que les documents sur les exigences devraient nous indiquer ce que nous essayons de résoudre. Et maintenant, nous avons une sorte de moyen de revenir en arrière et de regarder, peut-être les exigences. Document dit quelque chose comme, nous avons besoin de stocker les informations de l'utilisateur. Donc, si nous avons besoin de stocker les informations de l'utilisateur. , Bien sûr,nous avons besoin d'une base de données pour ça. Peut-être. Nous devons effectuer des transactions. Si on veut faire des transactions, on va avoir besoin d'une base de données pour ça. Et nous pouvons en quelque sorte énumérer toutes les différentes parties de ce problème informations utilisateur, transactions, images, etc. pour s'adapter à notre problème. Et une fois que nous avons compris tout cela, nous avons maintenant une idée de la base de données que nous devons concevoir. Nous devons donc maintenant identifier des solutions potentielles. Quelles solutions existe-t-il pour nous aider ? Il existe quelque chose appelé AWS Amazon Web services. Nous avons que nous pourrions construire. Nos propres serveurs sont peut-être notre propre serveur. Nous pourrions acheter de l'espace serveur sur une autre société de pays pour l'acheter quelque part . On construit le nôtre, mais on l'envoie à un endroit d'achat. Nous pourrions utiliser différentes technologies comme une base de données My SQL. Une base de données régulière sauvée hors de sa place, peut-être une base de données sans SQL. Sont toutes ces différentes options Et c'est là que nous devons vraiment ouvrir nos esprits et trouver le plus de solutions possible au problème. Nous ne voulons pas entrer dans une sorte d'état d'esprit d'Ok, nous allons travailler avec AWS, et ce sera ceci et ça sans aucune raison pour cela. Peut-être que la société dit peut-être que la société de design ou le client dit que nous devons utiliser huit d'entre nous. C' est très bien. C' est une exigence que quelque chose qui contraint, nous n'avons pas le choix. Dans ce cas, ça va aller dans nos documents de conception, seulement huit d'entre nous. Mais si nous n'avons pas cette contrainte, si nous avons la possibilité de trouver différentes solutions, alors nous devons trouver cette mini solution le plus possible afin de nous assurer de choisir la meilleure . Parce que si nous sommes juste un tunnel de vision nous-mêmes et que nous ne nous concentrons pas ou ah, concentrons pas ou ah, nous allons avoir un problème où une meilleure solution aurait pu être disponible. L' étape suivante consiste à décrire les abstractions de solution. Alors, qu'est-ce que la solution ? Abstraction ? Une solution ? abstractions sont des choses comme des documents de conception qui ne sont pas techniques. Donc, il dit que nous avons un modèle X ici que les contacts, modèle, pourquoi et ce que ce flux de contrôle. Ça remonte au modèle W. et ça contacte ça. C' est une sorte de cette façon d'utiliser des graphiques et des modèles comme ça ici pour trouver un plan global pour notre logiciel. C' est donc une abstraction. C' est ainsi que nous allions mettre en place notre base de données afin que vous puissiez voir que nous avons ah utilisateurs colonne un poste principal ou la table des utilisateurs poste principal employés, poste d'administrateur. Et puis tous ces éléments et ils se connectent tous de cette façon. Maintenant, c'est un peu plus loin du côté technique que certaines abstractions pourraient aller, mais c'est bon. Nous avons que vous savez, au lieu de mettre tout ça ici, on pourrait juste trouver les noms de table. mettre tout ça ici, Ce serait une bonne abstraction pour que nous puissions décrire comment nous allons stocker les données . Mais vous pouvez voir ce que cette table ici. Nous avons une très bonne idée du fonctionnement de la base de données. Donc on l'a choisi. Nous allons utiliser la base de données my SQL dans cette situation, et l'étape suivante est le genre d'abstractions est à venir avec ces modèles. Peut-être que c'est comme ça que fonctionne le contrôleur. Et ce graphique que je viens de vous montrer, ce graphique est peut-être ce module ici. Et puis peut-être que c'est ici, euh peut-être comment les données vont entrer et sortir dans les choses organisationnelles, et qu'on puisse en quelque sorte diviser ça en d'autres. Et fondamentalement, ce que nous faisons, c'est de répéter ce processus encore et encore jusqu'à ce que nous ayons réglé tous ces problèmes. Mémoriser dit qu'on l'avait fait, comme on l'avait fait. Peut-être ces problèmes qui se sont décomposés en ces problèmes, etcetera. Donc on va essayer de tout abstraire jusqu'à ce qu'on finisse. Jusqu' à ce que nous ayons cette sorte vraiment, vraiment top down sorte de niveau sur tous les différents composants et idées sur la façon dont tout fonctionne ensemble jusqu'à ce que ces abstractions soient faites. Puis une fois que nous avons fait tout ça, une fois que toutes ces abstractions sont en quelque sorte comprises ici. Nous allons ensuite passer aux prochaines étapes ici. Donc, beaucoup de fois, nous voulons une boucle ici jusqu'à ce que nous trouvions tout et ensuite nous pouvons passer à l'étape suivante et aux étapes suivantes un peu plus avancées. Suivant. Beaucoup de gens ignorent juste parce que c'est un peu difficile à faire et vous devez avoir l' expérience pour le faire, mais ce sera en fait de coder la chose sans enduire la chose. Rappelez-vous, nous avons dit que le design n'est pas un code. Ce n'est pas un code qui est important. Cependant, cela ne signifie pas que nous ne pouvons pas déterminer comment tout va interagir. Donc, ce que je dis avec cette étape, c'est que nous allons réellement créer les composants comme ça, et ensuite avec chacun de ces composants allaient venir avec peut-être qu'il va utiliser cette classe et cette classe va avoir cette cette méthode, cette méthode. Vous savez, cette méthode parle pour entendre cette méthode parler. Pour entendre cette méthode, on va regarder encore plus loin. Quelle est cette méthode de transfert ? Peut-être que c'est le transfert en tableau. Et comment trions-nous ce tableau ? Peut-être qu'on utilise un algorithme appelé T. Peut-être que nous utilisons un algorithme appelé Merge Sort. Alors nous entrons dans, genre, vraiment, vraiment, des détails grossiers de tout ça. Nous commençons à aller pièce par pièce et à venir avec cette sorte d'arbre de classe géant, qui pourrait être vraiment, vraiment, vraiment, vraiment grand si vous planifiez tout ça. Mais à la fin, nous avons en fait ce grand document où tout le monde peut aller le regarder et comprendre comment le programme fonctionne sans jamais faire tourner un serveur ou un développement. Ils voient juste tout le code là-bas, ce processus. C' est important. Mais je le ferai. Je vais en quelque sorte le professer avec ça, et on en parlera plus tard. Dans le cours. C' est très, très fastidieux. Et il y a tout un tas de frais généraux et la plupart du temps. Une fois que vous concevez ceci, les choses changent et puis il n'est pas mis à jour, donc il devient obsolète et fondamentalement inutile. Donc, même si ces étapes sont citées sans citation importantes dans le processus de conception, nouveaux modèles de nos jours en font une sorte de renoncer à cela pour développer solutions plus rapides et plus rapides. On jette en quelque sorte la documentation juste un peu parce qu'on n'a pas besoin de livres. Nous n'avons pas besoin de livres sur la documentation de notre logiciel empilé haut et alors pas réellement avoir de logiciel que nous pouvons montrer pour elle. Nous avons juste ce très, vraiment bon design, donc il y a un équilibre là, et c'est là que nous commençons à parler de la méthodologie agile plus tard, mais juste une sorte de vouloir jeter ça dedans. Il y en a si vous allez juste à ce cours, vous savez, conférence par conférence. Ne pensez pas que vous devez le faire à 100% parce que beaucoup de fois n'est pas réaliste, et les gens en quelque sorte le jeter dehors. Cependant, comprendre peut-être les principes de base vous aide quand vous arrivez à cette autre partie, parce que maintenant vous comprenez ce que vous abandonnez pour obtenir cette vitesse, etc. Mais ce sont les étapes du design. Comme je l'ai dit, ça change tout le temps. Votre entreprise pourrait avoir un autre ensemble, mais c'est un bon ensemble pour en quelque sorte le prendre à partir de ce niveau d'idée et vraiment commencer à le décomposer en obtenir une bonne idée presque au niveau du code sur la façon dont votre programme devrait fonctionner. 20. Modularité 4-3: Nous parlons donc d'une bonne conception de logiciel. Ce que nous essayons d'obtenir, c'est cette idée de modularité. Donc la modularité est cette idée de prendre notre programme et de le diviser en différents modules. Rappelez-vous, nous avons parlé des sous-systèmes et des modules. C' est la même terminologie ici, mais avec la modularité, nous avons un ensemble d'objectifs en tête. On ne veut pas juste briser ça. Nous voulons le briser d'une manière intelligente. Et avec cela, ce que nous essayons de faire est d'atteindre les objectifs principaux. Donc, avec notre module, disons que nous avons un morceau de code ici avec notre module. Nous voulons que ce module soit indépendant, et c'est la partie d'accouplement. Indépendant signifie que toutes ses actions et données sur Lee effet lui-même. Nous n'avons pas de module ici le contrôlant à un module ici le contrôlant. Et puis peut-être qu'il contrôle un module ici. Et celui-ci contrôle ça, etcetera, etcetera. Ensuite, vous entrez dans ce très gros problème d'une erreur ici, pourrait réellement se représenter ici. Ou en fait, il pourrait aller se représenter jusqu'ici. Vous avez un problème quand ils ne sont pas indépendants, donc c'est l'un de nos objectifs. Et c'est ce qu'est le couplage. On aura toute une conférence à ce sujet. Et puis la cohésion est à quel point un module existe-t-il singulier ? Comme ce que je veux dire par singulier est, est-ce que ses objectifs sont singulièrement conçus ? Si les objectifs air singulièrement conçu affaiblissent, prenez ce module, nous pouvons le retirer du programme et le mettre dans un autre programme. Si nous avions une page Web et que cette page Web avait ce contrôleur dedans, et que ce contrôleur contrôlait tout, je veux dire, ça parle à un tas d'autres contrôleurs. Donc peut-être qu'il a en fait un assez bon couplage dans le sens où même s'il contrôle tout cela, rien ne le contrôle, et ses données sont en quelque sorte encapsulées en elle-même. Mais le problème ici est que c'est très, très bien adapté à ce problème, ce qui signifie que si jamais nous essayons de sortir ça ou de mettre un nouveau morceau, ça ne marcherait pas. Ceci est très, très spécifique à ce problème exact, donc il ne répond pas à un objectif de conception singulier. Il fait tout. n'y a pas d'objectif. Je veux dire, tu pourrais, tu sais, dire site de contrôle. Cela pourrait être votre objectif, mais c'est un objectif très large, et ce n'est pas quelque chose de très singulier, et c'est ce que nous parlons de cohésion. Donc, avec la modularité, nous essayons d'obtenir ces deux aspects. Nous essayons de les obtenir tous les deux comme optimal est possible. Nous essayons de le rendre très indépendant et ensuite très singulièrement conçu. Ainsi, les objectifs de la modularité, les objectifs de la modularité sont les suivants. Il y a un autre ensemble. Moi, si tu cherches les objectifs, ça va être différent. Pour toutes les personnes qui en parlent, cependant, c'est un ensemble que j'aime sortir. Le premier but de la modularité est l'abstraction. C' est essentiellement de prendre notre module et de le mettre dans une boîte noire pour éliminer la complexité. Nous parlons de cela dans l'information, se cachant un peu, mais l'abstraction est très importante car elle nous permet de concevoir des idées de plus haut niveau. Si nous devions, par exemple, travailler sur le langage machine, ce qui signifiequenous contrôlons en fait que les zéros tout le temps. On ne voudrait rien faire. Ce serait trop complexe, mais quelqu'un l'a abstraite à un langage d'assemblage, donc c'est assembly, et alors quelqu'un a effectivement abrégé ce langage d'assemblage jusqu'à probablement un autre , puis jusqu'à notre comme Java afin que nous puissions utiliser Java avec son. Il est relativement facile d'utiliser les fonctions, puis de le décompresser dans n'importe quel langage qui va au langage d'assemblage qui va au langage machine. langage machine contrôle réellement le ram etcetera. Donc, quand nous parlons d'abstraction, nous parlons de la capacité de prendre ces idées complexes et de les amener lentement sur supprimer cette ville complexe afin que nous puissions construire de plus en plus de programmes avancés, décomposer la capacité dans la capacité de composer. Ça veut dire qu'on peut démonter le truc et le remettre ensemble. Cela aide au débogage. Cela aide à ajouter de nouvelles fonctionnalités. Cela aide essentiellement, tout ce qui a à voir avec la maintenance, c'est que nous voulons être en mesure d'ouvrir ce programme, de prendre une partie de tout démonter et de le remettre ensemble. Et ça aide vraiment quand vous avez ces deux. Et la ligne est parce que vous pouvez enlever ce contrôleur et qu'il ne casse pas tout le site Web. Vous pouvez en fait, vous savez, chaud une nouvelle manette et peut-être une autre qui fait des choses légèrement différemment plus efficacement. Il devient très facile à maintenir après ce module, comprendre la capacité ou simplement comprendre la capacité si vous voulez les garder tous. C' est un mot ici. Ce que comprendre la capacité signifie, c'est que je pourrais sauter dans un module et comprendre instantanément de quoi il parle avec celui-ci. C' est très, très en profondeur. Ce pourrait être, disons, 35 000 lignes de code. Pensez-vous que vous seriez capable de comprendre ce que ce module fait tout de suite ? Probablement pas. Mais disons que nous avons ce petit module ici, et tout ce qu'il fait est de faire peut-être des mises à jour sur la base de données. Donc tout ce qu'il fait est de mettre à jour la base de données, et peut-être que c'est son nom. Et il y a, vous savez, fonctions comme mise à jour, entier, mise à jour, à jour, chaîne le mot de passe de mise à jour de l'utilisateur. On s'y penche. Nous disons qu'il y a un problème avec les mises à jour dans notre base de données. Nous pouvons facilement aller bien, vérifions la mise à jour, base de données, le dossier ou le fichier, et c'est très facile. Très rapide à comprendre. Le suivant est la continuité. La continuité est un peu une idée où vous avez, disons que vous utilisez Constance est d'une très bonne façon de le dire. Nous avons X égal à trois. Donc, au lieu d'avoir dans chacun de ces aspects, une variable de X est égale à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois X égal à trois. Imaginez si maintenant, dans notre situation, X équivaut à quatre. Eh bien, maintenant nous devons passer par chacune de ces choses et les changer en quatre, ce qui va être le cas ou nous allons en manquer un et ensuite nous allons avoir des erreurs bizarres commencent apparaître. Ça allait devenir difficile à entretenir. Mais si nous avions un dossier constant, nous avions un fichier constant ici avec ce qui dit, X est égal à quatre. Eh bien, alors tout ça pourrait juste faire référence à ce fichier de Constance et ça devient un peu désordonné maintenant. Mais j'essaie, tu sais, tu sais, ramener à la maison ce point juste là. Est-ce que si nous avions ce dossier constant là-haut, alors tout ce que nous avons à faire est de le changer en un seul endroit, et il sera continu tout au long de notre projet. Donc, avoir cela à l'esprit est très important aussi et enfin protéger la capacité la façon dont nous pouvons protéger les données est si nous gardons très, très sorte de déverrouillage dans des fichiers spécifiques, nous n'avons pas, vous savez, 85 fichiers différents entrent en contact dans la base de données. Nous avons un seul contrôleur ou un seul ensemble de contrôleurs qui le font. Cela nous aide non seulement avec des conséquences involontaires, mais aussi contre les hacks et autres choses. Parce que si nous avons 86 points d'entrée différents dans notre base de données, tout ce qui doit arriver est que l'un d'eux doit échouer avant que quelqu'un ne saute. Il est donc très important de contrôler cela. la Etlamodularité vous aide à maintenir et à obtenir une sécurité plus forte. C' est donc l'introduction de la modularité. Dans les prochaines conférences, nous allons parler de la dissimulation d'informations et de l'encapsulation de données, qui sont d'autres locataires clés de la modularité. 21. 4 à 4 caches d'informations et Encapsulation de données: Donc, la prochaine sorte d'étapes de la modularité ou les prochains locataires de la modularité, nos informations cachant l'encapsulation des données de fin. Et ces deux sont vraiment juste des moyens d'abstraction et de l'importance de l'abstraction. Donc, le 1er 1 est l'information qui se cache, et c'est, vous cachez la complexité dans une boîte noire. Mais quand nous parlons d'abstraction et que nous parlons de la façon dont vous pouvez l'extraire du langage machine et l'amener jusqu'au haut pour que nous puissions faire des choses de plus haut niveau, eh bien, eh bien, c'est ce que fait la dissimulation d'informations. Il cache la complexité dans une boîte noire. Chacun d'entre eux est une boîte noire qui cache la complexité. Lorsque vous écrivez des choses pour le langage d'assemblage, vous utilisez des choses que ce langage ici, le langage machine a exposé quelques yeux AP. Certains commandent certaines fonctions. Vous utilisez ce code pour construire ceci, puis avec le langage d'assemblage, vous créez un nouvel ensemble de fonctions, contrôles et de commandes, que cette prochaine langue apportera. Une fois ses prochaines langues terminées, vous créez un autre ensemble de codes et de commandes, puis Java. En plus de cela va commencer à appeler ces codes et demandes qui appelleront ces codes et commandes qui parce que ceux qui feront des choses comme déplacer la mémoire autour. Donc avec ça ici, ce que nous essayons de faire avec les informations cachées, c'est de cacher cette complexité dans une boîte noire. Nous pourrions le faire avec des choses appelées comme des fonctions macro classes, méthode l'air, tous juste les termes techniques que nous utilisons chaque fois que nous programmons. Mais disons que nous avons une boîte noire appropriée juste ici et une autre boîte noire juste ici et ce qu'ils sont est un dispositif de cryptage, cryptage puis un dispositif de décryptage. Donc si, par exemple, on a mis 35 ici et que ça sort avec je ne sais pas, pourquoi 62 ? Donc c'est la sortie. Et puis maintenant nous prenons t pourquoi 62 le mettre dans le décryptage er. Et il en sort comme 35. Doit-on comprendre comment il s'agit de chiffrer et de déchiffrer pour pouvoir utiliser ces deux boîtes pour pouvoir utiliser ces deux programmes ? Non, pas du tout. Tout ce qu'on a besoin de savoir c'est, qu'est-ce que c'est ? Entrée. Et était-ce en sortie ? Et nous sommes complètement et totalement d'accord avec l'utilisation pour toutes ses fins. Les internes ne sont pas nécessaires pour être connus, et c'est très important. C' est quelque chose qui est très utile. Chaque fois que nous concevons des programmes, surtout avec disons, nous concevons un programme pour un, disons , un constructeur automobile. Nous avons tout ce code qui peut être auto-génère du code en arrière-plan dirait que c'est , ah, ah, auto conduite quelque chose de voiture. Mais nous ne sommes pas des voitures. On ne comprend pas à quoi ressemblent les voitures. On ne comprend pas comment tout est censé être programmé. Donc, ce que nous faisons c'est nous programmons un ensemble de boutons, un ensemble de tables et d'interrupteurs, un peu comme un petit panneau de contrôle ici et avec cette programmation. Nous faisons ensuite abstraction de tout le minutieux de la programmation réelle. Les quatre boucles, le while boucle les fonctions des classes de bibliothèques de Macron. Nous résumons tout cela, et nous permettons à un technicien d'appuyer simplement sur des boutons et d'entrer des valeurs, puis notre code fera le reste. On a donc donné le contrôle à l'ingénieur automobile Mawr. Nous leur avons donné le pouvoir d'utiliser notre code avec leurs trucs, et c'est l'importance de se cacher des informations, c'est qu'il permet de construire des choses de plus en plus complexes . Il vous permet de créer une fondation, puis de construire sur cette base et de continuer à créer des choses plus fortes et plus fortes au fil du temps. Et c'est ainsi que les programmes deviennent de plus en plus complexes au fil du temps, c'est que nous nous améliorons lentement à cette abstraction et que nous allons de plus en plus sauf l'information. Je pense que c'est l'idée de cacher la complexité dans une boîte noire. Le suivant est quelque chose appelé Data Encapsulation, et cela vous remarquerez qu'ils sont en fait assez proches. Celui-ci est une sorte d'information qui se cache, alors que celui-ci pourrait être connu sous le nom de cache de données, donc ils ont une relation. Mais celui-ci est tout au sujet de cacher les détails de l'implémentation à l'utilisateur et Onley fournissant un ensemble d'outils pour manipuler les données. Ce que nous entendons par ceci, c'est, disons que nous avons une classe ici et qu'une de ses variables est, disons, um, um, des données de transaction. Donc peut-être le montant d'argent, alors on a mis la transaction ici. Maintenant, pourquoi devrions-nous mettre une fonction get et la fonction set ? Pourquoi ne pas avoir ce qui est dans cette classe s'appelle les services bancaires. Pourquoi ne pas autoriser ce programme ici à appeler quelque chose comme une transaction de points bancaires équivaut à 50. Pourquoi ne pas autoriser ça ? Pourquoi ? Pourquoi ne pas autoriser cela à faire un appel direct à la transaction ? Eh bien, ce genre de casse l'idée d'encapsulation de données. Si nous faisons cela, alors soudainement nos données peuvent être manipulées de quelque manière que ce soit, forme ou forme, et nous n'avons aucun contrôle sur elles. Nous ne pouvons pas empêcher l'utilisateur de mettre des données invalides et de gâcher non seulement nos algorithmes, mais peut-être l'intégralité de notre base de données. Donc, avec l'encapsulation de données, ce que nous faisons est de créer les getters et les centres. Donc, si nous voulons savoir ce qu'est la transaction. Il appelle le git, donc il appellerait le git, puis la fonction get retournerait la valeur Cette fonction get pourrait être très importante , car peut-être qu'elle a une couche d'authentification dessus. Peut-être qu'il a une couche d'authentification avec cela. Cela signifie qu'un mot de passe devrait être entré avant que cette classe ne donne des données. Et c'est très important dans le monde bancaire. Vous ne voulez pas seulement que les gens puissent programmer des choses et extraire directement du serveur. Tout ce qu'ils veulent. Alors obtiens son aide à protéger ça. Et puis un centre est beaucoup de fois mawr important. Le centre nous empêchera de faire certaines choses. Donc, nous allons appeler une fonction à définir. Peut-être que nous disons que nous voulons régler la transaction à 50. Eh bien, le centre va avoir une simple déclaration si vous savez moins de zéro retour. Donc, si moins de zéro retour, je ne sais pas, erreur quelque chose de vraiment, vraiment simple. Et c'est un air de retour moins que simple, inférieur à zéro. Et pourquoi est-ce important ? Eh bien, nous faisons des transactions et nous voyons continuer à facturer les gens négatifs. 50 $. Eh bien, on va commencer à obtenir de l'argent à notre façon, et c'est un problème. Nous ne voulons jamais qu'une transaction soit inférieure à n'importe quel argent, car au lieu de facturer notre compte, nous prenons simplement de l'argent aux gens. Ainsi, un simple centre ajouterait une autre couche de sécurité et protégerait également l'intégrité de nos services bancaires en ce sens qu'il peut y avoir plus de chèques ici. Et nous ne pouvions pas déposer, disons 1 000 000 000 000$ par accident, soit il pourrait y avoir une partie supérieure qui pourrait l'escalader comme un manager ou quelque chose comme ça . Mais dans l'ensemble, l'idée de l'encapsulation des données est en quelque sorte de protéger les données, ce qui en fait. Nous exposons donc uniquement ce genre d'outils pour manipuler les données au lieu de simplement permettre l'accès aux données et de les modifier de toute façon, forme ou forme que nous voulons. Et donc, avec une bonne conception logicielle, nous pensons également à cette encapsulation de données. On pense à pourquoi. Pourquoi on laisse les gens saisir ces données ? Pourquoi ne pas faire un getter dans une fonction centrale ? Pourquoi ne pas le protéger d'une manière ou d'une autre, ou créer une classe entière qui s'occupe de ce genre de choses pour protéger l'intégrité de notre base de données ? 22. Introduction à 4 à 5 coutures: Dans la dernière conférence, nous avons introduit cette idée de couplage. Et donc avec le couplage, ce dont nous parlons, c'est la force des connexions entre les modules et les sous-systèmes. Maintenant, avec le terme « force », nous avons une sorte d'idée d'une connotation positive. Cependant, avec le couplage, nous ne voulons pas de cette force. Nous voulons une réelle faiblesse entre les modèles. Nous ne voulons pas que les modèles, modules et sous-systèmes soient étroitement couplés. Et donc quand on parle de couplage, on veut dire qu'ils dépendent l'un de l'autre. Donc, par exemple, si nous avions tout un tas, un petit ensemble de modules et de sous-systèmes ici, disons qu'il y a juste ce genre de lien et de chaîne, comme ça et, vous savez, votre programme est complexe ou non complexe, nous pourrions avoir une section étroitement couplée, et quand une section est étroitement couplée, cela signifie que si nous faisons un changement ici, par exemple, nous vont alors devoir aller à ce fichier et faire un changement. Allez dans ce fichier et ils pourraient changer. Accédez à ce fichier et apportez une modification. Allez dans ce fichier et ils pourraient changer etcetera etcetera jusqu'à ce que nous ayons fondamentalement tout changé afin que cela fasse fonctionner le changement ici réellement. Cela a tout un tas d'inconvénients. Le 1er 1, c'est juste le temps. Il nous faudra du temps pour comprendre ce qui est exactement couplé avec cette Habituellement faire essai et l'air. On dirige le programme, dit-il. J' espère qu'il y a eu une pause ici. Donc, nous allons le changer là-bas, relancer le programme. Il y a eu une pause ici. Allez le changer là si vous avez une meilleure documentation, peut-être un peu plus rapide, Mais beaucoup de fois, vous pouvez. Je dois aller à cette pause et réparer. La prochaine partie est, est qu'il va juste prendre fondamentalement la capacité de maintenir le programme et de le réduire . Parce que maintenant, quand nous apporterons ce changement, peut-être que nous avons fait tous ces changements. Mais on a oublié cette affaire ici. Et cette affaire Onley fonctionne, vous savez, peut-être une fois par mois, peut-être que c'est un code bizarre qui est comme, ah, truc de serveur qui fonctionne une fois par mois, et on oublie de le changer ici . Donc nous passons tous les tests et tout ça, et ça a l'air super et puis dans un mois, nous avons ce bug géant qui arrive. On ne sait pas d'où ça vient. Eh bien, c'est parce que vous êtes étroitement liés ensemble. C' est à cause de ce changement que cela arrive. Et c'est encore pire quand on arrive à quelque chose comme ça où il est en fait là où ce problème est parce que maintenant on doit penser, qu' est-ce qu'on change ? Peut-être que nous ne regardons que ces deux dossiers ou que nous n'avons pas vraiment changé ici. Oh, c'est en fait ce changement majeur ici qui a causé cet air en cascade si étroitement couplé . Les programmes sont généralement mauvais. Vous n'allez pas vraiment arriver au point de ne pas avoir de couplage, mais vous voulez essayer de le rendre aussi lâche que possible. Donc, avec un couplage serré, nous avons l'idée de variables partagées et d'informations de contrôle. Donc tout cela ici est l'idée d'informations de contrôle. Donc, nous avons ces méthodes et les classes qui parlent toutes directement aux autres modules contrôlent directement les autres modules, donc les changements dans l'un nécessitera des changements dans tous les autres. Et puis si nous avons l'idée de variables partagées, c'est là que nous avons ce genre de liste géante de variables, et chaque programme en bas utilise ces variables. Donc, si on fait un changement ici, il y a beaucoup de fois qu'on va vraiment devoir faire des changements dans tous les fichiers de fond aussi. Et cette structure peut en fait être bénéfique dans certaines situations qui peuvent aider à réduire d'autres domaines de problèmes. Mais cela pourrait également créer un problème. C' est pourquoi toute cette idée du design nous avons ce genre d'équilibre que nous devons dessiner. Il n'y a rien qui soit parfait. Donc on a dû trouver ce qui est le plus parfait pour l'obtenir. Ce qui est le plus optimisé que nous puissions l'obtenir, et c'est la direction que nous devons prendre. Et puis la décentralisation de l'Etat crée doit être un voir leur crée couplage lâche. Ce que nous entendons par là, c'est la décentralisation de l'État, c'est là que nous avons ces petits segments ici. Peut-être que ces deux-là sont couplés ensemble, mais nous avons une autre section où ces deux-là sont couplés ensemble et, vous savez , etcetera, etc. Mais dans l'ensemble, nous n'avons pas le programme dans son ensemble, vous savez, tous les sens. Nous avons presque ces petits États qui font tous leurs propres affaires avec peu communications entre les deux. Et cela nous aide à nouveau avec tout le débogage et des trucs comme ça plus tard. Donc dans la prochaine conférence, ce dont nous parlons en fait, c'est que nous allons parler des trois niveaux de couplage qui vont être le couplage serré, le couplage moyen et ensuite le couplage lâche. Et dans il y a de petites catégories dans chacun d'eux couple de contenu dans le contrôle externe commun , la structure de données, message de données et puis aucun. Et encore une fois, comme je le disais tout à l'heure, aucun n'est assez peu pratique. y a probablement presque aucune application qui n'utilisera aucun couplage. Mais nous voulons être en mesure de passer par toutes ces étapes afin que nous puissions examiner un programme et comprendre comment, couplé à ce programme, il est serré et, vous savez, est-ce bon ou mauvais ? 23. Coupler 4-6 étroits: Parlons de notre première sorte de classifications de couplage, et ce sera le pire scénario de couplage. Et c'est l'idée d'un couplage serré. Donc, un couplage serré nous avons un tas de modules qui sont tricotés ensemble. Un tricoté étroitement avec ce moyen est que si nous faisons un changement dans un module, nous allons devoir faire un changement dans tout un tas d'autres modules pour le faire afin que le programme ne casse pas cela pourrait être un peu divisé en ce genre de sous- , ces collants air communs, de types d'accouplement serré et qui va être dans le contenu, commun puis externe. Donc on va faire un par un des devoirs et tu verras qu'ils sont une erreur très facile à faire. Mais ils peuvent causer de très gros problèmes. Le 1er 1 est avec couplage de contenu. Donc, ce que c'est que c'est quand un module modifie plus se trouve sur le fonctionnement interne d' un autre module. Dans ce scénario, nous avons le module A, puis le module B et le module A saisissent directement du module B. Il saisit le débit de données du module B et l'utilise pour ses propres choses. Disons, par exemple, que le module soit les données en question est une sorte de distance. Donc c'est une sorte de distance. Disons qu'en B, c'est représenté par des mètres. Une chose typique qui pourrait arriver. Peut-être qu'on l'a pris à partir d'un A p I. Peut-être que c'est la façon dont on l'a programmé. Mais les données ici en B sont des mètres. Eh bien, le module A veut convertir ça en Miles, donc ça va prendre des mètres et essayer de le convertir en miles. Donc tout ce qu'il fait. Est-il attrape directement de l'être. Il envoie un algorithme de conversion do no et fait ensuite ce qu'il doit faire avec. Maintenant, pouvez-vous voir le problème ici ? Le problème, c'est que si quelqu'un entre et veut modifier être, disons que nous avons aussi un autre ici qui fait la même chose. L' accaparement des données battues peut être la conversion d'une autre manière, mais c'est en supposant que B va rester le même. Et c'est le problème. Voici l'hypothèse que B ne changera jamais. Comme je l'ai dit, un autre programmeur vient ici pour être. Comme je l'ai dit, Il se rend compte que nous sommes en train de convertir 2 miles partout. Peut-être que la norme de nos jours est de représenter toutes les distances en kilomètres. Peut-être que c'est pour représenter toutes les distances en centimètres, même dans le système métrique. Vous commencez à avoir cette capacité à changer les choses. Nous pourrions également représenter toutes les distances en miles. Disons cependant, que nous décidons juste de changer cela de mètres, deux kilomètres, quelque chose qui pourrait être un changement très simple. Donc, en B, il va et fait le changement, Peut-être ce petit algorithme de conversion rapide et maintenant battre les données. Les données ici représentent les mètres. Le problème est que vous ne pouvez pas voir qui s'appuie essentiellement sur ces données d'ici. Il pourrait y avoir 1000 personnes appelant ou 1000 modules appelant ce petit extrait de données. Maintenant, chaque fois que nous changeons cela, tout d'un coup tous ces air vont casser un A et un C et tout ce qui est connecté se cassera parce que chacun d'entre eux supposait que c'était des mètres et ensuite se convertissait en fonction ce hypothèse. Donc à cause de ça, A va avoir un problème. Ça va se briser, va représenter cet insecte bizarre où se trouvent les choses. Peut-être, vous savez, une