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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

Задачи:

1. Сформулировать точное определение объектно-ориентрованного подхода;
2. Пояснить основную суть подхода, выделив его преимущества и недостатки;
3. Сравнить с другими подходами;
4. Привести примеры;
5. Сделать вывод из проделанной работы.

Глава 1. МЕТОДЫ И СРЕДСТВА ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1. Методы проектирования ИС

Методология построения информационных систем делится на три основных элемента:

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

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

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

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

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

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

1. Подходы к определению методов проектирования ИС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Объектные методы обладают тремя главными свойствами:

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

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

Следующий подход, который следует рассмотреть, - это подход Прозорова А.А. Классификация методов в данном подходе осуществляется на основании понятия жизненного цикла ИС, подходов к сущностной и объектной декомпозиции и сокрытии (локализации) ИС. Он включает себя такие методы, как ОМТ (Object Modeling Technique), Icam DEFinition, COMET (Concurrent Object Modeling and Architectural Design Method).

В методе ОМТ проектируемая ИС представляется в виде трех взаимосвязанных моделей:

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

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

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

Метод ОМТ ограничивается двумя фазами жизненного цикла ПО (ИС): анализом требований совместно с построением объектной модели и реализацией программной системы.

Семейство методов проектирования и нотаций IDEF основан на методологии ICAM (Integrated Computer Aided Manufacturing) и состоит из следующих представителей:

• IDEF0 - метод и нотация описания бизнес-процессов;
• IDEF1 - метод и нотация описания взаимосвязей между информационными потоками;
• IDEF1X - метод и нотация разработки реляционных баз данных;
• IDEF3 - метод и нотация описания технологических процессов;
• IDEF5 - метод и нотация описания онтологических исследований.

Метод COMET основан на методе COMADM (Concurrent Object Modeling and Architectural Design Method), не имеет с ним незначительные отличия, а именно используемой в методе COMET нотацией UML [7].

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

Основные этапы COMET:

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

1. Методы проектирования архитектур ИС

Есть два метода проектирования архитектур ИС, каждый из которых включает в себя определенные методы, свойства, специфики использования: проектирование «в малом» и проектирование «в большом». Говоря о проектировании «в малом» подразумевается проектирование подсистем, а относительно проектирования «в большом» - проектирование архитектуры.

Структура проектирования подсистем включает в себя:

• диаграммы «сущность - связь»;
• структурные карты;
• диаграммы деятельности;
• диаграммы Варнье-Орра;
• диаграммы переходов состояний;
• блок-схемы;
• схемы экранов;
• псевдокод.

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

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

• нисходящего проектирования;
• метод восходящего проектирования;
• метод расширения ядра.

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

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

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

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

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

Проектирование архитектуры для объектно-ориентированной методологии включает следующие основные методы:

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

1. Методы анализа и построения спецификаций

Структурная методология включает следующие методы ведения структурного анализа:

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

Объектно-ориентированная методология включает следующие методы ведения объектно-ориентированного анализа:

• КОК-карты (класс - ответственность - кооперация);
• диаграммы вариантов использования;
• диаграммы классов;
• диаграммы состояний;
• диаграммы деятельности;
• диаграммы последовательности.

1. Подходы к ведению анализа и проектирования

Комбинации структурных методов образуют структурные подходы. Можно выделить три группы структурных подходов на основе порядка построения модели:

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

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

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

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

Подходы используют две основные группы средств моделирования:

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

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

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

• на основе языка UML;
• Шлеер-Меллора;
• Гради Буча
• Джеймса Рамбо;
• Ивара Якобсона.

Подход на основе языка UML состоит из четырех основных фаз разработки, причем работа с диаграммами ведется в основном на второй и третьей фазах. Во время второй фазы - фазы исследования - должна быть создана модель предметной области. На третьей фазе - построения - продолжается итеративная работа с диаграммами классов и деятельности. К ним добавляются типы диаграмм, которые определяют взаимодействие: диаграммы последовательности; диаграммы кооперации.

В случае сложного поведения системы разрабатывается еще одна группа диаграмм - диаграммы состояний.

UML (Unified Modeling Language) – язык (третьего поколения) визуального моделирования, служащий для создания моделей анализа и проектирования объектно-ориентированных программных систем. Основные разработчики - Г.Буч, Дж. Рамбо, И. Джекобсон. В настоящее время - версия UML 2.0. (Рисунок 4.)

UML - стандартный язык для написания моделей анализа, проектирования и реализации объектно-ориентированных программных систем. UML используется для визуализации, спецификации, конструирования и документирования результатов программных проектов. UML - не визуальный язык программирования, но его модели транслируются в текст на языках программирования (Java, C++, Visual Basic, Ada 95, Object Pascal) и в таблицы для реляционной БД.

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

Подход Шлеер-Меллора использует три группы средств для создания модели предметной области:

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

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

Подход предлагает механизм поддержки моделей состояний. Для этого вводятся четыре архитектурных класса:

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

1. Достоинства и недостатки объектно-ориентированного проектирования

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

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

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

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

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

Пока еще нет достаточного количества примеров для оценки эффективности объектно-ориентированного программирования при разработке формальных экономических моделей типа CoCoMo или Price-S.

Недостатки объектно-ориентированного проектирования могут повлиять на характеристики системы и на начальные затраты. Рассмотрим сначала ухудшение характеристик. Существует определенная плата за посылку сообщения от одного объекта к другому, выражающаяся в некотором ухудшении быстродействия. Для тех обращений к методам, которые не могут быть реализованы статически, необходимо провести динамический поиск, чтобы найти соответствующий метод, определенный в классе, которому принадлежит объект, получающий сообщение. Опыт показывает, что обращение к методу может занимать в 1,75-2,5 раза больше времени, чем обращение к обычной подпрограмме [3, 5]. Как правило, динамический поиск оказывается нужен, примерно, в 20% случаев от общего числа обращений. Поэтому транслятор в хорошо типизированном языке часто может сам определить, какие вызовы могут быть статически реализованы, и написать код вызова подпрограммы, а не поиска метода.

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

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

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

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

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

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

Глава 2. ПРИМЕРЫ ПРОГРАММНЫХ ПРОДУКТОВ, КОТОРЫЕ МОГУТ БЫТЬ ИСПОЛЬЗОВАНЫ ДЛЯ РЕАЛИЗАЦИИ ПОДХОДА

1. CASE-технологии

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

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

Вышеприведенные факторы привели к появлению программно-технологических средств специального класса - CASE-средств, которые реализуют CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) сегодня используется в достаточно широком смысле [6]. Изначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время имеет новый смысл, охватывающий процесс разработки сложных ИС в целом. Итак, теперь под термином CASE-средства подразумеваются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО (приложений) и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

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

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

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

Согласно обзору передовых технологий, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала добрая половина всех опрошенных пользователей более чем в трети своих проектов, из них около 85% завершились успешно). Но, несмотря на все потенциальные возможности CASE-средств, существует достаточное количество их неудачного внедрения, собственно из-за которых CASE-средства и становятся "полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:

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

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

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

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

Для успешного внедрения CASE-средств организация должна обладать следующими качествами:

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

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

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

Успешное внедрение CASE-средств должно обеспечить такие выгоды как:

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

1. Пример технического проекта

Для создания MS DОS-приложений может быть использован язык программирования Visual Basic for DOS Standard, Fortran 5.1,Visual C++ for Windows. Если необходимо перенести программы на другие электронно-вычислительные машины или другие операционные платформы, выбирается среда Windows NT. При разработке программ, работающих в среде Windows, возможно применение технологии OLЕ 2.0 для создания приложений, включающих объекты других приложений. Определяется способ использования объектов: внедрение (embedding) или связывание (linking). Приложение может работать с базами данных различных СУБД, для этого служит стандартная технология интерфейса Open Database Connectivity (ODBC). Работа в режиме телекоммуникаций обеспечивается стандартной технологией Messaging Application Program Interface (MAPI) [8].

1. Пример на основе графического интерфейса

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

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

Средствами редактора диалогов Microsoft Word Dialog Editor построено диалоговое окно, обеспечивающее графический интерфейс пользователя. К числу типовых объектов управлении графического интерфейса относятся:

• метка (label) - постоянный текст, который нельзя изменять при работе пользователя с экранной формой (например, слова Фамилия Имя Отчество);
• текстовое окно (text box) – отвечает за ввод информации произвольного вида, отображения хранимой информации в базе данных (например, для ввода фамилии сотрудника);
• рамка (frame) - объединяет объекты управления в группу по функциональному или другому принципу (например, для изменения их параметров);
• командная кнопка (command button) - обеспечивает передачу управления, например, кнопки <Сanсе1> <ОК> <Отмена>; выбор режима обработки типa <Bвoд>, <Удaлeниe>, <Peдaктиpoвaниe>, <Выход> и др.;
• кнопка-переключатель <option button> - служит для альтернативного выбора кнопки из группы такого же типа кнопок (например, семейное положение);
• помечаемая кнопка <check button> - для аддитивного выбора несколько кнопок из группы однотипных кнопок (например, мероприятие для посещения);
• окно-список (list box) - содержит список альтернативных значений для выбора;
• комбинированное окно (combo box) - объединяет задачи окна-списка и текстового окна;
• линейка горизонтальной прокрутки - для быстрого перемещения внутри большого списка или текста по горизонтали;
• линейка вертикальной прокрутки - для быстрого перемещения внутри большого списка или текста по вертикали;
• окно-список каталогов;
• окно-список накопителей;
• окно-список файлов и др.

ЗАКЛЮЧЕНИЕ

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

Нельзя не согласиться со словами Джонса об объектном подходе, которые как ничто другое главным образом характеризуют его и передают самую суть: «В объектном подходе акцент переносится на конкретные характеристики физической и абстрактной системы, являющейся предметом программного моделирования… Объекты обладают целостностью, которую не следует нарушать. Объект может только менять состояние, поведение, управляться или становиться в определенное отношение к другим объектам. Объект обладает неизменными качествами, но может изменять свое состояние. Например, подъемник характеризуется тем, что может двигаться вверх и вниз, оставаясь в пределах своих направляющих… Любая модель должна учитывать эти свойства подъемника, так как они составляют его назначение» [2].

Объектно-ориентированное проектирование – это подход, основанный на представлении о том, что программную систему нужно и просто необходимо проектировать как совокупность взаимодействующих друг с другом объектов, принимая каждый объект как экземпляр определенного класса, причем классы при этом образуют иерархию. Объектно-ориентированный подход отражает топологию новейших языков высокого уровня, таких, как Smalltalk, Object Pascal, C++, CLOS, Python, Perl, Delphi и Ada [1].

Можно выделить четыре важных преимущества, полученных от использования доступных сейчас объектно-ориентированных систем:

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

Но так как на свете нет ничего идеального, у объектно-ориентированного подхода также есть и минусы:

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

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

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

1. Гради Буч Объектно-ориентированное проектирование с примерами применения // Американский журнал Journal of object-oriented programming (JOOP Jan 1991, vol.3, No 5)
2. Jones, A. 1979. The Object Model: A Conceptual Tool for Structuring Software. Operating Systems. New York, NY: Springer-Verlag, p. 8.
3. Pascoe, G. August 1986. Elements of Object-Oriented Programming. Byte, vol. 11 (8), p. 144.
4. Russo, V., and Kaplan, S. 1988. A C++ Interpreter for Scheme. Proceedings of USENIX C++ Conference Berkeley, CA: USENIX Association, p. 106.
5. Simonian, R., and Crone, M. November/December 1988. InnovAda: True Object- Oriented Programming in Ada. Journal of Object-Oriented Programming, vol. 1 (4), p. 19.
6. CASE-технологии. Современные методы и средства проектирования информационных систем. URL: http://www.codenet.ru/db/other/case/
7. Методы и средства проектирования информационных систем. Основные понятия системного анализа. URL: https://docplayer.ru/49313322-Metody-i-sredstva-proektirovaniya-informacionnyh-sistem-osnovnye-ponyatiya-sistemnogo-analiza.html
8. Методология проектирования программных продуктов. URL: http://phys.bspu.by/static/lib/inf/posob/stu_m/glaves/glava18/gl_18_1.html

ПРИЛОЖЕНИЯ

П.1. Универсальные методы

Рисунок 1. Структура виртуальных методов.

П.2. Структурно-функциональные методы

Рисунок 2. Структурно-функциональные методы.

П.3. Объектные методы

Рисунок 3. Объектные методы.

П.4. Языки визуального моделирования

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