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


И основные этапы ее развития



 

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

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

• перечисление условий, при которых выполняется та или иная опера­ция;

•описания самих операций, где для каждой операции определены ис­ходные данные, результаты, а также инструкции, нормативы, стандарты, кри­терии и методы оценки и т. п. (рис. 1.1).

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

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

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

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

 

 

Рис. 1.1. Структура описания технологической операции

 

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

Первый этап - «стихийное» программирование. Этот этап охватыва­ет период от момента появления первых вычислительных машин до середи­ны 60-х годов XX в. В этот период практически отсутствовали сформулиро­ванные технологии, и программирование фактически было искусством. Пер­вые программы имели простейшую структуру. Они состояли из собственно программы на машинном языке и обрабатываемых ею данных (рис. 1.2).

 

 

Рис. 1.2. Структура первых программ

 

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

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

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

 

 

Рис. 1.3. Архитектура программы с глобальной областью данных

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

Например, подпрограмма поиска корней уравнения на заданном интервале по методу деления отрезка пополам меня­ет величину интервала. Если при выходе из подпрограммы не предусмотреть восстановления первоначального интервала, то в глобальной области ока­жется неверное значение интервала. Чтобы сократить количество таких оши­бок, было предложено в подпрограммах размещать локальные данные (рис. 1.4).

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

 

 

Рис. 1.4. Архитектура программы, ис­пользующей подпрограммы с локальными

данными

 

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

В начале 60-х годов XX в. раз­разился «кризис программирова­ния». Он выражался в том, что фирмы, взявшиеся за разработку сложного программного обеспече­ния, такого, как операционные сис­темы, срывали все сроки заверше­ния проектов. Проект устаревал раньше, чем был готов к внедрению, увеличивалась его стоимость, и в ре­зультате многие проекты так никогда и не были завершены.

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

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

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

Второй этап - структурный подход к программированию (60 -70-е годы XX в.). Структурный подход к программированию представляет собой совокупность рекомендуемых технологических приемов, охватывающих вы­полнение всех этапов разработки программного обеспечения. В основе структурного подхода лежит декомпозиция (разбиение на части) сложных си­стем с целью последующей реализации в виде отдельных небольших (до 40 -50 операторов) подпрограмм.

 

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

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

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

Поддержка принципов структурного программирования была заложена в основу так называемых процедурных языков программирования. Как пра­вило, они включали основные «структурные» операторы передачи управле­ния, поддерживали вложение подпрограмм, локализацию и ограничение области «видимости» данных. Среди наиболее известных языков этой группы стоит назвать PL/1, ALGOL-68, Pascal, С.

 

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

 

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

 

Модульное программирование предполагает выделение групп подпро­грамм, использующих одни и те же глобальные данные в отдельно компили­руемые модули (библиотеки подпрограмм), например, модуль графических ресурсов, модуль подпрограмм вывода на принтер (рис. 1.5). Связи между модулями при использовании данной технологии осуществляются через спе­циальный интерфейс, в то время как доступ к реализации модуля (телу под­программ и некоторым «внутренним» переменным) запрещен. Эту техноло­гию поддерживают современные версии языков Pascal и С (C++), языки Ада и Modula.

 

Рис. 1.5. Архитектура программы, состоящей из модулей

 

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

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

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

Третий этап - объектный подход к программированию (с середины 80-х до конца 90-х годов XX в.). Объектно-ориентированное программиро­вание определяется как технология создания сложного программного обес­печения, основанная на представлении программы в виде совокупности объ­ектов, каждый из которых является экземпляром определенного типа (клас­са), а классы образуют иерархию с наследованием свойств. Взаи­модействие программных объектов в такой системе осуществляется путем передачи сообщений (рис. 1.6).

Объектная структура программы впервые была использована в языке имитационного моделирования сложных систем Simula, появившемся еще в 60-х годах XX в. Естественный для языков моделирования способ представ­ления программы получил развитие в другом специализированном языке мо­делирования - языке Smalltalk (70-е годы XX в.), а затем был использован в новых версиях универсальных языков программирования, таких, как Pascal, C++, Modula, Java.

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

 

Рис. 1.6. Архитектура программы при объектно-ориентированном программировании

 

Бурное развитие технологий программирования, основанных на объект­ном подходе, позволило решить многие проблемы. Так были созданы среды, поддерживающие визуальное программирование, например, Delphi, C++ Builder, Visual C++ и т. д. При использовании визуальной среды у програм­миста появляется возможность проектировать некоторую часть, например, интерфейсы будущего продукта, с применением визуальных средств добав­ления и настройки специальных библиотечных компонентов. Результатом визуального проектирования является заготовка будущей программы, в кото­рую уже внесены соответствующие коды.

Использование объектного подхода имеет много преимуществ, однако его конкретная реализация в объектно-ориентированных языках программи­рования, таких, как Pascal и C++, имеет существенные недостатки:

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

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

 

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

Четвертый этап - компонентный подход и CASE-технологии (с сере­дины 90-х годов XX в. до нашего времени). Компонентный подход предпо­лагает построение программного обеспечения из отдельных компонентов - физически отдельно существующих частей программного обеспечения, ко­торые взаимодействуют между собой через стандартизованные двоичные интерфейсы.

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

Компонентный подход лежит в основе технологий, разработанных на базе COM (Component Object Model - компонентная модель объектов), и тех­нологии создания распределенных приложений CORBA (Common Object Request Broker Architecture - общая архитектура с посредником обработки запросов объектов). Эти технологии используют сходные принципы и разли­чаются лишь особенностями их реализации.

 

 

 

Рис. 1.7. Взаимодействие программных компонентов различных типов

 

Технология СОМ фирмы Microsoft является развитием техноло­гии OLE I (Object Linking and Embedding - связывание и внедрение объек­тов), которая использовалась в ранних версиях Windows для создания состав­ных документов. Технология СОМ определяет общую парадигму взаимодей­ствия программ любых типов: библиотек, приложений, операционной системы, т. е. позволяет одной части программного обеспечения использовать функции (службы), предоставляемые другой, независимо от того, функционируют ли эти части в пределах одного процесса, в разных процессах на одном компьютере или на разных компьютерах (рис. 1.7). Модификация СОМ, обеспечивающая передачу вызовов между компьютерами, называется DCOM (Distributed COM - распределенная СОМ).

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

Каждый интерфейс имеет имя, начинающееся с символа « I » и глобальный уникальный идентификатор IID (Interface IDentifier). Любой объект СОМ обязательно реализует интерфейс IUnknown (на схемах этот интерфейс всегда располагают сверху). Использование этого интерфейса позволяет по­лучить доступ к остальным интерфейсам объекта.

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

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

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

• удаленный сервер - создается процессом, который работает на другом компьютере.

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

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

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

На базе технологии СОМ и ее распределенной версии DCOM были раз­работаны компонентные технологии, решающие различные задачи разработ­ки программного обеспечения.

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

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

Основными преимуществами технологии ActiveX, обеспечивающими ей широкое распространение, являются:

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

• открытость и мобильность - спецификации технологии недавно были переданы в Open Group как основа открытого стандарта;

• возможность написания приложений с использованием знакомых средств разработки, например, Visual Basic, Visual C++, Borland Delphi, Borland C++ и любых средств разработки на Java;

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

• стандартность - технология ActiveX основана на широко используе­мых стандартах Internet (TCP/IP, HTML, Java), с одной стороны, и стандар­тах, введенных в свое время Microsoft и необходимых для сохранения совме­стимости (COM, OLE).

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

MIDAS (Multitier Distributed Application Server - сервер многозвенных распределенных приложений) - технология, организующая доступ к данным разных компьютеров с учетом балансировки нагрузки сети.

Все указанные технологии реализуют компонентный подход, заложен­ный в СОМ. Так, с точки зрения СОМ элемент управления ActiveX - внут­ренний сервер, поддерживающий технологию OLE-automation. Для програм­миста же элемент ActiveX - «черный ящик», обладающий свойствами, мето­дами и событиями, который можно использовать как строительный блок при создании приложений.

Технология CORBA, разработанная группой компаний OMG (Object Management Group - группа внедрения объектной технологии про­граммирования), реализует подход, аналогичный СОМ, на базе объектов и интерфейсов СОRВА. Программное ядро CORBA реализовано для всех ос­новных аппаратных и программных платформ и потому эту технологию можно использовать для создания распределенного программного обеспечения в гетерогенной (разнородной) вычислительной среде. Организация взаимо­действия между объектами клиента и сервера в CORBA осуществляется с помощью специального посредника, названного VisiBroker, и другого специ­ализированного программного обеспечения.

Отличительной особенностью современного этапа развития технологии программирования, кроме изменения подхода, является создание и внедре­ние автоматизированных технологий разработки и сопровождения про­граммного обеспечения, которые были названы CASE-технологиями (Computer-Aided Software/System Engineering - разработка программного обеспечения/программных систем с использованием компьютерной под­держки). Без средств автоматизации разработка достаточно сложного про­граммного обеспечения на настоящий момент становится трудно осуществи­мой: память человека уже не в состоянии фиксировать все детали, которые необходимо учитывать при разработке программного обеспечения. На сего­дня существуют CASE-технологии, поддерживающие как структурный, так и объектный (в том числе и компонентный) подходы к программированию.

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

Жизненный цикл и


Поделиться:



Популярное:

  1. Delphi. Основные характеристики и терминология
  2. I. Основные профессиональные способности людей (Уровень 4)
  3. I. С учетом условия развития, особенности инфицирования и состояния иммунитета
  4. II. Виды мышления, стадии его развития.
  5. II. ОСНОВНЫЕ ЖАЛОБЫ БОЛЬНОГО
  6. II. Основные расчетные величины индивидуального пожарного риска
  7. III этап. Психологическая диагностика уровня развития ребенка. Коррекционно-развивающие занятия, способствующие успешной социализации ребенка.
  8. III. Оценка физического развития
  9. IV. Государственная политика в области управления и развития рынка недвижимости
  10. VIII. Основные направления просветительской, популяризаторской и коммуникативной деятельности библиотек
  11. XVI. Основные правовые системы современности.
  12. А третья мамочка может воспользоваться этой ситуацией для развития творческих способностей девочки. Она воспримет это, как хорошую идею, и предложит разрисовать фломастерами джинсовые брючки.


Последнее изменение этой страницы: 2016-04-11; Просмотров: 844; Нарушение авторского права страницы


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