Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология
Образование Политология Производство Психология Стандартизация Технологии


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



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

1 - Развитие языков и методов программирования не успева­ло за растущими потребностями в про­граммах. Единственным реальным способом удовлетворить эти потребности был метод многократного использования уже разработанного, протестированного и отлаженного программного обеспечения.

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

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

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

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

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

2 - Достижения в методологии программирования, в частности модульное построение программных систем и инкапсуляция информации.

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

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

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

 

Объектно-ориентированный подход к программиро­ванию

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

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

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

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

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

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

Затем появились (и продолжают появляться) другие объектно-ориентированные языки, которые определяют современное состояние программирования. Наиболее распространенными из них стали Си++, С#, Java.

 

 Компоненты объектно-ориентированного подхода

 

Рассмотрим 3 компонента объектно-ориентированного под­хода:

1. Объектно-ориентированный анализ (ООА) – это методология, при которой требования к системе воспринимаются с точки зрения классов и объектов, выявленных в предметной области. ООА направлен на создание моделей реальной действительности с использованием ОО подхода.

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

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

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

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

В данном определении можно выделить три части: 1) OOП использует в качестве базовых элементов объекты, а не алгоритмы; 2) каждый объект является экземпляром какого-либо определенного класса; 3) классы организованы иерархически. Программа будет объектно-ориентированной только при соблюдении всех трех указанных требований.

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

 

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

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

Объектная модель имеет 4 главных элемента:

1. абстрагирование;

2. инкапсуляция (ограничение доступа);

3. модульность;

4. иерархия.

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

 

5. типизация;

6. параллелизм;

7. сохраняемость.

Они называются дополнительными, так как они полезны в объектной модели, но не обязательны.

Рассмотрим эти элементы.

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

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

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

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

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

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

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

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

Разделение программы на модули позволяет частично уменьшить ее сложность, однако гораздо более важен тот факт, что разделение программы позволяет улучшить проработку ее частей. В языках программирования (Object Pascal, C++, Ada, CLOS) модуль - это самостоятельная языковая конструкция. В этих языках классы и объекты составляют логическую структуру системы, они помещаются в модули, образующие физическую структуру системы. Это свойство становится особенно полезным, когда система состоит из многих сотен классов. Модули играют роль физических контейнеров, в которых помещаются определения классов и объектов при логическом проектировании системы.

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

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

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

1. Структура модуля должна быть достаточно простой для вос­приятия;

2. Реализация каждого модуля не должна зависеть от реализации других модулей;

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

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

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

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

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

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

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

Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия «is-a») и структура объектов (иерархия «part of»).

Примеры иерархии: одиночное наследование, множественное наследование, агрегация. Иерархия «is а» определяет отношение обобщение-специализация, то отношение «part of» (часть) вводит иерархию агрегации.

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

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

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

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

Объектно-ориентированные языки программирования могут быть:

1. строго типизированными,

2. нестрого типизированными,

3. совсем не типизированными.

Это позволяет говорить о типизации, как о второстепенном элементе. Сильно типизированные языки - это такие языки, в которых все выражения проводят проверку на соответствие типов. C++ поддерживает сильную типизацию. Различают статическую типизацию (раннее связывание) и динамическую типизацию (позднее связывание). Разделение имеет отношение ко времени, когда имена связывают с типами: статическая - во время компиляции; динамическая - во время исполнения программы.

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

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

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

7. Сохраняемость (устойчивость) - это свойство объекта существовать во времени и/или пространстве, вне зависимости от процессов, породивших данный объект. Выделяют следующие виды объектов, которые обладают различной степенью, сохраняемости или устойчивости:

1. Промежуточные результаты вычисления выражений.

2. Локальные переменные вызова процедур.

3. Собственные переменные (глобальные).

4. Данные, сохраняющиеся между вызовами основной программы.

5. Данные остающиеся без изменений в различных версиях программы.

6. Данные, которые переживают создавшую их программу.

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

 Модели жизненного цикла ПО

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

Одним из ключевых понятий управления программными проектами является понятие жизненного цикла программных средств (ЖЦ).

Жизненный цикл определяется моделью и описывается в форме методологии.

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

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

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207, который определяет понятие «Жизненный цикл программной системы» так:

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

Этот стандарт описывает 17 процессов жизненного цикла, распределенных по трем категориям – группам процессов:

1. Основные процессы ЖЦ

1.1.  Заказ

1.2.  Поставка

1.3.  Разработка

1.4.  Эксплуатация

1.5.  Сопровождение

2. Вспомогательные процессы ЖЦ

2.1.  Документирование

2.2.  Управление конфигурацией

2.3.  Обеспечение качества

2.4.  Верификация

2.5.  Аттестация

2.6.  Совместный анализ

2.7.  Аудит

2.8.  Решение проблем

3. Организационные процессы ЖЦ

3.1. Управление

3.2. Создание инфраструктуры

3.3. Усовершенствование

3.4. Обучение

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

Существуют три основные модели жизненного цикла ПО:

1. Каскадная (водопадная) или последовательная

2. Итеративная и инкрементальная (эволюционная, гибридная)

3. Спиральная или модель Боэма

Рассмотрим их подробнее.

 


Поделиться:



Последнее изменение этой страницы: 2019-03-31; Просмотров: 746; Нарушение авторского права страницы


lektsia.com 2007 - 2024 год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! (0.062 с.)
Главная | Случайная страница | Обратная связь