Диаграмма пакетов. Диаграмма кооперации
Диаграмма кооперация. Диаграмма кооперации - это альтернативный способ представления
взаимодействия объектов в процессе реализации сценария, который позволяет по-другому
взглянуть на ту же информацию. В отличие от диаграмм последовательностей диаграммы
кооперации показывают потоки данных между объектами классов, что позволяет уточнить связи
между ними.
Пример 7.4. Разработать диаграмму кооперации для сценария Процесс решения. Изобразим на
Одной диаграмме три возможных случая реализации сценария, нумеруя сообщения в порядке их
возможной генерации (рис. 7.10). 
Такое представление позволяет описать потоки данных, передаваемых между объектами
классов Решение, Задание и Алгоритм, реализующий метод, для сценария Процесс решения.
Диаграммы состояний объекта
поведение, для них целесообразно разрабатывать диаграммы состояний.
Диаграммы состояний объекта. Под состоянием объекта применительно к диаграмме
состояний понимают ситуацию в жизненном цикле объекта, во время которой он: удовлетворяет
некоторому условию, осуществляет определенную деятельность или ожидает некоторого события.
Изменение состояния, связанное с нарушением условия или, соответственно, завершением
деятельности или наступлением события называют переходом.
Диаграммы состояний показывают состояния объекта, возможные переходы, а также события
или сообщения, вызывающие каждый переход.
|
|
|
Условные обозначения состояний приведены на рис. 7.18. Действие, указанное после слова
Вход, выполняется при входе в состояние, а действие, указанное после слова Выход - при выходе
из него. Деятельность связывается с нахождением в состоянии.
Переход обозначается линией со стрелкой и может быть помечен меткой, состоящей из трех
частей, каждую из которых можно опустить:
<Событие> [<Условие>]/<Действие>.
Если событие не указано, то это означает, что переход выполняется по завершению
деятельности, связанной с данным состоянием. Если же оно указано - то при наступлении
события.
Условие записывается в виде логического выражения. Переход происходит, если результат
выражения — «истина». Объект не может одновременно перейти в два разных состояния, поэтому
условия перехода для любого события должны быть взаимоисключающими.
В отличие от деятельностей, действия, указанные для перехода, связывают с последним и
рассматривают как мгновенные и непрерываемые.
При необходимости можно определять суперсостояния (рис. 7.18, г), которые объединяют
несколько состояний в одно. Этот механизм обычно используют, чтобы показать переход из
нескольких состояний в одно и то же состояние, например, при отмене каких-либо действий.
|
|
|
Диаграмма компонентов
Диаграммы компонентов применяют при проектировании физической структуры
разрабатываемо программного обеспечения. Эти диаграммы показывают, как выглядит
программное обеспечение на физическом уровне, т. е. из каких частей оно состоит и как эти части
связаны между собой.
Диаграммы компонентов оперируют понятиями компонент и зависимость. Под компонентами
при этом понимают физические заменяемые части программного обеспечения, которые
соответствуют некоторому набору интерфейсов и обеспечивают их реализацию. По сути дела, это
отдельные файлы различных типов: исполняемые (.ехе), текстовые, графические, таблицы баз
данных и т. п., составляющие разрабатываемое программное обеспечение. Условные графические
обозначения компонентов различных типов приведены на рис. 7.22.
Зависимость между компонентами фиксируют, если один компонент содержит некоторый
ресурс (модуль, объект, класс и т. д.), а другой - его использует. Качество компоновки оценивают
по количеству и типу связей между компонентами, т. е. по степени независимости компонентов.
На диаграмме компонентов зависимость обозначают пунктиром со стрелкой на конце.
|
|
|
На рис. 7.23 в качестве примера приведена диаграмма компонентов системы решения
комбинаторно-оптимизационных задач. 
При компонентном подходе на диаграмме компонентов целесообразно показывать
интерфейсы, через которые компоненты связаны между собой (рис. 7.24) 
Кроме этого, на диаграмме компонентов допустимо уточнять зависимость между
компонентами, используя обозначения обобщения, ассоциации, композиции, агрегатирования и
реализации. Так, на рис. 7.23 и 7.24 показано, что база данных включает (отношение композиции)
две таблицы.
Диаграмма размещения
UML - диаграмму размещения.
Диаграмма размещения отражает физические взаимосвязи между программными и
аппаратными компонентами системы. Каждой части аппаратных средств системы, например,
компьютеру или датчику, на диаграмме размещения соответствует узел. Соединения узлов
означают наличие в системе соответствующих коммуникационных каналов. Внутри узлов
указывают размещенные на данном оборудовании программные компоненты разрабатываемой
программной системы, сохраняя указанные на диаграмме компонентов отношения зависимости.
|
|
|
С точки зрения диаграммы размещения локальная и глобальная сети - это тоже узлы, которые
обладают некоторой спецификой. На рис. 7.27 показаны условные обозначения узлов (процессора
и устройства) на диаграмме размещения.
Структурное тестирование
Структурное тестирование называют также тестированием по «маршрутам», так как в этом
случае тестовые наборы формируют путем анализа маршрутов, предусмотренных алгоритмом.
Под маршрутами при этом понимают последовательности операторов программы, которые
выполняются при конкретном варианте исходных данных.
В основе структурного тестирования лежит концепция максимально полного тестирования
всех маршрутов программы. Так, если алгоритм программы включает ветвление, то при одном
наборе исходных данных может быть выполнена последовательность операторов, реализующая
действия, которые предусматривает одна ветвь, а при втором - другая. Соответственно, для
программы будут существовать маршруты, различающиеся выбранным при ветвлении
вариантом.
Считают, что программа проверена полностью, если с помощью тестов удается осуществить
выполнение программы по всем возможным маршрутам передач управления. Однако нетрудно
видеть, что даже в программе среднего уровня сложности число неповторяющихся маршрутов
может быть очень велико, и, следовательно, полное или исчерпывающее тестирование
маршрутов, как правило, невозможно.
Структурный подход к тестированию имеет ряд недостатков. Так тестовые наборы,
построенные по данной стратегии:
• не обнаруживают пропущенных маршрутов;
• не обнаруживают ошибок, зависящих от обрабатываемых данных, например, в операторе if
(a - b) < eps - пропуск функции абсолютного значения abs проявится только, если а < Ь;
• не дают гарантии, что программа правильна, например, если вместо сортировки по
убыванию реализована сортировка по возрастанию.
Для формирования тестов программу представляют в виде графа, вершины которого
соответствуют операторам программы, а дуги представляют возможные варианты передачи
управления. Ниже приведен текст программы, которая определяет значение х в зависимости от
значений параметров процедуры.
Функциональное тестирование
Одним из способов проверки программ является тестирование с управлением по данным или по
принципу «черного ящика». В этом случае программа рассматривается как «черный ящик», и целью
тестирования является выяснение обстоятельств, в которых поведение программы не соответствует
спецификации.
Для обнаружения всех ошибок в программе, используя управление по данным, необходимо
выполнить исчерпывающее тестирование, т. е. тестирование на всех возможных наборах данных. Для
тех же программ, где исполнение команды зависит от предшествующих ей событий, необходимо
проверить и все возможные последовательности. Очевидно, что проведение исчерпывающего
тестирования для подавляющего большинства случаев невозможно. Поэтому обычно выполняют
«разумное» или «приемлемое» тестирование, которое ограничивается прогонами программы на
небольшом подмножестве всех возможных входных данных. Этот вариант не дает гарантии
отсутствия отклонений от спецификаций.
Правильно выбранный тест должен уменьшать, причем более чем на единицу, число других
тестов, которые должны быть разработаны для обеспечения требуемого качества программного
обеспечения.
При функциональном тестировании различают следующие методы формирования тестовых
наборов:
• эквивалентное разбиение;
• анализ граничных значений;
• анализ причинно-следственных связей;
• предположение об ошибке
Классификация ошибок
Отладка-это процесс локализации и исправления ошибок, обнаруженных при тестировании
программного обеспечения. Локализацией называют процесс определения оператора программы,
выполнение которого вызвало нарушение нормального вычислительного процесса. Доя
исправления ошибки необходимо определить ее причину, т. е. определить оператор или фрагмент,
содержащие ошибку. Причины ошибок могут быть как очевидны, так и очень глубоко скрыты.
В целом сложность отладки обусловлена следующими причинами:
• требует от программиста глубоких знаний специфики управления используемыми
техническими средствами, операционной системы, среды и языка программирования,
реализуемых процессов, природы и специфики различных ошибок, методик отладки и
соответствующих программных средств;
• психологически дискомфортна, так как необходимо искать собственные ошибки и, как
правило, в условиях ограниченного времени;
• возможно взаимовлияние ошибок в разных частях программы, например, за счет затирания
области памяти одного модуля другим из-за ошибок адресации;
• отсутствуют четко сформулированные методики отладки.
В соответствии с этапом обработки, на котором проявляются ошибки, различают (рис. 10.1):
синтаксические ошибки - ошибки, фиксируемые компилятором (транслятором, интерпретатором)
при выполнении синтаксического и частично семантического анализа программы;
ошибки компоновки - ошибки, обнаруженные компоновщиком (редактором связей) при
объединении модулей программы;
ошибки выполнения - ошибки, обнаруженные операционной системой, аппаратными средствами
или пользователем при выполнении программы.
Дата добавления: 2019-02-12; просмотров: 470; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!