Значение моделирования использования

При первом знакомстве с диаграммами использования в UML у разработчиков программного обеспечения, особенно у опытных разработчиков, часто возникает вопрос: зачем это нужно? При этом такого вопроса относительно других средств UML не возникает, поскольку ответ на него в большинстве случаев очевиден по аналогии.

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

Диаграммы состояний — это конечные автоматы, которые являются основным аппаратом в целом ряде областей программирования: трансляторы, логическое управление и другие.

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

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

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

ТЕХНИЧЕСКОЕ ЗАДАНИЕ

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

1. Прием, перевод и увольнение сотрудников.

2. Создание и ликвидация подразделений.

2. Создание вакансий и сокращение должностей.

Конечно, техническое задание из одного абзаца текста и трех нумерованных пунктов — это не более чем учебный пример. Однако даже на этом примере видны многие характерные "особенности" подобных документов, которые, увы, слишком часто встречаются в реальной жизни. С одной стороны, что-то написано, а, с другой стороны не очень понятно, что делать дальше. Безо всяких объяснений заказчик использует термины свой предметной области — разработчик должен их знать и понимать. Требований к реализации нет вовсе. Функции не упорядочены по приоритетам: не ясно, что является критически важным, а чем можно поступиться в случае необходимости. В общем, раскритиковать это техническое задание в пух и прах не составляет труда.

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

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

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

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

Наконец, рассмотрим самый модный объектно-ориентированный подход. Апологеты этого подхода первый шаг проектирования описывают примерно так: нужно выделить словарь предметной области (то есть набор основных понятий), сопоставить этим понятиям классы проектируемой системы, определить их атрибуты и операции.

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

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

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

• Простые утверждения. Моделирование использования фактически позволяет переписать исходное техническое задание в строгой и формальной, но в тоже время очень простой и наглядной графической форме, как совокупность простых утверждений относительно того, что делает система для пользователей..

• Абстрагирование от реализации. Моделирование использования предполагает формулирование требований к системе абсолютно независимо от ее реализации. Другими словами, представление использования описывает только, что делает система (но не как это делается и не зачем это нужно делать).

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

• Выявление границ. Представление использование определяет границы системы и постулирует существование во внешнем мире использующих ее агентов.

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