Моделирование использования призвано ответить на вопрос что полезного делает система во внешнем мире?, и этот вопрос ‒ один из первых, на которые необходимо дать ответ.
При первом знакомстве с диаграммами использования в UML у разработчиков программного обеспечения, особенно у опытных разработчиков, часто возникает вопрос: зачем это нужно? При этом такого вопроса относительно других средств UML не возникает, поскольку ответ на него в большинстве случаев очевиден по аналогии. Действительно, рассмотрим несколько примеров типичных ассоциаций, возникающих у разработчиков при первом знакомстве с UML.
Диаграммы деятельности — это не что иное, как блок-схемы алгоритмов. Разработчик программ, особенно со стажем, прекрасно понимает назначение и границы применимости блок-схем. Вопроса "зачем?" просто не возникает, возникают другие вопросы: стоит ли использовать блок-схемы в данном проекте, какую из альтернативных систем обозначений применять и тому подобное.
Диаграммы состояний — это расширение концепции конечных автоматов (см. главу 4), которые являются основным аппаратом в целом ряде областей программирования: трансляторы, логическое управление и другие. Если в конкретной предметной области, например, в области конструирования ответственных систем управления, приказано применять конечные автоматы, то разработчики применяют их, не спрашивая, "зачем?".
Диаграммы классов, в которых показаны атрибуты и операции классов, а также взаимосвязи (ассоциации) между ними, очень похожи на диаграммы "сущность-связь" (ERD ‒ Entity-Relationship Diagram), хорошо известные разработчикам приложений баз данных.
Перечень возникающих у разработчиков ассоциаций можно продолжать и продолжать, для большинства средств UML нетрудно отыскать аналоги среди широко используемых практических методов конструирования программных систем. И это не удивительно, ведь именно эти методы были унифицированы посредством UML. А вот для диаграмм использования известный аналог указать труднее. Мы попытаемся объяснить прагматику моделирования использования на конкретном примере.
В остальных частях книги рассматривается один сквозной пример моделирования сравнительно несложного приложения ‒ информационной системы отдела кадров. Выбор примера обусловлен следующими соображениями.
Во-первых, предметная область до некоторой степени знакома всем (мы полагаем, что читатель где-то работает, а значит, по крайней мере один раз, испытывал на себе работу отдела кадров). Таким образом, суть задачи заранее ясна, и можно сосредоточить внимание на тонкостях применения UML, а не на объяснении особенностей предметной области.
Во-вторых, информационная система отдела кадров — это типичное офисное приложение из самого распространенного класса систем автоматизации делопроизводства. UML как нельзя лучше подходит для моделирования именно таких систем и все средства языка можно проиллюстрировать естественным образом.
В-третьих, авторам случалось разрабатывать похожие системы на самом деле, а не только в книге.
Надо заметить, что целью рассмотрения данного примера является иллюстрация возможностей языка. Может показаться, что последовательность рассмотрения примеров является протоколом реализации процесса моделирования, в целом это не так. Пример рассматривается в порядке изложения различных конструкций языка UML. Рассматривать процесс построения модели безотносительно стадий (фаз) процесса разработки было бы неправильно. Некоторое внимание этому вопросу уделено в главе 5.
Про модель предметной области и модель самого приложения информационной системы отдела кадров, представленные в этой книге, можно сказать только то, что они синтаксически правильны (с точностью до понимания авторами спецификации UML) и семантически непротиворечивы (с точностью до понимания авторами предметной области задачи).
Итак, поставим себя на место разработчика и предположим, что в нашем распоряжении имеется следующий текст, поступивший от заказчика.
ТЕХНИЧЕСКОЕ ЗАДАНИЕ Информационная система «Отдел кадров» (сокращенно ИС ОК) предназначена для ввода, хранения и обработки информации о сотрудниках и движении кадров. Система должна обеспечивать выполнение следующих основных функций: 1. Прием, перевод и увольнение сотрудников. 2. Создание и ликвидация подразделений. 3. Создание вакансий и сокращение должностей.
Конечно, техническое задание из одного абзаца текста и трех нумерованных пунктов ‒ это не более чем учебный пример∇. Однако даже на этом примере видны многие характерные "особенности" подобных документов, которые, увы, слишком часто встречаются в реальной жизни. С одной стороны, что-то написано, а с другой стороны не очень понятно, что делать дальше. Безо всяких объяснений заказчик использует термины свой предметной области ‒ разработчик должен их знать и понимать. Требований к реализации нет вовсе. Функции не упорядочены по приоритетам: не ясно, что является критически важным, а чем можно поступиться в случае необходимости. В общем, раскритиковать это техническое задание в пух и прах не составляет труда. Однако, каким бы недостаточным ни было это техническое задание, после получения ответа на вопрос "кто виноват?", встает вопрос "что делать?".
Мы выберем третий путь, имея целью показать, как, применяя UML, можно постепенно превратить расплывчатое описание приложения во вполне четкую модель, пригодную для реализации.
Преимущества моделирования использования UML мы попробуем выявить, сравнивая его с другими подходами. Известно множество различных подходов к моделированию и последующему проектированию, то есть рекомендаций, что делать после получения технического задания. Мы рассмотрим три из них (наиболее нам близких) и попытаемся указать те подводные камни, которые моделирование использования позволяет обойти.
Наиболее заслуженными является, видимо, следующие методы структурного проектирования.
Программирование сверху вниз — это обобщающее название для модульного программирования без оператора Go To методом пошагового уточнения. Английское название ‒ Top-down approach ‒ более точно акцентирует важнейшее достижение технологической программистской мысли, аккумулированное в этом подходе: проектирование и реализация (кодирование) программы являются двумя неразрывно связанными фазами одного процесса, причем проектирование первично, а реализация вторична. При программировании сверху вниз процесс заключается в следующем. Исходная задача разбивается на подзадачи до тех пор, пока каждая отдельная подзадача не станет настолько простой∇, что ее реализация становится очевидной.
Парным к программированию сверху вниз является программирование снизу вверх, при котором уровень языка программирования повышается (например, с помощью определения модулей) до тех пор, пока он не станет настолько высоким и близким к исходной задаче, что ее реализация станет очевидной. Оба метода имеют очевидные достоинства, но имеют и недостатки: при программировании сверху вниз отладка возможна только по завершении всего проектирования, при программировании снизу вверх велик риск создания невостребованных модулей. На практике всегда применяется комбинация этих подходов, благо они не противоречат друг другу.
С.С. Лаврову принадлежит изобретение термина программирование вширь, когда, начиная с самого первого шага, создается и на всех последующих шагах поддерживается работоспособная версия программы. В терминах программирования сверху вниз это означает проведение одного пути в дереве последовательных уточнений до конца (ствол дерева), а затем постепенное наращивание дерева вширь. Конечно, в начале работы программа не умеет выполнять (почти) никаких нужных функций, но зато она не содержит и ненужных (ошибочных) функций, и что особенно важно, в любой момент может быть продемонстрирована заказчику. Такой стиль подразумевает проведение тестовых испытаний всех готовых модулей при добавлении или изменении любого модуля∇, но не откладывание отладки на окончание разработки. Это требует дополнительных трудозатрат, но оказывает чрезвычайно благотворное психологическое воздействие на разработчика, и еще более благотворное воздействие такой стиль программирования оказывает на заказчика.
Описанный выше метод структурного конструирования программ (с тремя вариациями) хорошо известен, надежен и легко применим во всех случаях. Мы даже рискнем утверждать, что большая часть ныне используемого программного обеспечения изготовлена именно таким способом. Однако наши личные наблюдения показывают, что в результате такого подхода структура приложения оказывается соответствующей структуре команды разработчиков, а не исходной задаче. Если, например, в разработке информационной системы отдела кадров будет задействовано два ведущих разработчика, то будет выделено две основных подсистемы, а если три, то и подсистем окажется три. Это, разумеется, не закон природы, но, тем не менее, при пошаговой детализации произвол выделения подсистем неизбежен.
Рассмотрим второй подход к моделированию. Всякому ясно, что информационная система отдела кадров — это приложение баз данных∇. При проектировании приложений баз данных первый шаг хорошо известен: после получения требований нужно составить схему базы данных, то есть определить состав таблиц базы и полей в таблицах, назначить первичные ключи (primary key) в таблицах и установить связи между таблицами с помощью внешних ключей (foreign key).
Опять мы не можем привести ни одного аргумента общего характера против такого образа действий, и ограничиваемся частным примером. Среди десятка знакомых нам информационных систем отдела кадров примерно в половине случаев (в том числе в коммерчески продаваемых системах) номер позиции в штатном расписании сделан ключом таблицы сотрудников. На первый взгляд такое решение допустимо: номер позиции в штатном расписании уникален, однозначно соответствует сотруднику и может быть использован в качестве ключа (в отличие от фамилии сотрудника, которая вполне может не быть уникальной). Однако полный анализ всего приложения показывает, что это грубая проектная ошибка, порождающая проблемы на позднейших стадиях разработки и заведомую неэффективность в работе системы. Чтобы понять, в чем ошибка, нужно рассмотреть операцию "перевод сотрудника", которая приводит к изменению номера позиции в штатном расписании, т.е. первичного ключа в записи сотрудника.
Наконец, рассмотрим самый модный объектно-ориентированный подход к моделированию. Апологеты этого подхода первый шаг проектирования описывают примерно так: нужно выделить словарь предметной области (то есть набор основных понятий), сопоставить этим понятиям классы проектируемой системы, определить их атрибуты и операции и дальше все пойдет как по маслу.
И здесь нечего возразить! Если словарь выделен, то действительно, дальше все идет отлично. Но кто выделяет словарь?
Если разработчик, то он должен быть экспертом в конкретной предметной области и знать ее досконально, в противном случае никто не может гарантировать полноту и адекватность словаря, а ошибки при выделении базовых классов относятся к самым тяжелым проектным ошибкам. Если же заказчик, то он должен быть образцом педантичности, аккуратности и дальновидности, потому что ошибку заказчика разработчик не заметит и не исправит ‒ ошибка перейдет в проект, потом в приложение и проявится уже при эксплуатации самым неприятным образом. Самый лучший вариант ‒ когда словарь составляется совместно и за несколько итераций.
Подводя итоги нашему рассмотрению альтернативных подходов к проектированию, отметим следующее обстоятельство. Во всех трех рассмотренных случаях первый шаг проектирования сразу выполняется в терминах проектируемой системы, причем однобоко. Действительно, в первом случае за основу берется структура будущего кода, во втором ‒ структура хранимых данных, а в третьем ‒ структура взаимодействующих объектов. Еще раз оговоримся: мы не видим в бегло упомянутых альтернативных подходах к проектированию никаких непреодолимых пороков. Опытный мастер легко спроектирует информационную систему отдела кадров, пользуясь любым подходом. Но новичок может столь же легко допустить при проектировании трудно исправимую ошибку. Запомним это обстоятельство и обратимся к рассмотрению моделирования использования.
Отвлечемся пока от технических деталей нотации диаграмм использования (они рассмотрены в разделе 2.2) и попробуем перечислить те преимущества, которые дает этот подход по сравнению с другими.
Простые утверждения. Моделирование использования фактически позволяет переписать исходное техническое задание (или просто записать, если никакой исходной формулировки требований не было) в строгой и формальной, но, в тоже время, очень простой и наглядной графической форме, как совокупность простых утверждений относительно того, что делает система для пользователей. Простое утверждение имеет следующую грамматическую форму: подлежащее ‒ сказуемое ‒ прямое дополнение. Или, в логических терминах, субъект ‒ предикат ‒ объект. Например: начальник увольняет сотрудника, директор создает отдел. Конечно, использование такой формы не гарантирует от ошибок (вряд ли гарантия от ошибок вообще возможна), но благодаря простоте и наглядности формы их легче заметить.
Абстрагирование от реализации. Моделирование использования предполагает формулирование требований к системе абсолютно независимо от ее реализации. Другими словами, представление использования описывает только, что делает система (но не как это делается и не зачем это нужно делать). Заметим, что другие подходы, используя на первых шагах термины и понятия реализации (структура программы, структура данных, структура взаимодействующих объектов) накладывают невольные ограничения на реализацию, которые не вытекают из существа задачи, а значит, могут служить источником неэффективности и ошибок.
Декларативное описание. Каждый вариант использования описывает (а вернее сказать, именует) некоторое множество последовательностей действий, доставляющих значимый для пользователя результат. Однако никакого императивного описания представление использования не содержит, в модели нет указаний на то, какой вариант использования должен выполняться раньше, а какой позже, то есть, нет описания алгоритма, а значит, нет алгоритмических ошибок.
Выявление границ. Представление использования определяет границы системы и постулирует существование во внешнем мире использующих ее агентов (действующих лиц). Описание системы в виде черного ящика с определенными интерфейсами кажется очень похожим на представление использования, но здесь есть важное различие, которое часто упускается из вида. Если ограничиться только описанием интерфейсов, то очень легко допустить ошибки следующего типа: предусмотреть интерфейс, который не нужен, потому что им никто не пользуется. Или, аналогично, забыть интерфейс, который необходим определенной категории пользователей. На диаграмме использования одинокие и покинутые действующие лица и варианты использования обнаруживаются с первого взгляда.
Наш вывод таков: моделирование использования безопаснее и надежнее альтернативных методов, то есть при прочих равных условиях позволяет совершить меньше грубых проектных ошибок на ранних стадиях проектирования. В этом заключается основное преимущество данного метода.
Не следует думать, что моделирование использования ‒ это панацея от всех болезней разработки программного обеспечения. Существуют области, где моделирование использования практически ничего не дает. Например: разработка автономного компилятора некоторого языка программирования.