Состояния видов деятельности

Моделирование объектов
Интернет-магазин
ТЕМЫ

Интернет-магазин – Постановка задачи

Use Case моделирование

Моделирование деятельности

Моделирование классов

Моделирование взаимодействия

Моделирование состояний
2
ИНТЕРНЕТ-МАГАЗИН– ПОРЯДОК
ОБРАБОТКИ
Покупка компьютера через Интернет
Компьютеры классифицируются
рабочие станции и ноутбуки
на
серверы,
Клиент
может
выбрать
стандартную
конфигурацию или построить заказную он-лайн
Для размещения заказа клиент должен заполнить
информацию о поставке и оплате (методы оплаты
кредитной картой наличными)
После ввода заказа система отправляет клиенту
сообщение о конфигурации по электронной почте
со спецификацией заказа
3
ИНТЕРНЕТ-МАГАЗИН(ПРОД.)
Клиент в любое
состояние заказа
время
может
проверить
Обработка
заказа
на
сервере
состоит
необходимости выполнения следующих шагов
Проверка полномочий и метода оплаты,
Запросить заказанную конфигурацию со склада,
Распечатать счет и запрос, и
Запросить склад отправить компьютер клиенту
Заказанная
конфигурация
клиенту со счетом
отправляется
4
МОДЕЛИРОВАНИЕ ПРЕЦЕДЕНТОВ
Поведение системы что делает система в ответ на внешние
события
Прецедент (Use case) – внешне заметное и проверяемое
поведение системы
Актор (Actor) – кто-либо или что-либо (субъект, машина, и
т.п.) взаимодействующее с вариантом использования
Актор получает полезный результат
Прецедент
представляет
функциональности для актора
Могут
быть
некоторые
взаимодействуют с актором
единицу
прецеденты,
полезной
которые
не
В многих случаях функциональное требование отображается
непосредственно на прецедент
Use Case Diagram визуальное представление акторов и
прецедентов вместе с дополнительными формулировками и
спецификациями
5
РАСШИРЕННЫЕ ТРЕБОВАНИЯ(СЦЕНАРИЙ)
Клиент использует веб-страницу интернет магазина
производителя для просмотра стандартной
конфигурации выбранного сервера, рабочей станции
или ноутбука. Также представляется цена.
Клиент выбирает просмотр конфигурации с
намерением приобрести ее в таком виде либо
построить более подходящую конфигурацию. Цена
для каждой конфигурации может вычисляться по
запросу клиента.
Клиент может выбрать компьютер для заказа он-лайн
или обратиться к продавцу с просьбой объяснить ему
детали заказа, обсудить цену и т.п. прежде чем заказ
будет действительно размещен.
Для размещения заказа клиент должен заполнить онлайн форму с адресом доставки и оплаты, а также
способом оплаты (кредитная карта или наличные).
6
РАСШИРЕННЫЕ ТРЕБОВАНИЯ (ПРОД.)
После ввода клиентом заказа в систему , продавец
посылает электронный запрос на склад со
спецификацией заказанной конфигурации.
Подробности транзакции, содержащие номер заказа
и номер счета клиента отправляются по электронной
почте клиенту, чтобы клиент мог проверить статус
заказа он-лайн.
Склад получает заказ от продавца и отправляет
компьютер клиенту.
7
АКТОРЫ
Акторы и прецеденты определяются на основе описания
требований:
После ввода клиентом заказа в систему , продавец посылает
электронный запрос на склад со спецификацией заказанной
конфигурации
Customer
Saleperson
Warehouse
8
ПРЕЦЕДЕНТЫ
Клиент использует вебстраницу интернет
магазина производителя
для просмотра
стандартной
конфигурации
выбранного сервера,
рабочей станции или
ноутбука.
Клиент выбирает
просмотр конфигурации
с намерением
приобрести ее в таком
виде либо построить
более подходящую
конфигурацию.
Display Standard
Computer Configuration
Build Computer
Configuration
Order Configured
Computer
Request
Salesperson Contact
Verify and Accept
Customer Payment
Inform Warehouse
about Order
Update
Order Status
Print Invoice 9
9
USE CASE ДИАГРАММА
Build Computer
Display Standard
Computer Configuration Configuration
Связь<<extend>>
Order Configured - прецедент
Computer
Order
Configured
Verify and Accept Customer
Customer Payment
<<extend>> Computer может
быть расширен
Customer с
прецедентом
Request
Salesperson ContactRequest
Print Invoice
Salesperson
Update
Order Status
Contact
Warehouse Salesperson
Warehouse Inform
about Order
10
ДОКУМЕНТИРОВАНИЕ ПРЕЦЕДЕНТОВ
Краткое описание
Участвующие Actors
Предусловия необходимы для запуска прецедента
Подробное описание потока событий включает:
Основной поток событий, который может быть разбит,
чтобы показать:
Подпотоки событий (подпотоки могут быть в дальнейшем
разделены на более мелкие для улучшения понятности
документа)
Альтернативные потоки для определения
исключительных ситуаций
Постусловия которые определяют состояние
системы после завершения прецедента
11
ОПИСАНИЕ СПЕЦИФИКАЦИИ ПРЕЦЕДЕНТА
Use Case
Заказ компьютера
Brief Description
Этот прецедент позволяет Customer ввести заказ покупки
Краткое описание …
Actors
Customer
Preconditions
Страница отображает подробности конфигурации компьютера с
его ценой …
Main Flow
Основной поток
Система назначает номер заказа и номер счета клиента для
покупки заказа и он хранится в информации о заказах в базе
данных. …
Alternative Flows
Альтернативный
поток
Customer инициирует функцию Purchase до введения всей
необходимой информации.
При нажатии Reset сисиема позволяет ввести информацию вновь
Postconditions
Постстусловия
Если прецедент был успешным, заказ на покупку записывается в12
базу данных.
МОДЕЛИРОВАНИЕ ВИДОВ
ДЕЯТЕЛЬНОСТИ
Модель видов деятельности
Может графически представлять поток событий для прецедента
Может использоваться для понимания шагов выполнения бизнеспроцесса на высоком уровне абстракции перед созданием
прецедента (до моделирования взаимодействия: диаграммы
последовательности и кооперации)
Показывает шаги вычислений
Каждый шаг соответствует состоянию (state) в котором что-нибудь
выполняется
Шаг выполнения называется состоянием вида деятельности
(activity states)
Изображает какие шаги выполняются последовательно, а какие
параллельно y
Переход (transition) – передача управления из одного состояния
в другое
Описания прецедента (Use case descriptions) обычно
создаетсяс точки зрения внешнего субъекта
Модели
видов деятельности (Activity models)
отражают внутрисистемную точку зрения
13
ВИДЫ ДЕЯТЕЛЬНОСТИ
Состояния видов деятельности (Activity states) могут
быть установлены на основе описания прецедентов
Виды
деятельности
(Activities)
должны
быть
поименованы с точки зрения системы, а не с точки зрения
субъекта
Вид деятельности
выполнения
(Activity)
требует
время
для
Действие (Action) завершается так быстро– в масштабах
временной шкалы– может считаться происходящим
мгновенно
UML использует один графический символ для состояния
вида деятельности (activity state) и состояния
действия (action state) – прямоугольник с
закругленными углами
14
УСТАНОВЛЕНИЕ ОПЕРАЦИЙ В ОСНОВНОМ И АЛЬТЕРНАТИВНЫХ ПОТОКАХ
N
Формулировки прецедента
Состояние вида
деятельности
1
Начало прецедента - решение клиента Заказать компьютер с помощью Display Current
выбора функции Continue (или аналогичной функции) при отображении Configuration; Get Order
Request
на экране подробной информации, относящейся к заказу
2
Система просит клиента ввести детализированную информацию о покупке, в том
числе: имя продавца (если оно известно); детали, касающиеся доставки (имя и
адрес клиента); детальную информацию по оплате (если она отличается от
информации по доставке); способ оплаты (кредитная карточка или чек) и
произвольные комментарии
Display Purchase Form
3
Клиент выбирает функцию Purchase (или аналогичную
функцию) для отправки заказа производителю.
Get Purchase Details
4
Система присваивает уникальный номер заказа и клиентский учетный
номер заказу на покупку и запоминает информацию о заказе в базе
данных
Store Order
5
Система отправляет клиенту по электронной почте номер заказа и
клиентский номер клиенту вместе со всеми деталями, относящимися
к заказу, в качестве подтверждения принятия заказа
Email Order Details
6
Клиент инициирует функцию Purchase до того, как введет всю
обязательную информацию. Система отображает на экране сообщение
об ошибке и просит ввести пропущенную информацию.
Get Purchase Details;
Display Purchase Form
7
Клиент выбирает функцию Reset (или аналогичную) для того, чтобы
вернуться к исходной форме заказа на покупку. Система дает
возможность клиенту вновь ввести информацию
15
Display Purchase Form
ВИДЫ ДЕЯТЕЛЬНОСТИ
Display Current
Configuration
Get Order
Request
Display
Purchase Form
Get Purchase
Details
Store Order
Email Order
Details
Система присваивает уникальный номер
заказа и клиентский учетный номер заказу на
покупку и запоминает информацию о заказе в
базе данных.
16
ДИАГРАММА ВИДА ДЕЯТЕЛЬНОСТИ
Диаграмма видов деятельности (Activity Diagram)
показывает переходы между видами деятельности
Закрашенная
окружность
состояние (initial state)
представляет
начальное
Конечное состояние (final state) показывается в виде
окружности с закрашенной центральной частью (бычий
глаз)
Переходы могут разветвляться по условию (branch) и
объединяться (merge) (ромб-условие ветвления) –
альтернативные вычислительные потоки
Переходы могут разделяться (fork) и сливаться (re-join)
(bar line) –в результате образуются параллельные
(concurrent) вычислительные потоки (threads)
Диаграмма вида деятельности без параллельных процессов
похожа на обычную блок-схему (flowchart)
17
ACTIVITY DIAGRAM
Display Current
Configuration
Множество
выходных
состояний
(условия
перехода
внутренние
по
отношению к
состоянию
вида
деятельности
[ timeout ]
Get Order
Request
Display
Purchase Form
[ incomplete ]
Get Purchase
Details
Store Order
[ OK ]
Email Order
Details
Явное условие
ветвления
(которое
появляется на
выходной
форме
состояния вида
деятельности)
18
МОДЕЛИРОВАНИЕ КЛАССОВ
Систему
образует
системное
состояние
(system
state)
–
функция
системной
информации в заданный момент времени
Элементы моделирования классов:
Сами классы
Атрибуты и операции классов
Связи– ассоциации, агрегации и композиции,
обобщения
Диаграмма классов (Class Diagram) – дает
обобщенное визуальное представление для
всех элементов модели
Моделирование классов и прецедентов обычно
выполняются параллельно
19
КЛАССЫ
До сих пор классы рассматривались, чтобы определять
бизнес-объекты, характеризующие сущность ИС
Называются классы-сущности (entity classes) (model classes)
Представляют постоянно хранимые объекты базы данных
Другие классы
Классы, которые определяют объекты GUI (sтакие как
экранные формы) – граничные классы (boundary classes)
(классы представления - view classes)
Классы, которые управляют программную
управляющие классы (control classes)
логику
–
Граничные и управляющие классы могут или не могут
рассматриваться на этапе анализа требований – могут
быть отложены до этапа проектирования системы.
20
Выделение
классов
представляет
собой
итеративную
задачу, и
первоначальный
перечень
предполагаемых
классов, как
правило,
претерпевает
изменения
21
КЛАССЫ (ПРОД.)
Что является классом?
Является ли понятие «вместилищем» данных?
Обладает ли оно отдельными атрибутами, которые
принимают различные значения?
Можно ли создать для него множество объектовэкземпляров?
Входит ли оно в границы прикладной области?
22
КЛАССЫ(ПРОД.)
•
Склад получает счет-фактуру (Invoice) от продавца
(Salesperson) и отправляет компьютер клиенту
(Customer)
Customer
Computer
(from Use Case View)
Необходим
ли класс
Shipment?
Входит ли он
в систему?
Salesperson
класс или атрибут
классов Order и
Invoice?
ConfiguredComputer
Order
Payment
ConfigurationItem
Invoice
23
АТРИБУТЫ
На практике
основные
атрибуты
назначаются
классу сразу
после его
добавления к
модели
24
АССОЦИАЦИИ
Customer
Computer
(from Use Case View)
1..1
Ассоциации,
связывающие классы,
устанавливают пути
для кооперации
объектов
1..1
Payment
0..*
ConfigurationItem
Order
1..1
0..*
1..1
0..1
Invoice
1..*
ConfiguredComputer
25
АГРЕГАЦИИ
Customer
Computer
(from Use Case View)
1..1
0..*
1..*
Order
ConfigurationItem
1..1
1..1
Payment
0..*
1..1
0..1
Invoice
1..*
1..*
ConfiguredComputer
26
ОБОБЩЕНИЯ
Customer
ConfigurationItem
(from Use Case View)
Класс изменен на абстрактный
1..1
класс Computer, являющийся
родовым для двух конкретных
подклассов — Standard
Computer и ConfiguredComputer.
1..1
Теперь классы Order и
ConfigurationItem связаны с классом
Computer, который может быть
либо классом StandardComputer,
либо классом ConfiguredComputer. 1..1
Payment
1..*
0..*
Computer
Order
0..*
1..*
1..1
0..1
Invoice
ConfiguredComputer
StandardComputer
27
ДИАГРАММА
КЛАССОВ
Диаграмма классов составляет,
так сказать, “сердце” и “душу”
объектно - ориентированной
системы. В данном наставлении
ставится цель только
продемонстрировать
возможности статического
моделирования применительно
к модели классов.
В классы пока что не введено ни
одной новой операции.
Операции принадлежат скорее к
этапу проектирования, чем
анализа.
28
МОДЕЛИРОВАНИЕ ВЗАИМОДЕЙСТВИЙ
Охватывает вопросы взаимодействия между объектами,
необходимым для выполнения прецедента
Показывает последовательность событий (сообщений) и
их связи с действующими в кооперации объектами
Используются на более развитых стадиях анализа
требований, когда становится известной модель классов,
так что ссылки на объекты опираются на модель классов
Два вида диаграмм взаимодействия
Диаграммы последовательностей (Sequence Diagram) –
концентрируются на временных последовательностях
Диаграммы кооперации (Collaboration Diagram) –
внимание уделяется отношениям между объектами
В
практике
разработки
ИС
–
диаграммы
последовательностей используются на этапе анализа
требований, а диаграммы кооперации - системного
проектирования
29
ВЗАИМОДЕЙСТВИЯ
Взаимодействие (Interaction) – набор сообщений,
свойственных поведению некоторой системы, которыми
обмениваются объекты в соответствии с установленными
между ними связями
Диаграммы последовательности
Объекты располагаются по горизонтали
Последовательности сообщений располагаются сверху вниз по
вертикали
Каждая вертикальная линия называется линией жизни
(lifeline) объекта
Стрелки представляют каждое сообщение, направляемое от
вызывающего объекта (отправителя) к операции (методу)
вызываемого объекта (получателя).
Фактические параметры могут быть
входными аргументами (передаются от отправителя к
получателю)
выходными аргументами (передаются от получателя назад к
отправителю).
crs_ref.getCourseName(out crs_name)
Показывать возврат return не обязательно
Итеративный маркер - звездочка перед обозначением
сообщения - указывает на процесс итерации сообщения
по всей коллекции
30
ВЗАИМОДЕЙСТВИЯ(ПРОД.)
: Customer
aConfWin :
ConfigurationWindow
aComp :
Computer
: Configuration
Item
openNew
getConf
* getConfItem (out item_rec)
displayComputer(item_recset)
Диаграмма последовательности для «отображения текущей конфигурации». Клиент
принимает решение оботображении конфигурации компьютера. Сообщение openNew
(открыть новое [окно]) отправляется объекту ConfWin класса ConfigurationWindow
([диалоговое] окно конфигурации). В результате создается ("материализуется как
экземпляр") новый объект ConfWin. (Класс ConfigurationWindow - граничный класс.
ConfWin необходимо “отобразить себя” вместе с данными, относящимися к
конфигурации. С этой целью он отправляет сообщение объекту aComp:Computer. В 31
действительности, aComp — это объект класса StandardComputer или ConfiguredComputer.
Класс Computer — абстрактный клас. aComp использует выходной аргумент для того,
чтобы “собрать себя” из элементов конфигурации — объектов ConfigurationItem
ВЗАИМОДЕЙСТВИЯ (CONT.)
32
ОПЕРАЦИИ
Исследование
взаимодействий
между
классами приводит к выявлению операций
Каждое сообщение(message) вызывает операцию
в вызываемом объекте
Имена операция и сообщения совпадают
Аналогично, наличие сообщения в диаграмме
последовательностей
обусловливает
необходимость ассоциации в диаграмме
классов
33
ОПЕРАЦИИ (ПРОД.)
Класс ConfigurationWindow —
пограничный класс. Два других
класса — это классы сущности,
представляющие постоянные
объекты базы данных. Операция
openNew выбрана в качестве
шаблона операции
конструктора. Это означает,
что операция openNew будет
реализована в качестве метода
конструктора, который
порождает новые объекты
класса.
34
ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ
ЗАКАЗ КОНФИГУРИРОВАННОГО КОМПЬЮТЕРА
35
линии жизни объектов Order и OrderWindow разделены на две части
ДИАГРАММА
ПОСЛЕДОВАТЕЛЬНОСТЕЙ(ПРОД.)
36
КОММЕНТАРИИ К ПРЕДЫДУЩИМ
СЛАЙДАМ






Пояснения к первым двум сообщением были сделаны на слайде 31.
Сообщение acceptConf вызывает отправку сообщения prepareForOrder
объекту :Order. Это приводит к созданию временного объекта :Order,
отображаемого в “объектеокне” :OrderWindow.
В ответ на принятие клиентом детализированных условий заказа
(submitOrder) объект :OrderWindow инициирует (storeOrder) создание
постоянного объекта :Order.
После этого объектзаказ :Order устанавливает связь с заказанным
компьютером (:Computer), а также соответствующими клиентом (:Customer)
и платежом :Payment.
После того, как эти объекты постоянно связаны в базе данных, объект
:Order отправляет электронное сообщение emailOrder внешнему субъектуклиенту (Customer).
Обратите внимание на двойное использование сущности :Customer — в
качестве внешнего субъекта, представленного объектом, и внутреннего
объекта-класса. Подобная двойственность довольно часто встречается в
моделировании. Клиент (Customer) является по отношению к системе
одновременно и внешней, и внутренней сущностью. Он представляет собой
внешнюю сущность, поскольку взаимодействует с системой извне. Однако
информация о клиенте должна храниться в системе, чтобы иметь
возможность установить идентичность внешнего клиента и внутренней
сущности, о которой знает система.
37
МОДЕЛИРОВАНИЕ СОСТОЯНИЙ
Фиксирует динамику изменения состояния классов
– возможные состояния класса - жизненный путь
класса
Эти изменения описывают поведение объектов в
рамках нескольких прецедентов
Состояние (state) объекта– обозначается текущими
значениями атрибутов объекта
Модель
состояний
(Statechart
Diagram)
–
двудольный граф
Состояний (states) (прям-к с закр. углами) и
Переходов (transitions) (стрелок) вызваных событиями
(events)
Концепция состояний и событий совпадает с
концепцией, которая известна по диаграмме
деятельности. Различие же заключается в том, что
"состояния графа видов деятельности представляют
состояния выполнения вычисления, а не состояния
38
обычного объекта"
СОСТОЯНИЯ И ПЕРЕХОДЫ
Значения атрибутов объекта изменяются,
однако не все подобные изменения
вызывают переход между состояниями
Модель состояний создается только для
интересных изменений состояний объекта
с точки зрения предметной области, а не
для любого изменения
Модель состояний – модель бизнес
правил
Бизнес правила– неизменны в течение
некоторого периода времени
Они относительно независимы от отдельных
прецедентов
39
СОСТОЯНИЯ И СОБЫТИЯ
Unpaid
partial payment
Partly Paid
final payment
final payment
Fully Paid
40
ДИАГРАММА СОСТОЯНИЙ
Обычно присоединяется к классу, но может
присоединяться и к другим
модельным
представлениям, например, прецедентам
Когда присоединяется к классу, диаграмма
определяет как объекты класса реагирует на
события
Определяет – для каждого состояния объекта –
какое действие (action) объект будет выполнять,
когда получает событие
Один и тот же объект может выполнять различные
действия для одних и тех же событий в
зависимости от состояния объекта
Выполнение действия будет обычно вызывать
изменение состояния
41
ДИАГРАММА СОСТОЯНИЙ (ПРОД.)
Источник
детализированного
описания
прецедента, и полное описание перехода состоит их
трех необязательных частей
event (parameters) [guard] / action
Event -
явление, воздействующее на объект,
возможна проверка срабатывания события
Action
– короткое атомическое вычисление,
которое выполняется при срабатывании перехода
Действие может также связано с состоянием
Activity
– более продолжительное вычисление,
связанное с состоянием
42
STATECHART DIAGRAM (CONT.)
Pending
Состояние
может
состоять из
других
состояний,
которые
называются
вложенными.
New Order
stock not available
Back Order
stock available[ ship date in future ]
Future Order
stock available[ ship date in future ]
[ canceled ]
stock available[ ship date now ] / configureComputer
Cancelled
Ready to Ship
[ canceled ]
ship[ accepted ]
Filled
43