9
votes

Design de haut en bas ou de bas-haut?

Il y a essentiellement ces deux approches pour concevoir un système. Quels sont les avantages et les inconvénients? Quand devrais-je utiliser lequel? Devrais-je combiner ces approches? Comment?


4 commentaires

C'est une courte question, mais je soupçonne que la réponse serait assez longue! ...


Je préfère la conception de gauche à droite.


@Mitch Bheat peut être, répondre également partiellement ou rediriger vers certains livres / papiers / articles / blogs suffira :)


@ Matti Virkkunen Je ne pense pas que ce soit simplement une question de choix que vous le suggérez, développez par ex. Système bancaire Je ne voudrais pas essayer d'aller de près ...


3 Réponses :


25
votes

Grandement parlant, de haut en bas provient d'une décomposition de l'espace de problème en sous-problèmes, tandis que Bottom-up provient de l'organisation de pièces de l'espace de la solution en plus grand morceaux.

Pour pouvoir utiliser efficacement le haut, vous avez besoin d'une compréhension très solide du problème, c'est-à-dire avoir des exigences solides en main. Pour être efficace pour être efficace, vous devez résoudre un problème «standard» dont les pièces sont bien connues, mais où l'assemblage exact peut avoir besoin d'expérimentation avant de le faire correctement.

Vous devriez lire des parnas 'brilliant papier Un processus de conception rationnel Et comment simuler pour bien plus encore sur cette question. La réponse est: Utilisez les deux, selon le cas. Lorsque vous avez terminé, faites tout ressembler (dans votre spécification, la documentation de conception et la documentation utilisateur) comme si vous aviez tout fait de haut en bas.


2 commentaires

Merci beaucoup pour une bonne réponse et un lien avec ce papier


+1: Car «Quand vous avez terminé, faites-vous tout ressembler comme si vous aviez tout fait de haut en bas»



2
votes

Vous devez également jeter un coup d'œil à la «découpage du gâteau» de la communauté agile. Ce principe vous oblige à vous concentrer sur l'ajout de valeur commerciale pour l'utilisateur à chaque itération de votre application. Vous essayez de concevoir et de mettre en œuvre une tranche verticale de votre application et de la livrer, puis concentrez-vous sur la section suivante, etc.

Voici un lien qui explique le principe plus en détail http: // blog.eergizedwork.com/2005/05/slicing-cake.html


1 commentaires

Merci, je sais sur les itérations, je suppose que le point difficile est de couper le gâteau afin que Addind une autre tranche ne soit pas aussi difficile que d'ajouter plusieurs précédents.



3
votes

Je pense que votre question mérite des réponses longues et articulées. Je suggère de lire un ancien article de Martin Fowler (CFR. "La conception est-elle morte?") Qui parle des relations sur les conceptions et les techniques agiles initiales ( http://martinfowler.com/articles/designdead.html )

Mon expérience est d'avoir toujours une architecture d'impression bleue des modules, des interactions entre les composants du système. Avoir ce plan (qui dans certains projets peut être de haut niveau), je commence à concevoir / développer des modules / composants. Certaines d'entre elles peuvent être développées également ascendantes.


1 commentaires

Bonne référence toujours appréciée :)