
- •Содержание
- •Лекция 1. Введение. Группа проекта. Жизненный цикл. Предварительные замечания Предварительные замечания
- •Группа проекта
- •Жизненный цикл Предварительные замечания
- •Последовательный тип
- •Эволюционный тип
- •Выбор типа жизненного цикла
- •Лекция 2. Архитектура программных систем Предварительные замечания
- •Структурные сущности
- •Архитектурные виды
- •Лекция 3. Рациональный унифицированный процесс Предварительные замечания
- •Характеристики процесса
- •Фазы, итерации и циклы разработки
- •Рабочие процессы
- •Артефакты
- •Другие артефакты
- •Лекция 4. Анализ и проектирование. Стадия анализа Предварительные замечания
- •Стадия анализа Стандарты семейства idef
- •Анализ на базе семейства idef
- •Объектно-ориентированный анализ и проектирование
- •Лекция 5. Модель анализа прецедентов Предварительные замечания
- •Поток событий, сценарий, кооперация
- •Организация прецедентов
- •Лекция 6. Типичные приемы анализа прецедентов Поведение элемента
- •Диаграмма прецедентов
- •Моделирование контекста системы
- •Моделирование требований к системе
- •Лекция 7. Введение в унифицированный процесс моделирования Предварительные замечания
- •Сущности uml
- •Отношения uml
- •Диаграммы uml
- •Правила языка uml
- •Общие механизмы языка uml
- •Лекция 8. Системы и модели Предварительные замечания
- •Системы и подсистемы. Модели и представления
- •Моделирование системной архитектуры
- •Различные представления системы
- •Лекция 9. Информационные технологии и средства анализа и проектирования информационных систем Предварительные итоги
- •Компонентная архитектура
- •Краткий перечень производителей и программных продуктов
- •Сравнительный обзор возможностей Rational Rose и paradigm plus
- •Поддерживаемая нотация
- •Методологии
- •Компонентно-базируемое проектирование
- •Ведение репозитария объектов
- •Построение диаграмм моделей. Пользовательский интерфейс
- •Генерирование программного кода
- •Наличие реинжиниринга
- •Проектирование баз данных. Поддержка sql и мостов для реляционных баз данных, idl для corba
- •Создание экранного интерфейса
- •Возможность групповой работы
- •Наличие Script-языка
- •Генерирование отчетов и формирование проектной документации
- •Поддерживаемые платформы
- •Место в общем цикле разработки программной системы
Диаграмма прецедентов
Диаграммы прецедентов представляют собой один из пяти типов диаграмм, применяемых в UML для моделирования динамических аспектов системы (остальные четыре типа - это диаграммы деятельности, состояний, последовательностей и кооперации). Диаграммы прецедентов играют основную роль в моделировании поведения системы, подсистемы или класса. Каждая из таких диаграмм показывает множество прецедентов, актеров и отношения между ними.
Диаграммы прецедентов применяются для моделирования вида системы с точки зрения прецедентов (вариантов использования). Чаще всего это предполагает моделирование контекста системы, подсистемы или класса либо моделирование требований, предъявляемых к поведению указанных элементов.
Диаграммы прецедентов имеют большое значение для визуализации, специфицирования и документирования поведения элемента. Они облегчают понимание систем, подсистем или классов, представляя взгляд извне на то, как данные элементы могут быть использованы в соответствующем контексте. Кроме того, такие диаграммы важны для тестирования исполняемых систем в процессе прямого проектирования и понимания их внутреннего устройства при обратном проектировании.
Диаграммой прецедентов (use case diagram), называется диаграмма, на которой показана совокупность прецедентов и актеров, а также отношения между ними. Диаграммы прецедентов обладают стандартными свойствами, присущими любой диаграмме, именем и графическим содержанием, которое представляет собой одну из проекций модели. Диаграмма прецедентов отличается от прочих своим конкретным содержанием. Диаграммы прецедентов обычно включают в себя:
прецеденты,
актеров,
отношения зависимости, обобщения и ассоциации,
как и все остальные диаграммы, они могут содержать примечания и ограничения.
Иногда диаграммы прецедентов помещают в пакеты, применяемые для группирования элементов модели в более крупные блоки, в ряде случаев и экземпляры прецедентов, особенно если надо визуализировать конкретную исполняемую систему.
Диаграммы прецедентов, или вариантов использования, применяют для моделирования статического вида системы с точки зрения прецедентов. Это вид охватывает главным образом поведение системы, то есть видимые извне сервисы, предоставляемые системой в контексте ее окружения. При моделировании статического вида системы с точки зрения прецедентов диаграммы использования обычно применяют двумя способами: для моделирования контекста системы и для моделирования требований.
Моделирование контекста системы
Моделирование контекста системы подразумевает, что мы обводим систему воображаемой линией и выявляем актеров, которые находятся за этой линией и взаимодействуют с системой. Диаграммы прецедентов нужны на этом этапе для идентификации актеров и семантики их ролей.
Любая система содержит внутри себя какие-либо сущности, в то время как другие сущности остаются за ее пределами. Сущности внутри системы отвечают за реализацию поведения, которого ожидают сущности находящиеся снаружи. Сущности. Находящиеся вне системы и взаимодействующие с ней, составляют ее контекст. Таким образом, контекстом называется окружение системы.
UML позволяет моделировать контекст с помощью диаграмм прецедентов, в которых внимание акцентируется на окружающих систему актерах. Важно правильно определить актеров, так как это позволяет описать класс сущностей взаимодействующих с системой. Еще важнее определить, что не является актером, так как при этом ограничивается окружение системы: в нем остаются только те элементы, которые участвуют в ее работе.
Моделирование контекста системы состоит из следующих шагов:
Идентифицируйте окружающих систему актеров. Для этого необходимо найти группы, которым участие системы требуется для выполнения их задач; группы, которые необходимы для осуществления системой своих функций; группы, взаимодействующие с ее внешними программными и аппаратными средствами, а также группы, выполняющие вспомогательные функции администрирования и поддержки.
Организуйте похожих актеров с помощью отношений обобщения/специализации.
Введите стереотипы для каждого актера, если это облегчает понимание.
Поместите актеров на диаграмму прецедентов и определите способы их связи с прецедентами системы.
Тот же метод позволят моделировать и контекст подсистемы. Вспомните, что элемент. Который на одном уровне абстракции выглядит как система, часто становится подсистемой на другом, более высоком уровне абстракции. Моделирование контекста подсистемы может пригодиться при построении системы из нескольких взаимосвязанных частей.