Использование диаграмм помогает вам разрабатывать программное обеспечение и эффективно доносить свои идеи.

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

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

Как говорится, картинка стоит тысячи слов. Диаграммы — это простые и легкие в использовании инструменты коммуникации. Несомненно, маркеры и доски являются основными канцелярскими принадлежностями во многих современных технологических компаниях. Инженеры-программисты рисуют схемы, объясняя свои идеи.

Почему чертежи важны?

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

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

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

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

Диаграммы для разработки программного обеспечения

В течение долгого времени диаграммы унифицированного языка моделирования (UML) были стандартами в индустрии разработки программного обеспечения для проектирования и документации программного обеспечения. Стандарты всеобъемлющие, существует около 14 типов диаграмм, описывающих поведение и структуру системы.

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

  • Диаграмма варианта использования
  • Диаграмма деятельности
  • Диаграмма компонентов
  • Диаграмма последовательности

Инструменты рисования

Существует множество программ для рисования, от самых простых, таких как MS Paint, до сложных инструментов, таких как MS Visio. Долгое время я использовал MS Visio для создания диаграмм для проектов по разработке программного обеспечения, затем обнаружил, что онлайн-инструмент для рисования diagrams.netон же draw.io не только доступен бесплатно, но также предлагает мощные функции, аналогичные MS Visio. Кроме того, он предоставляет некоторые другие полезные функции, такие как интеграция с онлайн-репозиториями и вики-страницами, которые недоступны в MS Visio.

Инструмент для рисования diagrams.net может работать в браузерах без установки, это означает, что я могу открывать свои рисунки и работать с ними где угодно, если эти рисунки можно получить из онлайн-репозитория. Оффлайн версия также доступна для установки на ПК.

Для создания UML-диаграмм diagrams.net предоставляет в наше распоряжение набор предопределенных фигур. Вот список фигур в категории Общие:

Для фигур, предназначенных для диаграммы UML, добавьте фигуры категории UML с помощью кнопки «+ Больше фигур».

Прием № 1 — выберите правильный уровень детализации

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

Давайте посмотрим на приведенную ниже диаграмму в течение 10 секунд и посмотрим, какие идеи вы можете из нее извлечь.

О чем эта диаграмма?

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

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

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

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

Прием № 2 — Визуализация системных требований

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

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

Техника № 3 — Визуализируйте логический поток системы

Далее давайте углубимся в подробные системные требования, которые определяют системную логику, такую ​​как входы, выходы, логическое разветвление и действия.

Неуклюже заключать всю логику в многословные предложения. Например, это описание процесса входа в систему:

Логика аутентификации сначала проверяет CAPTCHA. Если он действителен, найдите запись пользователя, в противном случае верните ошибку входа. Далее проверьте наличие записи пользователя. Если запись пользователя существует, подтвердите пароль, в противном случае запустите проверку пароля с фиктивным хешем и верните ошибку. Наконец, создайте сеанс входа в систему, если пароль правильный. Если нет, вернуть ошибку.

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

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

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

Давайте посмотрим на другой пример. Это диаграмма деятельности предложения продукта, состоящая из 2 частей — проверки запроса и формирования предложения. Есть 3 правила проверки — обязательные поля, наличие клиента и товара. Затем предложение формируется на основе таких факторов, как возраст клиента, почтовый индекс запроса, а также ставка скидки кампании.

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

Метод № 4 — Компоненты дизайн-системы

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

Для приведенного выше логического потока производственных предложений у нас есть Quotation Service в качестве промежуточного звена, которое координирует другие службы для создания предложений. Существуют специальные службы для таких организаций, как Служба продуктов, Служба поддержки клиентов и Служба CRMS. Затем ставка скидки для продукта, клиента и кампании передается в Quotation Engine для выполнения основной логики формирования предложения. Сгенерированная котировка также сохраняется в базе данных Mongo.

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

Затем диаграммы компонентов могут быть применены к дизайну службы. На диаграмме компонентов ниже показаны компоненты внутри Quotation Service, Quotation Endpoint получает запросы REST API и полагается на Quotation Business Service для выполнения бизнес-логики. Сервис использует API-клиенты для взаимодействия с внешними сервисами. Точно так же интеграция с базой данных Mongo выполняется через компонент репозитория.

Поскольку на диаграмме уже представлены все компоненты и зависимости, разработчики могут сразу начать программировать компоненты и связывать их вместе в соответствии с диаграммой, если служба построена с использованием Java Spring Framework.

Прием № 5 — Определение подробного системного потока

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

На приведенной ниже схеме компонентов указаны порядковые номера. Например, шаг 2 и шаг 3 соответственно далеки друг от друга. Это означает, что вам нужно просмотреть всю диаграмму, чтобы найти следующий шаг, когда вы прослеживаете каждый шаг на диаграмме. Чем больше шагов, тем сложнее отследить весь ход программы. Это недостаток использования порядковых номеров на диаграммах компонентов.

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

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

Более того, разветвление системного потока может привести к различному поведению системы. Диаграммы последовательности предоставляют способ учесть альтернативный поток, добавив раздел, аналогичный приведенному ниже примеру. Это показывает, что Quotation Service должен возвращать статус ответа 400 Bad Request, если запись о клиенте не найдена.

Последние мысли

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

Диаграммы могут не помочь, если вы не принимаете во внимание свою целевую аудиторию. Главное напоминание — поставить себя на место аудитории. Создавайте диаграммы с нужным уровнем детализации, подходящим для вашей аудитории.

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