Диаграммы активности (деятельностей)
Диаграммы деятельностей – это одна из самых больших неожиданностей UML. Используются для описания поведения систем.
В отличие от большинства других средств UML диаграммы деятельностей не имеют отношения к работам «троих друзей». Диаграммы деятельностей сочетают в себе идеи различных методов: диаграмм событий Джима Оделла, диаграмм состояний SDL и сетей Петри. Эти диаграммы особенно полезны в сочетании с потоками работ, а также в описании поведения, которое включает параллельные процессы.
Основным элементом диаграммы деятельностей является деятельность. Причем диаграммы деятельностей, как и диаграммы классов, могут строиться с трех различных точек зрения: с концептуальной, с точки зрения спецификации и с точки зрения реализации. В соответствии с точкой зрения деятельность рассматривается по-разному.
На концептуальной диаграмме деятельность – это некоторая задача, которую необходимо автоматизировать или выполнить вручную.
На диаграмме, построенной с точки зрения спецификации или реализации, деятельность – это некоторый метод над классом.
Рассмотрим пример на рис.6.8.1. Диаграмма деятельностей описывает метод над типом Личность.
Мы видим на примере, что за каждой деятельностью может следовать другая деятельность. В этом случае они образуют простую последовательность (например, за деятельностью «Положить Кофе в Фильтр» следует деятельность «Вставить Фильтр в Автомат»). При таком подходе диаграмма деятельностей напоминает блок-схему.
Разницу можно обнаружить, если посмотреть на деятельность «Поискать Напиток». Эта деятельность активизирует два действия: каждое действие содержит условие, которое может принимать одно из двух значений: «истина» или «ложь» (так же, как на диаграмме состояний). У нас Личность осуществляет деятельность «Поискать Напиток», выбирая между кофе и колой.
Предположим, что мы отыскали кофе, то есть идем вниз по «кофейному» маршруту. Этот путь ведет к линейке синхронизации, с которой связана активизация трех деятельностей: «Положить Кофе в Фильтр», «Добавить Воду в Ёмкость» и «Достать Чашки». Диаграмма указывает, что эти три деятельности могут выполняться параллельно. Причем порядок их выполнения не играет роли: их можно выполнять в любой последовательности, а можно и чередовать друг с другом (например, достать одну чашку, затем добавить немного воды в ёмкость; достать другую чашку, добавить еще немного воды и т.д.). А можно делать некоторые вещи одновременно: одной рукой наливать воду, а другой доставать чашки. Любой из этих вариантов допустим. Это и показывает линейка синхронизации, то есть выбор порядка выполнения действий остается за Личностью (за тем, кто выполняет эти действия). В этом заключается главное различие между диаграммой деятельностей и блок-схемой, то есть блок-схемы обычно показывают последовательные процессы, а диаграммы деятельностей могут поддерживать дополнительно параллельные процессы.
Поэтому диаграммы деятельностей являются полезными при параллельном программировании. Можно графически изобразить все ветви и показать, когда их необходимо синхронизировать. Такая возможность важна также при моделировании бизнес - процессов, так как среди бизнес-процессов часто встречаются такие, которые не обязаны выполняться последовательно: диаграмма побуждает людей искать возможности делать дела параллельно.
Итак, если при описании поведения системы выявляются параллельные процессы (деятельности), то их необходимо синхронизировать.
Простая линейка синхронизации (как в примере) показывает, что выходная деятельность ( «Включать Автомат» ) активизируется только тогда, когда выполнены обе входные деятельности: «Добавить Воду в Емкость» и «Вставить Фильтр в Автомат». Линейки могут быть и более сложными.
Обратите внимание, что второе решение (первое – «Поискать Напиток») относится к составным. Если кофе нет, то приходим ко второму решению, связанному с колой. При такой последовательности решений второе решение обозначается ромбом. Количество вложенных решений может быть любым.
Далее обратите внимание, что деятельность «Выпить Напиток» имеет два входа. Это означает, что она будет выполнена в любом случае, т. е. рассматривается как условие «ИЛИ» (выполняется, если выполняется хотя бы одна из двух входящих деятельностей). Линейку же синхронизации можно рассматривать как условие «И».
Диаграммы деятельности полезны для описания сложных методов. Их также можно применять где угодно. Например, для описания вариантов использования, если вариант использования представляет собой сложный процесс (функцию).
Каркасы и паттерны.
Образец (Pattern – паттерн) проектирования предлагает типичное решение типичной проблемы в определенном контексте.
Каркас (Framework) – это коллекция классов, используемых в нескольких различных приложениях (чаще всего в одной конкретной области).
Или другими словами – каркас – это архитектурный образец, который предлагает расширяемый шаблон (чаще всего классы внутри каркаса абстрактные, а в приложении используются через наследование (в основном) или агрегации, хотя в каркасе могут быть и конкретные классы, которые можно использовать).
Kаркасы описывают структуру и поведение системы в целом, а образцы описывают структуру и поведение сообщества классов. Образцы используются и в каркасах, и в процессе детального проектирования.
Образцы обычно накапливаются у тех разработчиков, которые умеют находить в своих проектах повторяющиеся решения.
Все паттерны авторы монографии делят на 3 категории: структурные, порождающие и паттерны поведения.
1) Структурные образцы (Адаптер, Компоновщик, Декоратор, Мост, Фасад и др. (всего 7)) используются с целью образования более крупных структур из классов и объектов для получения новой функциональности.
Структурные паттерны (отсюда их название) имеют дело со способами представления объектов (такими, как деревья или связные списки).
2) Порождающие (Креационные) паттерны (Aбстрактная Фабрика, Строитель, Фабричный метод, Прототип, Одиночка).
3) Паттерны поведения (Команда, Итератор, Интерпретатор, Посредник, Наблюдатель, Состояние, Шаблонный метод и др.).
Паттерн поведения позволяет нам следить за поведением объектов
Иногда в каркасах используется отношение “зависимости”, т.е. объекты каркаса вызывают (или уточняют) абстракции пользователя. Короче, как и в паттернах, каркас настраивается на пользователя. Короче, если выражаться короче, слово «короче» это, короче, самое, что ни наесть короче. Короче, выражаясь понятным языком, «короче» — самое короткое слово, короче, из всего, короче, ну, короче, нашего языка.
Акцент в каркасе делается на повторном использовании дизайна, а не кода (как в библиотеках).
Проектировщик каркаса рассчитывает, что единая архитектура будет пригодна для всех приложений в данной предметной области. Поэтому каркас должен быть максимально гибким и расширяемым, так как приложения сильно зависят от каркаса.
По этой же причине каркасы часто спроектированы с использованием паттернов
Поскольку между паттернами и каркасами много общего, то часто возникает вопрос: в чем же они различны? Так вот, существует 3 основных различия:
1. Паттерны проектирования более абстрактны, чем каркасы. Что имеется в виду? Паттерн необходимо реализовать всякий раз, когда он используется (хотя сегодня уже есть много примеров реализации паттернов на С++, Java).
2. Паттерны мельче, чем каркасы (в смысле архитектурных элементов типичный каркас содержит несколько паттернов).
3. Паттерны менее специализированы, чем каркасы. Каркас почти всегда создается для конкретной предметной области, а паттерны можно использовать в приложениях почти любого вида. Хотя, безусловно, есть и более специализированные паттерны. Например, для распределения систем, для параллельного программирования, для проектирования БД и др.
Основные понятия и определения теории тестирования. Подходы к тестированию. Стратегии тестирования. Критерии тестирования.
Общее содержание этапа тестирования было рассмотрено вкратце ранее, когда рассматривали ЖЦ ПО.
Заметьте (это важно!), что в процессе тестирования ставится цель - обнаружение ошибок, а не демонстрация правильности работы программы.
Тестировщик ставит цель - найти ошибки! А вот исправлять их должен программист-разработчик .Именно с этой целью во многих фирмах (Software) создаются специальные группы - группы тестирования. Основной задачей такой группы является проведение определённой политики тестирования программ и контроль полноты тестирования.
На сегодняшний день в основном используются 3 подхода к тестированию программ: статическое тестирование; динамическое тестирование; и формальное доказательство правильности программы (сюда же относят символьное тестирование).
Статическое тестирование не предполагает выполнение (запуск) программы. Код тестируется только путем логического анализа. Статический анализ программного кода может выполняться и в одиночку - за столом. Этот вид тестирования выполняет, как правило, сам автор программного кода, хотя может и кто-то другой.
Динамическое тестирование предполагает выполнение программы на машине. Это наиболее распространённый (и приятный) подход к тестированию.
Наконец, третий подход - верификация программ, или как ещё говорят, доказательство правильности программы. Суть верификации: проводится аналитическое доказательство того, что программа удовлетворяет своей спецификации. Вообще говоря, проводить верификацию бывает сложнее, чем писать код (если не считать игрушечных программ). Одно время даже предпринимались попытки автоматизировать этот процесс. Но, к сожалению, для реальных программ в ближайшем будущем это недостижимая цель.
----------------------------------
На сегодняшний день определились две стратегии тестирования программы:
1. тестирование "черного ящика" (или функциональное тестирование).
2. тестирование "белого ящика" (или структурное тестирование).
50. Критерии тестирования стратегии "черного ящика".
При использовании этой стратегии программа рассматривается как черный ящик, т.е. внутренняя структура программы (её логика) нам не видны. Известны только функции программы (спецификация программы), а также известны имена и типы входных и выходных данных программы, т.е. имеем:
Исчерпывающее тестирование программы, как правило, невозможно. Например, если в программе 10 входных величин и каждая принимает по 10 значений, то для исчерпывающего (полного) тестирования потребуется 10^10 тестов.
Критерии:
1. Эквивалентное разбиение
2. анализ граничных значений.
3. метод функциональных диаграмм.