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
Особенностями полиморфизма на уровне экземпляров класса являются:
- Лямбда-функции - анонимные функции, построенные на основе лямбда-исчисления. В них нет строго определенных типов принимаемых аргументов, как следствие, такие функции априори полиморфны.
- Объектно-ориентированные языки без строгой типизации, такие как JavaScript. В подобных языках не требуется определять тип переменной в обязательном порядке. Чем сильнее система типизации, тем строже правила. В JavaScript класс может не иметь строгой спецификации, то есть определения его свойств и методов.
Таким, образом типы конвертируются автоматически:
4 + '7'; // '47'
4 * '7'; // 28
2 + true; // 3
false - 3; // -3
Диаграмма активностей (видов деятельности) как и диаграмма состояний, отражает динамические аспекты поведения системы. По существу, эта диаграмма представляет собой блок-схему, которая наглядно показывает, как поток управления переходит от одной деятельности к другой.
Основными элементами диаграммы являются:
- исполняемые узлы
- объекты
- переходы
- управляющие узлы
- коннекторы
- группирующие узлы
Диаграмма деятельности позволяет любому, кто выполняет данный процесс, выбирать порядок действий. Другими словами, диаграмма только устанавливает правила обязательной последовательности действий, которым я должен следовать [5].
Пример:
Активности на диаграмме “разбросаны” по беговым дорожкам, каждая из которых соответствует поведению одного из объектов (например, клиента, менеджера, веб-сервера, сервера БД и т.п.). Благодаря этому легко определить, каким из объектов выполняется каждая из активностей. Дорожка - часть области диаграммы деятельности, на которой отображаются только те активности, за которые отвечает конкретный объект. Предназначены дорожки для разбиения диаграммы в соответствии с распределением ответственности за действия. Имя дорожки может означать роль или объект, которому она соответствует [4].
На диаграмме деятельности применяют один основной тип сущностей ‒ действие, и один тип отношений ‒ переходы(передачи управления и данных).
Действующим лицом на диаграмме деятельности является объект. Зачастую они представляют собой какие-то роли, подразделения, должностные лица и т.д. Могут как инициировать действия, так и являться их результатом. Названия объектов записываются в начале дорожки. Дорожки изображаются в нескольких видах, как указано на следующем рисунке:
Действующее лицо является внешним источником (не элементом системы), который взаимодействует с системой через вариант использования. Действующие лица могут быть как реальными людьми (например, пользователями системы), так и другими компьютерными системами или внешними событиями.
Действующие лица представляют не физических людей или системы, а их роли. Эти означает, что когда человек взаимодействует с системой различными способами (предполагая различные роли), он отображается несколькими действующими лицами. Например, человек, работающий в службе поддержки и принимающий от клиентов заказы, будет отображаться в системе как «участник отдела поддержки» и «участник отдела продаж».
Действующие лица могут иметь два типа связей с вариантами использования: Простая ассоциация — отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования.
Направленная ассоциация — то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.
Отличие от диаграммы вариантов использования. Диаграмма вариантов использования дает нам представление ЧТО должна делать Система. На вопрос КАК мы можем ответить, используя диаграмму активности [5].
При выполнении последовательности действий, описанной в определенной диаграмме деятельности UML, в зависимости от исхода действия определенный объект может выполнять или не выполнять те или иные действия. Соответственно одна такая диаграмма может иметь множество реализаций, что является сутью полиморфизма.
В ВКР может быть использована диаграмма действий UML для отражения динамических аспектов поведения системы анализа эффективности систем криптографической защиты информации на основе дискретного логарифмирования на эллиптических кривых.