Quelle est la Décomposition Fonctionnelle?
décomposition fonctionnelle, à quoi sert-elle et quels en sont les avantages et les inconvénients? Où sont-là quelques exemples de la façon dont il est utilisé?
5 réponses
la décomposition fonctionnelle est le processus qui consiste à prendre un processus complexe et à le décomposer en ses parties plus petites et plus simples.
par exemple, pensez à utiliser un distributeur automatique de billets. Vous pourrait décomposer le processus en:
Marche jusqu'à l'ATM
Insérez votre carte bancaire
entrez votre NIP
bien...vous obtenez le point.
vous pouvez penser à la programmation de la même façon. Pensez au logiciel qui exécute ce guichet automatique:
Code pour lire la carte
vérification des NIP
Traitement Des Transferts
dont Chacun peut être ventilée. Une fois que vous avez atteint les pièces les plus décomposées d'un sous-système, vous pouvez penser à la façon de commencer à coder ces pièces. Vous composez alors ces petites parties dans le plus grand ensemble. Regardez cette Wikipédia Article:
l'avantage de La décomposition fonctionnelle est qu'une fois que vous commencer à coder, vous travaillez sur les éléments simples que vous pouvez éventuellement travailler avec pour votre application. Par conséquent, le développement et la mise à l'essai de ces composants devient beaucoup plus facile (sans oublier que vous êtes mieux en mesure d'élaborer votre code et votre projet en fonction de vos besoins).
L'inconvénient évident est l'investissement en temps. Pour effectuer fonctionnel la décomposition sur un système complexe prend plus qu'une quantité insignifiante de temps avant que le codage commence.
personnellement, je pense que ce temps en vaut la peine.
c'est la même chose que les structures de WorkBreakDown (WBS), la mindMapping et le développement du haut vers le bas - essentiellement briser un grand problème en plus petits, plus compréhensibles sous-parties.
Pros
- permet une approche proactive de la programmation (resiting l'envie de code)
- aide à identifier les aspects complexes et/ou à risque d'un projet (dans L'exemple ATM, la sécurité est probablement la composante la plus complexe)
- aide à identifier tous les composants d'un projet - la cause #1 de l'échec du projet / code (via Capers Jones) est pièces manquantes - des choses qui n'ont pas pensé jusqu'à tard dans le projet (gee, Je ne savais pas que je devais vérifier le solde de la personne avant de distribuer le$)
- permet de découpler les composants pour une meilleure programmation, partage de code et distribution du travail
contre-il n'y a pas de vrai contre à faire une décomposition, cependant il y a quelques erreurs communes
- ne cassant pas en bas assez loin ou en se décomposant jusqu'à loin - chaque personne doit déterminer le niveau heureux de détail nécessaire pour leur fournir la perspicacité du composant sans faire trop (ne pas se décomposer en lignes de programmation de code...)
- pas d'aide de pré-existants modèles/modules de code en considération (retouches)
- ne pas examiner avec les clients pour s'assurer que la portée est correcte
- ne pas utiliser la panne lors du codage (comme concevoir une maison que d'oublier au sujet du plan et juste commencer à clouer quelques planches ensemble)
Voici un exemple: votre compilateur C.
d'Abord il y a le préprocesseur: il gère #include et #define et toutes les macros. Vous lui donnez un nom de fichier et quelques options et il retourne une chaîne très longue. Nous allons appeler cette fonction preprocess(filename).
Puis il y a l'analyseur lexical. Il prend une ficelle et la brise en jetons. Appelle lex(string). L'analyseur prend des jetons et les transforme en arbre, appelez-le parse(tokens). Puis il y a une fonction pour convertir un arbre à un DAG de blocs, appelez-le dag(tree). Appelez l'émetteur de code emit(dag), qui prend un DAG de blocs et crache monteur.
Le compilateur est alors:
emit(dag(parse(lex(preprocess(filename)))));
nous avons décomposé un grand, difficile à comprendre fonction (le compile fonction) en un tas de fonctions plus petites, plus faciles à comprendre. Vous n'avez pas à le faire qu'une canalisation, vous pouvez écrire votre programme:
process_data(parse_input(), parse_config())
C'est plus typique; les compilateurs sont assez profondes programmes, la plupart des programmes sont larges en comparaison.
la décomposition fonctionnelle est un moyen de décomposer le problème complexe en problèmes plus simples basés sur les tâches qui doivent être effectuées plutôt que les relations de données. Ce terme est habituellement associé à l'ancienne conception axée sur la procédure.
la décomposition fonctionnelle est utile avant de créer des documents sur les exigences fonctionnelles. Si vous avez besoin d'un logiciel pour quelque chose, la décomposition fonctionnelle répond à la question "Quelles sont les fonctions que ce logiciel doit fournir". La décomposition est nécessaire pour définir les fonctions à grain fin. "J'ai besoin d'un logiciel pour l'efficacité énergétique de mesure" est trop général. C'est pourquoi nous divisons cela en petits morceaux jusqu'à ce que nous comprenions clairement toutes les fonctions que les systèmes doivent fournir. Ce peut ensuite servir de liste de vérification de l'exhaustivité d'un système.
un document sur les exigences fonctionnelles (ED) est essentiellement une représentation textuelle de la décomposition fonctionnelle. Le codage direct à partir du FD peut être correct pour les langages procéduraux, mais il n'est pas suffisant pour les solutions orientées objet, car il n'identifie pas les objets. Ni l'un ni l'autre n'est bon pour la planification de l'utilisabilité et les tests.
mon opinion est que vous devriez prendre un certain temps pour créer un FD, mais ne pas l'utiliser trop la plupart du temps. Consulter toute personne qui connaît le processus que vous suivez avec votre système afin de trouver toutes les fonctions nécessaires.
j'ai beaucoup d'expérience dans la conception, le développement et la vente de logiciels, et j'utilise la décomposition fonctionnelle comme première étape du développement. Je l'utilise comme base pour le contrat, pour que le client sache ce qu'il obtiendra et je sais ce que je dois fournir.