Лекци 6 - Кафедра анализа данных и исследования операций

Пример банковской системы. Описание задачи.
Банк владеет несколькими банкоматами, которые находятся в разных местах и
соединены глобальной сетью с центральным сервером. В каждом банкомате есть устройство
считывания карточек, устройство выдачи наличных, клавиатура с дисплеем и устройство
печати чеков.
Банкомат позволяет клиенту снять деньги с чекового или сберегательного счета, получить
справку о балансе счета, а также перевести деньги с одного счета на другой. Клиент инициирует
транзакцию, когда вставляет карточку в устройство считывания. На магнитной полосе па обратной
стороне карточке помещены закодированный номер карточки, дата начала и дата окончания
действия. Если система опознает карточку; то она проверяет, не истек ли срок действия, совпадает
ли введенный клиентом ПИН-код с тем, что хранится в системе, и не числится ли данная карточка
утерянной или украденной. Клиенту даются три попытки для ввода правильного ПИН-кода,
после третьей ошибки карточка конфискуется. Также конфискуются утерянные и украденные
карточки.
Если ПИН-код напечатан правильно, система предлагает клиенту выбрать одну из трех
операций: снятие денег, получение справки или перевод. Прежде чем выдать наличные, система
проверяет, что на указанном счету достаточно денег, что не превышен суточный лимит и что в
банкомате есть требуемая сумма. Если транзакция одобрена, то выдается запрошенная сумма,
печатается чек, а карточка возвращается клиенту. До начала транзакции перевода денег система
проверяет, что у клиента есть хотя бы два счета и что на дебетуемом счете достаточно денег. Для
одобренных транзакций получения справки и перевода денег печатается чек и карточка
возвращается. Клиент может в любой момент отменить транзакцию, после чего карточка
возвращается сразу. Записи о клиентах, счетах и карточках хранятся на сервере.
Оператор вправе остановить банкомат для пополнения запаса наличных и для
профилактического обслуживания, а затем снова запустить его. Предполагается, что средства для
открытия и закрытия счетов, а также для создания, обновления и удаления записей о клиентах и
дебетования счетов уже реализованы в существующей системе и к рассматриваемой задаче не имеют
отношения.
Модель жизненного цикла разработки объектно-ориентированных программных систем – это
итеративный процесс разработки на основе концепции прецедентов (вариантов использования).
Каждый прецедент описывает последовательность взаимодействий между несколькими
действующими лицами. Прецедент можно анализировать на нескольких уровнях детализации. В
модели требований задаются функциональные требования к системе в терминах действующих лиц и
прецедентов. В аналитической модели прецедент уточняется с помощью характеристик
участвующих объектов и взаимодействий между ними. В проектной модели создается архитектура
системы, здесь рассматриваются вопросы распределенности, параллелизма и сокрытия информации.
 Анализа предметной области и формулировки функциональных требований к
программе
Данный этап включает подэтапы: анализ предметной области, установления
функциональных требований и их спецификация.
Для выявления требований аналитики предметной области различными методами
получения и использования информации.
Функциональные требования к системе (или, как их еще называют, внешние требования)
определяют, что система должна делать для пользователя. При указании внешних требований
систему следует рассматривать как черный ящик, то есть принимать во внимание лишь ее внешние
характеристики.
Описывается подход к заданию функциональных требований с помощью прецедентов,
объясняются понятия актера и прецедента. Здесь также будут рассмотрены отношения между
прецедентами, в частности отношения расширяет (extend) и включает (include). Приводится
несколько примеров.
Прецеденты
При использовании подхода на основе прецедентов функциональные требования задаются в
терминах актеров (actor), в роли которых выступают пользователи системы, и прецедентов (use case).
1
Актер участвует в прецеденте. Прецедент устанавливает последовательность взаимодействий между
одним или несколькими актерами и системой. На этапе определения требований модель прецедентов
описывает систему как черный ящик, а взаимодействие между актерами и системой, то есть действия
пользователя и реакция на них системы, указываются в словесной форме. Прецеденты в данной
модели выражают внешние требования к системе. Каждый прецедент описывает поведение
некоторой части системы, не раскрывая ее внутренней структуры. На следующем этапе
аналитического моделирования определяются объекты, участвующие в каждом прецеденте.
Рассмотрим простой пример из области банковского дела - банкомат, позволяющий клиентам
снимать наличные деньги со своего счета. Имеется один актер -Клиент Банкомата, и один прецедент
- Снять Деньги (рис. 1). Прецедент Снять Деньги описывает последовательность взаимодействий
между клиентом и системой, начиная с момента, когда клиент вставляет карточку в банкомат, и заканчивая выдачей наличных.
РИС.1. Пример актера и прецедента
Актеры
Актер представляет одного или нескольких внешних пользователей, взаимодействуюших с
системой. В модели прецедентов актеры - это единственные внешние сущности,
взаимодействующие с системой.
Есть несколько способов моделирования актеров. Часто в роли актера выступает человек.
Во многих информационных системах нет никаких других актеров, кроме людей. Но актером
бывает и внешняя система. В приложениях реального времени и в распределенных приложениях
актером может стать внешнее устройство ввода/вывода или таймер. Такие актеры чаще всего
встречаются во встраиваемых системах реального времени, где система взаимодействует с внешней
средой посредством датчиков и приводов.
Главный актер (primary actor) инициирует прецедент, то есть некоторые действия в системе.
Другие актеры, называемые второстепенными (secondary actors), также могут участвовать в
прецеденте, получая результаты и генерируя исходные данные. По меньшей мере один актер
(обычно главный) должен иметь какой-то результат от прецедента. Однако в системах реального
времени, когда в роли главного актера выступает внешнее устройство ввода/вывода или таймер,
бенефициарием становится второстепенный актер-человек, получающий от системы ту или иную
информацию.
Актер-человек использует для взаимодействия с системой различные внешние устройства
ввода/вывода: стандартные (клавиатуру, дисплей или мышь) либо нестандартные (скажем,
различные датчики). В любом случае актером является человек, а не эти устройства.
Рассмотрим несколько примеров актеров-людей. В банковской системе актером является,
например, кассир, который взаимодействует с системой посредством стандартной клавиатуры,
дисплея и мыши. Другой пример актера - клиент, общающийся с системой через банкомат. В этом
случае клиент применяет для взаимодействия, помимо клавиатуры и дисплея, и другие устройства
ввода/вывода: устройство считывания карточки, устройство выдачи наличных, устройство для
печати чеков.
Иногда, впрочем, в роли актера выступает устройство. Так бывает, когда люди в прецеденте
не участвуют, что типично для приложений реального времени. Обычно такой актер взаимодействует
с системой посредством датчика. Примером может служить Датчик Прибытия в системе
управления лифтами (рис. 2). Этот Датчик показывает, что лифт приближается к этажу, на
котором следует остановиться. Тем самым он инициирует прецедент Остановка Лифта на
Этаже. Другим актером в системе управления лифтами является пассажир, который общается с
системой с помощью кнопок выбора этажа и управления лифтом. Действия этого актера фиксируют
датчики кнопок.
2
Актером может быть также таймер, который периодически посылает события системе. Когда
система должна выводить некую информацию на регулярной основе, возникает нужда в регулярных
прецедентах. Особенно важно это в системах реального времени, но часто
Рис. 2. Пример устройства ввода в качестве актера
оказывается реального времени, но часто оказывается полезным и в информационных системах.
Некоторые методологи относят таймеры к внутренним элементам систем, но при проектировании
приложения реального времени удобно рассматривать их как логически внешние по отношению к
системе, считая главными актерами, инициирующими действия. Например, в системе круизконтроля таймер инициирует несколько разных прецедентов. Так, в примере на рис. 3 актер Таймер
задает прецедент Вычислить Скорость Движения, в котором периодически рассчитывается
средняя скорость, а полученное значение отображается на дисплее Водителя. В этом случае таймер
- главный актер, а водитель - второстепенный.
Рис. 7.3. Пример таймера в роли актера
Актером может быть также внешняя система, которая либо инициирует прецедент (в качестве
главного актера), либо участвует в нем (в качестве второстепенного). Пример такого рода Заводской Робот в системе автоматизации проиизводства. Он начинает прецедент Поднять
Тревогу и Известить, показанный на рис. 4. Робот генерирует сигнал тревоги, который посылается
операторам, уполномоченным реагировать на этот сигнал. В данном случае Заводской Робот
является главным актером, инициирующим прецедент, а Дежурный Оператор - второстепенным,
принимающим сигналы тревоги.
Рис. 7.4. Пример внешней системы в роли актера
Выявление прецедентов
Прецедент начинается с некоторого действия актера и представляет собой завершенную
последовательность событий, начатую этим действием и описывающую один из вариантов
взаимодействия актера с системой. Простой прецедент может состоять из единственного
взаимодействия, а более сложные содержат несколько взаимодействий. Допустимо также, чтобы в
прецеденте участвовали несколько актеров.
Для выявления прецедентов в системе полезно начать с рассмотрения актеров и
инициируемых ими действий. Каждый прецедент описывает последовательность взаимодействий
между актером и системой. Прецедент должен приводить к получению актером какого-либо
результата.
3
Таким образом, функциональные требования к системе определяются в терминах
прецедентов, составляющих в совокупности внешнюю спецификацию системы. Однако при
исследовании прецедентов важно избегать декомпозиции на несколько мелких прецедентов,
описывающих отдельные функции системы. Нужно описывать последовательность событий,
приносящих актеру определенную пользу.
Вернемся еще раз к банковской системе. Помимо снятия наличных, Клиент Банкомата
может получить справку о счете или перевести деньги с одного счета на другой. Поскольку это
разные функции, дающие клиенту различные результаты, их следует моделировать как разные
прецеденты, а не как части одного более крупного прецедента. Итак, клиент способен инициировать
три прецедента, изображенных на рис. 5: Снять Деньги, Получить Справку и Перевести Деньги.
Главная последовательность прецедента - это наиболее часто встречающаяся в нем
очередность взаимодействий между актером и системой. От главной последовательности могут
отходить ветви, описывающие взаимодействия, которые происходят реже. Такие отклонения от
главной последовательности вероятны
Рис. 5. Актеры и прецеденты в банковской системе
только при определенных условиях - например, если актер вводит в систему некорректные данные. В
зависимости от особенностей приложения альтернативные ветви позже могут снова сливаться с
главной последовательностью. Альтернативные ветви составляют часть описания прецедента.
В прецеденте Снять Деньги главная последовательность - это цепочка шагов, приводящая к
получению наличных. Альтернативные ветви соответствуют различным ошибкам. Например, если
клиент ввел некорректный ПИН-код (ПИН-персональный идентификационный номер), система
должна потребовать повторного ввода. Банкомат может также не опознать карточку, определить, что
она ворованная, и т.д.
Документирование прецедентов в модели прецедентов
Прецеденты документируются в модели следующим образом:

имя прецедента. Каждому прецеденту присваивается имя;

сводка. Краткое описание прецедента, обычно состоящее из одной-двух фраз;

зависимости. Этот раздел необязателен, в нем указывается, зависит ли прецедент от
других прецедентов, и если да, то каков характер зависимости: включение или расширение;

актеры. В данном разделе именуются актеры, участвующие в прецеденте. Всегда
существует главный актер, инициирующий прецедент, Кроме того, могут быть второстепенные
актеры. Например, в прецеденте Снять Деньги актером является Клиент Банкомата;

предусловия. Одно или несколько условий, которые должны быть истинными в начале
прецедента. В нашем примере банкомат должен быть свободен (в таком случае на его экране
отображается сообщение «Добро пожаловать»);

описание. Основная часть документации прецедента - это словесное описание
главной последовательности. Здесь перечисляются действия актера и реакция системы на них.
Система рассматривается как черный ящик: значение имеют ответы системы на действия актера, а не
ее внутреннее устройство;

альтернативы. Словесное описание альтернативных ветвей. От главной
последовательности может отходить несколько таких ветвей. Например, если на счете клиента
недостаточно средств, то следует принести извинения и вернуть карточку;
4

постусловие. Условие, которое должно быть истинным в конце прецедента, если
исполнение шло по главной последовательности. Например, клиенту выданы наличные;

неясные вопросы. Вопросы по поводу прецедента документируются для обсуждения с
пользователями.
Примеры прецедентов
В этом разделе мы приведем примеры прецедентов для банковской системы. На рис. 5
показана первая попытка нарисовать диаграмму для банковской системы. Здесь имеется один актер Клиент Банкомата - и три прецедента, представляющие основные функции, которые инициируются
актером, - Снять Деньги, Получить Справку и Перевести Деньги.
Клиент взаимодействует с системой посредством устройства считывания карточек и
клавиатуры. Актером является именно клиент, а не какие-либо устройства, последние служат лишь
средствами, с помощью которых клиент инициирует прецедент и отвечает на вопросы системы.
Устройства печати чеков и выдачи наличных - это устройства вывода; они не будут актерами,
поскольку именно клиент выполняет функцию бенефициарна прецедента.
Так как существует три вида транзакций, мы начнем с рассмотрения трех прецедентов: Снять
Деньги, Получить Справку и Перевести Деньги - по одному для каждой транзакции. Сначала
разберем прецедент Снять Деньги. В этом случае главная последовательность приводит к успешному
получению наличных клиентом. Сюда входят: считывание карточки, проверка ПИН-кода клиента,
контроль наличия средств на счете и - при условии, что все проверки прошли успешно, -выдача
наличных, печать чека и возврат карточки.
Альтернативные ветви относятся к различным ошибкам, например клиент ввел
неправильный ПИН-код и должен повторить ввод, карточка не опознана или признана украденной, и
т.д. Поскольку описать их несложно, нет смысла отмечать отдельные прецеденты.
Модель прецедентов
Прецеденты описываются с помощью модели прецедентов. Есть два актера: Клиент
Банкомата и Оператор, которые являются пользователями системы. Клиент имеет право
снимать деньги с чекового или сберегательного счета запрашивать сведения о состоянии счета и
переводить деньги с одного счета на другой. Клиент общается с системой с помощью устройства
считывания карточек, клавиатуры, дисплея, устройства выдачи наличных и устройства печати чеков.
Оператор способен выключить банкомат, пополнить запас наличных и включить банкомат.
Поскольку актер - это лишь роль, в которой выступает пользователь, то операторов и клиентов
может быть много.
Рассмотрим прецеденты, в которых участвует оператор: Добавить Наличные Запустить и
Остановить.
5
Проанализируем прецеденты Клиента Банкомата. Поскольку клиент может выполнять
транзакции трех типов, мы начнем с прецедентов Снять Деньги, получить Справку и Перевести
Деньги. Сравнение показывает, их первая часть - проверка ПИН-кода - является общей. Мы
вынесем ее в страстный включаемый прецедент Проверить ПИН-код.
Прецедент Проверить ПИН-код
Имя прецедента. Проверить ПИН-код.
Сводка. Сситема проверяет введенный клиентом ПИН-код.
Актер. Клиент банкомата.
Предусловие. Банкомат свободен, на экране сообщение «Добро пожаловать».
Описание:
1. Клиент вставляет карточку в устройство считывания.
2 Если система опознает карточку, она считывает ее номер.
3. Система предлагает ввести ПИН-код.
4. Клиент набирает ПИН-код.
5. Система проверяет срок действия, а также не является ли карточка утерянной или
украденной.
6.Если карточка действительна, система сравнивает указанный клиентом ПИН-код с тем,
который хранится в системе.
7.
Если ПИН-коды совпали, то система выясняет, какие счета доступны владельцу
карточки.
8.
Система отображает номера счетов и предлагает клиенту на выбор три транзакции:
Снять деньги, Получить справку и Перевести деньги.
Альтернативы:
 если карточка не опознается системой, вернуть карточку;
 если система определяет, что срок действия карточки истек, конфисковать
 карточку;
 если система устанавливает, что карточка утеряна или украдена, конфисковать
карточку;
 если указанный клиентом ПИН-код не совпадает с ПИН-кодом карточки,
предложить набрать ПИН-код повторно;
 если клиент три раза подряд вводит неправильный ПИН-код, конфисковать карточку;
 если клиент нажимает клавишу отмены, прервать транзакцию и вернуть карточку.
Постусловие. ПИН-код клиента проверен.
Прецедент «Снять Деньги»
Имя прецедента. Снять Деньги.
Сводка. Клиент снимает указанную сумму с существующего банковского счета.
Актер. Клиент банкомата.
Предусловие. Банкомат свободен, на экране сообщение «Добро пожаловать,
Описание:
1. Клиент вставляет карточку в устройство считывания.
2. Если система опознает карточку, она считывает ее номер.
3. Система предлагает набрать ПИН-код.
4. Клиент вводит ПИН-код.
5. Система проверяет срок действия, а также не является ли карточка утерянной или
украденной.
6. Если карточка действительна, система сравнивает указанный клиентом ПИН-код с тем,
что хранится в системе.
7. Если ПИН-коды совпали, система выявляет, какие счета доступны владельцу карточки.
8. Система отображает номера счетов и предлагает клиенту на выбор три транзакции: Снять
деньги, Получить справку и Перевести деньги.
9. Клиент выбирает «Снять деньги», вводит сумму и выбирает номер счета.
10. Система проверяет, достаточно ли средств на счете клиента и не превышен ли суточный
6
лимит.
10. Если все проверки прошли успешно, система разрешает выдачу наличных.
11. Система выдает наличные.
12. Система печатает чек, в котором указаны номер и тип транзакции, снятая сумма и баланс
счета.
13. Система возвращает карточку.
14. Система выводит на экран сообщение «Добро пожаловать».
Альтернативы:

если карточка не опознается системой, вернуть карточку;

если система определяет, что срок действия карточки истек, конфисковать карточку;

если система устанавливает, что карточка утеряна или украдена, конфисковать
карточку;

если набранный клиентом ПИН-код не совпадает с ПИН-кодом карточки,
предложить ввести ПИН-код повторно;

если клиент три раза подряд указывает неправильный ПИН-код, конфисковать
карточку;

если система определяет, что номер счета неверен, вывести на экран диагностическое
сообщение и вернуть карточку;

если система выявляет, что на счете клиента недостаточно средств, выразить
сожаление и вернуть карточку;

если система устанавливает, что превышен суточный лимит снятия наличных,
выразить сожаление и вернуть карточку;

если в банкомате недостаточно наличных, принести извинения, вернуть карточку и
отключить банкомат;

если клиент нажимает клавишу отмены, прервать транзакцию и вернуть карточку.
Постусловие. Деньги сняты со счета клиента.
Прецедент «Получить Справку»
Имя прецедента. Получить Справку.
Сводка. Клиент получает справку о состоянии существующего банковского счета.
Актер. Клиент банкомата.
Предусловие. Банкомат свободен, на экране сообщение «Добро пожаловать».
Описание:
1. Клиент вставляет карточку в устройство считывания.
2. Если система опознает карточку, она считывает ее номер.
3. Система предлагает указать ПИН-код.
4. Клиент вводит ПИН-код.
5. Система проверяет срок действия, а также не является ли карточка утерянной или
украденной.
6. Если карточка действительна, система сравнивает набранный клиентом ПИН-код с тем,
что хранится в системе.
7. Если ПИН-коды совпали, система выясняет, какие счета доступны владельцу карточки.
8. Система отображает номера счетов и предлагает клиенту на выбор три транзакции: Снять
деньги, Получить справку и Перевести деньги.
9. Клиент выбирает «Получить справку» и вводит номер счета.
10. Система считывает баланс счета.
11. Система печатает чек, в котором указаны номер и тип транзакции, снятая сумма и баланс
счета.
12. Система возвращает карточку.
13. Система выводит на экран сообщение «Добро пожаловать».
Альтернативы:




если карточка не опознается системой, вернуть карточку;
если система определяет, что срок действия карточки истек, конфисковать карточку;
если система устанавливает, что карточка утеряна или украдена, конфисковать карточку;
если набранный-клиентом ПИН-код не совпадает с ПИН-кодом карточки, предложить
7
ввести ПИН-код повторно;
 если клиент три раза подряд указывает неправильный ПИН-код, конфисковать карточку;
 если система определяет, что номер счета неверен, вывести на экран диагностическое
сообщение и вернуть карточку;
 если клиент нажимает клавишу отмены, прервать транзакцию и вернуть карточку.
Постусловие. Клиенту выдана справка по счету.
Прецедент «Перевести Деньги»
Имя прецедента. Перевести Деньги.
Сводка. Клиент переводит деньги с одного существующего банковского счета на другой.
Актер. Клиент банкомата.
Предусловие. Банкомат свободен, на экране сообщение «Добро пожаловать»
Описание:
1. Клиент вставляет карточку в устройство считывания.
2. Если система опознает карточку, она считывает ее номер.
3. Система предлагает указать ПИН-код.
4. Клиент вводит ПИН-код.
5. Система проверяет срок действия, а также не является ли карточка утерянной или украденной.
6. Если карточка действительна, система сравнивает набранный клиенток ПИН-код с тем, что
хранится в системе.
7. Если ПИН-коды совпали, система выясняет, какие счета доступны владельцу карточки.
8. Система отображает номера счетов и предлагает клиенту на выбор три транзакции: Снять деньги,
Получить справку и Перевести деньги.
9. Клиент выбирает «Перевести деньги» и вводит сумму, номер исходного счета и номер целевого
счета.
10. Если система определяет, что на исходном счете достаточно средств, то осуществляется
перевод.
11. Система печатает чек, в котором указаны номер и тип транзакции, переведенная сумма и
баланс счета.
12. Система возвращает карточку.
13. Система выводит на экран сообщение «Добро пожаловать».
Альтернативы:
 если карточка не опознается системой, вернуть карточку;
 если система определяет, что срок действия карточки истек, конфисковать карточку;
 если система устанавливает, что карточка утеряна или украдена, конфисковать карточку;
 если набранный клиентом ПИН-код не совпадает с ПИН-кодом карточки» предложить
ввести ПИН-код повторно;
 если клиент три раза подряд указывает неправильный ПИН-код, конфисковать карточку;
 если система определяет, что номер исходного счета неверен, вывести на экран сообщение об
ошибке и вернуть карточку;
 если система выявляет, что номер целевого счета неверен, вывести на экран сообщение об
ошибке и вернуть карточку;
 если система распознает, что на исходном счете недостаточно средств, выразить сожаление и
вернуть карточку;
 если клиент нажимает клавишу отмены, прервать транзакцию и вернуть карточку.
Постусловие. Деньги клиента переведены с одного счета на другой.
Отношения прецедентов
Если прецеденты становятся слишком сложными, то можно определить зависимости между
ними, пользуясь отношениями включения и расширения: таким образом увеличивается
расширяемость и пригодность прецедентов для повторного использования. При обозначении общих
для нескольких прецедентов паттернов определяются абстрактные прецеденты, которые в
дальнейшем допустимо применять повторно.
Еще одно отношение между прецедентами, определенное в UML, - это
обобщение/специализация. Обобщение прецедента сродни отношению расширения, поскольку оно
также предназначено для работы с вариантами. Однако пользователей концепция обобщения
8
прецедентов часто настораживает, поэтому она задействована только для классов. Варианты же
прецедентов вполне можно учесть с помощью отношения расширения.
Отношение расширения
Иногда прецедент становится чрезмерно сложным и имеет много альтернативных ветвей.
Отношение расширения позволяет промоделировать альтернативные ветви основного прецедента.
Сложность прецедента обусловлена большим числом альтернативных, необязательных и
исключительных последовательностей событий. Эта проблема решается путем вычленения таких
последовательностей в отдельный прецедент. Функция нового прецедента состоит в том, чтобы
расширить старый в случае, когда выполнены определенные условия. Расширяемый прецедент
называется базовым, а расширяющий - расширением.
Например, при некоторых условиях базовый прецедент В можно расширить в описании,
входящем в расширение Е. Расширять базовый прецедент можно по-разному, в зависимости от
условий. Отношение расширения используется следующим образом:

чтобы показать условную часть базового прецедента (выполняемую только при
соблюдении заданных условий);

чтобы промоделировать сложные или альтернативные пути.
Важно отметить, что базовый прецедент не зависит от расширения и способен
функционировать и без него. С другой стороны, расширяющий прецедент будет выполняться
только тогда, когда оказалось истинным некоторое условие в базовом. Без базового прецедента
расширение функционировать не может. Обычно расширение дополняет только один базовый
прецедент, хотя это и необязательно: оно в состоянии расширять сразу несколько
прецедентов.
Допустимо определить точки расширения, которые точно задают места, КУДА следует
добавить расширения базового прецедента. Тогда расширение дополнит базовый
прецедент только в этих точка.
Проиллюстрируем отношение расширения на примере из системы автоматизации
производства. Инженер-технолог определяет несколько производственных операций, а затем
составляет технологическую карту процесса, в которой фиксируется последовательность
операций при изготовлении детали. Это можно промоделировать с помощью одного
прецедента. Однако большая гибкость достигается, если воспользоваться расширяющим
прецедентом, как показано на рис. б Создать/Изменить Операцию - базовый прецедент,
который исполняется при создании каждой операции. Прецедент Создать/Изменить
Технологическую Карту расширяет базовый. Таким образом, технолог может провести
несколько операций с помощью базового прецедента, а затем при необходимости
разработать технологическую карту посредством прецедента расширения. В разделе
«Альтернативы» описания прецедента Создать /Изменить Операцию будет сказано, что
технолог вправе создать технологическую карту процесса, объединяющую ранее
определенные операции в последовательность
Рис. 6. Пример отношения расширения
На рис. 6 продемонстрирован также способ уменьшить число прецедентов. Некоторые
прецеденты следуют шаблону Создать/Прочитать/Изменить. Можно подготовить отдельный
прецедент для каждой функции: Создать Операцию, Изменить Операцию, Прочитать
9
Операцию. Однако удобнее сократить объем работы, объединив все три функции в один
прецедент под названием Создать/Изменить Операцию. По той же причине имеется только
один прецедент Создать/Изменить Технологическую Карту. В этих примерах допустимо
выбрать, какие из функций создания, чтения и изменения будут помещены в главную
последовательность. Первый вариант - оставить в главной последовательности функцию
создания, поскольку она содержит больше взаимодействий, а функций изменения и чтения
вынести в альтернативную ветвь. Второй вариант – включить в главную последовательность
как создание, так и изменение, при этом в прецеденте появится такая строка:
Если это новая операция, предложить оператору ввести ее название.
Подобные простые ветвления можно включать в главную последовательность,
поскольку они не затемняют ее сути. Предложения же типа «если-то-иначе» включать описание
не рекомендуется: это сделает его похожим на псевдокод.
Отношение включения
После разработки первого варианта прецедентов часто выявляются последовательности
взаимодействий между актером и системой, общие для нескольких прецедентов. Они отражают
функциональность, свойственную более чем одному прецеденту. Общий фрагмент можно изъять и
превратить в отдельный прецедент, называемый включаемым. Включаемый прецедент является
абстрактным в том смысле, что не может исполняться независимо, а лишь в составе конкретного
прецедента.
Вынеся общую функциональность во включаемый прецедент, ее легко использовать в
нескольких прецедентах. Следовательно, можно сократить описания старых прецедентов, убрав из
них включаемую часть. Такая сокращенная версия называется конкретным (или базовым)
прецедентом, включающим абстрактный прецедент.
Абстрактные прецеденты всегда отражают функциональность, общую для нескольких
прецедентов. Если общая функциональность абстрагируется, то абстрактный прецедент допустимо
включать в различные конкретные прецеденты. Обычно абстрактные прецеденты удается выделить
только после первой итерации, на которой несколько прецедентов уже разработано. Лишь тогда
становятся заметны повторяющиеся цепочки взаимодействий.
Абстрактный прецедент никогда не исполняется изолированно, а лишь в сочетании с
конкретным прецедентом, который его включает, а значит, и исполняет. Если провести аналогию с
программированием, то абстрактный прецедент похож на библиотечную процедуру, а конкретный на вызывающую ее программу.
В абстрактном прецеденте может и не быть никакого актера. Актер присутствует в
конкретном прецеденте, включающем абстрактный. Поскольку абстрактный прецедент способен
включаться в разные конкретные, то им могут пользоваться различные актеры.
Проиллюстрируем применение абстрактных прецедентов на примере ранее описанных
прецедентов Снять Деньги, Получить Справку и Перевести Деньги. Нетрудно заметить, что
первая часть - проверка ПИН-кода клиента - во всех случаях одинакова. Нет смысла повторять ее в
каждом прецеденте. Удобнее выделить проверку ПИН-кода в абстрактный прецедент, называемый
Проверить ПИН-код, и использовать во всех трех вышеупомянутых прецедентах. Получившаяся
диаграмма прецедентов показана на рис. 7. Абстрактный прецедент Проверить ПИН-код и
конкретные прецеденты Снять Деньги, Получить Справку и Перелети Деньги подробно описаны
в примере банковской системы.
7. Пример абстрактного прецедента и отношения включения
Пакеты прецедентов
10
В больших системах работа с огромным числом прецедентов становится
затруднительной. Решить эту проблему можно с помощью пакетов прецедентов, включающих
группы взаимосвязанных прецедентов. Такой пакет может представлять высокоуровневые
требования, предъявляемые к крупным подсистемам. Поскольку зачастую инициируют и
участвуют в логически связанных прецедентах одни и те же актеры, то объединение
прецедентов в пакеты удобно осуществить на основе участвующих в них актеров.
Например, в системе автоматизации производства главные актеры - это инженертехнолог, дежурный оператор и начальник производства, и каждый из них инициирует
несколько прецедентов и участвует в них. Следовательно, допустимо создать пакеты
прецедентов, обозначив их именами главных актеров: «Прецеденты инженера-технолога»,
«Прецеденты дежурного оператора» и «Прецеденты начальника производства». На рис. 8
приведен пример Пакета Прецедентов Дежурного Оператора, состоящего из четырех
прецедентов. Дежурный Оператор является главным актером в прецедентах Следить за
Сигналами Тревоги и Следить за Состоянием Рабочей Станции и второстепенным - в
остальных прецедентах. Заводской Робот - главный актер в прецедентах Поднять Тревогу и
Известить и Изменить Состояние Рабочей Станции и Известить
8. Пример пакета прецедентов
11