Эффективная подготовка к государственным междисциплинарным экзаменам для студентов технических специальностей (стр. 15 )

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

Принципы отладки

Принципы локализации ошибок.

Думайте.

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

Если вы зашли в тупик, отложите рассмотрение программы.

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

Если вы зашли в тупик, изложите задачу кому-нибудь еще.

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

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

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

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

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

Принципы исправления ошибок.

Там, где есть одна ошибка, вероятно, есть и другие.

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

Находите ошибку, а не ее симптом

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

Вероятность правильного нахождения ошибки не равна 100%.

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

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

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

Остерегайтесь внесения при корректировке новой ошибки.

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

Процесс исправления ошибки должен временно возвращать разработчика на этап проектирования.

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

Изменяйте исходный текст, а не объектный код.

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

Анализ ошибок

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

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

2. Кто сделал ошибку? Небесполезно показать, что 60% ошибок проектирования допустил один из десяти аналитиков или что программист Х сделал в три раза больше ошибок, чем другие программисты (не с целью наказания, а для разъяснения).

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

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

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

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

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

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

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

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

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

В 1994 году Гради Буч и Джеймс Рамбо, работавшие в компании Rational Software, объединили свои усилия для создания нового языка объектно-ориентированного моделирования. За основу языка ими были взяты методы моделирования, разработанные Бучем (Booch) и Рамбо (Object Modeling Technique — OMT). OMT был ориентирован на анализ, а Booch — на проектирование программных систем. В октябре 1995 года была выпущена предварительная версия 0.8 унифицированного метода (англ. Unified Method). Осенью 1995 года к компании Rational присоединился Айвар Якобсон, автор метода Object-Oriented Software Engineering — OOSE. OOSE обеспечивал превосходные возможности для спецификации бизнес-процессов и анализа требований при помощи сценариев использования. OOSE был также интегрирован в унифицированный метод.

На этом этапе основная роль в организации процесса разработки UML перешла к консорциуму OMG (Object Management Group). Группа разработчиков в OMG, в которую также входили Буч, Рамбо и Якобсон, выпустила спецификации UML версий 0.9 и 0.91 в июне и октябре 1996 года.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики.