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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Цель работы – краткий обзор возможностей объектно-ориентированного подхода и выявление наиболее эффективных инструментов для его применения на практике.

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

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

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

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

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

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

1. Теоретические основы объектно-ориентированного подхода

1.1 Основные понятия и суть подхода в проектировании ИС

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

То есть, в отличие от структурного подхода, где система представляется в виде иерархии (дерева) взаимосвязанных функций, то есть, выполняется её функциональная (процедурная, алгоритмическая) декомпозиция системы, в объектно-ориентированном подходе за основу принимается её объектная декомпозиция [1].

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

Третье существенное отличие двух подходов заключается в структурной организации внутри модулей системы. В структурном подходе модуль состоит из функций, иерархически связанных между собой отношением композиции (англ. «Part of» – часть-целое), т. е. функция состоит из подфункций, подфункция из под-подфункций и т. д [2]. В объектно-ориентированном подходе иерархия выстраивается с использованием двух отношений: композиции и наследования. При этом в объектно-ориентированном подходе «объект-часть» может включаться сразу в несколько «объектов-целое». Таким образом, модуль в структурном подходе представляется в виде дерева, а в объектно-ориентированном подходе – в виде ориентированного графа, т. е. с помощью более общей структуры [3].

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

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

Абстракция (лат. «abstractio» – отвлечение) – форма познания, основанная на мысленном выделении существенных свойств и связей предмета и отвлечении от других, частных его свойств и связей [6]. При этом «существенное» и «частное» должны рассматриваться с точки зрения решаемой задачи (предметной области). В объектно-ориентированном подходе абстракция – это модель сущности, описывающая ее свойства и поведение.

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

Индивидуальность – это свойство сущности, с помощью которого ее можно отличить от других. То есть, говоря об объекте «поезд», имеется в виду не обобщенное понятие поезд, как нечто состоящее из локомотивов и вагонов, а конкретный грузовой поезд с номером 1025, весом 4600 т, ведомый электровозом переменного тока ВЛ80Т с серийным номером 027, состоящий из четырехосных полувагонов с конкретными номерами и т. д. В то же время степень абстракции с точки зрения решаемой задачи может быть и более высокой. Например, при выполнении тяговых расчетов к графику движения поездов не требуется информация о серийных номерах локомотивов и вагонов, т. е. нет потребности в отличии друг от друга электровозов ВЛ80Т с серийными номерами 027 и 028.

Класс – это множество однотипных объектов, имеющих общую структуру и поведение, которые концептуально группируются в объектно-ориентированном подходе. Другими словами, класс – это шаблон, на основе которого генерируются (создаются) однотипные объекты. В качестве синонима понятия «объект» часто употребляют понятие «экземпляр класса» [4][5].

Каждый класс и соответственно объект характеризуются строго определенным набором атрибутов и методов. Текущие значения атрибутов четко определяют текущее состояние объекта. Набор методов и их алгоритмическая реализация определяют поведение объекта (класса объектов).

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «круг» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет фона и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус).

Инкапсуляция (информационная закрытость) – принцип, в соответствии с которым содержание внутреннего устройства элементов системы должно быть скрыто друг от друга. Этот принцип предписывает обмен информацией между объектами системы только в минимально необходимом объеме, ограничение доступа к атрибутам и методам объектов (классов) со стороны других объектов (классов) и полное скрытие алгоритмической реализации методов от других объектов (классов) [7].

Полиморфизм – принцип построения элементов модели так, чтобы они могли принимать различные внешние формы или функциональность (поведение) в зависимости от обстоятельств. Например, методы draw() (нарисовать) или calculateS() (рассчитать площадь) для классов «круг» и «ромб», определенных путем наследования атрибутов и методов родительского класса «фигура», алгоритмически должны быть реализованы по-разному.

Унифицированный процесс (Unified Process, UP) – это процесс разработки информационной системы, который обеспечивает упорядоченный подход к распределению задач и обязанностей в организации-разработчике. Унифицированный процесс охватывает весь жизненный цикл ПО, начиная с определения требований и заканчивая сопровождением, и представляет собой обобщенный каркас (шаблон, скелет), который может быть применен (специализирован) для разработки и сопровождения широкого круга систем. [8][9]

Унифицированный язык моделирования (Unified Model Language, UML) – язык (система обозначений) для определения, визуализации и конструирования моделей системы в виде диаграмм и документов на основе объектно-ориентированного подхода. UML является неотъемлемой частью Унифицированного процесса, хотя Унифицированный процесс и UML разрабатывались совместно.

Для разработки ИС на основе унифицированного языка моделирования (UML) требуется три основных компонента:

1. редактор исходного кода;
2. редактор UML для атрибутов и методов;
3. визуализация структуры UML.

Шаблон – это именованная пара «проблема/решение», содержащая готовое обобщенное решение типичной проблемы. Как правило, шаблон помимо текстового описания содержит также одну или несколько диаграмм UML (например, диаграммы классов, последовательности и/или коммуникации), графически иллюстрирующих состав и структуру классов, а также особенности их взаимодействия при решении поставленной проблемы. Шаблоны разрабатываются опытными профессионалами и являются проверенными, эффективными (порой оптимальными) решениями. Применение шаблонов на стадиях анализа и проектирования может резко сократить затраты и повысить качество разработки ПО [10].

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

Структура Унифицированного языка моделирования

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

Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний;

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

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

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

Сущности — это определенные в UML три типа понятий [12]:

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

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

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

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

Диаграмма — это группировка элементов нотации для отображения некоторого аспекта разрабатываемой информационной системы, как правило, связный граф, в котором сущности являются вершинами, а отношения – дугами [1]. Диаграмма прецедентов отображает функции системы, взаимодействие между актерами и функциями, диаграмма классов — набор классов, интерфейсов и отношений между ними, диаграмма пакетов — набор пакетов и отношений между ними. Диаграмма поведения представлена диаграммой автоматов (отображает состояния сущности и переходы между ними в процессе ее жизненного цикла), диаграммой деятельности (отображает бизнес-процессы в системе и алгоритмы поведения), и диаграммой взаимодействия, которая в свою очередь представлена диаграммой последовательности (отображает последовательность передачи сообщений между объектами и актерами) и диаграммой коммуникации (аналогична диаграмме последовательности, но основной акцент делается на структуру взаимодействия между объектами). Также есть диаграмма реализации, которая также представлена диаграммой компонентов (отображает компоненты системы и связи между ними) и диаграммой развёртывания (отображает размещение компонентов по узлам сети, а также ее конфигурацию) [1].

Все виды отношений UML, используемых на диаграммах для указания связей между сущностями, описываются через ассоциацию (наиболее общий вид отношения, описывающего значимую связь между двумя и более сущностями), агрегацию (подвид ассоциации, описывающей связь «часть–целое» между сущностями одного типа, в котором «часть» может существовать отдельно от «целого»), композицию (подвид агрегации, в которой «части» не могут существовать отдельно от «целого»), зависимость (отношение между двумя сущностями, в котором изменение в независимой сущности может влиять на состояние или поведение другой, зависимой, сущности), обобщение (отношение между обобщенной, родительской, сущностью, и специализированной сущностью — потомком, относящейся к тому же типу) и реализацию (отношение между интерфейсами и классами/компонентами, или между классами и кооперациями, где одна сущность определяет действие, которое другая сущность обязуется выполнить) [14].

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

Механизм расширения — это строка текста, заключенная в скобки или кавычки, применяемая для уточнения семантики сущностей и отношений. К таким относятся стереотип (обозначение, уточняющее семантику элемента нотации), сторожевое условие (логическое условие), ограничение (правило, ограничивающее семантику элемента модели) и помеченное значение (новое или уточняющее свойство элемента нотации) [9].

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

Структура Унифицированного процесса

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

1. технологических процессов (когда) – последовательности видов деятельности (работ), дающих ощутимый результат. Технологический процесс, как правило, представляется в виде диаграммы, отображающей состав работ и их последовательность на той или иной стадии разработки ПО;
2. видов деятельности (как) – работ, осуществляемых исполнителями;
3. исполнителей (кто) – заинтересованных в реализации проекта отдельных лиц или групп. Исполнитель характеризуется строго определенным поведением и обязанностями (ролью). Поведение выражается через виды деятельности, осуществляемые исполнителем, а обязанности – через результаты, получаемые в процессе выполнения работ. В процессе реализации проекта один и тот же человек может выступать в разных ролях;
4. артефактов (что) – информации, создаваемой, изменяемой или используемой исполнителями в проекте. Другими словами, артефакт – это не только то, что создается в результате деятельности (технические артефакты – модели системы, исходные коды программ, готовый программный продукт, документация к нему и т. д.), но и то, что направляет эту деятельность (артефакты управления – календарный план, техническое задание, инструкции и т. д.);
5. используемых утилит (с помощью чего) – программных продуктов, рекомендуемых при выполнении работ.

Технологические процессы

Унифицированный процесс придерживается спиральной модели (стратегии) жизненного цикла ПО.

Каждый виток характеризуется приращением (инкрементом) функциональности системы и одинаковым набором технологических процессов и стадий (в Унифицированном процессе – фаз). В рамках одной стадии также используется идея спиральной разработки. Перед началом выполнения каждой стадии планируется количество итераций, каждая из которых характеризуется некоторым приращением результатов. В рамках одной итерации выполняются основные процессы, начиная от формирования требований и заканчивая внедрением [8][9][12].

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

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

Уточнение (англ. «elaboration»). Целью фазы является разработка архитектуры и моделей проектируемой системы, основным результатом – технический проект.

Конструирование (англ. «construction»). Целью фазы является разработка действующей версии системы, основным результатом – версия системы.

Переход (англ. «transition»). Целью фазы является внедрение версии у заказчика, т. е. переход на новую технологию выполнения работ в организации. С точки зрения разработчиков основной результат данной фазы – удовлетворение потребностей заказчика и акты приемки-сдачи, а заказчика – обученный персонал, документация к информационной системе и, естественно, сама работающая система.

Организация работ по содержанию разбита на две группы технологических процессов: основные и вспомогательные [8][9][12].

Артефакты

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

Модель прецедентов — наименее формальная, но управляющая всем процессом разработки модель, ещё на этапе формирования требований отображающая существенные функциональные требования к системе (реализация которых принесет пользователям ощутимый и значимый результат) в форме, удобной для всех заинтересованных лиц

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

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

Модель реализации — применяемая на этапе реализации модель, которая содержит описание исполняемой системы (компонентов и схемы развертывания системы).

Модель тестирования — применяемая на этапе тестирования модель, предназначенная для проверки соответствия полученного ПО требованиям.

Модели описывают проектируемую систему с различных точек зрения и на разном уровне абстракции. При этом некоторые элементы (например, диаграммы или классы) могут одновременно входить в разные модели. Более того, один и тот же элемент может входить в две и более моделей с разной степенью детализации. Также модели могут быть вложены друг в друга. В Унифицированном процессе набор получаемых артефактов, как и технологический процесс, также может отображаться в виде диаграммы. [8][12]

1.2. Понятия, относящиеся к утилитам UML-моделирования

Качественное и своевременное выполнение проекта невозможно без применения средств автоматизации деятельности – утилит. К утилитам относятся различные инструментальные средства, поддерживающие жизненный цикл ПО [9].

Проприетарное программное обеспечение, несвободное программное обеспечение (англ. proprietary software; от proprietary — частное, патентованное, в составе собственности и software — программное обеспечение) — программное обеспечение, являющееся частной собственностью авторов или правообладателей и не удовлетворяющее критериям свободного ПО (наличия открытого программного кода недостаточно). Правообладатель проприетарного ПО сохраняет за собой монополию на его использование, копирование и модификацию, полностью или в существенных моментах. Обычно проприетарным называют любое несвободное ПО, включая полусвободное [15].

IDE (англ. «Integrated development environment»; интегрированная среда разработки [16]) — комплекс программных средств, используемый для разработки информационных систем. Многие современные среды разработки также включают браузер классов, инспектор объектов и диаграмму иерархии классов — для использования при объектно-ориентированном подходе к разработке.

CASE-технология (англ. «computer-aided software engineering») — это методология проектирования информационных систем, набор методов, нотаций и инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать модель системы на всех этапах разработки и сопровождения системы и разрабатывать приложения в соответствии с информационными потребностями пользователей [17].

CASE-средства — это набор инструментов по реализации CASE-технологии. Первоначально под CASE-средствами понимались только инструменты для упрощения наиболее трудоёмких процессов анализа и проектирования, но с приходом стандарта ISO/IEC 14102 CASE-средства стали определять, как программные средства для поддержки процессов жизненного цикла ИС.

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

Ниже перечислены функции CASE.

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

Вся документация по проекту генерируется автоматически на базе репозитория (как правило, в соответствии с требованиями действующих стандартов). Несомненное достоинство CASE-технологии заключается в том, что документация всегда отвечает текущему состоянию дел, поскольку любые изменения в проекте автоматически отражаются в репозитории [17].

Автопроверка — автоматическое обеспечение качества и тестирование моделей на наличие ошибок, полноту и непротиворечивость;

Прямое проектирование — это возможность генерации кода по спецификациям (диаграммам) UML на конкретном языке программирования. При этом порядок использования разработчиками CASE-средства следующий [18][19]:

1. создается логическая модель системы;
2. выбирается конкретный язык программирования (или СУБД) для построения физической модели, после чего CASE-средство автоматически создает физическую модель системы;
3. дорабатывается физическая модель;
4. выполняется автоматическая генерация текста программы или структуры базы данных на диске

Обратное проектирование — это создание UML-диаграмм перевод с языка программирования на язык. В этом случае порядок использования CASE-средства обратный – от текста программы или базы данных на диске к логической модели.

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

1. требуется осуществить поиск ошибок, чтобы убедиться в адекватности дизайна;
2. применение подхода RST (Reverse Semantic Traceability, обратная семантическая трассировка), когда осуществив после первого перевода с UML на язык программирования обратный перевод, и сравнив исходные и восстановленные UML-модели, можно убедиться в том, что дизайн системы соответствует модели, ошибок не обнаруживается и никакая информация не была утрачена в результате перевода;
3. если уходят «старые» разработчики или просто отсутствует документация и стоит задача модификации существующей системы, код которой плохо документирован, и требуется понять назначение системы и ее частей, функционал, предоставляемый ею, и т. д.;
4. появляются новые, более перспективные языки программирования и СУБД;

Реинжиниринг — это анализ существующего кода и его модификация после проведения обратного проектирования.

RTE (англ. «round-trip engineering», круговая/двусторонняя разработка) — это возможность CASE-средств синхронизировать два или более связанных с ними программных артефактов, таких как, исходный код, модели, файлы конфигурации и даже документации [20] [21]. Потребность в использовании RTE возникает, когда одна и та же информация присутствует в нескольких артефактах, из-за чего может возникнуть несогласованность, если не все артефакты постоянно обновляются, чтобы отразить данное изменение. Например, некоторая часть информации была добавлена/изменена только в одном артефакте, и в результате она утратилась/стала несовместимой с другими артефактами [22].

RTE часто ошибочно определяется как простая поддержка как прямого, так и обратного проектирования.

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

Еще одна характеристика RTE — это автоматическое обновление артефактов в ответ на автоматически обнаруженные несоответствия [20]. В этом смысле это отличается от прямого и обратного проектирования, имея возможность обновления как вручную (традиционно), так и автоматически (посредством автоматической генерации или анализа артефактов). Автоматическое обновление может быть по требованию или мгновенным (все связанные артефакты немедленно обновляются после каждого изменения, внесенного в один из них). В RTE по требованию авторы артефактов могут одновременно развивать артефакты (даже в распределенной настройке) и в какой-то момент выбрать выполнить сопоставление для выявления несоответствий и выбрать распространение некоторых из них и согласование потенциальных конфликтов [22].

RTE поддерживает итеративный процесс разработки. После того, как происходит синхронизация имеющейся модели с пересмотренным кодом, по-прежнему сохраняется возможность выбрать предпочитаемый способ действий (внести дополнительные изменения в код или внести изменения в свою модель). Синхронизация возможна в любом направлении в любое время, с повторением подобного цикла необходимое количество раз. [21]

Синхронизация между моделями UML и соответствующим исходным кодом — это наиболее распространенная форма применения RTE. Многие проприетарные CASE-средства поддерживают эту форму RTE (детальный анализ приведён далее во 2-ой главе настоящей работы). Обычно диаграммы классов UML поддерживаются CASE-средствами с RTE в некоторой степени; однако некоторые концепции UML, такие как ассоциации и сдерживание, не имеют прямых представлений во многих языках программирования, что ограничивает удобство использования созданного кода и точность анализа кода (например, сдерживание трудно распознать в коде) [22].

Общая проблема в утилитах с поддержкой RTE заключается в том, что модель, полученная в результате обратного проектирования, не совпадает с исходной, если только утилитам не помогают трудоемкие аннотации. Поведенческие части UML налагают еще больше проблем для RTE [21].

Более гибкая форма RTE реализуется в контексте интерфейсов прикладного программирования (API), в соответствии с которыми модель, описывающая использование API-интерфейса инфраструктуры, синхронизируется с кодом этого приложения [20].

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

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

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

OMG (сокр. от англ. «Object Management Group») — некоммерческое объединение, занимающееся разработкой и продвижением объектно-ориентированных технологий и стандартов для создания платформо-независимых приложений на уровне предприятия [23].

MDE (англ. «model-driven engineering» - разработка, управляемая моделями) — это стиль разработки программного обеспечения, когда модели становятся основными артефактами разработки, из которых генерируется код и другие артефакты [24].

Метамодель — это модель, описывающая другую модель и транзитивное отношение между двумя моделями. Метамодель описывает понятия, используемые в модели, и фиксирует информацию в виде метаданных, которые могут быть обработаны инструментами. Модель всегда ссылается на единственную метамодель. Типичные метамодели, рекомендуемые OMG это: UML, SysML, SPEM или CWM.

MDA (англ. «Model Driven Architecture», Архитектура, управляемая моделью) — создаваемая консорциумом OMG разновидность концепции «Разработка, управляемая моделями»: модельно-ориентированного подхода к разработке программного обеспечения. Является наиболее известной MDE-инициативой, суть которого состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов её трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.). Название концепции не совсем удачно, так как она определяет вовсе не архитектуру а именно метод разработки программного обеспечения [25].

MOF (англ. «Meta-Object Facility», мета-объектное средство) — это стандарт OMG для MDE, возникший из UML в качестве архитектуры метамоделирования для определения самого UML. MOF призван служить мостом между разными метамоделями, поскольку представляет собой мощную основу для их описания. Являясь частью концепции MDA [25], технология моделирования MOF определяет создание метамодели.

CORBA (англ. «Common Object Request Broker Architecture», типовая архитектура опосредованных запросов к объектам) — технологический стандарт написания распределённых приложений, продвигаемый консорциумом (рабочей группой) OMG и соответствующая ему информационная технология [26].

XMI (англ. «XML Metadata Interchange») — стандарт OMG для обмена метаданными с помощью языка XML. Наиболее часто XMI применяется как формат обмена UML-моделями, поскольку это позволяет импортировать UML-модель из одного инструмента UML-моделирования в другой — из-за различий в определении синтаксиса и семантики элементов языка [27].

Выводы.

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

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

2. Особенности подхода и CASE-средства для проектирования

2.1. CASE-средства реализации объектно-ориентированного подхода

ArgoUML - средство UML моделирования с открытым исходным кодом.

ArgoUML полностью написан на Java и для работы ему подходит любая операционная система с установленной Java 2 JRE или JDK версии 1.4 или выше. Поддерживает девять видов диаграмм UML (диаграммы классов, состояний, кооперации, последовательности, деятельности, прецедентов, объектов, компонентов, развёртывания) [28][29].

• Лицензия: EPL;
• Языки генерации кода: C ++, C #, Java, PHP, Ruby;
• Обратное проектирование: Java (другие языки с плагинами);
• Платформы: кросс-платформенное (Java);
• Другие особенности: поддержка MDA, спецификации UML 1.4, а также XMI 1.2; поддержка OCL для классов, автоматическая верификация модели UML (design critics); расширенное редактирование диаграммы и масштабирование; доступно на 10 языках.

Astah — созданный японской компанией Change Vision инструмент UML моделирования, ранее известный как JUDE (Java and UML Developers' Environment). Делится на версии «Community» и «Professional». Поддерживает девять видов диаграмм (диаграмма классов, прецедентов, последовательности, кооперации, состояния, деятельности, развёртывания, компонентов, «сущность-связь») [30].

• Лицензия: freeware/trialware;
• Языки генерации кода: Java, C++, C #, Python, Ruby и любые другие языки с плагинами;
• Обратное проектирование: Java, C++, C #, PHP;
• Платформы: Windows, Mac OS X;
• Другие особенности: поддержка спецификаций UML 1.4 (UML 2.0 в коммерческой версии) и XMI; интеллект-карты, функция ввода-вывода модели в/из XML, шаблоны прецедентов; предоставление API и плагинов; экспорт в RTF и HTML [30].

Borland Together — является инструментом проектирования UML для проектирования информационных систем и генерации кода [31].

• Лицензия: GPL2;
• Языки генерации кода: Java 6, C ++, CORBA;
• Обратное проектирование: только СУБД (Oracle, DB2, MSSQLServer);
• Платформы: кросс-платформенное (Java);
• Другие особенности: поддержка MDA и спецификаций UML 2; поддержка шаблонов проектирования и анализа кода, которые могут снизить риск возникновения общих и предотвращаемых ошибок на протяжении всего процесса разработки; интегрируется с Eclipse и MS VS.NET 2005; аудиты и показатели предоставляются как на уровне модели, так и на уровне кода, определяемом на языке ограничения объектов (OCL).

BOUML — дизайнер диаграмм UML, написанный на C++ и Qt Бруно Пажесом (Bruno Pagès) [32][33].

• Лицензия: GPL;
• Языки генерации кода: C ++, Java, PHP, IDL, Python, MySQL;
• Обратное проектирование: C ++, Java, PHP, MySQL;
• Платформы: Unix / Linux / Solaris, Mac OS X (Power PC и Intel) и Windows;
• Другие особенности: поддержка MDA и спецификаций UML 2, XMI$ поддержка шаблонов генерации кода.

Eclipse UML2 Tools — это набор редакторов на основе GMF для просмотра и редактирования моделей UML; он ориентирован на (возможную) автоматическую генерацию редакторов для всех десяти типов диаграмм UML2 [34].

• Лицензия: EPL;
• Языки генерации кода: Java (в рамках Eclipse);
• Обратное проектирование: Java (в рамках Eclipse);
• Платформы: кросс-платформенный (Java);
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI; поддержка шаблонов генерации кода.

IBM Rational Rose XDE (англ. «eXtended Development Environment») — это объектно-ориентированный инструмент проектирования, который поддерживает визуальное моделирование (UML) [35][36].

• Лицензия: IBM EULA;
• Языки генерации кода: C++, C, Java, Ada, C#, Corba, и др. (настраиваемый для других языков);
• Обратное проектирование: C++, C, Java, Ada, C#, и др. (настраиваемый для других языков);
• Платформы: Windows, Linux и Unix-подобные;
• Другие особенности: несмотря на свою известность, не поддерживает UML 2 (только версии 1.x), не поддерживает пользовательские шаблоны; на данный момент относится к категории устаревшего ПО, но поддерживает интеграцию с VS .NET и другими средами разработки и языками.

IBM Rational Software Architect (RSA) - сделанная подразделением корпорации IBM, компанией Rational Software, среда разработки и моделирования, которая использует UML для проектирования архитектуры приложений и веб-сервисов. Продукт сделан с помощью фреймворка открытого программного обеспечения, в среде разработки Eclipse, и включает в себя возможности, сфокусированные на архитектурном анализе кода, C++ и MDD (model-driven development) с UML для создания устойчивых приложений и веб-служб.

• Лицензия: проприетарное ПО;
• Языки генерации кода: C++, C, Java, Ada, C#, Corba [37];
• Обратное проектирование: Java, C ++, .NET;
• Платформы: Linux; Windows; FreeBSD, JVM, Solaris; OS X;
• Другие особенности: поддержка MDA, спецификации UML 2 и XMI; есть отладчик, поддержка разработки GUI, профилирование, есть покрытие кода, автодополнение, браузер классов, рефакторинг, архитектурный анализ кода; интеграция со средой Eclipse.

IBM Rational Software Modeler (RSM) — интегрированная среда разработки для объектно-ориентированного проектирования ИС от IBM, основанный на программной среде с открытым исходным кодом Eclipse, и использующийся для визуального моделирования и разработки на основе моделей (MDD) для создания приложений и веб-сервисов [38].

• Лицензия: IBM EULA
• Языки генерации кода: Java, C#, C ++, EJB, WSDL, XSD, IDL, SQL;
• Обратное проектирование: C++, C, Java, Ada, C#;
• Платформы: Linux, Windows;
• Другие особенности: поддержка спецификации UML 2; интеграция со средой Eclipse; поддержка моделирования сущностей (ER) и настройки шаблонов проектирования; с 2015 года не поддерживается.

MagicDraw — это визуальный инструмент моделирования UML, SysML, BPMN и UPDM с поддержкой совместной работы [39]. Разработанный для бизнес-аналитиков, аналитиков программного обеспечения и программистов этот динамичный и универсальный инструмент разработки облегчает анализ и проектирование объектно-ориентированных информационных систем и баз данных. Он обеспечивает механизм разработки кода, а также моделирования схемы базы данных, создания DDL.

• Лицензия: LGPL;
• Языки генерации кода: J2EE, C #, C ++, CORBA IDL, .NET, XML Schema, WSDL;
• Обратное проектирование: J2EE, C #, C ++, CORBA IDL, .NET, XML Schema, WSDL;
• Платформы: Windows XP SP3 и более поздние версии, OS X Lion и более поздние версии, Linux;
• Другие особенности: поддержка MDA, спецификации UML 2 и XMI; поддержка шаблонов генерации кода; генератор отчетов из шаблона в RTF, HTML, XML, ODT, ODS, ODP и текст (DOCX, XLSX, PPTX с 16.8).

Modelio – это инструмент UML с открытым исходным кодом, разработанный Modeliosoft. Он поддерживает стандарты UML2 и BPMN. Modelio поддерживает UML2-профили для XSD , WSDL и BPEL, SoaML для моделирования сервисов в распределенных средах. Доступен на английском, немецком и французском языках [40][41][42].

• Лицензия: GPL/Apache License 2.0.;
• Языки генерации кода: Java, C++, C #, XSD, WSDL, SQL;
• Обратное проектирование: Java, C++, C#;
• Платформы: Windows, Linux, macOS;
• Другие особенности: поддержка MDA, спецификаций UML2, XMI. Генерация документации в HTML.Extensions, создание документации в формате Open XML, поддержка TOGAF, SysML, SoaML, Hibernate, OMG MARTE. Поддержка шаблонов проектирования и совместной работы над фрагментами моделей.

NClass – бесплатный и открытый программный инструмент для создания диаграмм классов UML для приложений на C# и Java. Он написан только на C# и нуждается в .NET Framework 4.0 или последней версии Mono.

• Лицензия: GPL;
• Языки веб-программирования: C#, Java;
• Обратное проектирование: C#, Java;
• Платформы: Linux; Windows;
• Другие особенности: пользовательский интерфейс разработан как простой и удобный, а визуализация диаграмм настраивается через систему стилей; есть возможность реконструировать сборки .NET плагином, написанным Malte Ried; поддержка экспорта во многие форматы изображений, такие как JPEG, PNG или Windows Metafile. Ограничение функционала проявляется в отсутствии большинства диаграм и отсутсвии команды отмены.

ObjectiF — это инструмент CASE для моделирования с использованием моделей UML. Он разработан компанией microTOOL GmbH в Берлине (Германия). Предлагает различные типы диаграм [43][44][45].

• Лицензия: проприетарное ПО;
• Языки генерации кода: Java, C#, Visual Basic, C++;
• Обратное проектирование: Java, C#, Visual Basic;
• Платформы: Windows;
• Другие особенности: поддержка MDA, спецификации XMI; есть интеграция с Eclipse, Visual Studio; поддержка шаблонов проектирования.

Open ModelSphere – это инструмент моделирования данных и UML, написанный на Java и распространяемый как бесплатное программное обеспечение.

• Лицензия: GPL;
• Языки генерации кода: Java, SQL;
• Обратное проектирование: Java;
• Платформы: кросс-платформенное (Java);
• Другие особенности: взаимодействие с Oracle, Informix, Microsoft SQL Server, Sybase, DB2; поддержка шаблонов проектирования, поддержка шаблонов генерации кода.

Papyrus — это графическое средство редактирования для UML2 с открытым исходным кодом на основе среды Eclipse. Он был разработан Лабораторией модельной инженерии для встраиваемых систем (LISE), которая является частью Французской комиссии по альтернативной энергии и атомной энергии (CEA-List). Поддерживает все виды UML2 диаграмм.

• Лицензия: EPL;
• Языки генерации кода: Ada 2005, C / C ++, Java;
• Обратное проектирование: Java (только как компонент Eclipse, начиная с версии Neon);
• Платформы: Windows, Linux, macOS (Java);
• Другие особенности: поддерживает спецификации UML 2 и XMI; предоставляет полную поддержку SysML, чтобы обеспечить разработку систем (на основе моделей), включая реализацию статического профиля SysML и конкретных графических редакторов, необходимых для SysML; может использоваться как автономный инструмент или как плагин Eclipse.

PlantUML — это инструмент с открытым исходным кодом, позволяющий пользователям создавать диаграммы UML с обычного текстового языка. Язык PlantUML является примером специфического для приложения языка. Используя ПО «Graphviz» для выкладки своих диаграмм, он использовался, чтобы позволить работать с UML слепым (проектировать и читать диаграммы UML). Поддерживает 9 видов диаграмм [46][47][48].

• Лицензия: GPL;
• Языки генерации кода: Java, C/C++;
• Обратное проектирование: C#, grails, Java, Lua, PHP, SqlALchemy;
• Платформы: Linux, OS X, Windows;
• Другие особенности: поддержка спецификаций UML2 и частично XMI (только экспорт); интеграция с Chrome, Word, Open Office, Google Docs, J2EE Servlet, JQuery , Sublime, Eclipse, NetBeans, IntelliJ, LaTeX, Emacs, Doxygen и т. д.; выводит изображения в формате PNG или SVG.

Poseidon for UML – это приложение, используемое для создания моделей UML. Он возник из проекта ArgoUML,

• Лицензия: проприетарное ПО;
• Языки генерации кода: Java, VBScript, C++, C#, SQL, PHP, Delphi;
• Обратное проектирование: Java;
• Платформы: кросс-платформенное (Java);
• Другие особенности: поддержка спецификации UML2; интеграция с Eclipse и импорт JAR-фаилов.

PragmaDev Studio — это инструмент моделирования и тестирования, представленный PragmaDev в 2002 году, посвященный спецификации коммуникационных систем. Первоначально он назывался Real Time Developer Studio или RTDS, а его основная задача заключалась в поддержке технологии моделирования SDL-RT. Но с версии 5.0, RTDS называется PragmaDev Studio, и организована в четыре независимых модуля: Specifier, Developer, Tester и Tracer [49][50][51].

• Лицензия: freemium;
• Языки генерации кода: C, C++ (из модели SDL-RT);
• Языки для обратного проектированием;
• Платформы: Windows, Linux, OS X;
• Другие особенности: поддежка MDA, спецификаций UML 2 и частично XMI, возможность генерировать код из шаблона SDL. Сгенерированный код может быть адаптирован к любой операционной системе реального времени или планировщику. Инструмент также предлагает интеграцию с отладчиками, такими как gdb, чтобы производить отладку модели, а не сгенерированного кода.

Prosa UML Modeller – UML-инструмент от Insoft Oy, хранящий диаграммы в текстовом формате ASCII. Поддерживает 9 типов диаграмм (диаграмма использования, последовательности, взаимодействия, классов, состояний, действий, компонентов, развертывания, пакетов).

• Лицензия: проприетарное ПО;
• Языки генерации кода: C ++ Java, C #, SQL DDL и SQL-запросы;
• Обратное проектирование: C++, Java, C # (заголовки классов синхронизируются между диаграммами и кодом в режиме реального времени);
• Платформы: только Windows;
• Другие особенности: поддержка MDA, спецификаций UML2 и XMI (открытая база моделей); поддержка шаблонов и одновременной работы нескольких пользователей; интеграция с репозиториями.

Rational Rhapsody – основанная на UML среда моделирования для проектирования ИС. Rational Rhapsody Design Manager - это веб-приложение, которое заинтересованные стороны, разработчики и другие члены команды используют для совместной разработки продуктов, программного обеспечения и систем. Разработанные в Rational Rhapsody модели могут размещаться на сервере Design Manager, подключиться к которому позволяет компонент клиентского расширения Rational Rhapsody. После подключения к серверу модели могут быть перемещены в области проекта с конкретными областями моделирования [52][53][54].

• Лицензия: проприетарное ПО;
• Языки генерации кода: C++, C, Java, Ada, C#, Corba, и др. (возможность настройки для других языков);
• Обратное проектирование: C++, C, Java, Ada, C#, и др. (возможность настройки для других языков);
• Платформы: Windows, Linux;
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI; интеграция с Visual Studio, Eclipse, TcSE, WindRiver, Green Hills, QNX, Linux, Mathworks Simulink, DOORS, и настраиваемый для других; поддержка шаблонов проектирования; тестирование на основе моделей.

Reactive Blocks — это среда разработки на основе визуальной модели, основанная на диаграммах активности, поддерживающих формальный анализ модели, автоматическое создание кода, иерархическое моделирование и обширную библиотеку готовых к использованию компонентов для платформы Java. Комбинируя повторно используемые блоки, разработчик может создавать сложные приложения графически [55][56][57].

• Лицензия: свободное (издание сообщества)/проприетарное ПО;
• Языки генерации кода: Java;
• Обратное проектирование: не поддерживается;
• Платформы: Windows, Mac OS, Linux;
• Другие особенности: поддержка спецификаций UML 2 и XMI, генерация кода из диаграмм активности для J2SE, OSGi, Kura и ESF, модульное тестирование через JUnit, поддерживает формальный анализ и моделирование пространства состояний.

SAP PowerDesigner – это инструмент моделирования CASE, разработанный Sybase, дочерней компанией SAP SE. Он сочетает стандартные методы моделирования UML с возможностями структурного подхода к проектированию ИС.

• Лицензия: проприетарное ПО;
• Языки генерации кода: Java, C #, C++, VB .NET, PowerBuilder;
• Обратное проектирование: Java, C #, VB .NET, PowerBuilder;
• Платформы: только Windows;
• Другие особенности: поддержка MDA, спецификаций UML2 и XMI; интеграция с Eclipse; поддержка шаблонов, многопользовательский репозиторий; доступна работа в веб-интерфейсе и генерирование XML и IDL; поддерживаемые базы данных: IBM DB2, Informix, Ingres, InterBase, Access, MS SQL, MySQL, Oracle, PostgeSQL, Sybase AS Anywhere и Enterprise.

Software Ideas Modeler — это CASE-средство для UML-моделирования словацкого разработчика программного обеспечения Душан Родина (Dušan Rodina), которое поддерживает все 14 типов диаграмм, указанных в UML 2.4. ПО доступно в версии Professional Edition, бесплатной для некоммерческого использования, и версии Ultimate Edition, которая предоставляет больше возможностей. Обеспечивает простую систему создания задачи и возможность назначать конкретных людей этим задачам.

• Лицензия: свободное/проприетарное ПО;
• Языки генерации кода: Java, C#, C++, SQL DDL и т. д;
• Обратное проектирование: Java, C# и Visual Basic .NET;
• Платформы: Windows, Mac OS X, Linux, Solaris, JVM;
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI; создание документации для созданных моделей в форматах PDF, RTF, HTML, ODT или TXT; экспорт моделей в растровые (JPG, BMP, PNG), векторные (SVG) или другие (XMI, PDF) форматы.

Sparx Systems Enterprise Architect — это инструмент визуального моделирования и проектирования, основанный на OMG UML. Платформа поддерживает проектирование и создание информационных систем, моделирование бизнес-процессов, и моделирование доменов, основанных на технологии. Он используется предприятиями и организациями, чтобы не только моделировать архитектуру своих систем, но и обрабатывать реализацию этих моделей в течение всего жизненного цикла разработки приложений [58][59][60].

• Лицензия: проприетарное ПО;
• Языки генерации кода: ActionScript, C, C #, C ++, Delphi, Java, PHP, Python, Visual Basic, Visual Basic .NET, DDL, EJB, XML Schema, Ada, VHDL, Verilog, WSDL, BPEL, Corba IDL;
• Обратное проектирование: ActionScript, C, C #, C ++, Delphi, Java, PHP, Python, Visual Basic, Visual Basic .NET, DDL, XML Schema, WSDL;
• Платформы: Windows, Linux (через Wine), macOS (через CrossOver);
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI2.1, интеграция с OSLC, CVS (импорт/экспорт), ArchiMate (импорт/экспорт); интерфейс автоматизации - поддерживает полный интерфейс API для использования на любом языке на основе COM (и Java); среди доступных надстроек есть интерфейсы для VS.Net и Eclipse, Microsoft Office и DOORS.

StarUML — это инструмент UML от MKLab. Программное обеспечение было лицензировано в соответствии с модифицированной версией GNU GPL до 2014 года, когда переработанная версия 2.0.0 была выпущена для бета-тестирования под собственной лицензией. Заявленная цель проекта заключалась в замене более крупных коммерческих приложений, таких как Rational Rose и Borland Together. В конце 2011 года в результате «форка» (новой ветви развития) с версии StarUML 5.0 под названием WhiteStarUML теперь активно развивается в Object Pascal [61][62][63].

• Лицензия: проприетарное ПО (ранее GPL);
• Языки генерации кода: Java, C#, C++;
• Обратное проектирование: Java, C#, C++;
• Платформы: Windows, macOS, Linux;
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI (импорт моделей); поддержка шаблонов проектирования; интеграция с JavaScript, Node.js, HTML5.

Umbrello UML Modeller это бесплатный инструмент UML-моделирования, поддерживающий все типы диаграмм UML.

• Лицензия: GPLv2 +;
• Языки генерации кода: ActionScript, Ada, C#, C++, D, IDL, Java, JavaScript, Pascal, Perl, PHP, Python, Ruby, SQL, Tcl, Vala, XML Schema;
• Обратное проектирование: C++, IDL, Pascal/Delphi, Ada, Python, Java;
• Платформы: Unix-подобные, Windows (экспериментально через KDE);
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI (импорт из XMI-файлов, созданных внешними инструментами из PHP или Perl-кода, и экспорт в различные языки программирования); интеграция с KDE; экспорт в PNG и форматы DocBook и XHTML для совместной работы разработчиков (когда члены команды могут не иметь прямого доступа к Umbrello или в случаях, когда содержание модели должно быть опубликовано на веб-сайте) [64][65][66].

UML Designer – это инструмент графического моделирования для UML2 на основе плагина Eclipse UML2 и с открытым исходным кодом, основанный на Sirius и Eclipse. Обеспечивает поддержку основных диаграмм UML и профилей UML.

• Лицензия: EPL;
• Языки генерации кода: Java или C (есть совместимость с инструментами генерации кода Eclipse UMLGenerators или Acceleo);
• Обратное проектирование: Java или C (языки, поддерживаемые генераторами Eclipse UML);
• Платформы: Linux, Mac OS X, Microsoft Windows;
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI; интеграция с Eclipse (версии «Oxygen»); модули доступны через Eclipse Marketplace, чтобы объединить с SysML или напрямую сгенерировать код (Java или C).

UMLet — это инструмент UML с открытым исходным кодом на основе Java, предназначенный для обучения унифицированному языку моделирования и для быстрого создания диаграмм UML (диаграммы классов, прецедентов, последовательности, состояний, деятельности, развертывания). Его нельзя называть инструментом моделирования, поскольку он не предполагает наличие базового словаря или каталога объектов многократного использования. Имеет простой пользовательский интерфейс, который использует коды форматирования текста для изменения основных фигур. Есть онлайн-реализация под названием UMLetino [67][68][69].

• Лицензия: GPL;
• Языки генерации кода: не поддерживаются;
• Обратное проектирование: не поддерживается;
• Платформы: Windows, Mac OS X, Linux;
• Другие особенности: не поддерживает спецификации UML 2 (но для этого можно использовать функцию настройки); есть возможность экспортировать диаграммы в изображения (eps, jpg), формат чертежа (SVG), формат документов (PDF); буфер обмена можно использовать для копирования-вставки диаграмм в виде изображений в другие приложения; cоздание пользовательских элементов UML, изменение и использование основных объектов чертежа (это требует программирования элементов на Java); интеграция с Eclipse.

UModel — это инструмент UML-моделирования от Altova (создателя XMLSpy), поддерживающий все 14 типов диаграмм UML 2, и добавляющий уникальную диаграмму для моделирования XML-схем в UML.

• Лицензия: проприетарное ПО;
• Языки генерации кода: Java, C#, Visual Basic;
• Обратное проектирование: Java, C#, Visual Basic;
• Платформы: Windows, Mac OS X, Linux;
• Другие особенности: поддержка MDA, спецификаций UML 2 и XMI; поддерживает шаблоны проектирования; интегрируется с системами контроля версий и работает как плагин для интегрированных сред разработки Eclipse и Visual Studio; также поддерживает моделирование бизнес-процессов, SysML и моделирование базы данных.

Umple — является разработанным в Университете Оттавы CASE-инструментом, частично целью которого является приведение UML-моделирования и объектно-ориентированного программирования в соответствие. Название Umple представляет слияние «UML», «ample» («достаточно») и «programming language» («язык программирования»), что указывает на то, что оно предназначено для обеспечения широких возможностей расширения языков программирования с возможностями UML [70][71][72].

• Лицензия: MIT;
• Языки генерации кода: Java, C ++, SQL, Alloy, NuSMV, yUML, USE;
• Обратное проектироване: Java;
• Платформы: кросс-платформенное (JVM/Eclipse);
• Другие особенности: не поддерживает MDA, но поддерживает спецификации XMI и частично UML2 (класс, состояние, композитная структура); поддерживает шаблоны проектирования; импорт/экспорт может осуществляться по диаграмме или текстовой форме; внедряет код действия на Java и другие языки, написанные сами по себе; создание документации, архитектуры плагина для генераторов.

Visual Paradigm (VP-UML) – это инструмент UML от Visual Paradigm International, поддерживающий 13 типов диаграмм (диаграмма классов, прецедентов, последовательности, связи, состояния машины, деятельности, компонентов, развертывания, пакетов, объекта, композитной структуры, профиля, синхронизации, обзора взаимодействия).

• Лицензия: свободное (версия «community»)/проприетарное ПО;
• Языки генерации кода: Java, C #, C ++, PHP, Ada, Action Script (все только в коммерческой версии);
• Обратное проектирование: Java, C# (двоичный), C++, PHP (все только в коммерческой версии);
• Платформы: Windows, MacOS X, Linux , Solaris и других UNIX–системах;
• Другие особенности: поддержка спецификаций UML2, и отчасти XMI (только в коммерческой версии); интеграция с Eclipse, NetBeans, IntelliJ и Visual Studio; есть возможности структурного подхода [73].

2.2 Особенности объектно-ориентированного подхода

Преимущества подхода

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

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

Объединение атрибутов и методов в объекте (классе), а также инкапсуляция позволяют добиться большей внутренней и меньшей внешней связности между компонентами системы. Это облегчает решение проблем [11][74]:

1. адаптации системы к изменению существующих или появлению новых требований;
2. сопровождения системы на разных стадиях жизненного цикла;
3. повторного использования компонентов.

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

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

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

Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом, а сам UML получил широкое распространение и динамично развивается ещё и потому, что расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии [5][74].

Недостатки подхода

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

К ним можно отнести, во-первых, избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он включает много избыточных или практически неиспользуемых диаграмм и конструкций. Справедливости ради стоит отметить, что чаще это можно услышать в отношении UML 2.0, чем UML 1.0, так как более новые ревизии включают больше «разработанных комитетом» компромиссов [75].

Минусом является и неточная семантика. Так как UML определён комбинацией себя (абстрактный синтаксис), OCL (языком описания ограничений — формальной проверки правильности) и английского (подробная семантика), то он лишен скованности, присущей языкам, точно определённым техниками формального описания. В некоторых случаях абстрактный синтаксис UML, OCL и английский противоречат друг другу, в других случаях они неполные. Неточность описания самого UML одинаково отражается на пользователях и поставщиках инструментов, приводя к несовместимости инструментов из-за уникального трактования спецификаций [75][76].

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

Только код отражает код. Ещё одно мнение — что важны рабочие системы, а не красивые модели. Как лаконично выразился Джек Ривс, «The code is the design» («Код и есть проект»). В соответствии с этим мнением, существует потребность в лучшем способе написания ПО.

UML ценится при подходах, которые компилируют модели для генерирования исходного или выполнимого кода, однако этого всё же может быть недостаточно, так как UML не имеет свойств полноты по Тьюрингу, и любой сгенерированный код будет ограничен тем, что может разглядеть или предположить интерпретирующий UML инструмент [74].

Кумулятивная нагрузка/Рассогласование нагрузки (англ. «Cumulative Impedance/Impedance mismatch»). Рассогласование нагрузки — термин из теории системного анализа для обозначения неспособности входа одной системы воспринять выход другой. Как в любой системе обозначений, UML может представить одни системы более кратко и эффективно, чем другие. Таким образом, разработчик склоняется к решениям, которые более комфортно подходят к переплетению сильных сторон UML и языков программирования. Проблема становится более очевидной, если язык разработки не придерживается принципов ортодоксальной объектно-ориентированной доктрины (не старается соответствовать традиционным принципам ООП).

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

Вывод.

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

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

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

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

Поэтому если ранее наиболее популярным CASE-средством для объектно-ориентированного анализа и проектирования считался IBM Rational Rose, то к настоящему моменту наибольший интерес с точки зрения удобства использования, представляют современные IDE с поддержкой UML.

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

1. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML / А.В. Леоненков. – www.intuit.ru.
2. Анисимов, В. В. Проектирование информационных систем. Часть 1. Структурный подход [Текст]: конспект лекций / В. В. Анисимов, В. А. Долгов. – Хабаровск: Изд-во ДВГУПС, 2007.
3. Анисимов, В. В. Проектирование информационных систем. Часть 2. Объектно-ориентированный подход [Текст]: конспект лекций / В. В. Анисимов, В. А. Долгов. – Хабаровск: Изд-во ДВГУПС, 2007.
4. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2001. – 560 с.
5. Леоненков, А.В. Самоучитель UML 2 / А.В. Леоненков. – СПб.: БХВ - Петербург, 2007. – 576с.
6. Терра-Лексикон: Иллюстрированный энциклопедический словарь. – М.: ТЕРРА, 1998. - 672 с.
7. Мейер, Б. Объектно-ориентированное конструирование программных систем, 2-е издание, ISBN 5-7502-0255-0, 0-13-62155-4; 2005
8. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2002. - 496 с.
9. Крачтен, Ф. Введение в Rational Unified Process / Ф. Кратчен. - М.: Издательский дом «Вильямс», 2002. - 240 с.
10. Гранд, М. Шаблоны проектирования в Java / М. Гранд. - М.: Новое знание, 2004. - 559 с.
11. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2001. - 496 с.
12. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2004. - 432 с.
13. Goodwin, David. "Modelling and Simulation, p. 26". The University of Warwick - http://www2.warwick.ac.uk/fac/sci/physics/research/condensedmatt/imr_cdt/students/david_goodwin/teaching/modelling/l3_objectorientation.pdf
14. Орлов, С.А. Технологии разработки программного обеспечения : учеб. / С.А. Орлов. – СПб. : Питер, 2002. – 464 с.
15. Saraswati Experts. "2.5.3". COMPUTER SCIENCE WITH C++. Saraswati House Pvt Ltd. p. 1.27. ISBN 978-93-5199-877-8. Дата проверки: 29 Июня 2018г.
16. Computerwoche (German) "Interaktives Programmieren als Systems-Schlager" - www.computerwoche.de/a/interaktives-programmieren-als-systems-schlager,1205421
17. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 1998. – 176 с.
18. Калянов, Г.Н. CASE. Структурный системный анализ (автоматизация и применение) / Г.Н. Калянов. – М. : Лори, 1996. – с.
19. Баркер, Р. CASE*Method. Моделирование взаимосвязей между сущностями / Р. Баркер. – М., 1992. – 233 с.
20. Maciaszek, L.A.Process Model for Round-trip Engineering with Relational Database, in: Challenges of Information Technology Management in the 21st Century, 2000 Information Resources Management Association Internatio
21. ParadigmParadigm Plus. Round-trip Engineering with Microsoft Visual C++, Platinum Technology, 1997, 36 pp.
22. RationalRational Rose 98. Roundtrip Engineering with C++, Rational Software Corp., 1998, 454 pp.
23. OMG. – www.omg.com.
24. Marco Brambilla, Jordi Cabot, Manuel Wimmer, Model Driven Software Engineering in Practice, foreword by Richard Soley (OMG Chairman), Morgan & Claypool, USA, 2012, Synthesis Lectures on Software Engineering #1. 182 pages. ISBN 9781608458820 (paperback), ISBN 9781608458837.
25. David S. Frankel, Model Driven Architecture: Applying MDA to Enterprise Computing, John Wiley & Sons, ISBN 0-471-31920-1.
26. Роберт Орфали, Ден Харки, Джери Эдвардс «Основы CORBA» 1999.
27. Stevens, P. XMI and MOF: a mini-tutorial. University of Edinburgh - http://homepages.inf.ed.ac.uk/perdita/XMI/tutslides2up.pdf.
28. ArgoUML Features - http://argouml.tigris.org/features.html.
29. ArgoUML documentation. "UML Specification Incompatibility list" - argouml.tigris.org/documentation/umlsupport/index.html.
30. Astah at ComponentSource - https://www.componentsource.com/product/astah-gsn.
31. Borland Together product webpage - www.microfocus.com/products/requirements-management/together/?utm_medium=301&utm_source=borland.com.
32. Bouml Historic - bouml.fr/historic.html
33. Хейзинга Д., Колава А., Автоматическое предотвращение дефектов: лучшие практики в области управления программным обеспечением, Wiley-IEEE Computer Society Press, (ISBN 978-0-470-04212-0), 2007, с.398
34. Eclipse UML2 Tools - www.eclipse.org/modeling/mdt/?project=uml2.
35. Боггс, У. UML и Rational Rose / У. Боггс, М. Боггс. - М.: Издательство «ЛОРИ», 2001. - 582 с.
36. Леоненков, А.В. Визуальное моделирование в среде IBM Rational Rose 2003 / А.В. Леоненков. – www.intuit.ru.
37. IBM Rational Software Architect V8.5 product family delivers an enhanced architecture, design, and deployment planning solution, IBM United States Software Announcement 212-208, June 4, 2012 - www-01.ibm.com/common/ssi/cgi-bin/ssialias?infotype=AN&subtype=CA&htmlfid=897%2FENUS212-208&appname=USN.
38. About the end of support announcement for Rational Software Architect 7.5 and Rational Software Modeler 7.5 - http://www-01.ibm.com/support/docview.wss?uid=swg21670980
39. "MagicDraw" - No Magic, Inc. System Requirements -www.nomagic.com/products/magicdraw.
40. Bentakouk, Lina; Fayçal Bessayah; Mounir Lallali; Wissam Mallouli; Andrey Sadovykh. "A Framework for Modeling and Testing of Web Services Orchestration" - www.mallouli.com/recherche/publications/mda4sc2010.pdf.
41. Elvesæter, Brian; Arne-Jørgen Berre; Andrey Sadovykh. "Specifying Services using the Service Oriented Architecture Modeling Language (SOAML): A baseline for specification of cloud-based services" - remics.eu/system/files/SoaML_CLOSER_2011_Paper_Final.pdf.
42. Bagnato, Alessandra; Andrey Sadovykh; Richard F. Paige; Dimitrios S. Kolovos; Luciano Baresi; Angelo Morzenti; Matteo Rossi. "MADES: Embedded Systems Engineering Approach in the Avionics Domain" (архив) - web.archive.org/web/20120519142437/http://www.txtgroup.com/newsletter/attachment/MADES_HoPES2010_0.4.pdf
43. Michael Dutz: Unified Modeling Language. Totgesagte leben länger. dotNET Magazin 3/2011. S. 35-37.
44. Veikko Krypczyk: Butter bei die Fische. Unified Modeling Language, Teil 4: Vom Modell zum Quellcode. dotNET Magazin 5/2010. S. 50-56.
45. Dirk Frischalowski: Softwareentwurf mit der UML. dotNET Magazin 11/2004. S. 82-84.
46. Campagne, Fabien (June 16, 2014). The MPS Language Workbench, Vol. 1. CreateSpace Independent Publishing Platform. ISBN 9781497378650
47. Luque, L.; Veriscimo, E.S.; Pereira, G.C.; Filgueiras, L.V.L. (2014). "Can We Work Together? On the Inclusion of Blind People in UML Model-Based Tasks". In P.M. Langdon; J. Lazar; A. Heylighen; et al. Inclusive Designing Joining Usability, Accessibility, and Inclusion (Aufl. 2014 ed.). Cham: Springer International Publishing. ISBN 978-3-319-05095-9.
48. Müller, Karin (2012). "How to Make Unified Modeling Language Diagrams Accessible for Blind Students". In Klaus Miesenberger. Computers Helping People With Special Needs 13th International Conference, ICCHP 2012, Linz, Austria, July 11-13, 2012, Proceedings, Part I. Berlin [u.a.]: Springer-Verlag New York Inc. pp. 186–190. ISBN 978-3-642-31521-3.
49. Doldi, Laurent (2003). "Validation of Communications Systems with SDL: The Art of SDL Simulation and Reachability Analysis". John Wiley and Sons Inc.
50. Haddad, Serge; Kordon, Fabrice; Pautet, Laurent; Petrucci, Laure (2013). "Distributed Systems: Design and Algorithms". John Wiley and Sons Inc.
51. Brumbulli, Mihal (2015). "Model-driven development and simulation of distributed communication systems". Humboldt University of Berlin.
52. Harel, D.; Gery, E.; Weizmann Inst. of Sci., Rehovot "Executable object modeling with statecharts" 25 Mar 1996 doi:10.1109/ICSE.1996.493420
53. Harel, David. "Statecharts in the Making: A Personal Account". The Weizmann Institute of Science.
54. Rational Rhapsody Architect for Systems Engineers - www.systemsengineeringtool.com/rational-rhapsody-architect-for-systems-engineers
55. Reactive Blocks «Visual development environment for Java applications» - www.bitreactive.com.
56. Kraemer, Frank Alexander (2008). Engineering Reactive Systems: A Compositional and Model-Driven Method Based on Collaborative Building Blocks (PhD). Fakultet for informasjonsteknologi, matematikk og elektroteknikk.
57. "Huawei, Bitreactive and Eurotech join OSGi Alliance" (3.11.2015) - www.osgi.org/wp-content/uploads/Huawei-Bitreactive-and-Eurotech-Join-OSGi-Alliance-3-Nov-2015.pdf.
58. G.Dickinson, N. Orvis, S.Hufnagel. "From HITSP to HL7 EHR System Function and Information Model EHR-S FIM Release 3.0". National Institute of Standards and Technology.
59. Frank Truyen. "Model Driven Architecture with Enterprise Architect". Cephas.
60. Phil Chudley. "How to Create CORBA IDL using Enterprise Architect". Dunstan Thomas.
61. StarUML 3 "A sophisticated software modeler for agile and concise modeling" - staruml.io.
62. StarUML Review - www.methodsandtools.com/tools/staruml.php
63. StarUML. Project website at SourceForge - sourceforge.net/projects/staruml
64. "PHP2XMI". Motion-Twin Technologies - tech.motion-twin.com/php_php2xmi.html.
65. Welcome to Umbrello - The UML Modeller - umbrello.kde.org.
66. Umbrello UML Modeller. Project website at SourceForge - sourceforge.net/projects/uml
67. UMLet. . Project website at GitHub - github.com/umlet/umlet.
68. M. Auer, T. Tschurtschenthaler, S. Biffl, "Flyweight UML Modelling Tool for Software Development", Proc of 29th EUROMICRO Conference
69. M. Auer, L. Meyer, S. Biffl, Explorative UML Modeling - Comparing the Usability of UML Tools, Proc of 9th International Conference on Enterprise Information Systems (ICEIS 2007).
70. Forward, Andrew (2010). "The Convergence of Modeling and Programming: Facilitating the Representation of Attributes and Associations in the Umple Model-Oriented Programming Language". PhD Thesis, University of Ottawa.
71. Badreddin, Omar (2012). "A Manifestation of Model-Code Duality: Facilitating the Representation of State Machines in the Umple Model-Oriented Programming Language". PhD Thesis, University of Ottawa.
72. Lethbridge, Timothy C.; Forward, Andrew; Badreddin, Omar (October 2010). "Umplification: Refactoring to Incrementally Add Abstraction to a Program". 17th Working Conference on Reverse Engineering, pp. 220-224.
73. Curtis H. K. Tsang, Clarence S. W. Lau, Ying K. Leung: Object-oriented Technology: From Diagram to Code with Visual Paradigm for UML. McGraw-Hill, 2005, ISBN 978-0-07-124046-8.
74. Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. - М.: Весть-Метатехнология, 2001
75. Фаулер, М. Архитектура корпоративных программных приложений / М. Фаулер. – М.: Издательский дом «Вильямс», 2004. – 544 с.
76. Фаулер, М. UML. Основы. Третье издание. / М. Фаулер. – М.: Символ-Плюс, 2006. – 192 с.