Визуальное моделирование: теория и практика

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

Показывать лекцию целиком

Диаграммы классов (class diagrams)

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

На рис. 4.1 представлен фрагмент диаграммы классов телефонной службы приема заявок.

(рис 4.1) Пример диаграммы классов

На этом рисунке показаны основные классы сервера телефонной системы обработки заявок: класс CPBX_Agent отвечает за работу с PBX (с "железкой", занимающейся коммутацией абонентов); класс COperator содержит описание экземпляров операторов, работающих в call-центре, класс CSubOperator описывает особенного, "продвинутого" оператора (например, начальника над группой операторов); класс COperatorList управляет множеством операторов (добавляет их в список, удаляет и т.д.); класс CNetworkConnectionSupport отвечает за поддержку соединений сервера через локальную компьютерную сеть с компьютерами операторов; класс CDispatсher отвечает за синхронизацию всех остальных программных сущностей на сервере.

Итак, на диаграммах классов изображаются сами классы с атрибутами, типами атрибутов, методами, их параметрами и типами, а также иерархия наследования классов. И класс, и наследование в UML полностью соответствуют конструкциям объектно-ориентированных языков программирования. Но кроме них на диаграммах классов могут также присутствовать связи между классами - ассоциации. Так, на рис. 4.1 класс CDispatcher связан с классами CPBX_Agent, COperator, CServerNetworkConnectionSupport и COperatorList.

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

Ассоциации (association)

Если два класса связаны друг с другом ассоциацией, то это означает, что их экземпляры (объекты) определенным образом связаны друг с другом, например:

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

    Ассоциация как связь между классами обязательно переходит в связь между экземплярами этих классов. Этим она принципиально отличается от наследования. Ниже мы подробно остановимся на отличиях агрегирования и наследования.

    Ассоциации в программном коде могут быть реализованы, например, через атрибуты-указатели языка C++, как показано на рис. 4.2.

    (рис 4.2) Пример представления ассоциаций в программном коде

    Отметим, что доступ по ассоциации может быть однонаправленным и двунаправленным. На рис. 4.3, а изображена ассоциация, направленная от класса С1 к классу С2. Это может означать, что в программном коде класса С2 нет атрибута а2, и объекты класса С2 "не знают", что на них ссылаются объекты класса С1. На рис. 4.3, б и в показано два варианта изображения двунаправленной ассоциации. На рис. 4.2 приведен пример реализации именно для двунаправленной ассоциации.

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

    (рис 4.3) Виды ассоциаций

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

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

    (рис 4.4) Пример именования концов ассоциаций

    Концы ассоциации имеет смысл именовать всегда, когда ассоциация рефлексивна, то есть связывает класс с ним самим же. Пример такой ассоциации показан на рис. 4.5. Там представлен класс CListItem, реализующий элемент двусвязного списка. У него есть ассоциация с самим собой, которая указывает, что один объект этого класса связан этой ассоциацией с двумя другими объектами - с одним через конец Prev (то есть с предыдущим в списке), с другим - через конец Next (то есть со следующим в списке), а может быть связан только с одним (предыдущим или следующим, и тогда он является, соответственно, последним или первым в списке) или ни с одним вовсе (в этом случае этот объект является единственным в списке). Эти роли используются в качестве имен для концов ассоциаций. Количество объектов, с которыми может быть связан экземпляр класса CListItem по этой ассоциации, указывается с противоположного конца ассоциации с помощью конструкции "множественность".

    (рис 4.5) Пример рефлексивной ассоциации

    У конца ассоциации есть свойство под названием множественность (multiplicity). Это свойство определяет количество представителей (конкретных объектов), которые могут быть связаны с партнером ассоциации через этот конец. Множественность является целочисленным интервалом или константой. Ниже представлены примеры.

    0..1.

    1.

    0..*.

    1..*.

    * - просто много, без уточнения того, 0 или 1 фигурируют в качестве нижнего предела.

    Константа (например, 2, 10, 100).

    Интервал (например, 3..5, 10..20).

    Варианты с первого по пятый являются наиболее распространенными на практике.

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

    N-арные ассоциации и класс-ассоциации

    В этом курсе рассматриваются в основном бинарные ассоциации (binary association) - то есть те, которые связывают два класса. Выше были рассмотрены также рефлексивные ассоциации. Вместе с тем в UML возможны n-арные ассоциации (n-ary associations), которые связывают между собой несколько классов. Например, ассоциация под названием "Семья" может связывать следующие классы: "Муж", "Жена", "Ребенок", как показано на рис. 4.6.

    (рис 4.6) Пример N-арной ассоциации

    В этом примере муж и жена должны присутствовать в семье обязательно (значение множественности у соответствующего конца ассоциации "Cемья" равно 1 ), а детей может быть произвольное количество, в том числе и не быть вовсе (значение множественности у соответствующего конца ассоциации равно 0..* ).

    Ассоциация не может иметь атрибутов, но во многих случаях это крайне желательно. Например, если студент связан ассоциацией "многие-ко-многим" с курсом, то этой ассоциации целесообразно иметь атрибут под названием "оценка". Это достигается связыванием с ассоциацией специального класса - класса-ассоциации (association class), в котором и указываются все нужные атрибуты, как показано на рис. 4.7.

    (рис 4.7) Пример класса-ассоциации

    Агрегирование

    У конца ассоциации может быть одно важное свойство под названием агрегирование (aggregation), которое обозначает наличие связи "целое/часть" (part of) между экземплярами классов. Объект-часть в той или иной форме включается в объект-целое. Так, например, на рис. 4.1 показано, что объекты класса COperator входят в объект класса COperatorList (то есть первый класс агрегируется вторым). Таким образом, агрегирование, как частный случай ассоциации, также обязательно переходит в связи между экземплярами классов.

    С помощью агрегирования, например, нельзя определить nested-класс в Java-приложении. Подобный недостаток выразительных средств UML (в частности, для Java) является предметом обширной дискуссии и приводит к созданию диалектов UML, которые являются менее общими, но точнее отражают нужды конкретных платформ реализации. Эти специализации можно создавать, используя встроенные в UML средства - механизм профайлов и extention-механизм. А можно создавать свой собственный визуальный язык и реализовать его, пользуясь DSM-средствами, которых сейчас много - например, Microsoft DSL Tools или Eclipse/GMF. Подробнее об этом будет рассказано в следующих лекциях.

    Агрегирование может быть "слабым", как в примере на рис. 4.1, и "сильным". В последнем случае оно называется композицией (composition) и означает, что объект-агрегат несет полную ответственность за создание и удаление, а также существование объектов, которые связаны с ним композицией, а также один объект в каждый момент своего существования может одновременно быть частью только одного агрегата. Если в примере с классами COperator и COperatorList последний строго контролирует доступ к каждому оператору из своего списка (создание, удаление, обращение к оператору по номеру в списке и пр.), то можно обозначить связывающую их ассоциацию агрегирования как композицию:

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

    Агрегирование принципиально отличается от наследования. Это важно, поскольку при моделировании предметной области с помощью диаграмм классов UML можно заметить их определенное сходство: (i) оба позволяют строить древообразную иерархию классов; (ii) предок, также как и агрегируемый класс, добавляет функциональности в потомок/агрегат; (iii) изображения обоих отношений чем-то похожи визуально. И мне как-то раз пришлось в непростом диалоге убеждать аналитиков, что наследование и агрегирование - это не одно и то же. И вот почему.

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

    Диаграммы пакетов (package diagrams)

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

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

    Во-вторых, в пакеты традиционно помещают классы системы, особенно если проект большой и их много. При этом пакеты UML могут соответствовать, например, проектам (projects) Microsoft Visual Studio. Однако пакеты UML могут быть многократно вложены друг в друга, а проекты Microsoft Visual Studio вложенными быть не могут.

    В Microsoft Visual Studio есть так называемые рабочие области (solutions), которые содержат в себе проекты. Но на компьютере каждого разработчика проекта могут быть созданы свои собственные рабочие области, содержащие нужные ему проекты, а рабочая область всего приложения, используемая для целостной сборки приложения, может быть вообще другой. Так что рабочие области являются плохими кандидатами на роль пакетов, включающие в себя пакеты-проекты.

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

    Пример диаграммы пакетов изображен на рис. 4.9. Пакет Client содержит два пакета - ClientGUI, в котором находится описание пользовательского интерфейса, и ClientNetwork, отвечающий за сетевое взаимодействие с сервером. При этом первый пакет зависит от второго. В данном случае зависимость означает обычную зависимость проектов в Visual Studio.

    (рис 4.9) Пример диаграммы пакетов

    Пакет Server содержит все проекты приложения, которые реализуют работу сервера. ServerBusinessLogic содержит весь код, реализующий бизнес-логику сервера, ServerNetwork реализует сетевое сообщение с клиентом, RequestDB - примитивы доступа и логику работы с базой данных запросов. Пакет Util является служебным пакетом где находятся все вспомогательные типы данных, классы, операции и т. д., которые используются всеми пакетами сервера.

    На рис. 4.10 средствами диаграмм классов UML показано содержимое пакета ServerBusinessLogic.

    (рис 4.10) Содержимое пакета ServerBusinessLogic в терминах диаграмм классов

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

    Необходимо отметить, что при проектировании больших приложений, с большим количеством классов и пакетов (в смысле projects в Microsoft Visual Studio), целесообразно создавать диаграммы пакетов. Полезно как-то предварительно прикинуть структуру проектов приложения, хотя, конечно, потом это видение может меняться. Однако ошибки при проектировании структуры пакетов большого приложения приводят к значительным неудобствам, дополнительной работе и к потере концептуальной целостности приложения.

    Диаграммы объектов (object diagrams)

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

    (рис 4.11) Пример диаграммы объектов

    На этом рисунке изображена следующая конфигурация сервера службы телефонных заявок: один диспетчер (объект ' :CDispatcher '), один объект, работающий с PBX (' :PBX_Agent ') и два оператора – объекты ' Tester1:COperator ' и ' Tester2:CSubOperator '. Для двух первых объектов не указаны имена, поскольку в системе одновременно может быть только по одному такому объекту. Два других объекта соответствуют тестовым операторам, один из которых является "продвинутым" ( Tester2, принадлежащий классу CSubOperator ).>

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

    Общее правило для отображения имен экземпляров таково:

    <идентификатор1>: <идентификатор2>,

    где <Идентификатор1> - это имя экземпляра, а <Идентификатор2> - имя его классификатора. Строка с именем должна быть подчеркнута.

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

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

    Нужно отметить, что изображение имен классов у объектов, как правило, можно отключать, но это не означает, что их нет.

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

    Кооперации (collaborations)

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

    Общающиеся стороны задаются ролями, которые описывают некоторую часть функциональности класса, используемого данным контекстом (в данном случае таким контекстом является кооперация). Например, для двух классов - Абонент и Станция - кооперация "Соединение" (см. рис. 4.13) определяет контекст - процедуру установки соединения между абонентом и станцией, а роли этих классов "берут" из самих классов ту функциональность, которая реализует эту процедуру. Ведь кроме этой функциональности в данных классах может быть много разной другой. Роль занимает промежуточное место между классом и его экземплярамиПодробнее роль будет рассмотрена в лекциях, посвященных моделированию систем реального времени.. На рис. 4.12, а и б представлены примеры двух альтернативных способов задания кооперации.

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

    Кооперация "Соединение" может быть использована на других диаграммах - на диаграмме объектов, как на рис. 4.13, а также при определении других коопераций (см. рис. 4.14). Использование кооперации (collaboration use) - это новая конструкция UML, которая ссылается на определение кооперации и подставляет вместо ее ролей другие роли или объекты, совместимые с ней.

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

    (рис 4.14) Пример использования кооперации при определении другой кооперации

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

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

    Диаграммы конечных автоматов (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, я расскажу о разных источниках, к которым можно обратиться для дальнейшего изучения этого вопроса.

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

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

  • Какую информацию о разрабатываемой системе принято изображать на диаграммах классов?
  • Дайте определение ассоциации. Чем она отличается от наследования?
  • Какие отношения между классами не переходят в связи между экземплярами?
  • Что такое конец ассоциации?
  • Чем однонаправленная ассоциация отличается от двунаправленной?
  • Приведите свой пример n-арной ассоциации.
  • Расскажите о соображениях по именованию концов ассоциаций. Приведите примеры для бинарных ассоциаций, когда именование концов облегчает чтение диаграммы, и пример, когда это оказывается избыточным.
  • Как, на ваш взгляд, сочетаются имя ассоциации и имена ее концов на одной диаграмме? Приведите собственный пример для подтверждения своего мнения.
  • Зачем нужны классы-ассоциации? Постройте собственный пример.
  • Дайте определение агрегирования. Приведите примеры различных семантик агрегирования.
  • Агрегирование является: свойством ассоциации, свойством роли, отдельным отношением между классами UML?
  • Может ли у двух и более концов ассоциации быть свойство агрегирования?
  • Возможна ли ситуация, когда класс агрегируется несколькими другими классами, но тем не менее любой его экземпляр агрегируется только одним объектом? Приведите пример.
  • Может ли класс агрегироваться несколькими другими классами, и при этом его экземпляр также будет входить в несколько объектов? Верно ли то же утверждение про композицию? Приведите содержательный пример.
  • Чем агрегирование похоже на наследование и чем отличается?
  • Что такое композиция? Приведите пример.
  • Попробуйте расширить UML для выражения связи, которая существует между классом и вложенным в него классом ( nested -класс языка Java ).
  • Что такое UML -пакет?
  • Чем пакеты UML близки к проектам и solutions Microsoft Visual Studio?
  • Могут ли пакеты содержать элементы UML -модели, отличные от других пакетов и классов?
  • Что такое зависимость между пакетами? Может ли это отношение использоваться для других UML -элементов?
  • Дайте определение объекта.
  • Расскажите о правилах изображения имен у сущностей UML, соответствующих каким-либо экземплярам (в частности, объектам классов).
  • Что такое связи между объектами?
  • Что такое кооперация? Приведите свой пример.
  • Приведите примеры альтернативных определений кооперации.
  • На каких диаграммах может использоваться кооперация? Приведите собственные примеры.
  • Что такое совместимость фактических и формальных параметров кооперации?
  • Расскажите о правилах изображения имен ролей.
  • Что такое диаграммы конечных автоматов? Приведите свой собственный пример.
    •
    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^