робот

Анализ графика проведен с помощью аналитической программы по автоматическому анализу биржевых графиков PATTERN ANALYZER.

Бумаги Мосбиржи  с мая 2017 двигаются в рамках растущего канала.

Сейчас на графике видим растущий тренд и фигуру продолжения растущего движения «ФЛАГ НИСХОДЯЩИЙ». Цель движения 121,60 стоп можно разместить ниже 114 рублей за акцию. На этом уровне также проходит верхняя граница растущего канала (зеленая линия)



.

Анализ графика проведен с помощью аналитической программы по автоматическому анализу биржевых графиков PATTERN ANALYZER.
 
На часовом графике акций Газпром ао видим растущий тренд, фигуру продолжения растущего тренда «ФЛАГ НИСХОДЯЩИЙ» и пробой верхней границы фигуры с целью движения 131 рубль за акцию. Стоп можно разместить ниже уровня 121.

     Привет всем! В предыдущий раз я описал, как стратегии выставляют заявки. Сегодня будет ещё более интересная тема: получение маркет-даты. Для упрощения, под маркет-датой, буду иметь в виду тиковые данные (время, цена, объём).

     Я уже рассказывал про классы стратегий,  про то, что они используют интерфейс, который отвечает за получение маркет-даты – IMarketDataGate. Внутри себя, стратегии подписываются на событие AddTick из IMarketDataGate – т.е. на каждый тик стратегия проводит свой анализ данных, расчеты, и, при определённых условиях, выставляет заявки. Стратегии не важно, как генерируются тики – она просто реагирует на это событие. IMarketDataGate, имеет два варианта реализации. Первый – это обёрткой над COM библиотекой брокера (в моём случае – смартком). Тут всё просто – каждый день, кроме праздников и выходных, с 10 часов, магическим образом, начинают литься тики – их мне посылает система брокера. А вот для организации локальных бэктестов, нужен какой-то иной источник данных – некая имитация брокера по части генерации тиков. И тут-то и появляется наш герой – ITickGenerator.

interface ITickGenerator
{
   event EventHandler<StockTickEventArgs> OnTick;
   event Action OnEnd;
   void Start(string symbol);
}

     Добрый день. В предыдущем посте были описаны базовые компоненты – классы обёртки над API брокера. Не хотелось нагружать их дополнительной логикой, поэтому оставим их как есть, и перейдём к чуть более сложному объекту. На сцене появляется IOrderManager, который отвечает за заявки и сделки по ним.

interface IOrderManager
{
   List<Order> GetOrders(string symbol, int strategyID);
   void PlaceOrder(string symbol, int strategyID, OrderAction action, OrderType type, double price, double amount, double stopPrice);
} 

     Всего два метода – выставить заявку и получить их список. Но, у реализации IOrderManager’а непростая задача – надо не просто выставлять заявки, но также хранить какая стратегия это сделала и какие прошли сделки. Получается, у OrderManager’а есть некое состояние – список заявок/сделок, поэтому этот объект относится больше к модели, чем к сервисному слою программы. Перед этим я описывал IPortfolioGate – класс-обёртка для работы с портфелем, вот у него нет состояния, он просто транслирует вызов методов внешней COM библиотеки, а вот OrderManager это некий дополнительный уровень над всем этим – у него появляются «знания» о предметной области, и именно он используется в классах стратегий.
     Также, появляются две сущности – заявка (Order) и сделка (Trade). Класс Order имеет список сделок прошедших по данной заявке.

class Order
{
   public string Symbol { get; set; }
   public OrderAction Action { get; set; }
   public double Price { get; set; }
   …
   public List<Trade> Trades { get; set; }
}

     Приветствую! В предыдущем посте была теория, теперь к делу. Кое-что буду упрощать, чтобы представить картинку в целом.

     Итак, чтобы проект не зависел от API внешней com библиотеки (SmartCom или д.р.), чтобы в коде стратегий  не использовались специфические типы, разработку я начала с обёрток над смарткомом. Я определил три базовых интерфейса: IConnectGate, IMarketDataGate и IPortfolioGate. Соответственно для подключения, для получения маркет-даты и для выставления заявок и работы с портфелем. Причём каждый из этих трёх интерфейсов мне надо было реализовать минимум дважды – для смарткома и для локального тестера.

     В случае со смарткомом, это некий адаптер-обёртка, благодаря которому, я оперирую собственными типами и не завишу от com библиотеки. Т.е. у меня есть свои типы (например, направление заявки, тайм-фрейм), которые используются в коде, а адаптер-обёртка конвертирует их в специфические, понятные внешней библиотеке. Также, желательно, чтобы у каждого объекта, в программе, была только одна обязанность, поэтому никакой дополнительной логики эти обёртки не несут.