В начале 1990-х гг. Ивар Джейкобсон (Ivar Jacobson) и другие^ распространили идею применять прецеденты для изучения функциональных требований к системе. Позднее нотация прецедентов была включена в язык UML. Эта простая на вид концепция оказалась крайне полезной, особенно для изучения функциональных требований к большим и сложным системам.
В контексте данной книги прецеденты имеют большое значение, так как процесс разработки RUP в значительной степени управляется ими. Прецеденты не только используются для выражения требований, но и создают основу для последующих действий, от анализа до тестирования.
Моделирование прецедентов включает две фундаментальные концепции.
· Исполнитель (actor). Исполнитель представляет что-то (или кого-то) за пределами системы, обычно пользователя системы. Исполнители взаимодействуют с системой, что приводит к выполнению системой некоторого действия. Каждая отдельная роль представляется отдельным исполнителем.
· Прецедент(use case). Прецедент заключает в себе последовательность шагов, выполняемых системой по поручению исполнителя. Прецеденты дают исполнителю что-либо ценное. Прецедент состоит из основной последовательности событий и может иметь одну или несколько дополнительных последовательностей.
Требования подразделяются на две основных категории: функциональные и нефункциональные. Функциональные требования, которые описывают, что должна уметь делать система, можно легко смоделировать с помощью прецедентов. Нефункциональные требования касаются таких вопросов, как удобство применения и производительность, и для них труднее применить моделирование прецедентов.
Попробуем применить моделирование прецедента на практике, использовав для этого практическое исследование системы HomeDirect (требования к ней подробно описаны в главе 16).
Для лучшего понимания остальной части главы рекомендуется вначале прочесть раздел "Требования к HomeDirect" в главе 16.
В первую очередь мы займемся функциональными требованиями, из которых надо вывести прецеденты.
Идентификация исполнителей
Исполнителей обычно проще идентифицировать, чем прецеденты. Однако и здесь имеются две трудности. Во-первых, легко впасть в ошибку назначения нескольких исполнителей для одной и той же роли. Во вторых, исполнители могут быть неявными, т.е. они могут не идентифицироваться как пользователи системы, поэтому необходимо учитывать не только очевидные связи.
Во время чтения описания или сбора требований для проекта задавайте себе несколько вопросов: кто будет использовать эти функциональные возможности? Кто предоставляет или получает информацию? Кто может изменить информацию? Есть ли какие-то другие системы, которые взаимодействуют с разрабатываемой системой?
При исследовании системы HomeDirect можно выявить следующие роли: клиент, пользователь, администратор, владелец счета, служащий банка, продавец, служба HomeDirect, система, система Mail, система LoansDirect, служба BillsDirect и ACMEBank.
Основываясь на требованиях и на нашем обычном представлении о работе электронных банковских систем, легко определить, что клиент, пользователь и владелец счета почти наверняка означают одну и ту же роль. Таким образом, мы можем удалить из списка лишние "роли" пользователя и владельца счета. Роль продавца напоминает роль клиента, но имеет более широкое содержание, так как продавец, в отличие от клиента, может получать платежи. Аналогично, роли служащего банка и администратора, хотя и могут относиться к разным людям в банке (т.е. служащий банка не обязательно должен быть администратором HomeDirect), почти совершенно совпадают.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.