Технология разработки программного обеспечения Динамическое моделирование с учетом состояния. - презентация

1 Технология разработки программного обеспечения Динамическое моделирование с учетом состояния

2 Динамическое моделирование Два вида динамического моделирования 1.Моделирование не учитывающее состояние объектов. 2.Моделирование учитывающее состояние объектов (зависимое от состояния).

3 Динамическое моделирование с учетом состояния

4 Введение Моделирование динамического взаимодействия с учетом состояний имеет дело с ситуациями, в которых взаимодействие объектов является зависимым от состояния. В ходе структуризации объектов определяются объекты, которые участвуют в реализациях вариантов использования. Если, по крайней мере, один из объектов является управляющим объектом, зависящим от состояния, то тогда данное взаимодействие определяется, как зависимое от состояния и должен использоваться термин «моделирование динамического взаимодействия с учетом состояний».

5 Динамический анализ систем, зависящих от состояния В данном случае речь идет о взаимодействиях между объектами, которые участвуют в ВИ, зависящем от состояния: – выходные данные, получаемые актером, зависят не только от входных данных, но и от того, что происходило в системе раньше. В ВИ, зависящем от состояния, имеется зависящий от состояния управляющий объект, который исполняет свою диаграмму состояний, управляя тем самым последовательностью событий. В сложных ВИ таких объектов обычно несколько, и у каждого есть своя диаграмма состояний.

6 Сообщение состоит из события и связанных с ним данных. Если объект, исполняющий некоторую диаграмму состояний, получает сообщение, то событие, которое является его частью вызывает переход состояний. Выполняемое действие соответствует выходному событию, изображенному на диаграмме коммуникации.

7 Терминология В общем случае, – если говорится о сообщениях, то имеются в виду диаграммы взаимодействия (коммуникации или последовательности), – если говорится о событиях, то имеются в виду диаграммы состояний. Однако при описании динамического сценария с зависимостью от состояния обычно используется термин «событие».

8 Объект-отправитель посылает событие управляющему объекту, зависящему от состояния. Поступление входного события вызывает переход состояний. В результате этого перехода генерируется одно или несколько выходных событий, каждое из которых управляющий объект посылает тому или иному объекту-получателю. Выходное событие на диаграмме состояний изображается в виде действия (при переходе состояния, при входе или при выходе) либо начальной или завершающей деятельности.

9 Определение объектов и взаимодействий Целью моделирования динамического взаимодействия, учитывающего состояние является определение взаимодействий между следующими объектами: 1.Управляющим объектом, зависящим от состояния, который выполняет машину состояний. 2.Объектами (обычно программными интерфейсными), которые отправляют сообщения управляющему объекту. – Эти события вызывают переходы между состояниями во внутренней машине состояний управляющего объекта. 3.Объектами, которые выполняют действия и деятельности, которые запускаются управляющим объектом в ответ на переход в новое состояние. 4.Прочими объектами, которые участвуют в реализации данного ВИ. Взаимодействия между всеми этими объектами показываются на диаграмме коммуникации или последовательности.

10 Основные шаги динамического анализа, зависящего от состояния 1.Определение интерфейсных объектов. Для этого нужно выяснить, какие объекты получают входные данные от актера. 2.Определение зависящего от состояния управляющего объекта. Существует хотя бы один управляющий объект, который исполняет некоторую диаграмму состояний, но могут потребоваться и дополнительные управл. объекты. 3. Определение прочих внутренних объектов. Определяются внутренние объекты, которые взаимодействуют с управляющими или интерфейсными объектами.

11 4.Выполнение анализа взаимодействия объектов в сценарии основной последовательности действий. – Этот шаг следует выполнять вместе с шагом 5, т.к. необходимо детально выяснить взаимодействие между управляющим объектом и диаграммой состояния, которую он исполняет. 5. Определение выполнения диаграммы состояний. 6. Рассмотрение альтернативных последовательностей. – Проведение зависящего от состояния динамического анализа альтернативных последовательностей вариата использования.

12 Исполнение диаграммы состояний Исполнение диаграммы состояний рассматривается совместно с объектами, которые непосредственно взаимодействуют с соответствующим управляющим объектом. Сначала, как правило, проще разобрать плоскую (не иерархическую) диаграмму состояний. На диаграмме состояний представлены те аспекты варианта использования, которые зависят от состояния. Диаграмма состояний, исполняемая управляющим объектом, описывает общее управление и последовательность работы в прецеденте, зависящем от состояния.

13 Чтобы не вводить сразу много подробностей, при разработке диаграммы состояний рекомендуется анализировать только состояния, видимые извне (то есть доступные актеру). Необходимо также включить в рассмотрение события, прямо или косвенно поступающие из внешней среды и приводящие к изменению состояния управляющего объекта. При получении входного события зависящий от состояния объект генерирует выходные события, которые зависят не только от входных данных, но и от текущего состояния диаграммы состояний.

14 Диаграмму состояний следует анализировать вместе с диаграммой коммуникации. В частности, необходимо проанализировать сообщения, получаемые и посылаемые управляющим объектом, который исполняет данную диаграмму состояний. Входное для управляющего объекта сообщение, изображенное на диаграмме коммуникации, должно быть согласовано с соответствующим событием на диаграмме состояний. Напротив, выходное событие (приводящее к выполнению действия или деятельности), показанное на диаграмме состояний, должно быть согласовано с выходным сообщением на диаграмме коммуникации.

15 Предварительный вариант диаграммы состояний удобно разработать ранее для лучшего понимания зависящих от состояния аспектов поведения системы. Теперь полученная диаграмма состояний нуждается в уточнении. Если она создавалась до диаграммы коммуникации, то требуется проверить, согласована ли она с последней, и при необходимости внести изменения.

16 Разработка диаграмм кооперации и состояний обычно протекает итеративно; – последовательно рассматриваются все входные и все выходные (по отношению к управляющему объекту и его диаграмме состояния) события. Можно выделить более мелкие шаги: 1.Получение события управляющим объектом (часто от интерфейсного объекта) приводит к переходу состояний. – Для каждого перехода состояний следует определить, какие при этом выполняются действия и деятельности. – Помните, что действие выполняется мгновенно, а деятельность занимает конечное время. Концептуально действие выполняется в момент перехода, а деятельность протекает в течение всего времени нахождения в данном состоянии. – Укажите все объекты, которые исполняют выявленные действия и деятельности. – Действие срабатывает, а деятельность начинается. – Важно также выяснить, нужно ли завершить какую-то ранее начатую деятельность.

17 2.Для каждого сработавшего или начавшего работу объекта определите, какие сообщения он генерирует и что происходит с этими сообщениями: – посылаются они другому объекту или – выводятся во внешнюю среду. 3.Покажите внешнее событие и последовавшие за ним внутренние события на диаграммах состояний и кооперации. – События нумеруются, чтобы была видна последовательность их выполнения. – На обеих диаграммах события должны иметь одинаковые номера, которые фигурируют также и в словесном описании порядка сообщений.

18 Рассмотрение альтернативных последовательностей 1.По завершении зависящего от состояния динамического анализа для главной последовательности нужно рассмотреть альтернативные последовательности, указанные в прецеденте. – При этом на диаграмме состояний могут появиться новые состояния и переходы, например для обработки ошибок. 2. Прежде чем закончить, необходимо проверить все сценарии взаимодействия объектов и убедиться, что: – в каждое состояние можно попасть, и каждый переход срабатывает хотя бы один раз; – каждое действие и деятельность выполняются хотя бы единожды.

19 Пример динамического анализа: банковская система В качестве примера рассмотрим абстрактный вариант использования "Проверить ПИН-код", из банковской системы. Вначале определяются объекты, принимающие в участие в данном ВИ. Затем рассматривается основная последовательность событий, а затем альтернативные последовательности событий.

20 Спецификация варианта использования «Проверка ПИН кода» Имя варианта использования: Проверка ПИН кода. Краткое описание: Система проверяет ПИН код клиента. Актер: клиент банкомата (ATM). Предусловие: банкомат бездействует и показывает сообщение предлагающее начать работу. Основная последовательность: [далее] Альтернативная последовательность: [далее] Постусловие: ПИН код клиента проверен.

21 Основная последовательность ВИ 1.Клиент вставляет карточку банкомата (ATM card) в устройство чтения карт (card reader). 2.Если система распознает данную карту, то она читает с нее информацию (номер, дата выпуска, дата окончания). 3.Система предлагает клиенту ввести ПИН код карты. 4.Клиент вводит ПИН код. 5.Система проверяет дату окончания действия карты и не сообщается ли о том, что данная карта является потеряна или украдена. 6.Если карта является правильной (действующей), то проверяется совпадает ли введенный клиентом ПИН код с ПИН кодом, который хранится в банковской системе. 7.Если ПИН код правильный, то система проверяет, какие счета доступны с помощью данной карты. 8.Система показывает счета клиента и предлагает выбрать тип операции (транзакции): снятие денег, получение информации, перевод денег.

22 Альтернативные последовательности ВИ Шаг 2: Если система не распознает карту то, она выбрасывает ее. Шаг 5: Если система определяет, что срок действия карты завершен, то она конфискует данную карту. Шаг 5: Если система определяет, что есть сообщение о том, что данная карта утеряна или украдена, то система конфискует данную карту. Шаг 7: Если ПИН код введенный клиентом не соответствует ПИН коду карты, то система предлагает клиенту вновь ввести ПИН код. Шаг 7: Если клиент введет не правильный ПИН код три раза, то система конфискует данную карту. Шаги 4–8: Если клиент введет команду «Завершить» (Cancel), то система завершает обработку карты и выбрасывает ее.

23 Диаграмма состояний «Проверить ПИН-код» (рис. 6)

24 Диаграмма коммуникации ВИ «Проверить ПИН-код» (рис. 3)

25 Диаграмма последовательности ВИ «Проверить ПИН-код» (рис. 5)

26 ВИ начинается, когда клиент вставляет карточку в устройство считывания. Нумерация сообщений идет с 1, этот номер присваивается первому внешнему событию, инициированному актером. Следующие номера соотносятся с объектами в системе, реагирующими на это событие: 1.1,1.2, 1.3 и, наконец, 1.4. Последний номер присвоен отклику системы, который показан актеру на экране. Следующему внешнему событию, инициированному актером, присвоен помер 2 и т.д. В описании последовательности сообщений ниже указаны все сообщения на диаграммах кооперации и последовательности (рис. 3 и 5).

27 Очередность сообщений: 1: Клиент Банкомата вставляет карточку в Устройство Считывания Карточек. Данные с карточки считываются объектом Интерфейс Устройства Считывания Карточек. 1.1: Объект Интерфейс Устройства Считывания Карточек отправляет Данные Карточки, включающие идентификатор карточки и срок действия, сущностному объекту Карточка. 1.2: Интерфейс Устройства Считывания Карточек посылает событие Карточка Вставлена объекту Управление Банкоматом. Это приводит к переходу из состояния Простаивает (начального) в состояние «Ожидание ПИН-кода». С этим переходом ассоциировано действие «Получить ПИН-код», которое на диаграмме состояний соответствует выходному событию «Получить ПИН-код» на диаграммах кооперации и последовательности. 1.3: Объект Управление Банкоматом посылает событие Получить ПИН-код объекту «Интерфейс Клиента». 1.4: Объект Интерфейс Клиента выводит «Приглашение к Вводу ПИН-кода» актеру «Клиент Банкомата».

28 2: Актер «Клиент Банкомата» вводит ПИН-код в объект Интерфейс Клиента. 2.1: «Интерфейс Клиента» запрашивает Данные Карточки у объекта «Карточка». 2.2: Объект «Карточка» передает «Данные Карточки» объекту «Интерфейс Клиента». 2.3: «Интерфейс Клиента» отправляет «Информацию о Клиенте», содержащую идентификатор карточки, ПИН-код и срок действия карточки, сущностному объекту «Транзакция Банкомата». 2.4: «Интерфейс Клиента» посылает событие «ПИН-код Введен» (Данные о Клиенте) объекту Управление Банкоматом. Это вызывает переход последнего из состояния «Ожидание пин- кода» в состояние «Проверка ПИН-кода». С данным переходом ассоциировано выходное событие Проверить ПИН-код.

29 2.5: Объект «Управление Банкоматом» передает запрос «Проверить ПИН-код» (Данные о Клиенте) объекту Банковский Сервер. 2.6: «Банковский Сервер» проверяет ПИН-код и возвращает объекту «Управление Банкоматом» ответ «Правильный ПИН- код». При получении этого события объект «Управление Банкоматом» переходит в состояние «Ожидание Выбора Клиента». С таким переходом связано два описанных ниже выходных события.

30 2.7: Объект «Управление Банкоматом» посылает событие «Вывести Меню» объекту «Интерфейс Клиента». 2.7а: Объект «Управление Банкоматом» отправляет сообщение «Обновить Состояние» объекту «Транзакция Банкомата». 2.8: Объект «Интерфейс Клиента» выводит актеру «Клиент Банкомата» меню с операциями – «Снять деньги», – «Получить справку» и – «Перевести деньги».

31 На рис. показана параллельная последовательность, в которой присутствуют, в частности, сообщения 2.7 и 2.7а. Объект «Управление Банкоматом» посылает эти сообщения в момент выполнения одного и того же перехода, поэтому обе последовательности сообщений (одна для «Клиента Банкомата», другая для «Транзакции Банкомата») могут исполняться параллельно.

32 Альтернативные последовательности событий Далее рассматриваются альтернативные последовательности в ВИ «Проверить ПИН-код». При описании главной последовательности в предыдущем разделе предполагалось, что карточка действительна и ПИН-код введен правильно. Теперь рассматривается сценарий ветви, соответствующей недействительной карточке и неправильно введенному ПИН-коду. Их можно выявить на основе раздела «Альтернативы» в описании ВИ.

33 Анализ сообщения «Проверить ПИН-код», На данное сообщение возможно поступление различных ответов. 1.карточка действительна, ПИН-код введен правильно. 2.введен неправильный ПИН-код. 3.неправильный ПИН-код введен три раза подряд. 4.карточка украдена или закончился срок ее действия. В точке, где происходит разделение, каждая ветвь помечается своей заглавной буквой. – альтернативные ответы на сообщение 2.6 будут нумероваться так: 2.6А, 2.6В и 2.6С.

34 Ответ 1: «карточка действительна, ПИН-код введен правильно» Такой ответ соответствует главной последовательности и описывается условием [Правильный]: 2.6: [Правильный]: Правильный ПИН-код Банковский Сервер посылает сообщение «Правильный ПИН-код».

35 Ответ 2: «введен неправильный ПИН- код» Данная альтернатива описывается условием [Неправильный]: 2.6А* [Неправильный]: Неправильный ПИН-код В таком случае «Банковский Сервер» посылает сообщение «Неправильный ПИН- код». Повторный запрос порождает группу сообщений с номерами от 2.6А.1 до 2.6А.8;

36 Ответ 3: «неправильный ПИН-код введен три раза подряд» Такая ситуация описывается условием [Три Неудачи]: 2.6В [Три Неудачи]: Третий неверный ПИН-код В этом случае «Банковский Сервер» посылает сообщение «Третий неверный ПИН-код».

37 Ответ 4: «карточка украдена или закончился срок ее действия» Такая ситуация описывается условием [Украдена ИЛИ Закончилась]: 2.6С [Украдена ИЛИ Закончилась]: Карточка Украдена, Истек Срок Действия Какова бы ни была причина, последовательность сообщений одна и та же, а результат - конфискация карточки.

38 Все эти альтернативные сценарии можно изобразить на диаграмме взаимодействия. На следующем слайде показана диаграмма коммуникации для случая «неправильно введен ПИН-код». В данной ситуации становится истинным сторожевое условие [Неправильный], показывающее, что «Банковский Сервер» послал сообщение 2.6А: Неправильный ПИН-код. Наличие звездочки (*) говорит о том, что это сообщение может быть послано многократно (в нашем примере не более двух раз). При получении такого сообщения выполняется последовательность сообщений с номерами от 2.6А.1 до 2.6А.8.

39 Ситуация 1: «Неправильный ПИН-код» (рис. 7)

40 При повторном наборе неправильного ПИН-кода вся последовательность проводится еще раз. Альтернатива, показанная на рис. 7, соответствует случаю, когда клиент со второй или третьей попытки указывает правильный ПИН-код. Тогда «Банковский Сервер» посылает сообщение «Правильный ПИН-код», а сторожевое условие [Правильный] оказывается истинным. Последовательность сообщений в этом случае будет такой же, как на рис. 3.

41 Другая альтернатива возникает в ситуации, когда клиент и в третий раз вводит неправильный ПИН-код (рис. 8). Тогда будет истинным условие [Три Неудачи], и карточка блокируется.

42 Ситуация 2: «Третий Неправильный ПИН- код» (рис. 8.)

43 Еще один вариант показан на рис. 9: срок действия карточки истек или она украдена (последовательность сообщений 2.6С -2.6С.2). Оба случая обрабатываются так же, как предыдущий: карточка конфискуется.

44 Ситуация 3: «карточка украдена или у нее закончился срок действия» (рис. 9.)

45 Все альтернативы можно показать на обобщенной диаграмме коммуникации. Хотя при этом получается более компактное представление взаимодействий объектов, читать такую диаграмму труднее. Обобщенную диаграмму коммуникации следует применять лишь тогда, когда все альтернативы удается изобразить наглядно. Если же она оказывается слишком громоздкой, лучше нарисовать отдельные диаграммы коопераций или последовательности для каждой альтернативы.

46 Обобщенная ДК для ВИ «Проверить ПИН-код» (рис. 10)

47 Управляющий объект «Управление Банкоматом» исполняет диаграмму состояний, которая показана на следующем слайде. На ней изображены различные состояния, возникающие при исполнении ВИ «Проверить ПИН- код» (в том числе его альтернативных ветвей). При получении события «ПИН-код введен» (под номером 2.4) от «Интерфейса Клиента» объект «Управление Банкоматом» переходит в состояние «Проверка ПИН-кода» и посылает сообщение «Проверить ПИН-код» объекту «Банковский Сервер». Возможные ответы на это сообщение показаны на рис. 10.

48 Диаграмма состояния объекта «Управление Банкоматом» (рис. 11) Диаграмма состояния объекта «Управление Банкоматом» для ВИ «Проверка ПИН-кода», показаны все альтернативы

49 Получающиеся в результате состояния и действия изображены на рис. 11, а соответствующие взаимодействия объектов - на рис Ответ «Правильный ПИН-код» (событие 2.6) приводит к переходу в состояние «Ожидание Выбора Клиента». 2.Ответ «Неправильный ПИН-код» (событие 2.6А) сопровождается переходом в состояние «Ожидание ПИН-кода» и выполнением действия «Сообщение о Неправильном ПИН-коде» (событие 2.6А.1) объектом «Интерфейс Клиента». 3.Ответ «Третий Неправильный ПИН-код» (2.6В) способствует переходу в состояние Конфискуется и реализации действия Конфисковать (событие 2.6В.1) объектом «Интерфейс Устройства Считывания Карточек».

50 1.Ответ «Карточка Украдена» (2.6С) трактуется точно так же. 2.Наконец, если клиент решил «Отменить транзакцию» (2А.1) вместо того, чтобы повторно вводить ПИН-код, диаграмма переключается в состояние Возврат, и объект «Интерфейс Устройства Считывания Карточек» выполняет действие Вернуть (2А.2). 3.Поскольку клиент может «Отменить транзакцию», когда объект «Управление Банкоматом» находится в любом из подсостояний «Ожидание ПИН-кода», «Проверка ПйН-кода» или «Ожидание Выбора Клиента», то переход на диаграмме ведет из надсостояния «Обработка Ввода Клиента» (рис. 11).

51 Диаграмма состояний инициирует также параллельные последовательности действий, вызванные одним и тем же переходом. При этом все действия исполняются в недетерминированном порядке. Например, действия 2.7: Вывести Меню и 2.7а: Обновить Состояние, вызванные переходом из состояния Правильный ПИН-код, выполняются параллельно, как видно из рис. 10. Параллельные последовательности действий ассоциированы также с переходами – «Неправильный ПИН-код», – «Третий Неправильный ПИН-код» и – «Отменить».

52 Моделирование сценариев взаимодействия с помощью диаграмм взаимодействия и состояния Диаграммы взаимодействия могут использоваться с диаграммами состояния для моделирования сценариев взаимодействия зависимых от состояний (шаги 4 и 5). Сообщение на диаграмме взаимодействия состоит из – события и – данных, которые сопровождают данное событие. Рассмотрим взаимосвязь между сообщениями и событиями, в управляющем объекте, зависящем от состояния, который работает в соответствии с заданной диаграммой состояний.

53 Взаимосвязь между сообщениями и событиями Когда сообщение поступает в управляющий объект в диаграмме коммуникации, то событие, которое содержится в данном сообщении вызывает смену состояния на диаграмме состояний. Результатом смены состояния является некоторое действие, определенное в диаграмме состояний. Данное действие приводит к отправке сообщения, которое показано на диаграмме коммуникации. В общем случае, сообщению на диаграмме взаимодействия (коммуникации или последовательности) соответствует событие на диаграмме состояний; Однако, при описании зависимых от состояний динамических сценариев, для краткости, используется только термин событие.

54 Исходный объект отправляет событие управляющему объекту, зависящему от состояния. Поступление данного входного события вызывает смену состояния на диаграмме состояний. Результатом смены состояния является одно или более выходное событие. Зависимый от состояния управляющий объект отправляет выходное событие объекту, для которого он предназначен. – Прибытие сообщения из ДК инициирует событие в ДС (входное событие). – Событие инициированное в ДС (выходное событие) приводит к отправке сообщения в ДК

55 Выходное событие (output event) показывается на диаграмме состояний в виде действия (action), которое м.б. – действием по смене состояния; – входным действием (entry action) или – выходным действием. Для гарантирования согласованности между ДК и ДС эквивалентным сообщениям ДК и событиям ДС должны быть даны одинаковые имена. Более того, для рассматриваемого зависимого от состояния сценария необходимо на обоих диаграммах использовать одинаковую нумерацию очередности сообщений. Использование одинаковой нумерации очередности сообщений гарантирует, что сценарий будет точно представлен на обоих диаграммах и может анализироваться на согласованность.