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

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

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

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

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

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

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

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

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

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

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

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

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

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

Система анкетирования содержит следующие функции:

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

Система обработки результатов анкетирования позволяет:

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

Система управления позволяет:

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

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

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

ерверная часть программы по своей структуре соответствует архитектуре MVC (Model-View-Controller) или модель-представление-контроллер. MVC представляет собой архитектуру программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.
Рисунок 2.2. – Архитектура «Модель-Представление-Контроллер»
Такой подход позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента.

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

Преимущества, которые представляет архитектура MVC по сравнению с традиционной моделью:

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

Таким образом, использование архитектуры 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»

Поле	Тип	Длина	Описание
id	Числовой	11	Индекс
num	Числовой	11	Номер студенческого билета
name	Символьный	100	Имя
second_name	Символьный	100	Отчество
surname	Символьный	100	Фамилия
birth	дата	-	Дата рождения
year_postupl	год	-	Год поступления
address	Символьный	500	Адрес
phone_h	Символьный	15	Домашний телефон
phone_m	Символьный	15	Мобильный телефон
mail	Символьный	250	Адрес e-mail
icq	Числовой	10	Номер ICQ

Таблица 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.Разработка модели информационных потоков базы данных

Поскольку программа анализа анкет опроса студентов построена по принципу MVC, то можно представить информационные потоки следующим образом. При поступлении запроса от пользователя, который отсылает браузер Web-серверу, контроллер, следуя запрограммированным алгоритмам квалифицирует полученный запрос, изменяет и передаёт его в модель. Модель, являющаяся связующим звеном между контроллером и СУБД, интерпретирует запрос и делает соответствующее обращение к СУБД MySQL, возвращая результаты контроллеру.

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

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

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

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

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

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

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

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

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

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

Обязательно надо проверять входящие переменные в самом начале программы, не допуская до работы с функциями и запросами к базе данных ещё не проверенные, потенциально опасные, данные от пользователей. Таким образом, все необходимые для защиты функции будут находиться в одном определённом месте или даже файле. В случае с программой обработки анкет опроса студентов фильтрация данных производится на уровне фреймворка CodeIgniter в автоматическом режиме, поскольку в файле конфигурации включена строка $config["global_xss_filtering"] = TRUE.

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

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

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

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

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

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

Интерфейс пользователя выполнен на языке разметки HTML с использованием JavaScript и библиотеки jQuery, что позволило построить интерактивный пользовательский интерфейс программы.

К

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

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

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

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

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

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

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

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

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

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

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

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

3.1.1 Основы работы web-сервера

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

Microsoft Internet Explorer;
Opera;
Mozilla Firefox
Google Chrome.

Каждая страница web-сервера имеет свой так называемый универсальный адрес ресурса - Universal Resource Locator (URL). Чтобы получить доступ к той или иной странице, пользователь должен указать ее адрес URL браузеру. Как правило, любой web-сервер имеет одну главную страницу, содержащую ссылки на все остальные страницы этого сервера. Поэтому просмотр содержимого сервера Web обычно начинается с его главной (индексной) страницы.

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

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

3.1.3 Объектно-ориентированный подход

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.5 Интегрированная среда разработки Eclipse

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

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

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

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

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

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

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

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

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

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

на экране ничего не отображается, или выдается системная ошибка с соответствующим кодом (ошибка авторизации, сбой 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

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

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

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

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

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

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

Хотя язык программирования PHP можно использовать для создания сценариев командной строки для таких задач как системное администрирование и традиционная обработка данных, мощь языка особенно проявляется в web-приложениях.

Учитывая кратковременность выполнения 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

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

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

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

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

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

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

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

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

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

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

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

ОГУ 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 – Основное окно программы

Шаг 1. Определяем структуру управляющей программы, которая для нашего случая реализует работу с меню через клавиатуру: Программа
Шаг 2. Детализируем операцию Выполнить команду: Выполнить Команду
Подобный материал:

Н. Э. Баумана Факультет Информатики и систем управления Кафедра Компьютерные системы , 254.77kb.
Н. Э. Баумана Кафедра Компьютерные системы и сети Г. С. Иванова, Т. Н. Ничушкина Оформление , 109.65kb.
Н. Э. Баумана Факультет "Инженерный бизнес и менеджмент" Кафедра "Менеджмент" , 786.11kb.
Примерная программа наименование дисциплины Проектирование и архитектура программных , 182.2kb.
С. В. Чувиков Метрология и сертификация программного обеспечения Учебное пособие , 1298.56kb.
Электронное гиперссылочное учебное пособие по дисциплине «Основы теории управления» , 57.71kb.
Н. Э. Баумана Факультет "Информатика и системы управления" Кафедра "Системы обработки , 128.07kb.
М. В. Красильникова проектирование информационных систем раздел: Теоретические основы , 1088.26kb.
Программа вступительных испытаний (собеседования) для поступающих в магистратуру , 87.89kb.
Учебное пособие, 2003 г. Учебное пособие разработано ведущим специалистом учебно-методического , 454.51kb.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для того чтобы построить график необходимо задать функцию, интервал изменения аргумента , на котором функция непрерывна, количество точек графика n, размер и положение окна экрана, в котором необходимо построить график: wx1, wy1, wx2, wy2 и количество линий сетки по горизонтали и вертикали nlx, nly. Значения wx1, wy1, wx2, wy2, nlx, nly можно задать, исходя из размера экрана, а интервал и число точек графика надо вводить.

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

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

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

Программа.

Инициализировать глобальные переменные

Вывести заголовок и меню

Выполнять

Если выбрана Команда

то Выполнить Команду

иначе

Все-если

до Команда=Выход

Конец.

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

Шаг 2. Детализируем операцию Выполнить команду:

Выполнить Команду:

Выбор Команда

Функция:

Выполнить разбор формулы

Отрезок:

Ввести значения x1,x2

Ввести значение h

Вид результата:

Ввести вид_результата

Если Вид_результата=График

то Построить график

иначе Вывести таблицу

все-если

Все-выбор

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

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

Подпрограмма Вывод заголовка и меню параметров не имеет.

Подпрограмма Разбор формулы должна иметь два параметра: Fun – аналитическое задание функции, Tree – возвращаемый параметр – адрес дерева разбора.

Подпрограмма Расчет Значений функции должна получать адрес дерева разбора Tree, отрезок x1 и x2, а также шаг h. Обратно в программу она должна возвращать таблицу значений функции X(n) и Y(n), где n – количество точек функции.

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

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

Программа.

Вывод заголовка и меню

Выполнять

Если выбрана Команда

то

Выбор Команда

Функция:

Ввести или выбрать формулу Fun

Разбор формулы (Fun; Var Tree)

Отрезок:

Ввести значения x1,x2

Ввести значения h

Вид результата:

Ввести Вид_результата

Выполнить:

Расчет таблицы(x1,x2,h,Tree; Var X, Y, n)

Если Вид_результата=График

то Построение графика(X, Y, n)

иначе Вывеод таблицы(X, Y, n)

все-если

Все-выбор

иначе Обработать нажатие клавиш управления

Все-если

до Команда=Выход

Конец.

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 1.

Системное ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· содержит механизмы расширения и специализации базовых концепций языка.

· UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group(OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

· строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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