Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

Статическое испытание свай – длинный и трудозатратный производственный процесс. Продолжительность испытания варьируется от 2 до 30 суток, на протяжении которых работник, в посменном порядке, каждый заданный промежуток времени (в среднем каждые 15 минут) обязан совершать ручное снятие данных с датчиков часового типа, а также обслуживание участка проведения испытаний. Данный тип испытаний проводится преимущественно в осенне-зимние периоды, что, на фоне отсутствия здорового продолжительного сна, провоцирует возникновение простудных заболеваний и вызывает затруднения с доступом к отдельным элементам испытательной конструкции.

Актуальность проектирования данной системы обоснована неэффективными материальными и трудозатратами, плохими условиями труда. Внедрение системы в процесс позволит значительно сократить количество выполняемых человеком действий, повысить качество измерений и условий труда.

Цель курсовой работы: изучение и применение объектно-ориентированного подхода на примере автоматизации производственного процесса.

Задачи курсовой работы:

1. Проанализировать объектно-ориентированный подход проектирования.

2. Применить объектно-ориентированный подход при проектировании автоматизированной системы сбора данных.

Таким образом, поставленные задачи помогут изучить объектно-ориентированный подход в теории и на практике.

ГЛАВА 1. ТЕОРЕТИЧЕСКАЯ ЧАСТЬ

1.1. Основные принципы и элементы объектной модели

Объектная модель является основой объектно-ориентированного подхода в проектировании.

Объект – дискретная сущность, обладающая индивидуальными свойствами (экземпляр класса).

Класс – группа объектов, обладающих общими атрибутами и операциями.

Основные принципы объектно-ориентированного проектирования:

Индивидуальность – данные делятся на объекты, отличимые друг от друга.

Классификация – объекты с одинаковыми атрибутами и операциями группируются в классы.

Наследование – наличие общих атрибутов и операций, передающихся от родителя наследнику.

Полиморфизм – одна и та же процедура/трансформация может означать разное поведение в разных классах.

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

1.2.Унифицированный язык моделирования UML

UML – унифицированный язык моделирования.

Основные свойства языка UML:

Искусственность – наличие конкретных авторов языка.

Формальность – наличие правил его употребления.

Основные элементы языка UML:

Синтаксис – определение правил построения конструкций языка.

Семантика – определение правил, в соответствии с которыми конструкции языка приобретают смысловые значения.

Прагматика – определения правил использования языка для достижения поставленных целей.

Однако в случае, как свойств, так и элементов, UML язык не однозначный, так как сочетает в себе ряд исключений. Унифицированность языка объясняется тем, что UML объединяет в себе лучшее от всех предшествующих методов построения описательной модели, почему и является единственным языком моделирования, дотягивающим до «планки» стандарта. [1]

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

1.3. Диаграммы

Далее будут описаны диаграммы, применяемые при объектно-ориентированном подходе проектирования в соответствии с нотациями UML.

Диаграмма прецедентов - это диаграмма, представляющая динамические или поведенческие действия системы.

Диаграмма составляется из эктора(actor) – действующего лица.
Прецедента(use-case) – описания отдельного действия системы с точки зрения пользователя. Прецедентов(use case) – описание группы действий системы с точки зрения пользователя.

Обозначения прецедента по стандарту UML принято проводить эллипсом, а эктора изображением человечка.

Пример оформления диаграммы прецедентов показан на Рисунке 1.

Рисунок 1. Пример диаграммы прецедентов.

Цели создания диаграмм прецедентов:

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

Диаграмма классов – это набор статических элементов системы.

Класс – группа объектов, обладающих общими атрибутами и операциями. По своей сути – это строительные блоки любой объектно-ориентированной системы.

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

Пример оформления диаграммы классов показан на Рисунке 2.

Применяется такая диаграмма как при прямом проектировании системы – создании новой, так и обратном – описании уже существующей.

Рисунок 2. Пример диаграммы классов.

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

Объект – сущность с инкапсулированным поведением и состоянием.

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

Пример оформления диаграммы объектов показан на Рисунке 3.

Рисунок 3. Пример диаграммы объектов.

Диаграмма последовательностей – это диаграмма, отображающая динамическое взаимодействие объектов во времени, измеряемом прецедентом использования. Тем самым она обозначает временные особенности приема и передачи сообщений объектами.

Объекты на диаграмме обозначаются в купе с вызовами методов (стрелки) и возвращаемыми результатами (пунктир). Вертикальные прямоугольники обозначают время жизни.

Пример оформления диаграммы последовательностей показан на Рисунке 4.

Диаграммы последовательностей используются для уточнения диаграмм прецедентов.

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

Диаграмма взаимодействия – это диаграмма, отображающая динамическое взаимодействие объектов в потоке прецедентов, не ограниченном во времени

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

Пример оформления диаграммы взаимодействий показан на Рисунке 5.

Рисунок 5. Пример диаграммы взаимодействий.

Любой объект что-то делает и что-то «знает», т.е. обладает определенным поведением и состоянием, в котором находится во времени. Чтобы объяснить, каким образом работают сложные объекты, используются диаграммы состояний.

Состояние(state) – ситуация в жизненном цикле объекта, в которой он выполняет определенное действие, ожидает какое-то событие или обладает определенным свойством. Определяется атрибутами и связями.

Диаграмма состояний показывает переход только одного объекта, обладающего поведением, из одного состояния в другое.

Состояния, через которые объект проходит в течении своей жизни, обозначаются скругленными прямоугольниками, а переходы между ними – стрелками. Сразу после создания объект находится в начальном псевдосостоянии, обозначаемом черным кружком, а после достижения состояния, из которого уже не сможет выйти – в конечном, обозначаемом черным кружком обведенным окружностью.

Пример оформления диаграммы состояний показан на Рисунке 6.

Рисунок 6. Пример диаграммы состояний.

Диаграмма активности – это диаграмма, отображающая физические модули программного кода, раскрывающая детали алгоритмов, реализующих систему.

Алгоритм – последовательность действий или операция, приводящая к желаемому результату.

Оформление диаграммы схоже с оформлением классических блок-схем алгоритмов, но с добавлением нотаций диаграмм состояний.

Пример оформления диаграммы активности показан на Рисунке 7.

Рисунок 7. Пример диаграммы активности.

Диаграмма развертывания – это графическое представление инфраструктуры, на которую будет развернуто приложение. Данная диаграмма имеет смысл только при проектировании аппаратно-программных систем. Она помогает более рационально распределить компоненты системы по узлам сети и тем самым увеличить производительность, а также увеличивает безопасность и помогает решить другие вспомогательные проблемы.

Узлы системы обозначаются на диаграмме в виде кубиков. [2]

Пример оформления диаграммы развертывания показан на Рисунке 8.

Рисунок 8. Пример диаграммы развертывания.

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

1.4.Преимущества объектно-ориентированного подхода

Основные преимущества объектно-ориентированного подхода:

Распараллеливание работ – позволяет вносить изменения и дополнения на любом этапе проектирования, без полной переработки проекта.
Упрощение внесения изменений – обозначает локальных характер внесенных изменений, в основном благодаря свойству наследования.
Гибкая архитектура и переносимость – возможность гибко и эффективно менять роли объектов в системе, возможность изменения конфигурация объектов без изменения системы.
Повторное использование программных компонентов – решения, разработанные данным методом, часто являются типовыми, что дает возможность использовать их в других приложениях.
Естественность описания – позволяет описывать как статические, так и динамические отношения между объектами модели на удобном пользователю уровне детализации.

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

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

Скорость работы приложения – динамические связи в классах увеличивают время обращения к ним.
Каскад вызовов – чрезмерное количество вызовов методом в процессе работы приложения, связанное с большим количеством методов и излишним обращением к ним.
Производительность систем на компьютерах с сегментированной организацией памяти - низкая производительность в ситуации с расположением различных классов в разных сегментах памяти устройства.
Низкая производительность выполнения задач в реальном времени – подход активно использует динамическое создание и удаление объектов, что замедляет и дестабилизирует выполнение задач в условиях реального времени.

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

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

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

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

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

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

Картинки по запросу starUML

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

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

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

Картинки по запросу MS Visio

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

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

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

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

Картинки по запросу lucidchart

Рисунок 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 существующих типов диаграмм, в силу узкой специфики отдельных из них.

Преимуществами объектно-ориентированного подхода являются:

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

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

В ходе курсовой работы была частично спроектирована информационная система мониторинга показания датчиков.

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

В дальнейшем планируется развить практическую часть данной курсовой работы.

СПИСОК ЛИТЕРАТУРЫ

Золотов, С.Ю. Проектирование информационных систем / С.Ю. Золотов ; Министерство образования и науки Российской Федерации, Томский Государственный Университет Систем Управления и Радиоэлектроники (ТУСУР). – Томск : Эль Контент, 2013. – 88 с.
Бабич, А.В. UML. Первое знакомство: Пособие для подготовки к сдаче теста UM0-100 (OMG Certified UML Professional Fundamental) / А.В. Бабич ; Национальный Открытый Университет "ИНТУИТ". – Москва : Интернет-Университет Информационных Технологий, 2008. – 176 с.
Морозова В.И., Врублевский К.Э. Визуальное моделирование информационных систем: Методические указания к выполнению лабораторных работ. – М.: МИИТ, 2009. - 28 c.
StarUML/V3, V2 [Электронный ресурс]. – Доступ с сайта URL: http://staruml.io/download.
Visio/Наглядная работа. Простые и удобные схемы. [Электронный ресурс]. – Доступ с сайта URL: https://products.office.com/ru-ru/visio/flowchart-software.
Lucidchart/See more. Know more. Do more. [Электронный ресурс]. – Доступ с сайта URL: https://www.lucidchart.com/pages/.