Диаграммы классов UML. Логическое моделирование

Основным результатом  бизнес-анализа является бизнес-модель, которая представляется на языке UML. Состав ее будет обсуждаться ниже. Здесь мы заметим, что UML позволяет строить модели любой системы, не обязательно программной, поэтому для описания работы организации используются те же логические и функциональные модели, что и для ПС. Единственное дополнение состоит в том, что в модели бизнеса должны присутствовать бизнес-исполнители – специалисты обследуемой организации, отвечающие за выполнение тех или иных работ.

Роли

В моделировании  бизнеса участвуют:

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

Артефакты

При моделировании  создаются следующие артефакты  в виде текстовых документов и  моделей, описанных на UML:

• Документ «Видение бизнеса» – определяет цели проведение бизнес-анализа.
• Структура организации – статическое описание подразделений организации и отношений подчиненности в виде диаграмм пакетов и/или классов.
• Модель видов деятельности включает бизнес-актеров и виды деятельности организации. К числу бизнес-актеров относятся: заказчики, партнеры, поставщики, власти (представители закона, инспекция и др.), дочерние организации, собственники и инвесторы, внешние информационные системы. Бизнес-актеры помогают определить границы организации, которую требуется описать. Виды деятельности представляют собой бизнес-процессы. Модель видов деятельности представляется с помощью use case диаграмм.
• Объектная модель включает бизнес-актеров, бизнес-исполнителей и бизнес-сущности, а также содержит описание их взаимодействий при реализации видов деятельности. Модель представляется на UML с помощью диаграмм классов и взаимодействий (последовательностей, коопераций, деятельностей), которые иногда называют технологическими сценариями.
• Модель предметной области является подмножеством объектной модели. Она описывает основные бизнес-сущности и связи между ними. Эта модель представляется в виде диаграмм классов.
• Глоссарий – текстовый документ, содержащий определения основных понятий, используемых в данном бизнесе.
• Оценка деятельности организации – текстовый документ, описывающий текущее состояние организации, в которой будет использоваться ПС.
• Бизнес-правила – текстовый документ, определяющий условия и ограничения, которым должен удовлетворять бизнес.
• Дополнительные спецификации – текстовый документ, содержащий описание свойств бизнеса, не включенных в бизнес-модель.

Процесс

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

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

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

  
Рис.1. Технологический процесс бизнес-анализа

Реинжиниринг  программных систем

Откуда берутся  требования к системе? Один источник требований мы уже описали – это  бизнес-анализ, проводимый в начальной  фазе проекта. Вторым таким источником являются ПС, эксплуатируемые в организации. Разработка современных ПС редко  когда начинается "с нуля". Чаще всего у заказчика имеется  работающая (наследуемая) система, для  которой требуется расширить  состав выполняемых функций, перевести  ее на другую, более современную  платформу, обеспечить доступ через  интернет, повысить производительность и т. д. При этом типичной является ситуация, когда наследуемая система  плохо документирована (нет моделей  и описания, частично или полностью  отсутствуют исходные коды программ, устарела пользовательская документация и др.). В этом случае прежде чем  браться за разработку новой системы, необходимо документировать наследуемую. В терминах RUP это означает, что  необходимо построение модели, описывающей ПС с различных точек зрения. Моделирование наследуемой системы основывается на проведении реинжиниринга, в процессе которого выполняется восстановление описывающих систему моделей на основе анализа имеющейся информации. При этом функциональность, реализованная в наследуемой системе, определяет часть требований к проектируемой ПС (в большинстве случаев достаточно значительную).

К сожалению, в RUP реинжинирингу  ПС уделено весьма незначительное внимание. Настоящая статья позволит частично восполнить этот пробел.

Цели  реинжиниринга

Цели проведения реинжиниринга заключаются в  следующем:

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

Задачи  реинжиниринга

Задачи, решаемые при  реинжиниринге, включают:

• определение системных архитектур;
• определение актеров существующей системы;
• определение функциональности существующей системы;
• определение логической структуры системы;
• восстановление реляционной модели данных.

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

Начальная фаза

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

Определение системных архитектур

Работы по описанию архитектур начинаются фактически на начальном этапе, когда определяется состав оборудования и стандартное  программное обеспечение (ПО), необходимые  для инсталляции и запуска  существующей зафиксированной системы. Тем самым фактически определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры  представляются в нотации UML и при  необходимости дополняются текстовыми описаниями. Поостренные архитектурные  модели в процессе реинжиниринга  будут уточняться и дополняться.

Автоматический  реинжиниринг

Автоматический  реинжиниринг осуществляется с помощью  инструментальных средств визуального  моделирования. Его выполнение позволяет  построить модели, которые могут  быть приняты как исходные. Автоматическому  реинжинирингу подвергается как  бизнес логика (если есть исходные коды на объектно-ориентированном или  объектно-базированном языке), так и  БД.

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

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

Редактирование  диаграмм моделей

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

Если диаграмма  содержит слишком много элементов, то анализировать ее сложно. Попробуйте проанализировать диаграмму, содержащую более 100 классов! Поэтому целесообразно  разбить такую диаграмму на несколько  отдельных диаграмм, оставляя в каждой примерно по 7 – 10 элементов.

Метод повышения  наглядности диаграмм хорошо известен. Это иерархическая реструктуризация. Средством ее осуществления в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты – подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.

Построение  функциональной модели

Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей  и деятельностей. Источником для  ее построения является работающая наследуемая  система и проводимые с ней  эксперименты. На этом этапе особенно эффективно привлечение к работам  по реинжинирингу эксперта организации  заказчика (см. статью «RUP. Общие сведения»). С его помощью можно быстрее  и точнее определить состав актеров  наследуемой системы и основные ВИ. Эксперт заказчика может словесно описать, кто использует систему  и что она должна делать для  пользователей каждого типа. Он может  также информировать, с какими другими  системами взаимодействует наследуемая  ПС, какие работы осуществляются периодически. Все эти сведения будут способствовать более точному пониманию функциональности системы разработчиками.

Определение актеров

Для нахождения актеров  следует искать ответы на следующие  вопросы:

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

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

Актерам следует  присвоить имена, отражающие их роли в работе с системой.

Определение вариантов использования

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

Далее выполняется  детализация построенных пакетов  ВИ на основе анализа экранных форм. Рекомендуемые правила:

• если экран содержит меню, то это пакет ВИ. При этом каждая строка меню – это либо подпакет, либо отдельный ВИ;
• если основной экран – форма, то это отдельный ВИ.