Стратегии тестирования. Методы тестирования. Восходящий и нисходящий методы тестирования, страница 4

13.Понятие объекта. Состояние, поведение и индивидуальность объекта. Категории операций над объектами. Объекты: для исследователя предметной области: объект – опознаваемый предмет или сущность (реальный или абстрактный), имеющий важное функциональное значение в данной предметной области. С т..з. проектирования программной системы: объект – сущность обладающая состоянием, поведением и индивидуальностью. С т.з. программирования: объект – совокупность данных (переменных), существующая в машинном представлении как единое целое. Состояние объекта – перечень всех возможных свойств объекта и текущих значений каждого из этих свойств. Если объект составной, то его состояние определяется состоянием всех его частей. Поведение хар-ся то, как объект воздействует или подвергается воздействию других объектов с т.з. изменения состояния этих объектов. Индивидуальность – совокупность свойств объекта, которые отличают его от всех других объектов. Структурная неопределенность - нарушение индивидуальности. Категории операций над объектами: 1.Функция управления – операция которая изменяет состояние объекта. 2.Функция доступа – операция дающая доступ для определения состояния объекта без его изменения. 3.Функция реализации – операция над информацией из внешних источников, не изменяющая состояния данного объекта (изменяется состояние других объектов). 4.Конструктор – операция создания и инициализации объекта. 5.Деструктор - операция удаления объекта. 6.Вспомогательные функции – функции, которые используются для реализации перечисленных операций. Интерфейс: совокупность всех методов относящихся к конкретному объекту образует протокол объекта.

18.Основные черты унифицированного процесса(RUP). Фазы и основные потоки работОсновные черты RUP: 1.Использование UML (Unified Modelling Language) (по UML сущ-ет стандарт ОМС); 2.Компонентно-ориентированная технология (объектоно-ориентир) – компонентное; 3.Процесс разработки программ управляется прецедентами (USE CASE). Прецедент – часть функциональности системы, необходим для получения пользователем полезного и приятного результата (последовательность действий пользователя и реакции системы). Исполнители, пользователи, actoe, внешняя система (октант). Созданием прецедента мы задаем функциональные требования к системе.

Требования –> Анализ –> Проектирование  –> Реализация. Прецедент используется для написания тестов. По прецедентам создаются тесты. Формируется модель прецедентов. Они явл-ся основой для разработки системы. В процессе тестирования сравниваются результаты действия системы и результаты тестов. 4.Унифицированный процесс ориентирован на архитектуру. Архитектура – набор решений по организации программной системы (т.е. по выбору эл-ов структуры ПС, их интерфейсов и правил взаимодействий). Примеры:1.Брокер (механизм управления удаленными объектами); 2.Уровни (абстрактные машины) - приложение разбивается на уровни. И приложения имеют сведения об организации следующего нижнего уровня. 3.Клиент-сервер – 2уровня: клиентская часть взаимодействует с пользователем, а все действия выполняются на сервере. 4.Трех уровневая архитектура – явно выражается: -предоставляет информацию пользователю; -решение прикладной задачи; -сохранение данных. Шаги построения архитектуры: 1.по нефункц. требованиям объявляется платформа (по дополнительным соображениям). 5.Процесс явл-ся интерактивным и инкрементным: Сначала создается скелет, а потом добавляются элементы. При проектировании есть фазы: -анализ и определение требований: определение задач создаваемого продукта; подготовки исходного плана проектирования; -фаза проектирования: создание базового уровня архитектуры и опреление большинства требований; -фаза постоения: заканчивается созданием продукта (системы); -фаза внедрения: передача пользователям, обучение и внедряется. 

Основной рабочий процесс: Определение требований: Цель – направить процесс разработки на получение правильной с т.з. пользователя системы; Шаги (не последовательно): 1.Vision (feature) – неформальный документ об общих положениях прогр продукта. Что должна делать система, архитектура системы, т.е. формулировка задачи. Перечисление возможных требований и предложений. 2.Осознание контекста системы формирование представления о тех условиях в которых система будет эксплуатироваться. 3.Составление глоссария. 4.Определенние функциональных требований 5.определение нефункциональных требований.