Сведения о языке UML (1183998), страница 3
Текст из файла (страница 3)
Все действующие лицапоказаны в верхней части диаграммы; в приведенном выше примереизображено действующее лицо Клиент. Объекты, требуемые системедля выполнения варианта использования «Снять деньги», такжепредставлены в верхней части диаграммы. Стрелки соответствуютсообщениям, передаваемым между действующим лицом и объектом илимежду объектами для выполнения требуемых функций.На диаграмме последовательности объект изображается в видепрямоугольника, от которого вниз проведена пунктирная вертикальнаялиния.
Эта линия называется линией жизни (lifeline) объекта. Онапредставляет собой фрагмент жизненного цикла объекта в процессевзаимодействия.14Иван :КлиентПриемниккарт1: Принять картуЭкранATMУправлениеАТМСчетИванаКассовыйаппарат2: Считать № карты3: Инициализировать экран4: Запросить PIN-код5: Ввод PIN-кода (1234)6: Открыть счет7: Открыть счет8: Проверить PIN-код9: Запросить действие10: Выбор действия(Снять со счета)11: Запросить сумму12: Ввод суммы (20 рублей)13: Снять (20 руб.)14: Снять (20 руб.)15: Проверить вклад (20 руб.)16: Уменьшить вклад (20 руб)17: Выдать (20 руб.)18: Вернуть картуРис. 1.4.
Диаграмма последовательности для снятия клиентом денегсо счета15Каждое сообщение представляется в виде стрелки между линиямижизни двух объектов. Сообщения появляются в том порядке, как онипоказаны на странице сверху вниз. Каждое сообщение помечается какминимум именем сообщения; при желании можно добавить такжеаргументы и некоторую управляющую информацию, и, кроме того, можнопоказать само-делегирование (self-delegation) – сообщение, которое объектпосылает самому себе, при этом стрелка сообщения указывает на ту жесамую линию жизни.Хороший способ первоначального обнаружения некоторых объектов –это изучение имен существительных в потоке событий. Можно такжепрочитатьдокументы,описывающиеконкретныйсценарий.Под сценарием понимается конкретный экземпляр потока событий. Потоксобытий для варианта использования «Снять деньги» говорит о человеке,снимающем некоторую сумму денег со счета с помощью АТМ.Не все объекты появляются в потоке событий.
Там, например, можетне быть форм для заполнения, но их необходимо показать на диаграмме,чтобы позволить действующему лицу ввести новую информациюв систему или просмотреть её. В потоке событий, скорее всего, такжене будет и управляющих объектов (control objects). Эти объекты управляютпоследовательностью потока в варианте использования.1.4.2. Кооперативные диаграммыВторым видом диаграммы взаимодействия является кооперативнаядиаграмма.Подобно диаграммам последовательности, кооперативные диаграммы(collaborations) отображают поток событий через конкретный сценарийварианта использования. Диаграммы последовательности упорядоченыпо времени, а кооперативные диаграммы больше внимания заостряютна связях между объектами.
На рис. 1.5 приведена кооперативнаядиаграмма, описывающая, как клиент снимает деньги со счета.Как видно из рисунка, здесь представлена вся та информация, котораябыла и на диаграмме последовательности, но кооперативная диаграммапо-другому описывает поток событий. Из нее легче понять связимежду объектами, однако, труднее уяснить последовательность событий.162:Считать № карты1: Принять картуКассовыйаппаратПриемниккартИван : Клиент18: Вернуть карту5: Ввод PIN-кода (1234)10: Выбор действия (Снять со счета)12: Ввод суммы (20 руб.)3: Инициализироватьэкран4: Запросить PIN-код9: Запросить действие11: Запросить суммуЭкран ATM17: Выдать (20 руб.)Управление ATM7: Открыть счет8: Проверить PIN-код14: Снять (20 руб.)6: Открыть счет13: Снять (20 руб.)15: Проверить вклад (20 руб.)16: Уменьшить вклад (20 руб.)Счет ИванаРис.
1.5. Кооперативная диаграмма, описывающая процесс снятияклиентом денег со своего счетаПо этой причине часто для какого-либо сценария создают диаграммыобоих типов. Хотя они служат одной и той же цели и содержат однуи ту же информацию, но представляют ее с различных точек зрения.На кооперативной диаграмме так же, как и на диаграммепоследовательности, стрелки обозначают сообщения, обмен которымиосуществляется в рамках данного варианта использования.
Их временнáяпоследовательность, однако, указывается путем нумерации сообщений.1.5. Диаграммы классов1.5.1. Общие сведенияДиаграмма классов определяет типы классов системы и различногорода статические связи, которые существуют между ними. На диаграммахклассов изображаются также атрибуты классов, операции классови ограничения, которые накладываются на связи между классами.17Диаграмма классов для варианта использования «Снять деньги» показанана рис. 1.6.<<Entity>>Card Reader- Card Number : integer<<Boundary>>ATM Screen+ Prompt() : integer+ AcceptInput(Input : Integer) : integer+ Accept Card() : integer+ Eject Card() : integer+ Read Card() : integer0..10..10..10..n<<Entity>>Account- Account Number : integer- PIN : integer- Balance : long<<Boundary>>Cash Dispenser- Cash Balance : long1+ Open() : integer+ Withdraw Funds(Amount : long) : integer- Deduct Funds(Amount : long) : integer- Verify Funds() : integerРис.
1.6.«Снять деньги»Диаграммаклассов0..1 + Provide Cash() : integer+ Provide Receipt() : integerдлявариантаиспользованияНа этой диаграмме классов показаны связи между классами,реализующими вариант использования «Снять деньги». В этом процессезадействованы четыре класса: Card Reader1 (устройство для чтениякарточек), Account (счет), ATM Screen (экран АТМ) и Cash Dispenser(кассовый аппарат). Каждый класс на диаграмме выглядит в видепрямоугольника, разделенного на три части. В первой содержится имякласса, во второй – его атрибуты. В последней части содержатся операциикласса, отражающие его поведение (действия, выполняемые классом).1На диаграммах классов и всех последующих диаграммах используютсяанглийские имена, так как только такие имена поддерживаются в языкахпрограммирования. Использование русских имен объектов, операций, атрибутови т.
д. сопряжено с большими трудностями, так как CASE-средства ихне поддерживают должным образом.18Связывающиеклассылинииотражаютвзаимодействиемежду классами. Так, класс Account связан с классом ATM Screen (экранАТМ), потому что они непосредственно сообщаются и взаимодействуютдруг с другом. Класс Card Reader (устройство для чтения карточек)не связан с классом Cash Dispenser (кассовый аппарат), поскольку онине сообщаются друг с другом непосредственно.1.5.2 Стереотипы классовСтереотипы – это механизм, позволяющий разделять классына категории.
В языке UML определены три основных стереотипа классов:Boundary (граница), Entity (сущность) и Control (управление).Граничные классыГраничными классами (boundary classes) называются такие классы,которые расположены на границе системы и всей окружающей среды.Это экранные формы, отчеты, интерфейсы с аппаратурой (такой какпринтеры или сканеры) и интерфейсы с другими системами.Чтобы найти граничные классы, надо исследовать диаграммывариантов использования.
Каждому взаимодействию между действующимлицом и вариантом использования должен соответствовать, по крайнеймере, один граничный класс. Именно такой класс позволяет действующемулицу взаимодействовать с системой.Классы-сущностиКлассы-сущности (entity classes) содержат хранимую информацию.Они имеют наибольшее значение для пользователя, и потомув их названиях часто используют термины из предметной области.
Обычнодля каждого класса-сущности создают таблицу в базе данных.Управляющие классыУправляющие классы (control classes) отвечают за координациюдействий других классов. Обычно у каждого варианта использованияимеется один управляющий класс, контролирующий последовательностьсобытий этого варианта использования.
Управляющий класс отвечаетза координацию, но сам не несет в себе никакой функциональности, таккак остальные классы не посылают ему большого количества сообщений.Вместо этого он сам посылает множество сообщений. Управляющий класс19просто делегирует ответственность другим классам, по этой причине егочасто называют классом-менеджером.В системе могут быть и другие управляющие классы, общиедля нескольких вариантов использования. Например, может быть классSecurityManager (менеджер безопасности), отвечающий за контрольсобытий, связанных с безопасностью.
Класс TransactionManager (менеджертранзакций) занимается координацией сообщений, относящихсяк транзакциям с базой данных. Могут быть и другие менеджерыдля работы с другими элементами функционирования системы, такими какразделение ресурсов, распределенная обработка данных или обработкаошибок.Помимо упомянутых выше стереотипов можно создавать исвои собственные.1.5.3.
Механизм пакетовПакеты применяют, чтобы сгруппировать классы, обладающиенекоторой общностью. Существует несколько наиболее распространенныхподходов к группировке. Во-первых, можно группировать ихпо стереотипу. В таком случае получается один пакет с классамисущностями, один с граничными классами, один с управляющимиклассами и т.д.
Этот подход может быть полезен с точки зренияразмещения готовой системы, поскольку все находящиеся на клиентскихмашинах пограничные классы уже оказываются в одном пакете.Другойподходзаключаетсявобъединенииклассовпо их функциональности. Например, в пакете Security (безопасность)содержатся все классы, отвечающие за безопасность приложения. В такомслучае другие пакеты могут называться Employee Maintenance (Работас сотрудниками), Reporting (Подготовка отчетов) и Error Handling(Обработка ошибок).
Преимущество этого подхода заключаетсяв возможности повторного использования.Механизм пакетов применим к любым элементам модели, а не толькок классам. Если для группировки классов не использовать некоторыеэвристики, то она становится произвольной. Одна из них, котораяв основном используется в UML, – это зависимость. Зависимость между20двумя пакетами существует в том случае, если между любыми двумяклассами в пакетах существует любая зависимость. Таким образом,диаграмма пакетов (рис. 1.7) представляет собой диаграмму,содержащую пакеты классов и зависимости между ними. Строго говоря,пакеты и зависимости являются элементами диаграммы классов, то естьдиаграмма пакетов – это форма диаграммы классов.EntitiesBoundariesControlРис.
1.7. Диаграмма пакетовЗависимость между двумя элементами имеет место в том случае, еслиизменения в определении одного элемента могут повлечь за собойизменения в другом. Что касается классов, то причины для зависимостеймогут быть самыми разными: один класс посылает сообщение другому;один класс включает часть данных другого класса; один класс используетдругой в качестве параметра операции.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
