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

Кокорева Е.В.

Лабораторный практикум по курсу:

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

Москва 2007

УДК 004.43(075.8)

Кокорева Е.В.

Лабораторный практикум по курсу «Технология программирования». - М.: МИЭТ, 2007. - 127 с.: ил.

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

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

Лабораторные работы предназначены для студентов, обучающихся по специальности 230105 65 (220400) "Программное обеспечение вычислительной техники и автоматизированных систем" и по направлению подготовки бакалавров 230100 62 (552800) "Информатика и вычислительная техника".

© МИЭТ, 2007

содержание

Содержание………………………………………………………………………………… 3

Лабораторная работа № 1 Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия «Техническое задание»…………4

Лабораторная работа № 2 Структурный подход к программированию. Стадия «Эскизный проект»………………………………………………………………………..10

Лабораторная работа № 3 Структурный подход к программированию. Стадия «Технический проект»………………………………………………………………….…37

Лабораторная работа № 4 Этапы разработки программного обеспечения. Стадия «Реализация»………………... ………………………………...………………………….49

Лабораторная работа № 5 Проектирование программной системы при объектном подходе к программированию ………………………………………………...…………53

Лабораторная работа № 6 Тестирование программ методами «белого ящика»…..…65

Лабораторная работа № 7 Тестирование программ методами «черного ящика»……75

Лабораторная работа № 8 Создание сетевых приложений на Delphi с использованием Windows Sockets API………………………………………………………………………86

Лабораторная работа № 9 Использование технологий OLE COM и ActiveX…….…101

Приложение 1…………………………………………………………………………….110

Приложение 2…………………………………………………………………….………118

Приложение 3………………………………………………………………………….…122

Литература………………………………………………………………………………..127

Лабораторная работа № 1

Этапы разработки программного обеспечения при структурном подходе к программированию. Стадия «Техническое задание»

Цель занятия: ознакомиться с правилами написания технического задания.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

Разработка технического задания

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

1. Порядок разработки технического задания

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

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

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

Общие положения

2.1. Техническое задание оформляют в соответствии с ГОСТ 19.106-78 (Требования к программным документам, выполненным печатным способом) на листах формата А4 и А3 по ГОСТ 2.301-68 (Форматы), как правило, без заполнения полей листа. Номера листов (страниц) проставляют в верхней части листа над текстом.

2.2. Лист утверждения и титульный лист оформляют в соответствии с ГОСТ 19.104-78 (Основные надписи). Информационную часть (аннотацию и содержание), лист регистрации изменений допускается в документ не включать.

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

2.4. Техническое задание должно содержать следующие разделы:

· введение;

· наименование и область применения;

· основание для разработки;

· назначение разработки;

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

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приёмки;

· приложения.

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

Содержание разделов

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

3.2. В разделе "Наименование и область применения" указывают наименование, краткую характеристику области применения программы или программного изделия и объекта, в котором используют программу или программное изделие.

3.3. В разделе "Основание для разработки" должны быть указаны:

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

· организация, утвердившая этот документ, и дата его утверждения;

· наименование и (или) условное обозначение темы разработки.

3.4. В разделе " Назначение разработки" должно быть указано функциональное и эксплуатационное назначение программы или программного изделия.

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

· требования к функциональным характеристикам;

· требования к надёжности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

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

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

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

3.5.4. В подразделе " Требования к составу и параметрам технических средств" указывают необходимый состав технических средств с указанием их технических характеристик.

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

3.5.6. В подразделе "Требования к маркировке и упаковке" в общем случае указывают требования к маркировке программного изделия, варианты и способы упаковки.

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

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

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

3.7. В разделе "Порядок контроля и приёмки" должны быть указаны виды испытаний и общие требования к приёмке работы.

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

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

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

· другие источники разработки.

В случаях, если какие-либо требования, предусмотренные техническим заданием, заказчик не предъявляет, следует в соответствующем месте указать «Требования не предъявляются».

Пример 1.1: Разработать техническое задание на программный продукт, предназначенный для наглядной демонстрации школьникам графиков функций одного аргумента у = f (x). Разрабатываемая программа должна рассчитывать таблицу значений и строить график функций на заданном отрезке по заданной формуле и менять шаг аргумента и границы отрезка. Кроме этого, программа должна запоминать введенные формулы.

Техническое задание к данному примеру смотри в приложении 2.

Пример 1.2: Оформить техническое задание на разработку «Модуля автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института » см. приложение 3.

Порядок выполнения работы:

1. Разработать техническое задание на программный продукт (см. варианты заданий).

2. Оформить работу в соответствии с ГОСТ 19.106-78. При оформлении использовать MS Office.

3. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Техническое задание на программный продукт.

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

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

1. Этапы разработки программного обеспечения.

2. Жизненный цикл программного обеспечения.

3. Постановка задачи и предпроектные исследования.

4. Функциональные и эксплуатационные требования к программному продукту.

5. Правила разработки технического задания.

6. Основные разделы технического задания.

Лабораторная работа № 2

Структурный подход к программированию. Стадия

«Эскизный проект»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

3. Ознакомиться с лекционным материалом по теме "Этапы разработки программного обеспечения. Анализ требований и определение спецификаций программного обеспечения" учебной дисциплины "Технология разработки программного обеспечения".

4. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

Анализ требований и определение спецификаций при структурном подходе

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

· спецификаций процессов;

· словаря терминов;

· диаграмм переходов состояний (STD – State Transition Diagrams), характеризующих поведение системы во времени;

· функциональных диаграмм (методология SADT);

· диаграмм потоков данных (DFD – Data Flow Diagrams), описывающих взаимодействие источников и потребителей информации через процессы, которые должны быть реализованы в системе;

· диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы.

Спецификации процессов

Спецификации процессов могут быть представлены в виде псевдокодов, блок-схем алгоритмов, Flow-форм, диаграмм Насси-Шнейдермана или просто краткого текстового описания.

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

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

1.1. Схемы алгоритмов

Для изображения схем алгоритмов разработан ГОСТ 19.701-90 (см. табл. 1)

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

· следование – обозначает последовательное выполнение действий (рис. 1 а);

Таблица 1

Название

Обозначение

Назначение

Терминатор

Начало, завершение программы или подпрограммы

Процесс

Обработка данных (вычисления, пересылки и т. п.)

Данные

Операции ввода-вывода

Решение

Ветвление, выбор, поисковые и итерационные циклы

Подготовка

Счетные циклы

Граница цикла

Конец

Любые циклы

Предопределенный процесс

Вызов процедур

Соединитель

Маркировка разрывов линий

Комментарий

Пояснения к операциям

· ветвление – соответствует выбору одного из двух вариантов действий (рис. 1, б);

· цикл-пока – определяет повторение действий, пока не будет нарушено некоторое условие, выполнение которого проверяется в начале цикла (рис. 1, в).

Рис 1. Базовые алгоритмические структуры:

а - следование; б - ветвление; в - цикл-пока

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

· выбор – обозначает выбор одного варианта из нескольких в зависимости от значения некоторой величины (рис. 2, а);

· цикл-до – обозначает повторение некоторых действий до выполнения заданного условия, проверка которого осуществляется после выполнения действий в цикле (рис. 2, б);

· цикл с заданным числом повторений (счетный цикл) – обозначает повторение некоторых действий указанное количество раз (рис. 2, в).

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

Рис. 2. Дополнительные структуры алгоритмов:

а - выбор; б - цикл-до; в - цикл с заданным числом повторений

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

Рис. 3. Пример схемы алгоритма поиска максимального элемента массива

1.2. Псевдокоды.

Псевдокод – формализованное текстовое описание алгоритма (текстовая нотация). В литературе были предложены несколько вариантов псевдокодов. Один из них приведен в табл. 2.

Таблица 2

Структура	Псевдокод	Структура	Псевдокод
Следование	<Действие1> <Действие2>	Выбор	Выбор <код> <код1>:<Действие1> <код2>: <Действие2> … Все-выбор
Ветвление	Если <Условие> то <Действие1> иначе <Действие2> Все-если	Цикл с заданным количеством повторений	Для <индекс> = <n>,<k>,<h> <Действие> Все-цикл
Цикл-пока	Цикл-пока <Условие> <Действие> Все-цикл	Цикл-до	Выполнять <Действие> До <Условие>

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

Программа

Цикл-пока не конец файла

Прочитать запись

Сравнить заданные поля с критерием поиска

Если совпали

Сохранить в выходной список

Конец-если

Конец-цикл

Вывод результирующего списка

Конец-программа

Словарь терминов

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

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

термин;

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

краткое описание.

Пример:

Термин Web-сайт

Категория Интернет-программирование

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

Функциональные диаграммы

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

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

4.1. Методология SADT

В качестве примера рассмотрим методологию SADT предложенную Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition). Методология SADT представляет собой набор методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области.

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

· графическое представление блочного моделирования. На SADT-диаграмме функции представляется в виде блока, а интерфейсы входа/выхода в виде дуг, соответственно входящих в блок и выходящих из него. Интерфейсные дуги отображают взаимодействие функций друг с другом;

· строгость и точность отображения.

Правила SADT включают:

· уникальность меток и наименований;

· ограничение количества блоков на каждом уровне декомпозиции;

· синтаксические правила для графики;

· связность диаграмм;

· отделение организации от функции;

· разделение входов и управлений.

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

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

Рис. 7. Функциональный блок и интерфейсные дуги

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

· вход-выход блока подается на вход блока с меньшим доминированием, т.е. следующего (рис. 8, а);

· управление – выход блока используется как управление для блока с меньшим доминированием (рис. 8, б);

· обратная связь по входу – выход блока подается на вход блока с большим доминированием (рис. 8, в);

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

· выход-исполнитель – выход блока используется как механизм для другого блока (рис. 8, д).

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

На рис. 9 приведены четыре диаграммы и их взаимосвязи, показывающие структуру SADT-модели. Каждый компонент модели может быть декомпозирован на другой диаграмме. Детальная диаграмма иллюстрирует внутреннее строение блока «родительской» диаграммы.

Рис. 8. Типы влияний блоков: а - вход; б - управление; в - обратная связь по входу; д - выход-исполнитель

4.2. Иерархия диаграмм

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

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

Все диаграммы связывают друг с другом иерархической нумерацией блоков: первый уровень – АО, второй – А1, А2 и т. п., третий – А11, А12, А13 и т. п., где первые цифры – номер родительского блока, а последняя – номер конкретного блока детальной диаграммы.

Рис. 9. Структура SADT-модели. Декомпозиция диаграмм

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

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

На рис. 10 - 12 представлены различные варианты выполнения функций и соединения дуг с блоками.

Рис. 10. Одновременное выполнение

Рис. 11. Соответствие родительской и детальной диаграмм

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

Рис. 12. Пример обратной связи

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

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

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

I1 – размер массива;

I2 – массив;

С1 – выбор метода;

R1 – вывод описания метода;

R2 – отсортированный массив.

Рис. 13. Функциональные диаграммы для системы исследования функций:

а - диаграмма верхнего уровня; б - уточняющая диаграмма

Диаграммы потоков данных (DFD)

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

Для изображения диаграмм потоков данных традиционно используют два вида нотаций: нотации Иордана и Гейна-Сарсона (табл. 4).

Таблица 4

Понятие

Описание

Нотация Йордана

Нотация Гейна-Сарсона

Внешняя сущность

Внешний по отношению к системе объект, обменивающийся с нею потоками данных

Номер Имя

Функция

Действие, выполняемое моделируемой системой

Поток данных

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

Хранилище данных

Структура для хранения информационных объектов

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

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

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

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

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

· правило нумерации – означает, что при детализации подсистем должна поддерживаться их иерархическая нумерация. Например, подсистемы, детализирующие подсистему с номером 2, получают номера 2.1, 2.2, 2.3 и т.д.

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

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

В соответствии с вышесказанным процесс построения модели разбивается на следующие этапы:

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

2. Выявление внешних объектов, связанных с разрабатываемой системой.

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

4. Предварительная разработка контекстной диаграммы.

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

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

7. Проверка основных требований контекстной диаграммы.

8. Декомпозиция каждого процесса текущей DFD с помощью детализирующей диаграммы или спецификации процесса.

9. Проверка основных требований по DFD соответствующего уровня.

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

11. Проверка полноты и наглядности модели после построения каждых двух-трех уровней.

Пример 2. Разработаем иерархию диаграмм потоков данных программы сортировки одномерных массивов.

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

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

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

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

Рис. 15. Детализирующая диаграмма потоков данных программы сортировки одномерного массива (нотация Гейна-Сарсона)

6. Диаграммы сущность-связь

Базовыми понятиями ER-модели данных (ER – Entity-Relationship) являются: сущность, атрибут и связь.

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. Все варианты диаграмм сущность-связь исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

Поскольку нотация Баркера является наиболее распространенной, в дальнейшем будем придерживаться именно ее.

6.1. Основные понятия ER-диаграмм

Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Сущность имеет наименование, выраженное существительным в единственном числе и обозначается в виде прямоугольника с наименованием (рис 16, а). Примерами сущностей могут быть такие классы объектов как «Студент», «Сотрудник», «Товар».

Экземпляр сущности – это конкретный представитель данной сущности. Например, конкретный представитель сущности «Студент» – «Максимов». Причем сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности, для того чтобы различать экземпляры.

Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с описательными оборотами или прилагательными). Примерами атрибутов сущности «Студент» могут быть такие атрибуты как «Номер зачетной книжки», «Фамилия», «Имя», «Пол», «Возраст», «Средний балл» и т.п. Атрибуты изображаются в прямоугольнике, обозначающем сущность (рис. 16, б).

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

Связь – это отношение одной сущности к другой или к самой себе. Возможно по одной сущности находить другие, связанные с ней. Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «СОТРУДНИК обязан числиться точно в одном ОТДЕЛЕ». Графически связь изображается линией, соединяющей две сущности (рис. 17):

Рис. 16. Обозначения сущности в нотации Баркера:

а - без атрибутов; б - с указанием атрибутов; в - с ключевым атрибутом

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

Рис. 17. Пример связи между сущностями

Связь может иметь один из следующих типов:

Рис. 18. Типы связей

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

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

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

Каждая связь может иметь одну из двух модальностей связи:

Рис. 19. Модальности связей

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

Слева направо: «Сотрудник может иметь несколько детей».

Справа налево: «Ребенок должен принадлежать точно одному сотруднику».

6.2. Пример разработки простой ER-диаграммы

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

· хранить информацию о покупателях;

· печатать накладные на отпущенные товары;

· следить за наличием товаров на складе.

Выделим все существительные в этих предложениях – это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

· Покупатель – явный кандидат на сущность.

· Накладная – явный кандидат на сущность.

· Товар – явный кандидат на сущность

· (?)Склад – а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

· (?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями – "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

Рис. 20. Первый вариант ER-диаграммы

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

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

Рис. 21. Промежуточный вариант ER-диаграммы

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

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

· каждый товар имеет наименование, цену, а также характеризуется единицами измерения;

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

· каждый склад имеет свое наименование;

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

· Юридическое лицо – термин риторический, мы не работаем с физическими лицами. Не обращаем внимания;

· Наименование покупателя – явная характеристика покупателя;

· Адрес – явная характеристика покупателя;

· Банковские реквизиты – явная характеристика покупателя;

· Наименование товара – явная характеристика товара;

· (?)Цена товара – похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

· Единица измерения – явная характеристика товара;

· Номер накладной – явная уникальная характеристика накладной;

· Дата накладной – явная характеристика накладной;

· (?)Список товаров в накладной – список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;

· (?)Количество товара в накладной – это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной";

· (?)Цена товара в накладной – опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

· Сумма накладной – явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;

· Наименование склада – явная характеристика склада.

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

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

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму:

Рис. 22. Окончательный вариант ER-диаграммы

Порядок выполнения работы:

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

2. Оформить пояснительную записку к эскизному проекту в соответствии с ГОСТ 2.119-73 Эскизный проект (см. приложение 4).

3. Определить спецификации процессов.

4. Определить диаграммы переходов состояний.

5. Определить функциональные диаграммы (верхнего уровня и детализирующую).

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

7. Определить диаграммы «сущность-связь», если в задании присутствует база данных.

Примечание: При выполнении пп. 3 – 7 желательно использовать MS Visio.

8. Добавить словарь терминов.

9. Оформить все полученные результаты в виде приложений к эскизному проекту.

10. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Пояснительную записку к эскизному проекту:

· все полученные диаграммы;

· спецификации процессов;

· словарь;

· выбор метода решения и языка программирования.

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

1. Этапы разработки программного обеспечения.

2. Постановка задачи и предпроектные исследования.

3. Функциональные и эксплуатационные требования к программному продукту.

4. Составляющие эскизного проекта.

5. Спецификации и модели.

6. Диаграммы потоков данных.

7. Функциональные диаграммы.

8. Диаграммы переходов состояний.

9. Диаграммы «сущность-связь».

10. Факторы, влияющие на разработку программного обеспечения.

Лабораторная работа № 3

Структурный подход к программированию. Стадия

«Технический проект»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

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

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

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

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

Таблица 1

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

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

Программа

ввести данные

найти максимум введенных данных

вывести результаты

Конец.

Детализация 1.1. Ввод данных можно детализировать на псевдокоде следующим образом:

Ввести данные:

определить количество чисел

Цикл-пока не все элементы введены

прочитать и запомнить значение элемента

Все-цикл

Детализация 1.2. Отыскание максимума можно детализировать следующим образом:

Найти максимум:

выбрать в качестве максимума первый элемент данных

сравнить все значения с максимумом, заменяя текущий максимум

на очередное значение, если оно не превысило его

Детализация 1.3. Вывод результатов можно детализировать следующим образом:

Цикл-пока не все элементы выведены

вывести значение элемента

Все-цикл

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

Найти максимум:

выбрать в качестве максимума первый элемент данных

Цикл-пока не все элементы проверены

сравнить все значения с максимумом

Если текущее значение больше максимума

Максимум = текущее значение

Конец-если

Конец-цикл

Задача в приведенном примере проста и не требует разбиения на модули.

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

Структурные карты Джексона

Техника структурных карт Джексона основана методе структурного программирования Джексона, который выявляет соответствие между структурой потоков данных и структурой программы. Основное внимание в методе сконцентрировано на соответствии входных и выходных потоков данных. Структуры на диаграммах Джексона строятся из четырех основных компонентов, представленных на рис. 10:

q операция – блок кодов, имеющий один вход и один выход (рис. 10, а);

q следование – последовательное выполнение операций слева направо (рис. 10, б);

q выбор – выполнение одной из операций в зависимости от выполнения условия (рис. 10, в);

q итерация – многократное выполнение блока (рис. 10, г).

Рис. 10. Элементы структурных диаграмм Джексона.

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

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

Программа

Цикл-пока не конец файла

Прочитать запись

Сравнить заданные поля с критерием поиска

Если совпали

Сохранить в выходной список

Конец-если

Конец-цикл

Вывод результирующего списка

Конец-программа

Полученная структурная карта Джексона приведена на рис. 11.

Рис 11. Структурная карта Джексона

Порядок выполнения работы:

1. На основе технического задания из лабораторной работы № 1 и эскизного проекта из лабораторной работы № 2 оформить пояснительную записку к техническому проекту в соответствии с ГОСТ 2.120-73 Технический проект (см. приложение 5).

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

3. Разработать функциональную схему программного продукта.

4. Уточнить алгоритмы программ, разработанные в лабораторной работе № 2, используя метод пошаговой детализации.

5. Представить структурную схему в виде структурных карт Константайна.

6. Представить структурную схему в виде структурных карт Джексона.

7. Оформить результаты, используя MS Office или MS Visio в виде приложений к техническому проекту (структурные и функциональные схемы).

8. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен включать в себя:

1. Структурную схему программного продукта.

2. Функциональную схему.

3. Алгоритмы программ.

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

5. Структурные карты Джексона.

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

1. Этапы разработки программного обеспечения.

2. Проектирование программного обеспечения.

3. Структурный подход к программированию.

4. Метод пошаговой детализации при разработке алгоритмов программ.

5. Структурная и функциональная схемы.

6. Методика Константайна.

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

Лабораторная работа № 4

Этапы разработки программного обеспечения. Стадия

«Реализация»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

Составление программной документации

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

Виды программных документов

Документирование программного обеспечения осуществляется в соответствии с Единой системой программной документации (ГОСТ 19.XXX). ГОСТ 19.101-77 содержит виды программных документов для программного обеспечения различных типов. В данном ГОСТе перечислены документы следующих типов:

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

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

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

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

q ведомость эксплуатационных документов (код вида документа – 20) должна содержать перечень эксплуатационных документов на программу, к которым относятся документы с кодами: 30, 31, 32, 33, 34, 35, 46. Необходимость этого документа также определяется на этапе разработки и утверждения технического задания;

q формуляр (код вида документа – 30) должен содержать основные характеристики программного обеспечения, комплектность и сведения об эксплуатации программы;

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

q руководство системного программиста (код вида документа – 32) должно содержать сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения;

q руководство программиста (код вида документа – 33) должно содержать сведения для эксплуатации программного обеспечения.

q руководство оператора (код вида документа – 34) содержит сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения программы;

q описание языка (код вида документа – 35) – описание синтаксиса и семантики языка программы;

q руководство по техническому обслуживанию (код вида документа – 46) содержит сведения для применения программы при обслуживании технических средств.

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

Порядок выполнения работы:

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

2. Отладить программный модуль.

3. Получить результаты работы.

4. Оформить документацию к разработанному программному обеспечению.

5. Сдать и защитить работу.

Защита отчета по лабораторной работе

Отчет по лабораторной работе должен включать в себя:

1. Интерфейс пользователя.

2. Саму программу.

3. Документацию к программному обеспечению:

· спецификацию;

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

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

4. Результаты работы программ.

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

1. Этап реализации и отладки программного обеспечения.

2. Инструментальные средства разработки.

3. Стихийное программирование.

4. Структурное и модульное программирование.

5. Объектное и компонентное программирование.

6. Документация к программному обеспечению.

Лабораторная работа № 5

Проектирование программной системы при объектном подходе к программированию

Цель работы: познакомить студентов с методом проектирования программной системы путем CRC-карт.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в издании [1, 2].

Теория:

Основы UML - проектирования

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

Одним из способов проектирования является метод CRC-карточек. Этот метод проектирования является составляющей UML-проектирования.

Шаг первый

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

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

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

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

q студент (тестируемый);

q администратор (он же преподаватель, он же составитель тестов).

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

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

Название варианта Цель Действующие лица (актеры) Краткое описание Тип варианта

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

Подробное описание варианта использования Прохождение теста

Действия исполнителя	Отклик системы
1. Студент вводит свои данные (ФИО, Группа), т.е. регистрируется в системе	2. Система создает на диске файл с результатом тестирования и предлагает выбрать тест.
3. Студент выбирает тест	4. Система запускает тест
5. Студент последовательно отвечает на вопросы	6. Система регистрирует правильные и неправильные ответы
7. Студент завершает тестирование	8. Система подсчитывает процент правильных ответов
9. Студент ожидает результат	10. Система демонстрирует результат и предлагает сохранить его
11. Студент решает, сохранять результат или нет.	12. Если выбрано сохранение, система записывает результат в файл.
13. Студент завершает работу.	14. Система завешает работу.

Шаг второй

Для лучшего понимания структуры программы строится диаграмма вариантов использования, (диаграмма прецедентов):

Пример диаграммы прецедентов системы «Банкомат» изображен на рис. 1.

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

Рис. 1. Диаграмма вариантов использования «Банкомат»

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

Шаг третий

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

Придумать можно много (таймер, счетчик купюр, карточка и т.д.).

Далее оформляются CRC-карты. Это листки бумаги 10x15. Они разделены на 3 части и выглядят следующим образом:

Рис. 2. Оформление CRC-карты

Ниже приведен набор СРС-карт для примера с банкоматом:

Шаг четвертый

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

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

· диаграммы кооперации.

4.1. Диаграмма последовательности событий

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

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

q идентифицировать каждое действующее лицо (объект) и изобразить для него линию жизни. Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия (объект 1 на рис. 3). Правее изображается другой объект, который непосредственно взаимодействует с первым и т.д.;

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

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

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

4.1.1. Линия жизни объекта

Линия жизни объекта (object lifeline) служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. На диаграмме линия жизни изображается пунктирной вертикальной линией, ассоциированной с единственным объектом. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней (объекты 1 и 2 на рис. 3).

Если объекты разрушаются в какой-то момент для освобождения ресурсов системы, то их линия жизни обрывается в момент уничтожения. Для обозначения такого момента в языке UML используется специальный символ в форме латинской буквы "X" (объект 3 на рис. 3). Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий.

4.1.2. Фокус управления

Объекты на диаграмме последовательности могут находиться в двух состояниях: активном – непосредственно выполняя какие-либо действия и пассивном – ожидая сообщения от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника (см. объект 1 на рис. 3), верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона – окончание фокуса управления (окончание активности).

4.1.3. Сообщения

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

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

Рис. 3. Графические примитивы диаграммы последовательности

Диаграмма последовательности событий для нашего примера (Система банкомата) приведена на рис. 4.

Рис. 4. Диаграмма последовательности событий

4.2. Диаграмма кооперации (сотрудничества)

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

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

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

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

Решение приведено на рис. 5.

Рис. 5. Пример диаграммы кооперации

Заметим, что на приведенной диаграмме объекты классов «Отдел» и «Сотрудник» реализованы мультиобъектами.

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

Порядок выполнения работы:

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

2. Определить варианты использования системы и описать их в краткой или полной форме.

3. Построить диаграмму вариантов использования системы (использовать MS Office или MS Visio).

4. Определить классы проектируемой системы.

5. Создать CRC-карты для всех классов системы (использовать MS Office или MS Visio).

6. Построить диаграммы взаимодействия (использовать MS Office или MS Visio).

7. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Описание действующих лиц и прецедентов системы.

3. Диаграмму прецедентов.

4. CRC-карты.

5. Диаграммы взаимодействия.

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

1. Проектирование ПО при объектном подходе.

2. Моделирование предметной области при проектировании ПО.

3. Язык UML. Его назначение, преимущества и недостатки.

4. Варианты использования ПО.

5. Диаграммы в языке UML.

6. Диаграммы прецедентов.

7. Диаграммы взаимодействия.

8. Назначение и использование CRC-карт.

Варианты заданий:

1. Заказ билетов в аэропорту.

2. Электронный магазин.

3. Отправка sms.

4. Система охраны частного дома.

5. Пропускная система.

6. Система безопасности тюрьмы.

7. Система безопасности полета самолета.

8. Компьютерная система тестирования для оценки знаний студентов.

9. Заказ билетов в театральной кассе.

10. Телефонный коммутатор.

11. Система учета успеваемости студентов деканатом.

12. Записная книжка.

13. Пропускная система биоконтроля.

14. Автомат платежной системы.

15. Электронная почта.

Лабораторная работа № 6

Тестирование программ методами «белого ящика»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в издании [1, 3].

Теория:

Тестирование программного обеспечения

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

· постановка задачи для теста;

· проектирование теста;

· написание тестов;

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

· выполнение тестов;

· изучение результатов тестирования.

Виды тестов

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

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

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

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

Тестирование методом «белого ящика» также не дает стопроцентной гарантии того, что модуль не содержит ошибок. Даже если предположить, что выполнены тесты для всех ветвей алгоритма, нельзя с полной уверенностью утверждать, что программа соответствует ее спецификациям. Например, если требовалось написать программу для вычисления кубического корня, а программа фактически вычисляет корень квадратный, то реализация будет совершенно неправильной, даже если проверить все пути. Вторая проблема – отсутствующие пути. Если программа реализует спецификации не полностью (например, отсутствует такая специализированная функция, как проверка на отрицательное значение входных данных программы вычисления квадратного корня), никакое тестирование существующих путей не выявит такой ошибки. И, наконец, проблема зависимости результатов тестирования от входных данных. Одни данные будут давать правильные результаты, а другие нет. Например, если для определения равенства 3 чисел программируется выражение вида:

IF (A+B+C)/3 = A,

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

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

Стратегия «белого ящика»

Существуют следующие методы тестирования по принципу «белого ящика»:

q покрытие операторов;

q покрытие решений;

q покрытие условий;

q покрытие решений/условий;

q комбинаторное покрытие условий.

2.1. Метод покрытия операторов

Целью этого метода тестирования является выполнение каждого оператора программы хотя бы один раз.

Пример:

Рис. 1. Пример алгоритма программы

а – правильный; б – с ошибкой

Если для тестирования задать значения переменных А=2, В=0, Х=3, будет реализован путь ace, т.е. каждый оператор программы выполнится один раз (рис. 1, а). Но, если внести в алгоритм ошибки – заменить в первом условии and на or, а во втором X > 1 на X < 1 (рис. 1, б), ни одна ошибка не будет обнаружена (см. табл. 1). Кроме того путь abd вообще не будет охвачен тестом и, если в нем есть ошибка, она также не будет обнаружена. В табл. 1 ожидаемый результат определяется по блок-схеме на рис. 1-а, а фактический по рис. 1-б.

Как видно из этой таблицы, ни одна из внесенных в алгоритм ошибок не будет обнаружена.

Таблица 1

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=3	X=2,5	X=2,5	неуспешно

2.2. Метод покрытия решений (покрытия переходов)

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

Для программы приведенной на рис. 1 покрытие решений может быть выполнено двумя тестами, покрывающими пути {ace, abd}, либо {aсd, abe}. Для этого выберем следующие исходные данные: {A=3, B=0, X=3} – в первом случае и {A=2, B=1, X=1} – во втором. Однако путь, где X не меняется, будет проверен с вероятностью 50%: если во втором условии вместо условия X > 1 записано X < 1, то ошибка не будет обнаружена двумя тестами.

Результаты тестирования приведены в табл. 2.

Таблица 2

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=3, B=0, X=3	X=1	X=1	неуспешно
А=2, В=1, Х=1	Х=2	Х=1,5	успешно

2.3. Метод покрытия условий

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

В рассматриваемом примере имеем четыре условия: {A>1, B=0}, {A=2, X>1}. Следовательно, требуется достаточное число тестов, такое, чтобы реализовать ситуации, где A>1, A£1, B=0 и B¹0 в точке а и A=2, A¹2, X>1 и X£1 в точке b. Тесты, удовлетворяющие критерию покрытия условий и соответствующие им пути:

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd

Результаты тестирования приведены в табл. 3.

Таблица 3

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=1, B=1, X=0	X=0	X=1	успешно

2.4. Метод покрытия решений/условий

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

Недостатки метода:

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

q невозможно проверить условия, которые скрыты другими условиями;

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

Так в рассматриваемом примере два теста метода покрытия условий

а) A=2, B=0, X=4 ace

б) A=1, B=1, X=0 abd

отвечают и критерию покрытия решений/условий. Это является следствием того, что одни условия приведенных решений скрывают другие условия в этих решениях. Так, если условие А>1 будет ложным, транслятор может не проверять условия В=0, поскольку при любом результате условия В=0, результат решения ((А>1)&(В=0)) примет значение ложь. Т.е. в варианте на рис. 1 не все результаты всех условий выполнятся в процессе тестирования.

Рассмотрим реализацию того же примера на рис. 2. Наиболее полное покрытие тестами в этом случае выполняется так, чтобы выполнялись все возможные результаты каждого простого решения. Для этого нужно покрыть пути aceg (тест А=2,В=0,Х=4), acdfh (тест А=3, В=1, Х=0), abfh (тест А=0, В=0, Х=0), abfi (тест А=0, В=0, Х=2)..

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

Рис. 2. Пример алгоритма программы

2.5. Метод комбинаторного покрытия условий

Критерий комбинаторного покрытия условий удовлетворяет также и критериям покрытия решений, покрытия условий и покрытия решений/условий.

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

1. A>1, B=0.

2. A>1, B¹0.

3. A£1, B=0.

4. А£1, B¹0.

5. A=2, X>1.

6. A=2, X£1.

7. А¹2, X>1.

8. А¹2, X£1.

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

q A=2, B=0, X=4 {покрывает 1, 5};

q A=2, B=1, X=1 {покрывает 2, 6};

q A=0,5, B=0, X=2 {покрывает 3, 7};

q A=1, B=0, X=1 {покрывает 4, 8}.

Таблица 4

Тест	Ожидаемый результат	Фактический результат	Результат тестирования
A=2, B=0, X=4	X=3	X=3	неуспешно
A=2, B=1, X=1	X=2	X=1,5	успешно
A=0,5 B=0, X=2	X=3	X=4	успешно
A=1, B=0, X=1	X=1	X=1	неуспешно

Порядок выполнения работы:

1. Разработать схему алгоритма в соответствии с вариантом. Обозначить буквами или цифрами ветви алгоритма.

2. Спроектировать тесты по принципу «белого ящика» методами покрытия операторов, решений, условий, решений/условий и комбинаторного покрытия условий. Если разные методы покрываются одним и тем же набором тестов использовать один набор.

3. Выписать пути алгоритма, которые должны быть проверены тестами для каждого метода.

4. Внести в алгоритм несколько ошибок.

5. Протестировать разработанную Вами программу. Результаты оформить в виде таблиц (см. таблицы 1 - 4).

6. Проверить все виды тестов и сделать выводы об их эффективности.

7. Оформить отчет по лабораторной работе.

8. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Блок-схемы программ.

3. Тесты.

4. Таблицы тестирования программы.

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

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

1. Этап реализации и тестирования программного продукта.

2. Виды тестирования.

3. Критерии выбора тестов.

4. Свойства тестов.

5. Критерии надежности программ.

6. Оценка надежности программ.

Варианты задания:

Задача 1.

Разработать программу решения уравнения , где a, b, c - любые вещественные числа.

Задача 2.

Разработать программу определения суммарной длины тени, которую отбрасывают на ось ОХ отрезки, параллельные этой оси и заданные координатами x начала и конца отрезка:

Задача 3.

Разработать программу исследования уравнений второго порядка с двумя неизвестными Ax²+2Bxy+Cy2+2Dx+2Ey+F=0. Программа должна определять вид графика: эллипс, парабола, гипербола, две пересекающиеся прямые, две параллельные прямые, две мнимые прямые.

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

большому: и малому .

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

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

Задача 4.

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

Задача 5.

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

Задача 6.

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

Примечание. Две прямые лежат в одной плоскости, если

, прямые параллельны если ,

где l = x ₂ - x ₁ , m = y ₂ - y ₁ , n = z ₂ - z ₁ (верхний индекс соответствует номеру прямой).

Лабораторная работа № 7

Тестирование программ методами «черного ящика»

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

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

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

2. Изучить соответствующие разделы в литературе [1, 3].

Теория:

Тестирование по принципу «черного ящика»

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

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

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

Правильно выбранный тест подмножества должен обладать следующими свойствами:

1) уменьшать, причем более чем на единицу число других тестов, которые должны быть разработаны для достижения заранее определенной цели «приемлемого» тестирования:

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

Стратегия "черного ящика" включает в себя следующие методы формирования тестовых наборов:

¨ эквивалентное разбиение;

¨ анализ граничных значений;

¨ анализ причинно-следственных связей;

¨ предположение об ошибке.

Эквивалентное разбиение

Основу метода составляют два положения:

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

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

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

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

¨ выделение классов эквивалентности;

¨ построение тестов.

Построение тестов

Этот шаг заключается в использовании классов эквивалентности для построения тестов. Этот процесс включает в себя:

· назначение каждому классу эквивалентности уникального номера;

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

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

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

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

Анализ граничных значений

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

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

¨ при разработке тестов рассматриваются не только входные условия (пространство входов), но и пространство результатов;

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

· построить тесты для границ области и тесты с неправильными входными данными для ситуаций незначительного выхода за границы области, если входное условие описывает область значений (например, для области входных значений от -1.0 до +1.0 необходимо написать тесты для ситуаций -1.0, +1.0, -1.001 и +1.001);

· построить тесты для минимального и максимального значений условий и тесты, большие и меньшие этих двух значений, если входное условие удовлетворяет дискретному ряду значений. Например, если входной файл может содержать от 1 до 255 записей, то проверить 0, 1, 255 и 256 записей;

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

· использовать правило 2 для каждого выходного условия;

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

· попробовать свои силы в поиске других граничных условий.

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

3. Анализ причинно-следственных связей

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

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

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

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

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

Примечание. При этом можно использовать следующие приемы:

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

· Истина обозначается "1". Ложь обозначается "0". Для обозначения безразличных состояний условий применять обозначение "Х", которое предполагает произвольное значение условия (0 или 1).

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

Недостаток метода заключается в том, что он неадекватно исследует граничные условия.

Предположение об ошибке

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

5. Пример применения методов тестирования «черным ящиком»

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

В основе программы лежит решение системы линейных уравнений:

Ax + By = C и Dx + Ey = F.

5.1. Метод эквивалентных разбиений

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

1) все коэффициенты - вещественные числа;

2)- 7) поочередно каждый из коэффициентов - не вещественное число.

5.2. Метод граничных условий

Можно считать, что для исходных данных граничные условия отсутствуют (коэффициенты - "любые" вещественные числа).

Для результатов - получаем, что возможны варианты: единственное решение, прямые сливаются (множество решений), прямые параллельны (отсутствие решений). Следовательно, можно предложить тесты, с результатами внутри области:

1) результат - единственное решение (d ¹ 0);

2) результат - множество решений (d = 0 и d_x=d_y=0);

3) результат - отсутствие решений (d = 0, но d_x¹0 или d_y¹0);

и с результатами на границе:

1) d = 0,01;

2) d = -0,01;

3) d = 0, d_x= 0,01, d_y= 0;

4) d = 0, d_y= -0,01, d_x= 0.

5.3. Метод анализа причинно-следственных связей

Определяем множество условий.

а) для определения типа прямой:

- для определения типа и существования первой прямой;

- для определения типа и существования второй прямой;

б) для определения точки пересечения:

d = 0

d_x = 0

d_y = 0

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

A=0	B=0	C=0	Результат
0	0	X	прямая общего положения
0	1	0	прямая, параллельная оси ОХ
0	1	1	ось ОХ
1	0	0	прямая, параллельная оси ОУ
1	0	1	ось ОУ
1	1	Х	множество точек плоскости

Такая же таблица строится для второй прямой.

d = 0	d_x= 0	d_y= 0	Ед. реш.	Мн.реш.	Реш. нет
0	X	X	1	0	0
1	0	X	0	0	1
1	X	0	0	0	1
1	1	1	0	1	0

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

В результате к уже имеющимся тестам добавляются:

1) проверки всех случаев расположения обеих прямых - 6 тестов по первой прямой вкладываются в 6 тестов по второй прямой так, чтобы варианты не совпадали, - 6 тестов;

2) выполняется отдельная проверка несовпадения условия d_x = 0 или d_y = 0 (в зависимости от того, какой тест был выбран по методу граничных условий) - тест также можно совместить с предыдущими 6 тестами;

5.4. Метод предположения об ошибке

Добавим еще один тест: все коэффициенты - нули.

Всего получили 20 тестов по всем четырем методикам. Если еще попробовать вложить независимые проверки, то возможно число тестов можно еще сократить. (Не забудьте для каждого теста заранее указывать результат!).

Теория:

Сетевые приложения

Для поддержки сетевых приложений существует технология, названная "сокеты". Сокет - это модель одного конца соединения, со всеми присущими ему свойствами и методами. По сути, это прикладной программный интерфейс, входящий в состав многих операционных систем (ОС) и призванный для поддержки сетевых возможностей ОС. В стандарте структуры протоколов семиуровневой модели OSI-сокеты лежат на так называемом транспортном уровне, ниже находится сетевой протокол ip, а выше - протоколы сеансового уровня, такие как ftp, pop3, smtp и т.д.

В windows поддержка сокетов включена, начиная с версии 3.11, и названа winsock. Для написания приложений с сетевой поддержкой существует специальный winsock api.

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

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

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

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

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

Рассмотрим минимальный набор функций из winsock api, необходимых для написания элементарного клиента и сервера. Сами функции находятся в файле winsock.dll. Файл winsock.pas содержит необходимые объявления импортируемых функций winsock api и базовые структуры данных. К сожалению, этот файл импортирует не все необходимые нам функции, и позже мы напишем свой файл импорта.

function wsastartup(wversionrequired: word; var wsdata: twsadata): integer; stdcall;

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

function wsacleanup: integer; stdcall;

Функция сообщает ОС, что приложение более не использует winsock. Должна быть вызвана перед завершением приложения.

function socket(af, struct, protocol: integer): tsocket; stdcall;

Функция создает сокет. Порт и адрес задается в функции bind (сервер) или connect (клиент). Входящий параметр af - спецификация семейства сокетов (af_inet, af_ipx и др.), struct - спецификация типа нового сокета (принимает значение sock_stream или sock_dgram), protocol- специфический протокол, который будет использоваться сокетом. Если функция выполнена без ошибок, она возвращает дескриптор на новый сокет, если ошибки есть, возвращается invalid_socket.

function connect(s: tsocket; var name: tsockaddr; namelen: integer): integer; stdcall;

Функция соединения для клиента. Структура адреса содержит порт (необходимо привести функцией htons) и адрес (для клиента необходимо привести из имени или спецификации ip4 - xxx.xxx.xxx.xxx).

function bind(s: tsocket; var addr: tsockaddr; namelen: integer): integer; stdcall;

Функция ассоциирует адрес с сокетом. Структура адреса содержит порт (необходимо привести функцией htons) и адрес (для сервера обычно указывается inaddr_any - любой).

function send(s: tsocket; var buf; len, flags: integer): integer; stdcall;

Функция отправки данных. Помещает в очередь сокета s кусок данных из buf, длиной len. Последний параметр отвечает за вид передачи сообщения. Может быть проигнорирован (0).

function recv(s: tsocket; var buf; len, flags: integer): integer; stdcall;

Функция получение данных.

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

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

program winsock_server;

//Простейшее приложение-сервер.

//Сокеты работают в блокирующем режиме.

//На каждое соединение создается отдельный поток.

{$apptype console}

uses

sysutils,

winsock,

windows;

var

vwsadata : twsadata;

vlistensocket,vsocket : tsocket;

vsockaddr : tsockaddr;

trid : thandle;

const

cport = word(33);

csigexit = 'q';

//Процедура отдельного потока для каждого клиента.

procedure socketthread;

var sockname : tsockaddr;

abuf : array of char;

vbuf : string;

vsize : integer;

s :tsocket;

bufsize : integer;

begin

s := vsocket;

if s = invalid_socket then exit;

vsize := sizeof(tsockaddr);

getpeername(s, sockname, vsize);

writeln(format('client accepted, remote address [%s].',[inet_ntoa (sockname.sin_addr)]));

//Определяем размер буфера чтения для сокета

vsize := sizeof(bufsize);

getsockopt(s,sol_socket,so_rcvbuf,pchar(@

bufsize),vsize);

writeln(format('receive buffer size [%d]',[bufsize]));

setlength(abuf,bufsize);

repeat

//Получаем данные. Процедура работает в блокирующем режиме,

//таким образом следующая строка кода не получит управление,

//пока не поступят данные от клиента.

vsize := recv(s,abuf[0],bufsize,0);

if vsize<=0 then break;

setlength(vbuf,vsize);

lstrcpyn(@vbuf[1],@abuf[0],vsize);

writeln(format('received from cleint: %s',[vbuf]));

until vbuf = 'q';

writeln(format('client disconnected, remote address [%s].',[inet_ntoa(sockname.sin_addr)]));

setlength(abuf,0);

closesocket(s);

end;

begin

writeln('starting application...');

//Объявляем, что программа будет использовать windows sockets.

if wsastartup($101,vwsadata)<>0 then halt(1);

writeln('using windows sockets.');

//Создаем прослушивающий сокет.

vlistensocket := socket(af_inet,sock_stream,ipproto_ip);

writeln(format('creating socket on port [%d].',[cport]));

if vlistensocket = invalid_socket then halt(1);

fillchar(vsockaddr,sizeof(tsockaddr),0);

vsockaddr.sin_family := af_inet;

vsockaddr.sin_port := htons(cport);

vsockaddr.sin_addr.s_addr := inaddr_any;

writeln('binding socket...');

//Привязываем адрес и порт к сокету.

if bind(vlistensocket,vsockaddr,sizeof(tsockaddr)) <> 0

then halt(1);

//Начинаем прослушивать.

if listen(vlistensocket,somaxconn) <> 0

then halt(1);

writeln('socket status: listening.');

repeat

//Ожидаем подключения.

vsocket := accept(vlistensocket,nil,nil);

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

createthread(nil,0,@socketthread,0,0,trid);

until false;

closesocket(vlistensocket);

wsacleanup;

end.

В тексте программы использована не описанная ранее функция getpeername (), которая возвращает информацию о канале, ассоциированном с сокетом. В данном контексте она нужна для получения информации о ip-адресе подключившегося клиента. Подробно об этой функции, как и о всех других функциях winsock, можно прочитать в windows sockets 2 application program interface, входящем в состав win32 programmer's reference.

Приведенный выше код можно использовать только как учебное пособие. Для того, чтобы использовать его в качестве основы для настоящего приложения, необходимо некоторое количество доработок, т.к. многие вещи, которые могут привести в будущем к серьезным ошибкам, были сознательно опущены для уменьшения размера кода и акцентирования внимания именно на аспектах использования winsock. Если вы недостаточно хорошо знакомы с понятием потоков (threads) в windows, то вам лучше использовать класс tthread, существующий в delphi специально для поддержки многопоточных приложений.

Исходный код клиента представлен ниже:

program winsock_client;

{$apptype console}

uses

sysutils,

winsock;

const

cport = 33;

csigexit = 'q';

var

vwsadata : twsadata;

vsocket : tsocket;

vsockaddr : tsockaddr;

buf : string;

begin

if wsastartup($101,vwsadata)<>0 then halt(1);

vsocket := socket(af_inet,sock_stream,ipproto_ip);

if vsocket = invalid_socket then halt(1);

fillchar(vsockaddr,sizeof(tsockaddr),0);

vsockaddr.sin_family := af_inet;

vsockaddr.sin_port := htons(cport);

vsockaddr.sin_addr.s_addr := inet_addr('127.0.0.1');

if connect(vsocket,vsockaddr,sizeof(tsockaddr)) = socket_error then halt(1);

repeat

readln(buf);

if send(vsocket,buf[1],length(buf),0) = socket_error then break;

until buf = csigexit;

closesocket(vsocket);

wsacleanup;

end.

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

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

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

function select(nfds: integer; readfds, writefds, exceptfds: pfdset; timeout: ptimeval): longint; stdcall;

Эта функция позволяет контролировать состояние набора сокетов

Аргумент nfds игнорируется и оставлен только для совместимости. Должен быть равен 0. readfs, writefds, exceptfds - указатели на наборы сокетов, для которых нужно контролировать состояние чтения, отправки данных и ошибок соответственно. Наборы хранятся в структуре pfdset, управление которой осуществляется специальными макросами, описанными в winsock.pas:

procedure fs_zero(var fdset: tfdset) - обнуляет структуру, устанавливает количество контролируемых сокетов в 0;

procedure fd_set(socket: tsocket; var fdset: tfdset) - добавляет указанный сокет в структуру;

procedure fd_clr(socket: tsocket; var fdset: tfdset) - удаляет указанный сокет из структуры;

function fd_isset(socket: tsocket; var fdset: tfdset): boolean - возвращает true, если указанный сокет является членом указанной структуры.

Аргумент timeout является ссылкой на структуру типа ptimeval, в которой можно указать время ожидания срабатывания функции select. В случае указания в качестве значения времени задержки 0 или nil в качестве аргумента timeout функция select будет ждать бесконечно, как при выполнении операции в блокирующем режиме.

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

Давайте рассмотрим логику работы во втором случае, так как первый случай банален.

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

arg := 1;

ioctlsocket(socket,fionbio,arg);

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

arg := 0;

ioctlsocket(socket, fionbio, arg);

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

новые используемые переменные wfds :tfdset ; i : integer; tv : ttimeval;

Затем определим основной цикл, в котором будем обрабатывать данные:

repeat

...

until connum>0;

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

fd_zero(wfds);

for i:=1 to connum do

begin

fd_set(sock[i],wfds);

end;

Далее, указываем в структуре tv время задержки для функции select:

tv.tv_sec := 5;

tv.tv_usec := 0;

Теперь можно вызывать функцию select (т.к. мы следим только за приемом данных, то в качестве writefds, exceptfds мы указываем nil):

select(0,@wfds,nil,nil,@tv);

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

if wfds.fd_count=0 then continue;

for i:=0 to wfds.fd_count-1 do

begin

vsocket := wfds.fd_array[i];

//Обработка поступивших данных с сокета vsocket.

end;

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

Давайте теперь разберемся, для чего мы указали время ожидания функции send, а не сделали его бесконечным? Дело в том, что в текущей реализации, при создании нового сокета, он не попадет в обработку select, пока не будет установлен функцией fs _ set, что, естественно, не пройдет в блокирующем режиме, пока select не возвратит управление по событию с одним из отслеживаемых клиентов. Установка значения timeout гарантирует, что сокет попадет в обработку независимо от состояния других сокетов.

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

Помимо функции select существует еще два метода работы с асинхронными сокетами:

function wsaasyncselect(s: tsocket; hwindow: hwnd; wmsg: u_int; levent: longint): integer; stdcall;

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

const

wm_mysocket = wm_user + 1;

...

type

tform1 = class(tform)

...

private

procedure socket_proc(var msg:tmessage);message wm_mysocket;

...

wsaasyncselect(vsocket,form1.handle,wm_

mysocket,fd_accept+fd_read);

....

procedure tform1.socket_proc(var msg: tmessage);

begin

if ((msg.msg = wm_mysocket)

and (msg.lparam = fd_accept))

then showmessage('connected');

end;

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

function wsaeventselect(s: tsocket; event: thandle; levent: longint):integer;stdcall;

external 'ws2_32.dll' name 'wsaeventselect';

function wsawaitformultipleevents(ncount: dword; lphandles: pwohandlearray;

bwaitall: bool; dwmilliseconds: dword; falertable:bool):integer;stdcall;

external 'ws2_32.dll' name 'wsawaitformultipleevents';

function wsacreateevent:thandle;stdcall;

external 'ws2_32.dll' name 'wsacreateevent';

function wsaresetevent(event : thandle):bool;stdcall;

external 'ws2_32.dll' name 'wsaresetevent';

function wsaenumnetworkevents(const s : tsocket;

const event : thandle; lpnetworkevents : lpwsanetworkevents): longint ;

stdcall;far;

external 'ws2_32.dll' name 'wsaenumnetworkevents';

function wsacloseevent(event : thandle):integer;

stdcall; external 'ws2_32.dll' name 'wsacloseevent';

Также нам потребуется описание структуры wsanetworkevents

const

fd_max_events = 10;

type

twsanetworkevents = record

lnetworkevents: longint;

ierrorcode: array[0..fd_max_events-1] of integer;

end;

pwsanetworkevents = ^twsanetworkevents;

lpwsanetworkevents = pwsanetworkevents;

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

Затем, в цикле обработки мы организуем ожидание поступления события от сокета; это реализуется с помощью api функций waitforsingleobject - для ожидания одного события, либо waitformultipleobjects - для ожидания набора событий. При наступлении события функция возвращает управление. Для однозначной идентификации, от какого сокета пришло уведомление используется функция wsaenumnetworkevents, возвращающая структуру типа twsanetworkevents.

var

fevent : thandle;

//Создаем серверный сокет

...

feventclose := wsacreateevent;

wsaeventselect(socket,fevent, fd_close + fd_read );

repeat

waitforsingleobject(fevent,infinite);

wsaenumnetworkevents(fsocket,fevent,@ni);

case ni.lnetworkevents of

fd_close:break;

fd_read: begin

receivedata;

end;

wsaresetevent(feventclose);

until false;

wsacloseevent(feventclose);

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

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

send(vsocket,@buf1,length(buf1),0);

send(vsocket,@buf2,length(buf2),0);

фактически будет идентичен одному вызову send с объединенным буфером buf1+buf2.

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

При чтении из сокета данных, мы можем наблюдать как бы "склейку" порций данных, либо, наоборот, фрагментацию (не путать с фрагментацией пакетов на уровне tcp/ip). Такие ситуации должна обрабатывать наша программа. Решить проблему можно добавлением сигнатуры признака конца блока данных. Это имеет смысл, если приложения часто обмениваются небольшими блоками данных, где чаще всего возникает эффект "склеивания", но неэффективно при больших объемах, так как сканирование большого буфера на предмет сигнатуры отнимает много времени. Обычно это решается таким способом - в начале каждого пакета добавляется 32-битное число, определяющее длину порции данных в байтах. Таким образом, принимающая часть, зная размер каждого блока, может распознать "склейку" и фрагментацию.

Об остальных аспектах сетевого программирования с использованием библиотеки winsock вы можете узнать из справки "windows sdk" в разделе "windows sockets 2 application program interface".

Порядок выполнения работы:

1. Написать сетевое приложение с использованием Winsock API, в соответствии с заданным преподавателем вариантом. При этом один компьютер - сервер, другой клиент.

2. Отладить программу.

3. Произвести обмен данными с соседним компьютером.

4. Представить результат преподавателю.

5. Изменить направление клиент - сервер.

6. Еще раз обменяться данными и представить результат преподавателю.

7. Закончить работу с сокетами.

8. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Листинги программ.

2. Результаты работы.

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

1. Сетевое программное обеспечение.

2. Архитектура клиент – сервер.

3. Понятие сокета.

4. Понятие порта.

5. Функции для работы с сокетами.

6. Синхронные и асинхронные операции ввода-вывода.

Варианты заданий:

1. На базе примера написать чат. Программа должна передавать самой себе по WinSocket сообщения в обычном и кодированном виде. Использовать код Цезаря. Суть кода: все буквы сдвинуты на 3 позиции, то есть: "а" шифруется буквой "г", "б" - "д" и так далее, "э" - "а", "ю" - "б", "я" - "в". Аналогично сдвигается английский алфавит.

2. На базе примера написать чат. Программа должна передавать самой себе по WinSocket сообщения с присоединёнными к ним файлами (бинарными в общем случае).

3. Написать интернет-игру. Программа должна передавать самой себе по WinSocket координаты точки. Эта точка должна или рисоваться, или должны выводиться её координаты, либо указывать на ячейку таблицы Excel, либо отображаться каким-либо иным способом.

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

5. Написать распределённую базу данных. Одна программа посылает запросы на получение данных и на сохранение изменений в этих данных. Другая программа работает с таблицей Excel, читает из неё запрашиваемые данные или записывает данные в таблицу.

Таблицу можно не отображать на экране.

6. Написать "защищённую сеть". По нажатию кнопки в диспетчерской программе все указанные соединения должны закрываться. В диспетчерской программе должен быть список открытых соединений. В качестве пользовательских программ использовать пример или программы из 1 - 3 вариантов.

Лабораторная работа № 9

Использование технологий OLE, COM и ActiveX

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

1. Ознакомиться с лекционным материалом по теме " Использование технологий OLE, COM и ActiveX " учебной дисциплины "Технология программирования".

2. Изучить соответствующие разделы в изданиях [2, 5].

Теория:

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

ActiveX и OLE фирмы Microsoft – еще один шаг к более совершенным, т.е. более надежным и эффективным, программам. В основе ActiveX и OLE лежит очень простая идея, но, как оказалось, она позволяет существенно повысить эффективность программирования.

От OLE к ActiveX

Первоначально OLE была задумана как технология интеграции программных продуктов, входящих в комплект Microsoft Office. Предшественницей OLE является реализованная в Windows технология динамического обмена данными DDE (Dynamic Data Exchange), до сих пор широко применяемая в данной среде. Однако многие разработчики не без оснований считают, что DDE трудно использовать, поскольку это технология низкого уровня.

В качестве технологии более высокого уровня была реализована OLE 1.0 OLE 1 (Object Linking and Embedding – связывание и внедрение объектов). Она расширила возможности протокола DDE и, используя его как базовый механизм коммуникаций, позволила активизировать встроенный объект в документе, т. е. получить составной документ. Таким образом, OLE 1.0 унаследовала многие проблемы асинхронного протокола. Эта технология имела множество недостатков, а ее компоновка была слишком сложна для пользователей среднего уровня. Кроме того, установленные связи легко нарушались, например, в результате изменения маршрута доступа к файлу связанного объекта.

С помощью OLE 1 пользователь мог, например, объединить электронную таблицу, созданную Microsoft Excel, с текстовым документом «производства Microsoft Word. Идея состояла в том, чтобы документно-ориентированная (document-centric) модель работы с компьютером позволила бы пользователю больше думать об информации и меньше, о приложениях, ее обрабатывающих. Как следует из слов «связывание и внедрение, составные документы можно создать, либо связав два разных документа, либо полностью внедрив один документ в другой.

OLE 1, как и большинство первых версий программных продуктов, была несовершенна. Архитекторам следующей версии предстояло улучшить первоначальный проект. Вскоре они поняли, что составные документы лишь частный случай более общей проблемы: как разные программные компоненты должны предоставлять друг другу сервисы? Для решения этой проблемы архитекторы OLE создали группу технологий, область применения которых гораздо шире составных документов. Основу OLE 2 составляет важнейшая из этих технологий Модель многокомпонентных объектов (Component Object Model СОМ). Новая версия OLE не только обеспечивает поддержку составных документов лучше, чем первая, но и, несомненно, идет куда дальше простого объединения документов, созданных в разных приложениях. OLE 2 позволяет по-новому взглянуть на взаимодействие любых типов программ.

В начале 1996 года Microsoft ввела в оборот новый термин – ActiveX. Сначала он относился к технологиям, связанным с Интернетом, и приложениям, выросшим из него, вроде WWW (World Wide Web). Поскольку большинство разработок Microsoft в данной области было основано на СОМ, то и ActiveX была непосредственно связана с OLE. Однако очень скоро новый термин стал захватывать территории, традиционно принадлежавшие OLE, и вот теперь все вернулось на круги своя: OLE, как встарь, обозначает только технологию создания составных документов связыванием и внедрением, а разнообразные технологии на основе СОМ, ранее объединенные под именем OLE, собраны под знаменем ActiveX. А некоторые технологии, название которых содержало слово "OLE" даже перекрестили: теперь это технологии ActiveX.

Понятие СОМ

Все технологии OLE и ActiveX, описанные ниже, построены на основании, обеспеченном СОМ. Итак, что же такое СОМ? Чтобы ответить на этот вопрос, зададимся сначала другим: "Каким образом одна часть программного обеспечения должна получать доступ к сервисам, предоставляемым другой частью? " На сегодняшний день ответ зависит от того, что представляют собой эти части:

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

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

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

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

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

Как работает СОМ

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

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

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

Любой СОМ-объект – это экземпляр определенного класса. Объекты одного класса могут, например, реализовывать сервисы корректировки орфографии и словаря синонимов, тогда как объекты другого класса – представлять банковские счета. Обычно знать класс объекта необходимо для запуска экземпляра этого объекта, выполняемого с помощью библиотеки СОМ. Эта библиотека присутствует на любой системе, поддерживающей СОМ, и имеет доступ к справочнику всех доступных на данной машине классов Сом - объектов. Клиент может, например, вызвать функцию библиотеки СОМ, передав ей класс нужного ему СОМ - объекта и задав один из поддерживаемых объектом интерфейсов, указатель которого нужен клиенту в первую очередь. (Эти сервисы реализованы библиотекой СОМ в виде обычных вызовов функций, а не через методы интерфейса СОМ.) Затем библиотека СОМ запускает сервер, реализующий объекты данного класса. Кроме того, библиотека возвращает клиенту указатель требуемого интерфейса вновь созданного экземпляра объекта. Далее клиент может запросить указатели на другие необходимые ему интерфейсы непосредственно у самого объекта.

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

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

Microsoft применяет СОМ в большинстве продуктов; она используется для спецификации расширений Microsoft Windows и Microsoft Windows NT, а также для определения стандартных интерфейсов к различным типам сервисов. Выгоды применения СОМ в разработке всех типов программного обеспечения несомненны.

Составные документы

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

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

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

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

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

Распределенная СОМ

Хотя СОМ с самого начала разрабатывалась с учетом поддержки распределенных систем, ее первоначальная реализация могла работать только на одном компьютере. Объекты СОМ могли быть реализованы в DLL или в отдельном процессе, исполняемом на той же машине, что и их клиент, но не могли располагаться на других машинах в вычислительной сети. Эта ситуация изменилась с появлением распределенной СОМ (Distributed СОМ - DCOM). Теперь объекты СОМ могут предоставлять свои сервисы и клиентам на других машинах.

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

Разработку OLE-контейнеров и серверов проще всего вести в среде VisualC++ при помощи специальных мастеров (например, AppWizard), а также библиотеки MFC.

Порядок выполнения работы:

1. Создать приложение Cnt для этого:

· чтобы приступить к созданию нового проекта, выберите в окне компилятора MicrosoftVisualC++ в меню File команду New;

· в окне New выберите элемент MFC AppWizard(exe), в результате чего будет запущен мастер приложений, работа с которым осуществляется в шесть этапов:

1.1 . В первом окне установите опцию Singledocument.

1.2 . Во втором окне не задавайте поддержку баз данных.

1.3 . В третьем окне установите опцию Container, указывающую на то, что приложение будет OLE-контейнером. В этом же окне следует включить поддержку элементов управления ActiveX.

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

1.5 . В пятом окне установите опцию MFC Standard, опцию включения комментариев в программу и опцию статической компоновки библиотеки MFC.

1.6 . Наконец, в шестом окне, просмотрите список классов, которые будут созданы автоматически, и щелкните на кнопке Finish.

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

· осталось только построить исполняемый файл приложения, выбрав для этого в меню Build команду Rebuild All. В результате в папку DEBUG будет добавлен файл СМТ.ЕХЕ.

2. Проанализировать программный код.

Приложение включает пять основных исходных файлов, сгенерированных мастером AppWizard: CNT.CPP, MAINFRM.CPP, CNTDOC.CPP, CNTVIEW.CPP и CNTRITEM.CPP. Листинги файлов приведены в приложении 2

3. Внести, где это требуется, изменения.

4. Отладить программы.

5. Проверить работоспособность контейнера, для этого:

· запустите приложение Cnt (рисунок 1);

· выберите в меню Edit команду InsertNewObject..., в результате чего откроется стандартное диалоговое окно вставки объекта.

· в этом окне выделите элемент, соответствующий электронной таблице Excel (рисунок 2);

6. Оценить результат (рисунок 3).

7. Создать приложение по выбору преподавателя.

8. Сдать и защитить работу.

Рис. 1. Окно приложения Cnt

Рис. 2. Выбор внедряемого объекта

Рис. 3. Внедрение электронной таблицы Excel в приложение Cnt

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Листинги программ.

2. Результаты работы.

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

1. Технологии OLE, COM и ActiveX.

2. Преимущества и недостатки OLE.

3. Преимущества и недостатки COM.

4. Развитие от OLE до ActiveX .

5. VisualC++ и OLE.

приложение 1

Варианты заданий

Лабораторные работы №№ 1-4 выполняются для одного и того же варианта.

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

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

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

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

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

6. Разработать программный модуль «Кафедра», содержащий сведения о сотрудниках кафедры (ФИО, должность, ученая степень, дисциплины, нагрузка, общественная работа, совместительство и др.). Модуль предназначен для использования сотрудниками отдела кадров и деканата.

7. Разработать программный модуль «Лаборатория», содержащий сведения о сотрудниках лаборатории (ФИО, пол, возраст, семейное положение, наличие детей, должность, ученая степень). Модуль предназначен для использования сотрудниками профкома и отдела кадров.

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

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

10. Разработать программный модуль «Картотека агентства недвижимости», предназначенный для использования работниками агентства. В базе содержатся сведения о квартирах (количество комнат, этаж, метраж и др.). При поступлении заявки на обмен (куплю, продажу) производится поиск подходящего варианта. Если такого нет, клиент заносится в клиентскую базу и оповещается, когда вариант появляется.

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

12. Разработать программный модуль «Авиа касса», содержащий сведения о наличии свободных мест на авиамаршруты. В базе должны содержаться сведения о номере рейса, экипаже, типе самолета, дате и времени вылета, а также стоимости авиабилетов (разного класса). При поступлении заявки на билеты программа производит поиск подходящего рейса.

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

14. Разработать программный модуль «Автостоянка». В программе содержится информация о марке автомобиля, его владельце, дате и времени въезда, стоимости стоянки, скидках, задолженности по оплате и др.

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

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

Приложение 2

Пример технического задания на программный продукт

Министерство образования Российской Федерации Московский государственный институт электронной техники (технический университет) Кафедра Информатики и программного обеспечения вычислительных систем утверждаю Зав. Кафедрой ИПОВС, д.т.н., проф._______Гагарина Л.Г. «__»_________2006 г. Программа построения таблиц и графиков функций Техническое задание на курсовую работу Листов 5 Руководитель, к.т.н., доцент________Петров А.А. Исполнитель, студент гр. МП 33_____Власов С.Е. 2006

1. ВВЕДЕНИЕ

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

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

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

Разрабатываемая программа позволит школьникам проверить свои знания при изучении

указанной темы.

2. ОСНОВАНИЕ ДЛЯ РАЗРАБОТКИ

Программа разрабатывается на основе учебного плана кафедры «Компьютерные системы и

сети» и в соответствии с договором кафедры со школой № ... от 5.09.2001.

3. НАЗНАЧЕНИЕ

Основным назначением программы является помощь школьникам при изучении раздела

«Исследование функций одного аргумента» школьного курса элементарной алгебры.

4.ТРЕБОВАНИЯ К ПРОГРАММЕ ИЛИ ПРОГРАММНОМУ ИЗДЕЛИЮ

4.1.Т р е б о в а н и я к ф у н к ц и о н а л ь н ы м х а р а к т е р и с т и к а м

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

функций:

• ввод аналитического представления функции одной переменной и длительное хранение его в

системе;

• ввод и изменение интервала определения функции;

• ввод и корректировку шага аргумента;

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

функции на заданном интервале при условии, что на указанном интервале она не имеет точек

разрыва.

4.1.2. Исходные данные:

• аналитическое задание функции;

• интервал определения функции;

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

4.2. Т р е б о в а н и я к н а д е ж н о с т и

4.2.1.Предусмотреть контроль вводимой информации.

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

4.3. Т р е б о в а н и я к с о с т а в у и п а р а м е т р а м т е х н и ч е с к и х с р е д с т в

4.3.1.Система должна работать на IBM совместимых персональных компьютерах.

4.3.2.Минимальная конфигурация:

• тип процессора ...............................................................Pentium и выше;

• объем оперативного запоминающего устройств ........32 Мб и более.

4.4. Т р е б о в а н и я к и н ф о р м а ц и о н н о й и п р о г р а м м н о й с о в м е с т и м о с т и

Система должна работать под управлением семейства операционных систем Win 32 (Windows

95, Windows 98, Windows 2000, Windows NT и т. п.).

5. ТРЕБОВАНИЯ К ПРОГРАММНОЙ ДОКУМЕНТАЦИИ

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

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

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

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

5.3.В состав сопровождающей документации должны входить:

5.3.1. Пояснительная записка на 25-30 листах, содержащая описание разработки.

5.3.2. Руководство пользователя.

Приложение 3

Пример технического задания на разработку

«Утверждаю»

Профессор кафедры ВС
____________(Иванов И.И.)
«___» ______________ 200 г.

Техническое задание
на разработку «Модуля автоматизированной

системы оперативно-диспетчерского управления

теплоснабжением корпусов Московского

института »

Москва, 200_

Введение

Работа выполняется в рамках проекта «Автоматизированная система оперативно-диспетчерского управления электро-, теплоснабжением корпусов Московского института»

2. Основание для разработки

2.1. Основанием для данной работы служит договор № 1234 от 10 марта 2003 г.

2.1. Наименование работы

«Модуль автоматизированной системы оперативно-диспетчерского управления теплоснабжением корпусов Московского института»

2.2. Исполнители: OAO “Лаборатория создания программного обеспечения”

2.3. Соисполнители: нет.

3. Назначение разработки

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

4. Технические требования

4.1. Требования к функциональным характеристикам

4.1.1. Состав выполняемых функций

Разрабатываемое ПО должно обеспечивать:

- сбор и анализ информации о расходовании тепла, горячей и холодной воды по данным теплосчетчиков SA-94 на всех тепловых выходах;

- сбор и анализ информации с устройств управления системами воздушного отопления и кондиционирования типа РТ1 и РТ2 (разработки кафедры СММЭ и ТЦ);

- предварительный анализ информации на предмет нахождения параметров в допустимых пределах и сигнализирование при выходе параметров за пределы допуска;

- выдачу рекомендаций по дальнейшей работе;

- отображение текущего состояния по набору параметров -циклически постоянно (режим работы круглосуточный), при сохранении периодичности контроля прочих параметров;

- визуализацию информации по расходу теплоносителя:

· текущую, аналогично показаниям счетчиков;

· с накоплением за прошедшие сутки, неделю, месяц – в виде почасового графика для информации за сутки и неделю;

· суточный расход – для информации за месяц.

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

По отдельному запросу осуществляются внутренние настройки;

- в конце отчетного периода система должна архивировать данный.

4.1.2. Организация входных и выходных данных

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

Основной режим использования системы – ежедневная работа.

4.2. Требования к надежности

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

4.3. Условия эксплуатации и требования к составу и параметрам технических средств

Для работы системы должен быть выделен ответственный оператор.

Требования к составу и параметрам технических средств уточняются на этапе эскизного проектирования системы.

4.4. Требования к информационной и программной совместимости

Программа должна работать на платформах Windows 98/NT/2000

4.5. Требования к транспортировке и хранению

Программа поставляется на лазерном носителе информации. Программная документация поставляется в электронном и печатном виде.

4.6. Специальные требования

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

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

- Язык программирования – по выбору исполнителя, должен обеспечивать возможность интеграции программного обеспечения с некоторыми видами периферийного оборудования (например счетчик SA-94 и т.п.)

5. Требования к программной документации

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

6. Технико-экономические показатели

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

7. Порядок контроля и приемки

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

8. Календарный план работ

№ этапа	Название этапа	Сроки этапа	Чем заканчивается этап
1	Изучение предметной области. Проектирование ситемы. Разработка предложений по реализации системы.	01.02.200_-28.02.200_	Предложения по работе системы. Акт-сдачи приемки.
2	Разработка программного модуля по сбору и анализу информации со счетчиков и устройств управления. Внедрение системы для одного из корпусов МИЭТ.	01.03.200_-31.08.200_	Программный комплекс решающий поставленные задачи для пилотного корпуса МИЭТ. Акт сдачи-приемки
3	Тестирование и отладка модуля. Внедрение системы во всех корпусах МИЭТ	01.09.200_-30.12.200_	Готовая система контроля теплообеспечения МИЭТ, установленная в диспетчерском пункте. Программная документация. Акт сдачи-приемки работ

Руководитель работ Сидоров А.В.

Литература

1. Иванова Г.С. Технология программирования. – М.: Из-во МГТУ им. Баумана 2002, - 241 с.

2. Гагарина Л.Г., Виснадул Б.Д, Игошин А.В. Основы технологии разработки программных продуктов: Учеб. пособие – М.: Форум, 2006.

3. Майерс Г. Искусство тестирования программ / Пер. с англ. под ред. Б. А. Позина. - М.: Финансы и статистика,1982.-176с.

4. http://www.realcoding.net/article/view/1833

5. http://www.rusdoc.ru/material/lang/other/activex/active.shtml

Кокорева Е.В.

Лабораторный практикум по курсу:

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

Москва 2007

УДК 004.43(075.8)

Кокорева Е.В.

Лабораторный практикум по курсу «Технология программирования». - М.: МИЭТ, 2007. - 127 с.: ил.

содержание

Содержание………………………………………………………………………………… 3

Лабораторная работа № 6 Тестирование программ методами «белого ящика»…..…65

Лабораторная работа № 7 Тестирование программ методами «черного ящика»……75

Лабораторная работа № 9 Использование технологий OLE COM и ActiveX…….…101

Приложение 1…………………………………………………………………………….110

Приложение 2…………………………………………………………………….………118

Приложение 3………………………………………………………………………….…122

Литература………………………………………………………………………………..127

Лабораторная работа № 1

Цель занятия: ознакомиться с правилами написания технического задания.

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

2. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

Разработка технического задания

1. Порядок разработки технического задания

Общие положения

2.4. Техническое задание должно содержать следующие разделы:

· введение;

· наименование и область применения;

· основание для разработки;

· назначение разработки;

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

· технико-экономические показатели;

· стадии и этапы разработки;

· порядок контроля и приёмки;

· приложения.

Содержание разделов

3.3. В разделе "Основание для разработки" должны быть указаны:

· организация, утвердившая этот документ, и дата его утверждения;

· наименование и (или) условное обозначение темы разработки.

· требования к функциональным характеристикам;

· требования к надёжности;

· условия эксплуатации;

· требования к составу и параметрам технических средств;

· требования к информационной и программной совместимости;

· требования к маркировке и упаковке;

· требования к транспортированию и хранению;

· специальные требования.

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

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

· другие источники разработки.

Техническое задание к данному примеру смотри в приложении 2.

Порядок выполнения работы:

1. Разработать техническое задание на программный продукт (см. варианты заданий).

2. Оформить работу в соответствии с ГОСТ 19.106-78. При оформлении использовать MS Office.

3. Сдать и защитить работу.

Защита отчета по лабораторной работе:

Отчет по лабораторной работе должен включать в себя:

1. Постановку задачи.

2. Техническое задание на программный продукт.

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

1. Этапы разработки программного обеспечения.

2. Жизненный цикл программного обеспечения.

3. Постановка задачи и предпроектные исследования.

4. Функциональные и эксплуатационные требования к программному продукту.

5. Правила разработки технического задания.

6. Основные разделы технического задания.

Лабораторная работа № 2

Структурный подход к программированию. Стадия

«Эскизный проект»

Лабораторная работа рассчитана на 4 академических часа.

Подготовка к лабораторной работе:

4. Изучить соответствующие разделы в изданиях [1, 2].

Теория:

Анализ требований и определение спецификаций при структурном подходе

· спецификаций процессов;

· словаря терминов;

· диаграмм переходов состояний (STD – State Transition Diagrams), характеризующих поведение системы во времени;

· функциональных диаграмм (методология SADT);

· диаграмм «сущность-связь» (ERD – Entity-Relationship Diagrams), описывающих базы данных разрабатываемой системы.

Спецификации процессов

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

1.1. Схемы алгоритмов

Для изображения схем алгоритмов разработан ГОСТ 19.701-90 (см. табл. 1)

· следование – обозначает последовательное выполнение действий (рис. 1 а);

Таблица 1

Название

Обозначение

Назначение

Терминатор

Начало, завершение программы или подпрограммы

Процесс

Обработка данных (вычисления, пересылки и т. п.)

Данные

Операции ввода-вывода

Решение

Ветвление, выбор, поисковые и итерационные циклы

Подготовка

Счетные циклы

Граница цикла

Конец

Любые циклы

Предопределенный процесс

Вызов процедур

Соединитель

Маркировка разрывов линий

Комментарий

Пояснения к операциям

· ветвление – соответствует выбору одного из двух вариантов действий (рис. 1, б);

Рис 1. Базовые алгоритмические структуры:

а - следование; б - ветвление; в - цикл-пока

Рис. 2. Дополнительные структуры алгоритмов:

а - выбор; б - цикл-до; в - цикл с заданным числом повторений

Рис. 3. Пример схемы алгоритма поиска максимального элемента массива

1.2. Псевдокоды.

Таблица 2

Структура	Псевдокод	Структура	Псевдокод
Следование	<Действие1> <Действие2>	Выбор	Выбор <код> <код1>:<Действие1> <код2>: <Действие2> … Все-выбор
Ветвление	Если <Условие> то <Действие1> иначе <Действие2> Все-если	Цикл с заданным количеством повторений	Для <индекс> = <n>,<k>,<h> <Действие> Все-цикл
Цикл-пока	Цикл-пока <Условие> <Действие> Все-цикл	Цикл-до	Выполнять <Действие> До <Условие>

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

Программа

Цикл-пока не конец файла

Прочитать запись

Сравнить заданные поля с критерием поиска

Если совпали

Сохранить в выходной список

Конец-если

Конец-цикл

Вывод результирующего списка

Конец-программа

Словарь терминов

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

термин;

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

краткое описание.

Пример:

Термин Web-сайт

Категория Интернет-программирование

12 3 4 5 6 7 8 9 10 Следующая ⇒

Последнее изменение этой страницы: 2019-05-08; Просмотров: 1338; Нарушение авторского права страницы