Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Основные принципы и элементы объектной модели).pdf

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 30.03.2023

Просмотров: 230

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

Стоит отметить, что большинство перечисленных проблем уже имеют решения в среде специалистов и при грамотном подходе можно существенно нивелировать недостатки подхода. [3]

Таким образом, недостатками объектно-ориентированного подхода являются:

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

1.5.Анализ программных продуктов, для объектно-ориентированного подхода проектирования.

Программа StarUML примечательна функциональностью и очень удобным, интуитивно понятным интерфейсом. Она поддерживает самые последние версии стандарта UML, а за счет возможности подключения модулей она также способна на интеграцию с MS Word, Excel и PowerPoint. Поддерживает импорт Rational Rose. [4]

Интерфейс программы StarUML продемонстрирован на Рисунке 9.

Рисунок 9. Интерфейс StarUML.

Основным конкурентом StarUML рассматривался MS Visio. Но он оказался платным. Однако интерфейс данной программы на высоте и именно оттуда были позаимствованы некоторые фишки в StarUML. [5]

Интерфейс программы MSVisio продемонстрирован на Рисунке 10.

Рисунок 10. Интерфейс MS Visio.

Что касается условно бесплатных аналогов, например Lucidchart – программа также имеет удобный интерфейс и высокую функциональность, однако располагается исключительно на сервере компании и не подразумевает «десктопного» оффлайн использования. [6]

Интерфейс программы Lucidchart продемонстрирован на Рисунке 11.

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

Рисунок 11. Интерфейс LucidChart.

Именно за счет своей простоты и удобности, а также привычности было отдано предпочтение программе StarUML в борьбе между такими аналогами, как MS Visio и Lucidchart.

ГЛАВА 2. ПРАКТИЧЕСКАЯ ЧАСТЬ

2.1. Диаграмма прецедентов

Была составлена диаграмма прецедентов, результат продемонстрирован на Рисунке 12.


Рисунок 12. Диаграмма прецедентов.

Актеры:

Пользователь - это человек, который устанавливает датчики на сваи, следит за ее смещением, корректирует ее смещение.

Датчики - это внешняя система, которая снимает значения с тонометров в виде снимков.

База данных - это хранилище фотографий, настроек и снятых значений.

Прецеденты:

Сформировать имя снимка - прецедент используется датчиком, при создании фотографии.

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

Просмотреть данные - этот прецедент используется базой данных, для отображения данных пользователю.

Настроить - прецедент используется всеми актерами, для корректной работы системы.

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

Была построена диаграмма классов, результат продемонстрирован на Рисунке 13.

Рисунок 13. Диаграмма классов.

Далее в Таблице 1, Таблице 2, Таблице 3 и Таблице 4 описаны сущности Pile, Sensor, Connection, Photo.

Класс Pile Таблица 1.

Параметр

Значение

Комментарий

Сущность, представляющая собой, установленные сваи

Атрибуты

Private idFile: Int – уникальное имя сваи

Операции

Add() – добавление новой сваи

Edit() – редактирование добавленной сваи

Remove() – удаление записи сваи

getInfo() – получение информации о свае

Все операции имеют модификатор public

Класс Sensor Таблица 2.

Параметр

Значение

Комментарий

Сущность, представляющая собой, установленные датчики

Атрибуты

Private idSensor: Int – уникальное имя датчика

Private axis: Char – ось, на которой установлен датчик

Операции

Add() – добавление нового датчика

Edit() – редактирование добавленного датчика

Remove() – удаление записи датчика

getInfo() – получение информации о датчике

Все операции имеют модификатор public

Класс Connection Таблица 3.


Параметр

Значение

Комментарий

Сущность, представляющая собой, связь между датчиком и сваей

Атрибуты

Private idConnection: Int – уникальное имя связи

Операции

create() – добавление новой связи

Edit() – редактирование добавленной связи

Remove() – удаление записи связи

getInfo() – получение информации о связи

Все операции имеют модификатор public

Класс Photo Таблица 4.

Параметр

Значение

Комментарий

Сущность, представляющая собой, установленные значения фотографий

Атрибуты

Private idPhoto: Int – уникальное имя снимка

Private time: Date – время и дата создания снимка

Private value: Int –значение со снимка

Операции

create() – добавление нового снимка

getInfo() – получение информации со снимка

Все операции имеют модификатор public

Далее в Таблице 5 и Таблице 6 описаны интерфейсы Sensor и Processing

Интерфейс Sensor Таблица 5.

Параметр

Значение

Комментарий

Сущность, представляющая собой создание фотографии

Операции

createPhotoName() – создание имени фотографии

Интерфейс Processing Таблица 6.

Параметр

Значение

Комментарий

Сущность, представляет собой обработку фотографии

Операции

getValue() – получение значения с фотографии

Управляющий класс User представляет собой пользователя, взаимодействующего с системой.

Граничащий класс Sort служит для сортировки данных.

Граничащий класс Filter служит для фильтрации данных.

Граничащий класс GetInfo служит для получение данных для мониторинга.

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

Далее описана диаграмма состояний для настройки датчиков, результат продемонстрирован на Рисунке 14.

Рисунок 14. Диаграмма состояний.


Далее в Таблице 7 описаны состояния датчика.

Описание состояний датчика Таблица 7.

Состояние

Описание состояния

Добавляется

Добавление нового датчика, ввод данных

Добавлен

Датчик добавлен

Отображен

Датчик отображен для пользователя

Выбран

Датчик выделен

Редактируется

Изменение имени и оси датчика

Удаляется

Удаление записи датчика

Изменен

Данные датчика изменены

Удален

Датчик удален

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

Была построена диаграмма последовательностей для сценария «Просмотреть данные», результат продемонстрирован на Рисунке 15.

Рисунок 15. Диаграмма последовательностей.

Была построена диаграмма взаимодействий, результат продемонстрирован на Рисунке 16.

Рисунок 16. Диаграмма взаимодействий.

Далее дано краткое описание диаграммы взаимодействия, Таблица 8.

Описание сообщений диаграммы взаимодействия Таблица 8.

Номер сообщения

Объект – отправитель сообщения

Объект – получатель сообщения

Название

1

Данные фотографий

Вывод данных

Передача данных

2

Вывод данных

Пользователь

Получение всех данных

3

Данные свай

Пользователь

Получение данных о всех сваях

4

Пользователь

Фильтр

Выбор свай

5

Фильтр

Данные связи

Запрос на получение отфильтрованных данных

6

Данные связи

Данные датчиков

Поиск датчиков по выбранным сваям

7

Данные датчиков

Данные связи

Получение датчиков выбранных свай

8

Данные связи

Пользователь

Вывод датчиков

9

Данные датчиков

Пользователь

Получение данных о всех датчиках

10

Пользователь

Фильтр

Выбор датчиков

11

Фильтр

Данные фотографий

Запрос на получение отфильтрованных данных

12

Данные фотографий

Вывод данных

Передача отфильтрованных данных

13

Вывод данных

Пользователь

Вывод отфильтрованных данных

14

Пользователь

Сортировка

Выбор сортировки

15

Сортировка

Данные фотографий

Запрос на получение отсортированных данных

16

Данные фотографий

Вывод данных

Передача отсортированных данных

17

Вывод данных

Пользователь

Вывод отсортированных данных


2.5.Диаграмма активности

Бала построена диаграмма активности для потока событий прецедента «Просмотреть данные», результат продемонстрирован на Рисунке 17.

Рисунок 17. Диаграмма активности.

Пользователь не выбирает фильтров, программа выводит все датчики. Пользователь выбирает фильтры: сваи, сваи и соединенные с ними датчики, датчики.

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

Была построена диаграмма пакетов, результат продемонстрирован на Рисунке 18.

Рисунок 18. Диаграмма пакетов.

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

Была простроена диаграмма компонентов для клиентской части, результат продемонстрирован на Рисунке 19.

Рисунок 19. Диаграмма компонентов.

2.8.Диаграмма развертывания

Была построена диаграмма развертывания для системы мониторинга данных датчиков, результат продемонстрирован на Рисунке 20.

Рисунок 20. Диаграмма развертывания.

FTP Server, Приложение (Application), База данных (DataBase) установлены на ноутбук.

Система датчиков (Sensors) взаимодействует с FTP Server через беспроводную локальную сеть.

Ноутбук(Laptop) должен иметь минимальные требования: напишу их

Таким образом, была частично спроектирована информационная система мониторинга показания датчиков.

ЗАКЛЮЧЕНИЕ

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

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