Введение в UML 2.0, часть II

Диаграммы конечных автоматов (statechart diagrams)

На рис. 4.15 приведен пример диаграммы конечных автоматов. Эта диаграмма описывает алгоритм поведения объектов класса COperator системы "Телефонной службы приема заявок", изображенного на рис. 4.1.

Рис. 4.15. Пример диаграммы конечных автоматов

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

Из состояния WaitingForConnection объект может перейти в состояние Idle, если ожидание соединения с оператором превысит время T12.

При получении сигнала Disconnect, свидетельствующего об окончании обслуживания клиента, объект переходит в состояние Idle, в котором ожидает новый запрос. В этом же состоянии объект может обработать сигнал Terminate - указание завершить всю свою работу и освободить оперативную память.

В состоянии Connected объект может получить четыре сигнала Disconnect, не реагируя на них, но при получении пятого он переходит в состояние Idle.

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

Ремарки об изучении и использовании UML.

Начинающий читатель, впервые соприкоснувшись с UML, часто поражается той громаде знаний, которая включена в этот стандарт. Описание стандарта занимает более семисот страниц и содержит поистине необъятное количество различных конструкций, имеющих порой нетривиальный смысл. Ведь UML вобрал в себя принципы, знания и достижения, добытые более чем за тридцать лет развития программирования. В него включены достижения структурного анализа 1960-х - 1980-х годов (правила структурной декомпозиции систем, использование различных типов диаграмм и пр.) и около пятидесяти различных объектно-ориентированных методологий разработки ПО конца 1980-х - 1990-х годов. UML также предназначен для моделирования систем различного вида: систем реального времени, баз данных и информационных систем, web-приложений, обычных объектно-ориентированных систем, а также пригоден для бизнес-моделирования (хотя в отношении последнего основной вектор усилий OMG направлен сейчас на стандарт BPMN, который будет рассмотрен в следующих лекциях). Существуют также особенности визуального моделирования приложений, создаваемых на разных платформах разработки ПО - .Net, Java и пр. И так далее… Есть от чего закружиться голове.

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

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

Еще один совет начинающим практикам. Не стесняйтесь изобретать свои собственные методы и техники использования UML. Часто сильно сковывает иллюзия, что существуют "могучие" методы "правильного" использования UML. В этом есть доля истины - например, имеется сложный и непростой метод RUP/USDP [4.2], способный принести процессу разработки ПО значительную пользу при грамотном внедрении. Однако подобные тяжеловесные методы эффективны в крупных проектах, которые задействуют большое количество людей и средств. Они позволяют навести порядок в управлении разработкой, без которого такие проекты невозможно завершить. С другой стороны, существует большое количество небольших и средних проектов, а также локальное использование UML - даже в большом проекте, но одним или несколькими разработчиками.

В указанном случае "работает" следующий принцип. От UML берутся основные, базовые идеи, которые осмысляются и развиваются в определенном контексте, превращаясь в действенные практики. Например, создать эффективный процесс для применения диаграмм случаев использования для итеративного "вытягивания" и первичной формализации требований к системе, учитывающий особенности конкретного заказчика - не простая, но интересная задача. Для ее решения вовсе не обязательно применять стандартные формы спецификации случаев использования (см., например, [4.9]), знать многочисленную успешную практику использования этих диаграмм (с огромной библиографией этого вопроса можно ознакомиться в [4.2]). Можно даже нарушить синтаксис и семантику базовых UML-конструкций. Необходимо пробовать, стремясь решать реальные практические задачи. Например, в [4.10] приводится методика использования UML при документировании сложного программно-аппаратного комплекса, созданная авторами "на ходу".

Краткий обзор литературы об UML

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

1. Стандарт OMG [4.4]. Этот документ, несомненно, является самым подробным и полным изложением UML. Однако его описание занимает семьсот десять страниц и очень формализовано, так что для первого знакомства с языком этот источник не годится. Его предназначение - служить руководством для разработчиков UML-средств, а также справочником для экспертов в области визуального моделирования. Последние, как правило, являются популяризаторами стандарта, излагая его основные идеи в книгах, которые уже годятся для нормального восприятия.
2. Книга трех amigos - Грэди Буча, Джима Рэмбо и Ивара Якобсона (главных отцов-основателей UML ) - про UML 2.0 [4.1]. Этот труд является прекрасным справочником по всем конструкциям UML. Однако его полезно читать, когда имеются уже начальные знания. Когда знания UML глубоки, этот труд полезен как превосходное объяснение и напоминание различных деталей. Обзор UML с примерами, предшествующий справочной части, менее удачен. В русском переводе все окончательно запутывается…
3. Книга о методе USDP [4.2]. Это очень хорошая книга о самом известном методе разработки ПО, основанном на UML - RUP/USDP. Метод разрабатывался многие годы, многими людьми и многими компаниями. При чтении этого труда становится понятно, как можно использовать UML в "тяжеловесной" манере - большим коллективом с многими ролями, на всех фазах и этапах разработки. Хорошо объясняется предназначение диаграмм случаев использования, методы работы с этими диаграммами, а также то, как строить модели анализа, проектирования, чем они отличаются друг от друга и многое другое. Однако только по книге невозможно освоить весь тот богатый практический опыт, который вложен в этот метод. Требуются тренинги, а также опыт практического использования и внедрения. То есть метод достаточно сложен.
4. Книга Мартина Фаулера [4.7] - известного практика и методолога в области разработки ПО. Книга содержит практические рекомендации по использованию UML, основанные на опыте самого автора. Фаулер не создает никакой общей теории, пишет живо и понятно. В противовес [4.1], [4.2], эта книга небольшая, очень легко читается и может служить прекрасным источником для первого знакомства с UML. Опытные разработчики также смогут найти в ней много полезной информации. Книга содержит многочисленные ссылки для дальнейшего чтения.
5. Знаменитая книга Грэди Буча "Объектно-ориентированный анализ и проектирование" [4.8]. Эта книга - одна из многих методологий объектно-ориентированного анализа и проектирования ПО, появившихся с конца 1980-х до середины 1990-х годов. Результатом этого "взрыва" и стало появление UML, который, однако, стандартизовал только язык моделирования, оставив в стороне методы его использования. Данная книга является прекрасным учебником по основам объектно-ориентированной разработки ПО: там описываются основные концепции, такие как абстрагирование, инкапсуляция, модульность, иерархия, типизация, параллелизм, сохраняемость. Там подробно обсуждается, что такое классы, что такое объекты, приводятся примеры и аналогии из разных предметных областей, не только из программирования. Наконец, излагается сам метод (так называемый метод Буча), который демонстрируется на примерах различных приложений. Книга легко читается, снабжена наглядными и запоминающимися иллюстрациями.
6. Книга отечественного специалиста А.В. Леоненкова [4.9] (имеются и другие, более ранние его книги, посвященные UML ). Она в доступной форме излагает основы UML 1.5, легко читается, несмотря на любовь автора к термину "семантический", присутствующему в определениях многих UML-понятий. Интересен и содержателен акцент на бизнес-моделировании, отражающий практический опыт автора.
7. Не могу удержаться, чтобы не порекомендовать мою собственную книгу по языкам визуального моделирования [4.3]. Описывать ее не буду, скажу только, что одним из ее несомненных достоинств считаю малый размер (сто семьдесят страниц). Одновременно она содержит значительное количество информации - помимо UML там представлено описание других визуальных языков, в частности, SADT, SDL и MSC.

Контрольные вопросы

1. Какую информацию о разрабатываемой системе принято изображать на диаграммах классов?
2. Дайте определение ассоциации. Чем она отличается от наследования?
3. Какие отношения между классами не переходят в связи между экземплярами?
4. Что такое конец ассоциации?
5. Чем однонаправленная ассоциация отличается от двунаправленной?
6. Приведите свой пример n-арной ассоциации.
7. Расскажите о соображениях по именованию концов ассоциаций. Приведите примеры для бинарных ассоциаций, когда именование концов облегчает чтение диаграммы, и пример, когда это оказывается избыточным.
8. Как, на ваш взгляд, сочетаются имя ассоциации и имена ее концов на одной диаграмме? Приведите собственный пример для подтверждения своего мнения.
9. Зачем нужны классы-ассоциации? Постройте собственный пример.
10. Дайте определение агрегирования. Приведите примеры различных семантик агрегирования.
11. Агрегирование является: свойством ассоциации, свойством роли, отдельным отношением между классами UML?
12. Может ли у двух и более концов ассоциации быть свойство агрегирования?
13. Возможна ли ситуация, когда класс агрегируется несколькими другими классами, но тем не менее любой его экземпляр агрегируется только одним объектом? Приведите пример.
14. Может ли класс агрегироваться несколькими другими классами, и при этом его экземпляр также будет входить в несколько объектов? Верно ли то же утверждение про композицию? Приведите содержательный пример.
15. Чем агрегирование похоже на наследование и чем отличается?
16. Что такое композиция? Приведите пример.
17. Попробуйте расширить UML для выражения связи, которая существует между классом и вложенным в него классом ( nested -класс языка Java ).
18. Что такое UML -пакет?
19. Чем пакеты UML близки к проектам и solutions Microsoft Visual Studio?
20. Могут ли пакеты содержать элементы UML -модели, отличные от других пакетов и классов?
21. Что такое зависимость между пакетами? Может ли это отношение использоваться для других UML -элементов?
22. Дайте определение объекта.
23. Расскажите о правилах изображения имен у сущностей UML, соответствующих каким-либо экземплярам (в частности, объектам классов).
24. Что такое связи между объектами?
25. Что такое кооперация? Приведите свой пример.
26. Приведите примеры альтернативных определений кооперации.
27. На каких диаграммах может использоваться кооперация? Приведите собственные примеры.
28. Что такое совместимость фактических и формальных параметров кооперации?
29. Расскажите о правилах изображения имен ролей.
30. Что такое диаграммы конечных автоматов? Приведите свой собственный пример.