Программное обеспечение для фрактально-волнового анализа

[kailex]

В данной теме предлагаю начать рассматривать вопросы разработки собственного программного обеспечения, нацеленного на облегчение фрактально-волнового анализа (для краткости предлагаю называть его FWA).

Необходимость в собственном ПО возникла по причине ограничений существующих терминалов (например, в MT4 нету полноценной поддержки работы с XML-файлами, реляционными базами данных и.т.д. Это, конечно, можно вынести во внешнюю DLL, но тогда практически не вижу смысла базироваться на данном терминале). Не берусь утверждать, что в остальных терминалах такая же ситуация, но думаю вряд ли она кардинально отличается. Ведь все языки в терминалах создавались не для разработчиков, а скорее для трейдеров, имеющих некоторые навыки в программировании. Поэтому они по определению не могут быть сложные и полнофункциональные. Поправьте меня, если я ошибаюсь и кто-либо имел дело с терминалами, в которых можно легко встраивать полноценные приложения.

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

[kailex]

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

1) Программная платформа, на базе которой будет разрабатываться приложение. Предлагаю использовать платформу Microsoft .NET 3.5 а также WPF, WWF, WCF, как наиболее гибкую и активно развиваемую платформу на данный момент.

2) СУБД, которая будет использоваться на проекте. Приложение будет разрабатываться с учетом возможности работы на любых СУБД, но все равно для начала надо выбрать какую-то одну, отвечающую следующим требованиям:

a) СУБД должна быть легковесной (чтобы можно было запускать без проблем на рабочих компах трейдеров). Возможно даже она должна быть файловой (например SQLite).

б) СУБД должна быть бесплатной.

в) Легко конфигурироваться, настраиваться и использоваться.

г) Желательно, должна быть кроссплатформенной, чтобы можно было разместить её на внешнем собственном сервере или хостинг-сервере.

Наиболее подходящая по перечисленным выше пунктам, на мой взгляд, это MySQL.

3) Язык программирования. С учетом пункта 1) единственный подходящий вариант С#.NET.

[kailex]

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

На мой взгляд, на первом этапе самое главное, что должно быть реализовано в приложении следующее:

1) База данных для котировок, разметки, паттернов, фрактальных формаций.

2) Возможность импорта котировок из различных форматов. В первых версиях можно обойтись форматом CSV (OHLC).

3) Конвертер периодов для возможности получения котировок пользовательских ТФ (таких как H3, D2).

4) Возможность полу-автоматической оцифровки и добавления ручной разметки в БД для возможности последующей обработки.

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

6) Осуществлять поиск занесенных ранее паттернов и формаций по разметке, помещенной в БД.

7) Вывод результатов поиска и анализа (графики, отчеты, описание паттернов и ФФ и т.д.).

8) Относительно простой пользовательский интерфейс для упрощения описанных выше операций.

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

[Tomcat_MkII]

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

1) Программная платформа, на базе которой будет разрабатываться приложение.

2) СУБД, которая будет использоваться на проекте.

3) Язык программирования. С учетом пункта 1) единственный подходящий вариант С#.NET.

1 и 3) Платформа для разработки - выбор исключительно разработчика. Других программистов здесь пока нет

2) СУБД с точки зрения конечного пользователя тоже не важна, из распространенных бесплатных СУБД выбирать можно из трех - MySQL, PgSQL и Firebird. По компактности и простоте установки мне кажется преимущество у Firebird'a, но последнее слово тоже за разработчиком

[Tomcat_MkII]

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

На мой взгляд, на первом этапе самое главное, что должно быть реализовано в приложении следующее:

1) База данных для котировок, разметки, паттернов, фрактальных формаций.

2) Возможность импорта котировок из различных форматов. В первых версиях можно обойтись форматом CSV (OHLC).

3) Возможность полу-автоматической оцифровки и добавления ручной разметки в БД для возможности последующей обработки.

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

5) Осуществлять поиск занесенных ранее паттернов и формаций по разметке, помещенной в БД.

6) Вывод результатов поиска и анализа (графики, отчеты, описание паттернов и ФФ и т.д.).

7) Относительно простой пользовательский интерфейс для упрощения описанных выше операций.

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

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

У меня изначально аппетиты были гораздо скромнее

Не думаю, что есть какая-то необходимость заносить в базу разметку - это неоправданное усложнение, которое затянет работу во много раз.

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

Начать можно сразу с пункта 4. Для этого надо согласовать формат базы и отдельных таблиц (необходимые поля и их параметры). Далее, попробовать внести несколько десятков паттернов и подумать, в каком виде хотелось бы получать отчеты. По ФФ пока идей не имею, но думаю и для них нужно нечто подобное.