86. Диаграммы классов (class diagram). Основные объекты диаграммы
Диаграмма классов (англ. StaticStructurediagram) — диаграмма, демонстрирующая классы системы, их атрибуты, методы и взаимосвязи между ними. Входит в UML.
Существует два вида:
Статический вид диаграммы рассматривает логические взаимосвязи классов между собой;
Аналитический вид диаграммы рассматривает общий вид и взаимосвязи классов входящих в систему.
Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения:
Концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;
Точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;
Точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).
Взаимосвязи
Взаимосвязь — это особый тип логических отношений между сущностями, показанных на диаграммах классов и объектов. В UML’е представлены следующие виды отношений:
Ассоциации
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности.
Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. Вполне допустимы случаи, когда оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса позволительно связать другие объекты из того же класса. Ассоциация, связывающая два класса, называется бинарной. Можно, хотя это редко бывает необходимым, создавать ассоциации, связывающие сразу несколько классов; они называются n-арными. Графически ассоциация изображается в виде линии, соединяющей класс сам с собой или с другими классами.
Ассоциации может быть присвоено имя, описывающее природу отношения. Обычно имя ассоциации не указывается, если только вы не хотите явно задать для нее ролевые имена или в вашей модели настолько много ассоциаций, что возникает необходимость ссылаться на них и отличать друг от друга. Имя будет особенно полезным, если между одними и теми же классами существует несколько различных ассоциаций.
Класс, участвующий в ассоциации, играет в ней некоторую роль. По существу, это "лицо", которым класс, находящийся на одной стороне ассоциации, обращен к классу с другой ее стороны. Вы можете явно обозначить роль, которую класс играет в ассоциации.
Часто при моделировании бывает важно указать, сколько объектов может быть связано посредством одного экземпляра ассоциации. Это число называется кратностью (Multiplicity) роли ассоциации и записывается либо как выражение, значением которого является диапазон значений, либо в явном виде. Указывая кратность на одном конце ассоциации, вы тем самым говорите, что на этом конце именно столько объектов должно соответствовать каждому объекту на противоположном конце. Кратность можно задать равной единице (1), можно указать диапазон: "ноль или единица" (0..1), "много" (0..*), "единица или больше" (1..*). Разрешается также указывать определенное число (например, 3). С помощью списка можно задать и более сложные кратности, например 0 . . 1, 3..4, 6..*, что означает "любое число объектов, кроме 2 и 5".
Агрегация
Диаграмма классов, показывающая Агрегацию между двумя классами
Агрегация. Простая ассоциация между двумя классами отражает структурное отношение между равноправными сущностями, когда оба класса находятся на одном концептуальном уровне и ни один не является более важным, чем другой. Но иногда приходится моделировать отношение типа "часть/целое", в котором один из классов имеет более высокий ранг (целое) и состоит из нескольких меньших по рангу (частей). Отношение такого типа называют агрегированием; оно причислено к отношениям типа "имеет" (с учетом того, что объект-целое имеет несколько объектов-частей). Агрегирование является частным случаем ассоциации и изображается в виде простой ассоциации с незакрашенным ромбом со стороны "целого".
Графически агрегация представляется пустым ромбиком на блоке класса и линией, идущей от этого ромбика к содержащемуся классу.
Композиция
Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.
Композиция имеет жёсткую зависимость времени существования экземпляров класса контейнера и экземпляров содержащихся классов. Если контейнер будет уничтожен, то всё его содержимое будет также уничтожено.
Графически представляется как и агрегация, но с закрашенным ромбиком.
Различия между композицией и агрегацией
Отношения между классом Вуз и классами Студент и Факультет слегка отличаются друг от друга, хотя оба являются отношениями агрегирования. В ВУЗе может быть любое количество студентов (включая ноль), и каждый студент может обучаться в одном или нескольких вузах; вуз может состоять из одного или нескольких факультетов, но каждый факультет принадлежит одному и только одному ВУЗу. Отношение между классами ВУЗ и Факультет называют композицией так, как при уничтожении модели Вуз, модели факультетов принадлежащих этому вузу так же должны быть уничтожены. Студент и Вуз в отношении агрегации потому, что Студента нельзя удалить при уничтожении Вуза.[1]
Обобщение (наследование)
Диаграмма классов, показывающая наследование двух подклассов от одного суперкласса
Обобщение (Generalization) показывает, что один из двух связанных классов (подтип) является частной формой другого (надтипа), который называетсяобобщением первого. На практике это означает, что любой экземпляр подтипа является также экземпляром надтипа. Например: животные — супертип млекопитающих, которые, в свою очередь, — супертип приматов, и так далее. Эта взаимосвязь легче всего описывается фразой «А — это Б» (приматы — это млекопитающие, млекопитающие — это животные).
Графически обобщение представляется линией с пустым треугольником у супертипа.
Обобщение также известно как наследование или «is a» взаимосвязь (или отношение "является").
Реализация
Реализация — отношение между двумя элементами модели, в котором один элемент (клиент) реализует поведение, заданное другим (поставщиком). Реализация — отношение целое-часть. Графически реализация представляется так же, как и наследование, но с пунктирной линией.
Зависимость
Зависимость (dependency) — это слабая форма отношения использования, при котором изменение в спецификации одного влечёт за собой изменение другого, причём обратное не обязательно. Возникает когда объект выступает, например, в форме параметра или локальной переменной.
Графически представляется штриховой стрелкой, идущей от зависимого элемента к тому, от которого он зависит.
Существует несколько именованных вариантов.
Зависимость может быть между экземплярами, классами или экземпляром и классом.
Уточнения отношений
Уточнение имеет отношение к уровню детализации. Один пакет уточняет другой, если в нём содержатся те же самые элементы, но в более подробном представлении. Например, при написании книги вы наверняка начнете с формулировки предложения, в котором кратко будет представлено содержание каждой главы. Предположим, что резюме к каждой главе в качестве отдельного элемента входит в пакет «Предложение». Допустим также, что «Завершённая книга» — это пакет, элементами которого являются законченные главы. В этом контексте пакет «Завершённая книга» является уточнением пакета «Предложение».
Мощность отношений (Кратность)!
Мощность отношения (мультипликатор) означает число связей между каждым экземпляром класса (объектом) в начале линии с экземпляром класса в её конце. Различают следующие типичные случаи:
нотация | объяснение | пример |
0..1 | Ноль или один экземпляр | кошка имеет или не имеет хозяина |
1 | Обязательно один экземпляр | у кошки одна мать |
0..* или * | Ноль или более экземпляров | у кошки может быть, а может и не быть котят |
1..* | Один или более экземпляров | у кошки есть хотя бы одно место, где она спит |
- Процессы жизненного цикла систем (на основе iso/iec 15288)
- Структура и функциональное назначение процессов жизненного цикла программных средств (на основе iso/iec 12207)
- Модель качества и критерии качества программных средств (на основе iso/iec 9126 и iso/iec 25010)
- Оценка зрелости процессов создания и сопровождения программных средств на основе методологии cmm и cmmi (на основе iso/iec 15504)
- Система менеджмента информационной безопасности (на основе серии iso/iec 27000)
- Методы кодирования текстовой, графической и звуковой информации в эвм. Аналоговые, дискретные и цифровые сигналы
- История создания, принципы работы и основные сервисы сети Интернет.
- Представление данных в эвм. Единицы измерения информации. Двоичные приставки по гост 8.417-2002 и iec 80000-13.
- Принципы и архитектура фон Неймана.
- Порядок обработки команд микропроцессором. Прерывания. Типы прерываний.
- Поколения эвм. Основные особенности.
- I Поколение 50-60-е гг.
- II Поколение 60-70-е гг.
- III Поколение 70-80-е гг.
- IV Поколение 80-е (по наши дни?).
- Классификация запоминающих устройств в эвм. Современные реализации запоминающих устройств.
- 13. Алгебра логики. Основные законы алгебры логики. Применение алгебры логики в информатике.
- 14. Понятие алгоритма. Методы оценки алгоритмической сложности.
- 15. Понятие системы. Системный анализ. Применение системнго анализа в информатике.
- 16. Теория формальных грамматик. Основные понятия и положения. Применение в информатике.
- 17. Теория вероятностей. Основные понятия и положения. Применение в информатике.
- 18. Математические методы оптимизации и их применение в информатике.
- 19. Понятие компьютерного моделирования. Вычислительный эксперимент.
- 20. Структурное программирование. Понятия и принципы.
- 21. Объектно-ориентированное программирование. Понятия и принципы.
- 22. Декларативные языки программирования и их сфера применения.
- 23. Событийно-ориентированное программирование.
- 24. Многопоточное программирование. Процесс и поток выполнения. Средства синхронизации потоков.
- 25. Основные алгоритмы и структуры данных, применяемые в вычислительных системах.
- 26. Приёмы (шаблоны) объектно-ориентированного программирования.
- 27. Теория графов. Основные понятия. Решаемые задачи.
- 28. Средства моделирования при разработке программного обеспечения.
- 29. Инструментальные средства разработки программного обеспечения.
- 30.Методологии разработки программного обеспечения. Классификация. Особенности применения.
- 31. Программные средства для организации совместной разработки программного обеспечения.
- 32. Программный продукт. Жизненный цикл программного продукта.
- 4.1.1.1 Основные процессы жизненного цикла
- 5. Вспомогательные процессы жизненного цикла по гост р исо/мэк 12207-99.
- 4.1.1.2 Вспомогательные процессы жизненного цикла
- 33. Бизнес-процесс. Средства анализа и моделирования. Автоматизация бизнес-процессов.
- 34. Архитектура вычислительной системы, разновидности.
- 35. Аппаратное обеспечение вычислительных систем.
- 36. Архитектура вычислительной сети.
- 37. Виртуализация вычислительных ресурсов. "Облачные" вычисления.
- 38. Способы реализации человеко-машинного взаимодействия.
- 39. Принципы защиты информации в вычислительных системах и сетях.
- 40. Операционная система. Понятие и основные задачи. Классификация операционных систем.
- 41. Файловая система и принципы построения и основные функции.
- 42. Понятие машинного обучения и искусственного интеллекта. Решаемые задачи.
- 43. Методы сжатия графической информации. Области применения различных методов.
- 44. Методы сжатия звуковой информации. Области применения различных методов.
- 45. Понятие виртуальной и дополненной реальности. Средства реализации.
- 46. Компьютерная графика. Различные методы и технологии реализации.
- 47. Системы управления базами данных, разновидности.
- 48. Принципы построения реляционных баз данных. Нормализация данных.
- 49. Распределённые базы данных. Принципы построения и решаемые задачи.
- 50. Понятие открытой вычислительной системы. Классификация. Принципы построения.
- 51. Методы анализа информационных систем
- 52. Средства мониторинга сетевого трафика
- 53. Метод Монте-Карло. Принципы построения моделей для анализа эффективности информационных систем (основа построения, достоинства и недостатки).
- 54. Методы управления сетью: коммутация каналов, коммутация пакетов.
- 55. Методы балансировки трафика
- 56. Семиуровневая модель osi
- 57. Локальные вычислительные сети (топология, методы доступа)
- 58. Методы повышения достоверности при передаче информации
- 59. Понятие качества обслуживания в компьютерных сетях. Средства обеспечения качества обслуживания.
- 60. Назначение и принцип работы интернет сети
- 61. Основные протоколы сети Интернет, их назначение.
- 62. Понятие dns. Структура доменных имен в сети Интернет.
- 63. Понятие стека протоколов. Стек протоколов tcp/ip, udp/ip.
- 64. Системы автоматизированного проектирования (сапр).
- 70. Принципы построения распределенных информационных систем. Промежуточное программное обеспечение для обработки сообщений.
- 71. Сервисно-ориентированная архитектура распределённых приложений. Основные протоколы.
- 72. Корпоративные информационные системы (класс erp). Разновидности. Решаемые задачи.
- 73. Развитие новых информационно-коммуникационных технологий как база становления информационного общества
- 74. Модели жизненного цикла программного обеспечения
- 6. Модели жц программного продукта: каскадная.
- 7. Модели жц программного продукта: итерационная.
- 8. Модели жц программного продукта: спиральная (быстрого прототипирования).
- 75. Основные принципы структурного анализа систем
- 76. Консалтинг в области информационных технологий
- 77. Методика проведения обследования объектов автоматизации
- 78. Методы построения и анализа моделей деятельности предприятия
- 79. Структурно-функциональные модели
- 80. Модели потоков данных (dfd)
- 81. Модели "сущность-связь" (erd)
- 83. Объектно-ориентированный язык визуального моделирования uml
- 84. Методология rup: назначение и основные характеристики
- 85. Диаграммы вариантов использования (use-cases diagram)
- 86. Диаграммы классов (class diagram). Основные объекты диаграммы
- 87. Диаграммы деятельности (activity diagram). Основные объекты диаграммы
- 88. Диаграммы последовательности (sequence diagramm)
- 19. Uml: диаграмма состояний.