200120_ИСИС_2

1. Б1.В.15 ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ИНФОРМАЦИОННЫХ СИСТЕМ (4308-09, 09.03.02 ИСиТ, 5 семестр - экзамен)

160711-160715

2.

144 – 4 ЗЕТ
18 ч. лекций
36 ч. лаб.
3 теста
экзамен
54 СР
4 ЗЕТ
2

3. Литература:

1. Вендров
А.М.
Проектирование
программного
обеспечения экономических информационных систем.
Учебник. М.: Финансы и статистика, 2003, 352 с.
2. Вендров
А.М.
Практикум
по
проектированию
программного обеспечения экономических информационных
систем. М.: Финансы и статистика, 2002,192 с.
3. Леоненков А. UML 2-е издание, Санкт-Петербург: БХВПетербург, 2004,432 с.
.
3

4. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

4

5. Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ Об информации, информационных технологиях и о защите

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

6. Продолжение.

Документированная информация - зафиксированная на
материальном
носителе
путем
документирования
информация с реквизитами, позволяющими определить
такую информацию или в установленных законодательством
Российской Федерации случаях ее материальный носитель.
Информационные ресурсы - по законодательству РФ отдельные документы и отдельные массивы документов,
документы и массивы документов в информационных
системах: библиотеках, архивах, фондах, банках данных,
других видах информационных систем.
6

7.

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

8.

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

9.

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

10.

Названием «подсистема» подчеркивается, что такая часть
должна обладать свойствами системы (в частности,
свойством целостности). Этим подсистема отличается от
простой группы элементов, для которой не сформулирована
подцель и не выполняются свойства целостности (для такой
группы используется название «компоненты»). Например,
подсистемы АСУ, подсистемы пассажирского транспорта
крупного города. Например, для транспортного средства
можно
выделить
подсистемы:
трансмиссию,
электроснабжения, торможения и т.д. Т.е. в подсистему
объединяют элементы функционально тесно связанные и
имеющую частную функциональную задачу.
10

11.

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

12.

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

13.

Связь. Понятие «связь» входит в любое определение
системы наряду с понятием «элемент» и обеспечивает
возникновение и сохранение структуры и целостных
свойств системы. Это понятие характеризует одновременно
и строение (статику), и функционирование (динамику)
системы. Под связью понимают передачу от одного элемента
системы другому элементу системы материальных ресурсов,
энергии, информации.
Внешняя среда. Под внешней средой понимается
множество элементов, которые не входят в систему, но
изменение их состояния вызывает изменение поведения
системы.
Модель (model) — абстракция физической системы,
рассматриваемая с определенной точки зрения и
представленная на некотором языке или в графической
форме.
13

14.

Термин «цель»
Цель это совокупное представление о некоторой модели
будущего результата, способного удовлетворить исходную
потребность при имеющихся реальных возможностях.
14

15. Проекти́рование

Проекти́рование — процесс определения архитектуры,
компонентов, интерфейсов и других характеристик системы
или её части (ISO 24765). Результатом проектирования
является прое́кт — целостная совокупность моделей, свойств
или характеристик, описанных в форме, пригодной для
реализации системы.
Проектирование, наряду с анализом требований, является
частью большой стадии жизненного цикла системы,
называемой проектирование, системы (англ. system definition).
Результаты этой стадии являются входной информацией для
стадии реализации (воплощения) системы (англ. system
realization).
15

16.

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

17.

Проектирование
системы
направлено
на
представление
системы,
соответствующее
предусмотренной цели, принципам и замыслам; оно
включает оценку и принятие решений по выбору таких
компонентов системы, которые отвечают её архитектуре
и укладываются в предписанные ограничения.
Предметная
область
—
часть
реального
мира,
рассматриваемая в пределах данного контекста. Под
контекстом здесь может пониматься, например, область
исследования или область, которая является объектом
некоторой деятельности.
17

18. Термин «Инструментальные средства информационных систем»

Инструментальные средства ИС — комплекс
программно-технических средств предназначенных для
автоматизации процесса проектирования ИС.
18

19.

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

20.

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

21.

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

22. Термины процесса проектирования ИТ

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

23.

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

24.

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

25. ЖЦ каскадной модели проектирования ИС

25

26.

ЖЦ предусматривает последовательное выполнение всех
этапов проекта в строго фиксированном порядке. Переход на
следующий этап означает полное завершение работ на
предыдущем этапе и каждый этап завершается передачей
заказчику полного комплекта проектной документации по
ГОСТ серии 34. (с эта модель с 70 г.).
26

27.

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

28. Поэтапная модель ЖЦ ИС с промежуточным контролем

28

29. Достоинства и недостатки каскадной модели

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

30. Спиральная модель ЖЦ

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

31.

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

32. Спиральная модель ЖЦ ИС

32

33.

На каждом витке спирали выполняется создание
очередной версии продукта, уточняются требования проекта,
определяется его качество и планируются работы
следующего витка. Особое внимание уделяется начальным
этапам разработки - анализу и проектированию, где
реализуемость тех или иных технических решений
проверяется и обосновывается посредством создания
прототипов (макетирования).
Заказчику
передается
только
эксплуатационная
документация.
СПИРАЛЬНУЮ
МОДЕЛЬ
НЕЛЬЗЯ
ИСПОЛЬЗОВАТЬ ПРИ ПРОЕКТИРОВАНИИ СИСТЕМ
РЕАЛЬНОГО ВРЕМЕНИ!!!
33

34. ПАРАДИГМА СОВРЕМЕННОГО ПРОИЗВОДСТВА

Отныне нужно не “что-то производить и стараться
потом продать”, а “стараться производить, то, что
продается”.
34

35.

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

36. Роль и место информационных технологий в управлении предприятием

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

37.

Показатели, характеризующие тенденции развития
экономики предприятий
Показатель
1960-1980 гг.
1980-1990 гг.
1990-2000 гг.
2000-2020 гг.
Длительность
жизненного цикла 10 лет
продукции
Несколько
лет
Менее одного года
Несколько
месяцев
Конкуренция
Отсутствует
Национальные
компании
Мировые компании
Глобализация
экономики
Производство
Массовое
Партионное
По заказам
Персонализация заказов
Качество продукции Брак >10%
Частота
обновления
запасов,
раз/год
Метод управления
2-5
MPS
Брак не более 1%
Наличие
TQM
системы
качества
Непрерывно
5-50
50-100
CSRM,
e-Commerce
WCM, Virtual Enterprise
ERP II, CRM, SRM, SCM
BPM
MRP II ERP I JIT
Системы
управления
знаниями
MRP
37

38.

MPS- главный календарный план производства (Master
Production Schedule, MPS) или «Главного плана-графика
производства».
MRP — Material Requirements Planning (планирование
потребности).
Электронная торговля.
3838
38

39. Задачи предприятий:

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

40. Требования со стороны рынка к КИС

- открытая архитектура построения;
- распределенная система обработки данных;
- развитая коммуникационная подсеть (интрасеть);
- многоплатформенность приложений и баз данных.
Создание КИС обусловлено потребностью системы
управления
предприятием
в
реализации
новых
информационных технологий управления.
40

41. ПОНЯТИЕ ИНТЕГРИРОВАННОЙ ИС

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

42. Причины низкой эффективности управления компаниями в России 

Причины низкой эффективности управления
компаниями в России
Согласно исследованиям консалтинговой компании
McKinsey, основной причиной низкой производительности труда
(на уровне 19% от западной), низкой конкурентоспособности и
прибыльности отечественных компаний является низкое
качество управления. Причина низкой эффективности
управления во многих случаях достаточно проста — это
отсутствие целостной корпоративной системы управления,
объединяющей все информационные ресурсы компании.
Руководители в любой момент времени должны знать, какими
ресурсами
они
располагают,
насколько
эффективно
используются эти ресурсы, какую прибыль они приносят. Для
успешной работы компании всегда необходимо иметь самую
свежую, достоверную и полную информацию, анализ которой
позволяет оперативно реагировать на изменения рынка.
42

43. Специфика «кусочной» автоматизации

При «кусочной» автоматизации
на предприятии
раpабатываются не связанные между собой подсистемы
(например,
бухучет,
склады,
сбыт,
автотранспорт,
производственные подсистемы и т.д.), т.е. нет единой
информационной базы. В случае «кусочной» автоматизации
сотрудник отдела сбыта формирует служебную записку в
производственный отдел о ходе выполнения заказа клиента.
Подписывает служебную записку у начальника своего отдела.
43

44.

Передает подписанную служебную записку в
производственный отдел. Начальник производственного
отдела регистрирует служебную записку и передает записку
сотруднику, который отвечает за выполнение заказа клиента.
Тот ставит данную работу в очередь. Затем, когда доходит
очередь до этой работы, этот сотрудник по своей базе
определяет кто и в каких подразделениях отвечает за
выполнение заказа, обзванивает сотрудников цехов,
формирует письменный отчет, подписывает у начальника
производственного отдела, и передает в отдел сбыта
сотруднику сделавшему запрос. На отработку запроса может
понадобиться несколько дней!!!
44

45.

"Инвестиции в бардак этот бардак
только увеличивают" - это следствие из IIго закона термодинамики для общества.
45

46. Базовые принципы построения ИС

Рассмотрим базовые принципы построения ИС,
которые сформировались на современном этапе:
- масштабируемость;
- надежность;
- управляемость;
- опора на стандарты.
46
46

47. Масштабируемость

Масштабируемость
подразумевает
возможность
увеличить необходимую производительность системы, как
по количеству операций, так и по числу пользователей.
Может
сложиться
впечатление,
что
обеспечить
масштабируемость достаточно просто: необходимо просто
купить более мощное и производительное оборудование, и
проблема решена. Это верно лишь отчасти —
масштабирование наращиванием мощности работает только
до определенного уровня или, точнее, до момента «разрыва
непрерывности».
47

48.

Невозможно масштабировать прикладную программу,
написанную в незапамятные времена «на коленке»,
принципиально не понимающую распараллеливания или
многопроцессорности. Но это масштабы, до которых еще
нужно дожить. А вот для нашего малого и среднего бизнеса
очень характерна другая ситуация. Не секрет, что большая
часть расчетов и планов строится сотрудниками в
электронных таблицах — Excel. До определенного этапа
развития это нормально и экономически оправдано.
48

49. Надежность

Основное значение этого параметра: оценивать
устойчивость системы к сбоям, включая такие экстремальные
ситуации, как катастрофы. Современные технологии позволяют
создавать исключительно эффективные системы, устойчивые
практически к любым внешним воздействиям, вплоть до уровня
трансконтинентальных кластеров (локальная и глобальные
отказоустойчивости).
Уровень
надежности
определяется
процентом времени, которое система находится в рабочем
состоянии. Скажем, 0,99999 или, в просторечье, «пять девяток»,
обеспечивает такой уровень надежности, что в течение года
система будет в простое состоянии всего 5 минут в год!!! Такой
нижний уровень надежности предъявляется для банковских
систем. Сервера в банке Ак Барс имеют четырехкратное
резервирование!!!
В понятие «надежность» входит и защищенность от
внешних воздействий и кражи информации.
49

50. Управляемость

ИС не должна отнимать слишком много ресурсов на
свое обслуживание. В небольших и средних организациях
обычно пренебрегают эти фактором, считая, что он
проявляется только при сотнях и тысячах пользователей, но
это не всегда правильно, особенно на «кусочно»
автоматизированных предприятиях (до 30% затрат ИТ
отделов связано на интеграцию подсистем).
50

51. Опора на стандарты. При разработку ИС использовать самые современные инструментальные средства разработки!!!

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

52. Особенности управлению программными проектами

52

53. Отличия программной инженерии от других отраслей

Standish Group, проанализировав работу сотен
американских корпораций и итоги выполнения нескольких
десятков тысяч проектов, связанных с разработкой ПО, в
своем докладе с красноречивым названием «Хаос» пришла к
следующим неутешительным выводам.
53

54. Успешность программных проектов

54

55. Кто виноват?

Кто виноват? Никто. Cамого-то «хаоса» не было, и нет, а
есть лишь Богом данная (для атеистов — объективная)
реальность, которая заключена в особой специфике
производства программ, по сравнению с любой другой
производственной деятельностью, потому что то, что
производят программисты — нематериально, это
коллективные ментальные модели, записанные на языке
программирования.
То, что производят программисты нематериально — это
коллективные мысли и идеи, выраженные на языке
программирования.
55

56.

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

57. Причины неудачных проектов

1. Недостаточно адекватное управление требованиями.
2. Несогласованность требований, проектных решений и
реализации.
3. Жесткая архитектура ПО.
4. Нарастающая сложность ПО.
5. Неточная и противоречивая коммуникация.
6. Недостаточное тестирование.
7. Субъективное отношение к приоритетам отдельных
артефактов проекта.
8. Игнорирование рисков и отсутствие процедур
управления рисками.
9. Бесконтрольное внесение изменений в артефакты
проекта.
10. Недостаточное использование CASE-средств и
средств поддержки отдельных этапов проекта.
57

58. Отсутствие моделей при разработке ПО

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

59. Термин «Инструментальные средства информационных систем»

Инструментальные средства ИС — комплекс
программно-технических средств предназначенных для
автоматизации разработки ИС.
59

60. Лучшие практики разработки ПО

- использование визуальных моделей при разработке
ПО;
- итеративная разработка ПО;
- управление требованиями;
- управление изменениями и конфигурацией артефактов ПО;
- использование компонентных архитектур;
- непрерывное тестирование и верификация качества ПО;
- использование паттернов проектирования;
- использование CASE-средств.
Управление рисками:
- технологическими рисками;
- связанными с требованиями;
- связанными с квалификацией персонала проекта;
- политическими рисками.
60

61. МОДЕЛЬ ЗРЕЛОСТИ ПРОЦЕССОВ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Наилучшее решение проблемы надёжности – с
самого начала не допускать ошибок в программе.
61

62. Производственный процесс

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

63. Организация CMM по пяти уровням зрелости определяет приоритеты работ по развитию производственного процесса.

63

64.

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

65.

3)
Определенный.
Производственный
процесс
документирован и стандартизован как для управленческих
работ, так и для проектирования. Этот процесс интегрирован
в стандартный производственный процесс организации. Во
всех
проектах
используется
утвержденная
адаптированная версия стандартного производственного
процесса организации.
4) Управляемый. Собираются подробные количественные показатели производственного процесса и
качества создаваемого продукта. Как производственный
процесс, так и продукты оцениваются и контролируются
с количественной точки зрения.
65

66.

5)
Оптимизирующий.
Постоянное
совершенствование
процесса
достигается
благодаря количественной обратной связи с
процессом и реализации передовых идей и
технологий.
75% программного кода переходит в
новые проекты!!! Практически 100% гарантия
уложиться в срок и бюджет!!!
66

67. Объектно-ориентированный анализ и проектирование (ООАП) – основные понятия

Объектно-ориентированный анализ и проектирование
(Object-Oriented Analysis/Design) — технология разработки
программных систем, в основу которых положена объектноориентированная методология представления предметной
области в виде объектов, являющихся экземплярами
соответствующих классов
Предметная область (domain) – часть реального мира,
которая имеет существенное значение или непосредственное
отношение к процессу функционирования программы
Диаграмма (diagram) — графическое представление
совокупности элементов модели в форме связного графа,
вершинам и ребрам (дугам) которого приписывается
определенная семантика,
Нотация канонических диаграмм является основным
средством разработки моделей на языке UML.
67

68. ОСНОВНЫЕ КОНЦИИ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ (ООП)

ОСНОВНЫЕ КОНЦИИ ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ (ООП)
Мир состоит из систем.
Системы состоят из объектов.
Объекты некоторым образом взаимодействуют между
собой.
Каждый объект характеризуется своим состоянием и
поведением.
68

69. Принципы ООП

Инкапсуляция.
Наследование.
Полиморфизм.
69

70. Инкапсуляция

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

71. Наследование

1. Возможность порождать один класс от другого с
сохранением всех свойств и методов класса – предка (иногда
его называют суперклассом или родительским классом)
добавляя при необходимости новые свойства и методы.
2. Призвано отобразить такое свойство реального мира, как
иерархичность.
71

72. Полиморфизм

1. Классы – потомки могут изменять реализацию метода
класса – предка, сохраняя его сигнатуру (таким образом,
сохраняя неизменным интерфейс класса – предка).
Сигнатура - это описание функции, которое включает в
себя название, тип возвращаемого значения, типы
аргументов.
2. Позволяет обрабатывать объекты классов – потомков
как однотипные объекты, несмотря на то, что реализация
методов у них может различаться.
72

73. Канонические диаграммы языка UML 2.х

Диаграмма
Диаграмма
структуры
Диаграмма
классов
Диаграмма
компонентов
Диаграмма
развертывания
Диаграмма
поведения
Диаграмма
объектов
Диаграмма
композитной
структуры
Диаграмма
деятельности
Диаграмма
пакетов
Диаграмма
конечного
автомата
Диаграмма
взаимодействия
Диаграмма
последовательности
Диаграмма
вариантов
использования
Диаграмма
обзора
взаимодействия
Диаграмма
коммуникации
Временная
диаграмма
73

74. Использование языка UML в проектах по отраслевой принадлежности

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

75. Средний проект по разработке ПО:

- 5-10 человек;
- 10-15 месяцев;
- 10-15 задач;
- незначительная неопределенность и риски.
75

76. Диаграмма вариантов использования (use case diagram)

77. Диаграмма вариантов использования (ВИ) (use case diagram)

Диаграмма, на которой изображаются ВИ проектируемой
системы, заключенные в границу системы, и внешние актеры, а
также определенные отношения между актерами и вариантами
использования.
<<extend>>
Клиент Банка
Пополнить счет
Открыть счет
варианты использования
актеры
Кассир
<<extend>>
Операционист
ассоциации
Снять деньги со счета
Закрыть счет
зависимость с текстовым
стереотипом
77

78. Назначение диаграммы вариантов использования

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

79. Проектируемая система и ее окружение

Предоставляемые
сервисы
Предоставляемые
сервисы
ПРОЕКТИРУЕМАЯ
СИСТЕМА
Пользователи
системы
Заинтересованные
лица
Субъект (subject) – любой элемент модели,
который обладает функциональным поведением
79

80. Основные обозначения на диаграмме вариантов использования

80

81. Вариант использования (use case)

Вариант использования (use case)
– представляет собой общую спецификацию совокупности
выполняемых системой действий с целью предоставления
некоторого наблюдаемого результата, который имеет значение
для одного или нескольких актеров
Отвечает на вопрос «Что должна выполнять система?», не
отвечая на вопрос «Как она должна выполнять это?»
Имена – отглагольное существительное или глагол в
неопределенной форме.
<<use case>>
Формирование отчета по
выполненным заказам
Проверка состояния
текущего счета клиента
Формирование отчета по
выполненным заказам
81

82. Актер (actor)

– любая внешняя по отношению к проектируемой системе
сущность, которая взаимодействует с системой и использует ее
функциональные возможности для достижения определенных
целей или решения частных задач
Примеры актеров: кассир, клиент банка, банковский
служащий, президент, продавец магазина, менеджер отдела
продаж,
пассажир
авиарейса,
водитель
автомобиля,
администратор гостиницы, сотовый телефон
Клиент банка
<<actor>>
Посетитель
Интернет-магазина
Удаленный
пользователь
82

83. Вопросы для идентификации актеров в системе

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

84. Отношения на диаграмме вариантов использования

84

85. Отношение ассоциации

Ассоциация
(association)
является
одним
из
фундаментальных понятий в языке UML 2.х и может
использоваться на различных канонических диаграммах при
построении визуальных моделей
Применительно к диаграммам вариантов использования
отношение ассоциации может служить только для обозначения
взаимодействия актера с вариантом использования.
Просмотр списка
представленных товаров
Посетитель
Интернет-магазина
85

86. Отношение включения

Отношение зависимости (dependency) определяется как
форма взаимосвязи между двумя элементами модели,
предназначенная для спецификации того обстоятельства, что
изменение одного элемента модели приводит к изменению
некоторого другого элемента.
Отношение включения (include) специфицирует тот факт,
что некоторый вариант использования содержит поведение,
определенное в другом варианте использования
Оформление Заказа в
Интернет-магазине
вариант использования А
<<include>>
Регистрация
покупателя
вариант использования Б
86

87. Отношение расширения

Отношение расширения (extend) определяет взаимосвязь
одного варианта использования с некоторым другим
вариантом использования, функциональность или поведение
которого задействуется первым не всегда, а только при
выполнении некоторых дополнительных условий.
Оформление Заказа в
Интернет-магазине
вариант использования А
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
вариант использования Б
87

88. Изображение отношения расширения с условием выполнения

Условие: {клиент имеет бонусную карточку}
extention point:Скидка
Оформление Заказа в
Интернет-магазине
extention point
Скидка
<<extend>>
Предоставление бонусной
скидки постоянному
покупателю
88

89. Отношение обобщения

Отношение обобщения (generalization relationship)
предназначено для спецификации того факта, что один
элемент модели является специальным или частным случаем
другого элемента модели
Оплата выбранного в
Интернет-магазине товара
Оплата товара по
кредитной карточке
вариант использования А
вариант использования Б
Посетитель
Интернет-магазина
Покупатель
(актер А)
(актер Б)
89

90. Пример диаграммы ВИ для системы продажи товаров в Интернет-магазине

Система продажи товаров в Интернет-магазине
Просмотр списка
товаров
Изменение списка
товаров
Посетитель
Интернетмагазина
Изменение содержания
корзины
Оформление Заказа
на покупку товаров
<<include>>
<<extend>>
Менеджер
Регистрация
покупателя
Предоставление
бонусной скидки
Покупатель
Оплата выбранного
товара
Бухгалтер
Оплата товара
наличными
Оплата товара по
кредитной карточке
90

91. Формализация функциональных требований с помощью диаграммы ВИ

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

92. Классификация требований – модель FURPS+

Functionality
– функциональные требования
Usability (требования практичности)
Reliability (требования надежности)
Performance (требования производительности)
Supportability (требования обслуживания и
сопровождения)
Дополнительно + IEEE 610.12.1990
– Проектные ограничения
– Требования выполнения
– Требования к GUI
– Физические требования
92

93. Functionality – функциональные требования

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

94. Спецификация ВИ с помощью текстовых сценариев

Сценарий (scenario) – специально написанный текст, который
описывает поведение моделируемой системы в форме
последовательности выполняемых действий актеров и самой
системы.
94

95. Показатели качества для модели вариантов использования

Все ли функциональные требования описываются
вариантами использования?
Не содержит ли модель вариантов использования
ненужное поведение, которое отсутствует в требованиях?
Действительно ли в модели необходимы все выявленные
связи включения, расширения и обобщения?
Правильно ли произведено деление модели на пакеты
вариантов использования?
Стала ли модель в результате деление на пакеты проще и
удобнее для восприятия и сопровождения?
Можно ли на основе модели вариантов использования
составить четкое представление о функционировании системы
в контексте ее пользователей?
95

96. Последовательность разработки вариантов использования

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

97. Типичные ошибки при разработке диаграмм вариантов использования

1. Превращение диаграммы вариантов использования в
диаграмму деятельности за счет желания отразить все
функциональные действия.
2. Инициатором действий является разрабатываемая
система
Спецификация атрибутов и операций классов до того, как
сформулированы все варианты использования.
3.
Задание
слишком
кратких
имен
вариантам
использования.
4. Описание вариантов использования в терминологии,
непонятной пользователям системы или заказчику.
5.
Отсутствие
описаний
альтернативных
последовательностей действий.
6. Тратится слишком много времени на решение вопросов о
том, какие стереотипы и ассоциации использовать на
диаграмме.
97

98. Шаблон ВИ. Пример№1

Сценарий №1 выполнения варианта использования
"Снятие наличных по кредитной карточке"
Главный раздел
Вариант использования:
Снятие
наличных
по
кредитной
карточке
Актеры:
Клиент Банкомата, Банк
Цель:
Получение
требуемой
суммы
наличными
Краткое описание:
Клиент использует свою карточку для
снятия наличных. Клиент запрашивает требуемую сумму.
Банкомат обеспечивает доступ к счету клиента. Банкомат выдает
клиенту наличные.
Тип:
Базовый
Ссылки на другие варианты использования: Включает в себя
ВИ:
– Проверка ПИН-кода кредитной карточки
98

99. Раздел Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство чтения
банкомата
2. Банкомат передает информацию о кредитной карточке в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна (утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
7. Банкомат отображает опции меню
8. Клиент выбирает снятие наличных со своего счета
9. Банкомат предлагает ввести требуемую сумму

100. Раздел Типичный ход событий

10. Клиент вводит требуемую сумму
11. Банкомат делает соответствующий запрос в Банк
12. Банк проверяет введенную сумму
Исключение №5: Требуемая сумма превышает сумму на счете
клиента
13. Банк изменяет состояние счета клиента
15. Клиент получает свою кредитную карточку
Исключение №6: Клиент выбрал печать чека
14. Банкомат предлагает клиенту забрать его кредитную карточку
16. Банкомат выдает наличные и предлагает забрать их клиенту
17. Клиент получает наличные
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
100

101. Раздел Исключений

Исключение №1. Кредитная карточка недействительна
(утрачена)
4. Банкомат блокирует кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает клиенту забрать его кредитную карточку
15. Клиент получает свою кредитную карточку
18. Банкомат отображает сообщение о готовности к дальнейшей
работе
Исключение №3. Введенный ПИН-код неверный
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит ПИН-код
101

102. Сценарий №2 "Получение справки о состоянии счета"

Сценарий №2 "Получение справки о состоянии счета"
Главный раздел
Вариант использования:
Получение
справки
о
состоянии счета
Актеры: Клиент Банкомата, Банк
Цель:
Получение информации о балансе
Краткое описание:
Клиент использует свою карточку
для получения справки о состоянии счета. Банкомат
обеспечивает доступ к счету клиента. Банкомат выдает клиенту
справку в форме чека.
Тип:
Базовый
Ссылки на другие варианты использования:
Включает в себя ВИ:
– Проверка ПИН-кода кредитной карточки
102

103. Типичный ход событий

1. Клиент вставляет кредитную карточку в устройство
чтения банкомата
2. Банкомат передает информацию о кредитной карточке
в Банк
3. Банк проверяет информацию о кредитной карточке
Исключение №1: Кредитная карточка недействительна
(утрачена)
Исключение №2: Кредитная карточка просрочена
4. Банкомат предлагает ввести ПИН-код
5. Клиент вводит PIN-код
6. Банкомат проверяет ПИН-код
Исключение №3: Введенный ПИН-код неверный
Исключение №4: Клиент ввел неверный ПИН-код 3 раза
103

104. Типичный ход событий

7. Банкомат отображает опции меню
8. Клиент выбирает получение справки о состоянии счета
9. Банкомат делает соответствующий запрос в Банк
10. Банкомат предлагает клиенту забрать его кредитную
карточку
11. Клиент получает свою кредитную карточку
12. Банкомат выдает справку о состоянии счета и
предлагает забрать ее клиенту
13. Клиент получает справку о состоянии своего счета
14. Банкомат отображает сообщение о готовности к
дальнейшей работе
104

105. Раздел Исключений

Исключение №1. Кредитная карточка недействительна
(утрачена).
4. Банкомат блокирует кредитную карточку.
14. Банкомат отображает сообщение о готовности к
дальнейшей работе.
Исключение №2: Кредитная карточка просрочена.
4. Банкомат предлагает клиенту забрать его кредитную
карточку.
11. Клиент получает свою кредитную карточку.
14. Банкомат отображает сообщение о готовности к
дальнейшей работе.
Исключение №3. Введенный ПИН-код неверный.
4. Банкомат предлагает ввести ПИН-код.
5. Клиент вводит ПИН-код.
Исключение №4: Клиент вводит неверный ПИН-код 3 раза.
4. Банкомат блокирует кредитную карточку.
18. Банкомат отображает сообщение о готовности к
дальнейшей работе
105

106. Раздел Исключений

Исключение №4: Клиент вводит неверный ПИН-код 3 раза
4. Банкомат блокирует кредитную карточку.
18. Банкомат отображает сообщение о готовности к дальнейшей
работе.
Исключение №5. Требуемая сумма превышает сумму на счете
клиента.
9. Банкомат предлагает ввести новую сумму.
10. Клиент вводит новую требуемую сумму.
Исключение №6: Клиент выбрал печать чека.
16.1. Банкомат предлагает клиенту забрать чек.
Примечание. Клиент может отказаться от выполнения
транзакции "Снятие наличных по кредитной карточке" при введении
ПИН-кода, при выборе типа транзакции и при вводе суммы.
106

107. Диаграммы классов

107

108. Диаграммы классов. Термины.

Классом (Class) называется описание совокупности
объектов с общими атрибутами, операциями, отношениями и
семантикой. Графически класс изображается в виде
прямоугольника.
Диаграмма классов описывает типы объектов системы и
различного
рода
статические
отношения,
которые
существуют между ними. Имеется два основных вида
статических отношений:
ассоциации (например, клиент может взять напрокат ряд
видеокассет);
подтипы
(медсестра
является
разновидностью
личности).
На диаграммах классов изображаются также атрибуты
классов, операции классов и ограничения, которые
накладываются на связи между объектами.
108

109. Пример диаграммы классов. Диаграмма классов для варианта использования «Снять деньги»

Диаграмма классов определяет типы классов системы и
различного рода статические связи, которые существуют
между ними. На диаграммах классов изображаются также
атрибуты классов, операции классов и ограничения,
которые накладываются на связи между классами.
Диаграмма классов для варианта использования «Снять
деньги» показана на рис.
109

110. Диаграмма классов для варианта использования «Снять деньги»

110

111.

На этой диаграмме классов показаны связи между
классами, реализующими вариант использования «Снять
деньги». В этом процессе задействованы четыре класса:
Card Reader (устройство для чтения карточек), Account
(счет), ATM Screen (экран АТМ) и Cash Dispenser (кассовый
аппарат). Каждый класс на диаграмме выглядит в виде
прямоугольника, разделенного на три части. В первой
содержится имя класса, во второй – его атрибуты. В
последней части содержатся операции класса, отражающие
его поведение (действия, выполняемые классом).
111

112.

Связывающие
классы
линии
отражают
взаимодействие между классами. Так, класс Account связан
с классом ATM Screen (экран АТМ), потому что они
непосредственно сообщаются и взаимодействуют друг с
другом. Класс Card Reader (устройство для чтения
карточек) не связан с классом Cash Dispenser (кассовый
аппарат), поскольку они не сообщаются друг с другом
непосредственно.
112

113. Диаграммы классов. Стереотипы классов.

Стереотипы – это механизм, позволяющий разделять
классы на категории. В языке UML определены три
основных стереотипа классов:
Boundary (граница), Entity (сущность) и Control
(управление).
Граничные классы
Граничными классами (boundary classes) называются
такие классы, которые расположены на границе системы
и всей окружающей среды.
Это экранные
формы,
отчеты,
интерфейсы
с
аппаратурой (такой
как принтеры или сканеры) и
интерфейсы с другими системами.
113

114.

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

115. Диаграммы классов. Классы-сущности

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

116. Диаграммы классов. Управляющие классы.

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

117.

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

118. Диаграммы классов. Механизм пакетов.

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

119. Другой подход объединении классов

Другой подход заключается в объединении классов по
их функциональности. Например, в пакете Security
(безопасность) содержатся все классы, отвечающие за
безопасность приложения. В таком случае другие пакеты
могут
называться Employee Maintenance (Работа с
сотрудниками), Reporting (Подготовка отчетов) и Error
Handling (Обработка
ошибок).
Преимущество
этого
подхода
заключается в возможности повторного
использования.
119

120.

Механизм пакетов применим к любым элементам модели,
а не только к классам. Если для группировки классов не
использовать некоторые эвристики, то она становится
произвольной. Одна из них, которая в основном
используется в UML, – это зависимость. Зависимость
между двумя пакетами существует в том случае, если
между любыми двумя классами в пакетах существует
любая зависимость. Таким образом, диаграмма пакетов
представляет собой диаграмму, содержащую пакеты
классов и зависимости между ними. Строго говоря, пакеты
и зависимости являются элементами диаграммы классов,
то есть диаграмма пакетов – это форма диаграммы классов.
120

121. Диаграмма пакетов

121

122.

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

123.

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

124. Диаграммы классов. Атрибуты.

Атрибут – это элемент информации, связанный с
классом. Например, у класса Company (компания) могут
быть
атрибуты Name (Название), Address (Адрес) и
NumberOfEmployees (Число служащих).
Так как атрибуты содержатся внутри класса, они
скрыты
от
других классов. В связи с этим может
понадобиться указать, какие классы имеют право читать и
изменять атрибуты. Это свойство называется видимостью
атрибута (attribute visibility).
124

125. Диаграммы классов. Значения атрибутов.

1. Public (общий,
открытый «+»). Это
значение
видимости предполагает, что атрибут будет виден всеми
остальными классами. Любой класс может просмотреть или
изменить значение атрибута. В таком случае класс Company
может изменить значение атрибута Address класса
Employee. В соответствии с нотацией UML общему
атрибуту предшествует знак « + ».
2. Private (закрытый, секретный «-»). Соответствующий
атрибут не виден никаким другим классом. Класс
Employee будет знать значение атрибута Address и сможет
изменять его, но класс Company не сможет его ни увидеть, ни
редактировать. Если это понадобится, он должен попросить
класс Employee просмотреть или изменить значение этого
атрибута, что обычно делается с помощью общих
операций. Закрытый атрибут обозначается знаком « – » в
соответствии с нотацией UML.
125

126. Диаграммы классов. Значения атрибутов. Продолжение.

3. Protected (защищенный « # »). Такой атрибут
доступен только самому классу и его потомкам. Допустим,
что у нас имеется два различных типа сотрудников – с
почасовой оплатой и на окладе. Таким образом, мы
получаем два других класса HourlyEmp и SalariedEmp,
являющихся потомками класса Employee. Защищенный
атрибут Address можно просмотреть или изменить из
классов Employee, HourlyEmp и SalariedEmp, но не из
класса Company. Нотация UML для защищенного атрибута –
это знак « # ».
126

127. Диаграммы классов. Значения атрибутов. Продолжение.

4. Package or Implementation (пакетный). Предполагает,
что данный атрибут является общим, но только в пределах
его пакета. Допустим, что атрибут Address имеет пакетную
видимость. В таком случае он может быть изменен из
класса Company, только если этот класс находится в том
же пакете. Этот тип видимости не обозначается
никаким специальным значком.
127

128. Видимость атрибутов

128

129. Диаграммы классов. Значения атрибутов. Продолжение.

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

130. Диаграммы классов. Операции.

Операции
реализуют
связанное
с
классом
поведение. Операция включает три части – имя,
параметры и тип возвращаемого значения.
Параметры – это аргументы, получаемые операцией
«на входе». Тип возвращаемого значения относится к
результату действия операции.
На диаграмме классов можно показывать как имена
операций, так и имена операций вместе с их параметрами
и типом возвращаемого значения. Чтобы уменьшить
загруженность диаграммы, полезно бывает на некоторых
из них показывать только имена операций, а на других
их полную сигнатуру.
130

131. Диаграммы классов. Операции. Продолжение.

В языке UML операции имеют следующую нотацию:
Имя Операции (аргумент1 : тип данных аргумента1,
аргумент2 : тип данных аргумента2, ...) : тип
возвращаемого значения
131

132. Следует рассмотреть четыре различных типа операций. Операции реализации.

Операции
реализации (implementor operations)
реализуют некоторые бизнес-функции. Такие операции
можно найти, исследуя диаграммы взаимодействия.
Диаграммы этого типа фокусируются на бизнесфункциях, и каждое сообщение диаграммы, скорее всего,
можно соотнести с операцией реализации.
Каждая операция реализации должна быть легко
прослеживаема до соответствующего требования. Это
достигается
на
различных
этапах моделирования.
Операция выводится из сообщения на диаграмме
взаимодействия, сообщения исходят из подробного
описания потока событий, который создается на основе
варианта использования, а последний – на основе
требований.
132

133. Следует рассмотреть четыре различных типа операций. Операции реализации. Продолжение.

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

134. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции управления.

Операции управления (manager operations) управляют
созданием и уничтожением объектов. В эту категорию
попадают конструкторы и деструкторы классов.
134

135. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции доступа.

Атрибуты
обычно
бывают
закрытыми
или
защищенными. Тем не менее, другие классы иногда
должны просматривать или изменять их значения. Для
этого существуют операции доступа (access operations).
Пусть, например, у нас имеется атрибут Salary класса
Employee. Мы не хотим, чтобы все остальные классы
могли изменять этот атрибут.
Вместо этого к классу Employee мы добавляем две
операции доступа – GetSalary и SetSalary. К первой из
них, являющейся общей, могут обращаться и другие
классы. Она просто получает значение атрибута Salary и
возвращает его вызвавшему ее классу.
135

136. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Операции доступа. Продолжение.

Операция SetSalary
также является
общей,
она
помогает вызвавшему ее классу установить новое
значение атрибута Salary. Эта операция может содержать
любые правила и условия проверки, которые необходимо
выполнить, чтобы зарплата могла быть изменена.
Такой
подход
дает
возможность
безопасно
инкапсулировать атрибуты внутри класса, защитив их от
других классов, но все же позволяет осуществить к ним
контролируемый доступ. Создание операций Get и Set
(получения и изменения значения) для каждого атрибута
класса является стандартом.
136

137. Диаграммы классов. Следует рассмотреть четыре различных типа операций. Вспомогательные операции.

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

138. Чтобы идентифицировать операции, выполните следующие действия:

1.
Изучите
диаграммы
последовательности
и
кооперативные диаграммы. Большая часть сообщений на
этих диаграммах является операциями реализации.
2. Рассмотрите управляющие операции. Может
потребоваться добавить конструкторы и деструкторы.
3. Рассмотрите операции доступа. Для каждого
атрибута класса, с которым должны будут работать другие
классы, надо создать операции Get и Set.
138

139. Категории связей. Связь-зависимость.

В диаграмме классов могут участвовать связи трех
разных категорий: зависимость (dependency), обобщение
(generalization) и ассоциация (association).
Зависимостью называют связь по применению, когда
изменение в спецификации одного класса может повлиять
на поведение другого класса, использующего первый класс.
Чаще всего зависимости применяют в диаграммах классов,
чтобы отразить в сигнатуре операции одного класса тот
факт, что параметром этой операции могут быть объекты
другого класса.
139

140. Диаграмма классов со связью-зависимостью

Понятно, что если интерфейс второго класса изменяется,
это влияет на поведение объектов первого класса. Простой
пример диаграммы классов со связью-зависимостью
показан на рис.
140

141.

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

142. Связи-обобщения и механизм наследования классов в UML

Связью-обобщением называется связь между общей
сущностью, называемой суперклассом, или родителем, и
более специализированной разновидностью этой сущности,
называемой подклассом, или потомком. Обобщения иногда
называют связями «is a», имея в виду, что класс-потомок
является частным случаем класса-предка. Класс-потомок
наследует все атрибуты и операции класса-предка, но в нем
могут быть определены дополнительные атрибуты и
операции.
142

143.

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

144. Иерархия одиночного наследования классов

144

145.

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

146. Пример множественного наследования классов

146

147.

На этой диаграмме классы Студент и Преподаватель
порождены
из
одного
суперкласса
ЧеловекИзУниверситета. Вообще говоря, к классу Студент
относятся те объекты класса ЧеловекИзУниверситета,
которые
соответствуют
студентам,
а
к
классу
Преподаватель
–
объекты
класса
ЧеловекИзУниверситета,
соответствующие
преподавателям. Но, как это часто случается, многие студенты уже в
студенческие годы начинают преподавать, так, что могут
существовать такие два объекта классов Студент и
Преподаватель, которым соответствует один объект класса
ЧеловекИзУниверситета.
147

148.

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

149.

Следует отметить, что множественное наследование,
помимо того, что не слишком часто требуется на практике,
порождает ряд проблем, из которых одной из наиболее
известных является проблема именования атрибутов и
операций в подклассе, полученном путем множественного
наследования. Например, предположим, что при образовании
подклассов Студент и Преподаватель в них обоих был
определен атрибут с именем номерКомнаты. Очень вероятно,
что для объектов класса Студент значениями этого атрибута
будут номера комнат в студенческом общежитии, а для
объектов класса Преподаватель – номера служебных
кабинетов.
149

150.

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

151.

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

152. Связи-ассоциации: роли, кратность, агрегация

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

153.

С понятием ассоциации связаны четыре важных
дополнительных понятия: имя, роль, кратность и
агрегация. Во-первых, ассоциации может быть присвоено
имя, характеризующее природу связи. Смысл имени
уточняется с помощью черного треугольника, который
располагается над линией связи справа или слева от имени
ассоциации. Этот треугольник указывает направление чтения
имя связи. Пример именованной ассоциации показан на рис.
Треугольник показывает, что именованная ассоциация
должна читаться как «Студент учится в Университете».
153

154. Пример именованной ассоциации

154

155.

Другим способом именования ассоциации является
указание роли каждого класса, участвующего в этой
ассоциации. Роль класса задается именем, помещаемым под
линией ассоциации ближе к данному классу. На следующем
рис. показаны две ассоциации между классами Человек и
Университет, в которых эти классы играют разные роли. Как
мы видим, объекты класса Человек могут выступать в роли
РАБОТНИКОВ при участии в ассоциации, в которой
объекты класса Университет играют роль НАНИМАТЕЛЯ.
В другой ассоциации объекты класса Человек играют роль
СТУДЕНТА, а объекты класса УНИВЕРСИТЕТ – роль
ОБУЧАЮЩЕГО.
155

156. Две ассоциации с разными ролями классов

156

157.

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

158. Кратностью роли ассоциации

Кратностью (multiplicity) роли ассоциации называется
характеристика, указывающая, сколько объектов класса с
данной ролью может или должно участвовать в каждом
экземпляре ассоциации (в UML экземпляр ассоциации
называется соединением – link, но мы не будем здесь
использовать этот термин, чтобы не создавать путаницу –
все-таки трудно одновременно говорить про связи,
ассоциации и соединения, имея в виду разные понятия).
Наиболее распространенным способом задания кратности
роли ассоциации является указание конкретного числа или
диапазона. Например, указание «1» говорит о том, что
каждый объект класса с данной ролью должен участвовать в
некотором экземпляре данной ассоциации, причем в каждом
экземпляре ассоциации может участвовать ровно один
объект класса с данной ролью.
158

159.

Указание диапазона «0..1» говорит о том, что не все
объекты класса с данной ролью обязаны участвовать в
каком-либо экземпляре данной ассоциации, но в каждом
экземпляре ассоциации может участвовать только один
объект. Аналогично, указание диапазона «1..*» говорит о
том, что все объекты класса с данной ролью должны
участвовать в некотором экземпляре данной ассоциации, и
в каждом экземпляре ассоциации должен участвовать хотя
бы один объект (верхняя граница не задана). Толкование
диапазона «0..*» является очевидным расширением случая
«0..1».
159

160.

В более сложных (но крайне редко встречающихся на
практике)
случаях
определения
кратности
можно
использовать списки диапазонов. Например, список «2, 4..6,
8..*» говорит о том, что все объекты класса с указанной
ролью должны участвовать в некотором экземпляре данной
ассоциации, и в каждом экземпляре ассоциации должны
участвовать два, от четырех до шести или более семи
объектов класса с данной ролью.
160

161. Ассоциации с указанными кратностями ролей

161

162.

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

163. Агрегатная ассоциация (часть-целое)

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

164. Пример агрегатной ассоциации

164

165.

Объектами класса Аудитория являются студенческие
аудитории, в которых проходят занятия. В каждой аудитории
должны быть установлены парты. Поэтому в некотором
смысле класс Парта является «частью» класса Аудитория.
Мы умышленно сделали роль класса Парта необязательной,
поскольку могут существовать аудитории без парт
(например, класс для занятий танцами) и некоторые парты
могут находиться на складе. Обратите внимание, что, хотя
аудитории, не оснащенные партами, как правило,
непригодны для занятий, объекты классов Аудитория и
Парта существуют независимо. Если некоторая аудитория
ликвидируется, то находящиеся в ней парты не
уничтожаются, а переносятся на склад.
165

166. Агрегатная композициям

Бывают случаи, когда связь «части» и «целого»
настолько сильна, что уничтожение «целого» приводит к
уничтожению всех его «частей». Агрегатные ассоциации,
обладающие таким свойством, называются композитными,
или просто композициями. При наличии композиции
объект-часть может быть частью только одного объектацелого (композита). При обычной агрегатной ассоциации
«часть» может одновременно принадлежать нескольким
«целым». Графически композиция изображается в виде
простой ассоциации, дополненной закрашенным ромбом со
стороны «целого». Пример композитной агрегатной
ассоциации показан на рис.
166

167. Пример композитной агрегатной ассоциации

167

168.

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

169. 4-я лекция

169

170.

170

171.

171

172.

172

173. ПОВТОР. Диаграммы классов.

Классом (Class) называется описание совокупности
объектов с общими атрибутами, операциями, отношениями и
семантикой. Графически класс изображается в виде
прямоугольника.
Диаграмма классов описывает типы объектов системы и
различного
рода
статические
отношения,
которые
существуют между ними. Имеется два основных вида
статических отношений:
ассоциации (например, клиент может взять напрокат ряд
видеокассет);
подтипы
(медсестра
является
разновидностью
личности).
На диаграммах классов изображаются также атрибуты
классов, операции классов и ограничения, которые
накладываются на связи между объектами.
173

174.

174

175. Пример диаграмма классов для варианта использования «Снять деньги»

175

176. Особенности представления

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

177.

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

178.

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

179. ПОВТОР. Ассоциации

С
концептуальной
точки
зрения
ассоциации
представляют концептуальные отношения между классами.
На диаграмме показано, что Заказ может поступить только от
одного Клиента, а Клиент в течение некоторого времени
может сделать несколько Заказов. Каждый из этих Заказов
может содержать несколько Строк заказа, причем каждая
Строка заказа должна соответствовать единственному
Товару.
179

180. Навигация

На рис. предполагается, что существует один или более
методов, связанных с классом Клиент, с помощью которых
можно узнать, какие заказы сделал конкретный клиент.
Аналогично в классе Заказ существуют методы, с помощью
которых можно узнать, какой Клиент сделал конкретный
Заказ и какие Строки заказа входят в этот Заказ.
180

181. Атрибуты

На концептуальном уровне атрибут «имя Клиента»
указывает на то, что клиенты обладают именами. На
уровне спецификации этот атрибут указывает на то, что
объект Клиент может сообщить вам свое имя и обладает
некоторым способом для установления имени. На уровне
реализации объект Клиент содержит некоторое поле для
своего имени (называемое также переменной экземпляра или
элементом данных).
В зависимости от степени детализации диаграммы
обозначение атрибута может включать имя атрибута, тип и
присваиваемое по умолчанию значение. В синтаксисе языка
UML это выглядит следующим образом: <видимостъ>
<имя>: <тип> = <значение по умолчанию>, где видимость
имеет такой же смысл, как и для операций, описываемых в
следующем разделе.
181

182.

Атрибуты обычно имеют единственное значение. На
диаграмме, как правило, не показывается, является ли
атрибут обязательным или необязательным, хотя это можно
сделать, указав кратность в квадратных скобках после имени
атрибута, например получениеДанных[0..1 ]: Данные.
182

183. Операции

Операции представляют собой процессы, реализуемые
некоторым классом. Существует очевидное соответствие
между операциями и методами класса. На уровне
спецификации операции соответствуют общедоступным
методам над некоторым типом. Обычно можно не показывать
такие операции, которые просто манипулируют атрибутами,
поскольку они и так подразумеваются. Однако иногда
возникает необходимость показать, что данный атрибут
предназначен только для чтения (read-only) или является
неизменным (frozen), то есть его значение никогда не
изменяется. В модели реализации можно также указать
защищенные и закрытые операции.
183

184. Полный синтаксис операций

Полный синтаксис операций в языке UML выглядит
следующим образом:
где видимость может принимать одно из трех значений:
«+» общедоступная (public), «#» защищенная (protected) или
«-» закрытая (private).
имя представляет собой строку символов.
список-параметров содержит разделенные запятой
параметры, синтаксис которых аналогичен синтаксису
атрибутов: <направление> <имя>: <тип> = <значение по
умолчанию>. При этом дополнительным элементом является
направление, которое применяется, чтобы показать характер
использования параметра - для входа (in), выхода (out) или в
обоих направлениях (inout). Если значение направления
отсутствует, оно предполагается входным (in).
184

185. Полный синтаксис операций. Продолжение.

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

186. Операции запрос и модификация

Следует различать операции, изменяющие состояние
класса, и операции, не делающие этого. Язык UML
определяет запрос как некую операцию, которая получает
некоторое значение от класса, не изменяя при этом
состояние системы, другими словами, не производя
побочных эффектов. Такую операцию можно пометить
ограничением {запрос}. Операции, которые изменяют
состояние, называютя модификаторами.
186

187. Диаграммы взаимодействия

187

188.

Диаграммы
взаимодействия (interaction diagrams)
описывают поведение взаимодействующих групп объектов.
Как
правило,
диаграмма
взаимодействия
охватывает поведение объектов в рамках только
одного варианта использования. На такой
диаграмме отображается ряд объектов и те сообщения,
которыми они обмениваются между собой.
188

189.

Сообщение (message) – это средство, с помощью
которого объект-отправитель запрашивает у объекта
получателя выполнение одной из его операций.
Информационное (informative)
сообщение –
это
сообщение, снабжающее объект-получатель некоторой
информацией для обновления его состояния.
Сообщение-запрос (interrogative) – это сообщение,
запрашивающее выдачу некоторой информации об объектеполучателе.
Императивное (imperative)
сообщение –
это
сообщение,
запрашивающее
у
объекта-получателя
выполнение некоторых действий.
189

190. Диаграммы последовательности и кооперативные диаграммы

Существует два вида диаграмм взаимодействия:
диаграммы последовательности (sequence diagrams) и
кооперативные диаграммы (collaboration diagrams).
190

191. Диаграмм взаимодействия. Диаграммы последовательности.

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

192. Диаграмма последовательности для снятия клиентом денег со счета

Диаграмма
последовате
льности
для снятия
клиентом
денег со
счета
192

193.

Каждое сообщение представляется в виде стрелки
между линиями жизни двух объектов. Сообщения
появляются в том порядке, как они показаны на странице
сверху вниз. Каждое сообщение помечается как минимум
именем сообщения; при желании можно добавить также
аргументы и некоторую управляющую информацию, и,
кроме того, можно показать самоделегирование (selfdelegation) – сообщение, которое объект посылает самому
себе, при этом стрелка сообщения указывает на ту же
самую линию жизни.
193

194.

Эта диаграмма последовательности показывает поток
событий в рамках варианта использования «Снять
деньги». Все действующие лица показаны в верхней части
диаграммы; в приведенном выше примере изображено
действующее лицо Клиент. Объекты, требуемые системе
для выполнения варианта использования «Снять деньги»,
также представлены в верхней части диаграммы. Стрелки
соответствуют сообщениям,
передаваемым
между
действующим лицом и объектом или между объектами для
выполнения требуемых функций.
194

195. Сценарий действий

Под сценарием понимается конкретный экземпляр
потока
событий.
Поток
событий
для
варианта
использования «Снять деньги» говорит о человеке,
снимающем некоторую сумму денег со счета с помощью
АТМ.
Не все объекты появляются в потоке событий. Там,
например, может не быть форм для заполнения, но их
необходимо показать на диаграмме, чтобы позволить
действующему лицу ввести новую информацию в систему
или просмотреть её. В потоке событий, скорее всего,
также не будет и управляющих объектов (control objects). Эти
объекты управляют последовательностью потока в варианте
использования.
195

196. Диаграмм взаимодействия. Кооперативные диаграммы.

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

197. Кооперативная диаграмма, описывающая процесс снятия клиентом денег со своего счета

197

198.

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

199.

199

200. Диаграмма классов (class diagram) . Повторение.

Центральное место в ООАП занимает разработка
логической модели системы в виде диаграммы классов.
Нотация классов в языке UML проста и интуитивно
понятна всем, кто когда-либо имел опыт работы с CASEинструментариями. Схожая нотация применяется и для
объектов – экземпляров класса, с тем различием, что к
имени класса добавляется имя объекта и вся надпись
подчеркивается.
200

201.

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

202.

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

203.

Диаграмма классов представляет собой некоторый граф,
вершинами
которого
являются
элементы
типа
«классификатор», которые связаны различными типами
структурных отношений. Следует заметить, что диаграмма
классов может также содержать интерфейсы, пакеты,
отношения и даже отдельные экземпляры, такие как объекты
и связи. Когда говорят о данной диаграмме, имеют в виду
статическую структурную модель проектируемой системы.
Поэтому диаграмму классов принято считать графическим
представленном таких структурных взаимосвязей логической
модели системы, которые не зависят или инвариантны от
времени.
203

204.

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

205. Класс

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

206.

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

207.

Даже если секция атрибутов и операций является пустой,
в обозначении класса она выделяется горизонтальной
линией, чтобы сразу отличить класс от других элементов
языка UML. Примеры графического изображения классов на
диаграмме классов приведены на рис. . В первом случае для
класса «Прямоугольник» (рис. а) указаны только его
атрибуты – точки на координатной плоскости, которые
определяют его расположение. Для класса «Окно» (рис. б)
указаны только его операции, секция атрибутов оставлена
пустой. Для класса «Счет» (рис. в) дополнительно
изображена четвертая секция, в которой указано исключение
– отказ от обработки просроченной кредитной карточки.
207

208.

208

209. Атрибуты класса

Во второй сверху секции прямоугольника класса
записываются его атрибуты (attributes) или свойства. В языке
UML принята определенная стандартизация записи
атрибутов класса, которая подчиняется некоторым
синтаксическим правилам. Каждому атрибуту класса
соответствует отдельная строка текста, которая состоит из
квантора видимости атрибута, имени атрибута, его
кратности, типа значений атрибута и, возможно, его
исходного значения:
<квантор видимости><имя атрибута>[кратность]:
<тип атрибута> = <исходное значение>{строка-свойство}
209

210.

Квантор видимости может принимать одно из трех
возможных значений и, соответственно, отображается при
помощи специальных символов:
• Символ "+" обозначает атрибут с областью видимости
типа общедоступный (public). Атрибут с этой областью
видимости доступен или виден из любого другого класса
пакета, в котором определена диаграмма.
• Символ "#" обозначает атрибут с областью видимости
типа защищенный (protected). Атрибут с этой областью
видимости недоступен или невиден для всех классов, за
исключением подклассов данного класса.
210

211.

И, наконец, знак "-" обозначает атрибут с областью
видимости типа закрытый (private). Атрибут с этой областью
видимости недоступен или невиден для всех классов без
исключения.
Квантор видимости может быть опущен. В этом случае
его отсутствие просто означает, что видимость атрибута не
указывается. Эта ситуация отличается от принятых по
умолчанию
соглашений
в
традиционных
языках
программирования, когда отсутствие квантора видимости
трактуется как public или private. Однако вместо условных
графических
обозначений
можно
записывать
соответствующее ключевое слово: public, protected, private.
211

212.

Имя атрибута представляет собой строку текста, которая
используется в качестве идентификатора соответствующего
атрибута и поэтому должна быть уникальной в пределах
данного класса. Имя атрибута является единственным
обязательным элементом синтаксического обозначения
атрибута.
Кратность атрибута характеризует общее количество
конкретных атрибутов данного типа, входящих в состав
отдельного класса. В общем случае кратность записывается в
форме строки текста в квадратных скобках после имени
соответствующего атрибута:
[нижняя_граница1
..
верхняя_граница1,
нижняя_граница2.. верхняя_грашца2, ..., нuжняя_гpaнuцak ..
верхняя_границаk],
212

213.

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

214.

В качестве примера рассмотрим следующие варианты
задания кратности атрибутов.
[0..1] означает, что кратность атрибута может принимать
значение О или 1. При этом 0 означает отсутствие значения
для данного атрибута.
[0..*] означает, что кратность атрибута может принимать
любое положительное целое значение большее или равное 0.
Эта кратность может быть записана короче в виде простого
символа – [*].
[1.:*] означает, что кратность атрибута может принимать
любое положительное целое значение большее или равное 1.
[1..5] означает, что кратность атрибута может принимать
любое значение из чисел: 1, 2, 3, 4, 5.
214

215.

[1..3,5,7] означает, что кратность атрибута может
принимать любое значение из чисел: 1, 2, 3, 5, 7.
[1..3,7.. 10] означает, что кратность атрибута может
принимать любое значение из чисел: 1, 2, 3, 7, 8, 9, 10.
[1..3,7..*] означает, что кратность атрибута может
принимать любое значение из чисел: 1, 2, 3, а также любое
положительное целое значение большее или равное 7.
Если кратность атрибута не указана, то по умолчанию
принимается ее значение равное 1..1, т. е. в точности 1.
215

216.

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

217.

Можно привести следующие примеры задания имен и
типов атрибутов классов:
• цвет: Соlоr – здесь цвет является именем атрибута, Color
– именем типа данного атрибута. Указанная запись может
определять традиционно используемую RGB-модель
(красный, зеленый, синий) для представления цвета. В этом
случае имя типа Color как раз и характеризует
семантическую конструкцию, которая применяется в
большинстве языков программирования для представления
цвета.
217

218.

• имя_сотрудника [1..2] : String – здесь имя_сотрудника
является именем атрибута, который служит для
представления информации об имени, а возможно, и
отчестве конкретного сотрудника. Тип атрибута String
(Строка) как раз и указывает на тот факт, что отдельное
значение имени представляет собой строку текста из одного
или двух слов (например, «Кирилл» или «Дмитрий
Иванович»). Поскольку во многих языках программирования
существует
тип
данных
String,
использование
соответствующего англоязычного термина не вызывает
недоразумения у большинства программистов. Однако, хотя
в языке UML все термины даются в англоязычном
представлении, использование в качестве типа атрибута
Строка в данной ситуации не исключается и определяется
218
только соображениями удобства.

219.

• видимость:Boolean – здесь видимость есть имя
абстрактного атрибута (курсив здесь не случаен), который
может характеризовать наличие визуального представления
соответствующего класса на экране монитора. В этом случае
тип Boolean означает, что возможными значениями данного
атрибута является одно из двух логических значений: истина
(true) или ложь (false). При этом значение истина может
соответствовать наличию графического изображения на
экране монитора, а значение ложь – его отсутствию, о чем
дополнительно указывается в пояснительном тексте.
Поскольку кратность атрибута видимость не указана, она
принимает значение 1 по умолчанию. В этой ситуации
англоязычное имя типа атрибута вполне оправдано наличием
соответствующего
базового
типа
в
языках
219
программирования.

220.

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

221.

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

222.

В качестве примеров исходных значений атрибутов
можно привести следующие дополненные выше варианты
задания атрибутов:
• цвет:Соlоr = (255, 0, 0) – в RGB-модели цвета это
соответствует чистому красному цвету в качестве исходного
значения для данного атрибута.
• имя_сотрудника[1..2]:String = Иван Иванович –
возможно, это нетипичный случай, который.
222

223.

• видимость:Вооlеаn = истина – может соответствовать
ситуации, когда в момент создания экземпляра класса
создается
видимое
на
экране
монитора
окно,
соответствующее данному объекту.
• форма:Многоугольник = прямоугольник – вряд ли
требует комментариев, поскольку здесь речь идет о
геометрической форме создаваемого объекта.
223

224.

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

225.

Например, если некоторый атрибут задан в виде форма:
Прямоугольник. то это будет означать, что все объекты
данного класса могут иметь несколько различных форм,
каждая из которых является прямоугольником. Другим
примером может служить задание атрибута в виде
номер_счета:Integer. что может означать для объекта
Сотрудник наличие некоторого подмножества счетов, общее
количество которых заранее не фиксируется.
225

226.

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

227.

Например,
строка-свойство
в
записи
атрибута
заработная_плата:Currency = = {$500} может служить для
обозначения фиксированной заработной платы для каждого
объекта класса «Сотрудник» определенной должности в
некоторой организации. С другой стороны, запись данного
атрибута в виде заработная_плата: Currency = $500
означает уже нечто иное, а именно – при создании нового
экземпляра Сотрудник (аналогия – прием на работу нового
сотрудника) для него устанавливается по умолчанию
заработная плата в $500. Однако для отдельных сотрудников
могут быть сделаны исключения как в большую, так и в
меньшую сторону, о чем необходимо позаботиться
дополнительно в программе.
227

228. Операция

В третьей сверху секции прямоугольника записываются
операции или методы класса. Операция (operation)
представляет собой некоторый сервис, предоставляющий
каждый экземпляр класса по определенному требованию.
Совокупность операций характеризует функциональный
аспект поведения класса. Запись операций класса в языке
UML также стандартизована и подчиняется определенным
синтаксическим правилам. При этом каждой операции
класса соответствует отдельная строка, которая состоит из
квантора видимости операции, имени операции, выражения
типа возвращаемого операцией значения и, возможно,
строка-свойство данной операции:
<квантор
видимости><имя
операции>(список
параметров):
<выражение типа возвращаемого значения>{строкасвойство}
228

229.

Квантор видимости, как и в случае атрибутов класса,
может принимать одно из трех возможных значений и,
соответственно, отображается при помощи специального
символа. Символ "+" обозначает операцию с областью
видимости типа общедоступный (public). Символ "#"
обозначает операцию с областью видимости типа
защищенный (protected). И, наконец, символ "-" используется
для обозначения операции с областью видимости типа
закрытый (private).
Квантор видимости для операции может быть опущен. В
этом случае его отсутствие просто означает, что видимость
операции не указывается. Вместо условных графических
обозначений также можно записывать соответствующее
ключевое слово: public, protected, private.
229

230.

Имя операции представляет собой строку текста, которая
используется в качестве идентификатора соответствующей
операции и поэтому должна быть уникальной в пределах
данного класса. Имя атрибута является единственным
обязательным элементом синтаксического обозначения
операции.
Список параметров является перечнем разделенных
запятой формальных параметров, каждый из которых может
быть представлен в следующем виде:
<вид
параметра><имя
параметра>:<выражение
типа>=<значение параметра по умолчанию>.
230

231.

Здесь вид параметра – есть одно из ключевых слов in, out
или inout со значением in по умолчанию, в случае если вид
параметра
не
указывается.
Имя
параметра
есть
идентификатор соответствующего формального параметра.
Выражение типа является зависимой от конкретного
языка
программирования
спецификацией
типа
возвращаемого значения для соответствующего формального
параметра. Наконец, значение по умолчанию в общем случае
представляет собой выражение для значения формального
параметра, синтаксис которого зависит от конкретного языка
программирования и подчиняется принятым в нем
ограничениям.
231

232.

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

233. Отношения между классами

Кроме внутреннего устройства или структуры классов на
соответствующей диаграмме указываются различные
отношения между классами. При этом совокупность типов
таких отношений фиксирована в языке UML и
предопределена семантикой этих типов отношений.
Базовыми отношениями или связями в языке UML
являются:
• Отношение зависимости (dependency relationship)
• Отношение ассоциации (association relationship)
• Отношение обобщения (generalization relationship)
• Отношение реализации (realization relationship)
Каждое из этих отношений имеет собственное
графическое представление на диаграмме, которое отражает
взаимосвязи между объектами соответствующих классов.
233

234. Отношение зависимости

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

235.

Отношение зависимости графически изображается
пунктирной линией между соответствующими элементами
со стрелкой на одном из ее концов («->» или «<-»). На
диаграмме классов данное отношение связывает отдельные
классы между собой, при этом стрелка направлена от классаклиента зависимости к независимому классу или классуисточнику (рис. ). На данном рисунке изображены два
класса: Класс_А и Класс_Б, при этом Класс_Б является
источником некоторой зависимости, а Класс_А – клиентом
этой зависимости.
235

236. Графическое представление зависимости между классом-клиентом (Класс_С) и классами-источниками (Класс_А и Класс_Б)

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

237.

Стрелка может помечаться необязательным, но
стандартным
ключевым
словом
в
кавычках
и
необязательным индивидуальным именем. Для отношения
зависимости предопределены ключевые слова, которые
обозначают некоторые специальные виды зависимостей. Эти
ключевые слова (стереотипы) записываются в кавычках
рядом со стрелкой, которая соответствует данной
зависимости. Примеры стереотипов для отношения
зависимости представлены ниже:
• «access» – служит для обозначения доступности
открытых атрибутов и операций класса-источника для
классов-клиентов;
237

238.

• «bind» – класс-клиент может использовать некоторый
шаблон для своей последующей параметризации;
• «derive» – атрибуты класса-клиента могут быть
вычислены по атрибутам класса-источника;
• «import» – открытые атрибуты и операции классаисточника становятся частью класса-клиента, как если бы
они были объявлены непосредственно в нем;
• «refine» – указывает, что класс-клиент служит
уточнением класса-источника в силу причин исторического
характера, когда появляется дополнительная информация в
ходе работы над проектом.
238

239. Отношение ассоциации

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

240.

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

241.

В качестве простого примера отношения бинарной
ассоциации рассмотрим отношение между двумя классами –
классом «Компания» и классом «Сотрудник» (рис. ). Они
связаны между собой бинарной ассоциацией Работа, имя
которой указано на рисунке рядом с линией ассоциации. Для
данного отношения определен порядок следования классов,
первым из которых является класс «Сотрудник», а вторым –
класс «Компания». Отдельным примером или экземпляром
данного отношения может являться пара значений (Петров
И. И., ООО «Р&К»). Это означает, что сотрудник Петров И.
И. работает в ООО «Р&К».
241

242.

242

243. Отношение между тремя классами: «Футбольная команда», «Год» и «Игра»

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

244.

Как уже упоминалось, отдельный класс ассоциации имеет
собственную роль в отношении. Эта роль может быть
изображена графически на диаграмме классов. С этой целью
в языке UML вводится в рассмотрение специальный элемент
– конец ассоциации (Association End), который графически
соответствует точке соединения линии ассоциации с
отдельным классом. Конец ассоциации является частью
ассоциации, но не класса. Каждая ассоциация имеет два или
больше концов ассоциации. Наиболее важные свойства
ассоциации указываются на диаграмме рядом с этими
элементами ассоциации и должны перемешаться вместе с
ними.
244

245. Исключающая ассоциация (Xor-association).

Частным случаем отношения ассоциации является так
называемая исключающая ассоциация (Xor-association).
Семантика данной ассоциации указывает на тот факт, что из
нескольких потенциально возможных вариантов данной
ассоциации в каждый момент времени может использоваться
только один ее экземпляр. На диаграмме классов
исключающая ассоциация изображается пунктирной линией,
соединяющей две и более ассоциации, рядом с которой
записывается строка-ограничение «{хог}».
245

246. Отношение агрегации

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

247.

В качестве примера отношения агрегации рассмотрим
взаимосвязь типа «часть-целое», которая имеет место между
сущностью «Грузовой автомобиль» и такими компонентами,
как «Двигатель», «Шасси», «Кабина», «Кузов». Не претендуя
на точное соответствие терминологии данной предметной
области, нетрудно представить себе, что грузовой
автомобиль состоит из двигателя, шасси, кабины и кузова.
Именно
это
отношение
между
классом
«Грузовой_автомобиль» и классами «Двигатель», «Шасси»,
«Кабина», «Кузов» описывает отношение агрегации.
247

248.

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

249. Отношение композиции

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

250. Отношение обобщения

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

251.

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

252.

252

253.

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

254.

254

255. Диаграмма классов: крупным планом

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

256.

Что же внутри объектов класса? Пользователю об этом
знать необязательно, более того, абсолютно не нужно. Для
человека, использующего его, объект выступает в роли
черного ящика. Скрывая от пользователя внутреннее
устройство объекта, мы обеспечиваем его надежную работу.
Сейчас мы рассмотрим, как убрать из поля зрения
пользователя то, что ему знать не нужно.
Читателя может слегка смутить слово "пользователь",
которым мы злоупотребляли в предыдущем абзаце. Зачем
вообще пользователю какие-то объекты и классы? Внесем
ясность.
256

257.

Программист, использующий в своей программе
созданные кем-то компоненты, как раз и выступает в роли
такого пользователя. Зачем ему знать что внутри - он знает,
какие атрибуты надо модифицировать и какие операции
использовать, чтобы заставить объект работать именно так,
как ему нужно! Более того, а многие ли из нас знают, как
именно устроен и по каким принципам работает, например,
телевизор - объект класса "Бытовой прибор"?
257

258.

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

259.

Симв
Значение
ол
+
public - открытый доступ
private - только из операций того же класса
#
protected - только из операций этого же класса и
классов, создаваемых на его основе
259

260. Пример «Телевизор»

260

261. Как использовать объекты класса?

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

262.

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

263.

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

264.

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

265. Стереотипом <<interface>>

Стереотипом <<interface>>
Этот способ хорош, если нужно показать, какие именно
операции предоставляет интерфейс. Если же такие подробности
в данный момент не важны, предоставляемый интерфейс
изображают в виде кружочка или, как говорят, "леденца"
(lollipop ).
265

266.

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

267. Всегда ли нужно создавать новые классы?

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

268.

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

269.

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

270.

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

271.

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

272.

272

273. Пример применения этого подхода

273

274.

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

275.

Все остальные классы на этой диаграмме связаны с
классом "Фигура" отношением обобщения, т. е. в них нужно
доопределить только "недостающие" атрибуты - радиус,
ширину и высоту. Атрибуты, описывающие координаты
центра, эти классы имеют изначально как потомки класса
"Фигура" - они их наследуют. Заметим, что операции классов
мы тут не рассматриваем: понятно, что с ними была бы та же
история.
Классы-потомки ведь наследуют атрибуты и операции
суперкласса? Таким образом, они могут наследовать и их
интерфейсы - то есть объекты абсолютно разной природы
могут иметь один и тот же интерфейс! Так как же тогда
определить, какого же все-таки класса объект? Да и нужно ли
это вообще?
275

276.

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

277.

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

278.

Полиморфизм является основой для реализации
механизма интерфейсов в языках программирования. Вот,
кстати, и ответ на вопрос, какого класса объект: как только
пользователь обращается к некоторой операции через
интерфейс, определяется фактический класс объекта и
вызывается соответствующая операция класса. Примеры
полиморфизма можно увидеть в самых обыденных вещах,
которыми мы пользуемся в повседневной жизни. Например,
всем привычная кредитная карточка, является интерфейсом
для доступа к банковскому счету через банкомат (и не
только), одинаково работает в любой стране, вот только ведет
себя чуть-чуть по-разному, т. к. банкомат выдает деньги в
местной валюте. Согласны, пример не очень корректный, но
зато очень наглядный! Думаем, понаблюдав за окружающим
миром, читатель сам сможет привести массу примеров
полиморфизма.
278

279.

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

280. Отношения между классами

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

281.

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

282.

Приведем простой пример, опять-таки взятый из нашей
повседневности. Иногда к нам в руки попадают видеофайлы,
воспроизвести которые "с лету" не удается. Почему?
Правильно, потому что на компьютере не установлены
соответствующие
кодеки.
То
есть
операция
"Воспроизведение", реализуемая программой-медиаплеером,
зависит от операции "Декомпрессия", реализуемой кодеком.
Если спецификация операции "Декомпрессия" изменится,
придется менять код медиаплеера, иначе он просто не
сможет работать с каким-то кодеком и, в лучшем случае,
завершит свою работу с ошибкой. А вот так зависимость
между классами изображается в UML.
282

283.

283

284.

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

285. Ассоциация

285

286. Роли ассоциации

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

287.

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

288.

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

289. Простое агрегирование и композитное агрегирование

289

290.

В отношении между двумя классами сама ассоциация
тоже может иметь свойства и, следовательно, тоже может
быть представлена в виде класса.
290

291. Пример отношения между классами

291

292.

292

293. Выводы

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

294.

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

295. Диаграмма активностей: крупным планом

Нотация UML предлагает пять представлений системы:
• Вид системы с точки зрения прецедентов.
• Вид с точки зрения проектирования.
• Вид с точки зрения процессов.
• Вид с точки зрения развертывания.
• Вид с точки зрения реализации.
Каждый из перечисленных способов представления
системы может содержать последовательности действий,
которые могут быть описаны с помощью алгоритмов.
Деятельность - это протяженное по времени составное
действие. Составное! То есть составленное из более простых
действий.
295

296.

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

297.

297

298. Диаграмма активностей - это нечто большее, чем блок-схема (роли)

Диаграмма активностей - это нечто большее, чем блоксхема (роли)
298

299.

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

300.

300

301.

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

302.

302

303.

Диаграмма описывает высадку пассажиров самолета,
достигших пункта назначения, и посадку новых пассажиров.
Предлагаем читателю самому внимательно рассмотреть эту
диаграмму. Из нее, например, можно почерпнуть, что
конечных состояний может быть больше одного. Кстати,
кроме начального и конечного состояний есть еще конечное
состояние потока (Flow final mode). От конечного состояния
оно отличается вот чем: конечное состояние потока означает
завершение одного потока управления, а конечное состояние
говорит о завершении всех потоков управления внутри
деятельности. Обозначается конечное состояние потока
простым символом, напоминающим лампочку накаливания в
схемах электрических цепей
303

304. Моделирование операций (диаграмма активности, пример)

304

305. Приведем пример моделирования цикла с постусловием

305

306. Пример диаграммы деятельности

306

307.

307

308.

308

309.

309

310.

310

311.

311

312.

312

313.

313

314.

314

315.

315

316.

316

317.

317

318.

318

319.

319

320.

320

321.

321

322.

322

323.

323

324. Особенности управлению программными проектами

324

325. Добавление поведения и структуры. Представление поведения и структуры.

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

326.

Структура (structure) объекта описывается атрибутами
класса. Каждый атрибут - это поле данных, содержащееся в
объекте класса. Объект, созданный на основе класса,
наделен значениями всех атрибутов класса. Например, класс
Предмет (course) имеет следующие атрибуты: название
(nаmе), описание (definition) и количество учебных часов
(credit hours). Следовательно, каждый объект Предмет будет
содержать значения перечисленных атрибутов. Они могут
повторяться, так как в университете существуют учебные
предметы с одинаковым количеством академических часов.
326

327.

При формировании имен атрибутов и операций
используется определенный стиль, благодаря которому
достигается единообразие в описании классов и становится
удобно работать с моделью и кодом.
Если какой-либо объект класса не наделен атрибутами или
операциями, проверьте определение класса. Это может
означать отсутствие целостности класса и необходимость его
разделения. Предположим, что класс Учебный курс
(CourseOffering) имеет следующие атрибуты: номер курса
(offerNumber), место занятий (location), время занятий
(timeOfDay), факультет (department), количество курсов на
факультете (numberOfferinglnDepartment). Он может быть
осведомлен о своем факультете, но информация о
количестве других курсов на факультете ему не нужна.
327

328. Создание операций

Сообщения на диаграммах взаимодействий обычно
отображаются на соответствующие операции в классахполучателях. Однако в особых случаях сообщения не
становятся операциями. Если класс-получатель является
граничным классом, представляющим графический
интерфейс пользователя (GUI), сообщения отражают
требования к интерфейсу. Такие сообщения реализуются
обычно в виде элементов управления (кнопок и т.п.) и не
отражаются на операции, так как требуемое поведение
уже заложено в стандартных элементах управления.
Например, актер Преподаватель должен ввести пароль,
чтобы запустить сценарий Добавление учебного курса (Add
a Course Offering).
328

329.

Это представлено в виде сообщения, направляемого
граничному классу параметры Курса преподавателя
(ProfessorCourseOptions). Оно никогда не станет операцией
в интерфейсном классе, а, скорее, будет реализовано в виде
поля ввода в окне программы. Сообщения, поступающие
актерам и от актеров, также требуют отдельного
рассмотрения. Если актер является человеком, сообщение
отражает действия человека, следовательно, должно быть
реализовано в виде фрагмента руководства пользователя,
а не в виде операции.
329

330.

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

331.

Для названия операции следует использовать только
термины класса, выполняющего операцию, а не класса,
запрашивающего выполнение операции. Например, операция
Добавления студента к учебному курсу называется
Добавить студента (addStudent). Кроме того, имена
операций не должны отражать способ их выполнения,
потому что он может измениться. К примеру, объект
Учебный курс может иметь не более десяти прикрепленных
студентов.
331

332.

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

333. Диаграмма последовательности действий с операциями. Выбор курса для преподавания/Добавление учебного процесса.

333

334. Документирование операций

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

335. Отношения и сигнатуры операций

Входными параметрами для операции Зарегистрировать
преподавателя (setProfessor) в классе Предмет (Course)
являются классы Преподаватель (Professor) и Учебный
курс (CourseOffering). Это значит, что существуют
отношения:
- между классами Предмет и Преподаватель;
- между классами Предмет и Учебный курс.
335

336.

Отношения, основанные на сигнатурах, изначально
моделировались как ассоциации, но в ходе проектирования
системы они могут быть пересмотрены и представлены как
отношения
зависимости
(dependency
relationships).
Взаимосвязи между пакетами также могут быть
пересмотрены, по мере того как в модель включаются
отношения, основанные на сигнатурах операций. К примеру,
мы добавили в систему отношение между классами предмет
и преподаватель. Значит, между пакетами Объекты
университета и Сведения о людях существует отношение
зависимости.
336

337. Создание атрибутов

Большинство атрибутов класса выявляется при
анализе предметной области, системных требований и
описаний потоков событий, а также при составлении
описания класса. Кроме того, хорошим источником для
определения атрибутов является сама предметная область.
Например, в требованиях к системе указано, что
информация о названии предмета, его описании и
количестве учебных часов
содержится в каталоге
учебных курсов на семестр. Из этого следует, что
название, описание и количество учебных часов - это
атрибуты класса Предмет.
337

338. Документирование атрибутов

Определения атрибутов в документации должны быть
краткими и четкими и содержать информацию о назначении
атрибута, а не о его структуре. Приведу неудачный пример
описания атрибута название класса Предмет: «Символьная
строка длиной до 15 знаков». Правильным будет следующий
вариант: «Название учебного предмета, которое используется
в университетских изданиях».
338

339. Ассоциативные классы

Отношение может также иметь структуру и поведение.
Это происходит в том случае, когда информация обращена к
связи между объектами, а не к самому объекту.
Рассмотрим такой пример. Студент может посещать до
четырех учебных курсов, а учебный курс может читаться
нескольким студентам - от трех до десяти. Каждый студент
получает оценку (grade) за учебный курс. Где должна
храниться оценка? Она не принадлежит студенту так как он
наверняка получит различные оценки по разным предметам.
Оценка не принадлежит и курсу, потому что студенты
получат разные оценки за данный курс.
339

340.

Сведения об оценке принадлежат связи между студентом
и учебным курсом. Они моделируются с помощью
ассоциативного класса (association class), который ведет себя
как и любой другой класс и также может иметь отношения. В
нашем примере студент получает отчет об оценках (report
card), куда включены связанные объекты оценка.
340

341. Ассоциативный класс оценка

341

342. Заключение

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

343.

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

344. Изучение наследования

Наследованием (inheritance) называется такое отношение
между классами, когда один класс использует часть
структуры и/или поведения другого или нескольких классов.
При наследовании создается иерархия абстракций, в которой
подкласс (subclass) наследуется от одного или нескольких
суперклассов (superclass). Наследование также называют
иерархией типа «такой же, как» (is-a) или «такого вида, как»
(kind-of). Подкласс наследует все атрибуты, операции и
отношения, определенные в каждом его суперклассе. Значит,
все атрибуты и операции, определенные на верхнем уровне
иерархии, будут унаследованы классами на более низких ее
уровнях.
344

345.

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

346. Иерархия одиночного наследования классов

346

347.

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

348. Специализация

С помощью специализации (specialization) создаются
подклассы, которые уточняют суперкласс - добавляют
структуру и поведение. Такой метод наследования
применяется, когда уже существует определенный класс.
Подкласс создается, чтобы адаптировать поведение
существующего класса. Например, в систему регистрации
допускается добавить функцию, посредством которой
почетные граждане обеспечивались бы бесплатными
курсами.
Новый
подкласс
Почетный
гражданин
(SeniorCitizen) может быть добавлен в иерархию класса
Пользователь (RegistrationUser) для хранения данных,
относящихся к почетным гражданам.
348

349.

В подклассе операции могут быть перекрыты (overridden).
Однако подкласс не должен ограничивать операции,
определенные в его суперклассах, то есть не должен урезать
их структуру и поведение.
349

350. Дерево наследования

Основу для специализации (то есть цель создания
подкласса)
в
отношении
наследования
называют
дискриминатором (discriminator). Дискриминатор, как
правило, наделен конечным набором значений и подклассов,
которые создаются для каждого значения.
Например, одним из дискриминаторов для класса предмет
(Course) является место обучения. Классы очный предмет
(OnCampusCourse) и заочный предмет (OffSiteCourse)
могут стать подклассами для класса Предмет, созданными
на основе этого дискриминатора. Отношения наследования
для всех подклассов, полученных от одного дискриминатора,
представляются в виде дерева.
350

351.

Другим подклассом класса Предмет может стать класс
Обязательный предмет. Этот подкласс не будет частью
дерева наследования, так как он принадлежит другому
дискриминатору - типу Предмета. Следует внимательно
подходить
к
вопросу
определения
нескольких
дискриминаторов для одного класса. Например, что
произойдет, если обязательный предмет тоже очный?
Является ли это примером множественного наследования?
Не нужно ли здесь применить агрегацию? В ходе анализа и
проектирования ответы на эти вопросы постепенно позволят
получить законченную структуру модели.
351

352. Дерево наследования

352

353.

После создания суперкласса атрибуты, операции и
отношения размещают по возможности на самом
высоком уровне иерархии. Какие же свойства необходимо
перенести?
Рассмотрим иерархию с базовым классом
Пользователь. Атрибуты, операции и отношения для
подклассов показаны на рис. Так как атрибуты Имя (name) и
Номер (IDNumber) одинакового формата в подклассах, их
можно
с
уверенностью
перенести
в
суперкласс
Пользователь (RegistrationUser). Оба класса связаны с
классом Учебный курс (CourseOffering).
353

354.

Для этого отношения существуют два варианта:
- сохранить отношения на уровне подклассов;
- сделать отношение на уровне суперкласса со значением
мощности, учитывающим объекты преподаватель и студент
(один объект учебный курс связан с объектами пользователь
в количестве от 4 до 11).
Кроме того, здесь накладывается дополнительное
ограничение: один из объектов пользователь должен быть
преподавателем.
354

355. Иерархия наследования для класса Пользователь

355

356. Иерархия наследования после переноса атрибутов

356

357.

Какой из этих вариантов является правильным? Оба.
Какой из них лучше использовать? Зависит от ситуации.
Если требуется, чтобы объект Учебный курс «знал» всех
студентов и преподавателя, то хранить единый список с
такой информацией наверняка будет удобнее. В этом случае
воспользуйтесь вторым вариантом. С другой стороны, если
нужно знать только студентов или только преподавателей,
подойдет первый вариант. Все зависит от требований к
системе. В подобных ситуациях следует тщательно изучить
функции и сценарии, чтобы определить нужное поведение.
357

358. Одиночное и множественное наследование

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

359. Наследование и агрегация

Наследование часто используется не по назначению.
Существует мнение, что «чем больше я буду его
использовать, тем лучше станет мой код». Это заблуждение.
В действительности неправильное применение наследования
может привести к проблемам. Например, студент может
учиться очно- или заочно. Создадим суперкласс Студент
(Student) и два подкласса - Студент очного отделения
(FulltimeStudent)
и
Студент
заочного
отделения
(ParttimeStudent).
359

360.

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

361.

Наследование должно служить для отделения общности от
специфики. Агрегация - для отражения комбинированных
отношений. Часто оба типа отношений используются вместе.
Класс Студент имеет классификацию (агрегацию), которая, в
свою очередь, делится на классы Студент-очник и Студентзаочник (наследование).
361

362. Наследование в сравнении с агрегацией

362

363. Выводы

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

364. Анализ поведения объекта. Моделирование динамического поведения.

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

365. Состояния

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

366.

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

367. Диаграмма состояний

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

368. Состояния (класса Учебный курс)

368

369. Переходы между состояниями

Переходы между состояниями (state transitions)
представляют
собой
смену
исходного
состояния
последующим (которое может быть тем же, что и исходное).
Переход может сопровождаться определенным действием.
Есть два способа выхода из состояния - автоматический и
неавтоматический. Автоматическая смена состояния
происходит, когда действие исходного состояния будет
завершено - с переходом не связано каких-либо событий.
Неавтоматический переход между состояниями вызывается
определенным событием (от другого объекта или из внешней
среды). Считается, что оба типа переходов выполняются за
нулевое время и не могут быть прерваны. Переход между
состояниями изображается в виде стрелки, направленной от
исходного состояния к последующему.
369

370. Переходы между состояниями

370

371. Особые состояния

Есть два особых состояния, присутствующих на
диаграмме состояний, - начальное (start state) и конечное
(stop state).
Каждая диаграмма должна иметь одно и только одно
начальное состояние, так как объект может находиться в
целостном состоянии сразу после создания.
Начальное
состояние
Конечное состояние
371

372. Конечное состояние

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

373. Параметры переходов

С переходом между состояниями может быть связано
условие (guard condition) и/или определенное действие
(action). Переход может также вызывать событие (event).
Действие
это
поведение,
проявляющееся
при
возникновении
перехода.
Событие
сообщение,
отправляемое другому объекту системы. Условие - булево
выражение значений атрибутов, которое допускает переход,
только если оно верно. И действие, и проверка условия
представляют собой поведение объекта и обычно
реализуются в виде операций. Часто такие операции
являются скрытыми (private), то есть используются только
самим объектом.
373

374. Нотация языка UML для параметров переходов

374

375. Параметры переходов

375

376. Параметры состояний

Действия, сопровождающие возможные переходы в
определенное состояние, можно рассматривать как входные
действия (entry action) для этого состояния. И наоборот,
действия, сопровождающие переходы из данного состояния,
являются для него выходивши (exit action). Поведение,
возникающее внутри состояния, называется деятельностью
(activity). Деятельность начинается при входе в состояние и
завершается или прерывается при переходе из него.
Поведение может быть простым действием или событием,
посылаемым другому объекту. Как и в случае с действиями и
проверками условий для перехода, поведение внутри
состояния обычно реализуется в виде операций.
376

377. Нотация языка UMI-Для параметров состояний

377

378. Параметры состояний

378

379. Вывод

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

380. Проверка модели

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

381. Объединение классов

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

382.

Уделите особое внимание управляющим классам системы.
Изначально для каждого прецедента предусматривается по
одному управляющему классу. Однако управляющие
классы со схожим поведением могут быть объединены.
Изучите последовательную логику (sequencing logic) в
управляющих классах системы. Если она идентична,
управляющие классы можно объединить в один. В системе
Регистрации учебных курсов имеется один управляющий
класс для прецедента Сохранить информацию о курсах
(Maintain Course Information) и один для прецедента Создать
каталог курсов (Create Course Catalog). Каждый
управляющий
класс
получает
информацию
от
граничного класса и обрабатывает информацию о
курсах. Вероятно, эти классы могут быть объединены,
так как они имеют поведение и управляют одинаковой
382
информацией.

383. Разделение классов

Классы обязательно проверяются на предмет соответствия
«золотому» правилу объектно-ориентированной технологии,
которое утверждает, что класс должен выполнять одну
задачу и выполнять ее хорошо. Например, класс
Информация о студенте (Studentlnformation), содержащий
сведения об актере Студент, а также о курсах, которые тот
закончил, выполняет слишком много функций. Его лучше
представить в виде двух классов - Информация о студенте и
Выписка (Transcript) - и ассоциативной связи между ними.
383

384.

Часто атрибут класса имеет структуру и поведение внутри
себя и должен быть выделен как отдельный класс. Например,
рассмотрим факультет университета. Каждый учебный
предмет предлагается определенным факультетом. Вначале
эти сведения были представлены в модели как атрибут
класса Предмет (Course). Дальнейший анализ выявил
необходимость получать данные о количестве студентов,
обучающихся на факультете, количестве преподавателей,
проводящих занятия на факультете, и количестве учебных
предметов на каждом факультете. Таким образом, был создан
отдельный класс Факультет (Department). Первоначальный
атрибут Факультет в классе Предмет был заменен
ассоциативной связью между классами.
384

385. Исключение классов

Иногда класс вообще может быть удален из модели. Это
происходит в следующих случаях:
- когда класс не имеет какой-либо структуры или
поведения;
- когда класс не участвует в выполнении какого-либо
прецедента.
Рекомендуется
проверять
управляющие
классы.
Отсутствие последовательных действий может указывать на
удаление управляющего класса. Особенно в случае, когда он
просто проходной, то есть получает информацию от
граничного класса и тут же передает ее в класс-сущность без
какой-либо последовательной логики.
385

386.

В системе регистрации учебных курсов мы изначально
создали управляющий класс для прецедента выбор курсов
для Преподавания (Select Courses to Teach). Он позволяет
преподавателю определить курсы для чтения в данном
семестре. Для управляющего класса здесь не нужна
последовательная
логика
преподаватель
вводит
информацию с помощью формы пользовательского
интерфейса, и класс Преподаватель добавляется к
выбранному курсу. В данном случае управляющий класс для
прецедента может быть удален.
386

387. Проверка целостности

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

388.

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

389. Проход по сценарию

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

390.

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

391. Отслеживание событий

Для каждого сообщения, изображенного на диаграммах
взаимодействий, проверьте, чтобы операция в классеотправителе отправляла событие, а операция в классеполучателе ожидала событие и могла его обработать.
Убедитесь в наличии ассоциативной или агрегационной
связи на диаграмме классов между классом-отправителем и
классом-получателем. Если такая связь отсутствует, добавьте
ее на диаграмму классов. Если для класса уже создана
диаграмма состояний и переходов, то событие на ней должно
быть представлено для класса- получателя. Необходимо,
чтобы диаграмма состояний отражала все события,
которые может получать класс.
391

392. Просмотр документации

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

393. Вывод

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

394.

394

395. КОНЕЦ

395

396.

396

397.

397

398.

398

399. Конечное состояние

399

400.

400

401. НОВЫЕ МАТ, ДИАГР. КЛАССОВ

401

402.

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

403. Изображение класса

403

404.

А что же внутри объектов класса? Пользователю об этом
знать необязательно, более того, абсолютно не нужно. Для
человека, использующего его, объект выступает в роли
черного ящика. Скрывая от пользователя внутреннее
устройство объекта, мы обеспечиваем его надежную работу.
Сейчас мы рассмотрим, как убрать из поля зрения
пользователя то, что ему знать не нужно. он знает, какие
атрибуты
надо
модифицировать
и
какие
операции
использовать,
чтобы
заставить объект работать именно так, как ему нужно!
Пользователь, например, может не знать как именно устроен
и по каким принципам работает, например, телевизор объект класса "Бытовой прибор"?
404

405.

Сокрытие от пользователя внутреннего устройства
объектов называется инкапсуляцией. Если говорить более
"научным" языком, то инкапсуляция - это защита отдельных
элементов объекта, не затрагивающих существенных
характеристик его как целого. Инкапсуляция нужна для того,
чтобы создать иллюзию простоты объекта для пользователя
Прибор кажется очень простым только потому, что при
работе
с
ним
мы
используем
простой
и
понятный интерфейс - пульт дистанционного управления.
Мы знаем: для того чтобы увеличить громкость звука, надо
нажать вот эту кнопку, а чтобы переключить канал - вот эту.
Как телевизор устроен внутри, мы не знаем. Более того - в
отсутствие пульта ДУ такое знание было бы неудобным для
нас и весьма опасным для самого телевизора, вздумай мы
увеличить громкость с помощью паяльника. Поэтому-то
пульт ДУ и защищает от нас "внутренности" телевизора! Вот
405
так инкапсуляция реализуется в реальном мире.

406.

В программировании инкапсуляция обеспечивается
немного по-другому - с помощью т. н. модификаторов
видимости. С их помощью можно ограничить доступ к
атрибутам и операциям объекта со стороны других объектов.
Звучит это немного пугающе, но на самом деле все просто.
Если
атрибут
или
операция
описаны
с
модификатором private, то доступ к ним можно получить
только из операции, определенной в том же классе. Если
же атрибут или операция описаны с модификатором
видимостиpublic, то к ним можно получить доступ из любой
части программы.
406

407.

Модификатор protected разрешает доступ только из
операций этого же класса и классов, создаваемых на его
основе.
В
языках
программирования
могут
встречаться
модификаторы
видимости,
ограничивающие доступ на более высоком уровне,
например, к классам или их группам, однако смысл
инкапсуляции от этого не изменяется. В UML атрибуты
и операции с модификаторами доступа обозначаются
специальными символами слева от их имен:
Символ
+
#
Значение
public - открытый доступ
private - только из операций того же класса
protected - только из операций этого же класса и
классов, создаваемых на его основе
407

408. Пример с телевизором

408

409.

Если уж говорить о защите объекта, то чтобы она
действительно была эффективной, надо позаботиться о
некоем стандартном и безопасном, не зависящим от языка
программирования способе доступа к объекту. К тому же
такой стандартный способ доступа должен быть простым и с
точки зрения использования, и с точки зрения реализации.
Вспомните пример с телевизором. Нажимая кнопки на
пульте, мы ожидаем, что телевизор откликнется на это
действие каким-то определенным образом - именно так, как
мы ожидаем, а не иначе. То есть, с одной стороны, пульт ДУ
является средством доступа к скрытым операциям,
выполняемым телевизором, а с другой стороны - пульт
обеспечивает нужное для нас поведение телевизора.
409

410.

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

411. Интерфейс

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

412.

Интерфейс всегда реализуется некоторым классом,
который
в
таком
случае
называют
классом, поддерживающим интерфейс. Один и тот
же объект может иметь несколько интерфейсов. Это
означает,
что
класс
этого
объекта
реализует
все операции этих интерфейсов. К данному моменту в голове
читателя может созреть вопрос: "Мы же, вроде бы, говорили
о классах и объектах, а теперь вдруг перешли на интерфейсы.
Да и вообще, используются ли они в практике
программирования
или
являются
просто
изящной
теоретической конструкцией?". Ответ на этот вопрос прост:
многие из существующих технологий программирования
(например, COM, CORBA, Java Beans) не только активно
используют механизм интерфейсов, но и, по сути, полностью
412
основаны на нем.

413. Отображение класса Интерфейс

413

414.

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

415. Еще один способ изображения интерфейса. названия интерфейсов начинаются с буквы I

Еще один способ изображения интерфейса.
названия интерфейсов начинаются с буквы I
415

416. Всегда ли нужно создавать новые классы?

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

417.

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

418.

418

419. Почему стоит использовать уже существующие классы:

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

420.

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

421. Наследование

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

422.

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

423.

423

424. Пример применения наследования

424

425.

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

426.

Таким образом, мы создалисуперкласс "Фигура",
имеющий два атрибута - координаты центра. Все остальные
классы на этой диаграмме связаны с классом "Фигура"
отношением обобщения, т. е. в них нужно доопределить
только "недостающие" атрибуты - радиус, ширину и высоту.
Атрибуты, описывающие координаты центра, эти классы
имеют изначально как потомки класса "Фигура" - они их
наследуют. Заметим, что операции классов мы тут не
рассматриваем: понятно, что с ними была бы та же история.
426

427.

427

428. Диаграмма компонентов

428

429. Диаграммы компонентов

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

430. Пример диаграммы компонентов

430

431. Диаграмма компонентов. Цели.

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

432. Компонент (component)

Компонент – элемент модели, представляющий
некоторую
модульную
часть
системы
с
инкапсулированным содержимым, спецификация которого
является взаимозаменяемой в его окружении.
Имя экземпляра компонента записывается следующем
формате:
<имя-экземпляра-компонента>::=[<собственноеимя-компонента>] [‘:’<имя-типа>],
при этом собственное имя компонента записывается
со строчной буквы, а в качестве имени экземпляра
компонента должен присутствовать хотя бы один терм.
432

433. Интерфейс

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

434.

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

435. Стереотипом <<interface>>

Стереотипом <<interface>>
Этот способ хорош, если нужно показать, какие именно
операции предоставляет интерфейс. Если же такие подробности
в данный момент не важны, предоставляемый интерфейс
изображают в виде кружочка или, как говорят, "леденца"
(lollipop ).
435

436.

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

437. Примеры изображения простого компонента и компонента с интерфейсами

IDialog
«component»
Заказ
ISensor
IApplication
«component»
Контроллер
437

438. Примеры изображения компонента в нотации черного и белого ящика (структура компонента, т.е. описание компонента)

«component»
Заказ
«component»
Заказ
«provided interfaces»
МестонахождениеТов ара
Сопров ождение
«required interfaces»
Заказыв аемыйТов ар
Клиент
«provided interfaces»
МестонахождениеТов ара
Сопров ождение
«required interfaces»
Заказыв аемыйТов ар
Клиент
«realizations»
Заголов окЗаказа
СтрокаТов ара
«artifacts»
Заказ.jar
438

439. Интерфейсы

Требуемый интерфейс (required interface - вход) –
интерфейс, который необходим компоненту от своего
окружения
для
выполнения
заявленной
функциональности, контракта или поведения.
Предоставляемый интерфейс (provided interface выход) – интерфейс, который компонент предлагает для
своего окружения.
Заказываемый
Товар
«component»
Товар
Заказываемый
Товар
Сопровож дение
Счет-фактура
«component»
Заказ
Клиент
ЗаголовокЗаказа
заказ
1
элемент *
СтрокаТовара
Местонахождение
Товара
439

440. Представление интерфейсов в форме символа классификатора с отношениями зависимости и реализации

«interface»
Заказываемый
Товар
«use» «component»
Заказ
найтиПоИмени()
задатьКоличество()
получитьДетали()
«interface»
Местонахож дениеТовара
задать()
изменить()
получитьДетали()
440

441. Порты (содержат описание протоколов)

Порт определяет различимую точку взаимодействия между
компонентом и окружающей его средой или между компонентом
и его внутренними частями.
Наличие имени у порта не является обязательным.
При отсутствии имени порта его тип ассоциируется с типом
интерфейса, с которым связан порт.
Заказывае мый
Товар
«component»
Заказ
Клиент
ЗаголовокЗаказа
заказ
Сопровож де ние
элемент
1
М е стонахож де ние
Товара
*
СтрокаТовара
441

442. Собирающий соединитель (assembly connector)

– соединитель, который связывает два компонента в контексте
предоставляемый и требуемых сервисов.
Сопровож де ние
Сопровож де ние
«component»
Заказ
Заказывае мыйТовар
«component»
:Заказ
Заказывае мыйТовар
Заказывае мыйТовар
Заказывае мыйТовар
«component»
Товар
«component»
:Товар
442

443. Пример диаграммы компонентов с собирающими соединителями для одинаковых интерфейсов

:Отме не нныйЗаказ
М е стонахож де ние
М е стополож е ние
Товара
:Склад
Клиент
Клиент
Че лове к
:Заказ
:Физическое
Лицо
М е стополож е ние
Организация
Сопровож де ниеЗаказывае мый
:Поставщик
:Компания
Товар
Заказывае мый
Сопровож де ние
Товар
:Се рвис
:Товар
443

444. Делегирующий соединитель (2-я форма представления компонента) (delegation connector)

– соединитель, который связывает внешний контракт
компонента с реализацией этого поведения внутренними
частями этого компонента.
Делегирующий соединитель выполняет одну из следующих
задач:
– Передача сообщений или сигналов, поступающих в порт
компонента извне, для обработки в некоторую внутреннюю
часть компонента или другой порт.
– Передача сообщений или сигналов, поступающих из
некоторой внутренней части компонента, для обработки во
внешний порт компонента.
«component»
Ме стонахож де ние
Товара
Заказ
:ЗаголовокЗаказа
Клиент
:СтрокаТовара
444

445. Пример внутренней структуры экземпляра компонента

Местонахож дение
Товара
«component»
:М агазин
«delegate»
Местонахож дение
Товара
«component»
:Заказ
Клиент
Клиент
«component»
:Физическое
Лицо
Счет
Заказываемый
Товар
Заказываемый
Товар
«delegate»
Счет
«component»
:Товар
445

446. Пример отношений зависимости между компонентом

Отме не нныйЗаказ
Физиче ское
Лицо
Склад
Заказ
Поставщик
Компания
Се рвис
Товар
446

447. Отношения зависимости на диаграмме компонентов с интерфейсами

Местонахож дение
Товара
Человек
Клиент
Физическое
Лицо
Заказ
Местополож ение Сопровож дение
Заказываемый
Товар
Поставщик
Сопровож дение
Сервис
Организация
Компания
Заказываемый
Товар
Товар
447

448. Реализация (realization)

– специализация отношения зависимости для связи
компонентов
с
классификаторами,
которые
реализуют
функциональность этого компонента.
Реализация компонента может быть дополнительно помечена
стереотипом «implement» .
«component»
Заказ
<<implement>>
Заголовок
Заказа
<<implement>>
Строка
Товара
448

449. Изображение графических стереотипов компонентов Г.Буча

Dialog.dll
Inde x.htm l
Conte xt .hlp
Main.cpp
449

450. Графические стереотипы компонентов Дж. Коналлена

Серверная
страница
представляет
Web-страницу,
содержащую выполняемые сервером сценарии.
Эти сценарии могут взаимодействовать с серверными
ресурсами, такими как базы данных, бизнес-логика и
внешние системы.
Операции реализуемых компонент классов являются
функциями сценария, а их атрибуты — переменными,
видимыми в пределах этой страницы.
<<se rve r page >>
450

451. Клиентская страница

<<clie nt page>>
Представляет Web-страницу в формате HTML, а также
данные, элементы интерфейса и даже бизнес-логику.
Клиентские
страницы
отображаются
клиентскими
броузерами
и
могут
содержать
сценарии,
которые
интерпретируются броузером.
Операции клиентской страницы могут соответствовать
функциям, содержащимся в дескрипторах сценария страницы.
Атрибутам
клиентской
страницы
соответствуют
объявленные в дескрипторах сценария переменные, которые
доступны любой функции в пределах этой страницы.
451

452. Форма

<<form >>
Является набором полей ввода и представляет собой часть
клиентской страницы.
Форма преобразуется непосредственно в дескриптор HTML
<form>.
Атрибуты формы могут представлять поля ввода, текстовые
поля, переключатели, флажки, скрытые поля формы HTML.
С формой не связано никаких операций, поскольку их нельзя
в ней инкапсулировать.
Любые операции взаимодействия с формой являются
свойствами содержащей ее страницы.
452

453. Набор фреймов

<<fram e s e t>>
Представляет собой контейнер, состоящий из нескольких
Web-страниц.
Прямоугольная область просмотра делится на несколько
фреймов.
Каждый фрейм может быть связан с одним объектом со
стереотипом «target», однако это необязательно.
Содержимым фрейма может быть Web-страница или другой
фрейм. Набор фреймов преобразуется непосредственно в набор
фреймов Web-страницы и дескриптор HTML <frame>.
453

454. Цель

<<targe t>>
Представляет собой именованную область окна броузера, в
которой могут отображаться Web-страницы.
Имя цели соответствует имени целевого объекта.
Обычно целью является один из фреймов набора.
Однако целью может быть и новое окно броузера. Для цели
может быть задано место назначения, где будет отображена
новая Web-страница.
Имя цели должно быть уникальным для каждого клиента
системы.
454

455. Web-страница

<<w eb-page >>
Броузер может запрашивать Web-страницу по ее имени.
Этот компонент при необходимости может содержать
клиентские или серверные сценарии.
Обычно web-страницы являются текстовыми файлами,
доступ к которым можно получить через Web-сервер.
Однако они могут быть также компилируемыми
модулями, загружаемыми и запускаемыми Web-сервером.
В любом случае при доступе к такой странице,
хранящейся в файле или исполняемой Web-сервером, она
генерирует документ в формате HTML, который
отправляется в ответ на запрос броузера.
455

456. Диаграмма размещения

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

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

Распределенная конфигурация системы моделируется с
помощью диаграммы размещения. Ее основные элементы:
• узел (node) – вычислительный ресурс (процессор или
другое устройство (дисковая память, контроллеры различных
устройств и т. д.). Для узла можно задать выполняющиеся на
нем процессы;
• соединение (connection) – канал взаимодействия узлов
(сеть).
457

458. Пример: сетевая конфигурация системы регистрации (без процессов)

458

459.

Распределение процессов по узлам сети производится с
учетом следующих факторов:
• используемые образцы распределения (трехзвенная
клиент- серверная конфигурация, «толстый клиент», «тонкий
клиент», равноправные узлы (peer-to-peer) и т.д.);
• время отклика;
• минимизация сетевого трафика;
• мощность узла;
• надежность оборудования и коммуникаций.
459

460. Сетевая конфигурация системы регистрации с распределением процессов по узлам

460

461. Пример диаграмма размещения

461

462.

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

463. Комментарий

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

464. Пример комментарий

464

465. КОНЕЦ

465