Top Down v enfoque de abajo hacia arriba diseño

Question

Duplicar:. Design & Coding - top to bottom or bottom to top?

creo que he encontrado en mi experiencia reciente que diseño de software diferente que la mayoría de mis compañeros. Tiendo a tomar el enfoque ascendente ascendente después de reunir suficientes requisitos para obtener una idea de alto nivel de los componentes en el software.

Entonces, en el caso de diseñar una interfaz que admitiría múltiples clases concretas ... Echaré un vistazo a lo que es común a cada candidato concreto específico, preguntando cómo haría el trabajo para cada concreto (mientras pensando en ser robusto para el futuro concreto). Luego tomo ese conjunto de elementos comunes y hago una interfaz, que creo que es un enfoque de "abajo hacia arriba".

En el caso de un enfoque de arriba hacia abajo, creo que el diseñador miraría el lado del cliente de la interfaz y cómo un cliente interactuaría con la interfaz y luego trataría de implementar las clases concretas.

Así que puedo ver las ventajas y desventajas de arriba hacia abajo/abajo hacia arriba. Solo me gustaría saber cuál es más eficiente y proporciona un mejor resultado basado en tus experiencias previas.

Nota: No estoy hablando de metodología de desarrollo (ágil, cascada, etc.), estoy hablando de enfoques de diseño.

Answer 1

Creo que con buenos diseñadores de software (y en mi opinión, todos los desarrolladores de software también deberían ser diseñadores de software en algún nivel), la magia está en poder hacer de arriba hacia abajo y de abajo hacia arriba simultáneamente.

Lo que mis mentores me "enseñaron" a hacer es comenzar muy brevemente de arriba hacia abajo para comprender las entidades involucradas, luego pasar de abajo hacia arriba para descubrir los elementos básicos que quiero crear y luego hacer una copia de seguridad y vea cómo puedo bajar un nivel, sabiendo lo que sé sobre los resultados de mis resultados, y así sucesivamente hasta que "se encuentren en el medio".

Espero que ayude.

Answer 2

Depende del problema.

Si sabes cuál es el problema [permite a los clientes ver los estados de cuenta en línea], y cómo resolverlo, utiliza un enfoque ascendente. Analice cada paso, agrúpelos por área y desarrolle una solución. Plan de proyecto basado

Si tiene una vaga idea del problema [permitir que los agentes de campo se comuniquen a través de una wiki distribuida fuera de línea/en línea], un enfoque descendente funcionaría mejor. Mire el problema general y qué pasos se pueden usar para resolverlo. Prueba y error. Ágil.

Answer 3

No hay una manera perfecta de diseñar el software. Ningún enfoque garantizará el diseño perfecto.

Tiene que ver el problema de diferentes maneras cuando diseña una solución para él, y cuando tiene un diseño, debe verlo de diferentes maneras también. No se te ocurrirá el mismo diseño si te acercas desde la parte superior como lo harías si te acercaras desde abajo. Así que haga ambas cosas, y escoja y elija las ventajas que ambos métodos le brindan.

Comprenda el problema en su nivel más alto y avance hasta la solución, identificando las partes donde los detalles pueden terminar cambiando el diseño (detalles que debe abordar desde el nivel más bajo y volver a trabajar).Siga iterando a través de todos los componentes del problema hasta que tenga un diseño que sea lo suficientemente bueno para trabajar.

Code Complete capítulo 5 realmente puede ayudar a resolver los detalles de lo que estoy diciendo aquí. Te sugiero que eches un vistazo.

Answer 4

No estoy seguro de haber entendido su pregunta correctamente, pero si la tengo, está preguntando por los pros/contras con la construcción de una aplicación y luego es una interfaz versus construir una interfaz y luego construir la aplicación para hacerlo realidad hacer cosas.

Yo diría que gran parte de la respuesta depende de para quien está desarrollando/diseñando. ¿Su objetivo es proporcionar una aplicación interesante y (tal vez) útil para los usuarios? Comience con la interfaz de usuario. ¿O está intentando construir una interfaz para un sistema de negocios (que ya podría existir), o para completar tareas que ya se están ejecutando de otras maneras (menos eficientes)? Comience con las tareas.

Answer 5

De abajo hacia arriba es lo que muchos de nosotros codificamos. No por elección sino a través de intellisense. Petzold escribió un artículo sobre este here.

En la práctica, creo que encontrará la mayoría de los arquitectos diseñados de esta manera. Personalmente, no creo que haya visto a nadie hacer el diseño al revés (de concreto a abstracto).

Claro, los requisitos son concretos, pero uno generalmente usa los requisitos para dirigir las abstracciones y definir el propósito y la intención del software.