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

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

Содержание:

Введение

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

Информационные системы (ИС) на сегодняшний день занимают одно из важнейших мест в функционировании предприятий и организаций. Информационные системы позволяют вести учет и контроль многих функций предприятия. А задача проектирования и создания информационной системы актуальна.

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

Объектом исследования данной курсовой работы является объектно-ориентированный подход проектированию информационных систем.

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

Целью курсовой работы является исследование основных принципов и особенностей ООП и унифицированного языка моделирования UML.

В курсовой работе будут рассмотрены следующие вопросы:

Основные понятия и концепции объектно-ориентированного подхода к моделированию ИС
Обзор и анализ унифицированного процесса разработки ИС
Основные структуры и понятия унифицированного языка моделирования UML
Разработка модели ИС с использованием унифицированного языка моделирования UML

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

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

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

1 Проектирования информационных систем с помощью унифицированного языка моделирования UML

1.1 Объектно-ориентированных подход моделирования информационных систем

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

При использовании такого метода моделирования системы^[1] возможно построение бизнес-модели системы, в которой осуществляется переход от предметной модели к модели, в которой описаны объекты, реализующие бизнес-функции проектируемой информационной системы^[2].

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

Согласно^[3] объект – это некоторая сущность, абстракция (проекция, модель), которая реализует (повторяет) реальную или воображаемую сущность с четко определенными границами, состоянием и поведением. Другими словами, объект – это некоторая реализуемая сущность, которая описывает предметы или функции реального мира и способна обладать некоторыми индивидуальными свойствами и методами взаимодействия с другими объектами.

Абстракция^[4] – это процесс, при котором свойства и связи влияющие на изучение системы делятся на значимые и не значимые с целью более тесного участия других деталей, представляющих интерес. При этом категория «значимое» - «незначимое» не имеет постоянный характер и зависит от проектируемой системы.

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

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

Основной особенностью объектно-ориентированного подхода является тесная взаимосвязь функционирования моделей организации и моделей проектируемой информационной системы на всех этапах ее жизненного цикла^[5]: от постановки требований до конечной реализации. На базе таких моделей можно проследить отображение реальных структурных единиц организации в объекты и классы проектируемой информационной системы.

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

Унифицированный процесс – это описание этапов, которые необходимо реализовать при разработке системы.

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

Унифицированный язык моделирования (UML) представляет собой основу унифицированного процесса проектирования ИС, который в свою очередь является основной особенностью и преимуществом объектно-ориентированного подхода^[6]

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

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

1.2 Унифицированный процесс разработки информационных систем

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

Так же методология унифицированного процесса разработки информационных систем содержит описание:

технологический процесс (вопрос «когда?») - определенной последовательности всевозможных видов работ, с помощью которых достигается решение тех или иных задач. Технологический процесс представляется в виде диаграммы, на которой показан состав работ и их последовательность для текущей стадии разработки информационной системы;
вид деятельности (вопрос «как?») – работы, которые реализует исполнитель (рисунок 1);
исполнитель (ответ на вопрос «кто?») – осуществляющие разработку и реализацию проекта отдельные лица или группы лиц. Исполнителя характеризует определенная обязанность (роль) и набор функций (виды работ), которые определяют его поведение. Один и тот же исполнитель может выполнять различные функции (роли) (рисунок 2);
артефакт (вопрос «что?») – информация, создаваемая, изменяемая или используемая исполнителем или исполнителями в процессе реализации проекта. Артефактом может выступать не только то, что создается в результате работы (технические артефакты – исходные коды программ, модели системы, готовая информационная система, сопроводительная документация и пр.), но и то, что управляет этими работами (артефакты управления – техзадание, инструкции, календарный план и пр.) (рисунок 3);
используемые инструменты и утилиты (вопрос «с помощью чего?») – программных средств и систем, которые применяются при реализации проекта.

Рисунок 1 – Пример вида деятельности

Рисунок 2 – Пример исполнителя

Рисунок 3 – Примеры артефактов

Основными принципами унифицированного процесса проектирования являются следующие^[8]:

проектирование осуществляется итеративно, поэтапно;
проектирование ведется на основе требований, реализация и изменение которых постоянно контролируются. Основными требованиями являются функциональные (варианты использования системы);
модульная система построения. Система должна быть проектирован и построена таким образом, чтобы свести к минимум виляние последующих этапов на предыдущие. Это уменьшает число итераций этапов реализации проекта и повышает модульность и масштабируемость системы;
использование визуального моделирования с целью создания полного и согласованного представления всех аспектов разрабатываемой системы. Поэтому в качестве основного средства моделирования используется язык UML;
технологические процессы должны поддерживаться и выполняться при помощи инструментов и утилит.

Унифицированный процесс^[9] графически можно представить в виде расходящейся спиральной стратегии жизненного цикла информационной системы, разработанной Барри Боэм (рисунок 4).

Рисунок 4 – Спиральная стратегия жизненного цикла информационной системы

Каждый виток расходящейся спирали представляет итеративное увеличение функциональности проектируемой системы при постоянном наборе техпроцессов и фаз (рисунок 5)^[10]. Внутри каждой из фаз разработка также ведется по спиральной модели.

В начале каждого этапа определяется необходимое количество итераций, с необходимым приращением степени достижения поставленной задачи. При каждом этапе итерации реализуются все процессы: от формирования требований до внедрения ^[11].

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

Рисунок 5 – Распределение процессов при проектирование информационной системы

Технологический процесс «Управление проектами» можно представить в виде диаграммы.

Рисунок 6 – Диаграмма технологического процесса «Управление проектом»

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

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

В унифицированном процессе модели, обычно, отображают основные технологические процессы. Каждая модель представлена в виде набора взаимосвязанных UML-диаграмм и документов. Описание каждой из моделей представлена таблице 1^[12].

Таблица 1 – Характеристика унифицированных моделей

Процесс	Модель	Описание
Формирование требований	Модель вариантов использования	Показывает значимые функциональные требования к проектируемой системе. Форма представления – максимально наглядная для тех, кто будет эксплуатировать проектируемую систему. Под значимыми функциональными требованиями понимаются требования, реализация которых требуется пользователям для эффективного выполнения каких-либо бизнес-функций. Важно, что модель имеет минимальную формализованность, однако именно она управляет всеми будущими этапами проектирования системы.
Анализ требований	Модель анализа	Постановка требований к проектируемой системе, с учетом вариантов ее использования и внутренней архитектуры: анализ состава классов и отношений между ними.
Проектирование	Модель проектирования	Составление детального представления алгоритмов работы проектируемой системы. Моделируется внутренняя архитектура системы. Модель используется внутри организации, которая занимается проектированием системы.
Реализация	Модель реализации	Описывает реализацию исполняемой системы: компоненты (исходные тексты, исполняемые модули пр.) и схемы развертывания системы.
Тестирование	Модель тестирования	Применяется для тестирования проектируемой системы и соответствия достигнутых результатов необходимым.

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

Рисунок 7 – Модель

Модели могут входить в состав других моделей. Такая иерархия моделей может быть представлена двумя различными способами (рисунок 8).

Рисунок 8 – Способы иллюстрации вложенности моделей

Множество артефактов, получаемых в унифицированном процессе и как сам технологический процесс можно представить в виде диаграммы.

На рисунке 9 представлен пример диаграммы артефактов «Управления проектом»^[13].

Рисунок 9 – Диаграмма артефактов процесса «Управление проектом»

Своевременное и качественное выполнение поставленных задач по проектированию невозможно без применения специальных инструментов и утилит – средств автоматизации. К ним можно отнести инструментальные средства, предназначенные для обеспечения и поддержки жизненного цикла информационной системы. Линейка продуктов компании IBM Rational, является ярким примером объектно-ориентированного подхода к разработке информационных систем:

IBM Rational Rose^[14] – стандарт де-факто в сфере визуального моделирования и генерации объектного кода;
IBM Rational Requisite Pro – средство управление требованиями к приложениям и системам на всех этапах разработки проекта;
IBM Rational Clear Case – система управления версиями и конфигурациями;
IBM Rational Rapid Developer – среда для быстрой разработки на основе моделей;
IBM Rational Clear Quest – управление изменениями, помогает устранять дефекты, вносить изменения;
IBM Rational Team Test – межплатформенное решение для тестирования и анализа работы системы.
IBM Rational SoDA – автоматизированное решение для создания сопроводительной документации;

IBM Rational Rose комплексное решение визуального проектирования информационной системы с использованием широкого круга инструментальных средств и платформ. Его основные функции:

модельное проектирование – построение модели предметной области в виде диаграмм UML и глоссария;
генерация кода – автоматическая генерация кода на основе построенной модели;
генерация скриптов DDL3, схем баз данных Oracle и xml-документов;
реинжиниринг (обратное проектирование) – построение или восстановление модели на основе представленного кода программы, скрипта, базы данных или xml-документа;
синхронизация модели с ее физической реализацией для организации итеративного проектирования системы.

IBM Rational Rose позиционируется как универсальный инструмент анализа, разработки и проектирования.

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

1.3 Структура унифицированного языка моделирования (UML). Основные понятия

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

Общая структура UML представлена на рисунке 10^[15].

Семантика – раздел языкознания, который изучает значение языковых единиц.

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

Можно сказать, что, в случае с UML синтаксис и семантика^[16] представляют собой стиль построения моделей, который транслирует (преобразует, переводит) формальное описание естественным языком поведение информационной системы в представление элементов модели, которые более удобно описать программным кодом.

Рисунок 10 – Структура UML

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

В унифицированном языке UML доступно три типа сущностей:

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

Для указания вида связей отношений между элементами UML-диаграммы используются следующие обозначения представленные в таблице

Таблица 2 – Отношения между элементами диаграммы UML^[17]

Название	Обозначение	Семантика
Ассоциация		Прямая тесная связь между двумя и более сущностями.
Агрегация		Подкласс ассоциации, представляющий связь «часть - целое» (ромб), при которой они могут существовать отдельно друг от друга. Отношение агрегация может существовать только между сущностями одного и того же типа.
Композиция		Подкласс агрегации, при котором «части» и «целое» не могут существовать отдельно.
Зависимость		Отношение между двумя сущностями, при котором изменение состояния независимого элемента вызывает изменение состояния зависимого элемента. Независимый элемент указывается со стороны стрелки.
Обобщение		Отношение между родительской обобщенной сущностью (отмечается треугольником) и конкретизированной дочерней сущностью (потомком). Отношение обобщение возможно только между сущностями одного типа.
Реализация		Отношение между сущностями, когда одна из них определяет действие (указывается со стороны стрелки), которое другая должна выполнить. Отношения используются в следующих случаях: между вариантами использования и кооперациями, между интерфейсами и классами.

Для отношений типа Ассоциация, Агрегация и Композиция можно указывать кратность, которая показывает общее количество экземпляров сущностей, состоящих в отношении. Кратность указывается с каждой стороны отношения возле соответствующей сущности. Способы указания кратности:

любое число экземпляров (допускается нулевое значение);
любое целочисленное положительное значение, кратность которого строго фиксирована;
диапазон положительных целых чисел, допускается нижний предел равный нулю. Например, (0..10);
диапазон положительных целых чисел с «открытым» конечным значением например (10..*);
перечисление последовательности целочисленных положительных значений или/и указание диапазона через запятую, например: 0, 5..10.

Значение кратности по умолчанию равно единице. Т.е. если рядом с обозначением отношения нет указания кратности, то и кратность имеет значение равно 1, а не 0. Следует учесть, что для отношений Зависимость, Обобщение и Реализация кратность всегда имеет значение равное единице.

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

Таблица 3 – Условные обозначения механизмов расширения UML

Название	Обозначение	Семантика
Стереотип	« »	Уточнение семантики элемента.
Сторожевое условие	[ ]	Логическое условие.
Ограничение	{ }	Ограничение семантики элемента модели.
Помеченное значение	{ }	Задание нового или уточняющего свойства элемента.

Кроме текстовых стереотипов (представляют собой строку текста в кавычках), на UML-диаграммах так же используются графические стереотипы. На рисунке 11 представлено графическое условное обозначение стандартного и стереотипного отображения класса.

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

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

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

В таблице 4 представлены связи моделей системы и диаграмм.

Таблица 4 - Связь моделей и диаграмм

Модель	Диаграмма
Модель	Вариантов использования	Состояний	Классов	Кооперации	Последовательности	Деятельности	Компонентов	Развертывания
Вариантов использования	+	+	+	+	+
Анализа	+	+	+	+	+
Проектирования		+	+	+	+	+
Реализации			+				+	+

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

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

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

2. Моделирование информационной системы с использованием унифицированного языка моделирования UML на примере магазина радиоэлектронных товаров

2.1 Обзор объекта «Магазина радиоэлектронных товаров»

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

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

Рассмотрим основные процессы, происходящие на этапе заказ-продажа.

1. Менеджер отдела продаж получает заявку от офлайн или онлайн клиента на покупку электроники. Заявка содержит дату покупки, наименование и количество единиц товара, а так же его стоимость. Далее поступившая заявка регистрируется в журнале заявок.

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

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

Если срок оплаты заявки превышает установленные сроки, то в журнале учета счетов менеджером делается отметка, о том, что выставленный счет просрочен. Заявка аннулируется. В журнале заявок делается соответствующая пометка.

Менеджер отправляет оплаченные счёта о покупке продавцу-консультанту. Менеджер делает пометку в журнале заявок.

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

В конце месяца менеджером отдела продаж на основании журнала заявок

В конце каждого месяца на основании журнала заявок менеджером отдела продаж составляется отчет по поступившим/выполненным заявкам на каждое наименование товара.

На рисунках 12-15 представлены основные модели данного бизнес-процесса магазина электроники.

Рисунок 12 – Диаграмма действий бизнес-процесса «Продажа электроники»

Рисунок 13 – Контекстная диаграмма модели бизнес-процесса «Продажа электроники».

Рисунок 14 – Диаграмма декомпозиции первого уровня детализации контекстной диаграммы

Рисунок 15 – Диаграмма декомпозиции второго уровня детализации

2.2 Проектирование информационной системы с использованием языка UML

Произведем моделирование информационной системы по онлайн-продаже электроники через сеть Интернет.

На рисунке 16 представлена диаграмма вариантов использования.

Рисунок 16 – Диаграмма вариантов использования

Сценарии выполнения основных прецедентов представлены в таблицах 5-10.

Таблица 5 – Сценарий выполнения прецедента «Учет заказов»

Прецедент	Учет заказов
Актеры	Покупатель Информационная система
Цель	Регистрация заказа Доставка заказа покупателю
Краткое описание	Посетитель сайта (покупатель) Регистрируется или авторизуется в системе Выбирает товар в каталоге Оформляет и оплачивает заказ Информационная система Регистрирует поступивший заказ Формирует счет-фактуру заказа Отправляет счет-фактуру в магазин для продажи товара покупателю
Тип	Базовый
Ссылки	«Оформление заказа», «передача заказа в магазин»

Таблица 6 – Типичный ход события «Учет заказа клиента»

Действия актеров	Отклик
Покупатель выбирает товар в каталоге	Информационная система регистрирует артикул/код товара и добавляет его в «корзину» покупателя
Покупатель оформляет заказ	Информационная система регистрирует дату заказа, состав заказа, стоимость, возможные скидки, данные покупателя и информацию о доставке. Информационная система передает сообщение магазину о поступившей заявке.
Покупатель имеет право на скидку (постоянный покупатель, промо-код, подарочный сертификат и т.п.)	Информационная система проверяет Имеет ли скидку авторизованный покупатель Актуален или введенный промо-код Активен ли подарочный сертификат
Покупатель оплачивает товар	Информационная система проверяет правильность платежа, уведомляет покупателя о формировании заказа.
Информационная система оформляет счет-фактуру заказа и отправляет ее в магазин	Информационная система помечает заявку как оплаченную, формирует необходимые документы. Отправляет информацию на склад для формирования заказа и его доставки клиенту.

Таблица 7 – Сценарий выполнения прецедента «Оформление заказа»

Прецедент	Оформление заказа
Актеры	Покупатель
Цель	Формирование заказа покупателем и его оплата
Краткое описание	Покупатель в интернет-каталоге выбирает товар, формирует заказ, получает скидку, оплачивает заказ.
Тип	Включающий
Ссылки	«регистрация покупателя», «формирование заказа», «оплата товара», «скидка»

Таблица 8 – Типичный ход события «Оформление заказа»

Действия актеров	Отклик
Покупатель выбирает в каталоге товар, помещает его в «корзину»	Информационная система формирует предварительный заказ на основе «корзины» с указанием кода товара и его количества
Покупатель оформляет «корзину» как заказ	Информационная система регистрирует заказ, данные покупателя. Отправляет информацию о заказе магазину.
Покупатель вводит промо-код или подарочный сертификат. Авторизуется как постоянный клиент	Информационная система проверяет правильность введенных данных покупателем и предоставляет скидку.
Покупатель оплачивает товар	Информационная система проверяет правильность платежа и отправляет покупателю уведомление о оформлении заказа.

Таблица 9 – Сценарий выполнения прецедента «Передача заказа в магазин»

Прецедент	Передача информации о заказе покупателя в магазин
Актеры	Информационная система
Цель	Контроль статуса оплаты заказа покупателем. Отправка заказа покупателю.
Краткое описание	При успешном подтверждении статуса оплаты заказа покупателем информационная система формирует счет-фактуру и направляет информацию в магазин
Тип	Включающий
Ссылки	-

Таблица 10 – Типичный ход события «Передача заказа в магазин»

Действия актеров	Отклик
Информационная система формирует счет-фактуру и направляет информацию в магазин	Информационная система формирует все необходимые документы и отправляет информацию в магазин для отправки заказа покупателю

классов представлена 17.

Рисунок 17 – классов

представлена на 18.

18 – Диаграмма

Диаграмма на рисунке 19.

19 – кооперации

состояний рисунке 20.

Рисунок 20 –

Диаграмма представлена 21.

Рисунок 21 – Диаграмма

развертывания на 22.

22 – Диаграмма развертывания

Заключение

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

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

К преимуществам можно отнести:

Относительна простота переноса предметов и операций реального мира в описание модели и ее поведение в составе информационной системы.

Масштабируемость информационной системы. Применение классов и объектов позволяет относительно легко «дорабатывать» ИС, добавляя новый функционал.

Используя современные методы автоматизированного проектирования можно контролировать каждый этап разработки.

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

Недостатки (частично следуют из преимуществ):

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

Преимущество от применения ООП заметно только на этапе масштабирования информационной системы или при повторном использовании уже существующих компонент.

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

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

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

Библиография

Баркер, Р. CASE-Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 233 с.
Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 582 с.
Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений / Г. Буч. – М. : Бином, 2014. – 560 с.
Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.
Вайсфельд М. Объектно-ориентированное мышление. — СПб.: Питер, 2014. — 304 с.: ил. — (Серия «Библиотека программиста»).ISBN 978-5-496-00793-1
Вичугова, А. А. Методы и средства концептуального проектирования информационных систем: сравнительный анализ структурного и объектно-ориентированного подходов, М. : Издательство "Университет", 2014 — 10 с. — Прикладная информатика №1 (49) 2014
ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения http://docs.cntd.ru/document/1200006979
ГОСТ Р 43.0.10-2017 Информационное обеспечение техники и операторской деятельности. Информационные объекты, объектно-ориентированное проектирование в создании технической информации http://docs.cntd.ru/document/1200157252
Заботина Н. Н., Проектирование информационных систем: Учеб. пособие. — М.: ИНФРА-М, 2020. — 331 с
Зыков, С. В. Программирование. Объектно-ориентированный подход : учебник и практикум для академического бакалавриата / С. В. Зыков. — М. : Издательство Юрайт, 2017 — 155 с. — Серия : Бакалавр. Академический курс.
Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
Спецификация UML https://www.uml.org/
Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.
Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.

Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 54 с. ↑
Заботина Н. Н., Проектирование информационных систем: Учеб. пособие. — М.: ИНФРА-М, 2020. — 9 с ↑
ГОСТ Р 43.0.10-2017 Информационное обеспечение техники и операторской деятельности. Информационные объекты, объектно-ориентированное проектирование в создании технической информации http://docs.cntd.ru/document/1200157252 ↑
ГОСТ Р 43.0.10-2017 Информационное обеспечение техники и операторской деятельности. Информационные объекты, объектно-ориентированное проектирование в создании технической информации http://docs.cntd.ru/document/1200157252 ↑
ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения http://docs.cntd.ru/document/1200006979 ↑
Заботина Н. Н., Проектирование информационных систем: Учеб. пособие. — М.: ИНФРА-М, 2020. — 48 с ↑
Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002, 108 с. ↑
Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 80 с. ↑
Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с. ↑
ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения http://docs.cntd.ru/document/1200006979 ↑
Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с. ↑
Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 25 с. ↑
Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002,82 с. ↑
Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2015. - 18 с. ↑
Баркер, Р. CASE-Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2014. – 124 с. ↑
ГОСТ 34.003-90 Информационная технология (ИТ). Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения http://docs.cntd.ru/document/1200006979 ↑
Спецификация UML https://www.uml.org/ ↑