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

КУРСОВОЙ ПРОЕКТ

по дисциплене «Программирование на языке высокого уровня»

Разработка программного средства для долговременного хранения и обработки информации на примере игры «Скачки»

Пояснительная записка

ОГУ 27.03.03.0316.000ПЗ

Руководитель

преподаватель

В. В. Чекрыгина «___»_____________ 2016 г.

Студент группы 14САУ(ба)САУИТ _______ _________И.О. Фамилия

«___»_____________ 2016 г.

Оренбург 2016

Аннотация

Курсовая работа содержит 18 страницы, в том числе 4 рисунка, 5 источников и листинг программы.

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

Введение. 5

1 Техническое задание. 6

2 Описание программы.. 7

3 Руководство пользователю.. 9

4 Тестирование программы.. 10

Заключение. 11

Список использованных источников. 12

Приложение А.. 13

Введение

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

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

Базовым языком программирования служит язык Object Pascal – объектно-ориентированный Паскаль. Принципиальное различие систем программирования Delphi и Turbo Pascal (Turbo – торговая марка разработчика системы фирмы Borland International, Inc.(США)) состоит в использовании экранного режима монитора: Turbo Pascal – ориентирован на текстовый режим системы DOS, а Delphi, как и Windows – на графический. Поэтому одна из последних версий Delphi 7 уже может создавать приложения для новейшей среды.NET. Причём последние версии позволяет программировать и для операционной системы Linux.

Система Delphi реализует технологию объектно-ориентированного виртуального программирования (ООП). От всех других языков программирования его отличают строгость в определении всех переменных и констант, модульность программирования, широкие возможности в создании собственных структур данных, использование объектно-ориентированного программирования, отсутствие машинно-ориентированных конструкций. Корпорация Borland, которая является родоначальником Delphi, с самого начала сделала ставку на визуальное объектно–ориентированное программирование с предоставлением возможности работы с любыми базами данных. В настоящее время система программирования Delphi ни в чем не уступает по своим возможностям таким языкам программирования, как C++, С#, Visual C++, C–Builder, Visual Basic и др.

1 Техническое задание

Была поставлена задача: разработать игру на тему скачек на ипподроме в среде Delphi с организованным тотализатором.

В процессе решения данной задачи получили следующее приложение:

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

Задача играющего: выиграть как можно больше «денег» на тотализаторе.

Минимальные требования для работы с программой: IBM-совместимый 486dx или выше, 5 мб. свободного пространства на жестком диске, ОС Win9x/Me, Win2000/XP/Vista/Seven.

В программе предусмотрено:

Возможность при нулевом балансе можно взять долг;

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

2 Описание программы

Структурная схема программы

На рисунке 1 показано, расположение основных элементов программы, так выглядит основное окно программного продукта.

Рисунок 1 – Основное окно программы

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

5. 1. Разработка структурной и функциональной схем.

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

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

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

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

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

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

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

Структурная схема программного комплекса демонстрирует передачу управления от программы-диспетчера соответствующей программе (рис. 1.1).

Рис. 5.1. Пример структурной схемы программного комплекса.

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

Рис. 5.2. Пример структурной схемы программной системы.

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

Функциональная схема

Функциональная схема или схема данных (ГОСТ 19. 701-90) - схема взаимодействия компонентов программного обеспечения с описанием информационных потоков, состава данных в потоках и указанием используемых файлов и устройств. Для изображения функциональных схем используют специальные обозначения, установленные стандартом.

Функциональные схемы более информативны, чем структурные. На рис. 1.3 для сравнения приведены функциональные схемы программных комплексов и систем.

Рис. 5.3. Примеры функциональных схем: а - комплекс программ, б - программная система.

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

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

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

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

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

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

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

Не отделять операции инициализации и завершения от соответствующей обработки, так как модули инициализации и завершения имеют плохую связность (временную) и сильное сцепление (по управлению);

Не проектировать слишком специализированных или слишком универсальных модулей, так как проектирование излишне специальных модулей увеличивает их количество, а проектирование излишне универсальных модулей повышает их сложность;

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

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

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

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

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

5. 3. Структурные карты Константайна.

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

Различают четыре типа вершин (рис. 1.4.):

Модуль - подпрограмма,

Подсистема - программа,

Библиотека - совокупность подпрограмм, размещенных в отдельном модуле,

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

а). б). в). г).

Рис. 5.4. Обозначение вершин по стандартам IBM, ISO и ANSI:

а – модуль; б – подсистема; в – библиотека; г – область данных.

При этом отдельные части программной системы (программы, подпрограммы) могут вызываться последовательно, параллельно или как сопрограммы (рис. 1.5.).

Рис. 5.5. Обозначение типа вызова:

а – последовательный вызов; б – параллельный вызов; в – вызов сопрограммы.

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

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

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

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

5.4. Проектирование структур данных.

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

Вид хранимой информации каждого элемента данных;

Связи элементов данных и вложенных структур;

Время хранения данных структуры («время жизни»);

Совокупность операций над элементами данных, вложенными структурами и структурами в целом

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

Целые и вещественные числа различных форматов;

Символы;

Булевские значения: true и false;

а также некоторые структурные типы данных, например:

Специально объявленные классы.

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

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

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

Представление данных в оперативной памяти

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

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

Рис. 5.6. Векторная структура памяти.

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

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

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

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

Рис. 5.7. Примеры списковых структур памяти:

а - линейный односвязный список; б - древовидный список; в - n-связный список.

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

Для хранения указателей необходима дополнительная память;

Поиск информации в линейных списках осуществляется последовательно , а потому требует больше времени;

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

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

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

Представление данных во внешней памяти

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

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

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

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

В оперативной памяти размещают данные, к которым необходим быстрый доступ, как для чтения, так и для их изменения;

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

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

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

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

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

Методика Джексона

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

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

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

Строят изображение структур входных и выходных данных;

Выполняют идентификацию связей обработки (соответствия) между этими данными;

формируют структуру программы на основании структур данных и обнаруженных соответствий;

добавляют блоки обработки элементов, для которых не обнаружены соответствия;

Анализируют и обрабатывают несоответствия, т. е. разрешают «столкновения»;

Добавляют необходимые операции (ввод, вывод, открытие/закрытие файлов и т. п.); записывают программу в структурной нотации (псевдокоде).

Методика Варнье-Орра.

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

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

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

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

К нашему времени накоплен опыт успешного использования большинства известных методологий структурного анализа и проектирования в соответствующих CASE-средствах. Наибольшее распространение получили методологии: SADT (3, 3%), структурного системного анализа Гейна-Сарсона (20, 2%), структурного анализа и проектирования Йордана-Де (36, 5%), развития систем Джексона (7, 7%), развития структурных DSSD (Data Structured System Development) Варнье-Орра (5, 8%), анализ проектирования систем реального времени Уорда-Меллора и Хатли, информационного моделирования Мартина (22, 1%).

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

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

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

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

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

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

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

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

Пользовательский интерфейс часто проектируется на этапе выработки требований. Если это не так, его следует определить на этапе разработки архитектуры. Архитектура должна описывать главные элементы формата web-страниц, графического интерфейса (GUI) и т.д. Удобство интерфейса может в итоге определить популярность или провал программы.

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

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

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

Рисунок 2.1. - Структура системы

• 
  выдачи вопроса из анкеты;
• 
  автоматической проверки типа и корректности вводимых данных;
• 
  сохранения данных в базу данных.

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

• 
  контролировать проведение анкетирования;
• 
  управлять данными – добавлять, удалять и изменять;

• 
  cерверная часть, написанная на языке программирования PHP и выполняющаяся на сервере;
• 
  клиентская часть, написанная на языке разметки HTML и языке программирования JavaScript с использованием библиотеки jQuery и выполняющаяся в браузере пользователя.

• 
  Model (Модель) - модуль, отвечающий за непосредственный расчёт чего-либо на основе полученных от пользователя данных. Результат, полученный этим модулем, должен быть передан в контроллер, и не должен содержать ничего, относящегося к непосредственному выводу (то есть должен быть представлен во внутреннем формате системы). Основная цель - сделать так, чтобы модель была полностью независима от остальных частей и практически ничего не знала об их существовании, что позволило бы менять и контроллер и представление модели, не трогая саму модель и даже позволить функционирование нескольких экземпляров представлений и контроллеров с одной моделью одновременно. В следствие этого модель ни при каких условиях не может содержать ссылок на объекты представления или контроллера.
• 
  View (Представление) - модуль вывода информации. В обязанности представления входит отображение данных полученных от модели. Обычно представление имеет свободный доступ к модели и может брать из нее данные, однако это доступ только на чтение, ничего менять в модели или даже просто вызывать методы, приводящие к изменению ее внутреннего состояния, представлению запрещено. Для взаимодействия с контроллером, представление, как правило, реализует некий интерфейс, известный контроллеру, что позволяет менять представления независимо и иметь несколько представлений на контроллер.
• 
  Controller (Контроллер) - модуль управления вводом и выводом данных. В задачи контроллера входит реакция на внешние события и изменение модели и/или представления в соответствии с заложенной в него логикой. Один контроллер может работать с несколькими представлениями, в зависимости от ситуации, взаимодействуя с ними через некий (заранее известный) интерфейс, который эти представления реализуют. Важный нюанс - в классической версии MVC контроллер не занимается передачей данных из модели в представление.

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

• 
  прозрачность системы;
• 
  единая точка входа в систему;
• 
  повторное использование кода;;
• 
  быстрая разработка;
• 
  наличие готовых решений;
• 
  простота поддержки;
• 
  лёгкое внесение изменений.

2.Разработка структуры базы данных программы

• 
  адекватность описываемому объекту - на уровне концептуальной и логической модели;
• 
  удобство использования для ведения учёта и анализа данных - на уровне так называемой физической модели.

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

Структурный аспект - данные в базе данных представляют собой набор отношений.

Аспект целостности - отношения отвечают определенным условиям целостности.

Аспект обработки - поддерживаются операторы манипулирования отношениями.

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

В качестве СУБД была выбрана свободная система управления базами данных MySQL. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Благодаря открытой архитектуре и GPL-лицензированию (GNU General Public License - лицензия на свободное программное обеспечение, цель которой предоставить пользователю права копировать, модифицировать и распространять программы, а также гарантировать, что и пользователи всех производных программ получат вышеперечисленные права), в СУБД MySQL постоянно появляются новые типы таблиц.

Важным достоинством СУБД MySQL является то, что она портирована на большое количество платформ, таких как AIX, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, Solaris и Windows. Отметим, что компания MySQL AB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули.

MySQL имеет интерфейс прикладного программирования (API) для таких языков, как Delphi, C, C++, Java, Perl, PHP, Python и Ruby, библиотеки для языков платформы.NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера (Open DataBase Connectivity - это программный интерфейс доступа к базам данных) MyODBC.

Основным типом таблиц был выбран тип MyISAM. MyISAM-таблицы идеально оптимизированы для использования в связке с web-приложениями, где преобладают запросы на чтение. Таблицы типа MyISAM показывают очень хорошие результаты производительности при выборках SELECT. Во многом это связано с отсутствием поддержки транзакций и внешних ключей. Однако при модификации и добавлении записей вся таблица кратковременно блокируется, что может привести к серьёзным задержкам при большой загрузке. Но в случае с программой анализа анкет опроса это не является серьёзной проблемой, так как высокая нагрузка на систему не планируется.

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

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

Структура базы данных представлена на рисунке 2.4.

Р

исунок 2.3. – Структура базы данных

Таблица it_students содержит данные о студентах, прошедших анкетирование.

Таблица 2.1 – Таблица данных «it_students»

Таблица it_answers_var содержит варианты ответов на вопросы анкетирования.

Таблица 2.2 – Таблица данных «it_answers_var»

Таблица it_questions содержит вопросы анкетирования.

Таблица 2.3 – Таблица данных «it_questions»

Таблица it_tests_cfg делает привязку вопросов анкетирования к конкретной анкете.

Таблица 2.4 – Таблица данных «it_tests_cfg»

Таблица it_tests содержит данные обо всех анкетах и датах проведения анкетирований.

Таблица 2.5 – Таблица данных «it_tests»

Таблица it_text_answers содержит данные об ответах студентов, вводимых вручную.

Таблица 2.6 – Таблица данных «it_text_answers»

Таблица it_students_answers содержит данные об ответах студентов.

Таблица 2.6 – Таблица данных «it_students_answers»

3.Разработка модели информационных потоков базы данных

Примечательно, что для контроллера остаётся скрытым то, с каким типом или реализацией СУБД он работает, все обращения к БД происходят посредствам модели, основной задачей который и является абстрагирование работы с данными. Вместо базы данных можно даже использовать текстовый или XML файл, для контроллера это не будет иметь значения. Параллельно контроллер отправляет запрос компоненту представление, который компонует конечный шаблон и возвращает контроллеру. Так же возможен вариант, когда обмен данными происходит напрямую между моделью и представлением. Контроллер объединяет выборку из базы данных и шаблон представления и передаёт браузеру пользователя.

Рисунок 2.4. - Схема информационных потоков архитектуры МVС

4.Разработка алгоритмического обеспечения

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

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

Рисунок 2.5. – Алгоритм работы системы анкетирования

Одним из важнейших пунктов безопасности web-приложения является проверка всех поступающих данных, поэтому стоит всегда проверять данные, вводимые пользователем в формы поиска, заполнения полей регистрации и так далее на наличие «опасных» данных. Это может быть вредоносный JavaScript код, PHP или PERL команды, а так же (что самое опасное) - команды серверу.

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

• 
  анализ переменных и суперглобальных массивов POST и GET;
• 
  разделение переменных;
• 
  фильтрация строковых переменных.

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

Особо опасны текстовые переменные, например поле для ввода ответа на вопрос анкеты. Их просто необходимо проверять на наличие вредоносного кода. Для устранения опасности производится удаление некоторых элементов из текста или замена на другие символы. Алгоритм обработки входящих данных в фреймворке CodeIgniter показан на рисунке 2.6.

Р
исунок 2.6. – Алгоритм обработки входящих данных в фреймворке CodeIgniter

2.5 Разработка интерфейса программы

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

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

К

примеру, текстовое поле для ввода даты с использованием jQuery было преобразовано в компактный календарь, обладающий функцией автоматической проверки корректности ввода даты (см. рисунок 2.7).

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

опросов показан на рисунке 2.8.

Рисунок 2.8. – Интерфейс ответа на вопрос анкетирования

Рисунок 2.9. - Сообщение об ошибке ввода данных

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

Рисунок 2.10. – Интерфейс вывода результатов анкетирования

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

Существенным преимуществом построения Web-приложений для поддержки стандартных функций браузера заключается в том, что функции должны выполняться независимо от операционной системы данного клиента. Вместо того чтобы писать различные версии для Microsoft Windows, Mac OS X, GNU/Linux и других операционных систем, приложение создается один раз и разворачивается на любой платформе.

3. Технологический раздел

3.1 Технология разработки программы

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

• 
  Microsoft Internet Explorer;
• 
  Opera;
• 
  Mozilla Firefox
• 
  Google Chrome.

3.1.2 Пассивные и активные web-серверы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Наиболее известные приложения на основе Eclipse Platform - различные «Eclipse IDE» для разработки ПО на множестве языков (например, наиболее популярный «Java IDE», поддерживавшийся изначально). В данном случае использовались расширения для программирования на языках программирования PHP (модуль PDT) и JavaScript (модуль JSEclipse), а так же вёрстки с использованием языка разметки HTML.

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

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

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

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

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

• 
  нагрузочное тестирование;
• 
  ручная отладка и трассировка программы с использованием расширения XDebug;
• 
  модульное тестирование с помощью phpUnit.

• 
  на экране ничего не отображается, или выдается системная ошибка с соответствующим кодом (ошибка авторизации, сбой web-сервера и т.п.);
• 
  произошел сбой при работе с базой данных, при этом генерируется отчет об ошибке;
• 
  сбой сервера, связанный с высокой нагрузкой на приложение или БД;
• 
  произошла ошибка выполнения программы, в результате чего отображаются неверные данные или отчёт об ошибке.

3.2.1 Нагрузочное тестирование программы

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

Для нагрузочного тестирования программы обработки анкет опроса студентов кафедры была использована программа curl-loader. Curl-loader это свободно распространяемая утилита тестирования производительности web-приложений, написанная на языке программирования C. Она способна симулировать сотни и даже тысячи обращений к серверу по протоколам HTTP и HTTPS и использует библиотеку libcurl, что позволяет без каких-либо проблем тестировать приложения, требующие авторизации. А поддержка протокола HTTPS позволяет использовать утилиту curl-loader для нагрузочного тестирования web-приложений, работающих через шифрованные транспортные механизмы SSL (Secure Sockets Layer - уровень защищённых сокетов) и TLS (Transport Layer Security).

3.2.2 Отладка с использованием встроенных средств PHP

• 
  параметр display_errors, имеющий значения on или off, указывает, следует ли показывать пользователю сообщения об ошибках или оставить их скрытыми;
• 
  параметр log_errors, имеющий значения on или off, заставляет интерпретатор PHP записывать сообщения в файл журнала событий;
• 
  директива error_reporting определяет, в каких случаях следует генерировать предупреждение, а в каких его можно проигнорировать.

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

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

3.2.3 Отладка программы с помощью XDebug

Учитывая кратковременность выполнения web-приложений и их уровневую конструкцию (клиентское приложение, сеть, web-сервер, прикладной код и применяемая база данных), отловить ошибки в исходном коде может быть нелегко. Даже если предположить, что все уровни, за исключением PHP-кода, работают безупречно, трассировка до обнаружения ошибки в программе может быть трудной, особенно если приложение использует большое количество классов.

Выражение языка PHP echo и такие функции, как var_dump(), debug_zval_dump() и print_r() являются обычными и очень популярными средствами отладки, помогающими решить различные мелкие проблемы. Однако как средства тестирования и отладки эти выражения (и даже более надежный инструментарий, например, пакет PEAR Log) помогают слабо и не всегда.

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

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

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

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

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

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

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

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

исунок 2.1. – Интерфейс программы KCachegrind

3.2.4 Модульное тестирование с использованием phpUnit

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

Для того, чтобы написать минимальный набор тестов, используя phpUnit, необходимо:

• 
  подключить библиотеку PHPUnit.php;
• 
  создать подкласс базового класса TestCase;
• 
  добавить в него произвольное количество тестирующих методов, названия которых начинаются с "test". На вход будут подаваться заранее известные параметры, а результат сравнивается с эталонным посредством семейства функций Assert, унаследованных тестовым классом от базового класса TestCase;
• 
  создать класс PHPUnit_TestSuite, передав ему в качестве параметра название класса с набором тестов;
• 
  Запустить набор тестов и проверить результат выполнения.

6 (?). Перечень графического материала

6.1 Постановка задачи

6.2 Структурная схема программы

Тема 1.3: Системное программное обеспечение

Тема 1.4: Сервисное программное обеспечение и основы алгоритмизации

Введение в экономическую информатику

1.3. Системное программное обеспечение ПК

1.3.1. Структура программного обеспечения ПК

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

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

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

Рис. 1.

Системное ПО

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

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

К системному ПО относятся:

• операционные системы (эта программа загружается в ОЗУ при включении компьютера);
• программы – оболочки (обеспечивают более удобный и наглядный способ общения с компьютером, чем с помощью командной строки DOS, например, Norton Commander);
• операционные оболочки – интерфейсные системы, которые используются для создания графических интерфейсов, мультипрограммирования и.т.;
• Драйверы (программы, предназначенные для управления портами периферийных устройств, обычно загружаются в оперативную память при запуске компьютера);
• утилиты (вспомогательные или служебные программы, которые представляют пользователю ряд дополнительных услуг).

К утилитам относятся:

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

Необходимо отметить, что часть утилит входит в состав операционной системы, а другая часть функционирует автономно. Большая часть общего (системного) ПО входит в состав ОС. Часть общего ПО входит в состав самого компьютера (часть программ ОС и контролирующих тестов записана в ПЗУ или ППЗУ, установленных на системной плате). Часть общего ПО относится к автономными программам и поставляется отдельно.

Прикладное ПО

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

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

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

К прикладному ПО, например, относятся:

1. Комплект офисных приложений MS OFFICE.
2. Бухгалтерские системы.
3. Финансовые аналитические системы.
4. Интегрированные пакеты делопроизводства.
5. CAD – системы (системы автоматизированного проектирования).
6. Редакторы HTML или Web – редакторы.
7. Браузеры – средства просмотра Web - страниц.
8. Графические редакторы.
9. Экспертные системы.

Инструментальное ПО

Инструментальное ПО или системы программирования - это системы для автоматизации разработки новых программ на языке программирования.

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

1. Текстовый редактор для создания файла с исходным текстом программы.
2. Компилятор или интерпретатор. Исходный текст с помощью программы-компилятора переводится в промежуточный объектный код. Исходный текст большой программы состоит из нескольких модулей (файлов с исходными текстами). Каждый модуль компилируется в отдельный файл с объектным кодом, которые затем надо объединить в одно целое.
3. Редактор связей или сборщик, который выполняет связывание объектных модулей и формирует на выходе работоспособное приложение – исполнимый код. Исполнимый код – это законченная программа, которую можно запустить на любом компьютере, где установлена операционная система, для которой эта программа создавалась. Как правило, итоговый файл имеет расширение.ЕХЕ или.СОМ.
4. В последнее время получили распространение визуальный методы программирования (с помощью языков описания сценариев), ориентированные на создание Windows-приложений. Этот процесс автоматизирован в средах быстрого проектирования. При этом используются готовые визуальные компоненты, которые настраиваются с помощью специальных редакторов.

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

1. Borland Delphi - предназначен для решения практически любых задачи прикладного программирования.
2. Borland C++ Builder – это отличное средство для разработки DOS и Windows приложений.
3. Microsoft Visual Basic – это популярный инструмент для создания Windows-программ.
4. Microsoft Visual C++ - это средство позволяет разрабатывать любые приложения, выполняющиеся в среде ОС типа Microsoft Windows.

Тема 3. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ

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

Структура программного обеспечения

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

· на обеспечение устойчивой работы компьютера и вычислительной сети;

· на создание условий для нормальной работы прикладных про­грамм;

· на выполнение вспомогательных операций;

· на диагностику аппаратной части компьюте­ра и вычислительной сети;

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

Базовый подкласс ПО включает:

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

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

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

До недавнего времени на большинстве ПК была установлена операци­онная сис­тема MS DOS , которая была создана в 1981 г. фир­мой Microsoft (заметим, что она не была ори­гинальной разработкой самой Microsoft - ком­пания Билла Гейтса лишь дорабо­тала «операци­онку» под названием QDOS, созданную другой компанией ). До появления Windows дисковая операцион­ная система MS DOS была самой популярной и массовой в применении. В ее среде создано целое поколение программного продукта. На основе MS DOS в процессе развития компьютерных технологий появился Windows (с 1996 г. MS DOS включена в состав операционной среды Windows 95 ). Основные компоненты ОС, развитые в среде MS DOS, являются классикой, и орга­нично включены в Windows на новом этапе раз­вития программного обеспе­чения в целом и его сердцевины - операционных систем.

MS DOS 16-разрядная однозадачная операционная сис­тема, обладающая «интер­фейсом ко­манд­ной строки», компактна, предъяв­ляет скром­ные требо­ва­ния к аппаратуре и вы­полняет необ­ходимый мини­мум функций для поль­зователей и программ. Основ­ные недос­татки DOS:

· главным ее уяз­вимым ме­стом является работа с ограниченной оператив­ной памятью (в эпоху созда­ния MS-DOS оперативная па­мять большин­ства компьюте­ров не превышала 256 ки­лобайт. DOS мог­ла работать с 640 ки­лобай­тами ОП, и Билл Гейтс ут­верждал, что никому и никогда не понадо­бится больший объем, но время шло и появились программы, ко­то­рым требовался для работы больший объем опера­тив­ной памяти и при­ходи­лось ис­пользовать специальные про­граммы - ме­неджеры памяти, но и они не ре­шали проблему );

· вторым недос­татком DOS была не­возможность работы в полно­ценном гра­фическом ре­жиме (хотя то­гдашние ком­пь­ютеры уже могли бы обеспе­чить его под­держку );

· третьим недостат­ком MS-DOS была однозадачность.

Операционные системы се­мейства DOS, несмотря на свою про­стоту и экономичность, мо­рально устарели, и на смену им пришли опе­рацион­ные системы нового поко­ления. К числу таких ОС относятся операционные сис­темы се­мейства Windows , операци­онные системы семейства Unix и др.

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

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

· антивирусные программы (обеспечивающие защиту компь­ютера, обнаруже­ние и восстановление зараженных файлов );

· программы архивирования данных (обеспечивают процесс сжатия ин­форма­ции в файлах с целью уменьше­ния объема памяти для ее хранения );

· программы обслуживания сети.

· программы диагностики работоспособности компьютера;

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

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

· локальные средства, обеспечивающие выполнение отдельных работ по созда­нию программ;

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

Локальные средства разработки про­грамм включают языки и системы про­грам­мирования, а также инструментальную среду пользователя. Сущест­вуют ма­шинные языки программирования (воспринимаемые аппаратной ча­стью компью­тера ма­шин­ные коды ), машинно-ориентированные языки (языки программирова­ния, кото­рые отражают структуру конкретного типа компью­тера – ассемб­леры ), алго­ритмические (универсальные ) языки, не зависящие от архитектуры компьютера, напри­мер, Фор­тран (Fortran ), Ко­бол (Cobol ), Алгол (Algol ), Пас­каль (Pascal ), Бейсик (Basic ), Си (C ), Си++ (C++ ) и др.; процедурно-ориентированные языки (где име­ется возмож­ность описания про­граммы как совокупности процедур – подпро­граммы ), про­блемно-ориен­тированные языки (предназначенные для решения задач оп­реде­ленного класса ), интегрирован­ные системы программирования. Заметим, что класси­фикация языков программирования не закреплена ГОСТами (в учебных це­лях обычно проводится их классификация по различным призна­кам ). Про­грамма, подго­товленная на языке программи­рования, проходит этап трансля­ции, отладки и тести­рования.

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

Кроме того, существуют средства для создания сложных информацион­ных сис­тем (CASE – технология ). Проектирование информационных систем представ­ляет собой трудоемкую и дли­тельную работу, требующую высокой ква­лификации участ­вующих в ней специалистов. В недале­ком прошлом про­ектирование нередко выпол­нялось на интуитивном уровне неформализован­ными методами, включаю­щими в себя элементы искусства, практический опыт, экспертные оценки и дорого­стоящие экспериментальные проверки ка­чества функционирования. В начале 70-х гг. в США был отмечен кризис про­граммирования (software crisis ). Это выра­жалось в том, что боль­шие проекты стали выполняться с отставанием от гра­фика или с превышением сметы рас­хо­дов, разработанный продукт не обладал тре­буемыми функцио­нальными возможностями, произ­водительность его была низка, ка­чество получаемого про­граммного обеспечения не устраивало потре­бителей. Потребность кон­тролировать процесс разработки ПО, прогнози­ровать и гаран­тировать стои­мость разработки, сроки и качество ре­зультатов привела к необ­ходимости пере­хода от кус­тарных к индустриальным способам создания ПО и по­явле­нию совокупности инже­нерных методов и средств создания ПО, объеди­нен­ных общим названием «программная инжене­рия» (software engineering ). В основе про­граммной инженерии лежит сле­дующая идея: проектиро­вание ПО является фор­мальным процессом, который можно изучать и совершенство­вать. К концу 80-х гг. было проведено много исследований в области про­грамми­рования (разработка и внедрение языков высокого уровня, мето­дов струк­турного и модульного програм­мирования, языков проектирова­ния и средств их под­держки, формальных и нефор­мальных языков описания сис­темных требований и спецификаций и т. д. ). Термин CASE (Computer Aided Software Engineering ) имеет весьма широкое толкование. Первоначально зна­чение термина CASE ограни­чива­лось вопросами автоматизации раз­работки только лишь программного обеспече­ния, а в на­стоящее вре­мя оно при­обрело новый смысл и охватывает про­цесс разра­ботки сложных инфор­мационных систем в целом. CASE-технология представляет собой совокупность методов про­ектирования информационных сис­тем, а также набор инструментальных средств, позво­ляющих в наглядной форме моделировать предметную об­ласть, ана­лизиро­вать эту модель на всех ста­диях раз­работки и со­провожде­ния, разрабатывать приложения в соответствии с информаци­он­ны­ми потреб­ностями пользователей. Большинство существующих CASE-средств осно­вано на методах структурного или объектно-ори­ентированного анализа и проек­тирования, использую­щих специфи­кации в виде диаграмм или текстов для описания внешних требова­ний, свя­зей между моделями системы, дина­мики поведе­ния сис­темы и архитектуры про­граммных средств.

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

· программы обработки текстов;

· графические редакторы;

· программы обработки фото- и видеоизображений;

· программы подготовки презентаций;

· электронные таблицы;

· системы управления базами данных;

· программы эко­номического и статистического анализа;

· сис­темы автомати­зированного проектирования (САПР);

· информационно-поисковые системы;

· сетевое программное обеспечение (программы для работы с электронной почтой, доступ к ви­деоконференциям, браузеры Интернет и т.д. );

· игровые программы.

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

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