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

Методы и средства проектирования информационных систем и технологий (Основные понятия проектирования)

Содержание:

ВВЕДЕНИЕ

Информация в современном мире превратилась в один из наиболее важных ресурсов, а информационные системы стали необходимым инструментом абсолютно во всех сферах деятельности человека. В науке это системы обработки экспериментальных данных, системы математического, имитационного моделирования. В управлении государством – автоматизированные системы подсчёта результатов выборов, переписи населения. В экономике – бухгалтерские системы, расчёт бизнес-проектов. В образовании системы поддержки дистанционного обучения, например, система MegaCampus университета «Университет». Мобильная связь также поддерживаются информационными системами. Интернет — это тоже информационная система.

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

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

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

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

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

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

Глава 1. Основные понятия проектирования информационных систем

1.1 Понятие информационной системы

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

Информационная система в широком понимании относится к взаимодействию между процессами и технологией, в узком – к взаимодействию

между людьми, процессами, информацией и технологией (рис. 1.1.1).

Рисунок 1.1.1 Концепция информационной системы

Существует множество других определений информационной системы, имеющих смысл в соответствующих контекстах.

По определению стандарта ISO 12207, информационная система – это

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

По федеральному закону РФ от 27.07.06 N149-ФЗ «Об информации, информационных технологиях и о защите информации», информационная система – это совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств [[3]].

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

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

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

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

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

Целью обеспечивающих подсистем является обеспечение решения задач

функциональных подсистем информационных систем.

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

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

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

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

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

Метрологическое обеспечение – это метрологические средства и инструкции по их применению.

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

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

Математическое обеспечение – это методы решения задач управления, модели и алгоритмы. В функционирующей системе математическое обеспечение реализовано в составе программного обеспечения [[5]].

1.2 Методологические подходы к проектированию информационных систем

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

В общем смысле проектирование – это процесс создания проекта, прототипа, прообраза предполагаемого или возможного объекта, состояния.

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

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

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

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

  • структурная (процессно-ориентированная);
  • объектно-ориентированная.

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

В основе структурного подхода лежат следующие принципы:

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

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

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

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

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

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

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

Жизненный цикл информационных систем регламентируется международным стандартом ISO/IEC 12207:1995, где ISO (International Organization of Standardization) — это международная организация по стандартизации, a IEC (International Electrotechnical Commission) — международная комиссия по электротехнике. Российским аналогом является ГОСТ Р ИСО/МЭК 12207—99, который введен в действие в июле 2000 года [[7]].

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

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

Каскадная модель обеспечивает классический подход к разработке различных систем. На данной модели основан структурный подход. Эта модель широко использовалась в 1970-х — 80-х гг.

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

Рисунок 1.2.1 Каскадная модель разработки

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

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

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

На этапе тестирования выполняется проверка созданного программного обеспечения на предмет его соответствия требованиям, заявленным в техническом задании. На данном этапе привлекается команда тестировщиков.

Последний этап — сдача готового проекта.

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

Спиральная модель, в отличие от каскадной, предполагает итерационный процесс разработки информационной системы – процесс последовательной доработки «сырого» варианта системы до варианта, необходимого заказчику. При спиральной модели возрастает значение начальных этапов жизненного цикла, таких как анализ и проектирование, когда проверяется и обосновывается реализуемость технических решений путем создания прототипов. На спиральной модели основан объектно-ориентированный подход [[8]].

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

Рисунок 1.2.2 Спиральная модель разработки

Главная задача такого подхода к разработке продукта — как можно скорее создать работоспособный продукт, который можно представить пользователям для последующего внесения изменений, уточнений и дополнений. Эти изменения, как и выявленные пользователями ошибки, устраняются и тем самым пользователи, постоянно отслеживая изменения в проекте, в итоге получают завершенный продукт, максимально удовлетворяющий их потребности на современном этапе. К примеру, известное приложение WhatsApp в первых версиях имело очень много ошибок в работе, зависания, но в дальнейшем разработчики устранили серьезные недочеты.

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

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

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

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

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

2.1 Основные принципы построения объектной модели

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

Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон

Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula (1967), Smalltalk (1970-е гг.), C++ (1980-е гг.), Java (1996), С# (2002) и языком моделирования UML (1990-е гг.).

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

Составными частями объектно-ориентированного подхода, парадигмы являются:

  • объектно-ориентированный анализ;
  • объектно-ориентированное проектирование;
  • объектно-ориентированное программирование.

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

Рисунок 2.1.1

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

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

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

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

В данном определении можно выделить три части:

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

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

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

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

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

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

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

Основными механизмами объектной модели являются [[13]]:

  • абстрагирование;
  • инкапсуляция;
  • наследование;
  • полиморфизм;
  • модульность;
  • иерархия.

Все языки объектно-ориентированного программирования (C#, Java, Objective-C, Python, Swift), включая С++, основаны на этих положениях.

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

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

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

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

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

Инкапсуляция реализуется с использованием модификаторов доступа или спецификации. Модификатор доступа определяет область видимости члена класса. Например, C # поддерживает следующие спецификации [[15]]:

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

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

class NoEncapsulation

{

public double Value;

public string ValueString;

}

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

Пример реализации с использованием инкапсуляции:

class EncapsulationExample

{

private double valueDouble;

private string valueString;

public double Value

{

get { return valueDouble; }

set

{

valueDouble = value;

valueString = value.ToString();

}

}

public string ValueString

{

get { return valueString; }

set

{

double tmp_value = Convert.ToDouble(ValueString); // здесь может возникнуть исключение

valueDouble = tmp_value;

valueString = ValueString;

}

}

}

Здесь доступ к переменным valueDouble и valueString возможен только через свойства Value и ValueString. Если попытаться присвоить свойству ValueString некорректную строку и возникнет исключение в момент конвертации, то внутренние переменные останутся в прежнем, согласованном состоянии, поскольку исключение вызывает выход из процедуры.

В примере ниже на Java закрыты свойства «a» и «b» для класса A с целью предотвращения повреждения этих свойств другим кодом, которому необходимо предоставить только права на чтение.

Java

class A {

private int a;

private int b;

private void doSomething() { //скрытый метод

//actions

}

public int returnSomething() { //открытый метод

return a;

}

}

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

Наследование — это процесс, посредством которого один объект может приобретать свойства другого [[16]]. То есть, объект может наследовать основные свойства другого объекта и добавлять к ним черты, характерные только для него. Наследование позволяет поддерживать концепцию иерархии классов. Применение иерархии классов делает управляемыми большие потоки информации. Например, описание жилого дома. Дом — это часть общего класса, называемого строением. С другой стороны, строение — это часть более общего класса – конструкции, который является частью ещё более общего класса объектов, который можно назвать созданием рук человека. В каждом случае порождённый класс наследует все, связанные с родителем, качества и добавляет к ним свои собственные определяющие характеристики. Без использования иерархии классов, для каждого объекта пришлось бы задать все характеристики, которые бы его определяли. Однако при использовании наследования можно описать объект путём определения того общего класса или классов, к которому он относится, с теми специальными чертами, которые делают объект уникальным.

Полиморфизм — это свойство системы использовать объекты с одинаковым интерфейсом без информации о типе и внутренней структуре объекта. Полиморфизм позволяет одно и то же имя использовать для решения двух или более схожих, но технически разных задач. Целью полиморфизма, применительно к объектно-ориентированному подходу, является использование одного имени для задания общих для класса действий. Выполнение каждого конкретного действия будет определяться типом данных. Например, для языка Си, в котором полиморфизм поддерживается недостаточно, нахождение абсолютной величины числа требует трёх различных функций: abs(), labs() и fabs(). Эти функции подсчитывают и возвращают абсолютную величину целых, длинных целых и чисел с плавающей точкой соответственно. В С++ каждая из этих функций может быть названа abs(). Тип данных, который используется при вызове функции, определяет, какая конкретная версия функции действительно выполняется. В С++ можно использовать одно имя функции для множества различных действий. Это называется перегрузкой функций.

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

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

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

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

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

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

2.2 Языки объектно-ориентированного моделирования и программирования

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

Два самых популярных стандартных языка объектно-ориентированного моделирования – UML (The Unified Modeling Language) и SysML(The Systems Modeling Language). Существуют множество объектно-ориентированных языков программирования, такие как упомянутые ранее С++, C#. Java, на котором написаны практически все приложения под Андроид. Swift, который усердно продвигает корпорация Apple.

В рамках спиральной модели была разработана методология RAD (Rapid

Application Development, 1980 – разработка подхода, James Martin в IBM, 1991 –

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

программного обеспечения [[18]]. Методология RAD основана на использовании средств быстрой разработки приложений. При проектировании использует объектно-ориентированные методы описания предметной области.

Различные варианты итерационного подхода реализованы в большинстве современных методов [[19]]: Rational Unified Process (RUP), Microsoft Solutions Framework (MSF), XR и другие.

RUP (Rational Unified Process, компания Rational Software – подразделение IBM, 2003) – использует итеративную модель разработки, включающую четыре фазы (начало, исследование, построение, внедрение), разбитых на итерации, каждая из которых завершается получением промежуточной, но функциональной версии конечного продукта. RUP опирается на интегрированный комплекс инструментальных средств Rational Suite, в состав которого, кроме самой технологии RUP как продукта, входят такие компоненты, как:

  • Rational Rose – средство визуального моделирования (анализа и проектирования), использующее язык UML;
  • Rational XDE – средство анализа и проектирования, интегрируемое с платформами MS Visual Studio .NET и IBM WebSphere Studio Application Developer;

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

Унифицированный язык моделирования (UML) в настоящий момент является стандартом при проектировании и разработки объектно-ориентированных систем [[20]]. Модель UML — это, прежде всего, основной артефакт фазы проектирования.

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

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

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

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

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

UML – это язык конструирования. UML не является языком визуального программирования. Модели, созданные с его помощью, могут быть непосредственно переведены на различные языки программирования. Например, на такие языки, как Java, C++, С#, на таблицы реляционной базы данных или устойчивые объекты объектно-ориентированной базы данных. Понятия, которые предпочтительно передавать графически, так и представляются в UML. Однако понятия, которые лучше описывать в текстовом виде, выражаются с помощью языка программирования. Такое отображение модели на язык программирования позволяет осуществлять прямое проектирование: генерацию кода из модели UML в какой-то конкретный язык. Также возможно реконструировать модель по имеющейся реализации. Обратное проектирование не представляет собой ничего необычного. Если информацию не закодировали в реализации, то эта информация теряется при прямом переходе от моделей к коду. Поэтому для обратного проектирования необходимы инструментальные средства и вмешательство человека. Сочетание прямой генерации кода и обратного проектирования позволяет работать как в графическом, так и в текстовом представлении, если инструментальные программы обеспечивают согласованность между обоими представлениями.

UML – это язык документирования. Компания, выпускающая программные средства, помимо исполняемого кода производит и другие артефакты, такие как: требования к системе, архитектуру, проект, исходный код, проектные планы, тесты, прототипы, версии.

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

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

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

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

SysML — язык моделирования систем [[21]]. Поддерживает определение, анализ, проектирование, проверку и подтверждение соответствия широкого спектра систем. SysML фокусируется на предоставлении инженерам семантики языка моделирования, упрощающей операции проектирования.

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

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

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

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

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

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

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

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

Для описания поведенческих аспектов проектируемой системы в SysML используются обычные диаграммы UML, такие как диаграммы конечных автоматов.

SysML как и UML, — это язык моделирования, а не методология. Порядок применения SysML на практике определяет процесс, например MSF (Microsoft Solutions Framework) или XP (Extreme Programming).

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

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

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

Язык программирования С++ представляет высокоуровневый компилируемый язык программирования общего назначения со статической типизацией [[22]]. На сегодняшний день С++ является одним из самых популярных и распространенных языков. Своими корнями он уходит в язык Си. Фактически вначале C++ просто дополнял язык Си некоторыми возможностями объектно-ориентированного программирования. Впоследствии новый язык стал набирать популярность. В него были добавлены новые возможности, которые делали его не просто дополнением к Си, а совершенно новым языком программирования.

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

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

Как видно из приведенных ранее примеров C++ позволяет писать приложения в объектно-ориентированном стиле, представляя программу как совокупность взаимодействующих между собой классов и объектов. Это упрощает создание крупных и сложных программных продуктов.

Для создания программ можно использовать интегрированные среды разработки IDE, такие как Visual Studio, NetBeans, Eclipse.

Язык программирования Java. На сегодняшний момент язык Java, как и С++ является одним из самых распространенных и популярных языков программирования. Первая версия языка появилась в 1996 году в компании Sun Microsystems, которая впоследствии была поглощена компанией Oracle.

Java задумывался как универсальный язык программирования, который можно применять для различного рода задач. Текущей версией является Java 12, которая вышла в марте 2019 года [[23]]. Сегодня, Java превратилась из просто универсального языка в целую платформу и экосистему, которая объединяет различные технологии, используемые для целого ряда задач: от создания десктопных приложений до написания крупных веб-порталов и сервисов.

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

Объектно-ориентированный подход позволяет решить задачи по построению крупных, но в тоже время гибких, масштабируемых и расширяемых приложений. Java является языком с Си-подобным синтаксисом и близок в этом отношении к C/C++ и C#.

Ключевой особенностью языка Java является то, что его код сначала транслируется в специальный байт-код, независимый от платформы. Затем этот байт-код выполняется виртуальной машиной JVM (Java Virtual Machine). В этом плане Java отличается от стандартных интерпретируемых языков как PHP или Perl, код которых сразу же выполняется интерпретатором. В то же время Java не является чисто компилируемым языком, как С или С++.

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

Еще одной ключевой особенностью Java является то, что она поддерживает автоматическую сборку мусора. Это означает, что разработчику нет необходимости освобождать вручную память от ранее использовавшихся объектов, как в С++, так как сборщик мусора это сделает автоматически.

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

Язык C# и платформа .NET Core. На сегодняшний момент язык программирования C# один из самых мощных, быстро развивающихся и востребованных языков. Как и Java на нем пишутся самые различные приложения, обслуживающие ежедневно миллионы пользователей.

C# является языком с Си-подобным синтаксисом и близок в этом отношении к C++ и Java. Поэтому, если знать один из этих языков, то овладеть C# будет легче.

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

Когда говорят C#, нередко имеют в виду технологии платформы .NET (Windows Forms, WPF, ASP.NET, Xamarin). И, наоборот, когда говорят .NET, нередко имеют в виду C#. Хотя эти понятия связаны, отождествлять их неверно. Язык C# был создан специально для работы с фреймворком .NET.

Фреймворк .NET представляет мощную платформу для создания приложений. Можно выделить следующие ее основные черты [[24]].

Поддержка нескольких языков. Основой платформы является общеязыковая среда исполнения Common Language Runtime (CLR), благодаря чему .NET поддерживает несколько языков: наряду с C# это также VB.NET, C++, а также различные диалекты других языков, привязанные к .NET, например, Delphi.NET. При компиляции код на любом из этих языков компилируется в сборку на общем языке CIL (Common Intermediate Language) – своего рода ассемблер платформы .NET. Поэтому возможно сделать отдельные модули одного приложения на отдельных языках.

.NET является переносимой платформой, хотя и имеются некоторые ограничения. Последняя версия платформы на данный момент .NET Core поддерживается на большинстве современных операционных системах Windows, MacOS, Linux. Используя различные технологии на платформе .NET, можно разрабатывать приложения на языке C# для самых разных платформ – Windows, MacOS, Linux, Android, iOS.

.NET представляет единую для всех поддерживаемых языков богатую библиотеку классов. Какой бы программных продукт не собирались писать на C# -текстовый редактор, чат или сложную систему – так или иначе задействуется библиотека классов .NET.

Общеязыковая среда исполнения CLR и базовая библиотека классов являются основой для целого стека технологий, которые разработчики могут задействовать при построении тех или иных продуктов. Например, для работы с базами данных в этом стеке технологий предназначена технология ADO.NET и Entity Frame Work. Для построения графических приложений с богатым насыщенным интерфейсом – технология WPF и UWP, для создания более простых графических приложений – Windows Forms. Для разработки мобильных приложений - Xamarin. Для создания веб-сайтов - ASP.NET.

Также еще следует отметить такую особенность языка C# и фреймворка .NET, как автоматическая сборка мусора. Это значит, что в большинстве случаев не придется, в отличие от С++, заботиться об освобождении памяти. Вышеупомянутая общеязыковая среда CLR сама вызовет сборщик мусора и очистит память [[25]].

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

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

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

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

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

Недостатки:

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

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

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

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

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

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

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

Наследование ставит вопросы о повторении тестирования наследуемых операций. Например, допустим операция «А» принадлежит базовому классу, и она протестирована. Операция «В» принадлежит производному классу и вызывает операцию «А». Возникает вопрос, должна ли операция «А» тестироваться повторно.

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

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

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

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

  1. Большая российская энциклопедия. URL: https://bigenc.ru/technology_and_technique/text/3444940. (Дата обращения: 10.11.2019).
  2. Инюшкина О. Г. Проектирование информационных систем (на примере методов структурного системного анализа): учебное пособие / О.Г. Инюшкина, Екатеринбург: «Форт-Диалог Исеть», 2014. 240 с.
  3. Золотов, С.Ю. Проектирование информационных систем : учебное пособие / С.Ю. Золотов ; Министерство образования и науки Российской Федерации, Томский Государственный Университет Систем Управления и Радиоэлектроники (ТУСУР). – Томск : Эль Контент, 2013. – 88 с.
  4. КонсультантПлюс. URL: http://www.consultant.ru/document/cons_doc_LAW_61798/41021e09a57b2db1834266a1635d5a7a7a9e7ce9/. (Дата обращения: 10.11.2019).
  5. А. Б. Путилин, В. И. Калашников. Информационно-измерительная техника и технологии. 2002. – 454 с.
  6. Вендров A.M. Проектирование программного обеспечения экономических информационных систем: Учебник. — 2-е изд., перераб. и доп. - М.: Финансы и статистика, 2005. - 544 с.
  7. Ипатова, Э.Р. Методологии и технологии системного проектирования информационных систем : учебник / Э.Р. Ипатова, Ю.В. Ипатов. – 2-е изд., стер. – Москва : Флинта, 2016. – 257 с.
  8. Глотова Т. В. Объектно-ориентированная методология разработки сложных систем: Учебное пособие / Т. В. Глотова – Пенза – 2001. – 49 с
  9. Основы программирования на языках Си и C++ для начинающих. URL: http://cppstudio.com/post/439/. (Дата обращения: 20.11.2019).
  10. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. Второе издание / перевод с английского под редакцией И. Романовского и Ф. Андреева Санта- Клара, Калифорния – 1999. 359 с.
  11. METANIT.COM Сайт о программировании. URL: https://metanit.com/sharp/tutorial/3.2.php. (Дата обращения: 01.12.2019).
  12. Мухортов В. В., Рылов В. Ю. Объектно-ориентированное программирование, анализ и дизайн. Методическое пособие. Новосибирск, 2002. 108 с.
  13. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2006. – 496 с.
  14. Девятов С. С. Текст научной статьи по специальности «Компьютерные и информационные науки» №6 от 2006. Проектирование программного обеспечения с использованием стандартов UML 2.0 и SysML 1.0 – 2006. 16 с.
  15. Сафиулин Т.В. Плюсы и минусы методологии использования объектно-ориентированного подхода для разработки и тестирования информационных систем / Т.В. Сафиулин, Т.А. Серебрякова // Новое слово в науке: перспективы развития : материалы XI Междунар. науч.–практ. конф. (Чебоксары, 26 март 2017 г.) / редкол.: О.Н. Широков [и др.] – Чебоксары: ЦНС «Интерактив плюс», 2017. – С. 173-176. https://interactive-plus.ru/ru/article/117604/discussion_platform. (Дата обращения: 15.11.2019).
  16. Егорова А. А. Козлов С. А. Научный вестник МГТУ ГА, Информационные системы: Методы и средства проектирования – 2006. - №105. 9 с.
  1. Большая российская энциклопедия. URL: https://bigenc.ru/technology_and_technique/text/3444940. (Дата обращения: 10.11.2019).

  2. Инюшкина С. В. Проектирование информационных систем. Екатеринбург, 2014. С. 48.

  3. КонсультантПлюс. URL: http://www.consultant.ru/document/cons_doc_LAW_61798/. (Дата обращения: 10.11.2019).

  4. Инюшкина С. В. Проектирование информационных систем. Екатеринбург, 2014. С. 50.

  5. Золотов, С.Ю. Проектирование информационных систем. Томск. 2013. С. 52.

  6. Инюшкина С. В. Проектирование информационных систем. Екатеринбург, 2014. С. 75.

  7. Вендров A.M Проектирование программного обеспечения экономических информационных систем. 2005. С. 46.

  8. Инюшкина С. В. Проектирование информационных систем. Екатеринбург, 2014. С. 68.

  9. Путилин А. Б., Калашников В. И. Информационно-измерительная техника и технологии. 2002. С. 157

  10. Ипатова Э. Р. Методологии и технологии системного проектирования информационных систем. Москва, 2016. С. 47

  11. Глотова Т. В. Объектно-ориентированная методология разработки сложных систем. Пенза, 2001. С. 4

  12. Основы программирования на языках Си и C++ для начинающих. URL: http://cppstudio.com/post/439/. (Дата обращения: 20.11.2019)

  13. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на C++. 2-е изд.: Пер. с англ. И. Романовского и Ф. Андреева. 1999. С. 35.

  14. Вендров A.M Проектирование программного обеспечения экономических информационных систем. 2005. С. 188.

  15. METANIT.COM Сайт о программировании. URL: https://metanit.com/sharp/tutorial/3.2.php. (Дата обращения: 01.12.2019).

  16. Мухортов В. В., Рылов В. Ю. Объектно-ориентированное программирование, анализ и дизайн. Новосибирск, 2002. С. 35.

  17. Глотова Т. В. Объектно-ориентированная методология разработки сложных систем. Пенза, 2001. С. 8

  18. Вендров A.M Проектирование программного обеспечения экономических информационных систем. 2005. С. 82.

  19. Инюшкина С. В. Проектирование информационных систем. Екатеринбург, 2014. С. 74.

  20. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. Мухин Н. – М.: ДМК Пресс, 2006. C. 30 – 32.

  21. Девятов С. С. Прикладная информатика. Проектирование программного обеспечения с использованием стандартов UML 2.0 и SysML 1.0. 2006. С. 2.

  22. METANIT.COM Сайт о программировании. URL: https://metanit.com/cpp/tutorial/. (Дата обращения: 10.12.2019).

  23. METANIT.COM Сайт о программировании. URL: https://metanit.com/java/tutorial/. (Дата обращения: 11.12.2019).

  24. METANIT.COM Сайт о программировании. URL: https://metanit.com/sharp/tutorial/. (Дата обращения: 06.12.2019).

  25. METANIT.COM Сайт о программировании. URL: https://metanit.com/sharp/tutorial/. (Дата обращения: 04.12.2019).

  26. Егорова А. А., Козлов С. А. Информационные системы: Методы и средства проектирования. 2006 – С. 4.

  27. Плюсы и минусы методологии использования объектно-ориентированного подхода для разработки и тестирования информационных систем URL: https://interactive-plus.ru/ru/article/117604/discussion_platform. (Дата обращения: 15.01.2019).