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

Содержание:

Введение

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

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

Объектом исследования является технология разработки программного обеспечения.

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

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

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

- анализ эволюции развития подходов к разработке программного обеспечения;

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

- анализ основных принципов разработки приложений с использованием ООП;

- анализ стадий разработки проектов с использованием ООП;

- анализ средств разработки приложений с использованием ООП.

1.Структурные элементы объектно-ориентированного программирования

1.1. История развития технологий разработки программ

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

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

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

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

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

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

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

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

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

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

- Построением языка программирования, содержащего как можно больше типов данных, и выбором для каждого класса задач некоторого подмножества этого языка. Такой язык иногда называют языком-оболочкой. На роль языка-оболочки претендовал язык ПЛ/1, оказавшийся настолько сложным, что так и не удалось построить его формализованное описание. Отсутствие формализованного описания, однако, не помешало широкому применению ПЛ/1 как в Западной Европе, так и в СССР.

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

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

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

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

Объектный подход использовался в языках программирования Simula, Smalltalk, C++, Object Pascal. Данный подход предполагает использование моделей данных типа «Сущность - Связь».

Концептуальная основа объектно-ориентированного подхода включает следующие элементы [7]:

• алгоритмы абстрагирования (abstraction);
• алгоритмы инкапсуляции (encapsulation);
• принципы модульности (modularity);
• принципы иерархичности (hierarchy).

Помимо основных применяются также дополнительные элементы разработки программ, не являющиеся в отличие от основных строго обязательными [4]:

• принципы типизации (typing);
• принципы параллелизма (concurrency);
• принципы устойчивости (persistence).

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

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

1.2.1 Объектно-ориентированный подход

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

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

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

Параллелизм – свойство объектов, связанное с нахождением в активном либо пассивном состоянии, связанное с различением активных и пассивных объектов между собой.

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

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

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

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

Рисунок 1 – Схема принципов ООП

Семантика – включает описание смысла программы с позиции ее исполнения компьютером.

Прагматика - смысл работы программы с позиции работы пользователей.

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

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

Основными задачами использования объектно-ориентированного подхода к разработке программного обеспечения являются [8]:

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

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

Существуют следующие аспекты объектно-ориентированного подхода [12]:

• разработка ПО с использованием ООП;

• реализация ПО с использованием ООП.

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

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

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

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

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

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

2.Особенности реализации ПО с использованием объектно-ориентированного подхода

2.1. Этапы жизненного цикла проекта автоматизации

Проведем выбор концепции жизненного цикла в рамках проектирование системы автоматизации с использованием ООП.

Жизненным циклом информационной системы является период создания и использования информационной системы, который охватывает различный её состояния, начиная с момента появления необходимости в ее реализации и заканчивая моментом вывода системы из эксплуатации [9, стр.20].

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

- ГОСТ 34 (ГОСТ 34.601-90 «Автоматизированные системы Стадии создания»),

- ISO 12207 «Standard for Infrmmation Technoiogy - Software Life Cycle Processes», ISO 15288 «Standard for Infrmmation Technoiogy - System Life Cycle Processes».

Стандарт ГОСТ 34.601-90 в рамках создания и развития автоматизированных систем является достаточно обобщенным, при этом предъявляет набор жестких требований к структуре жизненного цикла информационной системы, а так же к объемам, свойствам и содержаниюу проектной документации. В настоящее время данный стандарт считается устаревшим. Стандарты ISO 12207 и ISO 15288 являются международными стандартами, регламентирующими структуру жизненного цикла. Данные стандарты являются более современными, по сравнению с ГОСТ 34. Различия данных стандартов состоят в том, что ISO 12207 используется при разработке исключительно программных продуктов, а стандарт ISO 15288 нацелен на полный анализ автоматизированных систем, включая программную и аппаратную платформы. В силу этого, в данном проекте будет применен стандарт жизненного цикла ISO 12207.

Существуют следующие основные стратегии внедрения системы [10]:

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

2. "Скачок". Данная стратегия привлекательна, но не рекомендуется.

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

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

В качестве стратегии внедрения системы выбрана модель пилотного проекта.

Модель ЖЦ ИС включает в себя [18]:

1. Стадии
2. Результаты выполнения работ на каждой стадии
3. Ключевые события — точки завершения работ и принятия решений.

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

На каждой стадии могут выполняться несколько процессов, определенных в стандарте ГОСТ Р ИСО/МЭК 12207-99, и наоборот, один и тот же процесс может выполняться на различных стадиях. Соотношение между процессами и стадиями также определяется используемой моделью жизненного цикла ИС [21]

Модели жизненного цикла ИС

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

Понятие «жизненный цикл проекта» можно интерпретировать как период времени от зарождения идеи проекта до его завершения, который можно разделить на соответствующие фазы или этапы [8]:

• Стадия замысла
• Стадия разработки
• Стадия производства
• Стадия применения
• Стадия поддержки применения
• Стадия прекращения применения и списания

Не существует единого оптимального метода, позволяющего определить наиболее подходящий жизненный цикл и структуру проекта. У некоторых организаций существуют принятые принципы, согласно которым для каждого проекта подразумевается один и тот же жизненный цикл, в то время как остальные организации позволяют команде управления проектом самим выбирать жизненный цикл, наиболее подходящий для проекта [26].

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

Модели жизненного цикла [15]:

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

Структура спиральной модели жизненного цикла программного обеспечения приведена в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99 Информационная технология. Процессы жизненного цикла программных средств [14].

Рисунок 2 - Спиральная модель

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

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

Каждый виток разбивается на секторы [20, c.36]:

• Определение перечня целей
• Оценивание вероятности рисков
• Осуществление разработки и тестирования
• Планирование

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

Главная задача - как можно быстрее показать Заказчику системы работоспособный продукт, таким образом активизируя процесс уточнения и дополнения требований.

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

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

Таблица 1 - Ожидаемые риски на этапах жизненного цикла

№ этапа	Этап жизненного цикла	Название риска	Меры противодействия
1	Предпроектная стадия	Риск персонала со стороны заказчика и исполнителя Риск неполноты сбора информации	Документирование рисков, включение в договор моментов неполного сбора информации
2	Проектирование	Риск принятия неверных проектных решений Риск неверного планирования Стоимостной риск Форс - мажор	Экспертиза технических заданий совместно ИТ, экономическими и профильными службами, страхование
3	Разработка	Риск персонала Технический риск	Тестирование на всех стадиях разработки, экспертиза разрабатываемого ПО на всех этапах создания, работа в команде
4	Внедрение	Риск персонала Технический  и программный риск	Тестирование на всех стадиях внедрения, экспертиза ПО на всех этапах создания, работа в команде
5	Эксплуатация и сопровождение	Технические риски Риск персонала	Работа в команде, юридическое обеспечение договоров

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

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

В качестве мер по предотвращению рисков подобного рода можно рассматривать [2, стр.30]:

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

В качестве мерами по предотвращению обозначенных выше рисков можно рассматривать [2, стр.15]:

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

В качестве мер предотвращения данных обстоятельств можно рассматривать следующие [4, стр.39]:

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

Этого можно избежать следующим образом [1, стр.76]:

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

Этого можно избежать, путем реализации следующих идей:

• проведение обучения персонала работы с системой;
• составление плана внедрения ИС;
• доведение до персонала смысла внедрения автоматизированной системы;
• активное вовлечение высшего руководства;
• организация системы поощрений использующего систему персонала заказчика.
  • Технический риск:
• потеря данных при внедрении ИС;
• возможный отказ технического оборудования при внедрении ИС;
• ошибки в программе, вызывающие простой системы;
• невозможность осуществления требуемых действия, «зависание» программы;
• использование вредоносных программ (вирусы, черви, трояны, логические бомбы), использование в корыстных целях найденных ошибок;
• приостановка деятельности третьего лица (например, провайдера Интернет услуг);

В качестве мер по предупреждению данных рисков можно рассматривать [2, стр.56]:

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

2.2. Анализ сред разработки, использующих объектно-ориентированный подход

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

Нижеописанные характеристики сред программирования приведены в работе [13].

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

Таблица 1 - Параметры сред программирования

№	Характеристики	Средства разработки
		РНР	1С: Предприятие	Visual Studio	Embarcadero Delphi XE10
1.	Режим создания приложений	Интерпретатор	Интерпретатор	Компилятор	Компилятор
2.	Язык программирования	РНР	1С: Предприятие	С#, VB.NET	Delphi
3.	Система	Закрытая	Закрытая	Открытая	Открытая
4.	Поддерживаемые СУБД	MySQL,Oracle, MS SQL, DB2, IBM и др.	Встроенный формат данных, возможность подключения к MySQL, MS SQL	Поддержка форматов SQL,MDB cиспользованием DB-библиотеки, ODBC	Работа с СУБД через внешние данные (ADO), использование BDE
5.	Создание приложений в режиме мастера	-	+	+	+
6.	Динамическая реализация форм ввода, возможность обработки сообщений	+	+	+	+
7.	Стандарт реализации приложения	-	-	каркасный (мастер)	компонентный (мастер)
8.	Технология	Меню, отчетов (drag-and-drop). Работа с построителями экранов, , классами	Разработка интерфейсов в режиме Конфигуратора	Редактор ресурсов, Редактор классов (drag-and-drop)	Редактор объектов (drag-and-drop)
9.	Реализация печатных форм	-	Встроенный	Внешний	Объект Report и возможность экспорта в Excel
10	Работа с исключениями	Процедура	Процедура	Объект	Объект
11	Генерация программного кода из CASE Rational Rose	+	-	+	-

Наиболее распространенной средой разработки приложений с использованием ООП является MS Visual Studio по следующим показателям [12]:

- соответствие возможностей среды разработки системным требованиям;

- возможности работы с различными СУБД;

- совместимость с фреймворками;

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

Выбор СУБД при проектировании системы управления заявками пользователей производится исходя из следующих характеристик:

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

- наличие сетевых решений с соответствующими уровнями безопасности;

- соответствие нагрузки на СУБД специфике предметной области и ИТ-инфраструктуры компании.

- подключение к СУБД из большинства сред разработки без необходимости установки драйверов для обеспечения совместимости;

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

- оценка критериев "цена - качество".

Сравнительные характеристики СУБД, которые могут быть использованы в разработках ПО с использованием ООП, приведены в таблице 2

Таблица 2 - Сравнительные характеристики СУБД

Сравнительные характеристики	MS SQL Server	Oracle	MS Access
Средства администрирования	Хорошо	Приемлемо	нет
Графический инструментарий работы с БД	Отлично	Хорошо	Хорошо
Простота в обслуживании	Отлично	Отлично	Отлично
Механизмы управления данными	Хорошо	Отлично	Хорошо
Возможность работы с несколькими ЦП	Приемлемо	Отлично	Хорошо
Функции по соединению и выбору индексов	Отлично	Отлично	Хорошо
Совместный доступ к системе	Хорошо	Отлично	Ограничено
Работа с мультимедиа-даными	Ограничено	Отлично	Ограничено
Подключение к Web - сервисам	Приемлемо	Отлично	Приемлемо
Создание триггеров	Отлично	Отлично	Нет
Текстовый поиск	Приемлемо	Отлично	Хорошо
Технологии функциональной совместимости	Приемлемо	Хорошо	Хорошо
Возможность сопряжения с другими БД	Приемлемо	Приемлемо	Хорошо
Единая аутентификация	Приемлемо	Хорошо	Нет
Кроссплатформенность	Ограничено	Хорошо	Нет
Наличие средств программирования	Хорошо	Отлично	Отлично
Работа с хранимыми процедурами	Хорошо	Отлично	Ограничено
Встроенный язык программирования	Приемлемо	Хорошо	Отлично
Построение баз данных	Хорошо	Отлично	Отлично
Поддержка SQQL	Отлично	Отлично	Отлично
Работа с объектно-ориентированными системами	Приемлемо	Отлично	Приемлемо
Репликации	Отлично	Отлично	-
Сервисы тиражирования	Отлично	Приемлемо	-
Сервисы распределенной обработки транзакций	Отлично	Отлично	-

Наиболее существенными показателями при сравнении СУБД являются эксплуатационные характеристики, например, параметры надежности, высокой готовности, производительности, масштабируемости. В таблице 14 показан сравнительный анализ рассмотренных СУБД по данным показателям, выполненный на основе использования метода экспертных оценок. Каждому из показателей была присвоена оценка по 10-бальной шкале.

Таблица 3 - Экспертная оценка многопользовательских СУБД

СУБД	Производительность	Конкурентный доступ	По количеству пользователей	поддержка больших БД	Готовность
Microsoft SQL Server	7	8	6	7	8
Oracle	8	8	7	10	10
MS Access	3	-	-	-	-

Таким образом, по итогам проведенного анализа баз данных, можно сделать выводы:

- использование Oracle эффективно при работе с промышленными СУБД в многопользовательском режиме с необходимостью обработки больших массивов данных;

- В СУБД MS Access реализован режим совместного доступа при небольшом количестве пользователей;

- MS SQL Server соответствует поставленным задачам по характеристикам производительности, совместимости, наличию средств управления и обеспечения информационной безопасности;

- Создание промышленных баз данных из разработанного в данной работе прототипа возможно путем экспорта данных в многопользовательскую СУБД.

Заключение

В данной работе проведен анализ принципов разработки программного обеспечения с использованием ООП.

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

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

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

Список использованных источников

1. Иванова Л. Н. Объектно-ориентированный подход в разработке приложений: учебное пособие / Л. Н. Иванова. - Новосибирск: Сибирский институт управления - филиал РАНХиГС, 2016. – 197с.
2. Базаров Т. Ю. Основы программирования: учебник / Т.Ю. Базаров. - 15-е изд., стер. - Москва : Академия, 2018. – 314с.
3. Мелихова Н. В. Объектно-ориентированное программирование: учебное пособие / Н. В. Мелихова. - Челябинск : Издательство Челябинского государственного университета, 2014. - 214 с.
4. Ахметова А. В. Информационные технологии в документационном обеспечении управления / А. В. Ахметова. - Комсомольск-на-Амуре: ФГБОУ ВПО "КнАГТУ", 2014. - 142 с.
5. Щеглов, Ю.А. Информационные системы и процессы /Ю.А. Щеглов, д.т.н. - Новосибирск: НИНХ, 2015. - 251 с.
6. Задорожный, В.Н. Информационные технологии и автоматизация управления / В. Н. Задорожный. - Омск : Изд-во ОмГТУ, 2016. - 269 с.
7. Баранов В. В., Горошко И. В., Лебедев В. Н. Информационные технологии управления и организация защиты информации: учебник / В. В. Баранов, И. В. Горошко, В. Н. Лебедев и др. - Москва: Академия управления МВД России, 2018. - 453 с.
8. Лебедева С. В. Проектирование информационных систем. Работа с MS SQL Server : учебное пособие / С. В. Лебедева. - Санкт-Петербург: ФГБОУВПО СПГУТД, 2014. - 120 с.
9. Некрасов В. Н., Архипова О. И. Информационно-коммуникационные технологии управления и особенности разрешения их противоречий: монография / В. Н. Некрасов, О. И. Архипова. - Ростов-на-Дону: Профпресс, 2014. – 105 с.
10. Бабиева Н. А., Раскин Л. И. Проектирование информационных систем : учебно-методическое пособие / Н. А. Бабиева, Л. И. Раскин. - Казань : Медицина, 2014. – 200с.
11. Стрекалова Н. Б., Маризина В. Н. Современные технологии в профессиональной подготовке специалистов: учебное пособие / Н.Б. Стрекалова, В.Н. Маризина. - Тольятти: Тольяттинская академия управления, 2016. - 128 с.
12. Гагарин А. Г., Костикова А. В. Проектирование информационных систем: учебное пособие / А. Г. Гагарин, А. В. Костикова. - Волгоград: ВолГТУ, 2015. – 57 с.
13. Сурушкин М. А. Анализ предметной области и проектирование информационных систем с примерами : учебное пособие / М. А. Сурушкин. - Белгород : НИУ "БелГУ", 2019. - 155 с.
14. Инюшкина О. Г. Проектирование информационных систем : (на примере методов структурного системного анализа) : учебное пособие / О. Г. Инюшкина. - Екатеринбург : Форт-Диалог Исеть, 2014. - 240 с.
15. Баранников Н. И., Яскевич О. Г. Современные проблемы проектирования корпоративных информационных систем / Н. И. Баранников, О. Г. Яскевич; ФГБОУ ВПО "Воронежский гос. технический ун-т". - Воронеж: Воронежский государственный технический университет, 2014. - 237 с.
16. Деменков, М.Е. Современные методы и средства проектирования информационных систем: учебное пособие / М. Е. Деменков, Е. А. Деменкова. - Архангельск: САФУ, 2015. – 89с.
17. Баранчиков А. И. Синтез информационных структур хранения данных на основе анализа предметных областей: А. И. Баранчиков. - Рязань: РГУ, 2014. - 229 с.
18. Шичкина Ю. А. Методы построения схемы и выполнения запросов в базах данных / Ю. А. Шичкина. - Санкт-Петербург : Изд-во СПбГЭТУ "ЛЭТИ", 2016. - 205 с.
19. Микляев И. А. Универсальные объектно-ориентированные базы данных на реляционной платформе : монография / И. А. Микляев. – Архангельск. : ИД САФУ, 2014. – 223с.
20. Ратманова И. Д. Базы данных : учебное пособие / И. Д. Ратманова. - Иваново: Ивановский государственный энергетический университет, 2014. - 159 с.