Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

Е-3: нет подходящих авиарейсов. Покупатель информируется, что в данное время такой полет невозможен. Возврат к началу элемента Use Case.

Е-4: не может быть создана связь между покупателем и авиарейсом. Информация сохраняется, система создаст эту связь позже. Элемент Use Case продолжается.

Е-5: введен неправильный номер заказа. Покупатель может повторить ввод правильного номера заказа или прекратить элемент Use Case.

Е-6: не может быть удалена связь между покупателем и авиарейсом. Информация сохраняется, система будет удалять эту связь позже. Элемент Use Case продолжается.

Е-7: система не может вывести информацию заказа. Возврат к началу элемента Use Case.

Е-8: некорректные параметры кредитной карты. Покупатель может повторить ввод параметров карты или прекратить элемент Use Case.

http://www.ibm.com/developerworks/ru/edu/r-hellorsav7/authors.html - author1Таким образом, в данной спецификации зафиксировано, что внутри элемента Use Case находится один основной поток и двенадцать вспомогательных потоков действий. В дальнейшем разработчик может принять решение о выделении из этого элемента Use Case самостоятельных элементов Use Case. Очевидно, что если самостоятельный элемент Use Case содержит подпоток, то его следует подключать к базовому элементу Use Case отношением include. В свою очередь, самостоятельный элемент Use Case с альтернативным потоком подключается к базовому элементу Use Case отношением extend.

Диаграммы деятельности

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

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

Рис. 12.13. Состояние действия

Состояние действия считается атомарным (действие нельзя прервать) и выполняется за один квант времени, его нельзя подвергнуть декомпозиции. Если нужно представить сложное действие, которое можно подвергнуть дальнейшей декомпозиции (разбить на ряд более простых действий), то используют состояние под-деятельности. Изображение состояния под-деятельности содержит пиктограмму в правом нижнем углу (рис. 12.14).

Рис. 12.14. Состояние под-деятельности

Фактически в данную вершину вписывается имя другой диаграммы, имеющей внутреннюю структуру.

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

Кроме того, в диаграммах деятельности используются вспомогательные вершины:

• решение (ромбик с одной входящей и несколькими исходящими стрелками);

• объединение (ромбик с несколькими входящими и одной исходящей стрелкой);

• линейка синхронизации — разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками);

• линейка синхронизации — слияние (жирная горизонтальная линия с несколькими входящими и одной исходящей стрелкой);

• начальное состояние (черный кружок);

• конечное состояние (незакрашенный кружок, в котором размещен черный кружок меньшего размера).

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

Вершина «объединение» отмечает точку слияния альтернативных потоков действий.

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

Пример диаграммы деятельности приведен на рис. 12.15. Эта диаграмма описывает деятельность покупателя в Интернет-магазине. Здесь представлены две точки ветвления — для выбора способа поиска товара и для принятия решения о покупке. Присутствуют три линейки синхронизации: верхняя отражает разделение на два параллельных процесса, средняя отражает и разделение, и слияние процессов, а нижняя — только слияние процессов.

Рис. 12.15. Диаграмма деятельности покупателя в Интернет-магазине

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

Создание диаграмм в среде Rational Software Architect

(По материалам Тинни Нг (Tinny Ng) - IBM Toronto)

Создание UML-проекта

После запуска Rational Software Architect создайте UML-проект с именем MyPhoneBookUMLProject. Для этого выполните следующие действия:

• В меню приложения выберите File > New > Project;

• Выберите UML Project и нажмите кнопку Next;

• Введите MyPhoneBookUMLProject в качестве имени проекта и нажмите кнопку Next;

• Введите Phone Book UML Model в качестве имени UML-модели и снимите флажок Create a default diagram in the new model, затем нажмите кнопку Finish;.

• Нажмите Yes в ответ на запрос открытия перспективы Modeling.

Создание диаграммы прецедентов

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

Действующее лицо - актер

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

Прецедент

Описывает функцию, которую выполняет система для достижения цели пользователя. Прецедент должен возвращать видимый результат, имеющий значение для пользователя системы.

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

Для простого приложения телефонной книги имеется только одно действующее лицо, Any User, которое может выполнять следующие два прецедента относительно системы:

1. Добавление записи

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

2. Поиск номера телефона

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

Для создания диаграммы двух прецедентов для простого приложения телефонной книги выполните следующие действия.

1. В Rational Software Architect панели Model Explorer нажмите правой кнопкой мыши Phone Book UML Model и выберите Add Diagram > Use case diagram, как это показано на рисунке:
   
   Рисунок 4. Добавление диаграммы прецедентов

2. Введите use case diagram в качестве имени сгенерированной диаграммы, заменив имя по умолчанию UsecaseDiagram1. Теперь можно построить диаграмму прецедентов с помощью добавления с панели Palette на диаграмму различных элементов моделей:
   
   Рисунок 5. Добавление элементов моделей

3. Выберите Actor в панели Palette, затем нажмите кнопку мыши в области диаграммы для создания действующего лица. Назовите его Any User;

4. Выберите Use Case в панели Palette, затем нажмите кнопку мыши в области диаграммы для создания прецедента. Назовите его Add an entry;

5. Таким же образом создайте другой прецедент и назовите его Search for a phone number;

6. Выберите Association в панели Palette. Нарисуйте линию отношения сопоставления от действующего лица Any User к прецеденту Add an entry для инициирования отношения между двумя элементами модели;

7. Назовите отношение use case 1;

8. Таким же образом создайте другое отношение сопоставления между действующим лицом Any User и прецедентом Search for a phone number и назовите его use case 2;

9. Полностью диаграмма прецедентов должна выглядеть так, как показано на рисунке 6. Нажмите Ctrl-S для сохранения диаграммы.
   
   Рисунок 6. Завершенная диаграмма прецедентов

Пример диаграммы прецедентов

Пример диаграммы деятельности для прецедента Просмотреть каталог

Задание

• Создать в среде Software Architect новый проект типа UML Model (из шаблона).

• На основе описания требований к СОИУ составить диаграмму(ы) прецедентов системы. Диаграмма прецедентов должна содержать:

• актеров,

• прецеденты системы,

• ассоциативные связи между актерами и прецедентами.

• Составить для основных прецедентов их описания (предусловия, поток событий, постусловие).

• Составить для основных прецедентов диаграммы деятельности (на основе описания).

• Уточнить диаграмму прецедентов, добавив

• связи типа <<include>> для указания подключаемых прецедентов,

• связи типа <<еxtend>> для указания расширяющих прецедентов и точки расширения в расширяемом прецеденте.

Дополнительные элементы и стереотипы студенты могут использовать по своему усмотрению.

• Добавить к проекту модель предметной области. Составить в ней модель классов предметной области.

• На основе описаний прецедентов и модели предметной области составить прототип пользовательского интерфейса (эскиз).

Отчет:

После выполнения работы составляется отчет, который содержит:

• титульный лист,

• описание исходных требований (функциональных и нефункциональных),

• диаграмму(ы) прецедентов,

• спецификации прецедентов,

• диаграмму(ы) активности,

• диаграмму классов предметной области,

• прототип пользовательского интерфейса.

Контрольные вопросы

1. Правила выбора актеров.

2. Правила выбора прецедентов.

3. Как создать модель в среде IBM Software Architect ?

4. Как добавить в модель диаграмму?

5. Как добавить в модель актера?

6. Как добавить в модель прецедент?

7. Как связаны актеры и прецеденты?

8. Типы связей между прецедентами?

9. Правила составления спецификации прецедента?

Литература

• Орлов С.А., Цилькер Б.Я. Технологии разработки программного обеспечения. - СПб.: Питер. - 2012 г.

• Якобсон А, Дуч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения. - Спб.: Питер. - 2002 г.

• http://www.ibm.com/developerworks/ru/edu/r-hellorsav7/section7.htmlМатериалы сайта http://www.ibm.com

13

Характеристики

Список файлов лабораторной работы