10. Производные контракты

10.2.1 Лонги, шорты, коллы и путы: Представление сложного словаря

Вопрос о лонгах и шортах действительно нуждается в обсуждении. В разделе 9.1 мы объяснили, что контракт может быть на покупку (long) или на продажу (short). Однако для опционов существует четыре варианта. Мы можем продать опцион на продажу денег, продать опцион на покупку денег, купить опцион на продажу денег или купить опцион на покупку денег. Выбор длинный/короткий по-прежнему существует в контракте, но он дополняется еще одним выбором длинный/короткий в опционе. В словарном запасе трейдера есть термины «колл» и «пут». Колл — это опцион на покупку (то есть длинный контракт), а пут — опцион на продажу (короткий контракт). Естественно, мы можем купить или продать колл (право покупки), а также купить или продать пут (право продажи). Пересказ этого языка несколько сложен, а также запутан.

Если я продаю опцион на покупку иены, то контрагент может купить у меня иену на дату истечения срока действия опциона. Разница между ним и форвардом заключается в том, что контрагент может не делать этого. Если я покупаю опцион на продажу иены, то позиция остается прежней, но контроль над исполнением опциона теперь принадлежит мне. В любом случае у меня (потенциально) короткая иена, следовательно, контракт короткий. В первом случае опцион также короткий, а во втором — длинный. В первом случае трейдеры сказали бы, что продают (короткий) колл, а во втором — что покупают (длинный) пут.

Один из способов взглянуть на это — сказать, что мы можем заменить длинное/короткое описание контракта на колл/пут. Но это не совсем работает, потому что мы не используем термины «колл» и «пут» для контрактов, которые не являются опционами.

Другой вариант — использовать термины long и short только для опционов, чтобы обозначить состояние опциона, а не контракта. Таким образом, первый пример выше будет коротким коллом, а второй — длинным путом (нет, ничего не перепутано). Это может иметь смысл для трейдера, но может запутать любое программное обеспечение. При оценке риска важна позиция суммы контракта, а в приведенных выше примерах оба контракта короткие. Следовательно, нам нужно уметь задавать направление контракта (которое определяет позицию), направление опциона и колл/пут. Итак, два примера: (короткий контракт, короткий опцион, колл) и (короткий контракт, длинный опцион, пут). Очевидно, что один из них может быть получен из двух других. На диаграмме показано, что колл/пут является производным. Вывод — это напоминание о том, что одно из них является производным, а не указание исполнителю на то, что на самом деле хранится или вычисляется в реализации.

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

Пример: 1 июня 1997 года я получил опцион на покупку 200 акций Aroma Coffee Makers 1 января 1999 года по цене $5 за акцию. Это опцион с датой сделки 1 июня 1997 года, инструментом — акциями Aroma Coffee Makers, количеством 200, датами поставки и истечения 1 января 1999 года, премией 0 долларов и ценой 5 долларов. 1 акция будет приобретена, поэтому контракт длинный (по отношению ко мне), и опцион тоже длинный (поскольку я его держу); таким образом, это колл.

Пример: Когда я бронирую билет на самолет, мне предоставляется опцион колл на билет. Дата истечения срока действия опциона — это дата, когда бронирование должно быть оформлено.

Другой проблемой является взаимодействие между датой поставки и датой истечения срока действия. Для опциона дата поставки может быть вычислена, если известна дата истечения срока действия (дата поставки = дата истечения + спот). Обратное, однако, не верно (из-за вмешательства праздников). Это означает, что для опционов дата поставки является вычисляемым сопоставлением. Важным моментом здесь является то, что интерфейс не меняется — по-прежнему существует аксессор для даты доставки, однако информация сохранена. Есть два способа для описания этой ситуации. Первый — мы можем отметить (обычно в глоссарии), что для опционов атрибут даты доставки переопределяется и вычисляется из даты истечения срока действия в соответствии с формулой. Второй — описать формулу как ограничение на тип опциона. Оба варианта вполне разумны, и выбор — дело вкуса. Какой код и структуру данных использовать, зависит только от исполнителя.

10.2.2 Подтипировать или нет — вот в чем вопрос

Структура, показанная на рис. 10.5 — не единственный способ работы с опционами; другой вариант показан на рис. 10.6. Разница между этими двумя структурами заключается в том, как опциональность добавляется в контракт. На рисунке 10.5 мы добавляем ее путем подтипизации. В этой схеме опцион — это разновидность контракта с дополнительными свойствами и некоторым вариантом поведения. На рис. 10.6 мы можем сказать, что у опциона есть базовый контракт, который трейдеры часто называют базой опциона. Здесь есть по крайней мере некоторое понятие сдерживания, особенно в том, что мы вряд ли попросили бы контракт оценить себя, если бы он был базовым для опциона. Аналогично, дата поставки будет зависеть от даты истечения опциона.

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

Рисунок 10.6 Отдельный объектный подход к опционам и контрактам.

Выбор между этими двумя конструкциями непрост. Обе обладают элегантными качествами. Модель на рис. 10.6 разделяет понятия опциона и контракта с определенным понятием базового контракта. Недостатком этой схемы является то, что один контракт представлен двумя объектами. Проще изменить рисунок 10.6 для работы с составными опционами (опционами, в которых базовый контракт является опционом). При таком небольшом выборе между ними мы можем легко запутаться. Прототипирование иногда может прояснить ситуацию, но не всегда. Когда появляются альтернативы, подобные этой, хорошей идеей будет использовать более простой подход, а затем, при необходимости, перейти к более сложному. В данном случае, однако, можно поспорить, какой подход проще. Когда ситуация настолько близка, я доверяю инстинктам экспертов домена, спрашивая их о том, что кажется лучше. Мы продолжим использовать рисунок 10.5 в качестве основы для дальнейшего обсуждения.

10.3.1 Должен ли продукт всегда присутствовать?

Одно из последствий модели на рис. 10.9 заключается в том, что не составные контракты представлены одним контрактом и одним продуктом. Продукт мало что добавляет к картине (кроме разделения ответственности между отделом продаж и отделом управления рисками).

Другая возможность — не делать ссылку на продукт обязательной. В такой схеме только составной контракт имеет продукт. Более простые контракты не имеют связи с продуктом. В контракте есть ссылки на части, но они возникают при наличии товара. Недостатком этой схемы является непоследовательное распределение ответственности. Контракт отвечает за управление отношениями с частями, за исключением случаев, когда он делегирует эти обязанности продукту. Такая непоследовательность может привести к большой путанице. По этой причине я предпочитаю использовать модель на рис. 10.9.

Традиционные специалисты по моделированию данных пришли бы к тому же выводу другим путем. Нормализация приводит к тому, что они не хотят дублировать связи с частями и поэтому выбирают модель, подобную рис. 10.9 (хотя в физической модели она может быть изменена по соображениям производительности). Объектно-ориентированный аргумент отличается тем, что он сосредоточен на четком распределении обязанностей, однако оба аргумента имеют общую суть: Концептуальная простота приводит к тому, что мы имеем минимум базовых ассоциаций (мы можем иметь столько производных ассоциаций, сколько захотим). В разработке ОО этот принцип приводит нас к четкому разделению обязанностей, а в реляционном моделировании данных — к 14-й нормальной форме (или как ее там сейчас называют).

10.4.1 Обеспечение соответствия диаграмм состояния

Диаграмма состояния сама по себе представляет интересную задачу. Мы можем заменить диаграмму состояний, показанную на рис. 10.4, диаграммой на рис. 10.11, обеспечивающей различное поведение подтипа барьера. Однако при этом возникает вопрос: можно ли так делать? В большинстве методик подчеркивается важность возможности замены подтипа на супертип. Это отражается на диаграммах объектов, позволяя нам только добавлять ассоциации, но не удалять их. Во многих учебниках не упоминается, какие правила управляют диаграммами состояний с подтипами. Шлаер и Меллор (Shlaer and Mellor) [6] указывают, что машины состояний можно размещать только либо в супертипе, либо в подтипе. Однако если у всех подтипов есть общая часть, то она может быть помещена в супертип для облегчения сопровождения. Рамбо [5] указывает, что подтипы могут (обычно) добавлять только ортогональные машины состояний.

Лучше всего о том, как работают подтипы и состояния, рассказано в работе Кука и Дэниелса (Cook and Daniels) [1], которые посвятили подтипам и машинам состояний целую главу. Они подчеркивают принципы проектирования по контракту [4], которые можно кратко сформулировать так: машина состояний супертипа может быть расширена двумя способами: либо добавлением ортогональной машины состояний, либо взятием состояния супертипа и разбиением его на подсостояния. Переходы супертипа могут быть изменены только путем перенаправления их на подсостояния состояния их супертипа.

Применяя эти рекомендации к моделям состояния опционов, мы видим ряд проблем. Первая заключается в трактовке события начала срока действия опциона. На рисунке 10.4 (диаграмма опциона) оно вызывает переход из состояния «куплен» в состояние «исполняется», но на рисунке 10.11 (диаграмма барьера) переход происходит из нового состояния «разрешен к исполнению». Аналогичная проблема возникает и с событием окончания срока действия: на рисунке 10.4 оно вызывает переход только из состояния, пригодного (разрешенного) для исполнения, а на рисунке 10.11 — из любого состояния.

Первая проблема возникает при рассмотрении следующей ситуации. Что должен делать объект, если он получает событие, при нахождении в состоянии когда с событием ничего не можем сделать. Объект может либо молча проигнорировать событие, либо выдать ошибку. Для того чтобы определить, как поступать в этом случае, следует выработать некоторую общую политику; например, Кук и Дэниелс советуют [1] явно перечислять события, в которых заинтересован объект. Любые события, которые обычно молча игнорировались бы, перечисляются как допустимые. Это решает вопрос о том, что произойдет, если диаграмма с рис. 10.11 (барьер) получит событие начала срока истечения, находясь в начале закупки. Если начало срока истечения является разрешенным событием, оно просто проигнорирует его.

Однако это все еще не полностью соответствует супертипу. На рис. 10.11 показано, что при получении события начала даты истечения купленный опцион меняется на исполняемый. Если рассматривать это в терминах контракта, то изменение на купленный является частью постусловия начала даты истечения. Мы не можем ослабить это постусловие в подтипе, только усилить его. Чтобы иметь колл с knock-down в качестве подтипа опциона, мы должны заменить обе диаграммы состояний на те, что показаны на рисунках 10.13 и 10.14.

Рисунок 10.13 Модифицированная диаграмма состояний для опции, позволяющей Куку и Дэниелсу соответствовать вызовам knock-in

Рисунок 10.14 Модифицированная диаграмма состояний для вызовов knock-in для поддержки соответствия рисунку 10.13.

Чтобы обеспечить соответствие, эти диаграммы отражают два изменения. Первое — это обобщение приобретенного и реализуемого в активное состояние. Отсюда мы можем перенаправить событие окончания срока действия. Второе изменение заключается в добавлении можноЛиИсполнить в качестве защиты для события начала срока действия. Эта операция — способ сказать, что начало срока истечения не всегда приводит к состоянию, пригодному для исполнения. Для обычных опционов можноЛиИсполнить всегда истинна. Подтипы опциона могут переопределять его для другого поведения. На рис. 10.14 показано, как это переопределение происходит для барьеров knock-in. Мы вводим подстатусы «куплено», чтобы указать, был ли барьер достигнут или нет. Затем мы разделили источник перехода «начало срока исполнения» и ослабили защиту, чтобы показать незащищенный переход. Так как мы разрешили начало срока исполнения для супертипа, барьер может игнорировать начало срока исполнения, когда его не достигают.

10.4.2 Проблемы с использованием соответствия

Пройдя через это упражнение по достижению соответствия, мы должны остановиться и задать себе несколько вопросов об этом процессе. По моему мнению, рисунки 10.4 и 10.11 представляют собой более простые и понятные выражения поведения, чем рисунки 10.13 и 10.14. Таким образом, хотя мы и приобрели соответствие (по крайней мере, в соответствии с определением Кука и Дэниелса), мы потеряли понятность. Кроме того, моделирование вызова «knock-in» заставило нас изменить диаграмму супертипов. Она и так была хороша — но нам понадобилась другая диаграмма состояний на основе новых состояний подтипа. Это означает, что новый подтип может заставить нас изменить диаграммы состояний супертипов снова, если только мы не окажемся достаточно умны, чтобы создать удивительно гибкую диаграмму состояний супертипа. К сожалению, я не думаю, что я настолько умен, поэтому подтипизация будет сопряжена с трудностями.

Одно из решений этих трудностей — перестроить иерархию обобщений, чтобы не беспокоиться о соответствии. Мы предположили, что колл с knock-down (т.е. барьер не достигнут) будет подтипом опциона, каждый из которых имеет свою собственную таблицу состояний, как показано на рис. 10.15. Другой подход заключается в том, чтобы рассматривать опцион как абстрактный тип без собственной диаграммы состояния и создать обычный подтип опциона для хранения машины состояния с рисунка 10.4, как показано на рисунке 10.16. Это избавляет от необходимости беспокоиться о соответствующих диаграммах состояний, позволяет использовать более естественные диаграммы состояний, но вводит отдельный тип. Это также более соответствует рекомендациям Рамбо, Шлаера и Меллора, которые не обсуждают соответствие между моделями состояний.

Это естественный подход, но как связаны модели состояний?

Рисунок 10.15 Knock-in (с достижением барьера) колл как подтип опциона.

Это может облегчить работу с моделями состояний, но это не так естественно. Оригинальная диаграмма приемлема. Главное, чтобы начало истечения срока действия

Рисунок 10.16 Создание обычного типа опции.

Проектирование по контракту гласит, что подтипы должны удовлетворять пост-условиям своих супертипов. Однако это не обязательно означает, что постусловие начала срока действия должно включать переход в состояние исполнения. Если мы решили не включать его в постусловие, то исходная диаграмма вполне приемлема. Важно то, что начало истечения срока должно быть разрешено во всех случаях; вызывает ли оно переход или нет, не определено.

На самом деле это пример более широкой проблемы, связанной с использованием проектирования по контракту. Часто люди говорят, что постусловия операции должны определять все изменения в наблюдаемом состоянии объекта. Этот принцип часто отстаивается сообществом формальных методов, но он не верен для проектирования по контракту. Постусловие просто определяет состояние, которое должно быть в конце операции. Мы всегда можем указать, что ничего не должно измениться, кроме того, что указано, но в данном подходе это не предполагается.

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

10.5.1 Проверка типов в фасаде приложения

В этой стратегии за решение проблемы отвечает элемент просмотра. Перед каждым запросом к контракту выполняется проверка типа контракта, чтобы убедиться, что запрос может быть выполнен безопасно, как показано на рис. 10.18. В C++ это происходит в виде проверки типа, затем следует преобразование типа к подтипу (downcast), после чего выполняется запрос.

Тип проверяется перед вызовом операции, которая определена только для подтипа.

Рисунок 10.18 Взаимодействие для проверки типа в строке браузера.

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

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

10.5.2 Предоставление супертипу охватывающего интерфейса

Суть проблемы заключается в том, что ошибочно запрашивать у контракта дату окончания его действия. Одно из решений — добавить в контракт все операции с подтипами. Контракт, естественно, будет отвечать nil для всех этих операций, но соответствующие подтипы могут переопределить эту операцию, чтобы предоставить свое значение.

Такой подход имеет множество проблем. Становится невозможно определить, какая операция над контрактом действительно легальна, а какая — ошибка. Проверка типов во время компиляции оказывается несостоятельной, поскольку не может определить, что из этого является ошибкой. Каждый раз, когда вводится подтип, интерфейс контракта должен быть изменен. Поэтому я не являюсь поклонником этого подхода.

10.5.3 Использование атрибута времени выполнения

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

Базовая модель для контрактов показана на рис. 10.19, или даже лучше взять рис. 10.20, где используется отображение с ключом (см. раздел 15.2). Все контракты имеют несколько условий, и каждый из них получает тип условия. В этом примере каждый атрибут контракта и его подтипы (цена исполнения, колл, барьерный уровень и так далее) будут типами условий контракта. Если у контракта запрашивают условие, он отвечает объектом значения, если такой условие существует. Таким образом, запрос даты истечения «неопциона» не является ошибкой.

Такой способ запроса свойства определенного только в опции не будет приводить к ошибке.

Рисунок 10.19 Атрибут времени выполнения для контракта.

Рисунок 10.20 Рисунок 10.19 Использование сопоставления с ключом.

Конечно, эта модель допускает случайное присвоение «неопциону» даты истечения. Это можно предотвратить несколькими способами. Первый — использовать уровень знаний (см. раздел 2.5), как показано на рис. 10.21. Другой способ — рассматривать тип условия как производный интерфейс. При этом предоставляются как атрибуты модели (те, что касаются контракта и его подтипов), так и интерфейс типа условия. Обновления предоставляются только через атрибуты модели.

Это позволит предотвратить неправильное размещение условий в контрактах, но проверить это можно только во время выполнения.

Рисунок 10.21 Использование уровня знаний для контроля размещения условий в контрактах.

Использование атрибутов времени выполнения действительно обеспечивает гибкость, но оно имеет и существенные недостатки. Во-первых, использование типов условий усложняет понимание интерфейса контракта и его подтипов. Помимо просмотра операций, определенных для типа, пользователь контракта должен также смотреть на экземпляры типа условий, и, конечно, на то, какие экземпляры являются допустимыми. Во-вторых, атрибутные типы не могут быть проверены во время компиляции, что лишает их очень важного преимущества проверки во время компиляции. Это не имеет значения для «элемента просмотра» (строки обозревателя), поскольку вся суть заключается в том, чтобы ослабить любую проверку во время компиляции, но это имеет большое значение для других частей системы. Третий недостаток заключается в том, что подрываются базовые механизмы языка. Компилятор не знает, что происходит, и такие особенности языка, как полиморфизм, программист должен кодировать вручную. Кроме того, атрибуты времени выполнения работают не так хорошо, как атрибуты модели. Многие из этих недостатков можно смягчить, предоставив оба интерфейса. Те части программы, которые знают об атрибутах во время компиляции, могут использовать атрибуты модели, а обозреватель — атрибуты времени выполнения.

10.5.4 Создание фасада приложения, видимого для доменной модели

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

Элемент просмотра должен быть виден контракту, что нарушает обычные правила видимости между слоями домена и приложения.

Рисунок 10.22 Взаимодействие для контрактов, создающий элементы просмотра.

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

Самый большой недостаток заключается в нарушении правил видимости между слоями приложения и домена, которые обсуждаются в главе 12. Этого можно избежать, поместив элемента просмотра в собственный пакет/библиотеку, как показано на рис. 10.23. Таким образом, зависимость от доменной модели ограничивается только типом элемента просмотра. Видимость можно еще больше уменьшить, разделив тип элемента просмотра на два. Презентация для обозревателя и контракты используют совершенно разные интерфейсы для элемента просмотра. Он может иметь свое собственное визуальное представление в UI пакете обозревателя. Тот в свою очередь имеет простое взаимодействие с элементом просмотра. В этом случае можно убрать видимость из представления обозревателя в пакет элемента просмотра.

Пакет элемента просмотра — это особый случай между слоями приложения и домена.

Рисунок 10.23 Видимость пакета элемента просмотра (на основе рисунка 12.6).

Другой недостаток связан с возможностью использования нескольких пользовательских приложений, которые могут иметь несколько разные потребности. Каждому приложению потребуется свой элемент просмотра, и все они должны быть известны по контракту. Здесь может помочь разделение элемента просмотра. Для каждого приложения будет создан собственный UI элемента просмотра, и все они будут использовать один пакет элемента просмотра с объявленным API. Таким образом, добавление новых видов обозревателей не изменит обязанностей контракта, если только в элемент просмотра не будет добавлена новая функция.

Факт остается фактом: любая новая функция, требуемая в элементе просмотра, требует изменения всего контракта и всех его подтипов. В этом и заключается фундаментальный компромисс между передачей контроля элементу просмотра и передачей контроля в контракт. Если новые контракты добавляются чаще, чем функции в элементе просмотра, то мы должны поместить контроль в контракт. Однако не стоит легкомысленно относиться к изменению привычной схемы видимости. Если только новые подтипы контрактов не появляются значительно чаще, чем изменения в элементе просмотра, я бы не стал вводить контроль в контракт, потому что многие новые подтипы контрактов сами по себе будут подразумевать новые возможности для элемента просмотра.

10.5.5 Использование обработки исключений

Конечно, все вышеперечисленные идеи основаны на том, что спрашивать у небарьерного опциона о его барьерном уровне — это плохо. Однако в правильном окружении это не такая уж и проблема. Если запрос объекта приводит к ошибке времени выполнения и эта ошибка проявляется в виде исключения, то элемента просмотра может просто перехватить исключение и обработать его как nil. Элемента просмотра должен проверить, что исключение действительно является результатом того, что приёмник не понял запрос, а не какой-то другой, более тревожной ошибкой. Это также предполагает, что можно отправить сообщение объекту, для которого у приёмника нет интерфейса. Именно здесь отсутствие безопасности типов становится преимуществом, в сочетании с функциями обработки исключений, присутствующими в новых реализациях. Smalltalk всегда можно использовать подобным образом, поскольку он не типизирован. В C++ безопасность типов можно обойти, используя приведение к дочерним типам (downcast).