Если методы структурного проектирования имели целью упрощение системной разработки на основе алгоритмического подхода, то объектно-ориентированные методы решают аналогичную задачу, используя описания классов и объектов, т. е. выразительные средства объектно-ориентированного программирования. Буч (Booch) определил объектно-ориентированное проектирование как «методологию проектирования, соединяющую в себе процесс объектной декомпозиции и приемы представления как логической и физической, так и статической и динамической моделей проектируемой системы».
Основой для объектно-ориентированного проектирования резонно служат результаты объектно-ориентированного анализа. Тем не менее результат любого из методов структурного анализа также может быть использован в качестве входных данных для объектно-ориентированного проектирования: в этом случае производится интеграция диаграмм потоков данных с классами и объектами.
На этапе проектирования используются следующие диаграммные техники:
• наследуемые от этапа анализа требований и развиваемые на этапе проектирования диаграммы классов и диаграммы объектов, являющиеся основой статической логической модели;
• диаграммы модулей и диаграммы процессов, моделирующие конкретные программные и аппаратные компоненты и являющиеся частью статической физической модели;
• динамические модели: диаграммы переходов состояний, моделирующие временную последовательность внешних событий, влияющих на объекты конкретного класса, и временные системные диаграммы, моделирующие временной порядок сообщений и событий, касающихся межобъектных взаимодействий.
|
|
Реализация (программирование/адаптация)
На этапе реализации осуществляется создание системы как комплекса программно-аппаратных средств, начиная с проектирования и создания телекоммуникационной инфраструктуры и заканчивая разработкой и инсталляцией приложений. В настоящее время существует обширная литература, в которой достаточно подробно рассмотрены все эти процессы, включая современные методы генерации исполняемого кода прикладных систем. Поэтому в настоящей книге вопросы реализации не рассматриваются, исключая случай, когда процесс реализации заключается в адаптации имеющейся на рынке системы. Учитывая недостаточное количество литературы по данному вопросу на русском языке, процесс адаптации детально рассматривается ниже в разделе «Управление процессом внедрения и эксплуатации (Типовой план внедрения)».
Тестирование и отладка
Корректность АСУП является ее самым важным свойством и, несомненно, составляет главный предмет заботы разработчиков. В идеальном случае под корректностью АСУП понимается отсутствие в ней ошибок. Однако для большинства сложных программных продуктов достигнуть этого невозможно — «в каждой программе содержится по крайней мере одна ошибка». Поэтому под корректным обычно подразумевают программный продукт, работающий в соответствии с предъявленными к нему требованиями, другими словами, продукт, для которого пока еще не найдены такие условия, в которых он окажется неработоспособным.
Установление корректности является главной целью рассматриваемого этапа жизненного цикла. Следует отметить, что этап тестирования и отладки — один из наиболее трудоемких, утомительных и непредсказуемых этапов разработки АСУП. В среднем при разработке традиционными методами этот этап занимает от '/3 до '/2 полного времени разработки. С другой стороны, тестирование и отладка представляют собой серьезную проблему: в некоторых случаях тестирование и отладка программы требуют в несколько раз больше времени, чем непосредственно программирование.
|
|
Тестирование представляет собой набор процедур и действий, предназначенных для демонстрации корректной работы АСУП в заданных режимах и внешних условиях. Цель тестирования — выявить наличие ошибок или убедительно продемонстрировать их отсутствие, что возможно лишь в отдельных тривиальных случаях. Важно различать тестирование и сопутствующее понятие «отладка». Отладка — это набор процедур и действий, начинающихся с выявления самого факта наличия ошибки и заканчивающихся установлением точного места, характера этой ошибки и способов ее устранения.
Различные аспекты тестирования многократно исследовались, однако полученные теоретические результаты носят почти исключительно негативный характер, что создает пессимистическую картину ценности получаемых при тестировании данных и в целом может быть суммировано в известном тезисе Дейкстры: «Тестирование программ может служить для доказательства наличия ошибок, но никогда не докажет их отсутствия!». Тем не менее нужно констатировать, что на практике результаты тестовых испытаний, не выявившие программных ошибок, интерпретируются как свидетельство корректности этой программы.
|
|
Важнейшим и наиболее часто применяемым на практике является метод детерминированного тестирования. При этом в качестве эталонов (тестов) используются конкретные исходные данные, состоящие из взаимосвязанных входных и результирующих величин и правильных последовательностей их обработки. В процессе тестирования при заданных исходных величинах необходимо установить соответствие результатов их обработки эталонным величинам. Для сложных систем требуется большое количество тестов и возникает проблема оценки их необходимого количества и использования методов их сокращения. Поэтому тестирование (как и любой другой вид деятельности) целесообразно планировать. План тестирования должен содержать:
• формулировку целей тестирования;
• критерии качества тестирования, позволяющие оценить его результаты;
• стратегию проведения тестирования, обеспечивающую достижение заданных критериев качества;
• потребности в ресурсах для достижения заданного критерия качества при выбранной стратегии.
Для целей тестирования программные элементы АСУП удобно представлять в виде ориентированного графа G = (N, Е),
где N = (N1, N2,..., Nm) — множество узлов (вершин), соответствующих выполняемым операторам тестируемой программы;
Е= (Е1, Е2,..., Еп) — множество ребер (дуг), соответствующих передачам управления между операторами.
Путем (маршрутом) называется последовательность вершин и дуг Р= (N1, E1,2, N2, E2,3 ,..., Ek-1,k, Nk), где каждая дуга Ei,i+l выходит из Nt и входит в Ni+l, причем N1 не обязательно начальный узел. Ветвью называется путь Р, в котором N1 — либо начальный узел, либо узел ветвления, Nk — либо узел ветвления, либо завершающий узел, все остальные N1 не являются узлами ветвления.
Очевидно, что полное тестирование всех возможных маршрутов не реально в связи с огромными затратами труда и времени. Поэтому на практике применяются критерии выбора тестов, не гарантирующие полной проверки программы. Общим требованием к этим критериям является достижение лишь определенной степени полноты АСУП или ее компонент. Как правило, эти критерии устанавливают требование по крайней мере однократной проверки всех операторов программы, всех ветвей программы, либо всех подпутей специального вида (например, всех подпутей, проверяющих циклы при начальном, завершающем и одном из промежуточных значений переменной — счетчика цикла). Самым распространенным критерием тестирования является критерий, требующий по крайней мере однократной проверки каждой из ветвей программ (критерий С1). Так, например, тестирование при приемке программного обеспечения для ВВС США производится на основании этого критерия. По ряду независимых оценок использование критерия С1 обеспечивает обнаружение от 67 до 90% ошибок.
Перечисленные критерии тестирования основаны на анализе структуры потока управления программы и не гарантируют обнаружение ошибок, связанных с ее потоками данных. Разработанные для решения этой задачи критерии разбиваются на две группы: использующие разбиение входных данных на обнаруживающие подобласти и основанные на отношениях между определениями и использованием информационных объектов.
В первом случае осуществляется поиск такого разбиения входных данных на подобласти, при котором корректная или некорректная работоспособность программы для любого элемента подобласти предполагает соответственно ее корректную или некорректную работоспособность для всех элементов этой подобласти. Если такое разбиение удается найти, то в качестве критерия тестирования принимается требование, по крайней мере, однократной проверки данных из каждой подобласти. Конечно, построить такое разбиение в большинстве реальных случаев практически невозможно. Однако этот принцип дает возможность строить обнаруживающие подобласти для отдельных типов ошибок: если имеется предположение о возможной ошибке, то часто можно определить и подобласть, на которую должна влиять эта ошибка, если бы в действительности она имела место.
Второе направление связано с попыткой выразить определенные свойства потоков данных через критерии тестирования. На уровне использующих некоторые переменные операторов программы определяется среда данных (множество всех определений каждой из переменных, для которых существует маршрут из точки определения в точку использования, на котором не встречается никакого другого определения данной переменной) и контекст данных (более полная модель, учитывающая одновременное использование определений с учетом их порядка). Соответствующие критерии тестирования требуют, по крайней мере, однократной проверки каждого из элементов среды и контекста данных.
Существуют и другие подходы к тестированию, например тестирование с ориентацией на слабые места (части программы, где вероятность появления ошибок относительно высока), тестирование с ориентацией на масштабы повреждения (проверка функций, ошибка в которых ведет к необратимым последствиям), стохастическое тестирование, мутационное тестирование. В последнем случае в программу целенаправленно вносятся представители различных групп ошибок — «мутанты». После тестирования осуществляется анализ числа и типов обнаруженных ошибок, включая «мутантов», далее на основе экстраполяции делается заключение о тщательности проведенного тестирования.
При установлении наличия ошибок на этапе тестирования возникает необходимость в следующем этапе — отладке. Отладка представляет собой процесс устранения ошибок: она начинается с обнаружения симптомов ошибки и заканчивается определением ее местоположения и последующим исправлением. В основе практически всех способов отладки лежат три метода: просмотр, проверка и прокрутка. Метод просмотра заключается в следующем: текст программы внимательно изучается на предмет обнаружения ошибок и смысловых расхождений с текстом алгоритма, при этом помимо сплошного просмотра может применяться и выборочный просмотр (циклов, условных операторов, параметров процедур и функций). При проверке своей программы программист по тексту мысленно старается восстановить определяемый программой вычислительный процесс, после чего сверяет его с требуемым процессом. Основой прокрутки является имитация программистом выполнения программы с целью более конкретного и наглядного представления о процессе, определяемом текстом проверяемой программы, т. е. программа проверяется как бы в динамике ее работы над конкретными данными.