Вершина Вниз против Восходящего подхода дизайна [дубликат]

Это зависит от проблемы.

Если вы знаете, в чем проблема [позволить клиентам просматривать банковские выписки в Интернете] и как ее решить, тогда используйте восходящий подход. Проанализируйте каждый шаг, сгруппируйте их по областям и разработайте решение. На основе плана проекта.

Если у вас есть смутное представление о проблеме [разрешить полевым агентам общаться через распределенную автономную / онлайн-вики], то подход сверху вниз будет работать лучше. Посмотрите на общую проблему и какие шаги можно использовать для ее решения. Методом проб и ошибок. Agile.

Не существует идеального способа разработки программного обеспечения. Ни один подход не гарантирует идеального дизайна.

Вы должны рассматривать проблему по-разному, когда разрабатываете для нее решение, и когда у вас есть дизайн, вы также должны смотреть на него по-разному. Вы не получите такой же дизайн, если будете подходить к нему сверху, как если бы вы подходили к нему снизу. Так что делайте и то, и другое, и выбирайте преимущества, которые дают вам оба метода.

Поймите проблему на самом высоком уровне и пройдите через решение, выявляя части, детали которых могут в конечном итоге привести к изменению конструкции (детали, к которым вам следует обратиться с самого нижнего уровня и продвигайтесь обратно вверх). Продолжайте повторять все компоненты проблемы, пока не получите дизайн, с которым можно работать.

Code Complete глава 5 действительно может помочь в детализации того, что я здесь говорю. Предлагаю вам взглянуть.

Я не уверен, что правильно понял ваш вопрос, но если да, вы спрашиваете плюсы / минусы создания приложения, а затем его интерфейса, а не создания интерфейса, а затем построения приложение, которое заставит его действительно делать что-то.

Я бы сказал, что большая часть ответа зависит от , для кого вы разрабатываете / проектируете. Ваша цель - предоставить пользователям крутое и (возможно) полезное приложение? Начнем с пользовательского интерфейса. Или вы пытаетесь создать интерфейс для бизнес-системы (которая может уже существовать) или выполнить задачи, которые уже выполняются другими (менее эффективными) способами? Начнем с задач.

Многие из нас кодируют "снизу вверх". Не по выбору, а с помощью intellisense. Петцольд написал об этом статью здесь .

На практике, я думаю, вы обнаружите, что большинство архитекторов проектируют именно так. Я лично не думаю, что когда-либо видел, чтобы кто-то делал дизайн наоборот (от конкретного к абстрактному).

Конечно, требования конкретны, но обычно используются требования для управления абстракциями и определения цели и намерения программного обеспечения.