Другое: Технология программирования

Технология программирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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