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

ТЕМЫ

2

Интернет-магазин – Постановка задачи

Use Case моделирование

Моделирование деятельности

Моделирование классов

Моделирование взаимодействия

Моделирование состояний

ИНТЕРНЕТ-МАГАЗИН– ПОРЯДОК ОБРАБОТКИ

Покупка компьютера через Интернет

Компьютеры классифицируются на серверы, рабочие станции и ноутбуки

Клиент может выбрать стандартную конфигурацию или построить заказную он-лайн

Для размещения заказа клиент должен заполнить информацию о поставке и оплате (методы оплаты кредитной картой наличными)

После ввода заказа система отправляет клиенту сообщение о конфигурации по электронной почте со спецификацией заказа

3

ИНТЕРНЕТ-МАГАЗИН(ПРОД.)Клиент в любое время может проверить состояние заказа

Обработка заказа на сервере состоит необходимости выполнения следующих шагов

Проверка полномочий и метода оплаты,

Запросить заказанную конфигурацию со склада,

Распечатать счет и запрос, и

Запросить склад отправить компьютер клиенту

Заказанная конфигурация отправляется клиенту со счетом

4

МОДЕЛИРОВАНИЕ ПРЕЦЕДЕНТОВ

Поведение системы что делает система в ответ на внешние события

Прецедент (Use case) – внешне заметное и проверяемое поведение системы

Актор (Actor) – кто-либо или что-либо (субъект, машина, и т.п.) взаимодействующее с вариантом использования

Актор получает полезный результат

Прецедент представляет единицу полезной функциональности для актора

Могут быть некоторые прецеденты, которые не взаимодействуют с актором

В многих случаях функциональное требование отображается непосредственно на прецедент

Use Case Diagram визуальное представление акторов и прецедентов вместе с дополнительными формулировками и спецификациями

5

РАСШИРЕННЫЕ ТРЕБОВАНИЯ(СЦЕНАРИЙ)

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

6

РАСШИРЕННЫЕ ТРЕБОВАНИЯ (ПРОД.)

После ввода клиентом заказа в систему , продавец посылает электронный запрос на склад со спецификацией заказанной конфигурации.

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

Склад получает заказ от продавца и отправляет компьютер клиенту.

7

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

8

Customer Saleperson Warehouse

ПРЕЦЕДЕНТЫКлиент использует веб-страницу интернет магазина производителя для просмотра стандартной конфигурации выбранного сервера, рабочей станции или ноутбука. Клиент выбирает просмотр конфигурации с намерением приобрести ее в таком виде либо построить более подходящую конфигурацию.

9

Display StandardComputer Configuration

Build ComputerConfiguration

Order ConfiguredComputer

Verify and AcceptCustomer Payment

Print InvoiceUpdate Order Status

RequestSalesperson Contact

Inform Warehouseabout Order

9

USE CASE ДИАГРАММА

10

Display StandardComputer Configuration

Build ComputerConfiguration

Verify and AcceptCustomer Payment Customer

Order ConfiguredComputer

RequestSalesperson Contact

<<extend>>

Inform Warehouseabout OrderWarehouse

Print Invoice

Salesperson

Update Order Status

Связь<<extend>> - прецедент Order Configured Computer может быть расширен Customer с прецедентом Request Salesperson Contact

ДОКУМЕНТИРОВАНИЕ ПРЕЦЕДЕНТОВ

Краткое описание

Участвующие Actors

Предусловия необходимы для запуска прецедента

Подробное описание потока событий включает:

Основной поток событий, который может быть разбит, чтобы показать:

Подпотоки событий (подпотоки могут быть в дальнейшем разделены на более мелкие для улучшения понятности документа)

Альтернативные потоки для определения исключительных ситуаций

Постусловия которые определяют состояние системы после завершения прецедента

11

ОПИСАНИЕ СПЕЦИФИКАЦИИ ПРЕЦЕДЕНТА

12

Use Case Заказ компьютера

Brief Description

Краткое описание

Этот прецедент позволяет Customer ввести заказ покупки …

Actors Customer

Preconditions Страница отображает подробности конфигурации компьютера с его ценой …

Main FlowОсновной поток

Система назначает номер заказа и номер счета клиента для покупки заказа и он хранится в информации о заказах в базе данных. …

Alternative FlowsАльтернативный поток

Customer инициирует функцию Purchase до введения всей необходимой информации. При нажатии Reset сисиема позволяет ввести информацию вновь

PostconditionsПостстусловия

Если прецедент был успешным, заказ на покупку записывается в базу данных.

МОДЕЛИРОВАНИЕ ВИДОВ ДЕЯТЕЛЬНОСТИ

Модель видов деятельности Может графически представлять поток событий для прецедентаМожет использоваться для понимания шагов выполнения бизнес-процесса на высоком уровне абстракции перед созданием прецедента (до моделирования взаимодействия: диаграммы последовательности и кооперации)

Показывает шаги вычисленийКаждый шаг соответствует состоянию (state) в котором что-нибудь выполняетсяШаг выполнения называется состоянием вида деятельности (activity states)Изображает какие шаги выполняются последовательно, а какие параллельно yПереход (transition) – передача управления из одного состояния в другое

Описания прецедента (Use case descriptions) обычно создаетсяс точки зрения внешнего субъектаМодели видов деятельности (Activity models) отражают внутрисистемную точку зрения

13

ВИДЫ ДЕЯТЕЛЬНОСТИ

Состояния видов деятельности (Activity states) могут быть установлены на основе описания прецедентов

Виды деятельности (Activities) должны быть поименованы с точки зрения системы, а не с точки зрения субъекта

Вид деятельности (Activity) требует время для выполнения

Действие (Action) завершается так быстро– в масштабах временной шкалы– может считаться происходящим мгновенно

UML использует один графический символ для состояния вида деятельности (activity state) и состояния действия (action state) – прямоугольник с закругленными углами

14

УСТАНОВЛЕНИЕ ОПЕРАЦИЙ В ОСНОВНОМ И АЛЬТЕРНАТИВНЫХ ПОТОКАХ

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

Display Current Configuration

Get Order Request

Display Purchase Form

Get Purchase Details

Store Order Email Order Details

ДИАГРАММА ВИДА ДЕЯТЕЛЬНОСТИ

Диаграмма видов деятельности (Activity Diagram) показывает переходы между видами деятельности

Закрашенная окружность представляет начальное состояние (initial state)

Конечное состояние (final state) показывается в виде окружности с закрашенной центральной частью (бычий глаз)

Переходы могут разветвляться по условию (branch) и объединяться (merge) (ромб-условие ветвления) – альтернативные вычислительные потоки

Переходы могут разделяться (fork) и сливаться (re-join) (bar line) –в результате образуются параллельные (concurrent) вычислительные потоки (threads)

Диаграмма вида деятельности без параллельных процессов похожа на обычную блок-схему (flowchart)

17

ACTIVITY DIAGRAM

18

Display Current Configuration

Get Order Request

Display Purchase Form

Get Purchase Details

Store Order

Email Order Details

[ timeout ]

[ incomplete ]

[ OK ]

Множество выходных состояний (условия перехода внутренние по отношению к состоянию вида деятельности

Явное условие ветвления (которое появляется на выходной форме состояния вида деятельности)

МОДЕЛИРОВАНИЕ КЛАССОВ

Систему образует системное состояние (system state) – функция системной информации в заданный момент времениЭлементы моделирования классов:

Сами классыАтрибуты и операции классовСвязи– ассоциации, агрегации и композиции, обобщения

Диаграмма классов (Class Diagram) – дает обобщенное визуальное представление для всех элементов моделиМоделирование классов и прецедентов обычно выполняются параллельно

19

КЛАССЫ

До сих пор классы рассматривались, чтобы определять бизнес-объекты, характеризующие сущность ИС

Называются классы-сущности (entity classes) (model classes)

Представляют постоянно хранимые объекты базы данных

Другие классыКлассы, которые определяют объекты GUI (sтакие как экранные формы) – граничные классы (boundary classes) (классы представления - view classes)

Классы, которые управляют программную логику – управляющие классы (control classes)

Граничные и управляющие классы могут или не могут рассматриваться на этапе анализа требований – могут быть отложены до этапа проектирования системы.

20

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

21

КЛАССЫ (ПРОД.)

Что является классом?

Является ли понятие «вместилищем» данных?

Обладает ли оно отдельными атрибутами,

которые принимают различные значения?

Можно ли создать для него множество

объектов-экземпляров?

Входит ли оно в границы прикладной области? 22

КЛАССЫ(ПРОД.)• Склад получает счет-фактуру (Invoice) от

продавца (Salesperson) и отправляет компьютер клиенту (Customer)

23

Customer(from Use Case View)

Computer

ConfiguredComputer

Order InvoicePayment

ConfigurationItem

Salesperson класс или атрибут классов Order и Invoice?

Необходим ли класс Shipment? Входит ли он в систему?

АТРИБУТЫ

24

Customer

customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String

(from Use Case View)

Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String

Paymentpayment_method : Stringdate_received : Dateamount_received : Currency

Invoiceinvoice_number : Stringinvoice_date : Dateinvoice_total : Currency

ConfiguredComputercomputer_name : Stringconfigured_price : Currency

Computercomputer_name : Stringstandard_price : Currency

ConfigurationItemitem_type : Stringitem_descr : StringНа практике

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

АССОЦИАЦИИ

25

Computer

ConfigurationItem

Customer(from Use Case View)

ConfiguredComputerPayment Invoice

Order

0..*1..1

0..*1..1

1..*

0..*

1..*

0..*1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

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

АГРЕГАЦИИ

26

Customer(from Use Case View)

Payment Invoice

Order

0..*1..1

0..*1..1

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

ConfiguredComputer

1..*

0..*

1..*

0..*ConfigurationItem

1..*1..*

Computer

1..*1..*

ОБОБЩЕНИЯ

27ConfiguredComputer StandardComputer

Customer(from Use Case View)

Payment Invoice

ConfigurationItem

Computer

1..*1..*

Order

0..*1..1

0..*1..1

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

1..*0..* 1..*0..*

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

ДИАГРАММА КЛАССОВ

28

ConfiguredComputerconfigured_price : Currency

StandardComputerstandard_price : Currency

Customer

customer_name : Stringcustomer_address : Stringphone_number : Stringemail_address : String

(from Use Case View)

Paymentpayment_method : Stringdate_received : Dateamount_received : Currency

Invoiceinvoice_number : Stringinvoice_date : Dateinvoice_total : Currency

ConfigurationItemitem_type : Stringitem_descr : String

Computer

computer_name : String

1..*1..*

Orderorder_number : Stringorder_date : Dateship_address : Stringorder_total : Currencyorder_status : Stringsalesperson_name : String

0..*

1..1

0..*

1..1

1..1

1..1

1..1

1..1

0..1

1..1

0..1

1..*0..* 1..*0..*

1..1

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

МОДЕЛИРОВАНИЕ ВЗАИМОДЕЙСТВИЙ

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

Диаграммы последовательностей (Sequence Diagram) – концентрируются на временных последовательностяхДиаграммы кооперации (Collaboration Diagram) – внимание уделяется отношениям между объектами

В практике разработки ИС – диаграммы последовательностей используются на этапе анализа требований, а диаграммы кооперации - системного проектирования

29

ВЗАИМОДЕЙСТВИЯВзаимодействие (Interaction) – набор сообщений, свойственных поведению некоторой системы, которыми обмениваются объекты в соответствии с установленными между ними связямиДиаграммы последовательности

Объекты располагаются по горизонтали Последовательности сообщений располагаются сверху вниз по вертикали Каждая вертикальная линия называется линией жизни (lifeline) объекта Стрелки представляют каждое сообщение, направляемое от вызывающего объекта (отправителя) к операции (методу) вызываемого объекта (получателя). Фактические параметры могут быть

входными аргументами (передаются от отправителя к получателю) выходными аргументами (передаются от получателя назад к отправителю).

crs_ref.getCourseName(out crs_name)Показывать возврат return не обязательноИтеративный маркер - звездочка перед обозначением сообщения - указывает на процесс итерации сообщения по всей коллекции 30

ВЗАИМОДЕЙСТВИЯ(ПРОД.)

31

: Customer

aConfWin : ConfigurationWindow

aComp : Computer

: ConfigurationItem

openNewgetConf

* getConfItem (out item_rec)

displayComputer(item_recset)

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

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

32

ОПЕРАЦИИИсследование взаимодействий между классами приводит к выявлению операций

Каждое сообщение(message) вызывает

операцию в вызываемом объекте

Имена операция и сообщения совпадаютАналогично, наличие сообщения в диаграмме последовательностей обусловливает необходимость ассоциации в диаграмме классов

33

ОПЕРАЦИИ (ПРОД.)

34

ConfigurationWindow

<<constructor>> openNew()displayComputer(item_recset)

<<boundary>>

Computer

computer_name : String

<<abstract>> getConf()

ConfigurationItem

item_type : Stringitem_descr : String

getConfItem(out item_rec)

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

ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТЕЙЗАКАЗ КОНФИГУРИРОВАННОГО КОМПЬЮТЕРА

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

СОСТОЯНИЯ И СОБЫТИЯ

40

Unpaid Partly Paid

Fully Paid

partial payment

final paymentfinal payment

ДИАГРАММА СОСТОЯНИЙ

Обычно присоединяется к классу, но может присоединяться и к другим модельным представлениям, например, прецедентамКогда присоединяется к классу, диаграмма определяет как объекты класса реагирует на события

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

41

ДИАГРАММА СОСТОЯНИЙ (ПРОД.)

Источник детализированного описания прецедента, и полное описание перехода состоит их трех необязательных частей

event (parameters) [guard] / action

Event - явление, воздействующее на объект, возможна проверка срабатывания события

Action – короткое атомическое вычисление, которое выполняется при срабатывании перехода

Действие может также связано с состоянием

Activity – более продолжительное вычисление, связанное с состоянием

42

STATECHART DIAGRAM (CONT.)

43

Pending

Future Order

New Order Back Order

Filled

Future Order

Ready to Ship

New Order Back Order

Cancelled

stock not available

stock available[ ship date in future ]

stock available[ ship date in future ]

stock available[ ship date now ] / configureComputer[ canceled ]

ship[ accepted ]

[ canceled ]

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