«Учебно-методическое пособие по дисциплине Анализ и проектирование на UML Новиков Ф.А., канд. физ.-мат. наук, доцент кафедры Технологии программирования Санкт-Петербург 2007 Оглавление  Введение 5  Тема 1. Введение в UML ...»

Санкт-Петербургский государственный университет информационных

технологий, механики и оптики

Учебно-методическое пособие

по дисциплине

«Анализ и проектирование на UML»

Новиков Ф.А.,

канд. физ.-мат. наук, доцент кафедры «Технологии программирования»

Санкт-Петербург

2007

Оглавление 

Введение 5  Тема 1. Введение в UML 6  1.1. Что такое UML? 6  1.1.1. UML — это язык 6  1.1.2. UML — это язык моделирования 8  1.1.3. UML — это унифицированный язык моделирования 13  1.2. 1.2. Назначение UML 15  1.2.1. Спецификация 15  1.2.2. Визуализация 17  1.2.3. Проектирование 18  1.2.4. Документирование 19  1.2.5. Чем НЕ является UML 20  1.2.6. Способы использования UML 21  1.2.7. Инструментальная поддержка 22  1.3. Определение UML 23  1.3.1. Определения искусственных языков 23  1.3.2. Метод определения UML 24  1.3.3. Структура стандарта UML 26  1.3.4. Терминология и нотация 27  1.4. Модель и ее элементы 28  1.4.1. Сущности 29  1.4.2. Отношения 32  1.5. Диаграммы 33  1.5.1. Классификация диаграмм 34  1.5.2. Диаграмма использования 36  1.5.3. Диаграмма классов 36  1.5.4. Диаграмма объектов 37  1.5.5. Диаграмма состояний 38  1.5.6. Диаграмма деятельности 38  1.5.7. Диаграмма последовательности 39  1.5.8. Диаграмма кооперации 40  1.5.9. Диаграмма компонентов 41  1.5.10. Диаграмма размещения 42  1.6. Представления 42  1.6.1. Пять представлений 43  1.6.2. Восемь представлений 44  1.6.3. Три представления 44  1.7. Общие механизмы 46  1.7.1. Внутреннее представление модели 46  1.7.2. Дополнения и украшения 48  1.7.3. Подразделения 48  1.7.4. Механизмы расширения 49  1.8. Общие свойства модели 52  1.8.1. Правильность 52  1.8.2. Непротиворечивость 52  1.8.3. Полнота 53  1.8.4. Вариации семантики 54  1.9. Выводы 54  Тема 2. Моделирование использования 55  2.1. Значение моделирования использования 55  2.1.1. Сквозной пример 55  2.1.2. Подходы к проектированию 56  2.1.3. Преимущества моделирования использования 60  2.2. Диаграммы использования 61  2.2.1. Действующие лица 62  2.2.2. Варианты использования 65  2.2.3. Примечания 67  2.2.4. Отношения на диаграммах использования 68  2.3. Реализация вариантов использования 72  2.3.1. Текстовые описания 73  2.3.2. Реализация программой на псевдокоде 73  2.3.3. Реализация диаграммами деятельности 76  2.3.4. Реализация диаграммами взаимодействия 78  2.4. Выводы 82  Тема 3. Моделирование структуры 83  3.1. Объектно-ориентированное моделирование структуры 83  3.1.1. Объектно-ориентированное программирование 84  3.1.2. Назначение структурного моделирования 89  3.1.3. Классификаторы 93  3.1.4. Идентификация классов 96  3.2. Диаграммы классов 98  3.2.1. Классы 99  3.2.2. Атрибуты 101  3.2.3. Операции 102  3.2.4. Зависимости 106  3.2.5. Обобщение 107  3.2.6. Ассоциации 110  3.2.7. Интерфейсы и роли 123  4.1. Объектно-ориентированное моделирование поведение 141  4.5.1. Взаимодействие последовательных процессов 228  4.5.2. Параллельные состояния и составные переходы 234  4.5.3. Развилки, соединения и обусловленные потоки управления 246  4.5.4. Параллелизм на диаграммах взаимодействия 250  5.2.2. Повышение продуктивности программирования 275  Учебное пособие «Анализ и проектирование на UML» содержит полное описание унифицированного языка моделирования UML и набор рекомендаций по применению языка для анали и проектирования программных систем.

Как опытному преподавателю, автору твердо известно, что существуют три уровня понимания обучающимся нового предмета, которые характеризуются следующими признаками:

1. возникает приятное чувство понимания;

2. может повторить своими словами;

3. видит ошибки.

Данная книга написана на третьем уровне и адресована обучающимся, ориентированным на третий уровень. Многие неловкости, неудобства и даже ошибки UML обсуждаются в этой книге и предлагаются авторский подход к их исправлению. Не исключено, что авторские предложения также содержат новые, более тяжелые ошибки.

• Что обозначает аббревиатура UML?

• Что послужило причиной возникновения UML?

• Для чего используют UML на практике?

• Из каких элементов состоит модель?

• Как комбинируются элементы модели?

• Что делать, если готовых элементов не хватает?

• Какова общая структура модели?

Предметом этой книги является UML в целом. Прежде чем обсуждать что-либо «в целом», резонно сначала точно определить, о чем идет речь в частности.

Обсуждаемый предмет обозначается идентификатором UML, который является аббревиатурой полного названия Unified Modeling Language. Правильный перевод этого названия на русский язык — унифицированный язык моделирования. Таким образом, обсуждаемый предмет характеризуется тремя словами, каждое из которых является точным термином.

Главным словом в этом сочетании является слово "язык".

Язык — это знаковая система для хранения и передачи информации.

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

Филологи, наверное, смогут назвать еще дюжину различных характеристик:

нормативный и ненормативный язык, живой и мертвый, синтетический и аналитический и т. д.

Что определяют определения?

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

определений достаточно, чтобы перейти к примерам — самому надежному и доходчивому способу аргументации.

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

ЗАМЕЧАНИЕ

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

Так вот, UML можно охарактеризовать как формальный искусственный язык, хотя и не в такой степени, как многие распространенные языки программирования.

Признаком искусственности служит наличие трех общепризнанных авторов (рис. 1.1):

Рис. 1.1.Авторы UML.

В то же время в формирование языка внесли вклад многие теоретики и разработчики, имя которым легион. Языкотворческая практика применительно к UML непрерывно продолжается (мы это обсудим позднее), что дает основание считать UML до некоторой степени естественным языком. Описание UML по большей части формальное, но содержит и явно неформальные составляющие.

Такие особенности UML как точки вариации семантики и стандартные механизмы расширения (см. раздел 1.7.4), заметно отличают UML от языков, которые, по общему мнению, являются образцами формализма.

ЗАМЕЧАНИЕ

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

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

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

• Синтаксис то есть определение правил конструирования выражений • Семантика, то есть определение правил приписывания смысла выражениям языка.

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

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

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

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

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

ЗАМЕЧАНИЕ

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

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

Чего, к сожалению, не случается с программистами.

Заказчик хочет не это Рис. 1.2. Жизненный цикл приложения

ЗАМЕЧАНИЕ

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

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

ЗАМЕЧАНИЕ

Был даже придуман специальный термин — продолжающаяся разработка, который включает в себя как разработку в обычном смысле, так и модификацию программы (и другие действия) в процессе эксплуатации. Для краткости мы предлагаем вам понимать термин "процесс разработки" в широком смысле, включая в него все действия, которые производятся с приложением – проектирование, кодирование, отладка, внедрение и т. д.

В результате понятия жизненного цикла и процесса разработки можно считать равнообъемными, даже можно сказать, что это две стороны одного понятия. Когда мы говорим "жизненный цикл", мы смотрим на предмет как бы с точки зрения программы, которая пассивно переживает одно состояние за другим, а когда мы говорим "процесс разработки", мы смотрим на тот же самый предмет с точки зрения программиста, который активно выполняет одно действие за другим.

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

ЗАМЕЧАНИЕ

Здесь слово "модель" используется в обычном смысле – как абстрактное описание некоторого явления, в котором существенные закономерности учтены, а несущественные детали опущены. Не следует путать это с моделями UML, о которых идет речь в других местах книги.

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

Мы используем модель процесса разработки приложений, основанную на понятиях фаза и веха. Большинство современных моделей процесса разработки также основаны на этих понятиях.

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

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

вытянуты в линейную последовательность. Т.е. некоторые фазы могут полностью или частично перекрываться во времени.

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

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

Рис. 1.3. Итеративный процесс разработки Оставим пока в стороне детальное обсуждение рис. 1.2 и 1.3 и остановимся только на одном моменте: на наличии состояния в жизненном цикле и фазы в процессе разработки, которые у нас названы одним словом "проектирование".

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

Но есть одно различие, которое сразу бросается в глаза. В архитектуре и строительстве очень широко используются чертежи. Чертежи разные — рисунки архитектора с общим видом будущего здания, детальные строительные чертежи, по которым ведется строительство, различные вспомогательные схемы инженерных коммуникаций и др. Конечно, садовый домик5 можно построить без всяких чертежей, "на глазок", но с чертежами обычно получается все-таки лучше. Наверное, можно попробовать построить и трехэтажный дом, не пользуясь чертежами, хотя результат вряд ли будет надежным и красивым. Но высотный дом нельзя построить без тщательного предварительного проектирования, учета строительных норм и правил (СНИП) и составления огромного количества разнообразных чертежей.

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

"А где же чертеж будущего приложения?", то они даже не понимают вопроса. Если речь идет о приложении типа "садовый домик", то такой подход может сработать — помогут опыт и чутье. Но если нужно построить высотный дом? Без чертежей не обойтись! В солидном приложении деталей (функций, процедур, модулей, форм, элементов управления, операторов) не меньше, а больше, чем в высотном доме соотношение результативности: случай обрушения дома из-за ошибок проектирования — это ЧП, которое случается очень редко. Что же касается разработки приложений, то по данным некоторых авторов, свыше половины проектов по разработке оканчиваются неудачей: не доводятся до конца, прекращаются из-за перерасхода времени и средств, имеют неудовлетворительный результат и т.д. Анализ показывает, что в подавляющем большинстве случаев причина неудач кроется в плохом проектировании.

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

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

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

Другими словами, ощущается дефицит инженерно проработанных средств проектирования приложений. Это обстоятельство создает дополнительные трудности для разработчиков, но не может служить оправданием для безответственного "проскакивания" фазы В процессе проектирования что-то делается и в результате нечто получается. Если эта деятельность и форма результата регламентированы определенным образом, то им уместно дать название. Так сложилось, что результат проектирования (и анализа), оформленный средствами определенного языка принято называть моделью.6 Деятельность по составлению моделей естественно назвать моделированием. Именно в этом смысле UML является языком моделирования.

Modeling vs. simulation Как уже отмечалось, слово "моделирование" многозначно. В частности, английские слова modeling и simulation оба переводятся как моделирование, хотя означают разные вещи. В первом случае речь идет о составлении модели, которая используется только для описания подразумевается составление модели, которая может быть моделируемом объекте или явлении. Во втором случае обычно добавляется уточняющее прилагательное: численное, математическое и др. UML является языком моделирования в первом смысле, хотя автору известны некоторые успешные попытки использования UML и во втором смысле. Прочие вариации смысла слова моделирование оставлены за рамками книги. В частности, названия профессий:

модельер, модельщик и моделист не имеют отношения к предмету. Тот, кто составляет модели UML по-русски никак не называется (пока).

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

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

Что вполне согласуется с наиболее общим смыслом слова модель — абстрактное описание чеголибо.

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

Объектно-ориентированное программирование программирования. Центральной идеей ООП является инкапсуляция, т. е. структурирование программы на модули особого вида, объединяющего данные и процедуры их обработки, причем внутренние данные модуля могут быть обработаны только предусмотренными для этого процедурами. В разных вариациях ООП этот модуль называют поразному: класс, абстрактный тип данных, кластер и др. Каждый такой класс имеет внутреннюю часть, называемую реализацией (или представлением), и внешнюю часть, называемую интерфейсом. Доступ к реализации возможен только через интерфейс. Обычно в интерфейсе различают свойства (которые синтаксически выглядят как переменные) и методы (которые синтаксически выглядят как процедуры или функции). Класс может иметь методы, называемые конструкторами и деструкторами, позволяющие во время выполнения программы динамически порождать и уничтожать экземпляры класса. Экземпляры одного класса сходны между собой (например, наследуют методы класса), но имеют различия (например, имеют разные значения свойств). Классы и экземпляры классов называют объектами, откуда и происходит название объектно-ориентированное программирование.

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

Если попытаться проследить историю возникновения и развития элементов UML, как на уровне основополагающих идей, так и на уровне технических деталей, то пришлось бы назвать сотни имен и десятки организаций. Мы не будем этого делать, и не только из экономии места, но и потому, что история развития UML отнюдь не завершена — язык постоянно совершенствуется, обогащается и расширяется.7 Мы полагаем достаточным воспроизвести на рис. 1.4. картинку, которой авторы UML обычно иллюстрируют историю своего детища.

Вы тоже можете принять в этом участие.

UML 2.0 8.03-9. Конкурс 1.2000-7. Рис. 1.4. История развития UML

ЗАМЕЧАНИЕ

UML — это унифицированный язык моделирования, но никак не единый и не универсальный (мы видели такие ошибочные толкования первой буквы U в некоторых источниках). Далее мы еще не раз вернемся к этому вопросу.

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

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

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

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

Спецификация — это декларативное описание того, как нечто устроено или работает.

Необходимо принимать во внимание три толкования спецификаций.

• То, которое имеет в виду действующее лицо, являющееся источником спецификации (например, заказчик).

• То, которое имеет в виду действующее лицо, являющееся потребителем спецификации (например, разработчик).

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

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

Математикам известны средства такого рода, например, язык исчисления предикатов. Действительно, если задать с помощью логического выражения на языке исчисления предикатов условие, которому должны удовлетворять входные данные приложения (так называемое предусловие) и условие, которому должны удовлетворять выходные данные приложения (постусловие), то не остается места для неоднозначности в определении того, делает приложение то, что нужно, или нет. Как говорят математики "не нужно спорить, давайте Например, предусловие a0 & b2–4ac>0 вместе с постусловием ax2+bx+c=0 является исчерпывающим ТЗ на разработку приложения "Решение квадратного уравнения" (входные данные a, b, c, выходное Если для рассматриваемой предметной области действительно существует строгая математическая модель, то формальная спецификация является наиболее предпочтительной. Именно такие спецификации используют при разработке приложений в инженерных К сожалению, в большинстве предметных областей сколько-нибудь проработанных математических моделей нет, степень формализации очень низка, и навыки использования формальных математических методов не очень распространены. При попытке применить формальные методы объем спецификации оказывается намного больше объема самого специфицируемого приложения, а разработка спецификаций оказывается гораздо более трудоемкой (и требующей более высокой квалификации!), чем разработка приложения.

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

Известная поговорка гласит, что лучше один раз увидеть, чем сто раз услышать.

Мы добавим: тем паче тысячу раз прочитать. Особенности человеческого восприятия таковы, что текст с картинками воспринимается легче, чем голый текст.

А картинки с текстом (это называется "комиксы") — еще легче. Модели UML допускают представление в форме картинок, причем эти картинки наглядны, интуитивно понятны, практически однозначно интерпретируются и легко составляются. Фактически, развитие и детализация этого тезиса составляет большую часть содержания остальной части книги. Мы не будем забегать вперед, и просто приведем пример без всяких объяснений (рис. 1.4). Разве что-нибудь непонятно?

Нужно еще указать, что все числа вещественные и задать точность, с которой должен быть определены корни, но это уже детали.

Рис. 1.4. Жизненный цикл работника на предприятии Таким образом, второе по важности назначение UML состоит в том, чтобы служить адекватным средством коммуникации между людьми. Разумеется, наглядность визуализации моделей UML имеет значение, только если они должны составляться или восприниматься человеком — это назначение UML не имеет отношения к компьютерам.

ЗАМЕЧАНИЕ

Графическое представление модели UML не тождественно самой модели. Это важное обстоятельство часто упускается из виду при первом знакомстве с UML.

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

Причина не в том, что никто не удосужился этим заняться, а в том, что это очень трудная задача.

Автоматический синтез программ Синтезом программ называется автоматическая генерация программы по некоторой спецификации. В зависимости от метода спецификации автоматический синтез программ подразделяют на несколько Это называется по-английски reverse engineering и обычно переводится на русский как "обратное проектирование". Нам этот перевод категорически не нравится: какое же это проектирование и почему оно обратное? Но другого термина мы не знаем, а потому вовсе не будем его употреблять.

Если спецификация задана в виде формальных логических условий, связывающих входные и выходные данные, то говорят о дедуктивном синтезе программ. Например, если спецификация задана с помощью предусловия (см. врезку "о формальных спецификациях") P(x) и постусловия Q(x,y), связывающего входные данные x с выходными данными y, то из конструктивного доказательства теоремы существования x(P(x)yQ(x,y)) может быть автоматически извлечена программа вычисления y по x. К сожалению, задача автоматического доказательства теорем во всех смыслах трудная, так что тот факт, автоматический синтез программ сводится к автоматическому доказательству теорем не слишком обнадеживает.

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

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

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

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

ЗАМЕЧАНИЕ

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

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

Не следует думать, что UML — это панацея от всех детских11 болезней программирования. Для ясного понимания назначения и области применения UML полезно сопоставить UML с другими родственными явлениями.

Во-первых, UML не является языком программирования (хотя генерация кода не возбраняется, см. предыдущий раздел). Дело не в том, что UML язык графический, а подавляющее большинство практических языков программирования являются линейными текстовыми языками. Гораздо важнее то, что для моделей UML не определена операционная семантика, то есть не определен способ выполнения моделей на компьютере. Это сделано вполне сознательно, в противном случае UML оказался бы зависимым от некоторой модели вычислимости, уровень абстрактности его концепций пришлось бы существенно снизить и он не отвечал бы своему основному назначению: служить средством спецификации приложений и других систем на любом уровне абстракции и в различных предметных областях.

Во-вторых, UML не является спецификацией инструмента (хотя инструменты подразумеваются и имеются, например, Together, Rational Rose, Visual Paradigm, Microsoft Visio и др.). В последние годы в компьютерной индустрии широкое распространение получили комплексные системы разработки приложений, которые обычно называют CASE12 средствами. В таких системах разработки предпринимаются попытки согласованным образом поддержать и обеспечить все фазы процесса разработки приложений, а не только фазы кодирования и отладки, традиционно поддерживаемые обычными системами программирования.

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

ЗАМЕЧАНИЕ

Все без исключения CASE средства, появившиеся на рынке в последние год-два так или иначе поддерживают UML.

Специальное приложение XML.

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

CASE — аббревиатура Computer Aided Software Engineering.

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

ЗАМЕЧАНИЕ

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

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

• Рисование картинок (+3). Графические средства UML можно и нужно использовать безотносительно ко всему остальному. Даже рисование диаграмм карандашом на бумаге позволяет упорядочить мысли и зафиксировать для себя существенную информацию о моделируемом приложении или иной системе. Мы ставим такое использование UML на первое место по важности.

• Обмен информацией (+2). Сообщество людей, применяющих и понимающих UML стремительно растет. Если вы будете использовать UML, то вас будут понимать другие и вы будете понимать других с полувзгляда.

• Спецификация систем (+1). Это важнейший способ использования UML. В нашей оценочной шкале использование UML для спецификации не стоит на первом месте только потому, что, к сожалению, еще не во всех случаях UML оказывается абсолютно адекватным средством спецификации (примеры приведены в других местах книги). Но по мере развития языка все меньше будет оставаться случаев, в которых UML оставляет желать • Повторное использование архитектурных решений (0). Повторное использование ранее разработанных решений — ключ к повышению эффективности. Наше мнение по этому поводу изложено в главе 5. Однако, пока что модели UML повторно используются еще в ограниченных масштабах. Оценка 0 (золотая середина) означает: хорошо, но мало.

• Генерация кода (–1). В разделе 1.2.3 приведена достаточно подробная аргументация, объясняющая оценку –1. Генерировать код нужно и можно, но возможности имеющихся инструментов не стоит переоценивать.

• Имитационное моделирование (–2). Возможности построения моделей UML, из которых путем вычислительных экспериментов можно было бы извлекать информацию о моделируемом объекте, пока что уступают возможностям специализированных систем, сконструированных для этой • Верификация моделей (–3). Было бы замечательно, если бы по модели можно было бы делать формальные заключения об ее свойствах: модель непротиворечива, согласована, эффективна и т. п. Кое-что UML позволяет проверить, но, конечно, очень мало. Здесь уместно привести аналогию с традиционными системами программирования: они позволяют быстро и надежно избавиться от синтаксических ошибок, но с логическими ошибками дело обстоит гораздо хуже. Может быть, в будущем...

Рассмотрим, как соотносится сегодняшняя практика использования UML с декларированным выше назначением языка. По мнению автора, можно выделить три основных варианта использования UML (рис. 1.5).

Рис. 1.5. Инструментальная поддержка.

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

Вариант использования "Составление моделей" подразумевает создание и изменение модели системы в терминах тех элементов моделирования, которые предусматриваются метамоделью UML. Значимым результатом в этом случае является машинно-читаемый артефакт с описанием модели. Мы будем для краткости называть такой артефакт просто моделью, деятельность по составлению модели называть моделированием, а субъекта моделирования называть архитектором (потому что соответствующие существительные — модельщик, модельер — в русском языке уже заняты).

Вариант использования "Разработка приложений" подразумевает детальное моделирование, проектирование, реализацию и тестирование приложения в терминах UML. Значимым для пользователя результатом в этом случае является работающее приложение, которое может быть скомпилировано во входной язык конкретной системой программирования или сразу интерпретировано средой выполнения инструмента. Этот вариант использования наиболее сложен в реализации.

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

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

1.3.1. Определения искусственных языков История языков программирования насчитывает полвека и столько же продолжается развитие методов их определения. На этом пути были прорывы (определения Алгола 60, Алгола 68, Паскаля), были и неудачи (PL/1). От определения искусственного языка требуется, чтобы оно было:

Между тем, эти требования зачастую исключают друг другу.13 В некоторых случаях во главу угла ставится что-либо одно, но результат редко оканчивается удачей. Например, определение Алгола 68, где все было нацелено на формальную точность, явилось новым словом в методах определения языков и оказало большое влияние на развитие теории. В тоже время, это описание оказалось настолько непонятным рядовым пользователям, что отпугнуло их от потенциально многообещающей разработки. Другой пример: с целью "понятности" первые диалекты Кобола описывались совершенно неформально, в результате получалось плохо, потому что для достижения минимальной необходимой точности и полноты неформальное описание приходилось делать очень длинным, а потому непонятным.

Наиболее удачными оказались компромиссные решения, и авторы UML пошли именно по этому пути.

Автору однажды встретилось замечательное рекламное объявление: "мы обучаем иностранному языку быстро, качественно и недорого — любые два условия из трех по выбору заказчика".

В основу описания UML положен метод раскрутки, то есть использование определяемого языка для определения этого языка. А именно, основные конструкции UML формально определены с помощью UML. Конечно, с чего-то раскрутку нужно начать, и это описано в UML неформально, с помощью текстов на естественном (английском) языке.

ЗАМЕЧАНИЕ

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

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

В описании UML используются три языковых уровня.

• Мета-метамодель, то есть описание языка, на котором описана • Метамодель, то есть описание языка, на котором описываются модели.

• Модель, то есть описание самой моделируемой предметной области.

Это кажется нагромождением сущностей без нужды, но на самом деле только использование ученой приставки мета (от греческого, что означает "между", "после", "через") может быть несколько непривычным. Действительно, рассмотрим описание какого-либо из обычных языков программирования. Чтобы никого не обидеть, пусть этот язык называется X. Если описание хорошее, то в самом начале указывается язык (иногда его так и называют — метаязык), который используется для описания языка X. Например, приводится фраза такого типа: "синтаксис языка X описан с помощью контекстно-свободной грамматики, правила которой записаны в форме Бэкуса-Наура (БНФ), контекстные условия и семантика описаны на естественном языке". Если описание не очень хорошее, то такая фраза может и отсутствовать, но она все равно неявно подразумевается и от читателя требуется понять используемый метаязык по контексту. Далее с помощью метаязыка более или менее формально описываются конструкции языка X; все, что не удается описать формально, описывается на естественном языке (при этом зачастую вводится большое количество "новых" терминов и используются трудные для чтения канцеляризмы). Все это, как правило, сопровождается многочисленными конкретными примерами фрагментов текстов на языке X. Чтобы читатель не путался, где текст на языке X, а где текст на метаязыке, или где общее описание, а где конкретный пример, применяются различные полиграфические приемы:

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

Формальные грамматики Для описания своих языков программисты с успехом используют теорию формальных грамматик, разработанную Н. Хомским. Вкратце суть заключается в следующем. Рассматривается конечный алфавит A (множество символов) и язык над этим алфавитом. Здесь язык — это просто множество последовательностей символов алфавита (цепочек).

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

Для описания (бесконечного) множества цепочек Хомский предложил использовать формальную грамматику — конечное множество правил вида, где и конечные цепочки, составленные из символов алфавита A (которые называются терминальными символами) и из символов некоторого дополнительного алфавита N (эти символы принято называть нетерминальными). В левую часть правила (т. е. в цепочку ) обязательно должен входить хотя бы один нетерминальный символ. Среди всех нетерминальных символов выделяется один, который называется начальным символом (или аксиомой) грамматики.

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

Например, грамматика, которая имеет один нетерминальный символ S, два терминальных символа 0 и 1 и два правила S01 и S0S определяет (как говорят порождает) язык, состоящий из цепочек вида Разумеется, все это так просто, пока не поставлены разные каверзные вопросы. Всякий ли язык может быть определен таким способом? Если дана грамматика и конкретная терминальная цепочка, то как узнать, принадлежит она языку или нет? Однозначен ли процесс порождения цепочки? Зависят ли ответы на предыдущие вопросы от вида (формы) Но если основная идея ясна, то можно оставить эти (трудные) вопросы математикам и принять тот факт, что синтаксис подавляющего подклассом формальных грамматик, которые называются контекстносвободными (левая часть всех правил состоит из одного нетерминального символа). Для этого подкласса грамматик все вопросы связанные с распознаванием принадлежности цепочки языку (это называется синтаксическим анализом, или разбором) надежно Таким образом, основная идея описания UML вполне традиционна и согласуется с общепринятой практикой: мета-метамодель — это описание используемого формализма; метамодель — это и есть собственно описание языка (элементов моделирования); там, где формализм не срабатывает, на помощь приходит естественный язык и все это сопровождается примерами фрагментов моделей.

А если не описывается, или описывается нелегко, то всегда можно привлечь естественный язык и все, что нужно, досказать словами. В качестве примера возьмите любое описание популярного языка программирования: С++, Visual Basic, Java.

Весь текст описания UML каждой версии находится в свободно распространяемых документах, доступных по адресу http://www.omg.org. В таблице 1.2. перечислены основные документы входящие в комплект документации для текущей версии UML 2.1.1 (октябрь 2007).

Таблица 1.2. Структура описания UML UML Diagram interchange Отображение средств обмена диаграммами OCL Specifications Описание объектного языка ограничений OCL Без специальной предварительной подготовки читать в этих документах имеет смысл только вводные разделы, примерно соответствующие по задачам этой главе, и последние разделы, в которых собраны толкования основных терминов. Остальное предназначено не для ознакомительного чтения пользователями, а для скрупулезного изучения разработчиками инструментов моделирования. По замыслу авторов языка для пользователей должны быть написаны другие книги, и они написаны, как самими авторами, так и любителями UML. Один из примеров у вас в руках.

Самым важным является раздел описания семантики. Семантика описана следующим образом. Для определяемого элемента моделирования задается абстрактный синтаксис (в форме диаграммы классов UML) и указываются ограничения, которым должен удовлетворять описываемый элемент в форме выражений языка OCL. Все остальное, включая прагматику, описывается на естественном языке, который авторы называют "plain English".

Далее для кажого элемента моделирования, указывается как уже определенные элементы моделирования рекомендуется изображать в графическом виде. Фактически, этот раздел соответствует разделу описания синтаксиса для обычного языка программирования. Но UML не обычный язык, а графический! Пока что для описания синтаксиса графических языков не придумано столь же удобного механизма, как формальные грамматики, поэтому в этом разделе стандарта приведены довольно многословные описания в следующем стиле:

"Состояние автомата изображается прямоугольником со скругленными углами, внутри которого указывается имя состояния в виде строки текста, а также, возможно…" и так далее. К счастью, графический синтаксис UML довольно прост и тщательно продуман, так что, если вы отличаете окружность от квадрата, то разобраться не трудно.

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

ЗАМЕЧАНИЕ

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

Проблема терминологии является одной из самых болезненных в этой книге.

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

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

UML сравнительно молод (но уже моден), бум публикаций в отечественной литературе начался только сейчас (с опозданием на десять лет, как обычно), поэтому устоявшейся терминологической традиции пока нет. Хотелось бы использовать хорошие русские слова — "эктор" и "персистентный" решительно отметаются. Словарь в таких случаях бесполезен (хотя им многие пытаются пользоваться). Остается фантазировать, опираясь на вышедшие из печати труды коллег, отечественные программистские традиции и собственный опыт. Основной критерий, который использован нами при выборе переводов терминов: как можно точнее передать смысл исходного термина (но не звучание, не морфологию и не буквальное значение).

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

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

Поэтому в качестве основных графических элементов были выбраны такие, которые было бы легко использовать во всех случаях. Типов элементов нотации четыре:

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

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

Линии в UML, естественно, одномерные. Линии всегда присоединяются своими концами к фигурам или значкам, они не могут быть нарисованы сами по себе. Что значит "присоединяются" — формально определить довольно трудно, но неформально (а нотация UML не формальна) все совершенно ясно: линия должна быть нарисована так, чтобы любому нормальному человеку было ясно, присоединяется данная линия к данной фигуре, или нет. Форма линий произвольна:

это могут быть прямые, ломаные, плавные кривые — значения это не имеет.

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

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

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

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

В книге имеется довольно много иллюстраций, выполненных в нотации UML. В качестве инструмента рисования использованы приложения Sun Java Studio Enterprise 8, Together, Visio 2000 Professional. Каждый из них имеет свои особенности и может получать разнообразные оценки пользователями, однако, из сказанного ранее следует, что семантика первична, а картинки вторичны, поэтому разработчики инструментов вольны в своем творчестве… Модель UML — это конечное множество сущностей и отношений между ними.

Сущности и отношения модели — это экземпляры метаклассов метамодели.

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

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

Для удобства обзора сущности в UML можно подразделить на четыре группы:

• структурные;

• поведенческие;

• группирующие;

• аннотационные.

О классификациях и группировках Хорошо известна всемирная константа 7±2 (по другим источникам 5±2) — усредненная верхняя оценка количества различных объектов, понятий, шагов рассуждения, которые средний нормальный человек может полноценно воспринимать (держать в голове) одновременно.

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

А что делать, если нужно? Ответ стар как мир: разделяй и властвуй.

Другими словами, нужно ввести классификацию или группировку так, чтобы групп оказалось немного и работать на уровне групп. Если одного уровня группировки мало, следует ввести два, три — столько, сколько нужно чтобы уложиться в ограничение 7±2.

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

Структурные сущности, как нетрудно догадаться, предназначены для описания структуры. Обычно к структурным сущностям относят следующие.

• Класс — описание множества объектов с общими атрибутами и операциями.

• Интерфейс — множество операций, которое определяет набор услуг (службу), предоставляемых классом или компонентом.

• Действующее лицо — сущность, находящаяся вне моделируемой системы и непосредственно взаимодействующая с ней.

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

• Компонент — физически заменяемый артефакт, реализующий некоторый набор интерфейсов.

• Узел — физический вычислительный ресурс.

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

Поведенческие сущности предназначены для описания поведения. Основных поведенческих сущностей всего две: состояние и действие (точнее, две с половиной, потому что иногда употребляется еще и деятельность, которая является частным случаем состояния).

Состояние — период в жизненном цикле объекта, в котором объект удовлетворяет некоторому условию, выполняет деятельность или ожидает события.

Деятельность — состояние, в котором выполняется работа, а не просто пассивно ожидается наступление события.

Действие — атомарный неделимый элемент работы.

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

Группирующая сущность в UML одна — пакет — зато универсальная.

Пакет — группа элементов модели (в том числе пакетов).

Аннотационная сущность тоже одна — примечание — зато в нее можно поместить все что угодно, так как содержание примечания UML не ограничивает.

В таблице 1.3 приведена стандартная нотация в минимальном варианте для упомянутых сущностей.

Таблица 1.3 Нотация основных сущностей Действующее лицо Интерфейс Кооперация Вариант использования Компонент Узел Состояние Деятельность Развилка / слияние Ветвление / соединение Пакет Примечание Ортогональные системы обозначений Очень хорошо, если система обозначений такова, что все ее элементы абсолютно необходимы, используются в равной мере и допускают единственный способ выражения данной мысли. Такие системы обозначений принято называть ортогональными, по аналогии с ортогональной системой векторов в векторном пространстве.

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

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

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

В UML используются четыре основных типа отношений:

• зависимость;

• ассоциация;

• обобщение;

• реализация.

Зависимость — это наиболее общий тип отношения между двумя сущностями, Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной стрелки, направленной от независимой сущности к зависимой. Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации.

Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.

Ассоциация — это наиболее часто используемый тип отношения между сущностями. Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими — ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности. На программном уровне непосредственная связь может быть реализована различным образом, главное, что ассоциированные сущности знают друг о друге. Например, отношение часть–целое является частным случаем ассоциации и называется отношением агрегации.

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

Отношение наследования между классами в объектно-ориентированных языках программирования является типичным примером обобщения.

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

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

О важности правильных обозначений Нельзя не отметить тщательность выбора графической нотации в UML.

Если основные принципы поняты, то обозначения оказываются вполне естественными. Рассмотрим, например, нотацию отношений. Два типа линий подчеркивают степень определенности семантики, привносимой отношением в модель. Ассоциация и обобщение имеют четко определенную семантику, по которой можно прямо генерировать код, поэтому и линии сплошные. Зависимость и реализация более расплывчаты — линии используются пунктирные. Далее, направления стрелок тоже выбраны не случайным, а единственно правильным образом. Независимая сущность может и не знать, что ее использует другая сущность, а вот зависимая сущность не может не знать, от чего она зависит. Эта аналогия уместна и для обобщения и реализации.

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

При рассмотрении последующих (более детальных и содержательных) примеров нотации читателю было бы полезно задавать себе вопрос:

"почему выбрано такое обозначение?" до тех пор, пока сам собой не появится ответ: "а как же иначе!".

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

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

Рассмотрим следующую аналогию с естественным языком. Каждая тройка сущность — отношение — сущность в модели вполне может рассматриваться как простое утверждение: pos := dpt.getNextPos() if not pos.isFree() then send posOccupied(pos) dpt.deletePos(pos) until dpt.size() = deleteDpt(dpt) Это же поведение в нотации диаграммы деятельности UML представлено на рис. 4.33.

Рис. 4.33. Диаграмма деятельности по удалению подразделения в информационной системе отдела кадров Здесь мы считаем нужным отступить от основного русла разбора примера и сделать существенное замечание относительно нотации. Ромбик, который используется на диаграмме деятельности, хотя и является значком, но не является сущностью. Это не более чем связующий символ, позволяющий более экономно изображать сегментированные переходы (см. разд. 4.2.2, рис. 4.10). В примере на рис. 4.30 два ромбика в верхней части диаграммы использованы, чтобы показать место ветвления потока управления на альтернативные112 потоки управления. Но сегментировать в виде дерева можно не только множество исходящих переходов данного состояния, но и множество входящих переходов. В таком случае можно также использовать ромбик, чтобы показать место слияния альтернативных потоков управления (нижний ромбик на рис. 4.30). При ветвлении ромбик соединяет один входящий и несколько исходящих сегментов перехода, а при слиянии ромбик соединяет несколько входящих и один исходящий сегмент.

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

Рис. 4.34. Варианты использования ромбика на диаграммах деятельности Стандарт и авторы языка на этот счет хранят молчание и в своих примерах таких конструкций не используют. Авторы же популярных руководств по UML и разработчики инструментов либо также обходят этот вопрос молчанием, либо считают данную конструкцию синтаксической ошибкой. Мы же полагаем, что такую конструкцию вполне осмысленной: на рис. 4.35 смысл фрагмента диаграммы слева раскрыт на фрагменте диаграммы справа. Другими словами, мы считаем разумным и допустимым произвольный ациклический ориентированный граф из переходных состояний, обозначенных ромбиками, и сегментов перехода, считая семантикой такого графа сегментированных переходов множество переходов, прочитанных, как все возможные пути в этом графе.

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

Не следует путать альтернативные потоки управления с параллельными.

Рис. 4.36. Диаграмма деятельности по удалению подразделения По нашему мнению, диаграмма на рис. 4.36 соответствует следующему псевдокоду:

while dpt.size() > pos := dpt.getNextPos() if not pos.isFree() then send posOccupied(pos) dpt.deletePos(pos) deleteDpt(dpt) Вообще говоря, можно поспорить, что более наглядно: диаграммы деятельности на рис. 4.33 и рис. 4.36 или приведенные программы на псевдокоде. Если положить перед человеком два листа: с диаграммой рис. 4.33 (или 4.36) и с текстом на псевдокоде, и предложить выбрать, то реакция, как показывают наблюдения автора, далеко не однозначна и сильно зависит от личностных качеств испытуемого. Чтобы читатель мог оценить, какой стиль ему предпочтителен, мы приведем еще несколько вариантов графической записи данного элементарного алгоритма, уже не в стиле структурной блок-схемы, как на рис. 4.36, а стиле машины состояний UML. Начнем с очевидного: традиционные ромбики не нужны, они только занимают место на диаграмме (рис. 4.37).

Рис. 4.37. Диаграмма деятельности без использования переходных состояний Если вам еще не надоел данный пример, попробуйте прочитать диаграмму на рис. 4.38. Здесь мы попытались отразить основную структуру разбираемого алгоритма: если подразделение пусто, то его можно удалять без всяких сомнений, а если нет, то нужно анализировать состояние должностей. Этот анализ выполняется в простом состоянии in Doubt. В данном состоянии имеется внутренняя активность do, состоящая в "бесконечном" циклическом переборе должностей в подразделении. Но никакой бесконечности, разумеется, нет: на каждом шаге цикла выполняется внутренний переход, в результате которого либо мы натыкаемся на занятую должность и работа машины состояний грубо обрывается действием terminate, либо уменьшаем размер перебираемого множества, так что процесс неизбежно закончится.

Рис. 4.38. Использование простого состояния с внутренней активностью и переходами Состояние deleteDpt является, на самом деле, состоянием действия, а не состоянием деятельности и без него, как мы отмечали, можно обойтись. Вглядимся теперь внимательно в простое состояние in Doubt. В сущности, там в цикле выполняется пара действий: взять следующую должность, обработать ее. Таким образом, имеются две точки, два мгновения в вычислительном процессе: когда мы от взятия переходим к обработке и когда от обработки переходим к взятию. Мы можем считать эти мгновения состояниями (но это не состояния объекта или системы, это состояния нашего вычислительного процесса!). Сами по себе эти состояния не важны — алгоритм определяется тем, в каком порядке посещаются эти состояния и какие содержательные действия выполняются на переходах. В результате мы получаем конечный автомат, приведенный на рис. 4.39. Все действия выполняются на переходах, а простые состояния служат только для определения смежности переходов. Их можно было бы никак не назвать, но синтаксис UML требует наличия имен простых состояний, поэтому мы их просто перенумеровали.

Рис. 4.39. Эквивалентный конечный автомат Мы надеемся, что повторный просмотр рис. 4.33–4.39 даст читателю достаточно пищи для размышлений и выработки собственного113 отношения к машинам состояний и диаграммам деятельности в UML.

В UML имеется своеобразное графическое средство, которое называется дорожкой.

Дорожка — это графический комментарий, позволяющий классифицировать по некоторому признаку сущности на диаграмме деятельности.

Дорожка не является элементом модели — в метамодели UML нет такого понятия.114 Это именно графический комментарий, подобный границам системы на диаграмме использования (разд. 2.2.2). Поэтому никаких формальных правил применения дорожек нет.

Будь на то наша воля, мы бы предпочли видеть спецификацию поведения операции удаления подразделения dpt примерно такой: posdpt(isFree(pos))deleteDpt(dpt).

В последних версиях стандаратных метамоделей появилось.

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

Рассмотрим бизнес-процесс приема сотрудника на работу в нашей информационной системе отдела кадров (см. разд. 3.3.2–3.3.3, рис. 3.11–3.14).

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

• Interview — сбор информации;

• Approve — анализ собранной информации и принятие решения;

• Fill Forms — заполнение документов;

• Refuse — отказ в найме.

Рис. 4.40. Диаграмма деятельности процесса найма на работу На диаграмме рис. 4.40 нет никаких дорожек — все деятельности равноправны и однородны. Допустим теперь, что деятельность, в которую нанимаемый вовлечен непосредственно (Interview, Fill Forms, Refuse) происходит в одном месте и, так сказать, у него на глазах, а важная деятельность (о которой нанимаемый может не догадываться) по анализу информации и принятию решения осуществляется в другом месте и, может быть, другими действующими лицами (техническими специалистами, руководителями подразделений и т. д.). Эта важная информация не является частью модели, т. к. не имеет отношения к поведению системы, но мы можем отразить ее на диаграмме с помощью дорожек (рис. 4.42). В данном случае мы подразумеваем, что дорожка с названием HRDpt содержит деятельности, выполняемые в приемной отдела кадров, а дорожка с названием SomeDpt содержит деятельности, выполняемые в том подразделении, куда предполагается принять кандидата.

Рис. 4.42. Дорожки Графически дорожки изображаются в виде прямоугольников с названиями. Как правило, их изображают со смыкающимися боковыми сторонами, хотя это и не обязательно. Авторы UML утверждают, что изображение, подобное приведенному на рис. 4.42, напоминает плавательные дорожки в бассейне, откуда и произошло название данной графической конструкции. Возложим ответственность за правомерность такой ассоциации на авторов UML и завершим этот несложный раздел.

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

Поток управления и поток данных В программе, написанной на обычном процедурном языке программирования, порядок выполнения операторов (шагов алгоритма) определяется порядком расположения операторов в тексте программы и структурами управления. Фактически, обычная программа задает поток управления (разд. 4.1.2). Но при выполнении шагов алгоритма выполняются преобразования данных: переменные приобретают и меняют своих значения. Последовательность изменения данных называется потоком данных. Поток управления (в детерминированной программе) определяет и поток данных. Действительно, если, например, в программе есть несколько оператор присваивания для одной переменной, то история изменения значения переменной (т. е.

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

Объект в состоянии — это объект некоторого класса, про который известно, что он находится в определенном состоянии в данной точке вычислительного процесса.

Синтаксически объект в состоянии изображается, как обычно, в виде прямоугольника и его имя подчеркивается, но дополнительно после имени объекта в квадратных скобках пишется имя состояния, в котором в данной точке вычислительного процесса находится объект. В некоторых случаях состояние объекта не важно, например, если достаточно указать, что в данной точке вычислительного процесса создается новый объект данного класса, и в этом случае применяется обычная нотация для изображения объектов. Важно подчеркнуть, что объект в состоянии на диаграммах деятельности "по определению" считается состоянием, т. е. вершиной графа модели, которая может быть инцидентна переходам, правда переходам особого рода Траектория объекта116 — это переход особого рода, исходным и/или целевым состоянием которого является объект в состоянии.

Это обстоятельство является источником болезненных ошибок в программах. Например, типичная ошибка: использование неинициализированной переменной, т. е. использование в вычислениях значения переменной до того, как это значение было определено.

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

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

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

Рассмотрим это на примере диаграммы деятельности, описывающей процесс найма сотрудника в информационной системы отдела кадров. Рис. 4.43 в основном повторяет рис. 4.21 и 4.42, но здесь представлена траектория объекта класса Person, хранящего данные о принимаемом сотруднике. На диаграмме хорошо видно, что именно является входными и выходными данными каждого из состояний деятельности: в результате деятельности Interview создается новый объект, который далее обрабатывается, меняя свою состояние.

[Accepted] : Person [Rejected] Рис. 4.43. Траектория объекта Нетрудно заметить, что в данном случае мы фактически повторяемся, описывая поведение системы. Из диаграммы на рис. 4.43 следует, что деятельность Approve выполняется после деятельность Interview причем это указано дважды: один раз с помощью перехода по завершении из Interview в Approve и второй раз с помощью траектории объекта, показывающей, что для выполнения деятельности Approve необходим объект, создаваемый деятельностью Interview. Разумеется, UML позволяет не говорить лишнего: диаграмма на рис. 4.44 описывает то же самое поведение, что и диаграмма на рис. 4.43.

[Accepted] : Person [Rejected] Рис. 4.44. Использование траекторий объектов вместо переходов по завершении В UML имеется довольно много обозначений, которые не несут самостоятельной семантической нагрузки, а являются "синтаксическим сахаром", применяемым для повешения наглядности, сокращения записи и просто для украшения диаграмм.

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

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

Вернемся еще раз к примеру с наймом на работу и допустим, что мы хотим отразить в модели несколько иной вариант поведения. В диаграммах на рис. 4.41– 4.44 процесс происходящий в приемной отдела кадров приостанавливается на то время, пока не будут завершена деятельность по оценке кандидата и принятию решения, которая фактически происходит в другом месте. Такое вынужденное ожидание может быть психологически неприятно кандидату (равно как и менеджеру по персоналу).117 Допустим, что в проектируемой информационной системы отдела кадров требуется обеспечить асинхронное проведение процесса приема: после сбора сведений о кандидате менеджер по персоналу отправляет сигнал в соответствующие инстанции и в ожидании ответного сигнала с решением переводит себя и кандидата в состояние ожидания с внутренней активностью — угощает чаем, рассказывает о миссии организации и т. п. В рамках уже рассмотренных обозначений такая ситуация может быть описана диаграммой деятельности (с использованием простого состояния), как показано на рис. 4.45.

Здесь мы предполагаем, что в не отображаемых на диаграмме "инстанциях" принимается сигнал Request с аргументом person и в ответ отправляется сигнал Answer с аргументом decision.

Рис. 4.45. Асинхронный процесс принятия решения при найме Распространенный выход из этой ситуации — "зайдите за ответом завтра после обеда" — не соответствует современному стилю общения.

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

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

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

С одной стороны, диаграммы деятельности — общее и мощное средство описания алгоритмов. Причем не обязательно программно реализованных алгоритмов:

диаграммы деятельности с успехом можно применять для моделирования поведения людей, устройств и организаций при выполнении бизнес-процессов.

Обратите внимание, что в наших примерах про процесс приема на работу (см.

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

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

Посмотрите еще раз рис. 4.33, 4.36-4.37 и особенно рис. 4.39 — это готовый к выполнению код.118 В качестве средства программирования диаграммы деятельности целесообразно применять для реализации операций (что, фактически, и сделано нами в упомянутых примерах — реализована операция удаления подразделения).

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

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

На рис. 4.47 приведен наш вариант метамоделей элементов диаграммы деятельности в UML. Поскольку диаграмма деятельности является частным случаем машины состояний, метаклассы, соответствующие элементам диаграммы деятельности определяются как подклассы метаклассов машины состояний.

К сожалению, анализируя возможности инструментов, доступных автору в момент написания книги, приходится констатировать, что диаграммы деятельности для генерации кода не используются (или используются не в полной мере), хотя даже авторы языка в [1] указали на возможность и желательность такого применения.

-isConcurrent : Boolean {has not entry action {has entry action Рис. 4.47. Метамодель элементов диаграммы деятельности Диаграммы взаимодействия предназначены для моделирования поведения путем описания взаимодействия объектов для выполнения некоторой задачи или достижения определенной цели. Взаимодействие происходит путем обмена сообщениями. Диаграммы взаимодействия применяются на разных уровнях моделирования: как для описания поведения отдельных операций, так и целых вариантов использования. Данный тип диаграмм позволяет описывать не только взаимодействие программных объектов (экземпляров классов), но и взаимодействие экземпляров иных классификаторов: действующих лиц, вариантов использования, подсистем, компонентов, узлов. Диаграммы взаимодействия графически изображаются в двух формах: диаграммы последовательности и диаграммы кооперации.

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

Семантически эти диаграммы эквиваленты потому, что описывают одно и то же:

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

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

На диаграммах обоих типов основными сущностями являются объекты:

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

Наряду с основными сущностями и отношениями на диаграммах последовательности и кооперации применяется множество дополнительных элементов нотации, которые рассматриваются в разд. 4.4.2 и 4.4.3, соответственно.