Бахир_7361_АрхИС_кр
.pdf
Рисунок 2 – Use case диаграмма проекта (серверная часть)
Описание для управления серверной частью приведено в таблице 3.1.
11
Таблица 3.1. Управление серверной частью
Вариант использования |
Конфигурирование сокетов |
|
|
|
|
Актеры |
Администратор |
|
|
|
|
Цель |
Выбор прослушивающего интерфейса для |
|
сервера |
||
|
||
|
Администратор выбирает параметры |
|
Краткое описание |
прослушивающего сокета для дальнейшего |
|
|
использования |
|
|
|
|
Тип |
Базовый |
|
|
|
|
Ссылки на другие варианты |
Включает в себя: Выбор listening ip, Выбор |
|
использования |
прослушивающего порта |
В таблице 3.2 описывается последовательность действий, приводящая к успешному выполнению варианта использования – конфигурация сокетов.
Таблица 3.2. Ход действий для управления сервером
Действия актеров |
Отклик системы |
|
|
|
|
1. Администратор редактирует файл |
2. Параметры конфигурации доступны в |
|
конфигурации программы |
соответствующем файле и их можно |
|
видеть в одном месте |
||
|
||
|
4. Система отображает информацию о |
|
3. Администратор запускает |
полученной конфигурации, |
|
программу с указанием файла |
администратор убеждается, что |
|
конфигурации |
механизм считывания конфигурации |
|
|
работает правильно |
|
5. Администратор подключает |
6. Система отображает информацию о |
|
том, что подключение произошло |
||
проверочного клиента к серверу |
||
успешно |
||
|
12
Описание моделирования работы системы приведено в таблице 3.3.
Таблица 3.3. Моделирование работы системы
Вариант использования |
Моделирование работы системы |
|
|
|
|
Актеры |
Пользователь |
|
Цель |
Визуализация работы производственного цеха |
|
|
|
|
|
Пользователь запускает моделирование работы |
|
Краткое описание |
цеха чтобы визуализировать производство и |
|
|
оценить эффективность работы |
|
|
|
|
Тип |
Базовый |
|
|
|
|
Ссылки на другие варианты |
Включает в себя: выбор параметров работы, |
|
выбор оснащения цеха. |
||
использования |
||
Предшествует: просмотр рабочего процесса |
||
|
В таблице 3.4 описывается последовательность действий, приводящая к успешному выполнению варианта использования – моделирование работы
системы.
Таблица 3.4. Ход действий для моделирования работы системы
|
Действия актеров |
Отклик системы |
|
|
|
|
|
1. |
Пользователь выбирает |
2. Система отображает количество |
|
количество работников |
работников |
||
|
|
|
|
3. |
Пользователь распределяет |
4. Система сообщает о количестве |
|
нераспределённых работников, чтобы |
|||
работников по рабочим местам |
|||
пользователь |
|||
|
|
||
5. |
Пользователь запускает тест, но у |
6. Система сообщает пользователю об |
|
него остались нераспределённые |
этом, спрашивает подтверждение на |
||
работники |
запуск тестов. |
||
7. |
Пользователь запускает тесты. |
8. Система переводит фокус на окно |
|
отображения рабочего процесса |
|||
|
|
||
|
|
|
|
13
2.3.2. Диаграмма классов
Описание диаграммы классов: в данном проекте можно выделить два независимых друг от друга пакета – Client и Server. Они представлены на рисунке
3. Пакет Client агрегирует классы, реализующие логику интерфейсной части приложения и нацелен на участие в сборке той части приложения, которая будет доставляться конечному пользователю (User и New user из Actors). Пакет Server
в свою очередь агрегирует классы, реализующие логику части приложения,
отвечающую за обработку и генерацию данных.
Рисунок 3 – основные пакеты приложения
`
14
Рисунок 4 – диаграмма классов пакета Client
Рисунок 5 – диаграмма классов пакета Server
15
Класс MainWindow клиентской части приложения описывает окно отрисовки интерфейса программы. Метод establishConnection реализует подключение к серверной части и создаёт объект класса ConnectionManager,
который отвечает за подключение к управляющему серверу. Метод updateConfigurationData позволяет обновить желаемую конфигурацию модели тестируемой системы. Этот метод считывает с пользовательского интерфейса выбранные настройки конфигурации и отправляет их в серверную часть приложения используя ConnectionManager.
Класс ConnectionManager используется для делегации работы с протоколом tcp/ip из основного кода приложения. Таким образом бизнес-логика отделяется от манипулирования пакетами передачи дынных. Этот класс обеспечивает консистентность передаваемых и получаемых данных, валидируя принимаемые настройки на программном уровне.
Класс Worker серверной части описывает работу одной единицы системы.
Позволяет задавать продуктивность работы и моделировать поведение отдельно взятой части этой системы.
Класс TimeModel отвечает за манипуляцию со временем моделируемой системы. Для получения статистики работы системы в долгосрочном периоде возможна необходимость в масштабировании по времени. Также это повышает удобство использования приложения, позволяя выбирать скорость проработки модели. Класс имеет атрибут speed – коэффициент масштабирования по времени и метод delay, позволяющий выполнять задержку по времени с указанным масштабом.
Класс MainProcess реализует модель системы, получая информацию о работе от агрегированных объектов класса Worker по заданной модели
TimeModel. Сгенерированные данные возвращаются клиенту при помощи объекта класса ConnectionManager.
16
2.3.3. Диаграмма активности
Описание диаграммы активности: для каждого пользователя, описанного ранее, существует определённый набора активностей. Так единственная возможность новых пользователей – подключение к управляющему серверу.
Следующая группа пользователей – обычные пользователи. Им доступна возможность выбора конфигурации моделирования и просмотра информации о производстве. Также на диаграмме отображён процесс взаимодействия клиентской и серверной части. Такое представление позволяет определить артефакты той и другой части приложения, а именно: данные конфигурации,
данные о производстве.
Последняя группа пользователей – администраторы. Необходимое действие администратора – конфигурация серверной части приложения. После этого ему доступен мониторинг работы системы.
На рисунке 6 приведена диаграмма активностей для данного проекта.
Рисунок 6 – Диаграмма активностей
17
2.3.4. Диаграмма развёртывания
Для развёртывания готового проекта необходим сервер с установленным python3.8. Диаграмма развёртывания проекта приведена на рисунке 7.
Пользователь со своего ПК открывает клиентское приложение и задаёт параметры подключения к серверу. После успешного подключения ему открываются возможности, перечисленные в use cases.
Рисунок 7 – Диаграмма развёртывания
18
3. ТЕСТЫ
Функциональность готового приложения должна быть протестирована в
нескольких вариантах:
1.Юнит-тесты (в соответствии с диаграммой классов)
2.Функциональные тесты (в соответствии с use cases и заявленными функциями приложения):
a.Со стороны пользователя:
i.Корректность подключения к серверу
ii.Возможность просмотра рабочего процесса (количество рабочих, эффективность станков, продуктивность рабочих)
iii.Возможность моделирования поведения цеха в различных условиях (выбор параметров работы, выбор оснащения цеха)
b.Со стороны сервера:
i.Возможность конфигурации прослушивающих сокетов
ii.Возможность корректной конфигурации вычислительных ресурсов, выделяемых приложению
3.Нагрузочные тесты:
a.Обрабатывая полученные данные для отображения,
клиентская часть должна оставаться отзывчивой к действиям пользователя и не останавливать свою работу
b.Обрабатывая смоделированные данные, серверная часть должна отслеживать клиентов, потребляющих слишком много вычислительных ресурсов и своевременно реагировать на превышение выставленного лимита.
4.User acceptance тесты:
a.Интерфейс приложения должен быть понятным и интуитивным
19
b.Приложение должно соответствовать сценариям использования, описанным в параграфе 2.3.1, а именно проявлять описанное поведение и предоставлять пользователю соответствующий сценарию использования отклик
c.Информационные сообщения, выводимые приложением,
должны быть понятны для конечного пользователя и верно доносить необходимую информацию
20