Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы (Структура и основные понятия объектно-ориентированного)

Содержание:

Введение

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

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

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

Цель данной работы является обзор и анализ основных принципов и особенностей объектно-ориентированного подхода, а так же его реализаций.

Задачи работы:

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

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

1. Анализ средств проектирования экономических информационных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждый виток расширяющейся спирали символизирует итеративное увеличение функциональности системы при одинаковом наборе технологических процессов и фаз (рисунок 5) [1, 5, 6]. Внутри каждой из фаз разработка также производится по спиральной модели. Перед стартом каждого этапа определяется количество итераций, с заданным приращением степени достижения поставленной задачи. Внутри каждой итерации реализуются все процессы: от формирования требований до внедрения [18, 19].

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

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

Технологический процесс можно представить в виде диаграммы. На рисунке изображена обобщенная схема «Управления проектом» [19].

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

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

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

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

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

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

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

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

Множество получаемых в унифицированном процессе артефактов может отображаться в виде диаграммы, также как и технологический процесс. На рисунке 9 представлен пример диаграммы артефактов «Управления проектом» [19].

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

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

• IBM Rational Rose – визуальное моделирование и генерация объектного кода;
• IBM Rational RequisitePro – управление требованиями;
• IBM Rational ClearCase – конфигурационное управление;
• IBM Rational RapidDeveloper – разработка;
• IBM Rational ClearQuest – управление изменениями;
• IBM Rational TeamTest – автоматизированное тестирование.
• IBM Rational SoDA – автоматизированное документирование;

IBM Rational Rose является главным продуктом автоматизации проектирования информационных систем является. Это классическая Case-система, основными возможностями которой являются:

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

IBM Rational Rose позиционируется как универсальное средство, пригодное для аналитиков, разработчиков и проектировщиков.

1.3. Структура и основные понятия объектно-ориентированного проектирования экономических информационных систем

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

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

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

Семантика – раздел лингвистики, изучающий значение языковых единиц: слов и словосочетаний [22].

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

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

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

В UML представлено 3 типа сущностей:

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

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

Таблица 2 - Отношения

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

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

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

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

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

Таблица 3 - Механизмы расширения

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

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

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

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

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

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

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

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

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

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

2. Проектирование экономической информационной системы на примере

2.1. Обзор объекта

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

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

1. Менеджер отдела продаж каждый день оформляет заявки клиентов на покупку косметики согласно прайс-листу. Он регистрирует заявки в журнале заявок.

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

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

4. Менеджер отдела продаж контролирует поступление платежей от клиентов. Если срок оплаты истёк, а платежи не поступили, то менеджер отмечает недействительность заявки в журнале заявок.

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

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

7. В конце каждого месяца на основании журнала заявок менеджером отдела продаж формируется сводка о количестве поступивших заявок на каждое наименование косметики. На рисунках 12-15 представлены основные модели данного бизнес-процесса.

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

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

Рисунок 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 – Диаграмма развертывания

Заключение

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

Объектно-ориентированный подход с точки зрения проектирования ЭИС обладает как преимуществами, так и недостатками по сравнению с другими концепциями, в частности:

Преимущества:

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

Недостатки:

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

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

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

• Объектная ориентированность, которая определяет семантическую близость методов описания результатов анализа и проектирования к методам программирования на современных объектно-ориентированных языках.
• Возможность описать систему различных точек зрения, учитывая разные аспекты ее поведения;
• Простота диаграммы и синтаксиса UML, что облегчает его изучение;
• Возможность расширения путем ввода собственных текстовых и графических стереотипов, что значительно расширяет области его применения;
• Широкая распространенность и динамичное развитие.

К недостаткам можно отнести следующие особенности UML:

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

Список использованной литературы

1. ГОСТ 34.003-90. Автоматизированные системы. Термины и определения.
2. ГОСТ 34.601-90. Автоматизированные системы. Стадии создания.
3. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
4. ГОСТ Р ИСО/МЭК 15271–02. Руководство по ИСО/МЭК 12207 (процессы жизненного цикла программных средств).
5. ОРММ ИСЖТ 2.01–00. Требования к составу, содержанию и оформлению документов при создании ИС. – М. : ВНИИАС МПС России, 2000. – 62 с.
6. ОРММ ИСЖТ 5.03–00. Процессы жизненного цикла ИС и программных средств – М. : ВНИИАС МПС России, 2000. – 48 с.
7. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 2016. – 233 с.
8. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2017. - 582 с.
9. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М. : Бином, 2014. – 560 с.
10. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2017. - 432 с.
11. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2018. – 176 с.
12. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2016. - 240 с.
13. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2014. - 496 с.
14. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2014. – 576с.
15. Орлов, С.А. Технологии разработки программного обеспечения : учеб. / С.А. Орлов. – СПб. : Питер, 2014. – 464 с.
16. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2018. – 688 с.
17. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 2015. - 672 с.
18. Элиенс, А. Принципы объектно-ориентированной разработки прог рамм / А. Элиенс. – М.: Издательский дом «Вильямс», 2014. – 496 с.
19. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2014. - 496 с.
20. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose. – www.intuit.ru
21. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML – www.intuit.ru
22. UML спецификация. – www.omg.com