Файл: История и развитие методологии объектно-ориентированного программирования. Сферы применения).pdf

Введение

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

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

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

Основоположниками ООП являются создатели языка Simula – Нюгорт и Оле Джохан Дал. История Симулы началась в 1962 года с проекта Simulation Language. Одновременно готовились две версии. Прародителем первой стал Алгол 60. Вторая была выбрана благодаря блочной архитектуре, сокрытию данных и высокой популярности.

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

Новая версия языка была закончена в 1967 году. Он поддерживал проектирование “сверху вниз” с помощью виртуальных процедур и технологии статического и динамического связывания. Также Якоб Пелме добавил механизм сокрытия переменных. Первый законченный компилятор Симулы 67 увидел свет в 1969 году.

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

Свои идеи он смог воплотить в новом языке SmallTalk, смоделированном на Бейсике, и реализованном на ассемблере. В процессе работы Алан предложил всем знакомый термин “объектно-ориентированное программирование” (ООП).

Превзойти популярность Си Smalltalk так и не смог. Этот язык, придуманный Кеном Томпсоном и Деннисом Ритчи, добрался до ООП своим путем.

1974 год. Марвин Мински предложил идею фрейма, отделившего описание структуры объекта от его экземпляра. Фрейм стал предшественником понятия объектов в Си++

1976 год. Кинстен Нюгорн создал новый язык BETA и ввел концепцию шаблонов – более высокого уровня абстракций, в отличие от объектов.

1980 год. Бьерн Страуструп дополнил язык Си концепцией классов, основанной на фреймах и объектных механизмах Симулы. Позднее, в 1983, он дал своему творении. Окончательное название – Си++.

Первая всемирная конференция по объектно-ориентированным системам программирования, прошедшая в 1986 в Портленде, оказала влияние на Уильяма Аткинсона, инженера Apple. Через год он спроектировал систему HyperCard, которая дала начало современным визуальным средам быстрой разработки. Эффективность новой технологии оказалась настолько велика, что уже в 1989 году одиннадцать компаний основали группу OMG (Object Management Group). И первым делом она начала выработку стандарта компонентной модели CORBA (Common Object Request Broker Architecture) – набора спецификаций, определяющих способы объектно-ориентированного взаимодействия компонентов промежуточного уровня в гетерогенных средах без привязки к конкретным языкам программирования^[1].

В 1992 году вышел стандарт CORBA 1.0, определяющий ключевые аспекты функционирования CORBA-систем. В него вошли: базовое описание объектной модели, наборы программных интерфейсов поддержки, декларативный язык определения интерфейсов Interface Definition Language (IDL).

1994 год, Стандарт CORBA 2.0, в котором были исправлены недостатки. Как результат – поддерживание транзакции и понимание кодировки Unicode.

Гради Буч и Джеймс Румбах решили объединить Booch и OMT и создать на их основе новый язык – UML (Unified Modeling Language).

А в 1995 Sun Microsystems идет распространение в сети Java.

Эксперты OMG осознают не только важность объектных технологий программирования, но и острую потребность в универсальных методологических концепциях проектирования крупных систем. Секретом стабильности системы и высокой отдачи инвестиций специалисты OMG называют независимую UML-модель и приступают к созданию концепции "Архитектура, управляемая моделью" (Model Driven Architecture, MDA). В ее основу закладывается базовая платформно-независимая UML-модель системы, несколько платформно-зависимых моделей и коллекция определений программных интерфейсов. Первую реализацию этой универсальной концепции (так называемое "отображение в объектный стандарт") OMG выполнила, конечно, для CORBA.

2000 год. Microsoft анонсирует новую объектную платформу .NET и новый язык программирования C#, сочетающий лучшие свойства С++ и Java. Он был предложен Microsoft во многом в противовес Java.

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

1. СЛОЖНОСТЬ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Объектно-ориентированный подход возник в первую очередь в ответ на растущую сложность программного обеспечения. На заре компьютерной эры возможности компьютеров были ограничены и было очень трудно написать большую программу. В 60–70-е гг. использование компьютеров в повседневной жизни возросло, и стало все больше создаваться прикладных программ повышенной сложности. Наибольшее распространение в это время получило структурное проектирование по методу сверху вниз. Однако через некоторое время оказалось, что структурный подход не работает, если объем программы превышает приблизительно 100 тыс. строк. Как результат – выход проектов за рамки установленных сроков и бюджетов и их несоответствие начальным требованиям. Для решения этих проблем и стали применять объектно-ориентированный подход.

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

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

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

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

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

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

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

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

Гибкость программного обеспечения - Программирование обладает максимальной гибкостью среди технических наук. Программист, как и писатель, работает со словом, и всеми базовыми элементами, необходимыми для создания программ, он может обеспечить себя сам, зачастую пренебрегая уже существующими разработками. Такая гибкость – чрезвычайно привлекательное, но опасное качество: пользователь, осознав эту возможность, постоянно изменяет свои требования; разработчик увлекается украшательством своей системы во вред основному ее назначению. Поэтому программные разработки остаются очень кропотливым и "бесконечным" делом, а программные системы потенциально незавершенными^[3].

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

Любая сложная система, в том числе и сложная программная система, обладает следующими общими признаками^[4]:

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

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

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

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

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

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

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

4. Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных.

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

5. Любая работающая сложная система является результатом развития работавшей более простой системы.

В качестве примера назовем теорию эволюции живой природы.

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

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