Проектирование ИС с использованием UML

От бизнес-модели к проектированию системы

Ранее мы детально описали характеристики информационных объектов. Для чего это нужно при проектировании информационной системы (ИС)? Такие описания позволяют:
• понять, как будет выглядеть интерфейс взаимодействия с пользователем;
• определить структуру базы данных, её элементы и связи;
• сформировать альбом выходных документов.

Когда информация об объектах получена, можно перейти к моделированию их взаимодействия. Например, для задачи регистрации товара в картотеке кладовщик получает накладную. Если карточка товара существует, запись о приходе вносится в неё; если нет — создаётся новая карточка. Эта схема фактически задаёт информационные потоки будущей системы. Она понятна разработчику, но плохо подходит для обсуждения с заказчиком — не стоит рассчитывать, что заказчик сможет по ней что-то уточнить.

Диаграммы состояний и скрытые атрибуты

Диаграммы состояний бизнес-объектов применяются, когда нужно вскрыть скрытые атрибуты, не проявляющиеся в документах обследования. Рассмотрим объект «Приёмный акт». Он создаётся в двух экземплярах: один передаётся снабженцу, другой — в бухгалтерию. Возможные состояния:
• Создан и находится у кладовщика.
• Один экземпляр передан снабженцу, второй — бухгалтеру.
• Передан обоим адресатам.

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

Правила перехода к системной модели

Следующий шаг — преобразование описания бизнес-деятельности в модель поддерживающей её системы. Применяются простые правила:
• Бизнес-прецеденты отображаются в подсистемы создаваемой ИС (законченная группа действий → подсистема).
• Внешние исполнители становятся исполнителями в системной модели (все, кто взаимодействуют с системой — равноправны).
• Внутренние исполнители преобразуются либо в исполнителей, либо в системные прецеденты. Последнее означает, что деятельность специалиста полностью автоматизируется, и необходимость в нём отпадает.
• Процессы внутренних исполнителей становятся системными прецедентами (крупные блоки действий ИС).

Применяя эти правила к модели склада, получаем: поставщик инициирует прецедент «Получение товара» в рамках подсистемы складского учёта. Оформление приёмного акта отображается в системную операцию «Формирование приёмного акта» (электронный бланк заполняется исполнителем). Регистрация в картотеке заменяется процедурой «Ведение картотеки» (создание и обновление карточек). Передача в бухгалтерию — подсистема или процедура внутрисетевого обмена. Так формируется структура системы и перечень программ, на этом проектирование завершается; далее следует реализация — разработка или настройка выбранного продукта.

Логика проектирования и место UML

Прослеживается последовательная цепочка:
1. Выявляется бизнес-прецедент.
2. Его реализация описывается диаграммами.
3. Для каждого действия определяются объекты и исполнители.
4. Описываются сами объекты (характеристики, связи).
5. Моделируются информационные обмены.
6. При необходимости строятся диаграммы состояний для поиска скрытых атрибутов.
7. На основе этой информации выделяются подсистемы и функции.

Эта логика зафиксирована в методике Rational Unified Process (RUP) — документе, регламентирующем грамотное использование UML (Unified Modeling Language) при проектировании ИС.

Основные принципы RUP

RUP — это одновременно база знаний, методическое пособие и конфигурируемый процесс. Ключевые постулаты:
• Итеративная разработка. Система создаётся серией итераций, причём итерации возможны внутри каждого этапа (в отличие от классической спиральной модели, где этапы выполняются последовательно). Это повышает качество: например, требования разрабатываются, обсуждаются, корректируются и утверждаются за несколько итераций.
• Разработка на базе компонентов. Используются готовые модули, встраиваемые в новые системы.
• Визуальное моделирование с применением UML, что сокращает объём текстовых документов.
• Конфигурируемый процесс. Нет двух одинаковых проектов; RUP адаптируется под масштаб (малые, средние, большие проекты) и специфику.
• Архитектурный акцент. Первоочередная задача — определение архитектуры ИС. Когда выделены подсистемы и их задачи, разработку можно распараллелить между группами, так как модули стыкованы идеологически. Без архитектуры разработка вынужденно последовательна, что ведёт к потере времени.
• Управление требованиями. Требования неизбежно меняются. Неуправляемый процесс ведёт к хаосу. RUP предлагает регламентированную методику управления изменениями.
• Управление прецедентами. Понятие прецедента проходит через весь жизненный цикл: от выявления деятельности до тестовых сценариев. Вся документация привязана к конкретным прецедентам.

Архитектура RUP и поддерживающие работы

Процесс в RUP представлен в двух измерениях: временны́е этапы и виды работ. Этапы: начало, уточнение требований, конструирование, внедрение. Основная нагрузка по моделированию бизнес-процессов, определению требований и разработке архитектуры приходится на середину жизненного цикла.

Работы делятся на основные и поддерживающие. Поддерживающие:
• Управление конфигурацией и изменениями. Изменения требований влияют на конфигурацию продукта. Специализированные средства RUP позволяют отслеживать связи между требованиями и при изменении одного указывают на «подозрительные» связанные требования. Также сюда входит ведение версий продукта и документации.
• Управление проектом. Специфическая задача достижения уникальных результатов в условиях ограничений по времени и ресурсам.
• Управление средой. Поддерживаются раздельные среды для разработки, отладки и эксплуатации, чтобы не нарушать работу действующей версии.

Бизнес-моделирование в RUP

Первый основной вид работ — бизнес-моделирование. Решаемые задачи и применяемые средства:
1. Определение бизнес-процессов, подлежащих автоматизации → диаграммы бизнес-прецедентов. Становится понятно, на какие подсистемы разбить будущую систему.
2. Описание исполнения бизнес-процессов → диаграммы деятельности. Они понятны заказчику и позволяют выявить, какие функции должны поддерживаться системой.
3. Описание бизнес-сущностей (документы, информационные и материальные потоки) → диаграммы классов. Каждый объект связывается с блоком информации, который детально описывается.
4. Моделирование состояний бизнес-сущностей → диаграммы состояний для выявления скрытых атрибутов.
5. Определение ролей и видов деятельности — чтобы понять, кто будет работать с системой и какие функции она реализует.
6. Описание структуры предприятия (вложенными пакетами) и бизнес-правил. Формальные правила можно фиксировать в характеристиках классов, а правила порядка действий — диаграммами деятельности.

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

Разработка требований и системное моделирование

Следующая крупная задача — определение требований. На основе построенных моделей:
• Диаграммы прецедентов → формулируются функции системы.
• Диаграммы классов → проектируется интерфейс (экранные формы).
• Диаграммы деятельности → описываются сценарии работы пользователя с системой.

Для удовлетворения требований создаются:
• Модель анализа — детализированные диаграммы бизнес-уровня с полным описанием атрибутов, типов значений и функций классов.
• Модель проекта — диаграммы, описывающие функции ИС (здесь появляются диаграммы последовательности, показывающие внутренние потоки данных и исполнение действий).

Таким образом, модели последовательно трансформируются: от бизнес-прецедентов → к системным прецедентам → к модели классов → к реализации и тестированию.

Соглашения RUP об артефактах и качестве работ

RUP вводит единообразное описание участников и результатов. Исполнитель (роль) обозначается специальным значком. С ним связаны артефакты — любые результаты проекта: документы, программные модули, настройки базы данных, модели и т.д. Каждый исполнитель выполняет определённые виды деятельности.

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

Процедура бизнес-моделирования

В ней участвуют бизнес-аналитик и системный аналитик (проектировщик). Последовательность шагов:
1. Фиксация общего словаря — один из самых важных начальных этапов. Все понятия расшифровываются и согласовываются, чтобы избежать разночтений между заказчиком, разработчиком и сотрудниками организации.
2. Поиск деловых субъектов и прецедентов — определение внешних действующих лиц и связанных с ними бизнес-прецедентов.
3. Детализация деловых прецедентов — описание исполнения с помощью диаграмм деятельности.
4. Определение внутренних исполнителей и бизнес-сущностей — выясняется, кто реализует действия и с какими объектами они связаны. Это приводит к иерархиям классов.
5. Экспертиза моделей — представитель заказчика проверяет и подтверждает правильность созданных моделей.

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

Пример: проектирование системы для поликлиники

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

Обслуживание пациентов — центральный бизнес-прецедент, с которым связано множество внешних действующих лиц: пациент, врач, технический персонал, страховые компании, внешние медицинские учреждения. Прецедент оказывается слишком сложным, его необходимо декомпозировать: выделяются прецеденты «Оказание медицинской помощи», «Финансовая деятельность», «Рецензирование», «Связь с другими учреждениями» и др. После декомпозиции с каждым прецедентом связано меньше лиц.

Далее для каждого прецедента строится диаграмма деятельности. Например, при оказании медицинской помощи: врач запрашивает карточку, анализирует, вносит дополнения и возвращает в регистратуру. Эта схема одинакова и для штатного врача, и для внешнего специалиста, что позволяет ввести суперкласс «Врач», объединяющий обоих. Аналогично, все, кто обращается за информацией о пациенте (страховая компания, техперсонал, врач), становятся подклассами суперкласса «Отправитель запроса». Такое обобщение упрощает модель.

Из диаграммы деятельности становится ясно, кто с кем взаимодействует и какой информацией обменивается. Строится модель бизнес-объектов: внешний исполнитель (Отправитель запроса) обращается к внутреннему персоналу, который подбирает и передаёт клинические записи. Это позволяет выделить объекты, поддерживаемые ИС. На данном этапе классы описываются в общем виде (модель анализа), без детализации атрибутов.

Для класса «Клиническая запись» строится диаграмма состояний. На первый взгляд она содержит логическую ошибку: переход из состояния «Находится у специалиста» сразу в «Архив» невозможен — запись сначала должна вернуться в хранилище. Исправленная схема: Хранилище → Выдана для обработки → Возвращена в хранилище → Отправлена в архив. В каждом состоянии допустимы строго определённые действия (в хранилище — только выдать; у специалиста — вносить изменения).

На этом бизнес-модель готова, и следующим шагом станет разработка требований к системе.

Краткие итоги

Проектирование информационной системы начинается не с программного кода, а с глубокого осмысления той реальной деятельности, которую предстоит автоматизировать. Ключевая идея представленного материала — системный переход от моделей «как есть» к моделям «как должно быть» в поддерживающей ИС. Ценность этого перехода в том, что он делает архитектурные решения не следствием интуиции, а результатом целенаправленной аналитической работы, зафиксированной в визуальных диаграммах.

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

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

Методология RUP обобщает подобный подход, возводя в принципы итеративность, управление требованиями и приоритет архитектуры. Итерации не только снижают риски ошибок, но и позволяют на каждом витке пересматривать границы прецедентов и обобщать действующих лиц — как в примере с поликлиникой, где суперклассы «Врач» и «Отправитель запроса» упростили модель без потери смысла. Требование обязательного рецензирования каждой работы создаёт механизм непрерывного контроля качества, предотвращая накопление дефектов.

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