Проектирование архитектур информационных систем. Беляев К.С. - 41 стр.

UptoLike

Составители: 

41
контролируемую форму расширения поведения прецедента с помощью
активизации другого прецедента в определенных точках расширения.
Отношение <<include>> отличается от отношения <<extend>> в том, что
«включаемый» прецедент является необходимым для завершения
«активизирующего» прецедента.
На практике проект может легко столкнуться с проблемами, если
прилагать слишком большие усилия для выявления отношений между
прецедентами и установления, какие отношения применимы к
определенной паре прецедентов. Кроме того, обобщенные прецеденты
имеют тенденцию к таким тесным связям, что взаимосвязи станут
превалировать и загромождать диаграмму, смещая акценты с надлежащей
идентификации прецедентов в сторону отношений между прецедентами.
2.1.20Примерспецификациипрецедентов
Обращаясь к постановке задачи для системы «Запись на
университетские курсы» на стр.23-24, а также к требованиям,
определенным на стр. 26-27 и стр. 29-30 установим прецеденты на основе
анализа функциональных требований.
На рис. 5 показана обобщенная диаграмма прецедентов для
приложения «Запись на университетские курсы». Модель содержит
четыре субъекта и четыре прецедента. Каждый прецедент инициируется
субъектом
и является завершенным, внешне видимым и ортогональным
фрагментом функциональных возможностей. Все субъекты, за
исключением субъекта Student, представляют собой инициирующих
субъектов. Субъект Student получает результаты экзаменов и инструкции
по записи на учебные курсы перед тем, как программа обучения в
следующем семестре (учебном периоде) может быть введена и проверена.
Прецедент Provide Examination Results (Предоставить результаты
экзаменов) может «
расширить» (<<extend>>) прецедент Provide Enrolment
Instructions (Предоставить инструкции по записи). Первый прецедент не