Анализ, проектирование и разработка
Варианты использования определяют систему
Существует система
Актанты — это среда, в которой
Актанты — это не обязательно люди. Актантами могут быть другие системы или
внешнее оборудование компьютера, взаимодействующее с системой. Каждый актант,
взаимодействуя с системой, исполняет согласованный набор ролей. Физический
пользователь может играть роль одного или нескольких актантов, выполняя
их функции по взаимодействию с системой. Поведение одного и того же актанта
может наблюдаться у нескольких физических пользователей. Например,
поведение актанта Клиент банка может быть присуще тысячам людей.
Актанты в ходе выполнения вариантов использования обмениваются информацией
с системой, посылая ей сообщения(приложение А) и получая ответные
сообщения. Определяя, что делают актанты, а что — варианты использования, мы
получаем четкое разграничение обязанностей между актантами и системой. Это
разграничение помогает нам лучше определить сферу деятельности системы.
Мы можем найти и определить всех актантов, рассматривая, как будут работать
с системой ее пользователи и какие внешние системы должны взаимодействовать
с нашей системой. Каждая категория пользователей или внешних систем, взаимодействующих
с нашей, будет представлена одним актантом.
Варианты использования создаются для того, чтобы пользователи, работая с системой,
могли удовлетворить свои потребности. Модель вариантов использования
определяет все функциональные требования системы. Мы даем следующее определение
варианта использования:
Вариант использованияопределяет последовательность действий (включая ее
варианты), которые может выполнить система, приносящих ощутимый и измеримый
результат, значимый для некоторого актанта.
Мы ищем варианты использования, рассматривая, как пользователи хотят использовать
систему для выполнения своей работы (способ структурирования вариантов
использования на основе целей см. в [15]). Каждый метод использования
системы, приносящий пользователю ощутимый результат — кандидат в варианты
использования. Эти кандидаты в дальнейшем превратятся в настоящие варианты
использования, будут разбиты на более частные варианты использования или включены
в глобальные варианты использования. Когда модель варианта использования
определяет все функциональные требования правильно и таким образом, что
их понимают клиенты, пользователи и разработчики, ее можно считать практи-__
чески законченной. Последовательность действий, происходящих при выполнении
варианта использования (то есть экземпляр варианта использования) — это
определенный путь осуществления варианта использования. Возможно множество
путей осуществления варианта использования, и многие из них очень похожи —
ведь все они являются вариантами выполнения последовательности действий,
описанных в варианте использования. Чтобы сделать модель вариантов использования
понятной, мы должны собрать описания похожих вариантов выполнения
в один вариант использования. Когда мы говорим, что идентифицируем и описываем
вариант использования, мы на самом деле подразумеваем, что мы идентифицируем
и описываем различные варианты выполнения, которые считаем полезным
рассматривать как один вариант использования.
Пример.Вариант использования Снять деньги со счета. Последовательность
действий пути осуществления варианта использования (очень упрощенно).
1. Кассир банка идентифицирует клиента.
2. Кассир банка выбирает счет, с которого будут сняты деньги, и определяет снимаемую
сумму.
3. Система снимает соответствующую сумму со счета и выдает деньги.
Варианты использования также используются для хранения нефункциональных
требований (приложение В; см. главу 6), определенных для этого варианта использования,
таких как производительность, точность и безопасность. Например,
к варианту использования Снять деньги со счета может быть приложено следующее
требование: время отклика для Клиента банка, измеряемое от ввода снимаемой
суммы до выдачи купюр, не должно превышать 30 секунд в 95% всех операций.
Подведем итог. К вариантам использования можно привязать все функциональные
требования. К вариантам использования можно приложить многие нефункциональные
требования. Фактически модель вариантов использования — это аппарат
перевода требований в легкоуправляемую форму. Клиенты и пользователи,
понимающие это, могут с помощью вариантов использования сообщать о своих потребностях
разработчикам последовательным и лишенным избыточности способом.
Разработчики могут разделить между собой работу по определению требований
и использовать ее результаты (прежде всего варианты использования) в качестве
исходных данных для анализа, проектирования, реализации и тестирования
системы.
при реализации варианта использования
В ходе анализа и проектирования мы преобразуем модель вариантов использования
через модель анализа в модель проектирования, то есть в структуру, состоящую
из классификаторов и реализаций вариантов использования. Цель состоит в том,
чтобы реализовать варианты использования так, чтобы система имела в результате
устраивающую нас эффективность и перспективы развития, не выходя при этом
за рамки бюджета.
В этом пункте мы рассмотрим, как пройти через анализ к разработке проекта
реализации вариантов использования. В главах 4 и 5 мы увидим, как опора на архитектуру
и итеративная и инкрементная разработка помогают нам разрабатывать
систему, которая может пополняться новыми требованиями, укладываясь при этом
в рамки бюджетных ограничений.
Создание по вариантам использования