Разработка программного обеспечения (ПО) - сложный процесс, требующий глубокого понимания предметной области. Без качественного анализа потребностей бизнеса и формализации требований невозможно создать продукт, который принесет реальную пользу заказчикам.
Поэтому одним из важнейших этапов является анализ предметной области. Цель этого этапа - выявить цели и задачи пользователей, определить сущности, с которыми они работают, и функции, которые должна выполнять система.
Задачи анализа предметной области
Анализ предметной области - это важный этап разработки программного обеспечения, позволяющий глубоко изучить область, в которой будет функционировать система. Основные задачи анализа предметной области:
- Понять терминологию и бизнес-процессы заказчика
- Выявить основных участников и их роли
- Определить цели и задачи системы
- Изучить структуру данных и информационные потоки
Глубокий анализ предметной области позволяет разработчикам лучше понять потребности бизнеса и построить систему, которая будет эффективно решать задачи заказчика. Это залог успеха проекта по разработке ПО.
| Этап | Задачи |
| Сбор информации | Интервью, наблюдение, изучение документов |
| Анализ информации | Построение моделей, выявление требований |
| Документирование | Составление отчетов, спецификаций, диаграмм |
Модели и диаграммы в анализе предметной области
При анализе предметной области широко используются различные модели, позволяющие структурировать и визуализировать полученную информацию. В зависимости от целей могут применяться следующие графические модели:
- Диаграммы потоков данных (DFD) - для описания процессов и информационных потоков
- Диаграммы сущностей и связей (ER-диаграммы) - для моделирования структуры данных
- Диаграммы деятельности (UML) - последовательности действий
- Диаграммы вариантов использования (use case) - функциональные требования
Кроме графических моделей применяются и текстовые спецификации требований, описания бизнес-процессов, глоссарии терминов и прочие артефакты.
Одной из наиболее популярных является методология IDEF (ICAM Definition, Integrated Computer-Aided Manufacturing). В основе IDEF лежат диаграммы потоков данных и функционального моделирования.
Функциональные блоки в IDEF0 обозначают функции системы, а стрелки - информационные или материальные потоки. Каждый блок имеет входы, выходы, управляющие параметры и механизмы выполнения.
| Модель | Цель |
| DFD | Описание процессов и потоков данных |
| IDEF0 | Функциональное моделирование |
| ER-диаграммы | Моделирование структуры данных |
| Диаграммы вариантов использования | Описание функциональных требований |
Диаграммы потоков данных для описания процессов
Диаграммы потоков данных широко используются при анализе предметной области для визуального представления процессов, происходящих в системе. Они содержат 4 основных компонента: процессы, хранилища данных, внешние сущности и потоки данных между ними.
Процессы на диаграммах изображаются в виде прямоугольников со скругленными углами и представляют различные преобразования данных. Хранилища данных показывают места хранения и накопления информации. Внешние сущности - это объекты вне рассматриваемой системы, с которыми она взаимодействует. Потоки данных демонстрируют движение информации между другими элементами диаграммы.
Обычно процессы могут детализироваться, если в них происходит достаточно много действий. Для этого строится отдельная диаграмма потоков данных только для данного процесса. Таким образом получается иерархия процессов разного уровня детализации. На самом верхнем уровне, как правило, находится один укрупненный процесс, отображающий всю систему целиком.
Использование диаграмм потоков данных позволяет наглядно представить, какие процессы происходят в системе, какие данные при этом используются, хранятся и передаются между элементами. Это облегчает понимание работы сложных систем.
Диаграммы сущностей и связей для структуры данных
Диаграммы сущностей и связей применяются в анализе предметной области для визуализации структуры данных, которые циркулируют в системе. В отличие от диаграмм потоков данных, на которых акцент делается на процессах, диаграммы ER ориентированы именно на данные.
Основными элементами таких диаграмм являются сущности и связи между ними. Сущность - это некий объект или понятие предметной области, которое можно выделить и идентифицировать. Например, Клиент, Заказ, Товар. Связи определяют отношения между сущностями.
Как сущности, так и связи могут иметь атрибуты - характеристики или параметры. Для сущности Клиент это могут быть ФИО, адрес, номер телефона. Для связи Оформил между Клиентом и Заказом важным атрибутом является дата оформления.
Сущности на диаграммах изображают в виде прямоугольников, а связи - в виде линий между прямоугольниками. Атрибуты записывают внутри прямоугольников или рядом с линиями связей.
Использование ER-диаграмм позволяет структурировать данные, выявить наиболее важные сущности и связи между ними, определить критические атрибуты. Это облегчает дальнейшее проектирование баз данных и программных систем.
Диаграммы вариантов использования в объектно-ориентированном анализе
Объектно-ориентированный анализ предметной области подразумевает использование диаграмм вариантов использования (use case diagrams) вместо диаграмм потоков данных. Эти диаграммы также позволяют описать функциональность системы, однако делают это иначе.
Основными элементами диаграмм вариантов использования являются сами варианты использования (use cases) и действующие лица (actors). Вариант использования представляет собой некоторую функцию или задачу системы. Действующее лицо - это пользователь или внешняя по отношению к системе сущность, которая взаимодействует с ней.
На диаграммах варианты использования изображаются в виде эллипсов или овалов, а действующие лица - в виде «человечков». Связи между ними показывают, какие функции доступны конкретным пользователям или внешним системам.
В отличие от диаграмм потоков данных, здесь отсутствует детальное описание внутренних процессов и потоков информации. Вместо этого каждый вариант использования может дополнительно детализироваться с помощью других UML-диаграмм: диаграмм деятельностей, диаграмм последовательностей, диаграмм состояний и т.д.
Использование диаграмм вариантов использования позволяет выделить ключевые задачи и функции, которые система должна выполнять, определить различные категории пользователей и предоставляемый им функционал. Это упрощает дальнейшее проектирование объектно-ориентированных систем.
Схема Захмана для моделирования организации
Схема Захмана (Zachman framework) - это методология для комплексного моделирования различных аспектов деятельности организаций любого масштаба. Она широко используется в анализе предметной области при проектировании корпоративных информационных систем.
В основе этой схемы лежат два измерения:
- 6 фундаментальных вопросов, на которые нужно ответить при моделировании: Что? Как? Где? Кто? Когда? Почему?
- Уровни абстракции: контекстный (общий план), концептуальный (бизнес-модель), логический (системная модель).
Пересечение этих измерений образует матрицу из 6×3=18 ячеек. Для каждой ячейки строятся модели соответствующего типа на соответствующем уровне детализации.
Например, на концептуальном уровне для вопроса «Как?» можно построить модель бизнес-процессов или диаграмму потоков данных. А для вопроса «Кто?» на том же уровне подойдет организационная структура.
Использование схемы Захмана при анализе предметной области позволяет комплексно исследовать и запланировать все аспекты функционирования организации.
Анализ предметной области как основа для формулировки требований
Одной из важнейших задач анализа предметной области является сбор информации, необходимой для корректной постановки требований к разрабатываемой программной системе. Без глубокого понимания предметной области и потребностей заказчиков сформулировать полные и непротиворечивые требования крайне сложно.
В процессе анализа предметной области определяется:
- Конечные пользователи системы, их потребности и ожидания
- Цели и задачи, которые должна решать система
- Функциональные возможности, которыми должна обладать система
- Бизнес-процессы, которые должна поддерживать система
- Сущности, с которыми предстоит работать системе
- Внешние системы и условия, с которыми нужно взаимодействовать
- Ограничения, которые необходимо учитывать при разработке
На основе этих данных формулируются функциональные и нефункциональные требования:
- Функциональные требования описывают необходимые функции и возможности системы
- Нефункциональные требования накладывают ограничения на реализацию функций с точки зрения производительности, надежности, безопасности и др.
Таким образом, именно анализ предметной области позволяет максимально полно и достоверно выявить потребности заказчика и перевести их на формальный язык требований к ПО.
Подробная документация результатов анализа
Документация результатов анализа предметной области крайне важна для успешной разработки программного обеспечения. В ней должны быть зафиксированы все ключевые элементы предметной области: процессы, данные, внешние сущности, связи между ними.
Документация обычно включает в себя набор диаграмм и сопровождающие их текстовые описания:
- Диаграммы потоков данных, описывающие процессы в предметной области
- Диаграммы сущностей и связей для структуры данных
- Диаграммы вариантов использования в объектно-ориентированном анализе
Каждая диаграмма должна сопровождаться подробным текстовым описанием, раскрывающим все детали. Например, для диаграммы потоков данных нужно описать:
- Назначение и состав всех потоков данных
- Функции всех процессов - какие действия они выполняют и какие правила используют
- Структуру и назначение всех хранилищ данных
- Роли всех внешних сущностей и характер их взаимодействия с системой
Аналогично для диаграммы сущностей и связей необходимо подробно описать смысл и состав всех атрибутов сущностей, а также всех типов связей между сущностями с указанием кардинальности.
При наличии полного комплекта детализированных диаграмм и сопроводительных текстовых описаний разработчики могут глубоко понять суть предметной области и корректно спроектировать программную систему.
Передача знаний о предметной области команде разработчиков
После того как системные аналитики или бизнес-аналитики выполнили глубокий анализ предметной области, наступает очень важный этап - передача полученных знаний команде разработчиков программного обеспечения. Успех всего проекта в значительной степени зависит от того, насколько полно и точно разработчики поймут суть предметной области.
Для передачи знаний традиционно используется комплект артефактов анализа предметной области - набор моделей в графической и текстовой форме. Ключевыми элементами являются:
- Диаграммы потоков данных, детально описывающие все процессы
- Диаграммы сущностей и связей для структуры данных
- Диаграммы вариантов использования
- Словарь терминов предметной области
Каждый из этих элементов должен сопровождаться исчерпывающими текстовыми описаниями. Также важно обеспечить возможность задавать уточняющие вопросы аналитикам.
Однако передача знаний на основе артефактов часто бывает недостаточно эффективной. Разработчики могут неправильно интерпретировать модели или упустить важные детали, которые кажутся аналитикам слишком очевидными.
Для более полного понимания рекомендуется использовать дополнительные методы:
- Проведение специальных сессий вопросов-ответов с участием аналитиков
- Вовлечение разработчиков в процесс анализа на ранних стадиях
- Использование инструментов визуализации и моделирования процессов
Благодаря комплексному подходу, включающему артефакты, личное общение и инструменты моделирования, команда разработчиков может построить полное и точное понимание предметной области. А это является фундаментом для разработки программного обеспечения, которое будет полностью соответствовать потребностям бизнеса.
