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




Если методы структурного проектирования имели целью упро­щение системной разработки на основе алго­ритмического подхода, то объектно-ориентированные методы решают аналогичную задачу, используя описания классов и объектов, т. е. выразительные сред­ства объектно-ориентированного программирования. Буч (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% ошибок.

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

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

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

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

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



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2022-09-06 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: