2.4.4 Управление обработкой партий
2.4 4.1 Понятие дисциплины очереди
Управление транспортом партий происходит в соответствии с определенной дисциплиной очереди.

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

Существует два типа очередей:

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

Очередь на установках, партии в этих очередях "ждут" подачи на операцию внутри микроцикла.

Ожидание в очереди 1-го типа может быть длительным (часы, сутки, недели). Ожидание в очереди 2-го типа должно быть кратковременным (минуты, десятки минут).

Управление очередями 2-го типа простое, оно осуществляется по методу FIFO (первым пришел - первым вышел), т.е. в первую очередь обрабатываются те партии, которые первыми попали в очередь.

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

Ниже приведены схемы дисциплины очереди.

2.4.4.2 Предварительная схема дисциплины очереди

При формировании дисциплины очереди необходимы знания об определенных параметрах партии и производственного процесса. Выделим эти параметры.

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

Время задержки прохождения партией данной операции (отрицательные времена тоже важны), Д tзад;

Априорная важность партии, Imp (обычная партия Imp = 1, важная партия Imp = 2,3,…) априорную важность партии устанавливает группа контроля по заданию руководства;

Процент прохождения маршрута, Pr;

Прогноз следствий невыполнения;

Коэффициент нагрузки, r = Iзаявок / Iобслуживания (I - интенсивность). r зависит от НЗП. Средняя длина очереди зависит от r: l = [1 - r] -1 Разумно выбирать r ? 0,5 - 0,6, в этом случае длина очереди l = ? 2 - 2,5.

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

Если партия прошла n-й микроцикл, то в программу управления производством поступает рапорт о выполнении микроцикла и заявка на выполнение n +1-ого микроцикла.

Считаем, что схема имеет вид правил:

Если …., то …., иначе.

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

Опишем конкретный вариант упрощенной схемы принятия решения.

Если есть свободная установка для выполнения первой операции n +1-ого микроцикла, и эта установка одна, то заявка подается на эту установку.

Иначе

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

Иначе

Если все устройства, соответствующие первой операции n +1-ого микроцикла заняты, то партия подается в очередь на все эти установки.

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

В простейшем случае текущий приоритет есть Д tзад * Imp.

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

2.5 Техническое задание на дипломный проект
Исходя из изложенного выше материала, сформулируем техническое задание на дипломное проектирование.

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

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

К программе регистрации предъявляются следующие требования:

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

Фиксировать время начала и окончания выполнения технологической операции.

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

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

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

Программа должен функционировать в среде MS Windows 95,98,NT. Предполагается использовать программу на участках с длительными технологическими операциями (нанесение эпитаксиальных структур, диффузия, металлизация).

2.6 Выбор платформы и инструмента разработки программы
В качестве операционной системы для реализации программного обеспечения была выбрана среда Windows'98 (Windows NT). Можно выделить следующие причины, обосновывающие этот выбор:

Распространенность этих операционных систем;

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

возможность работы с большими массивами данных, реализация чего в среде Windows 3.1 или в среде MS-DOS представляет нетривиальную и трудновыполнимую задачу;

32-разрядность систем Windows'95 и Windows NT увеличивает скорость выполнения вычислительных задач.

В качестве среды программирования была выбрана среда Visual C++ фирмы MicroSoft, сочетающая в себе следующие преимущества:

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

использование всех преимуществ операционных систем Windows'98 и Windows NT, включая 32-разрядность, многозадачность, удобный интерфейс и прочее;

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

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

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

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

3. Разработка алгоритмов и программ

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

Анализ требований.

Проектирование.

Реализация (программирование).

Тестирование.

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

Объектно-ориентированный анализ

Ниже приводятся результаты первого этапа - анализа требований к проектируемой системе. При анализе использовались стратегии и образцы, разработанные Питером Коудом, а также методология OMT (Object Modeling Technique). Результатами анализа являются назначение системы, характерные свойства, объектная модель.

Назначение системы:

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

3.2 Характерные свойства системы
Система должна:

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

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

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

Фиксировать время начала и окончания выполнения технологической операции.

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

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

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

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

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

Группа контроля - лицо или группа лиц, осуществляющее планирование запуска партий из НЗП в производство и материально ответственное за партии, хранящиеся в НЗП.

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

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

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

Установка - устройство, осуществляющее операции над партиями.

Участок - административная единица, выполняющая некий набор операций над партиями.

Участок НЗП - участок, на котором партии хранятся между микроциклами, в НЗП поступают новые партии и готовые партии.

Шкаф - место на участке НЗП, в котором партии хранятся между микроциклами.

Контроль - 1) участок, на котором осуществляется операция контроля,

2) операция контроля, на которой выявляется брак.

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

Маршрутный лист - документ, содержащий список операций, которые партия должна пройти в процессе изготовления.

Операция - действие, изменяющее готовность партии, этап изготовления партии согласно маршрутному листу.

Хранение - операция, которой подвергаются партии между микроциклами.

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

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

Микроцикл - часть технологического маршрута; между микроциклами партия может храниться длительное время.

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

Входной считыватель штрихкода - устройство, фиксирующее поступление партии на участок.

Выходной считыватель штрихкода - устройство, фиксирующее передачу партии с участка на транспорт.

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

Терминал - средство общения между системой управления и персоналом.

Цех - помещение, в котором осуществляется производство.

Участок ВТ - место нахождения Ведущего технолога.

Рис.7. Объектная модель, характеризующая объекты системы управления и связи между ними

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

Рис.8. Обозначения, принятые в объектной модели

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

3.4 Алгоритм выполнения технологической операции
В данной программе схема работы представлена двумя основными алгоритмами. Рис.9 описывает алгоритм выполнения технологической операции.

Рис.9. Алгоритм выполнения технологической операции

3.5 Алгоритм формирования дисциплины очереди
Рис.10 конкретизирует этап выбора партии полупроводниковых пластин для обработки.

Управление транспортом партий происходит в соответствии с определенной дисциплиной очереди.

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

Выбрать из всего множества партии с минимальным межоперационным временем;

Выбрать из оставшегося списка партии пластин с высоким априорным приоритетом;

Выбрать из оставшегося списка партии, близкие к завершению технологического цикла;

Использовать правило "FIFO - первым вошел - первым вышел".

Все рассмотренные правила представлены алгоритмом.

Рис.10. Алгоритм формирования дисциплины очереди

3.6 Использование библиотеки Microsoft Foundation Classes

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

Использование объектно-ориентированного подхода дает многочисленные преимущества в сравнении с традиционным стилем программирования:

Инкапсуляция кода и данных внутри класса;

Наследование;

Разрешение коллизий имен функций;

Уменьшается общий объем текстов.

Основные возможности библиотеки MFC:

Поддержка всех функций, управляющих элементов и ссобщений Windows, графических примитивов GDI, меню и окон диалога;

Использование соглашения об именах API Windows, при котором по имени класса становится ясным его предназначение;

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

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

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

Рис.11. Иерархия классов программы регистрации процесса производства

Cobject - базовый класс, широко используемый при разработке приложений Windows.

CCmdTarget -

CWnd - родительский класс для всех окон.

CWinApp - родительский класс для приложения.

CDialog - родительский класс для окон диалога.

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

CAngstremApp - основной класс. Разделен на два файла - заголовочным для него является файл cangstremapp. h, файл реализации - cangstrem. cpp.

CMainFrame - этот класс, производный от CFrameWnd, используется для управления главным окном приложения.

CAngstremView - является наследником класса CView. Класс CView, производный от CWnd, служит базовым для пользовательских классов отображения. Отображение (view) служит промежуточным звеном между документом и пользователем. Обычно отображение - это дочернее окно главного окна.

CAngstremDoc - класс используется для хранения данных.

Технологическая часть:

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

Выполнил:

Ляшко М.А.

Консультант:

Брусникин Г.Н.

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

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

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

В 1958 году были разработаны первые языки программирования, Фортран и Алгол-58. Программа на Фортране состояла из главной программы и некоторого количества процедур - подпрограмм и функций. Программа на Алголе-58 и его последующей версии Алголе-60 представляла собой единое целое, но имела блочную структуру, включающую главный блок и вложенные блоки подпрограмм и функций. Компиляторы для Фортрана обеспечивали раздельную трансляцию процедур и последующее их объединение в рабочую программу, первые компиляторы для Алгола предполагали, что транслируется сразу вся программа, раздельная трансляция процедур не обеспечивалась.

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

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

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

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

4.2 Понятие жизненного цикла программного обеспечения
Одним из базовых понятий методологии разработки информационных систем является понятие жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это непрерывный процесс, который начинается с момента принятия решения о необходимости создания программного обеспечения и заканчивается в момент его полного изъятия из эксплуатации.

Основным нормативным документом, регламентирующим ЖЦ ПО, является международный стандарт ISO/IEC 12207 (ISO - International Organization of Standardization). Он определяет структуру жизненного цикла, содержащую процессы, действия и задачи, которые должны быть выполнены.

4.3 Модели жизненного цикла программного обеспечения
Стандарт ISO/IEC 12207 не предлагает конкретную модель жизненного цикла и методы разработки ПО. Его регламенты являются общими для любых моделей ЖЦ, методологий и технологий его разработки.

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

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

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

Рис.12. Каскадная схема разработки программного обеспечения

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

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

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

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

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

Рис.13. Схема реального процесса разработки программного обеспечения

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

Рис.14. Спиральная модель жизненного цикла

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

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

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

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

удовлетворяет заданным (возможно, неформальным) функциональным спецификациям;

согласована с ограничениями, накладываемыми оборудованием;

удовлетворяет явным и неявным требованиям по эксплуатационным качествам и ресурсопотреблению;

удовлетворяет явным и неявным критериям дизайна продукта;

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

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

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

процедурное программирование;

метод структурного проектирования "сверху вниз";

метод потоков данных;

объектно-ориентированное проектирование.

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

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

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

Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного; в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами.

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

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

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

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

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

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

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

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

промежуточные результаты вычисления выражений;

локальные переменные в вызове процедур;

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

данные, сохраняющиеся между сеансами выполнения программы;

данные, сохраняемые при переходе на новую версию программы;

данные, которые вообще переживают программу.

В использовании объектно-ориентированной модели можно выделить следующие преимущества:

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

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

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

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

4.5.3 Процесс объектно-ориентированного проектирования
Процесс объектно-ориентированного проектирования не сводится к одностороннему движению "сверху вниз" или "снизу вверх". Хорошо структурированные сложные системы можно создать методом "возвратного проектирования".

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

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

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

Рис.15. Микропроцесс проектирования

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

выявление классов и объектов на данном уровне абстракции;

выяснение семантики этих классов и объектов;

выявление связей между этими классами и объектами;

спецификация интерфейса и реализация этих классов и объектов.

Рассмотрим их более подробно:

1. Выявление классов и объектов.

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

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

2. Идентификация семантики классов и объектов.

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

Результаты: Во-первых, уточняется словарь данных, с помощью которого мы изначально присвоили обязанности абстракциям. В ходе проектирования можно выработать спецификации к каждой абстракции, перечисляя имена операций в протоколе каждого класса. Затем, необходимо выразить интерфейсы этих классов на языке реализации. Например, для C++ это означает создание. h-файлов, в Ada - спецификаций пакетов, в CLOS - обобщенных функций для каждого класса, в Smalltalk - это объявление, но не реализация методов каждого класса. В добавление к этим, по сути тактическим решениям, мы составляем диаграммы объектов и диаграммы взаимодействий, передающие семантику сценариев, создаваемых в ходе макропроцесса. Эти диаграммы формально отражают раскадровку каждого сценария и, таким образом, описывают явное распределение обязанностей среди взаимодействующих объектов. На этом шаге впервые появляются конечные автоматы для представления некоторых абстракций.

3. Выявление связей между классами и объектами.

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

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

4. Реализация классов и объектов.

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

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

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

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

добавление нового класса или нового взаимодействия между классами;

изменение реализации класса;

изменение представления класса;

реорганизация структуры классов;

изменение интерфейса класса.

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

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

Типичный порядок действий на этом этапе таков:

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

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

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

приступают к разработке следующего эволюционного релиза программы.

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

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

5. Методика отладки и результаты работы программы

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

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

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

невысокая степень формализации критериев качества процесса тестирования и достигаемого при этом качества программного обеспечения как объекта тестирования;

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

Неоднократно экспериментально установлено, что в любом сложном программном обеспечении в процессе эксплуатации обнаруживаются ошибки, даже если проведено самое тщательное тестирование. Тем самым объективно утверждается, что невозможно формализовать и обеспечить абсолютную полноту всех эталонных значений, а также провести всеобъемлющее исчерпывающее тестирование и гарантированно устранить все ошибки в сложных программных продуктах. Поэтому тестирование проводится в объемах, минимально необходимых для проверки программ в некоторых ограниченных пределах изменения параметров и условий функционирования. Ограниченность ресурсов тестирования привела к необходимости тщательного упорядочения методов и конкретных значений параметров с целью получения при тестировании наибольшей глубины проверок программ. Анализ многих проектов показывает, что до начала тестирования число ошибок в сложных программах составляет порядка 1-2% от общего числа объектных команд в программе, т.е. в программном обеспечении объемом 100 тысяч команд в процессе тестирования обычно выявляется 1-2 тысячи ошибок. При тщательном системном проектировании и программировании на языках высокого уровня начальное число ошибок в несколько раз меньше. Таким образом самое тщательное тестирование сложных программных комплексов позволяет получить программы с вероятностью ошибки в каждой команде порядка 10-4-10-5, т.е. несколько ошибок может остаться не выявленными.

5.2 Типичный процесс тестирования программного обеспечения
Процесс тестирования программ обычно включает:

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

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

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

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

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

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

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

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

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

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

5.3 Особенности задачи в приложении к тестированию программ

5.3.1 Особенности среды программирования
Среда программирования Microsoft Visual Studio 6.0 и язык программирования в ней Microsoft Visual C++ имеют ряд особенностей, влияющих на тестирование программ:

Visual C++ является языком программирования высокого уровня, что сильно увеличивает значимость статического (символьного) тестирования;

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

Visual Studio имеет развитую систему автоматической символьной проверки. Она на этапе написания программы следит за корректностью вводимого текста и обнаруживает все синтаксические ошибки;

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

большую часть структуры программы в Visual C++ with Microsoft Foundation Classes занимают стандартные, автоматически создаваемые объекты, управляющие работой программы в ответ на действия пользователя. Поэтому ошибки в основном содержатся в алгоритмах процедур, написанных программистом.

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

корректность структуры программы;

корректность обработки данных;

устойчивость к ошибочному вводу данных пользователем.

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

недопустимо непустое значение поля данных;

недопустимо значение поля данных, не входящее в заданный интервал допустимых значений.

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

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

Суть критерия состоит в выборе и анализе базовых маршрутов в программе, формируемых и оцениваемых на основе определения цикломатического числа исходного графа, определяющего структуру программы или ее фрагмента. Критерий наиболее широко применяется для оценки сложности и корректности тестирования программных модулей. Для определения цикломатического числа Z исходного графа фрагмента программы используется полное число его вершин Nп, связывающих их дуг Y и связных компонент L: Z = Y - Nп + L. Вычисление цикломатического числа осуществляется по величинам, определяемым по максимально связному графу, который получается из исходного путем замыкания дуги из конечной вершины в начальную. В результате в максимально связном графе появляются маршруты между любыми двумя вершинами. При этом предполагается, что исходный граф корректен, т.е. не содержит "висячих" и "тупиковых" вершин. В таком графе цикломатическое число равно максимальному количеству его линейно-независимых маршрутов. Величина L соответствует количеству связных компонент всего исходного графа, и обычно для графов не содержащих полностью независимых частей L=1. Иначе говоря, L измеряется количеством замыкающих дуг, необходимых для преобразования исходного графа в максимально сильно связный граф.

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

Рис.16. Фрагмент исходного текста программы

Рассмотрим на примере фрагмента кода разрабатываемого программного обеспечения тестирование корректности структуры этого фрагмента (см. рис.16). На основе данного фрагмента кода выделим операторы управления и построим графовую модель программы по управлению. Цифрами на рис.16 условно обозначены вершины графа. Рис.17 отображает схему этого графа.

Рис.17. Граф программы по управлению

Далее определим цикломатическое число графа по исходным данным:

Nп = 6

Y = 8

L = 1

Z = Y - Nп + L = 3

В данном случае для максимально связного графа количество линейно-независимых маршрутов для которых следует подготовить тесты равно цикломатическому числу графа. Эти маршруты показаны на рис.18.

Рис.18. Линейно-независимые маршруты

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

5.3.2.2 Контроль чтения и записи переменных

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

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

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

существует ли запись этой величины вообще;

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

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

Рис. 19. Схема контроля чтения и записи переменных

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

Страницы: 1, 2