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

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

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

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

Добавлен: 23.04.2023

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

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

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

Рисунок 10 Диаграмма состояний заказного товара

С состоянием можно связать пять основных типов данных: деятельность, входное действие, выходное действие, событие и история состояния.

Деятельность представляет собой определенное поведение, пока объект находится в определенном состоянии и всегда имеет окончание. К примеру, компьютер находящийся в «режиме ожидания» без нового действия переходит в «спящий (или энергосберегающий) режим».

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

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

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

Диаграмма деятельности – способ представления большого потока событий в оптимизированном, схематичном виде, для избегания запутанности. Такая диаграмма имеет в своей основе деятельность (activity). Эта деятельность должна быть на что-то направлена, к примеру это может быть выполнение какого-либо действия или задачи. У каждой диаграммы деятельности должна быть начальная точка – то место, с которого начинается поток событий. Иметь конечную точку не обязательно, однако их может быть большое множество так же, как и в случае с диаграммой состояний. В диаграмме могут быть представлены различные объекты или потоки объектов. Сами же объекты связываются с деятельностью через потоки объектов.

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

Рисунок 11 Диаграмма компонентов для банковской системы

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


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

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

Сообщение (message) — средство запроса

Информационное (informative) сообщение — сообщение, обеспечивающие информацией другие инстанции

Сообщение-запрос (interrogative) — сообщение, в основе которой есть потребность получения какой-либо информации

Императивное (imperative) сообщение — сообщение, в основе которого лежит запрос информации у получателя услуги

Существуют два вида диаграмм взаимодействия: диаграммы последовательности и кооперативные диаграммы.

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

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

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

Заключение:

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

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