Моделирование объектов Интернет-магазин. Т ЕМЫ 2 Интернет-магазин – Постановка задачи Use Case моделирование Моделирование деятельности Моделирование. - презентация

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

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

3 И НТЕРНЕТ - МАГАЗИН – П ОРЯДОК ОБРАБОТКИ Покупка компьютера через Интернет Компьютеры классифицируются на серверы, рабочие станции и ноутбуки Клиент может выбрать стандартную конфигурацию или построить заказную он-лайн Для размещения заказа клиент должен заполнить информацию о поставке и оплате (методы оплаты кредитной картой наличными) После ввода заказа система отправляет клиенту сообщение о конфигурации по электронной почте со спецификацией заказа 3

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

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

6 Р АСШИРЕННЫЕ ТРЕБОВАНИЯ ( СЦЕНАРИЙ ) Клиент использует веб-страницу интернет магазина производителя для просмотра стандартной конфигурации выбранного сервера, рабочей станции или ноутбука. Также представляется цена. Клиент выбирает просмотр конфигурации с намерением приобрести ее в таком виде либо построить более подходящую конфигурацию. Цена для каждой конфигурации может вычисляться по запросу клиента. Клиент может выбрать компьютер для заказа он-лайн или обратиться к продавцу с просьбой объяснить ему детали заказа, обсудить цену и т.п. прежде чем заказ будет действительно размещен. Для размещения заказа клиент должен заполнить он- лайн форму с адресом доставки и оплаты, а также способом оплаты (кредитная карта или наличные). 6

7 Р АСШИРЕННЫЕ ТРЕБОВАНИЯ ( ПРОД.) После ввода клиентом заказа в систему, продавец посылает электронный запрос на склад со спецификацией заказанной конфигурации. Подробности транзакции, содержащие номер заказа и номер счета клиента отправляются по электронной почте клиенту, чтобы клиент мог проверить статус заказа он-лайн. Склад получает заказ от продавца и отправляет компьютер клиенту. 7

8 А КТОРЫ Акторы и прецеденты определяются на основе описания требований: После ввода клиентом заказа в систему, продавец посылает электронный запрос на склад со спецификацией заказанной конфигурации 8 CustomerSalepersonWarehouse

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

10 U SE C ASE ДИАГРАММА 10 Display Standard Computer Configuration Build Computer Configuration Verify and Accept Customer Payment Customer Order Configured Computer Request Salesperson Contact > Inform Warehouse about Order Warehouse Print Invoice Salesperson Update Order Status Связь > - прецедент Order Configured Computer может быть расширен Customer с прецедентом Request Salesperson Contact

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

12 О ПИСАНИЕ СПЕЦИФИКАЦИИ ПРЕЦЕДЕНТА 12 Use CaseЗаказ компьютера Brief Description Краткое описание Этот прецедент позволяет Customer ввести заказ покупки … Actors Customer PreconditionsСтраница отображает подробности конфигурации компьютера с его ценой … Main Flow Основной поток Система назначает номер заказа и номер счета клиента для покупки заказа и он хранится в информации о заказах в базе данных. … Alternative Flows Альтернативный поток Customer инициирует функцию Purchase до введения всей необходимой информации. При нажатии Reset сисиема позволяет ввести информацию вновь Postconditions Постстусловия Если прецедент был успешным, заказ на покупку записывается в базу данных.

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

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

15 У СТАНОВЛЕНИЕ ОПЕРАЦИЙ В ОСНОВНОМ И АЛЬТЕРНАТИВНЫХ ПОТОКАХ 15 NФормулировки прецедента Состояние вида деятельности 1 Начало прецедента - решение клиента Заказать компьютер с помощью выбора функции Continue (или аналогичной функции) при отображении на экране подробной информации, относящейся к заказу Display Current Configuration; Get Order Request 2 Система просит клиента ввести детализированную информацию о покупке, в том числе: имя продавца (если оно известно); детали, касающиеся доставки (имя и адрес клиента); детальную информацию по оплате (если она отличается от информации по доставке); способ оплаты (кредитная карточка или чек) и произвольные комментарии Display Purchase Form 3Клиент выбирает функцию Purchase (или аналогичную функцию) для отправки заказа производителю. Get Purchase Details 4 Система присваивает уникальный номер заказа и клиентский учетный номер заказу на покупку и запоминает информацию о заказе в базе данных Store Order 5 Система отправляет клиенту по электронной почте номер заказа и клиентский номер клиенту вместе со всеми деталями, относящимися к заказу, в качестве подтверждения принятия заказа Order Details 6 Клиент инициирует функцию Purchase до того, как введет всю обязательную информацию. Система отображает на экране сообщение об ошибке и просит ввести пропущенную информацию. Get Purchase Details; Display Purchase Form 7 Клиент выбирает функцию Reset (или аналогичную) для того, чтобы вернуться к исходной форме заказа на покупку. Система дает возможность клиенту вновь ввести информацию Display Purchase Form

16 В ИДЫ ДЕЯТЕЛЬНОСТИ Система присваивает уникальный номер заказа и клиентский учетный номер заказу на покупку и запоминает информацию о заказе в базе данных. 16

17 Д ИАГРАММА ВИДА ДЕЯТЕЛЬНОСТИ Диаграмма видов деятельности (Activity Diagram) показывает переходы между видами деятельности Закрашенная окружность представляет начальное состояние ( initial state) Конечное состояние ( final state) показывается в виде окружности с закрашенной центральной частью (бычий глаз) Переходы могут разветвляться по условию ( branch) и объединяться ( merge) (ромб-условие ветвления) – альтернативные вычислительные потоки Переходы могут разделяться ( fork) и сливаться (re- join) (bar line) –в результате образуются параллельные ( concurrent) вычислительные потоки ( threads) Диаграмма вида деятельности без параллельных процессов похожа на обычную блок-схему (flowchart) 17

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

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

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

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

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

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

24 А ТРИБУТЫ 24 На практике основные атрибуты назначаются классу сразу после его добавления к модели

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

26 А ГРЕГАЦИИ 26

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

28 Д ИАГРАММА КЛАССОВ 28 Диаграмма классов составляет, так сказать, сердце и душу объектно - ориентированной системы. В данном наставлении ставится цель только продемонстрировать возможности статического моделирования применительно к модели классов. В классы пока что не введено ни одной новой операции. Операции принадлежат скорее к этапу проектирования, чем анализа.

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

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

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

32 В ЗАИМОДЕЙСТВИЯ ( CONT.) 32

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

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

35 Д ИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ З АКАЗ КОНФИГУРИРОВАННОГО КОМПЬЮТЕРА 35 линии жизни объектов Order и OrderWindow разделены на две части

36 Д ИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙ ( ПРОД.) 36

37 К ОММЕНТАРИИ К ПРЕДЫДУЩИМ СЛАЙДАМ Пояснения к первым двум сообщением были сделаны на слайде 31. Сообщение acceptConf вызывает отправку сообщения prepareForOrder объекту :Order. Это приводит к созданию временного объекта :Order, отображаемого в объектеокне :OrderWindow. В ответ на принятие клиентом детализированных условий заказа (submitOrder) объект :OrderWindow инициирует (storeOrder) создание постоянного объекта :Order. После этого объектзаказ :Order устанавливает связь с заказанным компьютером (:Computer), а также соответствующими клиентом (:Customer) и платежом :Payment. После того, как эти объекты постоянно связаны в базе данных, объект :Order отправляет электронное сообщение Order внешнему субъекту- клиенту (Customer). Обратите внимание на двойное использование сущности :Customer в качестве внешнего субъекта, представленного объектом, и внутреннего объекта-класса. Подобная двойственность довольно часто встречается в моделировании. Клиент (Customer) является по отношению к системе одновременно и внешней, и внутренней сущностью. Он представляет собой внешнюю сущность, поскольку взаимодействует с системой извне. Однако информация о клиенте должна храниться в системе, чтобы иметь возможность установить идентичность внешнего клиента и внутренней сущности, о которой знает система. 37

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

39 С ОСТОЯНИЯ И ПЕРЕХОДЫ Значения атрибутов объекта изменяются, однако не все подобные изменения вызывают переход между состояниями Модель состояний создается только для интересных изменений состояний объекта с точки зрения предметной области, а не для любого изменения Модель состояний – модель бизнес правил Бизнес правила– неизменны в течение некоторого периода времени Они относительно независимы от отдельных прецедентов 39

40 С ОСТОЯНИЯ И СОБЫТИЯ 40 UnpaidPartly Paid Fully Paid partial payment final payment

41 Д ИАГРАММА СОСТОЯНИЙ Обычно присоединяется к классу, но может присоединяться и к другим модельным представлениям, например, прецедентам Когда присоединяется к классу, диаграмма определяет как объекты класса реагирует на события Определяет – для каждого состояния объекта – какое действие ( action) объект будет выполнять, когда получает событие Один и тот же объект может выполнять различные действия для одних и тех же событий в зависимости от состояния объекта Выполнение действия будет обычно вызывать изменение состояния 41

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

43 S TATECHART D IAGRAM ( CONT.) 43 Состояние может состоять из других состояний, которые называются вложенными.