Дизайн сверху вниз – подход к безупречному проектированию и внедрению программного обеспечения


сверху вниз "class =" fr-fin fr-dib "src =" https://dzone.com/storage/temp/12696104-top-down.png "title =" сверху вниз

Проверьте этот вид сверху вниз.

Вам также может понравиться:
Принципы разработки программного обеспечения

Дизайн сверху вниз

В разработке программного обеспечения вы бы прочитали во многих статьях и книгах, что дизайн должен быть главным приоритетом. Хороший дизайн решит многие проблемы. Дизайн внесет большую ясность для разработчиков. Это даст детальные детали о точных требованиях. В этой статье я собираюсь обсудить Сверху вниз Дизайнерский подход. Я объясню шаг за шагом на примере электронного обучения.

Проблема должна рассматриваться на нескольких уровнях. У каждого из них есть свои преимущества. Различные уровни в дизайне или разработке программного обеспечения следующие

  • Большая картинка или тема.
  • Модули / System.
  • Подмодули / Подсистемы.
  • Особенности.
  • Подфункции.
  • Бизнес правила.

Большая фотография

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

Я из области электронного обучения. Мне было бы легко относиться к процессу проектирования. В приложении электронного обучения создание отчетов о прогрессе для студентов может быть темой требования.

Справедливо, однако, какие отчеты о прогрессе требуются для этих студентов. Это приведет вас к следующему уровню.

Тип отчетов будет инициировать вы определяете модули.

Модули

Определение типа отчетов на более широком уровне составляет определение модулей. Модули определены как

  • Инструктор Отчеты.
  • Студенческие отчеты.

Как только вы определите более широкие модули, мы должны определить подмодули для этих идентифицированных модулей.

Подмодуль

Давайте рассмотрим модули и определим возможные подмодули.

  • Отчеты инструктора – Модуль

    • Отчет о курсе.
    • Назначение мудрого отчета.
    • Студенческий мудрый отчет.
    • Отчет о результатах.
  • Студенческие отчеты – Модуль

    • Конечно, мудрый отчет.
    • Назначение мудрого отчета.

особенности

Как только мы определили подмодули, детализируйте это со списком особенностей. Вот несколько примеров:

  • Отчет о курсе
    • Преподаватель должен иметь возможность создать отчет для одного или нескольких курсов.
    • Он должен иметь возможность выбирать диапазон дат.
    • Он должен давать результаты для всех студентов курса вместе со списком экзаменов в качестве опции полного просмотра.
  • Отчет о назначении
    • Пользователи должны выбрать одно или несколько заданий.
    • Пользователи должны иметь возможность получать отчет по диапазону дат.
    • Отчет о назначении для одного конкретного курса или нескольких курсов.

Функции также можно разбить на подфункции.

Варианты использования и бизнес-правила

Для отчетов такого типа нам необходимо идентифицировать бизнес-объекты. Здесь, в этом случае, субъектами хозяйствования будут:

  • Курс.
  • Студенты.
  • Инструктор.
  • Экзамены.
  • Гол.
  • Grade.

Эти лица помогут API дизайна, Ваш API должен быть разработан на основе сущностей домена.

Они также помогут нам идентифицировать системы и подсистемы. Например, в приведенном выше списке пользователя, конечно, экзамены, оценки все разные системы самостоятельно. Модули отчетов должны будут взаимодействовать со всеми этими системами, чтобы получить данные, необходимые для отчета.

После того, как мы определили все шаги, описанные выше, пришло время углубиться в эту функцию и под-функцию более подробно.

Мы должны составить список бизнес-правил для каждой функции или подфункции. В нем должен быть указан точный список бизнес-правил, который должен быть достигнут как часть функции.

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

Нефункциональные требования

После того, как мы определили и сделали глубокое погружение функциональных требований с помощью нисходящего дизайна. Важно учитывать нефункциональные требования, такие как безопасность и производительность, а также на каждом этапе. Это обеспечит работу разработанной системы при более высокой нагрузке или требуемой нагрузке и ее безопасность.

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

Общее количество пользователей может вырасти до 3000-5000. Это приведет к нефункциональному требованию. Это поможет вам определить меры, которые необходимо предпринять, чтобы поддержать такие большие ожидания. Он должен обрабатываться на этапе проектирования, чтобы реализация выполнялась правильно и работала, как ожидалось.

Требование личной информации пользователя должно быть получено из другой системы. Здесь снова, нефункциональные требования безопасности и производительности находятся в сфере.

Для разработки системы для поддержки всех этих случаев требуется достаточно времени. Мы должны определить эти нефункциональные требования как часть вашего дизайна сверху вниз. Это также поможет вам составить правильную оценку.

Преимущества нисходящего дизайна

  • Это помогает идентифицировать системы и подсистемы.
  • Внесите больше ясности в связь между двумя системами или подсистемами.
  • Полный список функций и подфункций вместе со всеми бизнес-правилами.
  • Нет места для ошибок в реализации пользовательские требования, Высокое качество может быть достигнуто.
  • Убедитесь, что получите правильную оценку.
  • Легко кодировать, так как мы четко определили ожидания на всех уровнях.
  • Нефункциональный поможет убедиться, что он работает, защищен.

Дальнейшее чтение

Принципы разработки программного обеспечения DRY и KISS

20 лучших вопросов по системному проектированию для программистов на Java

Визуальное восприятие и его влияние в UX Design