Техническое задание информационная система Отдел кадров
 Скачать 434.84 Kb.
|
|
2. Моделирование использования 2.1 Значение моделирования использования При первом знакомстве с диаграммами использования в UML у разработчиков программного обеспечения, особенно у опытных разработчиков, часто возникает вопрос: зачем это нужно? При этом такого вопроса относительно других средств UML не возникает, поскольку ответ на него в большинстве случаев очевиден по аналогии. Диаграммы деятельности — это не что иное, как блок-схемы алгоритмов. Разработчик программ, особенно со стажем, прекрасно понимает назначение и границы применимости блок-схем. Диаграммы состояний — это конечные автоматы, которые являются основным аппаратом в целом ряде областей программирования: трансляторы, логическое управление и другие. Диаграммы классов, в которых показаны атрибуты классов и ассоциации между ними, очень похожи на диаграммы "сущность-связь", хорошо известные разработчикам приложений баз данных. Перечень возникающих у программистов ассоциаций можно продолжать и продолжать, для большинства средств UML нетрудно отыскать аналоги среди широко используемых практических методов конструирования программных систем. А вот для диаграмм использования известный аналог указать труднее. Попытаемся объяснить прагматику моделирования использования на конкретном примере. В остальных частях пособия рассматривается один сквозной пример моделирования несложного приложения — информационной системы отдела кадров. Итак, поставим себя на место разработчика и предположим, что в нашем распоряжении имеется следующий текст, поступивший от заказчика. ТЕХНИЧЕСКОЕ ЗАДАНИЕ Информационная система «Отдел кадров» (сокращенно ОК) предназначена для ввода, хранения и обработки информации о сотрудниках и движении кадров. Система должна обеспечивать выполнение следующих основных функций. Прием, перевод и увольнение сотрудников. Создание и ликвидация подразделений. Создание вакансий и сокращение должностей. Конечно, техническое задание из одного абзаца текста и трех нумерованных пунктов — это не более чем учебный пример. Однако даже на этом примере видны многие характерные "особенности" подобных документов, которые, увы, слишком часто встречаются в реальной жизни. С одной стороны, что-то написано, а, с другой стороны не очень понятно, что делать дальше. Безо всяких объяснений заказчик использует термины свой предметной области — разработчик должен их знать и понимать. Требований к реализации нет вовсе. Функции не упорядочены по приоритетам: не ясно, что является критически важным, а чем можно поступиться в случае необходимости. В общем, раскритиковать это техническое задание в пух и прах не составляет труда. Покажем, как, применяя UML, можно постепенно превратить расплывчатое описание приложения во вполне четкую модель, пригодную для реализации. Преимущества моделирования использования UML мы попробуем выявить, сравнивая его с другими подходами. Известно множество различных подходов к проектированию, то есть рекомендаций, что делать после получения технического задания. Мы рассмотрим три (наиболее нам близких) из них и попытаемся указать те подводные камни, которые позволяет обойти использование UML. Наиболее заслуженным является, видимо, метод структурного проектирования "сверху вниз". Этот метод конструирования программ хорошо известен, надежен и легко применим во всех случаях. Однако наблюдения показывают, что в результате структура приложения оказывается соответствующей структуре команды разработчиков, а не исходной задаче. Если в разработке информационной системы отдела кадров задействовано два ведущих разработчика, то будет выделено две основных подсистемы, а если три, то и подсистем окажется три. Рассмотрим второй подход. Всякому ясно, что информационная система отдела кадров — это приложение баз данных. При проектировании приложений баз данных первый шаг хорошо известен: нужно составить схему базы данных, то есть определить состав таблиц базы и атрибутов в таблицах, назначить первичные ключи в таблицах и установить связи между таблицами с помощью внешних ключей. Наконец, рассмотрим самый модный объектно-ориентированный подход. Апологеты этого подхода первый шаг проектирования описывают примерно так: нужно выделить словарь предметной области (то есть набор основных понятий), сопоставить этим понятиям классы проектируемой системы, определить их атрибуты и операции. Если словарь выделен, то действительно, дальше все идет отлично. Но кто выделяет словарь? Если разработчик, то он должен быть оракулом в конкретной предметной области, в противном случае никто не может гарантировать полноту и адекватность словаря, а ошибки при выделении базовых классов относятся к самым тяжелым проектным ошибкам. Отметим, что во всех трех рассмотренных случаях первый шаг проектирования сразу выполняется в терминах проектируемой системы, причем однобоко. Действительно, в первом случае за основу берется структура будущего кода, во втором — структура хранимых данных, а в третьем — структура межмодульных интерфейсов. Рассмотрим, что предлагается делать на первом шаге моделирования использования. Наш язык и мышление устроены так, что самой простой, понятной и четкой формой изложения мыслей являются так называемые простые утверждения. Простое утверждение имеет следующую грамматическую форму: подлежащее — сказуемое — прямое дополнение. Или, в логических терминах, субъект — предикат — объект. Например: начальник увольняет сотрудника, директор создает отдел. Именно простые утверждения и записаны на диаграмме использования. Действительно, действующее лицо — это субъект, а вариант использования — предикат (вместе с объектом). Таким образом, моделирование использования отличается от рассмотренных подходов тем, что предполагает явное формулирование требований к системе на самом начальном этапе разработки. Перечислим те преимущества, который дает этот подход по сравнению с другими. Простые утверждения. Моделирование использования фактически позволяет переписать исходное техническое задание в строгой и формальной, но в тоже время очень простой и наглядной графической форме, как совокупность простых утверждений относительно того, что делает система для пользователей.. Абстрагирование от реализации. Моделирование использования предполагает формулирование требований к системе абсолютно независимо от ее реализации. Другими словами, представление использования описывает только, что делает система (но не как это делается и не зачем это нужно делать). Декларативное описание. Каждый вариант использования описывает (а вернее сказать, именует) некоторое множество последовательностей действий, доставляющих значимый для пользователя результат. Однако, в модели нет указаний на то, какой вариант использования должен выполняться раньше, а какой позже, то есть нет описания алгоритма, а значит, нет алгоритмических ошибок. Выявление границ. Представление использование определяет границы системы и постулирует существование во внешнем мире использующих ее агентов. Следовательно, моделирование использования безопаснее и надежнее альтернативных методов, то есть при прочих равных условиях позволяет совершить меньше грубых проектных ошибок на ранних стадиях проектирования. В этом заключается основное преимущество данного метода. 2.2 Диаграммы использования Диаграмма использования является основным средством моделирования использования в UML. На диаграмме использования применяются следующие типы сущностей: действующие лица; варианты использования; примечания; пакеты. Между этими сущностями устанавливаются следующие типы отношений: ассоциация между действующим лицом и вариантом использования; обобщение между действующими лицами; обобщение между вариантами использования; зависимости (двух стереотипов) между вариантами использования; зависимости между пакетами. На рисунке 2.1. представлена графическая нотация элементов диаграмм использования, справедливая дл версии UML 2.0.  Рисунок 2.1. Нотация диаграмм использования (UML 2.0) Применение пакетов для группировки элементов модели унифицировано в UML для всех типов диаграмм, а остальные элементы рассмотрим по порядку. Действующие лица. Вопрос о выделении (или идентификации) действующих лиц при составлении модели — один из самых болезненных. Неудачный выбор действующих лиц может отрицательно повлиять на всю модель в целом. Здесь легко впасть в крайность: объявить, что имеется одно действующее лицо (внешний мир), взаимодействующее со всеми вариантами использования или, наоборот, придумать искусственных действующих лиц для каждого варианта использования. Формального метода идентификации действующих лиц не существует. Перечислим некоторые приемы, которые полезно, по нашему мнению, иметь в виду при выделении действующих лиц и покажем применение этих приемов на нашем сквозном примере. Для начала укажем более детальное определение действующего лица. С синтаксической точки зрения действующее лицо — это стереотип классификатора, который обозначается специальным значком. Для действующего лица указывается только имя, идентифицирующее его в системе. Семантически действующее лицо — это множество логически взаимосвязанных ролей. Роль в UML — это интерфейс, поддерживаемый данным классификатором в данной ассоциации. С прагматической точки зрения главным является то, что действующие лица находятся вне проектируемой системы (или рассматриваемой части системы). В типовых случаях различные действующие лица назначаются для категорий пользователей (если их удается выделить естественным образом), внешних программных и аппаратных средств (если система взаимодействует с таковыми). Рассмотрим наш пример с информационной системой отдела кадров. Про внешние программные и аппаратные средства в техническом задании ничего не сказано и этот вопрос пока разумно оставить в стороне. Трудно представить себе организацию, в которой реорганизация внутренней структуры и найм персонала выполняются автоматически, без участия человека, поэтому у нашей системы, очевидно, будут пользователи. Выделение категорий пользователей происходит, как правило, неформально: из соображений здравого смысла и собственного опыта. Имеет смысл отнести пользователей к разным категориям, если наблюдаются следующие признаки: пользователи участвуют в разных (независимых) бизнес-процессах; пользователи имеют различные права на выполнение действий и доступ к информации; пользователи взаимодействуют с системой в разных режимах: от случая к случаю, регулярно, постоянно. В первом приближении выделяем две категории пользователей: менеджер персонала, который работает с конкретными людьми; менеджер штатного расписания, который работает с абстрактными должностями и подразделениями. Бизнес-процесс пользователя первой категории включает в себя не только работу с приложением, но и беседы с конкретными людьми, интервью и тому подобное, чем явно отличается от других бизнес-процессов предприятия. Пользователи второй категории, очевидно, должны иметь специальные права доступа, поскольку вряд ли допустимо, чтобы кто угодно мог создавать и уничтожать подразделения на предприятии. На рисунке 2.2 показано формирование представление использования информационной системы отдела кадров. Менеджер персонала имеет имя Personnel Manager, а менеджер штатного расписания — Staff Manager, в соответствии с используемой дисциплиной имен.  Рисунок 2.2. Действующие лица информационной системы отдела кадров Правила формирования идентификаторов в программе называются дисциплиной имен. Дисциплина имен должна учитывать по меньшей мере три фактора: набор различных характеристик именуемых объектов (и области значений этих характеристик), которые учитываются в данной дисциплине; набор правил формирования имен по заданным значениям выбранных характеристик (с учетом возможных лексических ограничений системы программирования); набор операций (помимо операции чтения человеком), которые выполняются над множествами имен. Важным вопросом при формировании имен является выбор набора символов. Для идентификаторов в программах обычно используют буквы латинского алфавита. Для содержательных (семантических) частей желательно, чтобы имена являлись узнаваемыми словами или словосочетаниями. Использование транслитерированных русских слов выглядит ужасно. Использование правильных английских слов хорошо, но требует, чтобы все читатели и писатель программы одинаково владели английским. Выход заключается в том, чтобы составить жаргонный словарь из слов, сокращений и аббревиатур и пользоваться только им.1 Для UML пока что нет достаточно устоявшейся дисциплины имен, но некоторый набор рекомендаций можно найти в литературе. В частности, в качестве имен действующих лиц рекомендуется использовать существительное (возможно с определяющим словом), а в качестве имен вариантов использования — глагол (возможно, с дополнением). Эти правила основаны на семантике моделирования использования. Выделение вариантов использования — ключ ко всему дальнейшему моделированию. На этом этапе определяется функциональность системы, то есть, что она должна делать. Нотация для варианта использования очень скудная — это просто имя, помещенное в овал (или помещенное под овалом — такой вариант тоже допустим). Другими словами, функции, выполняемые системой, на уровне моделирования использования никак не раскрываются — им только даются имена. Семантически вариант использования — это описание множества возможных последовательностей действий (событий), приводящих к значимому для действующего лица результату. Каждая конкретная последовательность действий называется сценарием. Таким образом, вариант использования является классификатором (см. главу 3), экземплярами которого являются сценарии. Прагматика варианта использования состоит в том, что среди всех последовательностей действий, могущих произойти при работе приложения, выделяются такие, в результате которых получается явно видимый и достаточно важный для действующего лица (в частности, для пользователя) результат. Сказанное для действующих лиц уместно повторить и для вариантов использования: выбор вариантов использования сильно влияет на качество модели, а формальные методы предложить трудно. Если в вашем распоряжении есть техническое задание, пункты которого естественным образом переводятся в варианты использования, знайте, что вам сильно повезло. Если техническое задание представляет собой смесь очевидных пожеланий пользователя, смутных утверждений и конкретных требований (как обычно бывает), то попробуйте поискать в тексте отглагольные существительные и глаголы с прямым дополнением: может статься, что в них зашифрованы варианты использования. Если у вас вовсе нет технического задания, составьте его, пользуясь исключительно простыми утверждениями. В нашем примере простой анализ текста технического задания выявляет семь вариантов использования: прием сотрудника; перевод сотрудника; увольнение сотрудника; создание подразделения; ликвидация подразделения; создание вакансии; сокращение должности; Опираясь на знание предметной области, которое не отражено в техническом задании (характерный случай), заметим, что термин "вакансия" является сокращением оборота "вакантная должность", то есть должность в некотором особом состоянии. Само же слово "должность" многозначно. Это может быть и обозначение конкретного рабочего места — позиции в штатном расписании, и обозначение совокупности таких позиций, имеющих общие признаки: функциональные обязанности, зарплата и т. п. Например: "в организации различаются должности: программист, аналитик, руководитель проекта" или "в отделе разработки предусмотрены 9 программистов, 3 аналитика и 2 руководителя проектов". Кадровые работники легко различают эти случаи по контексту. Примем рабочую гипотезу о том, что автор технического задания использовал слово должность в первом смысле и получим набор вариантов использования, представленный на рисунке 2.3.  Рисунок 2.3. Варианты использования информационной системы отдела кадров Третьим типом сущности, применяемым на диаграмме использования, является примечание.. Примечания можно и нужно употреблять на всех типах диаграмм, а не только на диаграммах использования. UML является унифицированным, но никак не универсальным языком — при моделировании проектировщик часто может сказать о моделируемой системе больше, чем это позволяют сделать строгая, но ограниченная нотация UML. В таких случаях наиболее подходящим средством для внесения в модель дополнительной информации является примечание. В отличии от большинства языков программирования примечания в UML синтаксически оформлены с помощью специальной нотации и выступают на тех же правах, что и остальные сущности. А именно, примечание имеет свою графическую нотацию — прямоугольник с загнутым уголком, к котором находится текст примечания. Примечания могут находиться в отношении соответствия с другими сущностями — эти отношения изображаются пунктирной линией без стрелок. Примечания содержат текст, который вводит пользователь — создатель модели. Это может быть текст в произвольном формате: на естественном языке, на языке программирования, на формальном логическом языке, например, OCL и т. д. Более того, если возможности инструмента это позволяют, в примечаниях можно хранить гиперссылки, вложенные файлы и другие внешние по отношению к модели артефакты. В UML последовательно проводится следующий важный принцип: вся информация, которую пользователь соизволил внести в модель, должна быть сохранена инструментом во внутреннем представлении модели и предъявлена по первому требованию, даже если инструмент не умеет обрабатывать эту информацию. Примечания являются важнейшим средством реализации этого принципа. Примечания могут иметь стереотипы. В UML определены два стандартных стереотипа для примечаний: requirement — описывает общее требование к системе; responsibility — описывает ответственность класса. Примечания первого типа часто применяют в диаграммах использования, а примечания второго типа — в диаграммах классов. Возвращаясь к нашему примеру, будет совсем не лишним указать, что информацию о состоянии кадров нужно хранить постоянно, т. е. она не должна исчезать после завершения сеанса работы с системой (Рисунок 2.4).  Рисунок 2.4. Требование к информационной системе отдела кадров На диаграммах использования применяются следующие основные типы отношений: ассоциация между действующим лицом и вариантом использования; обобщение между действующими лицами; обобщение между вариантами использования; зависимости между вариантами использования; Ассоциация между действующим лицом и вариантом использования показывает, что действующее лицо тем или иным способом взаимодействует (предоставляет исходные данные, потребляет результат) с вариантом использования. Другими словами, эта ассоциация обозначает, что действующее лицо так или иначе, но обязательно непосредственно участвует в выполнении каждого из сценариев, описываемых вариантом использования. Ассоциация является наиболее важным и, фактически, обязательным отношением на диаграмме использования. Действительно, если на диаграмме использования нет ассоциаций между действующими лицами и вариантами использования, то это означает, что система не взаимодействует с внешним миром. Такие системы, равно как и их модели, не имеют практического смысла. Применительно к нашему примеру в первом приближении можно обозначить ассоциации, представленные на рисунке 2.5.  Рисунок 2.5. Ассоциации между действующими лицами и вариантами использования информационной системы отдела кадров Обобщение между действующими лицами показывает, что одно действующее лицо наследует все свойства (в частности, участие в ассоциациях) другого действующего лица. Такое обобщение является весьма мощным средством моделирования. Во-первых, с помощью обобщения между действующими лицами легко показать иерархию категорий пользователей системы, в частности, иерархию прав доступа к выполняемым функциям и хранимым данным. Например, мы можем предположить, что среди пользователей информационной системы отдела кадров имеется категория пользователей (назовем ее высшее руководство), которым разрешен доступ к любым данным и к любым операциям. Этот предположение можно отразить в модели системы так, как показано на рисунке 2.6.  Рисунок 2.6. Иерархия категорий пользователей информационной системы отдела кадров Во-вторых, действующее лицо, будучи классификатором, может быть абстрактным классификатором, то есть таким классификатором, который не может иметь непосредственных экземпляров. Введение абстрактных действующих лиц позволяет без потери информации сократить количество непосредственных ассоциаций в модели, сделав ее более лаконичной, а значит более наглядной и полезной. Например, в информационной системе отдела кадров полезно предусмотреть вариант использования, при котором данные не меняются, а только просматриваются пользователем. Если мы проектируем систему отдела кадров для обычной организации, а не для государственной секретной службы, то разумно предположить, что просматривать данные могут все категории пользователей. В этом случае можно ввести новый вариант использования и установить ассоциации со всеми действующими лицами, а можно поступить так, как показано на рисунке 2.7.  Рисунок 2.7. Абстрактное действующее лицо в информационной системе отдела кадров Обобщение между вариантами использования показывает, что один вариант использования является частным случаем (подмножеством множества сценариев) другого варианта использования. Обобщающий вариант использования, будучи классификатором, может быть абстрактным классификатором. Например, такой важный для сотрудника вариант использования, как увольнение, на самом деле является абстракцией: в каждом конкретном случае имеет место ровно один из возможных частных случаев увольнения, которые все приводят к одному и тому же результату с точки зрения менеджера персонала, но весьма различны с точки зрения сотрудника. Допустим, что в нашей информационной системы отдела кадров предусмотрены два типа увольнения: увольнение по инициативе администрации и увольнение по собственному желанию. Данное обстоятельство можно отразить в модели так, как показано на рисунке 2.8.  Рисунок 2.8. Обобщение между вариантами использования в информационной системе отдела кадров Зависимость между вариантами использования показывает, что один вариант использования зависит от другого варианта использования. В UML имеются два стандартных стереотипа зависимости между вариантами использования, которые в некотором смысле двойственны друг другу: include — показывает, что сценарий независимого варианта использования включает в себя в качестве подпоследовательности действий сценарий зависимого варианта использования; extend — показывает, что в сценарий зависимого варианта использования может быть в определенном месте вставлен в качестве подпоследовательности действий сценарий независимого варианта использования. Объясним тонкости семантики этих отношений в первом разделе следующего параграфа, а здесь ограничимся примерами. Рассмотрим еще раз вариант использования увольнение сотрудника (один из самых сложных в реальных системах управления персоналом). Известно, что при увольнении сотрудника следует в целях информационной безопасности удалить (или заблокировать) учетную запись пользователя в локальной сети организации. Причем эта последовательность действий должны быть выполнена в любом сценарии увольнения. С другой стороны, при выполнении определенных условий, при увольнении иногда выплачивается некоторая денежная компенсация (за неиспользованный отпуск, выходное пособие при сокращении и т. д.). Все это примеры последовательностей действий (т. е. вариантов использования), которые вполне могут быть востребованы как при увольнении, так и помимо него. Отношения зависимости между всеми этими вариантами использования могут быть отражены на диаграмме использования, например, так, как показано на рисунке 2.9  Рисунок 2.9. Зависимости между вариантами использования в информационной системе отдела кадров 2.3 Реализация вариантов использования Представление использования, если оно тщательно продумано и детально прорисовано, является формой технического задания, содержащей достаточно информации для дальнейшего проектирования и реализации любым другим методом. Может статься, что в коллективах программистов, в совершенстве владеющих какой-либо другой методикой проектирования и реализации, такое ограниченное использование UML окажется вполне оправданным. Однако, UML содержит средства не только для моделирования использования, но и для поддержки всех остальных фаз процесса разработки, и эти средства по меньшей мере не хуже альтернативных. Рассмотрим возможные пути перехода от моделирования использования к других видам моделирования. Действующие лица находятся вне системы — с ними ничего делать не нужно. Можно сказать, что действующие лица уже выполнили свою задачу, просто появившись в модели системы. Таким образом, переход от моделирования использования к другим видам моделирования состоит в уточнении, детализации и конкретизации вариантов использования. В представлении использования мы показали, что делает система, теперь нужно определить, как это делается. Это обычно называется реализацией вариантов использования. Исторически самый заслуженный и до сих пор один из самых полярных способов: составить текстовое описание типичного сценария варианта использования. Рассмотрим следующий ниже текст в качестве примера. Увольнение по собственному желанию Сотрудник пишет заявление Начальник подписывает заявление Если есть неиспользованный отпуск, то бухгалтерия рассчитывает компенсацию Бухгалтерия рассчитывает выходное пособие Системный администратор удаляет учетную запись Менеджер штатного расписания обновляет базу данных При более внимательном прочтении неясно, например, как должна вести себя система, если на шаге 2 начальник НЕ подписывает заявление. Из текста сценария не только не ясен ответ, но, хуже того, при невнимательном чтении можно и не заметить, что есть вопрос. Текстовые описания сценариев всем хороши: просты, всем понятны, легко и быстро составляются. Плохи они тем, что могут быть неполны и неточны, и эти недостатки незаметны. Наиболее часто используемый метод описания множества последовательностей действий состоит в указании алгоритма. Чаще всего алгоритмы указывают с помощью программ — текстов на некотором языке. Если программа предназначена для выполнения компьютером, то она должна быть записана на сугубо формальном (и на сегодняшний день довольно примитивном) языке, который называют в этом случае языком программирования. Если же программа предназначена исключительно для чтения и, может быть, выполнения человеком, то можно применить менее формальный (и более удобный) язык, который в этом случае обычно называют псевдокодом. Обычно в псевдокод включают смесь общеизвестных ключевых слов языков программирования и неформальные выражения на естественном языке, обозначающие выполняемые действия. Первый способ реализации варианта использования — записать алгоритм на псевдокоде. Этот способ хорош тем, что понятен, привычен и доступен любому. Однако в настоящее время вряд ли можно рекомендовать такой способ реализации, как основной, по следующим причинам. Реализация на псевдокоде плохо согласуется с современной парадигмой объектно-ориентированного программирования. При использовании псевдокода теряются все преимущества использования UML: наглядная визуализация с помощью картинки, строгость и точность языка проектирования и реализации, поддержка распространенными инструментальными средствами. Решения на псевдокоде практически невозможно использовать повторно. Тем не менее, рассмотрим пример реализации вариантов использования на псевдокоде (Рисунок 2.10).  Рисунок 2.10. Реализация вариантов использования при помощи программы на псевдокоде Увольнение по собственному желанию запускается по инициативе сотрудника. Увольнение по инициативе администрации начинается с приказа об увольнении. В этих текстах использовано ключевое слово include, отражающее наличие зависимостей с таким стереотипом в модели. А именно, это означает, что в этом месте в текст псевдокода для данного варианта использования нужно включить текст псевдокода для варианта использования DeleteAccount. Вариант использования PayCompensation запускается, если есть условия для выплаты компенсаций. При этом основные варианты использования не должны знать, каковы эти условия и как рассчитывается компенсация — за это отвечает вариант использования PayCompensation. Зависимость со стереотипом «extend» означает, что псевдокод варианта использования PayCompensation должен быть включен в текст основных вариантов использования. При этом вариант использования PayCompensation должен знать, в какое место ему нужно включиться. Для этого в основных вариантах использования определена точка расширения — а по сути просто метка в программе. Этот пример в достаточной мере объясняет сходство и различие между зависимостями со стереотипом include и extend. В обоих случаях речь о включении текста одной программы внутрь текста другой программы. Различие состоит в том, где хранится информация о включении. В случае стереотипа «include» включающая программа знает имя включаемой, а включаемая программа не обязана знать, что ее куда-то включают. В случае стереотипа «extend» наоборот, включаемая программа знает имя включающей, а включающая программа не обязана знать, что в нее что-то включают. Поскольку включающая программа знает свою структуру, то при использовании стереотипа «include» ей не нужно никакой дополнительной информации о месте включения. Напротив, поскольку включаемая программа не знает структуры включающей программы, то при использовании стереотипа «extend» включаемой программе нужна информация о месте включения — имя точки расширения, то есть метки в тексте включающей программы. Третий способ реализации варианта использования — описать алгоритм с помощью диаграммы деятельности. С одной стороны, диаграмма деятельности — это полноценная диаграмма UML, с другой стороны, диаграмма деятельности немногим отличается от блок-схемы (а тем самым и от псевдокода). Таким образом, реализация варианта использования диаграммой деятельности является компромиссным способом ведения разработки — в сущности, это проектирование сверху вниз в терминах и обозначениях UML. Например, в информационной системе отдела кадров прием сотрудника может быть организован так, как показано на рисунке 2.11. С одной стороны, вместо одной сущности, подлежащей реализации (вариант использования HirePerson) появилось пять новых: три сторожевых условия и две деятельности, которые в свою очередь теперь нуждаются в реализации. С другой стороны, каждая из этих новых сущностей кажется более простой и понятной, а значит быстрее и надежнее реализуемой. Кроме того, эту диаграмму можно показать заказчику, чтобы проверить, действительно ли проектируемая нами логика работы системы соответствует тому бизнес-процессу, который существует в реальности. Применение диаграмм активности для реализации вариантов использования не слишком приближает к появлению целевого артефакта — программного кода, однако может привести к более глубокому пониманию существа задачи и даже открыть неожиданные возможности улучшения приложения, которые было трудно усмотреть в первоначальной постановке задачи.  Рисунок 2.11. Реализация варианта использования приема сотрудника информационной системы отдела кадров при помощи диаграммы деятельности Например, рассматривая схему процесса на рисунке 2.11, мы видим, что процесс может иметь три исхода. Нормальное завершение, которое предполагает обязательное выполнение деятельности FillPosition. Резонно предположить, что при выполнении этой деятельности в базу данных будет записана какая-то информация, что, несомненно, является значимым для пользователя результатом. Исключительная ситуация, возникающая в том случае, когда процесс не может быть нормально завершен (мы хотели принять человека на работу, и он был согласен, а текущее состояние штатного расписание не позволило этого сделать). Факт возникновения такой ситуации, хотя формально и не является значимым результатом для менеджера персонала, на самом деле может быть весьма важен для высшего руководства или менеджера штатного расписания. Завершение процесса без достижения какого-либо видимого результата. Например, менеджер персонала сделал кандидату какие-то предложения, но ни одно из них кандидата не устроило, после чего они расстались, как будто ничего и не было. Этот простой анализ наталкивает на следующие соображения. Вариант использования должен доставлять значимый результат, значит, если результата нет, то что-то спроектировано не так, как нужно. Действительно, все известные нам практические информационные системы отдела кадров обязательно накапливают статистическую информацию о всех проведенных кадровых операциях. Такая статистика совершенно необходима для так называемого анализа движения кадров — важной составляющей процесса управления организацией. Однако далеко не все системы позволяют учитывать и не проведенные операции. Между тем, учет этой информации, например, учет причин, по которым кандидаты не принимают предложенной работы или, наоборот, причин, по которым организации отвергают кандидатов, может быть весьма полезен для исследования рынка труда и формирования кадровой политики организации. Немного подумав над этой проблемой (или посоветовавшись с заказчиком), мы можем усовершенствовать нашу диаграмму, например так, как показано на рисунке 2.12.  Рисунок 2.12. Усовершенствованная реализация варианта использования приема сотрудника информационной системы отдела кадров Вот теперь (формально) все хорошо: информация не теряется. Более того, имеет смысл вернуться к представлению использования и посмотреть, не нужно ли включить в модель новые варианты использования (может быть, как низкоприоритетные и подлежащие реализации в последующих версиях системы). Так реализация вариантов использования может приводить к изменению и усовершенствованию самих вариантов использования. Четвертый из основных способов реализации варианта использования — создать диаграмму взаимодействия (в форме диаграммы кооперации или диаграммы последовательности), которая описывает сценарий данного варианта использования. Этот способ в наибольшей степени соответствует идеологии UML и рекомендуется авторами языка как основной и предпочтительный. Рассмотрим основные достоинства и недостатки реализации варианта использования диаграммой взаимодействия. Начнем с положительного. На диаграмме взаимодействия представлено взаимодействие объектов, т. е. экземпляров некоторых классов. Тем самым построение такой диаграммы с необходимостью приводит к выявлению некоторых классов, которые должны существовать в модели и некоторых операций этих классов (а именно тех, которые появятся в форме сообщений типа вызова операции на диаграмме взаимодействия). Более того, поскольку сообщения передаются вдоль связей (экземпляров ассоциаций), оказываются выявленными и некоторые необходимые ассоциации. Таким образом, реализация варианта использования диаграммой взаимодействия обеспечивает органичный переход от моделирования использования к моделированию структуры и поведения. При составлении диаграмм взаимодействия для нескольких вариантов использования могут быть задействованы одни и те же классы, играющие разные роли в различных кооперациях . Одинаковое поведение и структура, проявляющиеся в разных вариантах использования, оказываются реализованными одним классом. Такой стиль моделирования полностью соответствует объектно-ориентированному подходу и обеспечивает концептуальную целостность проектируемой системы. При реализации вариантов использования диаграммами взаимодействия на ранних этапах моделирования появляются сопутствующие фрагменты диаграмм классов (и, может быть, диаграмм реализации). Эти диаграммы гораздо ближе к целевому артефакту — программному коду — нежели диаграммы использования и даже диаграммы деятельности. Все инструменты поддерживают генерацию кода по диаграммам классов, а некоторые — и по диаграммам взаимодействия. Таким образом, появляется возможность автоматизированного построения прототипов (версий системы, обеспечивающих функциональность частично), что полностью соответствует идеологии инкрементальной разработки. Однако у диаграмм взаимодействия UML есть существенное ограничение. В целом эти диаграммы формулируются на уровне объектов, а потому позволяют реализовать только отдельный сценарий (экземпляр варианта использования). Другими словами, диаграммы взаимодействия позволяют описать протокол выполнения алгоритма, но не сам алгоритм, они не являются универсальной моделью вычислимости. Возникает вопрос: насколько существенным и обременительным оказывается это ограничение при практическом моделировании? Если алгоритм варианта использования линеен (просто последовательность действий, без ветвлений и циклов), то проблемы нет — линейные алгоритмы суть протоколы выполнения. Для ветвлений и циклов диаграммы взаимодействия содержат некоторые (весьма ограниченные) средства моделирования. Иногда этих средств может оказаться достаточно. Что же делать, если все-таки никак не удается построить исчерпывающую диаграмму взаимодействия для варианта использования? В этом случае рекомендуется применять следующие методы. Во-первых, реализовать вариант использования несколькими диаграммами взаимодействия. Каждая диаграмма описывает отдельный сценарий, а все вместе они дают достаточное представление об алгоритме варианта использования. Во-вторых, можно пересмотреть представление использования таким образом, чтобы исключить трудно реализуемые варианты использования. Например, с помощью обобщения выделить частные случаи вариантов использования, которые описывают более однородные множества сценариев и легче реализуются диаграммами взаимодействия. Обычно итеративно применяет оба приема, пока не будет достигнут удовлетворительный результат. Попробуем проиллюстрировать сказанное на примере реализации диаграммами взаимодействия варианта использования прием сотрудника на работу информационной системы отдела кадров. Сначала рассмотрим типовой сценарий, когда прием проходит безо всяких осложнений: есть вакантное рабочее место и кандидат готов его занять. Диаграмма последовательности для такого сценария приведена на рисунке 2.13.  Рисунок 2.13. Диаграмма последовательности для типового сценария приема сотрудника информационной системы отдела кадров На приведенной диаграмме (Рисунок 2.13) последовательность посылаемых сообщений примерно соответствует последовательности действий на диаграмме деятельности (Рисунок 2.12) в том случае, когда поток управления проходит по диаграмме сверху вниз один раз. Таким образом, диаграмма 2.13 до некоторой степени определяет типовой сценарий варианта использования HirePerson. Однако, помимо определения последовательности выполняемых действий диаграмма 2.13 содержит и другую информацию, существенную для дальнейшего проектирования. А именно, построив такую диаграмму, мы постулировали существование в системе некоторых классов (возможно, еще не всех), объекты которых должны взаимодействовать для обеспечения требуемого поведения моделируемого варианта использования. Действующее лицо PersonnelManager уже было определено при моделировании использования, здесь же в нашей модели появились новые сущности: класс HireForm, ответственный за интерфейс, необходимый для выполнения варианта использования прием сотрудника; класс Person, ответственный за хранение данных о конкретном человеке; класс Position, ответственный за хранение данных и выполнение операций с конкретной должностью. На этой стадии моделирования список операций указанных классов еще далеко не полон (а атрибуты пока совсем отсутствуют), однако сам факт появления классов в модели является важным архитектурным решением, существенно приближающим нас к реализации системы. Заметим, что диаграмма 2.13 семантически не полна: она не отражает все сценарии варианта использования, которые предусматриваются, например, диаграммой 2.12. Как уже было сказано, в этом случае можно составить дополнительные диаграммы взаимодействия, реализующие альтернативные сценарии варианта использования. Например, на рисунке 2.14 показан сценарий приема сотрудника, соответствующий исключительной ситуации, когда нет вакантных должностей. На этот раз мы представим сценарий в форме диаграммы кооперации (коммуникации).  Рисунок 2.14. Диаграмма кооперации для исключительной ситуации при приеме сотрудника информационной системы отдела кадров Построение этой диаграммы выявило необходимость включения в модель (по крайней мере) еще одного класса — ExceptionsHandier, который несет ответственность за обработку исключительных ситуаций. Конечно, тот способ решения проблемы, который мы предлагаем на диаграмме 2.14 далеко не единственный, и, может быть, не самый лучший из известных. Дело в том, что построение диаграммы взаимодействия выявило сам факт необходимости предусмотреть обработку исключительных ситуаций в системе. Если бы мы не построили диаграмму взаимодействия для альтернативного сценария, мы могли бы упустить из виду это обстоятельство и, тем самым, совершить грубую проектную ошибку. Авторы UML рекомендуют на этапе перехода от моделирования использования к более детальному проектированию строить диаграммы взаимодействия для всех сценариев вариантов использования (на крайний случай для всех вариантов использования, выбранных для реализации в первой версии системы). После того, как диаграммы взаимодействия построены, нужно сопоставить набор выявленных классов с неформальным словарем предметной области. Если наблюдается значительное совпадение, скажем, если большинство понятий словаря предметной области оказалось среди классов, выявленных при реализации вариантов использования, то это означает, что мы на правильном пути и можно смело переходить к более детальному проектированию. Если же пересечение словаря и множества выделенных классов незначительно, скажем, если оно составляет менее половины объема словаря, то нужно приостановить проектирование и вернуться на фазу анализа (привлечь сторонних экспертов в предметной области, заново выполнить моделирование использования, проконсультироваться с заказчиком и т. д.). Таким образом, реализация вариантов использования диаграммами взаимодействия является наиболее трудоемким и сложным методом, но этот метод лучше всего согласован с объектно-ориентированным подходом и в наибольшей мере приближает к конечной цели. 1Например, в таком стиле: CurRecNum означает "номер текущей записи". |