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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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

Для реализации поставленной цели решены следующие задачи:

– рассмотрены основные положения объектно-ориентированного подхода;

– изучены особенности языка UML для поддержки объектно-ориентированного проектирования;

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

ГЛАВА 1
ОСНОВЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

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

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

Характерными свойствами объектно-ориентированного подхода являются [1,2]:

модульность (представление в виде множества модулей).
повторное применение существующих и новых модулей.

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

Если представить реальный объект, такой как телевизор, он будет иметь несколько функций и свойств:

его не нужно открывать для использования;
он имеет некоторые элементы управления (кнопки на корпусе или пульт дистанционного управления);
концепция телевизора понятна, даже если он подключен к DVD-плееру;
он готов к использованию, когда мы его приобретаем.

Все перечисленное во многом очень хорошо сравнимо с понятием класса, потому что класс должен:

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

Классы позволяют представлять сложные структуры и включают два компонента [1,2]:

состояния (или данные) – это значения, которые имеет объект;
методы (или поведение) – это способы, которыми объект может взаимодействовать со своими данными, действиями.

Класс Television (Телевидение) показан на рисунке 1 средствами языка унифицированного языка моделирования (UML).

Рисунок 1. Класс Television (Телевидение)

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

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

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

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

Рисунок 2. Пример объектов «Телевизоры»

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

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

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

Существует подмножество функциональных возможностей, которые пользователю разрешено вызывать, называемое интерфейсом. В случае телевизора, это функции, которые можно вызывать с помощью пульта дистанционного управления или кнопки на передней панели телевизора. Полная реализация класса – это совокупность открытого интерфейса и частной реализации [2,3].

Рисунок 3. Пример интерфейса телевизора

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

Для пользователя (который может быть другим программистом) [3]:

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

Для программиста:

программист может изменить реализацию, но не должен уведомлять пользователя.

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

Определение уровня «сокрытия» определенных методов или состояний класса выполняют с использованием общедоступных, закрытых и защищенных ключевых слов [1,3]:

публичные методы описывают интерфейс;
частные методы описывают реализацию.

На рисунке 4 показана инкапсуляция в применительно к классу Television (телевидение). Согласно нотации UML частные методы обозначаются знаком минус, а открытые методы обозначаются знаком плюс.

Частные методы – это написанные методы, которые являются частью внутренней работы телевидения, но не должны быть понятны пользователю. Например, пользователю потребуется вызвать метод powerOn (), но также будет вызван закрытый метод displayPicture(), но внутри, а не напрямую пользователем. Поэтому этот метод не добавляется в интерфейс, а скрывается внутри реализации с использованием ключевого слова private [1-3].

Рисунок 4. Пример инкапсуляции для класса «Телевидение»

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

Этот принцип применяется людьми при категоризации объектов и описаний. Например, на вопрос: «Что такое утка?», можно ответить:

птица, которая плавает,

или точнее:

птица с перепончатыми лапами, которая плавает.

Таким образом, на рисунке 5 проиллюстрировано отношение наследования между уткой и птицей, согласно которому утка – особый тип птицы [3,4].

Рисунок 5. Пример наследования для класса «Утка»

При необходимости предоставления неструктурированного описания, например, различных транспортных средств, можно указать, что автомобиль-универсал – это автомобиль с очень большим багажником. На рисунке 6 показан пример того, как можно организовать такое описание с использованием наследования [1,4].

Рисунок 6. Пример наследования для нескольких классов

Таким образом, представление является родительско-дочерним. Дочерний класс наследует свойства родительского класса поэтому на рисунке 6 класс Car (Машина) является дочерним по отношению к классу Vehicle (Транспорт), т.е. Car (Машина) наследуется от Vehicle (Транспорт).

Рисунок 7 иллюстрирует отношение между родительским и дочерним классами [1,3].

Рисунок 7. Отношение между родительским и дочерним классом

Один из способов определить, правильно ли организованы классы, – это проверить их с помощью проверок отношений «IS-A» («ЯВЛЯЕТСЯ») и «IS-A-PART-OF» («ЯВЛЯЕТСЯ ЧАСТЬЮ»). Легко спутать объекты внутри класса и потомки класса, поэтому на рисунке 8 приведена проверка предыдущих отношений между автомобилем и транспортным средством [3,4].

Рисунок 8. Проверка отношений в классе

Отношение «IS-A» («ЯВЛЯЕТСЯ») описывает наследование, при этом можно сказать, что «Автомобиль ЯВЛЯЕТСЯ Транспортом» и «Автомобиль седан ЯВЛЯЕТСЯ Транспортом», поэтому все отношения правильные. Отношение «IS-A-PART-OF» («ЯВЛЯЕТСЯ ЧАСТЬЮ») описывает состав (или агрегацию) класса. Таким образом, на рисунке 8 можно выделить «двигатель, являющийся частью транспортного средства», или «двигатель и колеса, являющиеся частью транспортного средства». Это так, даже если Engine (Двигатель) – это тоже класс, включающий много разных описаний двигателя – бензин, дизель, количество клапанов и т. д.

Итак, использование наследования позволяет [3,4]:

унаследовать поведение и добавить дополнительное специализированное поведение – например, Car (Машина) IS A Vehicle (Транспорт) с добавлением объектов Колеса, Сидения и т. д.
унаследовать поведение и заменить его – например, класс SaloonCar (Седан) унаследует от Car (Машины) и предоставит новую реализацию.
сокращение объема кода, который должен быть написан и отлажен – например, в этом случае детализируются только различия, SaloonCar (Седан), по сути, идентичен Car (Машина), и только различия требуют описания.

Когда класс наследует от другого класса, он наследует как состояния, так и методы этого класса, поэтому в случае наследования класса Car (Машина) от класса Vehicle (Транспорт) класс Car наследует методы класса Vehicle, такие как engineStart (), gearChange (), lightsOn () и т. д.

Класс Car также наследует состояния класса Vehicle, такие как isEngineOn, isLightsOn, numberWheels и т. д.

Полиморфизм означает множественность форм. В ООП эти множественные формы относятся к нескольким формам одного и того же метода, где одно и то же имя метода может использоваться в разных классах или одно и то же имя метода может использоваться в одном и том же классе со слегка отличающимися параметрами.

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

Полиморфизм играет важную роль, позволяя объектам, имеющим разные внутренние структуры, использовать один и тот же внешний интерфейс. Например, объекты разной формы – квадрат, треугольник, круг, показанные на рисунке 9, относятся к общему понятию – фигуры [4].

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

Рисунок 9. Полиморфизм фигур

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

Объектно-ориентированный подход дает возможность уменьшить некоторые основные расходы, связанные с системами, такие как обслуживание и разработка программного кода. Далее рассмотрены некоторые преимущества объектно-ориентированного подхода [4,5]:

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

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

3. Моделирование в реальном мире: объектно-ориентированные системы, как правило, моделируют реальный мир более полно, чем традиционные методы. Объекты организованы в классы объектов, а объекты связаны с поведением. Модель основана на объектах, а не на данных и обработке [4].

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

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

Также рассмотрим и недостатки объектно-ориентированной технологии. Существует несколько основных заблуждений, которые необходимо учитывать при рассмотрении использования объектно-ориентированной технологии [5,6]:

1. Объектно-ориентированная технология не является панацеей – объектно-ориентированная разработка лучше всего подходит для динамических интерактивных сред, о чем свидетельствует ее широкое распространение в системах CAD / CAM и инженерных системах проектирования. Для крупномасштабных объектно-ориентированных корпоративных системы вопрос пока открыт, и многие приложения для информационных систем (например, начисления заработной платы, бухгалтерский учет) могут не получить выгоды от объектно-ориентированного подхода.

2. Объектно-ориентированная разработка еще не полностью принята крупными поставщиками, хотя имеет вес на рынке.

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

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

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

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

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

Моделирование данных при использовании структурного подхода выполняется с помощью DFD и E-R диаграмм, в то время как при объектно-ориентированном подходе применяются диаграммы классов, последовательности, состояний [6].

ГЛАВА 2
ПРИМЕНЕНИЕ ЯЗЫКА UML ДЛЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

2.1 Виды диаграмм на языке UML

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

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

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

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

каждый вариант использования связан как минимум с одним актером;
каждый вариант использования имеет инициатора (то есть актера);
каждый вариант использования приводит к соответствующему результату.

Варианты использования также могут иметь отношения с другими вариантами использования. Три наиболее типичных типа отношений между вариантами использования [6,7]:

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

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

Актеры представляют не физических людей или системы, а их роль. Это означает, что когда человек взаимодействует с системой по-разному (принимая на себя разные роли), он будет представлен несколькими участниками. Например, человек, который обеспечивает поддержку клиентов по телефону и принимает заказы от клиента, будет представлен актером «Вспомогательный персонал» и актером «Торговый представитель» [8].

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

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

Рисунок 10. Диаграмма использования «Заказ авиабилета»

Диаграммы классов показывают различные классы, которые составляют систему, и как они связаны друг с другом. Диаграммы классов относятся к «статическим» диаграммам, поскольку они показывают классы, их методы и атрибуты, а также статические отношения между ними [7,8].

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

В UML классы представлены прямоугольниками с именем класса (рисунок 11), а также могут отображать атрибуты и операции класса в двух других «областях» внутри прямоугольника [8].

Рисунок 11. Визуальное представление класса в UML

В UML атрибуты отображаются, по крайней мере, с именем, а также могут отображать тип, начальное значение и другие свойства. Атрибуты также могут отображаться с их видимостью [6,8]:

+ –публичный атрибут;

# – защищенный атрибут;

- личный атрибут.

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

+ – публичные операции;

# – защищенные операции;

- частные операции.

Классы могут быть связаны друг с другом следующим образом [8,9]:

1. Обобщение.

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

В UML обобщение связи между двумя классами определяет иерархию, представляющую концепцию наследования производного класса от базового класса. В UML обобщения представлены линией, соединяющей два класса со стрелкой на стороне базового класса (рисунок 12) [9].

Рисунок 12. Визуальное представление обобщения в UML

2. Ассоциация представляет отношения между классами и дает общую семантику и структуру для многих типов «связей» между объектами.

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

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

В UML ассоциации представлены в виде линий, соединяющих классы, участвующие в отношениях, а также могут показать роль и множественность каждого из участников (рисунок 13). Кратность отображается в виде диапазона [min..max] неотрицательных значений со звездочкой (*) на максимальной стороне, представляющей бесконечность [9].

Рисунок 13. Визуальное представление ассоциации в UML

3. Агрегирование

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

В UML, агрегация представлена ассоциацией с ромбом на стороне целого (рисунок 14) [8,10].

Рисунок 14. Визуальное представление отношений агрегации в UML

4. Композиция образует отношения целых частей, но отношения настолько сильны, что части не могут существовать сами по себе. Они существуют только внутри целого, и если целое разрушено, части тоже не существуют. В UML композиции представлены сплошным ромбом на стороне целого (рисунок 15) [5,9].

Рисунок 15. Визуальное представление композиции в UML

Пример диаграммы классов приведен на рисунке 16 [9].

Рисунок 16. Диаграмма классов «Запрос к серверу»

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

Диаграммы состояний рассматривают Объекты как конечные автоматы или конечные автоматы, которые могут находиться в одном из множества конечных состояний и которые могут изменять свое состояние посредством одного из конечного набора причин. Например, объект типа Сервер может находиться в одном из следующих состояний [10]:

готов;
ожидает;
работает;
выключен.

События, которые могут вызвать изменение состояния объекта:

объект создан;
объект получает сообщение об ожидании;
клиент запрашивает соединение по сети;
клиент прекращает запрос;
запрос выполнен и прекращен;
объект получает сообщение об остановке и т.д.

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

Не каждое изменение в одном из атрибутов объекта должно быть представлено состоянием, а только те изменения, которые могут существенно повлиять на работу объекта [9,11].

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

Пример диаграммы состояний приведен на рисунке 17 [10].

Рисунок 17. Диаграмма состояний «Работа сервера»

Диаграммы отношений сущностей (ER Diagrams) показывают концептуальный дизайн приложений баз данных. Они изображают различные сущности (концепции) в информационной системе и существующие отношения и ограничения между ними. Расширение диаграмм отношений сущностей, называемое «Расширенные диаграммы отношений сущностей» или «Расширенные диаграммы отношений сущностей» (EER), используется для включения объектно-ориентированных методов проектирования в диаграммы ER [9,10].

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

На диаграмме ER сущности представлены прямоугольниками с именем сущности вверху, а также могут отображать атрибуты сущности в другом «отделении» внутри прямоугольника (рисунок 18) [10].

Рисунок 18. Визуальное представление объекта в ER-диаграмме

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

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

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

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

Проверочное ограничение – это условие, которое определяет допустимые данные при добавлении или обновлении записи в таблице реляционной базы данных. Проверочное ограничение применяется к каждой строке в таблице. Ограничение должно быть предикатом. Оно может ссылаться на один или несколько столбцов таблицы. Пример: Цена > = 0 [9,11].

Пример ER-диаграммы приведен на рисунке 19.

Рисунок 19. ER-диаграмма «Кредит в банке»

2.2 Примеры программного обеспечения для проектирования информационных систем

Lucidchart – это проприетарная веб-платформа, которая позволяет пользователям совместно работать над составлением, редактированием и распространением диаграмм [12].

Lucidchart работает в браузерах, которые поддерживают HTML5. Это означает, что она не требует обновлений стороннего программного обеспечения, такого как Adobe Flash.

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

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

GenMyModel был основан как инструмент моделирования только на UML, но с тех пор он расширился и теперь охватывает бизнес-моделирование с поддержкой Archimate и BPMN [13].

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

Это больше инструмент для моделирования, чем для рисования (с его плюсами и минусами, в зависимости от того, как вы планируете использовать свои модели). Таким образом, ключевым отличием GenMyModel является его поддержка экспорта моделей в формате XMI («стандартный» формат для обмена моделями) и его возможности генерации кода. Интерфейс GenMyModel приведен на рисунке 20 [13].

Команда разработчиков программного продукта Gliffy утверждает, что в нем уделено особое внимание аспектам совместной работы и контроля версий, поэтому Gliffy является «наиболее широко используемым онлайн-приложением для создания диаграмм». Gliffy поддерживает все диаграммы UML вместе с множеством других видов диаграмм, включая сильную поддержку моделей процессов BPMN. Главная страница сайта приведена на рисунке 21 [14].

Рисунок 20. Интерфейс GenMyModel

Продукт поставляется с плагинами для Confluence и Jira, что обеспечивает интеграцию с данными инструментами. Это важно, если они используются и в будущем модели будут интегрированы в оставшуюся часть процесса обсуждения/разработки.

Рисунок 21. Главная страница сайта Gliffy

Продукт draw.io пользователи выбирают за его простоту. После перехода на сайт draw.io в браузере, сразу откроется пустой холст, и можно начинать рисовать. Он поставляется с формами для базового моделирования UML, ER и BPMN. Тем не менее, это яркий пример инструмента, который не совсем понимает семантику того, что рисует пользователь, так что можно в основном делать все и создавать самые различные диаграммы [15].

Draw.io хорошо интегрируется с Google Drive, Dropbox, OneDrive и другими сервисами для автоматического сохранения моделей в выбранном расположении. Draw.io – программное обеспечение с открытым исходным кодом, построенное с использованием библиотеки mxGraph.

Интерфейс программного продукта показан на рисунке 22 [15].

Рисунок 22. Интерфейс draw.io

Creately обеспечивает совместную работу в режиме реального времени. Продукт предлагает более 50 типов диаграмм и тысячи примеров для начала работы [16].

Работать можно в автономном режиме, а впоследствии синхронизировать свою работу. Единственное «но», это то, что на сегодняшний день для работы требуется установить Flash. Это является минусом, поскольку, так как Adobe планирует отказаться от Flash в будущем. Это оттолкнет потенциальных пользователей, т.к. инструмент не имеет будущего. Главная страница сайта продукта приведена на рисунке 23 [16].

Рисунок 23. Главная страница сайта Creately

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

Cacoo поддерживает диаграммы вариантов использования, последовательности, класса, активности и конечного автомата. Главная страница сайта показана на рисунке 24 [17].

UMLetino простой и бесплатный онлайн UML-инструмент для быстрого создания UML-диаграмм. Он работает в браузере и не требует установки. UMLetino основан на UMLet (доступен как самостоятельный инструмент или плагин Eclipse). Диаграммы могут быть экспортированы как XML или файлы изображений [18].

Рисунок 24. Главная страница сайта Cacoo

Несмотря на ограничения (среда моделирования явно не соответствует уровню по сравнению с графическим качеством и мощным интерфейсом некоторых других инструментов), если необходим бесплатный и простой в использовании онлайн-инструмент UML, это определенно вариант для рассмотрения. Интерфейс продукта приведен на рисунке 25 [18].

Рисунок 25. Интерфейс UMLetino

ЗАКЛЮЧЕНИЕ

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

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

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

Проектирование программного обеспечения экономических информационных систем / А.М. Вендров. – М: Финансы и статистика, 2016.
– 544 с.
Вендров А.М. Практикум по проектированию программного обеспечения экономических информационных систем / А.М. Вендров.
– М: Финансы и статистика, 2017. – 192 с.
Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. – Братск: Филиал ГОУВПО «БГУЭП», 2017. – Ч.1
– 146 с.
Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Н.Н. Заботина. – Братск: Филиал ГОУВПО «БГУЭП», 2017.
– Ч.2 – 132 с.
Мартин Ф., Кендалл С. UML Основы / Ф. Мартин, С. Кендалл.
– СПб. :Символ-Плюс, 2016. – 192 с.
Леоненков А.В. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose.
– Издательства: Интернет-университет информационных технологий, Бином. Лаборатория знаний, 2016. – 320 с.: ил.
Федоров, Н.В. Проектирование информационных систем на основе современных CASE-технологий / Н.В. Федоров. – М.: МГИУ, 2008. – 280 c.
Лешек А. М. Анализ и проектирование информационных систем с помощью UML 2.0 / А. М. Лешек. –С.-П.: Вильямс, 2008. – 244 с.
Пол Киммел. UML. Основы визуального анализа и проектирования / Киммел Пол. – НТ Пресс, 2008. – 198 с.
Леоненков А. Самоучитель UML. Эффективный инструмент моделирования информационных систем / А. Леоненков. BHV – Санкт – Петербург, 2014. – 168 с.
Леоненков А. Самоучитель UML 2 / А. Леоненков. BHV – Санкт – Петербург, 2013. – 172 с.
LucidChart. Официальный сайт: https://www.lucidchart.com/pages/ (дата обращения 30.01.2020).
GenMyModel. Официальный сайт: https://www.genmymodel.com/ (дата обращения 30.01.2020).
Gliffy. Официальный сайт: (дата обращения 30.01.2020).
Draw.io. Официальный сайт: https://www.draw.io/ (дата обращения 30.01.2020).
Creately. Официальный сайт: https://creately.com/ (дата обращения 30.01.2020).
Cacoo. Официальный сайт: https://cacoo.com/home (дата обращения 30.01.2020).
Umletino. Официальный сайт: https://www.umletino.com/ (дата обращения 30.01.2020).