Моделирование объектов Интернет-магазин

1. Моделирование объектовИнтернет-магазин

2. Темы • Интернет-магазин – Постановка задачи • Use Case моделирование • Моделирование деятельности • Моделирование классов • Моделирование взаимодействия • Моделирование состояний

3. Интернет-магазин– Порядок обработки • Покупка компьютера через Интернет • Компьютеры классифицируются на серверы, рабочие станции и ноутбуки • Клиент может выбрать стандартную конфигурацию или построить заказную он-лайн • Для размещения заказа клиент должен заполнить информацию о поставке и оплате (методы оплаты кредитной картой наличными) • После ввода заказа система отправляет клиенту сообщение о конфигурации по электронной почте со спецификацией заказа

4. Интернет-магазин(прод.) • Клиент в любое время может проверить состояние заказа • Обработка заказа на сервере состоит необходимости выполнения следующих шагов • Проверка полномочий и метода оплаты, • Запросить заказанную конфигурацию со склада, • Распечатать счет и запрос, и • Запросить склад отправить компьютер клиенту • Заказанная конфигурация отправляется клиенту со счетом

5. Моделирование прецедентов • Поведение системычто делает система в ответ на внешние события • Прецедент (Use case) –внешне заметное и проверяемое поведение системы • Актор (Actor) – кто-либо или что-либо (субъект, машина, и т.п.) взаимодействующее с вариантом использования • Актор получает полезный результат • Прецедент представляет единицу полезной функциональности для актора • Могут быть некоторые прецеденты, которые не взаимодействуют с актором • В многих случаях функциональное требование отображается непосредственно на прецедент • Use Case Diagramвизуальное представление акторов и прецедентов вместе с дополнительными формулировками и спецификациями

6. Расширенные требования(сценарий) • Клиент использует веб-страницу интернет магазина производителя для просмотра стандартной конфигурации выбранного сервера, рабочей станции или ноутбука. Также представляется цена. • Клиент выбирает просмотр конфигурации с намерением приобрести ее в таком виде либо построить более подходящую конфигурацию. Цена для каждой конфигурации может вычисляться по запросу клиента. • Клиент может выбрать компьютер для заказа он-лайн или обратиться к продавцу с просьбой объяснить ему детали заказа, обсудить цену и т.п. прежде чем заказ будет действительно размещен. • Для размещения заказа клиент должен заполнить он-лайн форму с адресом доставки и оплаты, а также способом оплаты (кредитная карта или наличные).

7. Расширенные требования (прод.) • После ввода клиентом заказа в систему , продавец посылает электронный запрос на склад со спецификацией заказанной конфигурации. • Подробности транзакции, содержащие номер заказа и номер счета клиента отправляются по электронной почте клиенту, чтобы клиент мог проверить статус заказа он-лайн. • Склад получает заказ от продавца и отправляет компьютер клиенту.

8. Акторы • Акторы и прецеденты определяются на основе описания требований:После ввода клиентом заказа в систему , продавец посылает электронный запрос на склад со спецификацией заказанной конфигурации Customer Saleperson Warehouse

9. Прецеденты • Клиент использует веб-страницу интернет магазина производителя для просмотра стандартной конфигурации выбранного сервера, рабочей станции или ноутбука. • Клиент выбирает просмотр конфигурации с намерением приобрести ее в таком виде либо построить более подходящую конфигурацию. Display Standard Build Computer Computer Configuration Configuration Request Order Configured Salesperson Contact Computer Verify and Accept Inform Warehouse Customer Payment about Order 9 Update Print Invoice Order Status

10. Use Case диаграмма Build Computer Display Standard Configuration Computer Configuration Связь<<extend>> - прецедент Order Configured Computerможет быть расширен Customerс прецедентомRequest Salesperson Contact Order Configured Computer Verify and Accept Customer Customer Payment <<extend>> Request Salesperson Contact Print Invoice Update Order Status Inform Warehouse Salesperson Warehouse about Order

11. Документирование прецедентов • Краткое описание • Участвующие Actors • Предусловиянеобходимы для запуска прецедента • Подробное описание потока событий включает: • Основной поток событий, который может быть разбит, чтобы показать: • Подпотокисобытий (подпотоки могут быть в дальнейшем разделены на более мелкие для улучшения понятности документа) • Альтернативные потоки для определения исключительных ситуаций • Постусловия которые определяют состояние системы после завершения прецедента

12. Описание спецификации прецедента

13. Моделирование видов деятельности • Модель видов деятельности • Может графически представлять поток событий для прецедента • Может использоваться для понимания шагов выполнения бизнес-процесса на высоком уровне абстракции перед созданием прецедента (до моделирования взаимодействия: диаграммы последовательности и кооперации) • Показывает шаги вычислений • Каждый шаг соответствует состоянию (state) в котором что-нибудь выполняется • Шаг выполнения называется состоянием вида деятельности (activity states) • Изображает какие шаги выполняются последовательно, а какие параллельно y • Переход (transition) – передача управления из одного состояния в другое • Описания прецедента (Use case descriptions)обычно создаетсяс точки зрения внешнего субъекта • Модели видов деятельности(Activity models)отражают внутрисистемную точку зрения

14. Виды деятельности • Состояния видов деятельности(Activity states)могут быть установлены на основе описания прецедентов • Виды деятельности (Activities)должны быть поименованы с точки зрения системы, а не с точки зрения субъекта • Вид деятельности (Activity)требует время для выполнения • Действие (Action)завершается так быстро– в масштабах временной шкалы– может считаться происходящим мгновенно • UML использует один графический символ для состояния вида деятельности (activity state)и состояния действия (action state) – прямоугольник с закругленными углами

15. N Формулировки прецедента Состояние вида деятельности 1 Начало прецедента - решение клиента Заказать компьютер с помощью выбора функции Continue (или аналогичной функции) при отображении на экране подробной информации, относящейся к заказу Display Current 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 (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система дает возможность клиенту вновь ввести информацию Display Purchase Form Установление операций в основном и альтернативных потоках

16. Виды деятельности • Система присваивает уникальный номер заказа и клиентский учетный номер заказу на покупку и запоминает информацию о заказе в базе данных.

17. Диаграмма вида деятельности • Диаграмма видов деятельности (Activity Diagram)показывает переходы между видами деятельности • Закрашенная окружность представляет начальное состояние(initial state) • Конечное состояние (final state)показывается в виде окружности с закрашенной центральной частью (бычий глаз) • Переходы могут разветвляться по условию (branch)и объединяться (merge) (ромб-условие ветвления) – альтернативные вычислительные потоки • Переходы могут разделяться (fork)и сливаться (re-join)(bar line) –в результате образуются параллельные (concurrent)вычислительные потоки (threads) • Диаграмма вида деятельности без параллельных процессов похожа на обычную блок-схему (flowchart)

18. Activity Diagram Явное условие ветвления (которое появляется на выходной форме состояния вида деятельности) Множество выходных состояний (условия перехода внутренние по отношению к состоянию вида деятельности

19. Моделирование классов • Систему образует системное состояние (system state) – функция системной информации в заданный момент времени • Элементы моделирования классов: • Сами классы • Атрибуты и операции классов • Связи– ассоциации, агрегации и композиции, обобщения • Диаграмма классов (Class Diagram) – дает обобщенное визуальное представление для всех элементов модели • Моделирование классов и прецедентов обычно выполняются параллельно

20. Классы • До сих пор классы рассматривались, чтобы определять бизнес-объекты, характеризующие сущность ИС • Называются классы-сущности (entity classes) (model classes) • Представляют постоянно хранимые объекты базы данных • Другие классы • Классы, которые определяют объекты GUI (sтакие как экранные формы) – граничные классы (boundary classes) (классы представления - view classes) • Классы, которые управляют программную логику – управляющие классы (control classes) • Граничные и управляющие классы могут или не могут рассматриваться на этапе анализа требований – могут быть отложены до этапа проектирования системы.

21. Выделение классов представляет собой итеративную задачу, и первоначальный перечень предполагаемых классов, как правило, претерпевает изменения

22. Классы (прод.) • Что является классом? • Является ли понятие «вместилищем» данных? • Обладает ли оно отдельными атрибутами, которые принимают различные значения? • Можно ли создать для него множество объектов-экземпляров? • Входит ли оно в границы прикладной области?

23. Классы(прод.) • Склад получает счет-фактуру (Invoice) от продавца (Salesperson) и отправляет компьютерклиенту (Customer) Необходим ли класс Shipment? Входит ли он в систему? Salesperson класс или атрибут классов Orderи Invoice?

24. Атрибуты На практике основные атрибуты назначаются классу сразу после его добавления к модели

25. Ассоциации Ассоциации, связывающие классы, устанавливают пути для кооперации объектов

26. Агрегации

27. Обобщения Класс изменен на абстрактный класс Computer, являющийся родовым для двух конкретных подклассов — Standard Computer и ConfiguredComputer. Теперь классы Order и ConfigurationItem связаны с классом Computer, который может быть либо классом StandardComputer, либо классом ConfiguredComputer.

28. Диаграмма классов Диаграмма классов составляет, так сказать, “сердце” и “душу” объектно - ориентированной системы. В данном наставлении ставится цель только продемонстрировать возможности статического моделирования применительно к модели классов. В классы пока что не введено ни одной новой операции. Операции принадлежат скорее к этапу проектирования, чем анализа.

29. Моделирование взаимодействий • Охватывает вопросы взаимодействия между объектами, необходимым для выполнения прецедента • Показывает последовательность событий (сообщений) и их связи с действующими в кооперации объектами • Используются на более развитых стадиях анализа требований, когда становится известной модель классов, так что ссылки на объекты опираются на модель классов • Два вида диаграмм взаимодействия • Диаграммы последовательностей (Sequence Diagram) – концентрируются на временных последовательностях • Диаграммы кооперации (Collaboration Diagram) – внимание уделяется отношениям между объектами • В практике разработки ИС – диаграммы последовательностей используются на этапе анализа требований, адиаграммы кооперации - системного проектирования

30. Взаимодействия • Взаимодействие (Interaction) – набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты в соответствии с установленными между ними связями • Диаграммы последовательности • Объекты располагаются по горизонтали • Последовательности сообщений располагаются сверху вниз по вертикали • Каждая вертикальная линия называется линией жизни (lifeline) объекта • Стрелки представляют каждое сообщение, направляемое от вызывающего объекта (отправителя) к операции (методу) вызываемого объекта (получателя). • Фактические параметры могут быть • входными аргументами (передаются от отправителя к получателю) • выходными аргументами (передаются от получателя назад к отправителю). • crs_ref.getCourseName(out crs_name) • Показывать возвратreturnне обязательно • Итеративный маркер - звездочка перед обозначением сообщения - указывает на процесс итерации сообщения по всей коллекции

31. Взаимодействия(прод.) Диаграмма последовательности для «отображения текущей конфигурации». Клиент принимает решение оботображении конфигурации компьютера. Сообщение openNew (открыть новое [окно]) отправляется объекту ConfWin класса ConfigurationWindow ([диалоговое] окно конфигурации). В результате создается ("материализуется как экземпляр") новый объект ConfWin. (Класс ConfigurationWindow - граничный класс. ConfWin необходимо “отобразить себя” вместе с данными, относящимися к конфигурации. С этой целью он отправляет сообщение объекту aComp:Computer. В действительности, aComp — это объект класса StandardComputer или ConfiguredComputer. Класс Computer — абстрактный клас. aComp использует выходной аргумент для того, чтобы “собрать себя” из элементов конфигурации — объектов ConfigurationItem

32. Взаимодействия (cont.)

33. Операции • Исследование взаимодействий между классами приводит к выявлению операций • Каждое сообщение(message)вызывает операцию в вызываемом объекте • Имена операция и сообщения совпадают • Аналогично, наличие сообщения в диаграмме последовательностей обусловливает необходимость ассоциации в диаграмме классов

34. Операции (прод.) Класс ConfigurationWindow —пограничный класс. Два других класса — это классы сущности, представляющие постоянные объекты базы данных. Операция openNew выбрана в качестве шаблона операции конструктора. Это означает, что операция openNew будет реализована в качестве метода конструктора, который порождает новые объекты класса.

35. Диаграмма последовательностейЗаказ конфигурированного компьютера линии жизни объектов Order и OrderWindow разделены на две части

36. Диаграмма последовательностей(прод.)

37. Комментарии к предыдущим слайдам • Пояснения к первым двум сообщением были сделаны на слайде 31. • Сообщение acceptConf вызывает отправку сообщения prepareForOrder объекту :Order. Это приводит к созданию временного объекта :Order, отображаемого в “объектеокне” :OrderWindow. • В ответ на принятие клиентом детализированных условий заказа (submitOrder) объект :OrderWindow инициирует (storeOrder) создание постоянного объекта :Order. • После этого объектзаказ :Order устанавливает связь с заказанным компьютером (:Computer), а также соответствующими клиентом (:Customer) и платежом :Payment. • После того, как эти объекты постоянно связаны в базе данных, объект :Order отправляет электронное сообщение emailOrder внешнему субъекту-клиенту (Customer). • Обратите внимание на двойное использование сущности :Customer — в качестве внешнего субъекта, представленного объектом, и внутреннего объекта-класса. Подобная двойственность довольно часто встречается в моделировании. Клиент (Customer) является по отношению к системе одновременно и внешней, и внутренней сущностью. Он представляет собой внешнюю сущность, поскольку взаимодействует с системой извне. Однако информация о клиенте должна храниться в системе, чтобы иметь возможность установить идентичность внешнего клиента и внутренней сущности, о которой знает система.

38. Моделирование состояний • Фиксирует динамику изменения состояния классов – возможные состояния класса - жизненный путь класса • Эти изменения описывают поведение объектов в рамках нескольких прецедентов • Состояние (state) объекта– обозначается текущими значениями атрибутов объекта • Модель состояний (Statechart Diagram) – двудольный граф • Состояний (states) (прям-к с закр. углами) и • Переходов (transitions) (стрелок) вызваных событиями (events) • Концепция состояний и событий совпадает с концепцией, которая известна по диаграмме деятельности. Различие же заключается в том, что "состояния графа видов деятельности представляют состояния выполнения вычисления, а не состояния обычного объекта"

39. Состояния и переходы • Значения атрибутов объекта изменяются, однако не все подобные изменения вызывают переход между состояниями • Модель состояний создается только для интересных изменений состояний объекта с точки зрения предметной области, а не для любого изменения • Модель состояний– модель бизнес правил • Бизнес правила– неизменны в течение некоторого периода времени • Они относительно независимы от отдельных прецедентов

40. partial payment Unpaid Partly Paid final payment final payment Fully Paid Состояния и события

41. Диаграмма состояний • Обычно присоединяется к классу, но может присоединяться и к другим модельным представлениям, например, прецедентам • Когда присоединяется к классу, диаграмма определяет как объекты класса реагирует на события • Определяет – для каждого состояния объекта – какое действие (action)объект будет выполнять, когда получает событие • Один и тот же объект может выполнять различные действия для одних и тех же событий в зависимости от состояния объекта • Выполнение действия будет обычно вызывать изменение состояния

42. Диаграмма состояний (прод.) • Источник детализированного описания прецедента, и полное описание перехода состоит их трех необязательных частей event (parameters) [guard] / action • Event - явление, воздействующее на объект, возможна проверка срабатывания события • Action – короткое атомическое вычисление, которое выполняется при срабатывании перехода • Действие может также связано с состоянием • Activity – более продолжительное вычисление, связанное с состоянием

43. Statechart Diagram (cont.) Состояние может состоять из других состояний, которые называются вложенными.