Stratégies de conception
Stratégie descendante
La stratégie descendante utilise l'approche modulaire pour développer la conception d'un système. Il est appelé ainsi parce qu'il part du module du haut ou du plus haut niveau et se déplace vers les modules du plus bas niveau.
Dans cette technique, le module de plus haut niveau ou le module principal de développement du logiciel est identifié. Le module principal est divisé en plusieurs sous-modules ou segments plus petits et plus simples en fonction de la tâche effectuée par chaque module. Ensuite, chaque sous-module est subdivisé en plusieurs sous-modules de niveau inférieur suivant. Ce processus de division de chaque module en plusieurs sous-modules se poursuit jusqu'à ce que les modules de niveau le plus bas, qui ne peuvent pas être subdivisés davantage, ne soient pas identifiés.
Stratégie ascendante
La stratégie ascendante suit l'approche modulaire pour développer la conception du système. Il est appelé ainsi parce qu'il part du bas ou des modules de niveau le plus basique et se déplace vers les modules de niveau le plus élevé.
Dans cette technique,
Les modules du niveau le plus élémentaire ou le plus bas sont identifiés.
Ces modules sont ensuite regroupés en fonction de la fonction remplie par chaque module pour former les modules de niveau supérieur suivants.
Ensuite, ces modules sont ensuite combinés pour former les prochains modules de niveau supérieur.
Ce processus de regroupement de plusieurs modules plus simples pour former des modules de niveau supérieur se poursuit jusqu'à ce que le module principal du processus de développement de système soit atteint.
Conception structurée
La conception structurée est une méthodologie basée sur le flux de données qui aide à identifier l'entrée et la sortie du système en développement. L'objectif principal de la conception structurée est de minimiser la complexité et d'augmenter la modularité d'un programme. La conception structurée aide également à décrire les aspects fonctionnels du système.
Dans la conception structurée, les spécifications du système servent de base pour représenter graphiquement le flux de données et la séquence des processus impliqués dans le développement d'un logiciel à l'aide de DFD. Après avoir développé les DFD pour le système logiciel, l'étape suivante consiste à développer l'organigramme.
La modularisation
La conception structurée divise le programme en petits modules indépendants. Ceux-ci sont organisés de manière descendante avec les détails indiqués en bas.
Ainsi, la conception structurée utilise une approche appelée Modularisation ou décomposition pour minimiser la complexité et gérer le problème en le subdivisant en segments plus petits.
Advantages
- Les interfaces critiques sont testées en premier.
- Il fournit de l'abstraction.
- Il permet à plusieurs programmeurs de travailler simultanément.
- Il permet la réutilisation du code.
- Il fournit le contrôle et améliore le moral.
- Cela facilite l'identification de la structure.
Graphiques structurés
Les graphiques structurés sont un outil recommandé pour concevoir des systèmes modulaires de haut en bas qui définissent les différents modules de développement de système et la relation entre chaque module. Il montre le module système et leur relation entre eux.
Il se compose d'un diagramme constitué de cases rectangulaires qui représentent les modules, des flèches de connexion ou des lignes.
Control Module - C'est un module de niveau supérieur qui dirige les modules de niveau inférieur, appelés subordinate modules.
Library Module - C'est un module réutilisable et peut être appelé à partir de plusieurs points du graphique.
Nous avons deux approches différentes pour concevoir un graphique structuré -
Transform-Centered Structured Charts - Ils sont utilisés lorsque toutes les transactions suivent le même chemin.
Transaction–Centered Structured Charts - Ils sont utilisés lorsque toutes les transactions ne suivent pas le même chemin.
Objectifs de l'utilisation des organigrammes de structure
Pour encourager une conception descendante.
Soutenir le concept de modules et identifier les modules appropriés.
Pour montrer la taille et la complexité du système.
Identifier le nombre de fonctions et de modules facilement identifiables au sein de chaque fonction.
Décrire si chaque fonction identifiable est une entité gérable ou doit être décomposée en composants plus petits.
Facteurs affectant la complexité du système
Pour développer une bonne qualité de logiciel système, il est nécessaire de développer une bonne conception. Par conséquent, l'objectif principal lors du développement de la conception du système est la qualité de la conception du logiciel. Une conception logicielle de bonne qualité est celle qui minimise la complexité et les dépenses de développement de logiciels.
Les deux concepts importants liés au développement du système qui aident à déterminer la complexité d'un système sont coupling et cohesion.
Couplage
Le couplage est la mesure de l'indépendance des composants. Il définit le degré de dépendance de chaque module de développement système par rapport à l'autre. En pratique, cela signifie que plus le couplage entre les modules d'un système est fort, plus il est difficile de mettre en œuvre et de maintenir le système.
Chaque module doit avoir une interface simple et propre avec d'autres modules, et que le nombre minimum d'éléments de données doit être partagé entre les modules.
Couplage élevé
Ces types de systèmes ont des interconnexions avec des unités de programme dépendant les unes des autres. Les modifications apportées à un sous-système ont un impact important sur l'autre sous-système.
Couplage bas
Ces types de systèmes sont constitués de composants indépendants ou presque indépendants. Un changement dans un sous-système n'affecte aucun autre sous-système.
Mesures d'accouplement
Content Coupling - Lorsqu'un composant en modifie un autre, le composant modifié dépend entièrement de la modification d'un.
Common Coupling - Lorsque la quantité de couplage est quelque peu réduite en organisant la conception du système de sorte que les données soient accessibles à partir d'un magasin de données commun.
Control Coupling - Lorsqu'un composant passe des paramètres pour contrôler l'activité d'un autre composant.
Stamp Coupling - Lorsque des structures de données sont utilisées pour transmettre des informations d'un composant à un autre.
Data Coupling - Lorsque seules les données sont transmises, les composants sont connectés par ce couplage.
Cohésion
La cohésion est la mesure de la proximité de la relation entre ses composants. Il définit le degré de dépendance des composants d'un module les uns par rapport aux autres. En pratique, cela signifie que le concepteur de systèmes doit s'assurer que -
Ils ne divisent pas les processus essentiels en modules fragmentés.
Ils ne rassemblent pas des processus indépendants représentés comme des processus sur le DFD dans des modules dénués de sens.
Les meilleurs modules sont ceux qui sont fonctionnellement cohérents. Les pires modules sont ceux qui sont cohésifs par coïncidence.
Le pire degré de cohésion
La cohésion coïncidente se trouve dans un composant dont les parties ne sont pas liées à une autre.
Logical Cohesion - C'est là que plusieurs fonctions ou éléments de données liés logiquement sont placés dans le même composant.
Temporal Cohesion - C'est quand un composant qui est utilisé pour initialiser un système ou définir des variables exécute plusieurs fonctions en séquence, mais les fonctions sont liées par le temps impliqué.
Procedurally Cohesion - C'est lorsque les fonctions sont regroupées dans un composant juste pour assurer cet ordre.
Sequential Cohesion - C'est lorsque la sortie d'une partie d'un composant est l'entrée de la partie suivante de celui-ci.