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

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

Содержание:

ВВЕДЕНИЕ

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

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

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

Задачи исследования:

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

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

Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ. Об информации, информационных технологиях и о защите информации, содержит термины и определения, относящиеся информации, к информационным системам [1];

ГОСТ 34.003-90, устанавливающий основные термины и определения основных понятий в области ИС [2];

ГОСТ 34.601-90, устанавливающий и описывающий содержание работ этапов жизненного цикла ИС [3].

Учебник А.М. Вендрова, кандидата технических наук, описываются особенности использования CASE-технологий, частые ошибки разработчиков, а также излагается суть проектирования ИС с применением CASE-средств [4].

Учебное пособие «Проектирование информационных систем на примере методов структурного системного анализа» в авторстве кандидата физико-математических наук Инюшкиной О.Г. содержит основные понятия, относящиеся к общей теории систем, проектирования, жизненного цикла проекта по разработке ИС, а также описывает объектно-ориентированную парадигму (ООП) [5].

Учебное пособие «Основы проектирования информационных систем» И.Ю. Коцюбы, в соавторстве с Чунаевым А.В. и Шиковым А.Н. излагает основные сведения о проектировании современных ИС, описывает CASE-технологии и унифицированный язык моделирования UML [6].

Учебное пособие «Основы объектно-ориентированного моделирования с использованием языка UML» Лариной Ю.А. содержит основы объектно-ориентированного моделирования с использованием языка UML [7].

В учебном пособии кандидата технических наук Сартасова Евгения Михайловича подробно рассмотрены вопросы разработки программ с применением объектно-ориентированного программирования [8].

Учебное пособие Токмакова Г.П. изложены основные понятия ИС, приводятся примеры разработки ИС с применением CASE-технологий и UML [9].

Электронный ресурс «www.omg.org» (Официальный сайт консорциума «Object Management Group») содержит спецификацию технологии UML [10].

Официальный сайт «Sparx Systems» (электронный ресурс) содержит руководство по изучению CASE-средства Enterprise Architect [11].

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

1.1 Основные понятия

Информация – некоторые сведения, либо сообщения, имеющие произвольную форму представления [1].

Система – совокупность элементов, взаимосвязанных друг с другом, зависящая от поведения каждого отдельного элемента, при этом, целостность системы разрушается при расчленении этой взаимосвязи. [5, c.8].

Данные – разновидность информации, представленная в цифровой форме на электронном носителе, предназначенной для обработки электронными вычислительными машинами и комплексом средств автоматизации [3, c.3].

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

База данных (БД) – набор данных, упорядоченных по определенным критериям и заранее организованным правилам [3, с.3].

Автоматизированная система (АС) – система, представляющая собой совокупность средств автоматизации, выполняющую установленные функции [2].

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

Архитектура информационной системы – концепция, которая устанавливает правила моделирования и структурирования ИС, а также определяет ее функции и способ взаимосвязи объектов [6, c.10].

Жизненный цикл ИС – последовательность стадий разработки, изменения состояния, эксплуатации, сопровождения и утилизации информационной системы [2] [3, c.4]. Жизненный цикл ИС состоит из 7 этапов: подготовка, проектирование, реализация, внедрение, эксплуатация, сопровождение и снятие с эксплуатации [5, c.57] [3, c.8–9].

Техническое задание на АС – документ, определяющий технические и экономические требования к АС организационные и проектные решения по созданию АС [2].

Программное обеспечение (ПО) – комплекс упорядоченных инструкций, выполненных в определённой последовательности, предназначенных для осуществления операций с данными на основе алгоритмов [3, c.4].

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

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

1.2 Принципы объектно-ориентированного проектирования ИС

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

Рисунок 1. Класс

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

Объектно-ориентированное программирование базируется на трех принципах – инкапсуляции, наследования и полиморфизма [5, c.76].

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

Рисунок 2. Инкапсуляция. Модификаторы доступа

Класс может происходить от другого класса, включая все его основные свойства и элементы. Такой принцип построения классов называется наследованием [8, c.38] [7, c.8]. Существующий класс, на основе которого создается другой класс, называется базовым классом или суперклассом, а класс, происходящий от него, называется производным классом или дочерним классом. Данный подход позволяет существенно сократить время разработки программного обеспечения и повышает совместимость программных продуктов. Классическим примером наследования классов служит пример с геометрическими фигурами (рисунок 3).

Рисунок 3. Наследование

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

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

Точно также классы «куб» и «шар», произведенные от класса «фигура», имеют разные методы вычисления объема. Принцип полиморфизма позволяет единообразно вызывать один и тот же метод различных по типу классов, скрытых путем инкапсуляции, когда интерфейс класса абстрагирован от способа исполнения функции. В объектно-ориентированных языках программирования полиморфизм реализуется посредством переопределения унаследованных функций дочерних классов (рисунок 4) [8, c.38-43].

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

2. ОБЗОР СРЕДСТВ РАЗРАБОТКИ ИС С ПОДДЕРЖКОЙ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА

2.1 Унифицированный язык моделирования UML

Unified Modeling Language (UML) – Унифицированный язык моделирования – средство объектного моделирования, поддерживаемое большинством объектно-ориентированных CASE-средств, предназначенное для графической визуализации различных систем в процессе их моделирования, в том числе ИС, [9, c.41] [6, c.184]. Данный язык был разработан консорциумом OMG (Object Management Group) в 1994г [10, c.2] [9, c.41].

Для проектирования на языке UML на основе ООП используется три модели, определяющие уровень функционирования ИС:

Модель классов;
Модель состояний;
Модель взаимодействий;

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

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

Модель взаимодействий служит для описания взаимодействий объектов между собой на протяжении всего жизненного цикла. Изображается на диаграммах прецедентов [7, c.9].

Все элементы проектируемой ИС при помощи средства UML имеют графическое представление в виде диаграмм (рисунок 5). Для объектно-ориентированного моделирования, чаще всего, используется следующий набор диаграмм [7 c.16] [6, c.195]:

- Use case diagram (Диаграммы вариантов использования);

- Class diagram (Диаграммы классов);

- Sequence diagram (Диаграммы последовательности);

- Statechart (Диаграммы состояний);

- Activity diagram (Диаграммы деятельности);

- Deployment diagram (Диаграммы развертывания).

Рисунок 5. Типы диаграмм UML

2.1.1. Диаграммы классов

Диаграммы классов – графическое представление статических элементов структуры системы. Содержит информацию о классах, их состояниях, интерфейсах, методах и отношениях с другими классами. Изображается в виде прямоугольника, разделенного внутри при помощи горизонтальных линий на отдельные секции, где указывается имя класса (рисунок 6, а), а также могут быть добавлены атрибуты класса (рисунок 6, б) и его операции (рисунок 6, в) [7, c.20-21] [10, c.75].

Рисунок 6. Варианты представления класса на диаграмме классов

Имя класса – уникальное обозначение класса, по смыслу соответствующее его назначению. Атрибуты класса – свойства класса, представленные в виде кратких описаний, указывающих значения его отдельных переменных. Данные, содержащиеся в атрибутах класса подчиняются принципу инкапсуляции и имеют свои модификаторы доступа. Операциями класса являются процедуры (методы) класса, имеющие свои имена и модификаторы доступа [7, c.21-25] [10, c.34-37]. Отношениями между классами называются их взаимодействия и зависимости. Существует четыре типа отношения между классами: ассоциации, обобщения, агрегации и композиции [7, c.26].

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

Рисунок 7. Графическое изображение ассоциаций

Для удобства, ассоциация может снабжаться именем, которое записывается над линией ассоциации с заглавной буквы. Кратностью плюса ассоциации называется определение возможного количества объектов (экземпляров класса), связанных при помощи ассоциации с объектом, происходящим от другого класса. Графически изображается в конце линии ассоциации в виде константы, либо интервала целых чисел. Полюс ассоциации, также может иметь имя [7, c.31-33].

Обобщение (generalization) – отношение между суперклассом (базовым классом) и его дочерними классами (наследниками, подклассами). Данное отношение подчиняется принципам наследования и полиморфизма, когда дочерний класс наследует свойства и методы класса со способностью их переопределения. Также дочерний класс может иметь свои собственные свойства и методы [7, c.38] [8, c.38-42]. Графически изображается в виде полой, треугольной стрелки, при этом, как правило, классы располагаются иерархически (рисунок 8) [10, c.204].

Рисунок 8. Графическое изображение обобщения

для нескольких классов-наследников

Агрегация (aggregation) – вид отношения между классами, когда один класс является элементом (составной частью) другого класса. Агрегация иллюстрирует общую систему отношений «часть-целое», состоящую из некоторых взаимосвязанных компонентов. Графически изображается в виде прямой линии, с полым ромбом со стороны агрегата (класса-элемента) (рисунок 9) [7, c.47].

Рисунок 9. Пример отношения агрегации

Композиция (composition) – вид отношения между классами, когда один класс является элементом (составной частью) другого класса, но, в отличие от агрегации, жизненные циклы элементов и целого числа совпадают. Из этого следует, что отдельные элементы не могут существовать без целого, также как и не могут принадлежать нескольким классам одновременно. Графически изображается в виде прямой линии, с закрашенным ромбом со стороны класса-композита (рисунок 10) [7, с.48] [10, c.205].

Рисунок 10. Пример отношения композиции

2.1.2. Диаграммы вариантов использования

Диаграмма прецедентов, или диаграмма вариантов использования (use case diagram) – графическая нотация, создаваемая на этапе формирования требований к будущей системе и ее объектно-ориентированного анализа. В данной нотации изображаются отношения между элементами системы и актерами (actor), под которыми понимаются внешние сущности, взаимодействующими с данной системой, но не являющимися ее частью [10, c.645] [7, c.80]. Вариантом использования или прецедентом, называется порядок специфических действий, выполняемых ИС в случае взаимодействия с актерами. Графически изображается в виде эллипса, содержащего имя в виде краткого описания прецедента. Актеры изображаются в виде схематичной фигурки человека (проволочная фигурка), внизу которой указывается имя актера [6, c.187] [7, c.80-82].

Как правило, все варианты использования, подразумеваемые системой, заключаются на диаграмме в прямоугольник, в то время как актеры изображаются снаружи. Это связано с тем, что актер, как сущность, находится вне проектируемой ИС и не имеет определения внутренней структуры (рисунок 11) [7, c.83].

Рисунок 11. Варианты использования на примере торгового автомата

Существует четыре типа отношения между актерами и вариантами использования: ассоциации, включения, расширения и обобщения [7, c.84] .

Ассоциация (association) – обозначение взаимодействия актера с прецедентом, когда происходит инициация одного из вариантов взаимодействия. Изображается в виде сплошной линии со стрелкой, которая соединяет актера и прецедент между собой. Стрелка является необязательной и может не указываться (рисунок 12, а) [7, c.85].

Включение (include) – обозначает ситуацию, когда существует альтернативный вариант поведения одного и того же варианта использования. Графически изображается пунктирной линией со стрелкой, направленной на включаемый (целевой) прецедент, с указанием ключевого слова «include» (рисунок 12, б) [7, c.85-86] [6, c.187].

Расширение (extend) – обозначает взаимосвязь двух вариантов использования (базового и расширяющего). Поведение базового расширяется за счет добавления к нему расширяющего варианта использования, если выполнено заранее установленное для этого условие. Условие указывается в специальном примечании (note), которое изображается в виде прямоугольника, правый верхний угол которого загнут. Графически расширение изображается пунктирной линией со стрелкой, направленной на базовый (целевой) прецедент, с указанием ключевого слова «extend». Условие также соединяется с расширением пунктирной линией (рисунок 12, в) [7, c.86-87].

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

Рисунок 12. Графическое обозначение отношений между актерами и прецедентами

2.1.3. Диаграммы последовательности

Диаграммы последовательности (sequence diagram) (рисунок 13) – графическое представление потока событий, представленных во времени, упорядоченных по мере их возникновения [6, c.190]. Такие диаграммы служат для организации обмена сообщениями между актерами ИС, либо описания жизненного цикла какого-либо объекта в рамках данной ИС [7, c.95-96] [10, c.593]. Графически диаграммы последовательности представляются в виде сообщений между объектами и линией жизни объекта.

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

Для выделения участков активности какого-либо из объектов используется специальный символ – фокус управления (focus of control), называемый также спецификацией исполнения (execution specification) – вытянутый вертикальный прямоугольник, расположенный внизу активного объекта [7, c100] [10, c.594].

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

Сообщения – способ реализации взаимодействий между элементами ИС. Графически изображаются в виде стрелок, имеющих разную форму, в зависимости от типа сообщения. Порядок передачи сообщений или наступления событий во времени зависит от их расположения относительно линий жизни объектов – сообщения, которые расположены выше, передаются раньше, чем те, что расположены ниже. Распространены три основных типа сообщения: синхронные, асинхронные, и ответные сообщения [7, c.101].

Синхронные сообщения (synchCall) предназначены для вызова функций (методов), а также для обозначения вложенных потоков управления, при этом, поток управления отправителя останавливается до тех пор, пока ответное сообщение не будет получено. Графически синхронные сообщения представляются в виде прямой линии с закрашенной стрелкой (рисунок 14, а) [7, с.101].

Ответные сообщения (reply message) предназначены для выхода (возврата) из процедур или функций (методов). Графическое изображение ответного метода представляет собой пунктирную линию, оканчивающуюся открытой стрелкой с противоположной стороны от сообщения, на который производится ответ. Ответные сообщения на диаграммах часто не изображаются, поскольку принято считать, что любые вызываемые процедуры и функции, не имеющие безусловного замкнутого цикла, имеют возврат (рисунок 14, б) [10, c.471].

Асинхронные сообщения (asynchCall) – сообщения, передаваемые в произвольный момент, без ожидания ответа отправителем. В отличие от синхронных сообщений, асинхронные не вызывают остановку потока управления, а принимающая сторона не получает фокус управления. Графически асинхронные сообщения представляются в виде прямой линии с открытой стрелкой (рисунок 14, в) [7, c.102].

Рисунок 14. Графическое изображение различных типов сообщений меду объектами

2.1.4. Диаграммы состояний

Диаграммы состояний (statechart diagram) – описание поведения ИС в виде конечного автомата, являющегося по своей сути графом с вершинами, описывающими состояния ИС и дугами – переходами между этими состояниями (рисунок 15) [7, c.58].

Событием (event) называется некое происшествие, возникшее на каком-либо отрезке времени в виде внешнего воздействия [7, c.59].

Состоянием (state) называется совокупность всех свойств и значений объекта. Графическое обозначение – прямоугольник с закругленными углами, в котором указывается имя, деятельность при входе, текущая деятельность и деятельность при выходе [7, c.60].

Деятельностью (activity) называется поведение объекта на момент нахождения в каком-либо состоянии. Деятельность при входе помечается при помощи ключевого слова «entry/», текущая деятельность – с помощью «do/», а деятельность при выходе – при помощи «exit/».

Переход (transition) из одного состояния ИС в другое графически изображается в виде прямой линии с открытой стрелкой со стороны целевого состояния. Также над прямой линией может быть указана метка перехода [7, c.61].

Рисунок 15. Пример диаграммы состояний

2.1.5. Диаграммы деятельности

Диаграмма деятельности (activity diagram) – модель, определяющая последовательной действий, выполняемые элементами ИС. Графически представляется в виде блок-схем с изображением последовательной и параллельной деятельности (рисунок 16) [10, с.377].

Действие (action) – единица поведения, шаг, из последовательности которых состоит деятельность, описываемая посредством потока управления, являющегося по своей сути графом с вершинами, описывающими узлы деятельности и дугами деятельности [7, c.116].

Узел управления (activity) служит для координации потоков управления и подразделяется на:

начальный узел (initial);
финальный узел (final);
узел финального потока (flow final);
узел соединения (merge);
узел решения (decision);
узел разделения (fork);
узел слияния (join) (рисунок 16) [7, c.117].

Рисунок 16. Пример диаграммы деятельности

2.2 Использование CASE-средств при разработке ИС

2.2.1. CASE-технология. Общие сведения

CASE-технология (Computer Aided Software Engineering) – технология автоматизированной разработки и сопровождения программных средств различных ИС [9, c.221].

CASE-средства – программное обеспечение специального класса для автоматизированного проектирования ИС [9, c.9]. Представляет собой набор инструментов (программных средств) для моделирования предметной области с последующим анализом данной модели на всех этапах ее жизненного цикла. К CASE-средствам можно отнести любое ПО, способное автоматизировать процессы жизненного цикла ИС и обладающее следующими характеристиками:

- наличие графических средств для описания компонентов ИС и последующего ее документирования, а также удобного интерфейса;

- организация хранения метаданных проекта (репозитория);

- возможность интеграции отдельных компонент CASE-средств, обеспечивающая управляемость процессом создания ИС [4, c.56-57].

Классификация CASE-средств происходит по следующим признакам:

- по методологиям, применяемым при проектировании ИС и БД;

- по степени интегрированности с СУБД;

- по платформам.

Методы визуального представления и графические средства моделирования играют важную роль в выборе CASE-средств по причине трудоемкости этапов анализа и проектирования. Подобные методы помогают разработчикам изучать проектируемую, либо существующую информационную систему в наглядном виде [4, c.58].

Не смотря на удобство использования данной технологии, внедрение CASE-средств в процесс разработки ИС не всегда целесообразно. Подобное решение подразумевает долгосрочные расходы в процессе эксплуатации данных средств из-за частого обновления программного обеспечения и морального устаревания ранних версий, а также постоянных затрат на повышение квалификации и обучение пользователей. По этой причине, как правило, проводится тщательное экономическое обоснование успешного внедрения CASE-технологии среди предприятий-разработчиков [4, c.66].

2.2.2. CASE-средство Rational Rose

Rational Rose – объектно-ориентированное CASE-средство, продукт компании Rational Software Corporation, который предназначается для автоматизации проектирования ИС, с поддержкой целого ряда промышленных языков программирования и создания проектной документации [4, c.112].

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

- Репозиторий;

- Графический интерфейс пользователя;

- Браузер проекта;

- Средство контроля проекта;

- Средство обнуления статистики;

- Генератор документов.

Репозиторий Rational Rose выполнен в виде объектно-ориентированной базы данных. Браузер играет роль «навигатора» по проекту и способен перемещаться по иерархиям классов, а также переключать виды диаграмм. В процессе проектирования и развития проекта есть возможность обнаружения и устранения ошибок за счет средств контроля и сбора статистики. [4, c.113].

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

Генератор документов предназначен для формирования отчетов на основе информации, хранящейся в базе данных репозитория и способен автоматически создавать следующие документы:

- Диаграммы классов;

- Диаграммы модулей;

- Диаграммы состояний;

- Диаграммы процессов;

- Диаграммы сценариев;

- Спецификации атрибутов, операций, классов и объектов;

- Модель разрабатываемой ИС [4, c.114].

Rational Rose может функционировать на платформах Windows, Unix, Solaris, SunOS, HP UX и AIX [4, c.115].

2.2.3. CASE-средство Enterprise Architect

Enterprise Architect – продукт компании «Sparx Systems», объектно-ориентированное CASE-средство, предназначенное для UML-моделирования [11].

Данное программное обеспечение обладает следующим функционалом:

- Репозиторий;

- Графический интерфейс пользователя (см. приложение 1) [11];

- Поддержка популярных промышленных языков программирования;

- Средство контроля проекта;

- Генератор документов [11].

Диаграммы создаются на основе шаблонов UML 2.0, с возможностью загрузки UML профилей. Данное CASE-средство поддерживает следующие языки программирования: С++, С#, Java, VB, VB.NET, Delphi, PHP; Репозиторий организован в виде объектно-ориентированной базы данных, на основе содержания которой возможна генерация документов в формате HTML и RTF. База данных Enterprise Architect может интегрироваться с MySQL, SQL Server, Oracle9i. Предусмотрена многопользовательская работа, имеется автоматизированный интерфейс поддержкой макросов [11].

Существует три редакции Enterprise Architect:

- EA Desktop Edition, разработана для одиночных разработчиков и

бизнес-аналитиков с ограниченным функционалом. В данной редакции отсутствуют некоторые функции, такие как импорт и экспорт программного кода и DDL и интерфейс Active X;

- EA Professional Edition – полнофункциональная редакция;
- EA Corporate Edition – является самой полной редакцией,

предназначенной для групповой работы с авторизацией пользователей и поддержкой интеграции распространенных разновидностей баз данных сторонних разработчиков [11].

ЗАКЛЮЧЕНИЕ

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

К преимуществам объектно-ориентированного подхода можно отнести следующее:

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

Недостатками объектно-ориентированного подхода при разработке ИС могут служить следующие факторы:

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

Федеральный закон Российской Федерации от 27 июля 2006 г. N 149-ФЗ. Об информации, информационных технологиях и о защите информации.
Гост 34.003-90 Автоматизированные системы. Термины и определения. Дата введения 01.01.1992. // Опубликован: М.:Стандарт-информ, 2009 год. Официальное издание.
Гост 34.601-90 Автоматизированные системы. Стадии создания. Дата введения 01.01.1992. // Опубликован: М.: Стандартинформ, 2009 год. Официальное издание.
Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 2015. – 176 с.
Инюшкина, О.Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина, Екатеринбург: «Форт-Диалог Исеть», 2014. 240 с.
Коцюба, И.Ю. Основы проектирования информационных систем. Учебное пособие / Коцюба И.Ю., Чунаев А.В., Шиков А.Н. – СПб: Университет ИТМО, 2015. – 206 с.
Ларина, Ю. А. Основы объектно-ориентированного моделирования с использованием языка UML: учебное пособие / Ю. А. Ларина; Яросл. гос. ун-т им. П. Г. Демидова. – Ярославль : ЯрГУ, 2010. – 151 с.
Сартасов, Е. М. Объектно-ориентированное программирование: учебное пособие / Е.М. Сартасов. – Челябинск: Издательский центр ЮУрГУ, 2014. – 54с.
Токмаков, Г.П. CASE-технологии проектирования информационных систем: учебное пособие / Г.П. Токмаков. – Ульяновск: УлГТУ, 2018. − 224 с.
Официальный сайт «Object Management Group» // Unified Modeling Language specification version 2.5 (Спецификация UML). [Электронный ресурс]. URL: https://www.omg.org/spec/UML/2.5 (Дата обращения: 09.12.2018г.)
Официальный сайт «Sparx Systems» // Enterprise Architect [Электронный ресурс]. URL: https://sparxsystems.com/products/ea/index.html (Дата обращения: 09.12.2018г.)

Приложение 1

Графический интерфейс Enterprise Architect

(продолжение)

Графический интерфейс Enterprise Architect

(продолжение)