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