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

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

Обучение созданию программы — процесс явно не простой, но доступный, тем более он значительно упростился в связи с появлением различных языков программирования для разных этапов метода написания программ. Например, на этапе анализа системных и программных требований можно использовать графическо-текстовые языки Варнье — Орра, Джексона; на этапе проектирования алгоритмов, структур данных и программных структур — языки UML, SADT и т. д. В качестве первого шага в этом направлении необходимо сделать следующее:1) произвести классификацию программ по степени сложности, так как от этого зависит применение графическо-текстовых языков;2) четко обозначить, на каком этапе применяется тот или иной метод, кратко разъяснить его на простых примерах.

В качестве критериальной единицы рассмотрим KLOC (K Lines of Code — количество строк программного кода). Если KLOC больше 0, но меньше 10 000, то программа называется простой или формализуемой, к числу таких программ относятся программы, решающие математические, физические, технические и т. д. задачи, программные разработки предполагаются строго упорядочивающими, в этих программах прогнозируется весь объем предстоящих работ. Порядок, который должен выполнять при этом человек-разработчик, чрезвычайно строг — «шаг вправо, шаг влево — виртуальный расстрел». Если KLOC больше 10 000, но меньше 100 000, программа называется программой средней степени сложности, или слабо формализуемой. К числу таких программ относятся программы, описывающие задачи, начальные условия которых уточняются по мере решения, т. е. в начале процесса определяются, по возможности, пользовательские и системные требования, оставшаяся часть создания программы выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая — реализует дополнительные возможности и т. д., пока не будет получена полная система. И наконец, если KLOC больше 100 000, программа называется программой для сложной системы, или неформализуемой. Это программы, начальные условия которых неопределены, и для части их формулировки приходится решать какие-то дополнительные задачи, т. е. система строится в виде последовательности версий, но в начале программы определены не все требования. Требования уточняются в результате разработки версий. Подготовка высококвалифицированных специалистов в области информационных технологий без такой классификации практически невозможна, так как она порождает инновационные процессы в высшей школе. Эффективность подготовки аналитиков и программистов при этом определяется уровнем компьютеризации различных сфер образовательной деятельности в университетах, поскольку их профессиональная направленность тесно связана с искусством создавать программы. После такой классификации программ необходимо отметить, что составляющими технологии создания программ для систем (средней степени сложности и сложных) являются продукты (программные системы) и процессы, обеспечивающие создание продуктов. Процессы (методологии) делятся на тяжеловесные (прогнозирующиеся) и облегченные (подвижные XP) процессы [1], каждый тип процесса (методологии) предполагает определенную стратегию.

Введение

в образовательный процесс понятия стратегии является педагогическим новшеством, способным значительно облегчить создание программного обеспечения. Различают следующие виды стратегии:1) однократная стратегия (классический жизненный цикл, водопадная стратегия) — линейная последовательность этапов создания. Представителями стратегии являются: модель классического жизненного цикла и модель макетирования. Программы для них относятся к простым, или формализуемым;2) инкрементная стратегия — в начале процесса определяются, по возможности, пользовательские и системные требования, оставшаяся часть выполняется в виде последовательности версий. Первая версия реализует часть запланированных возможностей, следующая версия реализует дополнительные возможности и т. д., пока не будет получена полная система. Представителями стратегии являются: инкрементная модель и модель быстрой разработки приложений. Программы, созданные для таких моделей, относятся к средней сложности;3) эволюционная стратегия — система строится в виде последовательности версий, но в начале процесса определены не все требования. Требования уточняются в результате разработки версий. Представителями стратегии являются: спиральная модель и компонентно-ориентированная модель, программы для них относятся к программам для сложных систем.

Для того чтобы разработать педагогическую систему, применяющую понятие стратегии, необходимо рассмотреть структуру процессов и реализующих их моделей. Разные модели реализуют различные стратегии, которые в свою очередь характеризуют определенные процессы. Известно, что в процессах различают методы, средства и процедуры. Методы обеспечивают решение следующих задач: — планирование и оценка риска;- анализ системных и программных требований;- проектирование алгоритмов, структур данных и программных структур;- кодирование;- тестирование;- сопровождение. Средства (утилиты) ТСПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного создания ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).Процедуры являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки. Процедуры определяют: — порядок применения методов и утилит;- формирование отчетов, форм по соответствующим требованиям;- контроль, который помогает обеспечивать качество и координировать изменения;- формирование «вех», по которым руководители оценивают прогресс.

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

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

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

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

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

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

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

Отметим, что для оценки риска при конструировании ПО для сложных систем существуют специальные методы, такие как: размерно-ориентированные метрики (LOC-оценки, Lines of Code), функционально-ориентированные метрики (FP-оценки, Function Points, А. Альбрехт (1979)), COCOMO 81 (Constructive Cost Model, Барри Боэм (1981)), COCOMO 95 (1995).Рассмотрим второй этап: анализ системных и программных требований. В прошлом этот этап при изучении дисциплины «Технология программирования» в высших учебных заведениях изучался как этап анализа. При этом он значился под номером первым, т. е. этапа планирования и оценки риска не было. Разделение анализа на два, появление первого этапа произошло не так давно, в связи с созданием программ для средних и сложных систем. С точки зрения обучения это был большой шаг вперед и должным образом дает возможность сформулировать структуру будущего специалиста.

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

Системный анализ проводится с целью:1) выяснения потребностей заказчика;2) оценки выполнимости системы;3) выполнения экономического и технического анализа;4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.)5) определения стоимости и ограничений планирования;6) создания системной спецификации. В системной спецификации описываются функции, характеристики системы, ограничения разработки, входная и выходная информация. Анализ требований дает возможность:1) определить функции и характеристики программного продукта;2) обозначить интерфейс продукта с другими системными элементами;3) определить проектные ограничения программного продукта;4) построить модели: процесса, данных, режимов функционирования продукта;5) создать такие формы представления информации и функций системы, которые можно использовать в ходе проектирования.

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

Среди современных информационных технологий создание проекта программы занимает особое место как в Computer Science, так и в образовательной информатике. Поэтому обратимся к третьему этапу: проектированию алгоритмов, структур данных и программных структур. Проектирование состоит в создании представлений: — архитектуры ПО;- модульной структуры ПО;- алгоритмической структуры ПО;- структуры данных;- входного и выходного интерфейса (входных и выходных форм данных).Исходные данные для проектирования содержатся в спецификации анализа, т. е. в ходе проектирования выполняется трансляция требований к ПО во множество проектных представлений. При решении задач проектирования основное внимание уделяется качеству будущего программного продукта. Проектирование — итерационный процесс, при помощи которого требования к ПС транслируются в инженерные представления ПС. Вначале эти представления дают только концептуальную информацию (на высоком уровне абстракции), последующие уточнения приводят к формам, которые близки к текстам на языках программирования. Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное проектирование. Предварительное проектирование формирует абстракции архитектурного уровня, детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого — сформировать графический интерфейс пользователя (GUI).Предварительное проектирование обеспечивает: — идентификацию подсистем;- определение основных принципов управления подсистемами, взаимодействия подсистем. Предварительное проектирование включает три типа деятельности:1) структурирование системы: система структурируется на несколько подсистем, где подсистема понимается как независимый программный компонент; определяются взаимодействия подсистем;2) моделирование управления: определяется модель связей управления между частями системы;3) декомпозиция подсистем на модули: каждая подсистема разбивается на модули; определяются типы модулей и межмодульные соединения. Этап кодирования — четвертый, один из самых изученных, — появился, как только появились компьютеры, менялись лишь языки кодирования, поэтому педагогических приемов в области программирования разработано немало. Приведем один из них.

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

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

Освоение принципов объектно-ориентированного проектирования и методов объектно-ориентированного программирования средствами языка С++ входит в задачи изучения дисциплины «Объектно-ориентированное программирование» студентами информационных специальностей.

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

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

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

Наименование темы.

• 1. Алфавит языка. Типы. Данные.Операции. Выражения
• 2. Структура простой программы. Объявления. Простые инструкции
• 3. Сложные инструкции (блок, ветвления, циклы)
• 4. Функции, прототипы. Заголовочные файлы. Макросы. Модульность. Классы памяти. Проект
• 5. Массивы и указатели. Модели памяти
• 6. Структуры, объединения. Динамические переменные. Связанный список
• 7. Классы. Конструкторы и деструкторы. Друзья
• 8. Перегрузка операций
• 9. Наследование. Полиформизм
• 10. Шаблоны
• 11. Контейнеры. Итераторы
• 12. Потоки
• 13. Визуальное программирование

А чего не может тестирование? Тестирование не может показать отсутствия дефектов (оно может показывать только присутствие дефектов). Важно помнить это (скорее, печальное) утверждение при проведении тестирования. На вводе процесса тестирования три потока:

• * текст программы;
• * исходные данные для запуска программы;
• * ожидаемые результаты.

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

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

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

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

Существуют два принципа тестирования программы:* функциональное тестирование (тестирование «черного ящика»);* структурное тестирование (тестирование «белого ящика»).И наконец, последний из этапов — этап сопровождения, его также нет в учебных планах университетов, однако необходимость обучения сопровождению не вызывает сомнений, кроме того в настоящее время ни один программный продукт не обходится без этого этапа.

Сопровождение — это внесение изменений в эксплуатируемое ПО. Цели изменений: — исправление ошибок;- адаптация к изменениям внешней для ПО среды;- усовершенствование ПО по требованиям заказчика.

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

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

программирование информационный студент.

1. Шаяхметова Б. К. Подготовка студентов к профессиональной деятельности на основе использования графическо-текстовых и объектно-ориентированных языков программирования: Автореф. дис. … канд. пед. наук. — Астана, 2007.