Глава 4 - Описание SUT, драйвера и сети   

 
  СОДЕРЖАНИЕ:

4.1 Общее описание
4.2 Описание Драйвера и Тестируемой системы (System Under Test (SUT))
4.3 Примеры реализаций Тестовых конфигураций
4.4 Дополнительные требования к реализациям SUT и Драйвера



4.1 Общее описание

TPC-E является упрощенной моделью абстрагированной реальной OLTP среды. Для того чтобы понять, что тестируется TPC-E, и что, соответственно, не тестируется, необходимо понять основы реальной среды (Глава 4.1.1 Описание Реальной OLTP Среды), абстракцию этой базовой среды (Глава 4.1.2 Абстракция функциональных компонент реальной OLTP Среды) и упрощенную модель этой абстракции (Глава 4.1.3 Упрощенная модель функциональных компонент в Тестировании TPC-E).

4.1.1 Описание реальной OLTP среды.
Рисунок ниже отображает реальную среду, на которой основан тест TPC-E is based. Пользователи связаны с брокерской фирмой при помощи сети, используя мириады возможных сетевых устройств (например ПК или КПК). Брокерская фирма также способна при помощи сети подключаться ко внешним организациям (например, бирже).


                             Рисунок 4.a – Диаграмма реальной OLTP среды.

4.1.2    Функциональные компоненты абстракции реальной OLTP среды.
Исходя из диаграммы реальной среды OLTP может быть абстрагирована следующая диаграмма ключевых функциональных компонент.


                              Рисунок 4.b – Абстрагирование функциональных компонент в OLTP среде.

Пользователь использует некоторые устройства для подключения посредством сети к представительским службам бизнес процессов. Уровень представительских служб, как принято в среде отношений Клиент-Бизнес, является для пользователя способом осуществлять навигацию по доступным службам, выбирать желаемые операции, вводить данные и читать результаты. Примерном этого на практике может служить то, как клиент, используя домашний ПК, подключается к сайту компании для ведения дел.
Брокерская фирма аналогично соединилась бы через сеть с внешним бизнесом, таким как биржа. Для среды корпоративных клиентов не требуются представительские службы. Скорее, информацией можно обменяться непосредственно без потребности в удобном для чтения человеком формате.
Независимо от того, как данные достигают брокерской фирмы, они, в конечном счете, проходят через функции управления торгами, где происходит мультиплексирование/демультиплексирование подключений; здесь также может быть выполнена маршрутизация, равно как и другие возможные функции. Уровень управления транзакциями гарантирует, что данные будут поставлены верной бизнес логике кода, который может выполнить требуемую задачу.

В бизнес логике критический шаг происходит тогда, когда данные передаются некоторой функции или реализации метода для обработки базы данных. Эта реализация метода будет включать код Интерфейса Базы данных для того, чтобы собрать соответствующие данные и передать их в схему приложения базы данных (например, сохранённая процедура SQL) запущенная в контексте системы управления базой данных. Логика приложения базы данных будет использовать службы системы управления для того, чтобы выполнить необходимые задачи, и результаты в конечном счете будут возвращены назад.

4.1.3 Упрощение функциональных компонент в среде TPC-E
По умолчанию, центральным элементом TPC-E является база данных. Поэтому, даже при том, что Службы Представления – это важная часть законченного решения Клиент - Бизнес, они были дистиллированы из рабочей нагрузки TPC-E. На практике, Службы Представления часто масштабируют таким образом, чтобы Организатор формировал (имитировал) достаточно серверов, чтобы обеспечивать выполнение Служб Представления, таким образом они не являются ограничивающим фактором для тестирования. Таким образом, чтобы сосредоточиться на проведении оценок и облегчении тестирования, Службы Представления не являются функциональным компонентом в тестируемой конфигурации.
В контексте диаграммы функциональных компонентов модели целевой системы, роль Клиента заключается в принятии решения и предоставлении данных (т.е. решает, что делает транзакция, и снабжает эту транзакцию необходимыми входными данными). Однако, отсутствие Служб Представления в TPC-E приводит к некоторым упрощениям в эмуляции тестовой конфигурации Пользователя. Характеристики принятия решения и ввода данных Пользователем все еще являются существенными, но такие параметры, как скорость печати и время обдумывания не имеют значения.
Задачами Устройства пользовательского Интерфейса (User Interface Device (UID)) являются принятие входных данных от Пользователя и отправка этих данных в Службы Представление, а также принятия выходных данных от Служб Представления и предоставление этих данных Пользователю. Однако TPC-E не устанавливает требований к способам отображения данных (поскольку не существует Службы представления). Следовательно не существует неоходимости в преобразованию входных и выходных данных в формат отображения. К примеру, нет необходимости в отправке и получении полностью сформированных HTML страниц по протоколу HTTP; входные и выходные данные транзакций могут быть представлены в двоичном формате.
Опираясь на вышеизложенное и на диаграмму функциональных компонент целевой моделируемой системы, можно построить диаграмму функциональных компонент тестовой конфигурации. Необходимо заметить, что реализация этих функциональных компонент подразумевает оборудование и программное обеспечение.


                      
                       Рисунок 4.c – Функциональные компоненты Тестовой конфигурации.

4.1.3.1 Управление и отчеты – Организатор предоставляет функционал для подготовки, управления и выполнения Теста, сбора данных и создания сводных отчетов. Код, написанный Организатором, должен осуществлять вызовы EGenDriver через Интерфейс, определенный TPC.
4.1.3.2 CE – Организатор предоставляет функционал для подготовки, управления и выполнения Эмулятора клиента. Код, написанный Организатором, должен осуществлять вызовы EGenDriverCE.
4.1.3.3 MEE – Организатор предоставляет функционал для подготовки, управления и выполнения Эмулятора Фондовой биржи. Код, написанный Организатором, должен осуществлять вызовы EGenDriverMEE.
4.1.3.4 DM – Организатор предоставляет функционал для подготовки, управления и выполнения Транзакции Data-Maintenance один раз каждую минуту. Организатор может также предоставить функционал для вызова Транзакции Trade-Cleanup единожды перед запуском выполнения теста (см. описание EGenDriverDM ниже). Код, написанный Организатором, должен осуществлять вызовы EGenDriverDM.
Интерфейс, определенный TPC – это член класса С++, спроектированный для обмена данными (и передачи контроля выполнения) между кодом Драйвер/SUT, предоставляемым Организатором, и кодом Драйвер/SUT, предоставляемым TPC.

4.1.3.5 В таблице, приведенной в приложении A.14 перечислены Интерфейсы, определенные TPC, и соответствующие классы C++ и функции членов.

4.1.3.6 EGenDriver – исходный код на языке С++, предоставленный TPC, который реализует базовый функционал во время Выполнения Теста. Использование EGenDriver является обязательным. Ниже перечислены части EGenDriver.
  •  EGenDriverCE – Эмулятор клиента, который предоставляет необходимое сочетание транзакций и генерацию данных, вводимых пользователем.
  •  EGenDriverMEE – Эмулятор фондовой биржи, которые предоставляет функционал рынка ценных бумаг и генерации данных.
  •  EGenDriverDM – функционал обслуживания данных, который вызывает Транзакцию Data-Maintenance и создает для нее данные. Также он поддерживает интерфейс, который может быть использован Организатором для вызова Транзакции Trade-Cleanup.
4.1.3.7 EGenDriver Connector – Функционал, предоставленный Организатором, который сочетается с Интерфейсом, предоставленным TPC. EGenDriver Connector вызывается из EGenDriver через интерфейс. EGenDriver Connector предназначен для отправки и получения созданных EGenDriver и соответствующих результирующих данных в (и из, соответственно) EGenTxnHarness Connector посредством Сети. Примером оборудования и программного обеспечения, необходимого для реализации Connector, является:
  •  Код, написанный Организатором
  •  Операционная система, которая предоставляет API сокетов и нижележающий функционал
  •  Оборудование, на котором работает Операционная система, и сетевая карта, необходимая для подключения к Сети (сетевой кабель, идущий из сетевой карты для подключения его к Сети будет считаться не частью Коннектора, а частью Сети)
4.1.3.8 Сеть – предоставляемые Организатором средства, которые должны поддерживать связь при помощи стандартных протоколов коммуникации с использованием физических средств. Одним из выдающихся свойств связи Коннектор – Сеть – Коннектор является то, что она следует важным стандартам и должна отображать более чем просто прикладные пакеты. Должно быть возможно одновременное использование этих средств другими приложениями. Требуется физическая передача данных, и нижележащие средства этих способов передачи должны обеспечивать связь на случайных глобально распределенных географических дистанциях. Использование протокола TCP/IP в локальной вычислительной сети является примером приемлемой реализации Сети.
4.1.3.9 EGenTxnHarness Connector – функционал, предоставляемый Организатором, необходимый для получения данных из, и отправки соответствующих результирующих данных назад в, EGenDriver Connector посредством Сети. EGenTxnHarness Connector предоставляет и получает данные в и из EGenTxnHarness посредством вызова Интерфейса, определенного TPC. Пример реализации EGenDriver Connector также применим и для этого случая.
4.1.3.10 EGenTxnHarness – Исходный код на языке С++, предоставленный TPC, который реализует необходимый базовый функционал во время Выполнения Теста. EGenTxnHarness осуществляет вызовы реализованных Организатором Фреймов Транзакций, предоставляя необходимые входные данные и принимая необходимые выводы через Интерфейс, определенный TPC. Использование EGenTxnHarness является обязательным.
4.1.3.11 Реализация Фреймов – средства, предоставляемые Организатором, принимающие входные данные и предоставляющие выходные данные в EGenTxnHarness через Интерфейс, определенный TPC. Реализация Фрейма и все нижележащие функциональные компоненты отвечают за предоставление соответствующего функционала, описанного в Профилях Транзакций (Пункт 3.3).
4.1.3.12 Интерфейс Базы данных – коммерчески доступный продукт, используемый Реализацией Фрейма для связи с Сервером Базы данных. Связь Интерфейса Базы данных с Сервером Базы данных может осуществляться с использованием информационной сети, но это не является необходимостью.
4.1.3.13 Сервер базы данных — коммерчески доступный продукт. В контексте Сервера базы данных может использоваться логика, предоставляемая Организатором (к примеру, хранимые SQL процедуры). Примером Сервера базы данных являются:
  •  Коммерчески доступная СУБД, работающая на
  •  Коммерчески доступной Операционной Системе, работающей на
  •  коммерчески доступном оборудовании, использующем
  •  коммерчески доступное хранилище данных.

4.1.3.14 Логика базы данных – логика Реализации Фрейма, написанная Организатором (например, хранимые SQL процедуры).

Примечание: Для реализаций EGenDriver Connector и EGenTxnHarness Connector допустимо внесение изменений в формат данных, предоставляемых им, в том и только том случае, если: такие изменения внесены для поддержания меняющихся характеристик нижележащих механизмов передачи данных. К примеру, для передачи данных из с машины одного типа на машину диаметрально противоположного типа, или из среды ASCII в среду EBCDIC потребуется изменение формата данных.


4.2 Описание Драйвера и Тестируемой системы (System Under Test (SUT))


Диаграмма функциональных компонент Тестируемой Системы может быть дополнена для представления графического описания Драйвера, SUT, Уровня А и Уровня В.


              Рисунок 4.d – Описанные компоненты Тестируемой конфигурации.

4.2.1 Драйвер – это все оборудование и программное обеспечение, необходимое для того, чтобы реализовать Управление и создание отчетов, EGenDriver и вышележащие функциональные компоненты Connector.
4.2.2 Использование сети (как описано в Пункте 4.1.3) между Драйвером и Уровнем А является обязательным.
4.2.3 Уровень A – представляет собой все оборудование и программное обеспечение, необходимое для реализации всех составляющих функциональных компонент Connector, EGenTxnHarness, Реализация Фрейма и Интерфейс базы данных.
4.2.4 Уровень B – представляет собой все оборудование и программное обеспечение, необходимое для реализации функциональных компонент Сервера баз данных. Это понятие включает носитель для хранения данных, удовлетворяющий потребностям выполнения требований к начальному наполнению базы данных, указанных в Пункте 2.6.1 и требованиям роста Рабочего дня, установленным в Главах 6.6.6.3 и 6.6.6.4.
4.2.5 Тестируемая система (System Under Test (SUT)) является объединением Уровня А и Уровня B.

Примечание: Для Драйвера, Уровня А и Уровня В допустимо иметь общие ресурсы реализации. К примеру, программная часть реализации Драйвера и программная часть Уровня А могут выполняться на одном и том же оборудовании..



4.3 Примеры реализаций Тестовых конфигураций.

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


                        Рисунок 4.e – Пример компонент Физической составляющей конфигурации теста.

4.3.2
На следующих изображениях показаны несколько допустимых вариаций представленной выше конфигурации и несколько допустимых путей для использования общих ресурсов Драйвером, Уровнем А и Уровнем В.



                         Рисунок 4.f – Отделенный Драйвер с объединенными Уровнями А и В.


                                Рисунок 4.g – Драйвер и Уровень А объединены, Уровень В отделен.


                                   Рисунок 4.h – Объединенные Драйвер, Уровень А и Уровень В.


4.4 Дополнительные требования к реализацям SUT и Драйвера.

4.4.1 Ограничения, накладываемые на Драйвер.

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

4.4.1.1 Во время Выполнения теста код, написанный Организатором для реализации Драйвера не должен:
  •  принимать решения, основываясь на содержимом базы данных (включая EGenInputFiles)
  •  предоставлять информацию в SUT, которая приводит к увеличению производительности.
4.4.1.2 В случае использования разделения клиентов в EGenDriverCE, конфигурация должна удовлетворять требованиям Пункта 6.4.2.

4.4.1.3 Правило закрытого пакета: маршрутизация данных, основанная на содержимом пакета в in EGenDriver Connector или EGenTxnHarness Connector не допустима.

4.4.1.4 Код, написанный Организатором и выполняемый между EGenDriver (т.е. следующими API: CESUTInterface, MEESUTInterface, DMSUTInterface) и требуемой Сетью, не может принимать каких либо решений, относящихся к маршрутизации, управлении временем и порядком или этапам выполнения этой Транзакции или любой другой Транзакции, основываясь на типе этой Транзакции или входных значениях.

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

4.4.1.5 Любой код, написанный Организатором, который посылает рыночные заявки из SUT в Драйвер (т.е. SendToMarketInterface) не может принимать каких либо решений, относящихся к маршрутизации, управлении временем и порядком или этапам выполнения этой заявки или любой другой заявке, основываясь на входных данным этой заявки.

Примечание: Эти ограничения включают непосредственные и неявные сведения.

4.4.1.6 Если в пределах реализации Фрейма выполняется маршрутизация, монитор транзакций должен выполнять маршрутизацию (см. Пункт 3.2.1.8). Реализованный Организатором Интерфейс SendToMarketFromFrame не руководствуется этой главой, но реализация должна соответствовать требованиям, указанным в Пункте 4.4.1.5.

4.4.2 Описание конфигурации сети

Организатор теста должен полностью описать конфигурации сети как тестируемых служб, так и предполагаемых реальных (целевых) моделируемых служб.
4.4.3 Ограничения реализации SUT, накладываемые на возможности вмешательства Оператора.

Системы должны быть способны выполнять нормальные операции в течение по меньшей мере одного Рабочего дня без необходимости вмешательства оператора для поддержания Отчетной производительности.

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

4.4.4 Синхронизация Времени.
Все системы, используемые для Драйвера и SUT должны иметь системные часы, которые синхронизированы в пределах отклонения, равного 10 секундам, между всеми системами. Синхронизация должна проверяться один раз до и один раз после Выполнения теста.