Учет учебных материалов кафедры

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

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

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

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

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

Независимо  от привязки к языку программирования, объектно-ориентированный подход имеет  ряд общих принципов, а именно:

• возможность создавать абстрактные типа данных, позволяющая наряду с предопределёнными типами данных (такими как integer, string и т.д.) вводить свои собственные типы данных (классы) и объявлять «переменные» таких типов данных (объекты). Создавая свои собственные типы данных, программист оперирует не машинными терминами (переменная, функция), а объектами реального мира, поднимаясь тем самым на новый уровень абстракции;
• инкапсуляция, ограничивающая взаимодействие пользователя абстрактных типов данных только их интерфейсом и скрывающая внутреннюю реализацию объекта, не допуская влияния на его внутреннее состояние. Память человека ограничена и не может содержать все детали огромного проекта, тогда как использование инкапсуляции позволяет разработать объект и использовать его, не заботясь о внутренней реализации и прибегая только к небольшому числу интерфейсных методов;
• наследование, позволяющее развить существующий абстрактный тип данных – класс, создав на его основе новый класс. При этом новый класс автоматически получает возможности уже существующего абстрактного типа данных. Зачастую абстрактные  типы данных слишком сложны, поэтому прибегают к их последовательной разработке, выстраивая иерархию классов от общего к частному;
• полиморфизм, допускающий построение целых цепочек и разветвленных деревьев, наследующих друг другу абстрактных типов данных (классов). При этом весь набор классов будет иметь ряд методов с одинаковыми названиями: любой из классов данного дерева гарантированно обладает методом с таким именем. Этот принцип помогает автоматически обрабатывать массивы данных разного типа.

 

3.1.4 Особенности фреймворка CodeIgniter

Используемый фреймворк CodeIgniter написан с использованием объектно-ориентированного подхода. Все классы контроллеров, отображений и моделей, вводимые программистом, наследуют исходные классы, введённые в сам фреймворк. Это даёт возможность писать меньший по объёму исходный код, поскольку все необходимые базовые функции сразу же становятся доступны.

Помимо доступных программисту классов контроллеров, отображений  и моделей, в фреймворке CodeIgniter существуют также доступные программисту функции плагинов (plugins) и хелперов (helpers - помощники). Хелперы, как видно из названия, призваны помочь исполнить какую-либо незначительную функцию. Например, существуют хелперы построения web-форм, загрузки файлов или работы с сессиями. В отличие от всех остальных основных элементов фреймворка, хелперы – наборы элементарных функций., написанных даже без использования объектно-ориентированного подхода. Каждая функция выполняет небольшую, строго ограниченную задачу. Однако набор довольно велик, и такая «мелочь» становится очень полезной в работе.

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

3.1.5 Инструментарий совместной разработки Subversion

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

Subversion (сокр. SVN) — свободная централизованная  система управления версиями, созданная  в 2000 г. компанией CollabNet Inc.

Subversion разработана специально для замены устаревшей системы CVS, распространённой открытой системы управления версиями. Subversion обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и свободна от ряда её недостатков.

Subversion — централизованная система (в отличие от распределённых систем, таких, как Git или Mercurial), то есть данные хранятся в едином хранилище. Хранилище может располагаться на локальном диске или на сетевом сервере.

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

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

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

Для удобства работы с ситемой использовалась ситема работы с репозитариями –  Tortoise SVN

3.1.6 Интегрированная среда разработки Zend Studio

При разработке программы обработки  анкет опроса студентов кафедры  также использовался такой важный и полезный инструмент программиста, как интегрированная среда разработки (IDE - Integrated Development Environment), а именно Zend Studio. Zend Studio - фреймворк для разработки модульных кроссплатформенных приложений.

Zend Studio использовался в тандеме  с отладчиком Zend Debugger, о котором речь пойдет в разделе 3.2.1.

3.2 Технология тестирования программы

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

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

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

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

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

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

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

Тестирование системы проводилось  двумя методами:

• функциональное тестирование;
• метод контрольных тестов (Test - испытание, проверка) [3.3].

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

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

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

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

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

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

Основные принципы тестирования:

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

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

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

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

д) Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и ни делает ли она то, что не должна делать.

е) Не следует выбрасывать тесты, даже если программа уже не нужна.

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

Поэтому на практике последовательно применяют следующие  методы тестирования:

• статический;
• детерминированный;
• стохастический.

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

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

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

Тестирование PHP программы – означает тестирование того, что на экран пользователя выводятся нужные данные, что запрос пользователя принимается, обрабатывается, происходит соответствующее взаимодействие с СУБД MySQL, и ответ направляется на соответствующим образом генерируемую HTML страницу, отображающуюся у пользователя, пославшего зарос. Сбои отображения происходят в следующих случаях: