Откуда берутся требования к системе? Один источник требований мы уже описали – это бизнес-анализ, проводимый в начальной фазе проекта. Вторым таким источником являются ПС, эксплуатируемые в организации. Разработка современных ПС редко когда начинается "с нуля". Чаще всего у заказчика имеется работающая (наследуемая) система, для которой требуется расширить состав выполняемых функций, перевести ее на другую, более современную платформу, обеспечить доступ через интернет, повысить производительность и т. д. При этом типичной является ситуация, когда наследуемая система плохо документирована (нет моделей и описания, частично или полностью отсутствуют исходные коды программ, устарела пользовательская документация и др.). В этом случае прежде чем браться за разработку новой системы, необходимо документировать наследуемую. В терминах RUP это означает, что необходимо построение модели, описывающей ПС с различных точек зрения. Моделирование наследуемой системы основывается на проведении реинжиниринга, в процессе которого выполняется восстановление описывающих систему моделей на основе анализа имеющейся информации. При этом функциональность, реализованная в наследуемой системе, определяет часть требований к проектируемой ПС (в большинстве случаев достаточно значительную).
К сожалению, в RUP реинжинирингу ПС уделено весьма незначительное внимание. Настоящая статья позволит частично восполнить этот пробел.
Порядок решения этих задач принципиально отличается от порядка действий, выполняемых при разработке новых проектов. Логическая архитектура системы определена ее реализацией, в частности, структурой каталогов, размещением файлов по каталогам, распределением задач между сервером и клиентскими местами. Кроме того, часть моделей системы может быть получена автоматически с помощью инструментальных средств. Таким образом, не функциональное описание системы служит основой для выявления классов и отношений между ними, а наоборот, предварительно полученные диаграммы классов могут существенно облегчить описание поведения системы.
Начать процесс реинжиниринга следует с определения того, что есть по существующей системе (исходные тесты, БД, описания и т. д.). При этом фиксируется текущее состояние наследуемой системы (все изменения, вносимые в нее после этого момента, при выполнении реинжиниринга не учитываются). Если есть возможность выполняется развертывание наследуемой ПС у разработчика.
Работы по описанию архитектуры начинаются фактически на начальном этапе, когда определяется состав оборудования и стандартное программное обеспечение (ПО), необходимые для инсталляции и запуска существующей зафиксированной системы. Тем самым фактически определяются архитектуры БД, оборудования и стандартного ПО, телекоммуникаций. Все архитектуры представляются в нотации UML и при необходимости дополняются текстовыми описаниями. Поостренные архитектурные модели в процессе реинжиниринга будут уточняться и дополняться.
Автоматический реинжиниринг осуществляется с помощью инструментальных средств визуального моделирования. Его выполнение позволяет построить модели, которые могут быть приняты как исходные. Автоматическому реинжинирингу подвергается как бизнес логика (если есть исходные коды на объектно-ориентированном или объектно-базированном языке), так и БД.
Автоматический реинжиниринг бизнес логики может быть выполнен только в случае, когда имеются (полностью или частично) исходные тексты программ. В результате автоматического реинжиниринга кодов создаются диаграммы классов и диаграммы компонент UML.
Реинжиниринг БД выполняется с помощью инструментальных средств проектирования БД. Результатом является реляционная модель данных, которая может графически отображаться этим средством. Полученная реляционная модель может по усмотрению разработчиков переведена в диаграмму классов UML путем использования применяемого инструментального средства разработки БД или программных мостов со средствами визуального ОО моделирования.
Модели, полученные автоматически, весьма сложно читать и анализировать, поскольку элементы модели размещаются без учета наглядности диаграмм. Поэтому построенные модели должны быть отредактированы. В процессе редактирования не следует выполнять содержательные преобразования (удалять или добавлять элементы модели). Главной целью редактирования на этом этапе является достижение наглядности диаграмм. Для этого используется перемещение элементов диаграмм. В процессе редактирования могут вноситься комментарии к элементам модели. Например, можно прокомментировать назначение отдельных классов. Комментарии заносятся в поля спецификаций элементов моделей.
Если диаграмма содержит слишком много элементов, то анализировать ее сложно. Попробуйте проанализировать диаграмму, содержащую более 100 классов! Поэтому целесообразно разбить такую диаграмму на несколько отдельных диаграмм, оставляя в каждой примерно по 7 – 10 элементов.
Метод повышения наглядности диаграмм хорошо известен. Это иерархическая реструктуризация. Средством ее осуществления в UML являются пакеты. Сложные ПС обычно включают несколько подсистем, имеющих разное целевое назначение и функциональность. Поэтому на верхнем уровне иерархии можно показать пакеты – подсистемы. Каждый из таких пакетов должен получить имя, отражающее суть соответствующей подсистемы. На этом уровне можно также показать пакеты классов, являющиеся общими для всей системы и используемые подсистемами. На начальной стадии реструктуризации логической модели можно ввести пакет верхнего уровня, куда помещаются классы, которые трудно отнести к какому-либо другому пакету. В любой ПС есть пользовательский интерфейс, связь с БД, управление, обработка, классы данных. Такого типа пакеты можно ввести в каждой подсистеме на следующем уровне иерархии.
Модель функционирования описывается с помощью диаграмм ВИ и детализирующих их диаграмм последовательностей и деятельностей. Источником для ее построения является работающая наследуемая система и проводимые с ней эксперименты. На этом этапе особенно эффективно привлечение к работам по реинжинирингу эксперта организации заказчика (см. статью «RUP. Общие сведения»). С его помощью можно быстрее и точнее определить состав актеров наследуемой системы и основные ВИ. Эксперт заказчика может словесно описать, кто использует систему и что она должна делать для пользователей каждого типа. Он может также информировать, с какими другими системами взаимодействует наследуемая ПС, какие работы осуществляются периодически. Все эти сведения будут способствовать более точному пониманию функциональности системы разработчиками.
Ответы на поставленные вопросы можно получить либо путем опроса экспертов заказчика, либо из документации на систему, либо (если таковых не имеется) путем запуска системы и анализа экранных форм или меню.
Актерам следует присвоить имена, отражающие их роли в работе с системой.
Определение ВИ выполняется на основе анализа экранов работающей системы. Сначала определяются пакеты ВИ. Для этого следует найти все первичные экраны и для каждого из них в модели на головной диаграмме ВИ завести отдельный пакет. Таким образом, на этой диаграмме будет пакет актеров и несколько пакетов ВИ.
Поскольку очень важно показать, как актеры соотносятся с ВИ, после нахождения ВИ определяется, какие актеры взаимодействуют с системой в этом варианте. В модель включаются ассоциации. Они имеют направления, соответствующие направлениям передачи информации между актерами и ВИ.
Могут быть и другие способы обеспечения наглядности модели, важно лишь иметь четкую стратегию разбиения на пакеты.
Одновременно с выделением ВИ строится навигация экранов наследуемой системы в виде диаграммы классов UML. Каждый экран показывается в модели как отдельный класс, в котором полям соответствуют атрибуты, функциональным кнопкам – операции, а кнопкам меню – одноименные отношения.
Детализация функциональности представляет собой построение сценариев реализации ВИ, представленных в модели ВИ. Она выполняется с помощью диаграмм последовательностей и диаграмм деятельностей UML. Выбор вида диаграмм в каждом конкретном случае зависит от того, что преобладает в данном ВИ – логика выполнения или передачи данных. В первом случае предпочтительно применять диаграммы деятельностей, где легко показывать ветвления и параллельную обработку, во втором – диаграммы последовательностей.
Детализация требуется в особенности для тех вариантов использования, в которых важна последовательность действий, учитывается состояние системы, имеется разветвленная логика выполнения. Целесообразно детализировать выполнение ВИ, определяющих основную функциональность системы. Если заказчик высказывает пожелания относительно того, что из наследуемой системы должно быть сохранено в новой ПС, то именно эти ВИ должны быть детализированы.
Детализация осуществляется на основе анализа исходных кодов. По текстам программ выявляются ветвления, выражения, циклы. Это позволяет восстановить алгоритмы, представив их в виде диаграмм деятельностей или диаграмм состояний. Другой путь – это проведение экспериментов с работающей наследуемой системой. Варьирование входных данных и анализ реакции системы на эти данные делает возможным обнаружение ветвлений и ограничений. Можно также выдвигать и проверять гипотезы об алгоритмах вычислений.
Модели, построенные в результате реинжиниринга, являются основой для определения требований к проектируемой ПС, а также для построения логической и функциональной моделей новой системы.