Размещено на http://www.allbest.ru/

Тезисы лекционных материалов

Лекция 1. Введение. Цели и задачи дисциплины "Технология программирования". Роль вычислительной техники в информационных системах. Компьютеризация учебного процесса. Общие сведения. Введение в систему программирования

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

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

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

Определение технологии конструирования программного обеспечения

Технология конструирования программного обеспечения (ТКПО) -- система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах [64], [69], [71].

Различают методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

* планирование и оценка проекта;

* анализ системных и программных требований;

* проектирование алгоритмов, структур данных и программных структур;

* кодирование;

* тестирование;

* сопровождение.

Основные этапы решения задачи на ЭВМ могут быть представлены следующими пунктами (рис. 1):

Методы автоматизации программирования. Различают методы, средства и процедуры ТКПО.

Методы обеспечивают решение следующих задач:

* планирование и оценка проекта;

* анализ системных и программных требований;

* проектирование алгоритмов, структур данных и программных структур;

* кодирование;

* тестирование;

* сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как

Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

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

* порядок применения методов и утилит;

* формирование отчетов, форм по соответствующим требованиям;

* контроль, который помогает обеспечивать качество и координировать изменения;

* формирование "вех", по которым руководители оценивают прогресс.

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

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

Рассмотрим наиболее популярные парадигмы ТКПО.

Классический жизненный цикл

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

Охарактеризуем содержание основных этапов.

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

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

Рисунок -1.1.Классический жизненный цикл разработки ПО.

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

Анализ требований относится к программному элементу -- программному обеспечению. Уточняются и детализируются его функции, характеристики и интерфейс.

Проектирование состоит в создании представлений:

* архитектуры ПО;

* модульной структуры ПО;

* алгоритмической структуры ПО;

* структуры данных;

* входного и выходного интерфейса (входных и выходных форм данных). Все определения документируются в спецификации анализа. Здесь же завершается решение задачи планирования проекта.

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

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

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

Сопровождение -- это внесение изменений в эксплуатируемое ПО. Цели изменений:

* исправление ошибок;

* адаптация к изменениям внешней для ПО среды;

* усовершенствование ПО по требованиям заказчика.

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

Как и любая инженерная схема, классический жизненный цикл имеет достоинства и недостатки.

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

Недостатки классического жизненного цикла:

реальные проекты часто требуют отклонения от стандартной последовательности шагов;

цикл основан на точной формулировке исходных требований к ПО (реальное начале проекта требования заказчика определены лишь частично);

результаты проекта доступны заказчику только в конце работы.

Макетирование

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

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

Основная цель макетирования -- снять неопределенности в требованиях заказчика.

Макетирование (прототипирование) -- это процесс создания модели требуемого программного продукта.

Модель может принимать одну из трех форм:

бумажный макет или макет на основе ПК (изображает или рисует человекомашинный диалог);

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

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

Как показано на рис. 1.2, макетирование основывается на многократном повторении итераций, в которых участвуют заказчик и разработчик.

Рисунок - 1.2 Макетирование

Последовательность действий при макетировании представлена на рис. 1.3.

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

Затем выполняется быстрое проектирование. В нем внимание сосредоточивается на тех характеристиках ПО, которые должны быть видимы пользователю.

Рисунок - 1.3. Последовательность действий при макетировании

Быстрое проектирование приводит к построению макета.

Макет оценивается заказчиком и используется для уточнения требований к ПО.

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

Достоинство макетирования: обеспечивает определение полных требований к ПО.

Недостатки макетирования:

* заказчик может принять макет за продукт;

* разработчик может принять макет за продукт.

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

Спиральная модель

Спиральная модель -- классический пример применения эволюционной стратегии конструирования.

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

На рисунке 1.4. представлена спиральная модель.



Рисунок-1.4. Спиральная модель

7 -- начальный сбор требований и планирование проекта; 2 -- та же работа, но на основе рекомендаций заказчика; 3 -- анализ риска на основе начальных требований; 4 -- анализ риска на основе реакции заказчика; 5 -- переход к комплексной системе; б -- начальный макет системы; 7 -- следующий уровень макета; 8 -- сконструированная система; 9 -- оценивание заказчиком

Как показано на рис. 1.4, модель определяет четыре действия, представляемые четырьмя квадрантами спирали.

Планирование -- определение целей, вариантов и ограничений.

Анализ риска -- анализ вариантов и распознавание/выбор риска.

Конструирование -- разработка продукта следующего уровня.

Оценивание -- оценка заказчиком текущих результатов конструирования.

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

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

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

Достоинства спиральной модели:

наиболее реально (в виде эволюции) отображает разработку программного обеспечения;

позволяет явно учитывать риск на каждом витке эволюции разработки;

включает шаг системного подхода в итерационную структуру разработки;

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

Недостатки спиральной модели:

новизна (отсутствует достаточная статистика эффективности модели);

повышенные требования к заказчику;

трудности контроля и управления временем разработки.

Компонентно-ориентированная модель

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

Литература 3 [10-100]

Контрольные вопросы

Дайте определение технологии конструирования программного обеспечения.

Какие этапы классического жизненного цикла вы знаете?

Охарактеризуйте содержание этапов классического жизненного цикла.

Объясните достоинства и недостатки классического жизненного цикла.

Чем отличается классический жизненный цикл от макетирования?

Какие существуют формы макетирования?

Чем отличаются друг от друга стратегии конструирования ПО?

Укажите сходства и различия классического жизненного цикла и инкрементной (макетирования) модели.

9.Объясните достоинства и недостатки инкрементной модели.

Чем отличается модель быстрой разработки приложений от инкрементной модели?

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

Укажите сходства и различия спиральной модели и классического жизненно го цикла.

В чем состоит главная особенность спиральной модели?

Чем отличается компонентно-ориентированная модель от спиральной модели и классического жизненного цикла?

Перечислите достоинства и недостатки компонентно-ориентированной модели.

Лекция 2. Методология программирования. Этапы и уpовни pазpаботки пpогpамм. Техническое задание на pазpаботку пpогpамм. Этап технического пpоектиpования пpогpамм. Разpаботка стpуктуpных схем алгоpитмов. Оpганизация данных. Разpаботка стpуктуpы пpогpамм и внутpипpогpаммного интеpфейса

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

Разработка структурных схем алгоритмов

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

Пример. Вычислить значение

y=ax3+bx2+cs+d

Прямое решение

Y=A*X**3+B*X**2+C*X+D

Более эффективное решение

Y=A*X*X*X +B*X*X +C*X+D (повторное умножение более эффективно, чем возведение в степень)

Дальнейшее упрощение алгоритма - разложение полинома (методом Горнера):

y=ax3+bx2+cs+d=x(ax2+bx+c)+d=x(x(ax+b)+c)+d

В этом случае требуется выполнить по три действия сложения и умножения.

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

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

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

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

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

Тесты. Разрабатываются по схеме и техническому заданию на программу. Определяя количество тестов, необходимо следить, чтобы проверялись все возможные варианты внешнего эффекта алгоритма и чтобы все ветви схемы были пройдены минимум один раз. Для каждого теста выписываются исходные данные, результаты и те данные, которые должны выдать отладочные средства. При составлении тестов могут быть обнаружены ошибки, для корректировки которых следует вернуться к п. 5 или 4, а далее повторно пройти этапы 5, 6, 7, так как изменения в схеме программы могут привести к иной расстановке отладочных средств и иному комплекту тестов.

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

Тестирование и отладка. Записанная на языке программирования программа выполняется с тестовыми исходными данными с целью обнаружения ошибок (тестирование). Если результаты выполнения расходятся с ожидаемыми, то принимаются меры к поиску причин расхождения (отладка). Для исправления ошибки необходимо перепрограммировать какую-то часть программы, т.е. вернуться к п. 4 или 5.

Счет. По завершении отладки из программы удаляются отладочные средства, программа записывается в оттранслированном виде на магнитные носители. Затем программа поступает в эксплуатацию.

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

Таковы основные этапы разработки программы.

Модели качества процессов конструирования

В современных условиях, условиях жесткой конкуренции, очень важно гарантировать высокое качество вашего процесса конструирования ПО. Такую гарантию дает сертификат качества процесса, подтверждающий его соответствие принятым международным стандартам. Каждый такой стандарт фиксирует свою модель обеспечения качества. Наиболее авторитетны модели стандартов ISO 9001:2000, ISO/ IEC 15504 и модель зрелости процесса конструирования ПО (Capability Maturity Model -- СММ) Института программной инженерии при американском университете Карнеги-Меллон.

Модель стандарта ISO 9001:2000 ориентирована на процессы разработки из любых областей человеческой деятельности. Стандарт ISO/IEC 15504 специализируется на процессах программной разработки и отличается более высоким уровнем детализации. Достаточно сказать, что объем этого стандарта превышает 500 страниц. Значительная часть идей ISO/IEC 15504 взята из модели СММ.

Базовым понятием модели СММ считается зрелость компании [61], [62]. Незрелой называют компанию, где процесс конструирования ПО и принимаемые решения зависят только от таланта конкретных разработчиков. Как следствие, здесь высока вероятность превышения бюджета или срыва сроков окончания проекта.

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

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

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

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

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

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

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

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

Каждый уровень СММ характеризуется областью ключевых процессов (ОКП), причем считается, что каждый последующий уровень включает в себя все характеристики предыдущих уровней. Иначе говоря, для 3-го уровня зрелости рассматриваются ОКП 3-го уровня, ОКП 2-го уровня и ОКП 1-го уровня. Область ключевых процессов образуют процессы, которые при совместном выполнении приводят к достижению определенного набора целей. Например, ОКП 5-го уровня образуют процессы:

Ш предотвращения дефектов;

Ш управления изменениями технологии;

Ш управления изменениями процесса.

Если все цели ОКП достигнуты, компании присваивается сертификат данного уровня зрелости.

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

Литература 3 [10-100]

Контрольные вопросы

1.Назовите этапы алгоритма?

2.Разработка структурных схем, объясните.

3. Назовите модели качества создания прогрммы?

4. Назовите критерии для оценки зрелости компании?

Лекция 3. Основы технологии программирования. Методы пpоектиpования пpогpаммного обеспечения. Hисходящее и восходящее пpоектиpование пpогpамм и их сочетание. Стpуктуpное пpогpаммиpование. Модульное пpогpаммиpование. Выбоp языка пpогpаммиpования. Стиль пpогpаммиpования. Показатели качества пpогpаммиpования. Читаемость пpогpамм, комментаpии. Пpогpаммиpование с защитой от ошибок. Этап отладки и испытания пpогpамм

Понятие технологичности программного обеспечения

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

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

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

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

В его основу были положены следующие основные концепции:

нисходящая разработка;

модульное программирование;

структурное программирование;

сквозной структурный контроль.

Нисходящая и восходящая разработка программного обеспечения

При проектировании, реализации и тестировании компонентов структурной иерархии, полученной при декомпозиции, применяют два подхода:

- восходящий;

- нисходящий.

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

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

Для тестирования и отладки компонентов проектируют и реализуют специальные тестирующие программы.

Подход имеет следующие недостатки:

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

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

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

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

Нисходящий подход.

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

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

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

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

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

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

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

- обеспечение возможности выдачи результатов - модули вывода результатов должны создаваться раньше обрабатывающих;

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

- наличие необходимых ресурсов.

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

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

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

Нисходящий подход обеспечивает:

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

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

- возможность нисходящего тестирования и комплексной отладки (см гл. 9).

Структурное и "неструктурное" программирование. Средства описания структурных алгоритмов

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

Различают три вида вычислительного процесса, реализуемого программами: линейный, разветвленный и циклический.



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

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

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

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

Именно для изображения схем алгоритмов таких программ в свое время был разработан ГОСТ 19.701-90, согласно которому каждой группе действий ставится в соответствие специальный блок (табл. 1 .1). Хотя этот стандарт предусматривает блоки для обозначения циклов, он не запрещает и произвольной передачи управления, т. е. допускает использование команд условной и безусловной передачи управления при реализации алгоритма.

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

- следование - обозначает последовательное выполнение действий (рис. 2.3, а);

- ветвление - соответствует выбору одного из двух вариантов действий (рис. 2.3, б);

- цикл-пока - определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла (рис. 2.3, в).

Рисунок 2.1-Базовые алгоритмические структуры:

а- следование, б- ветвление, цикл-пока

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

- выбор - обозначает выбор одного варианта из нескольких в зависимости от значения некоторой величины (рис. 2.4, а);

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

- цикл с заданным числом повторений (счетный цикл) - обозначает повторение некоторых действий указанное количество раз (рис. 2.4, в).

Рисунок 2.2- Дополнительные структуры алгоритмов: а- выбор, б- цикл-до, в- цикл с заданным числом повторений.

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

Примечание. Слово "структурное" в данном названии подчеркивает тот факт, что при программировании использованы только перечисленные конструкции (структуры). Отсюда и понятие "программирование без go to".

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

Модули и их свойства

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

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

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

объектный.

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

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

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

Термин "модуль" стал использоваться и в смысле автономно компилируемый набор программных ресурсов. Данные модуль может получать и/или возвращать через общие области памяти или параметры.

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

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

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

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

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

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

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

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

легче разобраться в отдельном модуле и всей программе и, соответственно, тестировать, отлаживать и модифицировать ее;

меньше вероятность появления новых ошибок при исправлении старых или внесении изменений в программу, т, е. вероятность появления "волнового" эффекта;

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

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

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

Различают пять типов сцепления модулей:

по данным;

по образцу;

по управлению;

по общей области данных;

по содержимому.

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

Например, функция Мах предполагает сцепление по данным через параметры скалярного типа:

Function Max(a, b: integer).'integer; begin

if a>b then Max:=a else Max:=b; end;

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

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

Function MaxEl(a:array of integer).'integer; Var i:word; begin

MaxEl: =a[OJ;

for i:=l to High(a) do

if a[i]>MaxEl then MaxEl:=afij;

end;

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

Например, функция MinMax предполагает сцепление по управлению так как значение параметра flag влияет на логику программы: если функция MinMax получает значение параметра flag, равное true, то возвращает максимальное значение из двух, а если false, то минимальное:

Function MinMax(a, b:integer;jlag:boolean):integer; begin

if(a>b) and (flag) then MinMax: =a

else MinMax: =6; end;

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

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

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

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

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

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

Function MaxA: integer; Var i:word; begin

МахА: =a[Low(a)J; for i:= Low(a)+l to High(a) do if a[i]>MaxA then MaxA:=a[i];

end;

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

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

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

Различают следующие виды связности (в порядке убывания уровня)

функциональную;

последовательную;

информационную (коммуникативную);

процедурную;

временную;

логическую;

случайную.

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

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

При последовательной связности функций выход одной функции служит исходными данными для другой функции (рис. 2.1, б). Как правило, такой модуль имеет одну точку входа, т.е. реализует одну подпрограмму, выполняющую две функции. Считают, что данные, используемые последовательными функциями, также связаны последовательно. Модуль с последовательной связностью функций можно разбить на двa или более модулей, как с последовательной, так и с функциональной связностью. Такой модуль выполняет несколько функций, и, следовательно, егo технологичность хуже: сложнее организовать тестирование, а при выполнении модификации мысленно приходится разделять функции модуля.

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

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

Библиотеки ресурсов. Различают библиотеки ресурсов двух типов: библиотеки подпрограмм и библиотеки классов.

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

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

В качестве средства улучшения технологических характеристик библиотек ресурсов в настоящее время широко используют разделение тела модуля на интерфейсную часть и область реализации (секции Interface и Implementation - в Pascal, h и срр-файлы в C++ и в Java).

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

Документиpование пpогpамм. Составление программной документации - очень важный процесс.

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

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

Отсутствие документации любого типа для конкретного программного продукта не допустимо.

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

Литература

Контрольные вопросы

1. Назовите три основных вида модулей?

2. Что означает Библиотеки ресурсов?

3. Что такое модули и приведите их свойства?

4. Назовите виды структурного программирования?

Лекция 4. Выбоp языка пpогpаммиpования. Стиль пpогpаммиpования. Показатели качества пpогpаммиpования. Читаемость пpогpамм, комментаpии. Пpогpаммиpование с защитой от ошибок. Этап отладки и испытания пpогpамм. Документиpование пpогpамм. Виды пpогpаммной документации, установленные ГОСТом. Единая система пpогpаммной документации (ЕСПД)