Материал: Лабораторные_Архитерктура ИС
1
8
Диаграмма
классов
для
варианта
использования
«
Снять
деньги
»
показана
на
рис
.
1
.6.
Рис
.
1
.6.
Диаграмма
классов
для
варианта
использования
«
Снять
деньги
»
На
этой
диаграмме
классов
показаны
связи
между
классами
,
реализующими
вариант
использования
«
Снять
деньги
».
В
этом
процессе
задействованы
четыре
класса
: Card Reader
1
(
устройство
для
чтения
карточек
), Account (
счет
), ATM Screen (
экран
АТМ
)
и
Cash Dispenser
(
кассовый
аппарат
).
Каждый
класс
на
диаграмме
выглядит
в
виде
прямоугольника
,
разделенного
на
три
части
.
В
первой
содержится
имя
класса
,
во
второй
–
его
атрибуты
.
В
последней
части
содержатся
операции
класса
,
отражающие
его
поведение
(
действия
,
выполняемые
классом
).
1
На
диаграммах
классов
и
всех
последующих
диаграммах
используются
английские
имена
,
так
как
только
такие
имена
поддерживаются
в
языках
программирования
.
Использование
русских
имен
объектов
,
операций
,
атрибутов
и
т
.
д
.
сопряжено
с
большими
трудностями
,
так
как
CASE-
средства
их
не
поддерживают
должным
образом
.
Card Reader
- Card Number : integer
+ Accept Card() : integer
+ Eject Card() : integer
+ Read Card() : integer
<<Entity>>
Account
- Account Number : integer
- PIN : integer
- Balance : long
+ Open() : integer
+ Withdraw Funds(Amount : long) : integer
- Deduct Funds(Amount : long) : integer
- Verify Funds() : integer
<<Entity>>
Cash Dispenser
- Cash Balance : long
+ Provide Cash() : integer
+ Provide Receipt() : integer
<<Boundary>>
0..
1
0..
1
0..
1
1
0..n
ATM Screen
+ Prompt() : integer
+ AcceptInput(Input : Integer) : integer
<<Boundary>>
0..
1
1
9
Связывающие
классы
линии
отражают
взаимодействие
между
классами
.
Так
,
класс
Account
связан
с
классом
ATM Screen (
экран
АТМ
),
потому
что
они
непосредственно
сообщаются
и
взаимодействуют
друг
с
другом
.
Класс
Card Reader (
устройство
для
чтения
карточек
)
не
связан
с
классом
Cash Dispenser (
кассовый
аппарат
),
поскольку
они
не
сообщаются
друг
с
другом
непосредственно
.
1.5.2
Стереотипы
классов
Стереотипы
–
это
механизм
,
позволяющий
разделять
классы
на
категории
.
В
языке
UML
определены
три
основных
стереотипа
классов
:
Boundary (
граница
), Entity (
сущность
)
и
Control (
управление
).
Граничные
классы
Граничными
классами
(boundary classes)
называются
такие
классы
,
которые
расположены
на
границе
системы
и
всей
окружающей
среды
.
Это
экранные
формы
,
отчеты
,
интерфейсы
с
аппаратурой
(
такой
как
принтеры
или
сканеры
)
и
интерфейсы
с
другими
системами
.
Чтобы
найти
граничные
классы
,
надо
исследовать
диаграммы
вариантов
использования
.
Каждому
взаимодействию
между
действующим
лицом
и
вариантом
использования
должен
соответствовать
,
по
крайней
мере
,
один
граничный
класс
.
Именно
такой
класс
позволяет
действующему
лицу
взаимодействовать
с
системой
.
Классы
-
сущности
Классы
-
сущности
(entity classes)
содержат
хранимую
информацию
.
Они
имеют
наибольшее
значение
для
пользователя
,
и
потому
в
их
названиях
часто
используют
термины
из
предметной
области
.
Обычно
для
каждого
класса
-
сущности
создают
таблицу
в
базе
данных
.
Управляющие
классы
Управляющие
классы
(control classes)
отвечают
за
координацию
действий
других
классов
.
Обычно
у
каждого
варианта
использования
имеется
один
управляющий
класс
,
контролирующий
последовательность
событий
этого
варианта
использования
.
Управляющий
класс
отвечает
за
координацию
,
но
сам
не
несет
в
себе
никакой
функциональности
,
так
как
остальные
классы
не
посылают
ему
большого
количества
сообщений
.
Вместо
этого
он
сам
посылает
множество
сообщений
.
Управляющий
класс
20
просто
делегирует
ответственность
другим
классам
,
по
этой
причине
его
часто
называют
классом
-
менеджером
.
В
системе
могут
быть
и
другие
управляющие
классы
,
общие
для
нескольких
вариантов
использования
.
Например
,
может
быть
класс
SecurityManager (
менеджер
безопасности
),
отвечающий
за
контроль
событий
,
связанных
с
безопасностью
.
Класс
TransactionManager (
менеджер
транзакций
)
занимается
координацией
сообщений
,
относящихся
к
транзакциям
с
базой
данных
.
Могут
быть
и
другие
менеджеры
для
работы
с
другими
элементами
функционирования
системы
,
такими
как
разделение
ресурсов
,
распределенная
обработка
данных
или
обработка
ошибок
.
Помимо
упомянутых
выше
стереотипов
можно
создавать
и
свои
собственные
.
1.5.3.
Механизм
пакетов
Пакеты
применяют
,
чтобы
сгруппировать
классы
,
обладающие
некоторой
общностью
.
Существует
несколько
наиболее
распространенных
подходов
к
группировке
.
Во
-
первых
,
можно
группировать
их
по
стереотипу
.
В
таком
случае
получается
один
пакет
с
классами
-
сущностями
,
один
с
граничными
классами
,
один
с
управляющими
классами
и
т
.
д
.
Этот
подход
может
быть
полезен
с
точки
зрения
размещения
готовой
системы
,
поскольку
все
находящиеся
на
клиентских
машинах
пограничные
классы
уже
оказываются
в
одном
пакете
.
Другой
подход
заключается
в
объединении
классов
по
их
функциональности
.
Например
,
в
пакете
Security (
безопасность
)
содержатся
все
классы
,
отвечающие
за
безопасность
приложения
.
В
таком
случае
другие
пакеты
могут
называться
Employee Maintenance (
Работа
с
сотрудниками
), Reporting (
Подготовка
отчетов
)
и
Error Handling
(
Обработка
ошибок
).
Преимущество
этого
подхода
заключается
в
возможности
повторного
использования
.
Механизм
пакетов
применим
к
любым
элементам
модели
,
а
не
только
к
классам
.
Если
для
группировки
классов
не
использовать
некоторые
эвристики
,
то
она
становится
произвольной
.
Одна
из
них
,
которая
в
основном
используется
в
UML, –
это
зависимость
.
Зависимость
между
2
1
двумя
пакетами
существует
в
том
случае
,
если
между
любыми
двумя
классами
в
пакетах
существует
любая
зависимость
.
Таким
образом
,
диаграмма
пакетов
(
рис
.
1
.7)
представляет
собой
диаграмму
,
содержащую
пакеты
классов
и
зависимости
между
ними
.
Строго
говоря
,
пакеты
и
зависимости
являются
элементами
диаграммы
классов
,
то
есть
диаграмма
пакетов
–
это
форма
диаграммы
классов
.
Entities
Boundaries
Control
Рис
.
1
.7.
Диаграмма
пакетов
Зависимость
между
двумя
элементами
имеет
место
в
том
случае
,
если
изменения
в
определении
одного
элемента
могут
повлечь
за
собой
изменения
в
другом
.
Что
касается
классов
,
то
причины
для
зависимостей
могут
быть
самыми
разными
:
один
класс
посылает
сообщение
другому
;
один
класс
включает
часть
данных
другого
класса
;
один
класс
использует
другой
в
качестве
параметра
операции
.
Если
класс
меняет
свой
интерфейс
,
то
любое
сообщение
,
которое
он
посылает
,
может
утратить
свою
силу
.
Пакеты
не
дают
ответа
на
вопрос
,
каким
образом
можно
уменьшить
количество
зависимостей
в
вашей
системе
,
однако
они
помогают
выделить
эти
зависимости
,
а
после
того
,
как
они
все
окажутся
на
виду
,
остается
только
поработать
над
снижением
их
количества
.
Диаграммы
пакетов
22
можно
считать
основным
средством
управления
общей
структурой
системы
.
Пакеты
являются
жизненно
необходимым
средством
для
больших
проектов
.
Их
следует
использовать
в
тех
случаях
,
когда
диаграмма
классов
,
охватывающая
всю
систему
в
целом
и
размещенная
на
единственном
листе
бумаги
формата
А
4,
становится
нечитаемой
.
1.5.4.
Атрибуты
Атрибут
–
это
элемент
информации
,
связанный
с
классом
.
Например
,
у
класса
Company (
компания
)
могут
быть
атрибуты
Name (
Название
),
Address (
Адрес
)
и
NumberOfEmployees (
Число
служащих
).
Так
как
атрибуты
содержатся
внутри
класса
,
они
скрыты
от
других
классов
.
В
связи
с
этим
может
понадобиться
указать
,
какие
классы
имеют
право
читать
и
изменять
атрибуты
.
Это
свойство
называется
видимостью
атрибута
(attribute visibility).
У
атрибута
можно
определить
четыре
возможных
значения
этого
параметра
.
Рассмотрим
каждый
из
них
в
контексте
примера
(
рис
.
1
.8).
Пусть
у
нас
имеется
класс
Employee
с
атрибутом
Address
и
класс
Company:
–
Public (
общий
,
открытый
).
Это
значение
видимости
предполагает
,
что
атрибут
будет
виден
всеми
остальными
классами
.
Любой
класс
может
просмотреть
или
изменить
значение
атрибута
.
В
таком
случае
класс
Company
может
изменить
значение
атрибута
Address
класса
Employee.
В
соответствии
с
нотацией
UML
общему
атрибуту
предшествует
знак
« + ».
–
Private (
закрытый
,
секретный
).
Соответствующий
атрибут
не
виден
никаким
другим
классом
.
Класс
Employee
будет
знать
значение
атрибута
Address
и
сможет
изменять
его
,
но
класс
Company
не
сможет
его
ни
увидеть
,
ни
редактировать
.
Если
это
понадобится
,
он
должен
попросить
класс
Employee
просмотреть
или
изменить
значение
этого
атрибута
,
что
обычно
делается
с
помощью
общих
операций
.
Закрытый
атрибут
обозначается
знаком
« – »
в
соответствии
с
нотацией
UML.
–
Protected (
защищенный
).
Такой
атрибут
доступен
только
самому
классу
и
его
потомкам
.
Допустим
,
что
у
нас
имеется
два
различных