Ответы на все вопросы (СиППО (24, 29-41))

Посмотреть архив целиком




24. Динамическое создание и уничтожение объектов в С++

29.  Виды контроля программ; тестирование и отладка.

30.  Методы функционального тестирования.

31.  Методы структурного тестирования. Тестирование путей.

32.  Совместное тестирование модулей.

Тестирование программных комплексов, построенных функциональной декомпозицией (ФД)

Тестирование программных комплексов, построенных по ООП

33.  Тестирование программ и жизненный цикл программного продукта.

34.  Общая характеристика и назначение языка UML.

35.  Диаграммы вариантов использования, назначение, компоненты, отношения между компонентами.

36.  Диаграмма последовательности и кооперативная диаграмма, их назначение, компоненты.

37.  Диаграмма классов, характеристики класса

38.  Диаграмма классов, типы и характеристики отношений. (+можно почитать еще 37 билет)

39.  Диаграммы состояний, их назначение, компоненты.

40.  Диаграммы деятельности, их назначение, компоненты.

41.  Диаграммы компонентов и размещения, их назначение, составные части.





24. Динамическое создание и уничтожение объектов в С++

̆ объект является либо статическим, либо автоматическим. Статический объект размещается в памяти в момент запуска программы и существует там до ее завершения. Автоматический объект размещается в памяти всякий раз, когда управление попадает в блок, содержащий определение объекта, и существует только до тех пор, пока управление остается в этом блоке. Тем не менее, часто бывает удобно создать новый объект, который существует до тех пор, пока он не станет ненужным. В частности, бывает удобно создать объект, который можно использовать после возврата из функции, где он был создан. Подобные объекты создает операция new, а операция delete используется для их уничтожения в дальнейшем. Про объекты, созданные операцией new, говорят, что они размещаются в свободной памяти. Примерами таких объектов являются узлы деревьев или элементы списка, которые входят в структуры данных, размер которых на этапе трансляции неизвестен. 

Объект, созданный с помощью операции new, существует, до тех пор, пока он не будет явно уничтожен операцией delete. После этого память, которую он занимал, вновь может использоваться new. Обычно нет никакого "сборщика мусора", ищущего объекты, на которые никто не ссылается, и предоставляющего занимаемую ими память операции new для повторного использования. Операндом delete может быть только указатель, который возвращает операция new, или нуль. Применение delete к нулю не приводит ни к каким действиям.

Операция new может также создавать массивы объектов, например:

char* save_string(const char* p) {

    char* s = new char[strlen(p)+1]; 

    strcpy(s,p); 

    return s;

}

Отметим, что для перераспределения памяти, отведенной операцией new, операция delete должна уметь определять размер размещенного объекта. Например:

int main(int argc, char* argv[]) {

    if (argc < 2) exit(1); 

    char* p = save_string(arg[1]); 

    delete[] p;

}

Чтобы добиться этого, приходится под объект, размещаемый стандартной операцией new, отводить немного больше памяти, чем под статический (обычно, больше на одно слово). Простой оператор delete уничтожает отдельные объекты, а операция delete[] используется для уничтожения массивов.

Операции со свободной памятью реализуются функциями

void* operator new(size_t); 

void operator delete(void*);

Здесь size_t - беззнаковый целочисленный тип, определенный в .

Стандартная реализация функции operator new() не инициализирует предоставляемую память.

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

char* p = new char [100000000];

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

#include  

#include  

#include

void out_of_store() {

cerr << "operator new failed: out of store\n"; exit(1);

} 

int main() {

set_new_handler(&out_of_store); char* p = new char[100000000]; cout << "done, p = " << long(p) << '\n';

}

скорее всего, будет напечатано не "done", а сообщение:

operator new failed: out of store

С помощью функции new_handler можно сделать нечто более сложное, чем просто завершить программу. Если известен алгоритм операций new и delete (например, потому, что пользователь определил свои функции operator new и operator delete), то обработчик new_handler может попытаться найти свободную память для new. Другими словами, пользователь может написать свой "сборщик мусора", тем самым сделав вызов операции delete необязательным. Однако такая задача, безусловно, не под силу новичку.

По традиции операция new просто возвращает указатель 0, если не удалось найти достаточно свободной памяти. Реакция же на это new_handler не была установлена. Например, следующая программа:

#include

main()

{

    char* p = new char[100000000]; 

    cout << "done, p = " << long(p) << '\n';

}

выдаст

done, p = 0

Память не выделена, и вам сделано предупреждение! Отметим, что, задав реакцию на такую ситуацию в функции new_handler, пользователь берет на себя проверку: исчерпана ли свободная память. Она должна выполняться при каждом обращении в программе к new (если только пользователь не определил собственные функции для размещения объектов пользовательских типов).







29.  Виды контроля программ; тестирование и отладка.

 

Методы проверки программ разделяют на статические и динамические.

 

Статические -- анализ текста программы без выполнения.

Динамические -- выполнение программы на тестовых наборах исходных данных и анализа полученных результатов.

 

1. Статический и синтаксический анализ.

Соблюдено ли формальное выполнение программы

2. анализ качества текста программы

for(int i>0; i<8; i++);

3. верификация программы. математическое доказательство корректности программы.

4. инспекция программы

а) для решения достаточно сложной задачи

б) написанный текст просм. контролем качества

 

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

 

Отладка -- выявление и устранение причин неправильной работы программы, если факт неправильной программы установлен тестированием.

 

Полное тестирование -- проверка программы на всех возможных значениях исходных данных и их сочетаниях.

 

Достаточное тестирование - тестирование на подмножестве исходных данных в надежде на то, что все ошибки найдутся.

 

Тестирование:

1 примитивных программ

2 программных комплексов

 

1-е не содержат вызовов процедур и функций

2-е делятся на два вида:

* построенные методом ф-ной декомпозиции

* по объектно-ориентированной методике

 

Тестирование примитивных программ

2 подхода взаимодополняют друг друга

- функциональное тестирование, тестирование по данным и тестирование черного ящика

- структурное тестирование, тестирование по управлению, тестирование белого ящика

 



 

30.  Методы функционального тестирования.

ИД -> ПР в квадратике -> Результат

 

При ФТ структура программы неизвестна или мы ей не пользуемся.

 

3 метода ФТ:

1) Метод эквивал. разбиения, метод классов эквивалентности

2) метод граничных значений

3) метод функциональных диаграмм

 

Пример

y = |x|

 

y = { x, x >= 0

       { -x, x<0

 

Задача имеет 2 класса эквивалентности

 

ОПР: Классы эквив. -- подмножество значений исходных данных, такое, что каждый элемент этого подмножества в качестве теста эквивалентен каждому другому элементу этого же подмножества.

 

Правильные КЭ и неправильные КЭ.

 

П.К.Э. - допустимые значения исходных данных

Н.К.Э. - недопустимые значения исходных данных

 

Пример y:=lnX,

x>0 - ПКЭ

x <= 0 - НКЭ

x принадлежит [1.5;8.3]

 

программа должна быть протестирована как на ПКЭ, так и на НКЭ

 

Тестирование:

1. выделить классы эквивалентности

2. построить тесты, таким образом, чтобы все КЭ были охвачены, но чтобы суммарное количество тестов было минимальным

(для этого нужно знать какому классу эквивалентности какой ответ соответствует)

 

Пример: задан массив, найти среднее арифметическое значение элементов, принадлежащих интервалу 10 <= Xi <= 20

 

1) Xi < 10

2) 10 <= Xi <= 20

3) Xi > 20

 

Xi >= C1

Xi <= C2

 

I. C1…C2

5…15…25

 

II. Xi < 10 or Xi > 20

 

Слабое место: не всегда легко разбить на классы. Может быть много входных данных => множество количества сочетаний

10 <= Xi <= 20

50 <= Yi <= 55

Xi + Yi <= 60

 

2) Требует использования в качестве тестов. знач. на и около границ классов эквивалентности.

Подход теоретиков: используя данные типа real (4 байт) (точность 10^-6)

10 != 10^-5

Подход практиков: вполне определена точность (10 +- 0.01)

 

0.99     |    10               10.01

не было учтено 1 ср. арифметическое, а  в практике учтено

 

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

 

3) Метод, который призван помочь преодолеть основной недостаток (!)-го метода -- колоссальная трудоемкость!!111

 

Входы                           Выходы

1                                             100

2                                             101

3

(тут короче какие-то стремные линии от входов к выходам)

позволяет выделить неопределенности

 

Чтобы перейти к тестам должны быть использованы дополнительные условия:

1) один и только один

2) хотя бы один

3) взаимное отрицание

4) если А, то Б

(тут еще картиночки шли)

5) если А, то не Б

 

Задача:

пользователь в праве выбрать первую или вторую схемы оплаты за электроэнергию. Если пользователь выбрал 1-ю схему, <=100, то должен оплатить постоянную сумму С. Если 1-ю, то его  оплата вычисляется по методике P1. Если он выбрал 2ю схему и расходовал <= 100, для расчета применяется методика P2, а если 2-ю схемы оплаты и расх > 100 то P1.

 

I                  <= 100                  C

                  >100                         P1

II                  <= 100                  P2

                  > 100                   P1

 

В таком случае получим следующие входы

(тут снова картинка)

 

Как анализировать и составлять тесты?

Разобраться при каких сочетания входов будет получен выход С, можем исключая не, которых не может быть.




31.  Методы структурного тестирования. Тестирование путей.

Граф-программы:

 

Отрывок программы

Xi = 3.5

Ki = 5

if ( z>x) AND (k

else Ki := k-1

Z:=K*x

 

нарисуем для него граф

 

1

  \

   2

     \

     3--4----5

     |    /      /

     |   /     /

     6      /

     |     /

     |   /

     7

цикломатическое число = 3

 

Цикломатическая сложность графа программы -- это цикломатическое число графа программы

 

Программа, которая не содержит разветвлений и циклов имеет цикломатическую сложность >1

 

Таким образом, составить тесты, чтобы все пути были пройдены хотя бы 1 раз

 

Усложняющее обстоятельство: программа имеет 25 строк, то граф усложняется, кол-во путей растет

 

Можно тестировать программу по частям (ваш К.О)

 

Упрощающее обстоятельство:

допустим,

if ( k>50) then p:=1 else p:=-1

z:=4.8

if (k<20) then t:=1 else t:0

z:=p*z

 

Могут быть противоречивые пути, невозможно подобрать данные, чтобы путь пройти.

 

Рекомендуют начинать с функционального тестирования. Если результаты хорошие и логическая сложность задачи невелика (мало условных операторов), то этим ограничиваются.

 

Если в программе есть ошибки и найти их не удалось, или задача обладает высокой структурой, то надо проводить структурное тестирование.

 

Проектируя тесты пришли к выводу, что надо N тестов. После этого нарисовали граф программы и стали смотреть сколько путей охватывают эти N тестов.

 

1) N - путей, каждый из тестов соответствует одному пути. Значит эти N тестов надо выполнить

2) M - путей ( != Т),

21 N > M

* t1, t2 по одному пути

* t1, t2 - на самом деле разные, но пойдут по одному пути => нашли 1 ошибку

 

22. N < M

* эти пути противоречивы,и их пройти невозможно

* найден путь, не охваченный тестами => увеличить количество тестов

 




32.  Совместное тестирование модулей.

 

Тестирование программных комплексов, построенных функциональной декомпозицией (ФД)

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

 

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

 

Вывод: n-ной количество драйверов и заглушек.

"+" - возможно тщательное тестирование всех модулей

работу можно распараллелить

уменьшение затрат машинного времени по сравнению с пошаговым тестированием.

 

Протестируем модули самого нижнего уровня. После этого поднимемся на следующий уровень, но заглушки не использ., в качестве заглушек протестируем модули А1 и Б2 (Снизу Вверх)

 

Сверху вниз: верхний уровень, нужны заглушки. Так до нижнего.

В большинстве случаев пошаговое тестирование лучше.

В чем преимущество?

1. Можно тщательно протестировать логику 1го уровня

2. при тестировании модулей следующего уровня проверить интерфейс, вместе с этим протестировать модули нижнего уровня

 

Недостатки: долго не существует программа как целое.

Системные ошибки всплывают относительно позднее.

 

(тут видимо чувак совсем устал писать и почерк стал нечитаем)

 

(+) Начинает функционир. раньше, как единое целое (чуть выше было указано взаимоисключающее понятие)

(-) подбирать наверху такие данные чтобы все уровни были

 

Надо учитывать информационные связи. (??????)

 

Тестирование информации

Системное тестирование

 

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

 

Тестирование программных комплексов, построенных по ООП 

- Тестировать методы в составе классов

- Тестирование классов - взаимодействие классов, иерархии классов

 

ob1:cl1 ---- message ----- ob3:cl3

         \                           /

          \                       /

               \               /

                 ob2:cl1

 

объекты передают друг другу сообщения (вызов методов класса-адресата)

ob3 - тестирование примитивных классов.

 

ОПР: Класс называется примитивным, если он только принимает сообщения (если он не отправляет сообщения)

 

CL3

Данные

Методы

(все в квадратике и две перекладинки)

 

Должны убедиться, что класс принимает и обрабатывает направленные на него сообщения.

 

Проверка интерфейсной части

Занимаемся следующим классом ob2

Проверить принимает ли сообщения и отправляет ли сообщения и корректны ли все данные и т.д. отрабатываем все схемы

 

- Тестирование иерархии классов

(тут какая-то неприличная картинка)

 

                     A

                     F() Abstract

                     |

               ------------------

         *         |                |

               B               C

               f()

 

Всегда сверху - вниз!!!11

 

Допустим класс А всесторонне проверили:

----> X : B

 

Если сообщение отрабатывается проверенным методом, то можно не тестировать, т.к. там протестировано (К.О?)

При тестировании методов должны убедиться, что проверены все реализации.

 

f()

-------> y:C

 

f()

-------> x:B  -- новая реализация и ее надо проверить

 

Класс является абстрактным, значит не можем тестировать напрямую:

1. Запомним абстрактные методы в дельфи и чисто виртуальные функции Си++ и проверим

2. Спустимся в (*), считаем комментарии и тестир. абстр методы и т.д. (чо-чо?)

 

Регрессивное тестирование -- проверка: после разработки новой версии проверяем функциональность старой версии.

 



33.  Тестирование программ и жизненный цикл программного продукта.

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

Дефект – симптом существования ошибки в программе или возникновение проблем при ее выполнении.

Отладка – выявление причин и устранение ошибок в программах.

Начальное тестирование проводит автор программы. Дальнейшее тестирование должны проводить специалисты, не принявшие участие в реализации, а на заключительной стадии тестирования – специалисты, вообще не участвовавшие в разработке. По принципу «Со стороны виднее». Отладку, «к сожалению», придется выполнить самому автору: кто лучше его знает, где может быть ошибка и как ее устранить?    

Рассмотрим организацию тестирования и его разновидности. Особенности тестирования объектно-ориентированных программ будут рассмотрены в следующей главе. При тестировании необходимо выполнение следующих задач:

·        Планирование тестов для каждой итерации, включая тесты на целостность и системные тесты. Тесты на целостность проводятся после каждого билда,  системные тесты – только в конце итерации.

·        Проектирование и реализация тестов.

·        Проведение тестов и анализ их результатов. Билды, в которых обнаруживаются дефекты, возвращают на доработку и подвергают повторному тестированию.

Процесс тестирования начинается с планирования, которое выполняет инженер по тестированию. Он же проектирует тесты.  Инженер по компонентам реализует тесты. Тестер по целостности проводит тестирование интеграции, а системный тестер – тестирование системы. В завершение процесса инженер по тестированию оценивает его результаты.

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

Регрессионное тестирование – это повторное тестирование части билда, которая уже тестировалась на предыдущем билде. Цель регрессионного тестирования: убедиться в том, что «старая функциональность» из «старого билда» продолжает работать и после добавления «новой функциональности» через «новый билд».

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

 

Основные процессы жизненного цикла:

1.     заказ,

2.     поставка,

3.     разработка,

4.     эксплуатация,

5.     сопровождение.

Вспомогательные процессы жизненного цикла:

1.     документирование,

2.     управление конфигурацией,

3.     обеспечение качества,

4.     верификация,

5.     аттестация,

6.     совместный анализ,

7.     аудит, решение проблем.

Организационные процессы жизненного цикла:

1.     управление,

2.     создание инфраструктуры,

3.     усовершенствование,

4.     обучение.

Процесс разработки состоит из следующих работ:

1.     подготовка процесса,

2.     анализ требований к системе,

3.     проектирование системной архитектуры,

4.     анализ требований к программным средствам,

5.     проектирование программной архитектуры,

6.     техническое проектирование программных средств,

7.     программирование и тестирование программных средств,

8.     сборка программных средств,

9.     квалификационное испытание программных средств,

10.                       сборка системы,

11.                       квалификационные испытания системы,

12.                       ввод в действие программных средств,

13.                       обеспечение приемки программных средств.

Процесс эксплуатации состоит из следующих работ:

1.     подготовка процесса,

2.     эксплуатационные испытания,

3.     эксплуатация системы,

4.     поддержка пользователя.

Процесс сопровождения состоит из следующих работ:

1.     подготовка процесса,

2.     анализ проблем и изменений,

3.     внесение изменений,

4.     проверка и приемка при внесении изменений,

5.     перенос, снятие с эксплуатации.



 



 

34.  Общая характеристика и назначение языка UML.

Язык UML – Unified Modeling Language – унифицированный язык моделирования, предназначен для выполнения этапов анализа и проектирования программных средств. Кроме того, язык UML может быть использован при тестировании и для управления выполнением проекта. Язык UML поддерживает объектно-ориентированную методику разработки программных продуктов. 

С помощью языка UML можно выполнять следующие задачи:

∙        Описание требований к разрабатываемой системе.

∙        Описание структуры и бизнес-процессов предметной области.

∙        Проектирование архитектуры программного продукта.

∙        Проектирование размещения программного продукта в сети.

∙        Генерация  структуры объектно-ориентированной программы.

Как любой язык, так и UML имеет различные реализации. Так как UML является языком проектирования программных средств, то его реализации выполнены в виде CASE-средств (Computer Aided Software Engineering). Кроме того, для пользования им необходимо освоить методику работы с UML.

Язык UML это язык диаграмм и его использование заключается в их составлении. Каждая диаграмма состоит из компонентов и отношений между ними. Основные диаграммы языка UML:

∙        Диаграмма вариантов использования (Use Case Diagram), равнозначный термин - диаграмма прецедентов.

∙        Диаграмма последовательностей (Sequence Diagram).

∙        Диаграмма кооперации (Collaboration Diagram).

∙        Диаграмма классов (Class Diagram).

∙        Диаграмма деятельности (Activity Diagram).

∙        Диаграмма компонентов (Component Diagram).

∙        Диаграмма развертывания (Deployment Diagram).

∙        Диаграмма состояний (Statechart Diagram).

Диаграмма последовательностей и диаграмма кооперации вместе называют диаграммами взаимодействия.





35.  Диаграммы вариантов использования, назначение, компоненты, отношения между компонентами.

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

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

Рис. 2.1.

 

Между пакетами допускается только одна разновидность отношений - отношение зависимости. В данном случае это означает, что пакет 1 зависит от пакета 2. Допускается использование и нескольких уровней пакетов: внутри пакета могут находиться пакеты следующего уровня.

Примечание: пакеты могут использоваться не только в диаграммах вариантов использования но и в других диаграммах.

Рис. 2.2.

 

Основными компонентами диаграммы вариантов использования являются действующие лица (в литературе используют равнозначные термины актер, актант), варианты использования (равнозначный термин – прецедент) и отношения между ними. На рис. 2.2. показаны символы UML для их обозначения. 

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

На диаграмме вариантов использования могут быть применены (и показаны на диаграммы) следующие виды отношений:

·        Отношение ассоциации (association relationship).

·        Отношение расширения (extend relationship).

·        Отношение включения (include relationship).

·        Отношение обобщения (generalization relationship).

Отношение ассоциации используется для задания взаимодействия действующего лица и вариантов использования: какое действующее лицо какие варианты использует. Пример этого отношения приведен на рис. 2.2. 

Отношение расширения используется между вариантами использования: оно указывает, что один вариант расширяет возможности другого, но это расширение не имеет обязательного характера, а предоставляет дополнительные возможности, которые потребуются не всегда (например, подзадача, которая может возникнуть или нет).

Отношение включения показывает, что один вариант использования всегда включает и другой вариант использования (например, как подзадачу, которую придется всегда решить). Отношения расширения и включения представлены на рис. 2.3.

Отношение обобщения связывает менее общее с более общим. Подробно рассмотрим это отношение при обсуждении диаграмм классов. Пример отношения обобщения приведен на рис. 2.4.

 

Рис. 2.3.

Рис. 2.4.

 

Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе с помощью действующих лиц – потенциальных пользователей и вариантов использования – задач, с которыми они будут обращаться к разрабатываемому программному продукту. Рекомендуемые ограничения: действующих лиц не более 20, вариантов использования не более 50. В противном случае диаграмма теряет наглядность; в таком случае следует составить несколько диаграмм или использовать пакеты для структурирования модели. Важно сконцентрироваться исключительно на том, что должен делать создаваемый программный продукт, а не на том, как он это будет делать. Построение диаграммы вариантов использования специфицирует не только функциональные требования к проектируемой системе, но и выполняет исходную структуризацию предметной области.

Составление диаграммы вариантов использования позволяет:

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

2.     Варианты использования позволяют разработчикам понять назначение разрабатываемой системы.

3.     Варианты использования являются основой тестирования элементов программного продукта на всем протяжении его жизненного цикла; они позволяют проверять корректность их реализации.

Составление диаграммы вариантов использования рекомендуют выполнять в следующей последовательности:

1.     Выделить действующие лица. При этом надо четко ответить на вопрос: чем отличаются друг от друга отдельные действующие лица?

2.     Для каждого действующего лица выделить варианты использования. После этого составить общий список вариантов использования.

3.     Связать между собой действующие лица и варианты использования (установить отношение ассоциации).

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

Рассмотрим сказанное на небольшом учебном примере. Пусть требуется автоматизировать работу магазина. По телефону потенциальные покупатели могут получить  справки  о наличии товара, о ценах и характеристиках и при желании забронировать товар. Забронированный товар должен быть куплен в течение дня; забронированный, но не купленный товар после закрытия магазина считается свободным для продажи. Магазин торгует товарами малых размеров и массы, поэтому доставка товара покупателям не осуществляется. Покупатель, пришедший в магазин, может у продавцов также получать информацию о наличии товара, о ценах и характеристиках. Кроме того, продавец может выписывать счет на оплату товара, копия счета передается на склад,  кладовщик доставит товар на выдачу и сотрудник на выдаче, убедившись, что товар оплачен, передает его покупателю. Товар между выписыванием счета и доставкой кладовщиком на выдачу считается забронированным. Продавец может выписывать счет и на забронированный товар, а также забронировать товар. Забронированный у продавца товар обрабатывается аналогично забронированному по телефону. Выписанный, но не оплаченный в течение трех часов товар возвращается на склад и считается свободным для продажи другому покупателю. Автоматизация расчетов с покупателями и ведения бухгалтерского учета на данном этапе не рассматриваются. Менеджер магазина отслеживает расход товаров и состояние склада и принимает на этой основе решения о заказе новых партий у поставщиков или о продаже залежавшегося товара.

Действующие лица:

1.     менеджер,

2.     консультант у справочного телефона магазина,

3.     продавец,

4.     кладовщик,

5.     сотрудник на выдаче.

Примечание. В магазине несколько продавцов, кладовщиков и сотрудников на выдаче, но их задачи не отличаются друг от друга.

         Варианты использования.

Консультант на телефоне:

1.     получение справок о характеристиках продаваемых товаров,

2.     получение справок о наличии товара на складе,

3.     резервирование товара,

4.     аннулирование резервирований по желанию покупателя или после закрытия магазина.

Продавец:

1.     получение справок о характеристиках продаваемых товаров,

2.     получение справок о наличии товара на складе,

3.     резервирование товара,

4.     выписывание счета,

5.     передача копии счета на склад.

Кладовщик:

1.     Изменение количества товара на складе после отпуска,

2.     Изменение количества товара на складе после возврата с выдачи.

Менеджер:

1.     получение справок о наличии товара на складе,

2.     анализ хода продаж отдельных видов товаров,

3.     анализ времени нахождения товара на складе.

 

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

Рис. 2.5.

Рис. 2.6.



36.  Диаграмма последовательности и кооперативная диаграмма, их назначение, компоненты.

1) Диаграмма последовательности.

Работа программы заключается в обмене сообщениями между объектами. Любой объект является представлением какого либо класса. В общем случае можно иметь один или более объектов одного класса. Сообщение (message) представляет собой законченный фрагмент информации, который отправляется одним объектом другому. С программистской точки зрения сообщение – это обращение из одного объекта к методу в составе другого объекта. Естественно, что решение задачи сводится к обмену сообщениями между объектами в определенной последовательности. Для представления этого процесса и используется диаграмма последовательностей.

Рис. 2.21.

 

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

Рассмотрим компоненты диаграммы последовательностей на рис. 2.22.

На диаграмме обозначены объекты, задействованные при исполнении данного варианта использования. Обозначение объектов

  имя_объекта : имя_класса

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

Рис. 2.22.

Примечание: на диаграмме последовательности ось времени направлена сверху вниз.

Отдельные объекты могут быть уничтожены до завершения работы программы: в таком случае на их линии жизни ставится знак × (объект :Класс2). Часто уничтожение является результатом направления к такому объекту сообщения со стереотипом destroy(). Возможно и создание нового объекта в ходе работы программы. Такой объект  показан не у верхнего края диаграммы, а ниже; к такому объекту направлено сообщение стереотипа create(). На рисунке Объект3 : Класс3.

В процессе функционирования объектно-ориентированных систем  одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Для явного выделения состояния объекта, применяется фокус управления, который изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало активности, а нижняя сторона ее конец. Естественно, фокус управления должен целиком находиться на линии жизни объекта. Периоды активности объекта могут чередоваться периодами ожидания. На рис. 2.22. Объект1 и Объект2 имеют постоянный фокус управления, у :Класс2 периоды активности чередуются; потом объект :Класс2 будет уничтожен. Даже если потом объект этого класса будет вновь создан – то это  будут уже новый объект.

Сообщение показаны на диаграмме горизонтальными линиями. Имеются следующие стереотипы сообщений:

∙        Call (вызвать) – сообщение, требующее вызова метода  класса-адресата. Это сообщение может быть рефлексивным, тогда оно требует вызова метода в классе-отправителе.

∙        Return (возвратить) – возвращает результат выполнения сообщения вызвать.

∙        Create (создать) – сообщение, требующее создание другого объекта.

∙        Destroy (уничтожить) – сообщение с требованием уничтожения объекта-адресата.

Рядом с сообщением может быть дано его имя. За именем в скобках могут быть параметры сообщения, при необходимости. В качестве имени сообщения можно использовать только имена методов класса – адресата. Если не создан класс для объекта – адресата или в этом классе нет методов, то дать имена сообщениям невозможно.

Упрощенная диаграмма последовательности процесса продажи товара показана на рис. 2.23. Процесс продажи состоит из следующих действий:

∙        Уточнение и обсуждение с покупателем характеристик товара и выбор подходящего изделия.

∙        Подтверждение наличия товара на складе.

∙        Продажа товара.

 

2) Диаграмма кооперации.

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

На этой диаграмме показаны три объекта, принадлежность к классу одного из них (Объект2) не установлена. Наличие сплошной линии между объектами показывает, что между ними могут передаваться сообщения. Сами сообщения показаны рядом с линиями. Цифры у сообщений показывают очередность их возникновения. Рядом с сообщениями может быть указан метод класса адресата. На основе диаграммы последовательности кооперативная диаграмма может быть создана автоматически. На рис. 2.25. приведена кооперативная диаграмма, соответствующая приведенной на рис. 2.23. диаграмме последовательностей.

Рис. 2.23.

Рис. 2.24.

Рис. 2.25.



37.  Диаграмма классов, характеристики класса

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

Диаграмма классов служит для представления статической структуры модели системы в терминологии объектно-ориентированного программирования. Диаграмма классов может отражать структуру отдельных классов и их взаимосвязи. Диаграмма классов состоит из классов и отношений между ними. При большой сложности и/или объеме на диаграмме классов можно использовать пакеты. Их внешний вид, назначение и отношения между ними совпадают с описанными в п. 2.2. Обозначение  класса на языке UML показано на рис. 2.7. 

 

Рис. 2.7.

 

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

Атрибуты (или свойства) класса задают набор его характеристик. На первом этапе моделирования можно ограничиться лишь определением состава атрибутов, но кроме этого на языке UML имеются возможности кроме названий атрибутов определить видимость, тип данных, кратность, начальное значение. Приведенные перед именами атрибутов символы обозначают видимость. Мы вернемся к этому позже.

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

Классы могут быть отнесены к определенному стереотипу. Стереотип позволяет задать назначение класса. Часть стереотипов определена на UML, но пользователь может расширить их состав. Примеры наиболее существенных стереотипов и их обозначения приведены на рис. 2.8.

 

Рис. 2.8.

 

Стереотип Действующее лицо (Actor) нам уже знаком. Стереотип Граничный класс (Boundary)  используется для задания взаимодействия разрабатываемого программного продукта с внешней средой. Поэтому каждому действующему лицу должен соответствовать граничный класс. Стереотип Сущность (Entity) используется для классов, предназначенных  для создания баз данных (т.е. для длительного хранения данных). Сущность Управление (Control) предназначена для управления работой функционирования программным продуктом.   Все стереотипы классов имеют одинаковую структуру, рассмотренную нами выше: название, атрибуты, операции.

 

В качестве примера рассмотрим часть диаграммы классов для магазина (рис. 2.15).

Рис. 2.15.

 

Составление диаграммы классов занимает центральное место в объектно-ориентированном анализе и проектировании. От правильного выбора классов и отношений между ними в большой степени зависит успех выполнения проекта в целом. При наличии классов – сущностей возникает вопрос об обновлении условно-постоянных данных. В нашем случае данные о количестве товара можно изменять при их поступлении или отпуске; но номенклатуру данных и их характеристики необходимо время от времени изменять. 



38.  Диаграмма классов, типы и характеристики отношений. (+можно почитать еще 37 билет)

Между  классами имеются следующие отношения:

∙        Обобщения (generalization),

∙        Ассоциации (association),

∙        Зависимости (dependency),

∙        Реализации (realization).

Отношение обобщения (рис. 2.9.) связывает класс, соответствующий более общему понятию (предок) с менее общими понятиями - классами (потомками).

Рис. 2.9.

 

Отношение ассоциации (ассоциативное отношение, рис. 2.10.) показывает наличие содержательной связи между двумя классами.

 

Рис. 2.10.

 

На этом рисунке:

Учеба – имя отношения, необязательно.

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

1,  1..*    Мощность отношения, ее желательно задать. В нашем случае имеем отношение «один ко многим»: в вузе учится много студентов, но каждый студент учится только в одном вузе. Кроме этого существуют мощности «один к одному» и «многие ко многим». Вместо 1..* можно задать и более конкретные значения. Например, 1.. 4 соответствую от 1 до 4 объектов класса;   0..3 условное отношение от нуля до 3.

Имеется разновидность отношения ассоциации – отношение агрегации. Оно показывает, что один класс содержит в своем составе другие классы. Пример отношения агрегации приведен на рис. 2. 11.(дата состоит из дня, месяца, года). Характеристики этого отношения совпадают с характеристиками отношения ассоциации. Различают агрегацию по ссылке и по значению (именуемое иногда отношением композиции). Отношение композиции (рис.2.12.) предполагает, что составные части не имеют смысла бес своего владельца.

 

 

Рис. 2.11.

 

Рис.2.12.

 

Отношение зависимости определяет, что изменение одного класса может повлиять на другой класс, который его использует, причем обратное  в общем случае неверно.  Это отношение необходимо указать, если один класс (клиент) использует другой (сервер). Зависимость показана на рис.2.13; изменения в Класс_В (сервер) могут повлиять на Класс_А (клиент).

Рис. 2.13.

Отношение реализации (рис. 2.14.) задается между классами, один из которых описывает действия, а другой гарантирует их выполнение. Чаще всего реализации используют для определения отношений между интерфейсом и классом, который предоставляет объявленные в интерфейсе операции или услуги. Интерфейс позволяет отделить спецификацию (сам интерфейс) от реализации. В нашем случае Класс_С реализует интерфейс Класс_D.

                                     

Рис. 2.14.



39.  Диаграммы состояний, их назначение, компоненты.

Объекты многих классов могут находиться в разных состояниях. Будем говорить о состояниях классов, подразумевая при этом, что все объекты этого класса будут находиться в одинаковых состояниях. Переход объектов класса из одного состояния в другое задает характерные черты их поведения. Исследование состояний проводим, исходя из следующих предпосылок:

∙        Объект может в любой момент времени находиться только в одном состоянии.

∙        Переход из одного состояния в другое происходит скачкообразно; имеются четкие критерии, позволяющие  отличить одно состояние от другого (т.е. при изменении состояния должно измениться значение хотя бы одной переменной класса).

∙        Допустимы не все переходы между состояниями: часть переходов противоречит законам природы, часть - правилам эксплуатации.

∙        Существуют события (events), заставляющие выполнить переход из одного состояния в другое.

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

∙        Объекты класса создаются и уничтожаются (активизируются и деактивируются) в ходе работы.

∙        Объекты мигрируют от одного класса к другому (в пределах одного класса-предка).

∙        Объекты накапливают значения своих атрибутов постепенно, на протяжении жизненного цикла.

∙        Объект отчетливо проходит через разные стадии цикла.

∙        Объект возникает или производится поэтапно.

∙        Объект вступает в связи и выходит из них.

∙        Если объект - это оборудование, нормальное функционирование или сбой которого оказывает влияние на другие объекты.

         Если нет ни одного из перечисленных случаев, то можно обойтись и без этой диаграммы.   Все переходы между состояниями (события) оформляются приказами. На диаграмме используют обозначения, приведенные на рис. 2.16. На рис. 2.17. представлена упрощенная диаграмма состояний процесса обучения студента в вузе.

Рис. 2.16.

Рис. 2.17.

 

На диаграмме состояний могут быть даны дополнительные характеристики состояний и событий (рис. 2.18).

Рис. 2.18.

Для событий можно указывать следующие дополнительные характеристики:

∙        Имя события.

∙        Аргументы события (при необходимости).

∙        Условие, которое должно выполняться при возникновении данного события.

∙        Дополнительные действия, возникающие вместе с этим событием.

Для состояний:

∙        Имя состояния.

∙        Действия, которые должны быть выполнены в момент входа в состояние.

∙        Действия, которые должны  выполняться во время нахождения объекта в данном состоянии.

∙        Действия, которые должны быть выполнены в момент выхода из состояния.

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

Все действия, как в состоянии, так и при событии задаются в следующей форме:

^имя_класса.имя_события(аргументы_события)

 

Состояние может иметь и подсостояния. Например, диаграмма состояний коробки передач автомобиля (рис. 2.19).

Рис. 2.19.



40.  Диаграммы деятельности, их назначение, компоненты.

Для моделирования исследуемой предметной области часто необходимо представить  особенности алгоритмической и логической реализации выполняемых системой операций. Например, для реализации с помощью создаваемого программного продукта отдельных вариантов использования необходимо выяснить и документировать порядок их выполнения людьми. При составлении диаграммы деятельности используют следующее символы (рис. 2.20).

Линия синхронизации 1 означает, что после начала процесса проверка условия и деятельность 5 могут выполняться одновременно. В зависимости от условия 1 выполняется либо деятельность 1 либо деятельность 2; деятельность 3 может начинать выполняться после их завершения.  Линия синхронизации 2 означает, что деятельность 4 может выполняться после завершения деятельности 3 и деятельности 5.

В более сложных условиях на диаграмме деятельности модно использовать дорожки, которые связывают отдельные деятельности с конкретными исполнителями (подразделениями). На рис. 2.21. приведена диаграмма деятельности для магазина. Выделены 3 дорожки (продавец, кладовщик, выдача), соответствующие трем подразделениям магазина и показаны деятельности по обслуживанию покупателя.

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

Рис. 2.20.



41.  Диаграммы компонентов и размещения, их назначение, составные части.

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

Диаграмма компонентов описывает особенности физического представления создаваемой системы. Поэтому до составления диаграммы компонентов должна быть выбрана среда реализации и на эту диаграмму могут быть занесены только такие компоненты, которые имеются в выбранной среде. Примерами компонентов могут служить exe-модуль, dll-библиотека. На рис. 2.26 показана диаграмма компонентов с exe-модулями и базой данных. Все классы, которые должны быть реализованы программно, должны быть присоединены к компонентам. Другими словами, компоненты состоят из классов.

Рис. 2.26.

В наше время редко когда разрабатывается приложение, функционирующее на одном компьютере. Поэтому возникает необходимость показать, какие компоненты на каких компьютерах работают и как эти компьютеры связаны. Для этого служит диаграмма развертывания (размещения), представленная на рис. 2.27.

Рис.2.27.

На диаграмме имеется две разновидности узлов:

∙        Процессоры, в которых выполняется обработка информации.

∙        Устройства, в которых обработка информации не выполняется, которые лишь предоставляют услуги (например, сетевой принтер).

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

 


Случайные файлы

Файл
28389-1.RTF
97106.rtf
71816-1.rtf
26318.rtf
150683.rtf




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