exam_04
Полиморфизм — возможность объектов с одинаковой спецификацией иметь различную реализацию. Понятие " полиморфизм " может трактоваться как способность объекта принадлежать более чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под разными углами зрения, выделять при построении абстракций разные аспекты сущностей моделируемой предметной области, не нарушая при этом целостности объекта. (Строго говоря, существуют и другие виды полиморфизма, такие как перегрузка и параметрический полиморфизм, но нас они сейчас не интересуют.)
Язык программирования поддерживает полиморфизм, если классы с одинаковой спецификацией могут иметь различную реализацию — например, реализация класса может быть изменена в процессе наследования [1]. как пример подхода могу привести контейнирезацию собираемую в yml файле. имеется образ(read only шаблон) над ним строется еще одна оболочка и это все все базовая настройка что не меняется ,но вынесены переменные окружения аргументы.
и когда необходимо создать новый сервис в контейнере
той же сборки только настройки другие ничего кроме вынесенных аргументов не меняется
это полиморфизм в своем роде.
вот мини пример такого подхода в пометке build берется образ и дальше указываются переменные. тем самым и придерживается ооп подход
services:
zabbix-server:
build: ./server-pgsql/ubuntu
image: zabbix-server-pgsql:ubuntu-local
ports:
- "10051:10051"
volumes:
- /etc/localtime:/etc/localtime:ro
- ./zbx_env/usr/lib/zabbix/alertscripts:/usr/lib/zabbix/alertscripts:ro
- ./zbx_env/usr/lib/zabbix/externalscripts:/usr/lib/zabbix/externalscripts:ro
- ./zbx_env/var/lib/zabbix/export:/var/lib/zabbix/export:rw
links:
- postgres-server:postgres-server
- zabbix-java-gateway:zabbix-java-gateway
ulimits:
nproc: 65535
nofile:
soft: 20000
hard: 40000
deploy:
resources:
limits:
cpus: '0.70'
memory: 1G
reservations:
cpus: '0.5'
memory: 512M
env_file:
- .env_db_pgsql
- .env_srv
secrets:
- POSTGRES_USER
- POSTGRES_PASSWORD
Диаграмма активностей (видов деятельности) как и диаграмма состояний, отражает динамические аспекты поведения системы. По существу, эта диаграмма представляет собой блок-схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой.
Диаграмма деятельности позволяет любому, кто выполняет данный процесс, выбирать порядок действий. Другими словами, диаграмма только устанавливает правила обязательной последовательности действий, которым я должен следовать [5].
Пример:
Активности на диаграмме “разбросаны” по беговым дорожкам, каждая из которых соответствует поведению одного из объектов (например, клиента, менеджера, веб-сервера, сервера БД и т.п.). Благодаря этому легко определить, каким из объектов выполняется каждая из активностей. Дорожка - часть области диаграммы деятельности, на которой отображаются только те активности, за которые отвечает конкретный объект. Предназначены дорожки для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует [4].
На диаграмме деятельности применяют один основной тип сущностей ‒ действие, и один тип отношений ‒ переходы(передачи управления и данных).
Действующим лицом на диаграмме деятельности является объект. Зачастую они представляют собой какие-то роли, подразделения, должностные лица и т.д. Могут как инициировать действия, так и являться их результатом. Названия объектов записываются в начале дорожки. Дорожки изображаются в нескольких видах, как указано на следующем рисунке:
Действующее лицо является внешним источником (не элементом системы), который взаимодействует с системой через вариант использования. Действующие лица могут быть как реальными людьми (например, пользователями системы), так и другими компьютерными системами или внешними событиями.
Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».
Действующие лица могут иметь два типа связей с вариантами использования: Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.
Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.
Отличие от диаграммы вариантов использования. Диаграмма вариантов использования дает нам представление ЧТО должна делать Система. На вопрос КАК мы можем ответить, используя диаграмму активности [5].
Диаграммы последовательности UML представляют собой спецификацию объекта или процесса и тем самым обеспечивают наличие полиморфизма. Одна диаграмма последовательности UML может иметь несколько реализаций, что представляет собой суть полиморфизма.
Полиморфизм можно использовать при написании выпускной квалификационной работы. Например, при разработке автоматизированной системы контроля количества товара на складе диаграмма последовательности может быть реализована различными методами.