План лекции Предварительные замечания > Эволюция разработки программного обеспечения Предварительные замечания icon

План лекции Предварительные замечания > Эволюция разработки программного обеспечения Предварительные замечания


Смотрите также:
План лекции Предварительные замечания Введение Генезис современного российского капитализма:...
Литература
Моделирование требований к системе 29...
Предварительные замечания...
Предварительные замечания...
Предварительные замечания...
А. И. Яковлев Предварительные замечания...
Общая характеристика лекций Замечания по лекциям каждого преподавателя > Общие замечания и...
Доклад посвящен применению теории сетей Петри для моделирования процессов разработки...
«Компетенции членов команды разработки программного обеспечения»...
«Техническое задание»...
Современная концепция образовательной области «искусство» в школе Предварительные замечания...



Загрузка...
страницы:   1   2   3   4   5   6   7   8   9   10   11
скачать

ВЫСОКОУРОВНЕВЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ

ЛЕКЦИЯ 1. ВВЕДЕНИЕ В ВЫСОКОУРОВНЕВЫЕ МЕТОДЫ ПРОГРАММИРОВАНИЯ


План лекции

1. Предварительные замечания

2. Эволюция разработки программного обеспечения

1. Предварительные замечания


Осмысленное использование высокоуровневых языков программирования и методов построения программ невозможно без глубокого понимания основ объектно-ориентированного анализа (ООА). Этот небольшой курс лекций дает возможность ознакомиться с фундаментальными понятиями одних из самых распространенных методов высокоуровнего программирования – структурным, основанным на структурной методологии, и объектно-ориентированным, основанным на методологии ООА.

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

- противопоставления структурного и объектно-ориентированного анализа;

- первичности функциональной или информационной моделей;

- диаграмм потоков данных и структурных диаграмм SADT (Struktured Analysis and Design Technique).

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

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

2. Эволюция разработки программного обеспечения


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

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

По мере того как вычислительные машины становились мощнее и надежнее, значение программного обеспечения осознавалось все большим количеством ученых и практиков. Важнейший прорыв произошел в конце 50-х годов, когда появились языки программирования высокого уровня: Фортран, Алгол и др. Появление языков программирования высокого уровня было обусловлено прежде всего тем, что написание программ без них становилось все более сложной задачей. Решив текущие проблемы, эти языки создали новые. Ускорив и упростив программирование, языки программирования существенно расширили круг задач, которые стали решаться с помощью ЭВМ. Новые задачи, более сложные, чем решавшиеся раньше, привели к тому, что имеющихся средств снова стало недостаточно для успешного их решения.

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

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

Языки, которые мы уже упоминали (Фортран, Алгол, PL/1) поддерживают процедурный стиль программирования. Программа разрабатывается в терминах тех действий, которые, она выполняет. Основной единицей программы является процедура. Процедуры вызывают другие процедуры, все вместе они работают по определенному алгоритму, который ведет к решению задачи. Алгоритм - -это точная последовательность действий для получения необходимого результата.

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

Слово «алгоритм» (algoNthmi, algorismus) произошло от латинской транслитерации имени среднеазиатского математика аль-Хорезми, который описал точную последовательность действий для вычисления наибольшего общего делителя .

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

В 60-е годы многими теоретиками и практиками было осознано, что только лишь создание новых, более совершенных языков программирования не может решить все проблемы разработки программ. Начались интенсивные исследования в области тестирования программ, организации процесса разработки программного обеспечения и др.

Первой, пожалуй, была осознана проблема ошибок. Сравнивая программирование с другими инженерными дисциплинами, многие задавались вопросом: почему можно добиться безошибочной работы радиоприемника или даже процессора ЭВМ, но чрезвычайно сложно добиться безошибочной работы программы- Нельзя ли так организовать тестирование и проверку программ, чтобы добиться 100-процентной уверенности в ее правильности-

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

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

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

Прежде всего, было необходимо создать строгое описание не только синтаксиса языка, но и смысла всех его конструкций. Если с синтаксисом принципиально проблема была решена еще в конце 50-х годов созданием формальной теории грамматики языка Хомского и способа записи грамматики Бэкуса — Каура, то с семантикой оказалось сложнее. Было разработано несколько методов описания семантик: W-грамматики, аксиоматический подход, денотационный метод, атрибутные грамматики, Венский метод описания и ряд других. С помощью этих методов было описано несколько реальных языков программирования: PL/1, Алгол-68, Паскаль и др.

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

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

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

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

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

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

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

Несмотря на провал при достижении основной цели, опыт разработки САЗЕ-средств дал очень много для развития методов программирования. Небольшая часть систем используется напрямую (например, генераторы компиляторов lex и уасс), часть идей была использована в современных средствах быстрой разработки программ (RAD, Rapid Application Development), таких, как JBuilder, Delphi, Powerbuilder и др. Кроме того, методы анализа и проектирования программ очень много унаследовали от методов, использовавшихся при разработке средств автоматизированного программирования.

По мере увеличения сложности решаемых задач и соответственно увеличения размеров программных систем все большее значение приобретали вопросы организации процесса разработки программного обеспечения. Широко известна (и не потеряла своего значения до сих пор) книга Брукса. Автор — один из руководителей разработки операционной системы OS/360 для ЭВМ IBM/360 — показал значение организации работы программистских коллективов для успеха (или провала) проекта. Ценность этой книги даже не в том, что приведены конкретные организационные структуры (например, метод хирургических бригад не нашел широкого применения), а в том, что она развеяла миф о человеко-месяцев. Механическое увеличение количества людей, работающих над программой, не ускорит процесса ее разработки.

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

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

Приведенный исторический экскурс развития методологии программирования иллюстрирует то, что все время программирование «боролось» за возможность решать все более сложные задачи, создавать все более сложные программные системы и делать это как можно быстрее. Периодически то или иное достижение объявлялось панацеей (будь то структурное программирование, САSЕ-средства или что-либо еще). С той же закономерностью оказывалось, что широко разрекламированное средство не способно решить все проблемы.




оставить комментарий
страница1/11
Дата28.09.2011
Размер0,7 Mb.
ТипЛекция, Образовательные материалы
Добавить документ в свой блог или на сайт

страницы:   1   2   3   4   5   6   7   8   9   10   11
отлично
  2
Ваша оценка:
Разместите кнопку на своём сайте или блоге:
rudocs.exdat.com

Загрузка...
База данных защищена авторским правом ©exdat 2000-2017
При копировании материала укажите ссылку
обратиться к администрации
Анализ
Справочники
Сценарии
Рефераты
Курсовые работы
Авторефераты
Программы
Методички
Документы
Понятия

опубликовать
Загрузка...
Документы

наверх