· они должны быть действительно недолгими;
· не нужно обсуждать все подробности (только самое важное);
· относитесь к полученному в результате проектному решению как к наброску, а не как к конечной версии, не подверженной изменениям.
Последний пункт стоит раскрыть подробнее. Когда вы занимаетесь предварительным проектированием, вы неизбежно обнаруживаете, что некоторые ваши решения неправильны. Причем обнаруживается это уже при кодировании. Разумеется, это не проблема, если вы после этого вносите соответствующие изменения. Проблемы начинаются тогда, когда вы полагаете, что с проектированием покончено, и не учитываете полученные сведения, сохраняя неверный дизайн.
Изменения в дизайне вовсе необязательно подразумевают изменения в диаграммах. Абсолютно разумным будет просто-на просто выбросить диаграмму, после того, как она помогла вам найти нужное решение. Нарисовав диаграмму, вы решили стоявшую перед вами проблему, и этого совершенно достаточно. Диаграмма и не должна существовать как некий постоянный арте факт. Надо сказать, что лучшие UML-диаграммы такими арте фактами как раз не являются.
Кроме того, UML-диаграммы используются в качестве документации по проекту. Как правило, в своей обычной форме это модель, редактируемая с помощью некоторого CASE-инструмента. Идея здесь состоит в том, что ведение такой документации облегчает работу. На самом деле, чаще всего она вообще не нужна, поскольку:
· нужно постоянно тратить массу времени, чтобы не дать диаграммам устареть, в противном случае они не будут со ответствовать программному коду;
· диаграммы находятся внутри сложного CASE-средства либо в толстенной папке, и никто туда не заглядывает.
Итак, если вы хотите иметь текущую документацию по проекту, учитывайте все вышеперечисленные проблемы:
· используйте только те диаграммы, которые вы можете поддерживать без особых усилий;
· помещайте диаграммы туда, где их все видят. Пусть остальные рисуют на ней ручкой все простые изменения, которые были внесены в изначальный вариант;
· посмотрите, обращают ли ваши разработчики на диаграммы хоть какое-то внимание, и если нет, выбросите их.
И наконец, последний аспект использования UML для документации — передача проекта в другие руки (например, от од ной группы разработчиков другой). Согласно методологии ХР создание документации — такая же задача, как и все остальные, а значит, ее приоритет должен быть определен заказчиком. В этой ситуации может пригодиться UML, разумеется, при условии избирательности диаграмм, которые создавались с целью облегчения коммуникации. Помните, что программный код — это основной репозиторий подробной информации, а диаграммы служат для обобщенного представления основных аспектов системы.
Суть проектирования. Программирование и тестирование
Проектирование в ХР требует от человека следующих качеств:
· постоянного желания сохранять программный код простым и понятным насколько это возможно;
· наличия навыков рефакторинга, так чтобы с уверенностью вносить в систему изменения, как только в этом возникнет необходимость;
· хорошего знания паттернов: рассматривать их не просто как готовые решения, а оценивать своевременность и использовать постепенно, от простого к сложному;
· умения объяснять при необходимости решения по конструированию системы (используя для этого программный код, диаграммы и, самое главное, личное общение).
Для того чтобы реализовать задачу, ответственный за нее программист прежде всего ищет себе партнера, поскольку окончательный код всегда пишется двумя людьми на одной машине. Если возникают вопросы о предмете или методах реализации, партнеры проводят короткую (15-минутную) встречу с заказчиком и/или программистами, осведомленными в вопросах кодирования задач, которые с наибольшей вероятностью будут связаны с кодом данной задачи в ходе реализации.
По результатам этой встречи программисты составляют спи сок тестовых примеров, которые необходимо прогнать до завершения реализации задачи. Из списка выбирается такой тест, в реализации которого программисты полностью уверены и с по мощью которого они смогут лучше понять суть задачи. Пишется тестовая программа. Если она сразу нормально заработает, можно двигаться дальше. Однако, как правило, без проблем не обходится. В случае если тест не работает, возможна одна из следующих ситуаций:
· мы знаем простой способ заставить его работать, и мы действуем этим способом;
· мы знаем сложный и очень неприятный способ заставить его работать, но понимаем, как изменить архитектуру системы и добиться нормальной работы тестового примера без лишних усилий. Тогда мы решаемся на переработку системы;
· мы знаем сложный и неприятный способ заставить его работать и не видим никакой возможности переработать систему, поэтому мы идем этим сложным путем.
После того как тест заработал, мы, возможно, снова поймем, как усовершенствовать систему, что и сделаем.
Вполне вероятно, что в ходе реализации тестового примера мы найдем другой тестовый пример, который также должен работать. Мы заносим новый тест в свой список и продолжаем разработку. Возможно, мы обнаружим, что масштабы перестройки системы. выходят за рамки требований текущего теста, тогда зафиксируем и этот факт и двинемся дальше. В конце концов, наша цель — сконцентрироваться на деталях и успешно справиться С конкретной проблемой, но одновременно не потерять общего представления о системе, которое формируется в процессе интенсивной работы над кодами.
Контрольные вопросы
1. Что такое CASE-технологии?
2. Что такое RAD-технологии?
3. Охарактеризуйте модель проектируемого ПО при объектном подходе
4. Что такое экстремальное программирование?
4 Тестирование и отладка программ
В целом разработчики различают дефекты программного обеспечения и сбои. В случае сбоя программа ведет себя не так, как ожидает пользователь. Дефект – это ошибка/неточность, которая может быть (а может и не быть) следствием сбоя.
Общепринятая практика состоит в том, что после завершения продукта и до передачи его заказчику независимой группой тестировщиков проводится тестирование ПО. Эта практика часто выражается в виде отдельной фазы тестирования (в общем цикле разработки ПО), которая часто используется для компенсирования задержек, возникающих на предыдущих стадиях разработки. Другая практика состоит в том, что тестирование начинается вместе с началом проекта и продолжается параллельно созданию продукта до завершения проекта. Второй путь обычно требует больших трудозатрат, но качество тестирования при этом будет выше.
Уровни тестирования:
· модульное тестирование. Тестируется минимально возможный для тестирования компонент, например отдельный класс или функция;
· интеграционное тестирование. Проверяется, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами, например, не передастся информация, передается некорректная информация,
· системное тестирование. Тестируется интегрированная система на ее соответствие исходным требованиям:
˗ альфа-тестирование – имитация реальной работы с системой штатными разработчиками либо реальная работа с системой потенциальными пользователями/заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приемочного тестирования. Иногда альфа, тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО;
˗ бета-тестирование – в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц с тем, чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.
4.1 Термины и определения
Выполнение программы с целью обнаружения ошибок называется тестированием. Виды ошибок и способы их обнаружения приведены в таблице 4.1.
Таблица 4.1. Вида программных ошибок и способы их обнаружения
Эффективность контроля 1-го вида зависит и от языка, и от компилятора. Контроль 2-го вида осуществляется с помощью исключений – Exceptions и весьма полезен для проверки правдоподобности промежуточных результатов. Тест – это набор контрольных входных данных совместно с ожидаемыми результатами. В число входных данных времязависимых программ входят события и временные параметры. Ключевой вопрос – полнота тестирования: какое количество каких тестов гарантирует, возможно, более полную проверку программы? Исчерпывающая проверка на всем множестве входных данных недостижима. Пример: программа, вычисляющая функцию двух переменных: Y=f(X, Z). Если X,Y,Z— real, то полное число тестов (232)2 = 264 ≈ 1031 Если на каждый тест тратить 1 мс, то 264 мс = 800 млн лет. Следовательно:
· в любой нетривиальной программе на любой стадии ее готовности содержатся необнаруженные ошибки;
· тестирование – технико-экономическая проблема, основанная на компромиссе время — полнота. Поэтому нужно стремиться к возможно меньшему количеству хороших тестов с желательными свойствами.
Детективность: тест должен с большой вероятностью обнаруживать возможные ошибки
Покрывающая способность: один тест должен выявлять как можно больше ошибок.
Воспроизводимость: ошибка должна выявляться независимо от изменяющихся условий (например, от временных соотношений) – это труднодостижимо для времяэависимых программ, результаты которых часто не воспроизводи мы.
Только на основании выбранного критерия можно определить тот момент времени, когда конечное множество тестов окажется достаточным для проверки программы с некоторой полнотой (степень полноты, впрочем, определяется экспериментально). Используется два вида критериев (таблице. 4.2):
|
Из за большого объема этот материал размещен на нескольких страницах:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
