требования к системе
Алексей Неботов
проектирования ПО, документ доступен здесь
https://docs.google.com/fileview?id=1Vfl2zNvrFJhuBzh9NaXuAP8GZx1IKr2efpdZpE2JRP7zYH40YTCHxSamguoc&hl=ru
Я согласен со всем, что написано в данном документе. Единственное, что
я бы добавил, это то, что процесс описанный в таблице 1 допускает
инерционность. Т.е. идти к идеалу можно постепенно.
Андрей, ты сможешь организовать сбор требований?
Кроме того, я предполагая модульность системы, т.е. данный процесс
можно разбить по модулям (Ядро также считаю модулем). Весь опус ниже,
объясняет мой подход к модульности:
Я изначально предполагал, что будут расхождения в ожиданиях конечного
функционала. Более того, не собираюсь ничего делать для переубеждения
всех участников в правильности своего пути. И не верю, что среди
программистов удастся его добиться, т.к. каждый будет думать "ну раз к
моим хотелкам не прислушались, тогда я в проекте не участвую".
Для того, чтобы данные противоречия не мешали проекту была придумана
модульная система. Более того, модули загружаются динамически, т.е.
заменить любой из модулей системы своим не составит труда.
Пример подобной системы miranda, я хочу создать нечто подобное для
торговли. Т.е. если Вас не устраивает какая либо из частей системы, Вы
переделываете её под себя, при этом вся остальная система продолжает
нормально функционировать. Это принципиальный момент (требование)!!!
Ни один модуль системы не должен зависеть ни от чего кроме ядра. Это
позволит не собирать требования для системы в целом и впоследствии,
безболезненно реализовывать дополнительные требования.
Например: Сейчас реализуется интеграция с Quik, а в последствии
захотелось реализовать интеграцию с Плаза2. Для этого пишется модуль
данной интеграции, который просто копируется в папку плагинов, и все
модули начинают использовать дополнительный функционал. Или модуль
хранения торговых данных, я реализую его на sqlite, а кто то захочет
реализовать на mssql или в файлах, тогда он, возможно взяв модуль с
sqlite за основу, реализует свой, и просто заменив dll, без
перекомпиляции всей системы, получит требуемый функционал.
Мои высокоуровневые требования к функционалу описаны в разделе
"Функции Cap'а" документа http://code.google.com/p/open-wealth-project/wiki/Modules
au100
По поводу инерционности. Как я уже писал, программирование сложных
систем является "грязной проблемой", поэтому идеал достигается
постепенно. И если мы обеспечим возможность легкой модификации, то
ничего не мешает нам в процессе разработки дополнять и расширять
требования. Именно для этого модульность и предлагается. Динамичная
загрузка (чего и как - вопрос пока что дискуссионный), и без этого не
обойтись. Мое основное пожелание - это мобильность системы за счет
правильной организации ядра, чтобы можно было любому легко добавлять
свою функциональность. Тогда система станет живой и нужной многим.
Вопрос по организации сбора требований - займусь с завтрашнего дня. Но
просил бы прямо сейчас "коротенько минут на 40", на одной страничке и
возможно на неполной страничке сформулировать проблему (приветствуются
любые идеи и мнения, пинать никто никого не будет, и возможно что в
самой на первый взгляд дурной идее заложено огромное рациональное
зерно) . Те кто может - пусть откликнуться, Тогда я попытаюсь ее
обобщить и изложить для обсуждения. Тем временем начну заниматься
требованиями, которые также выложу на всеобщее "оборзение".
Параллельно можно высказывать мысли по любым пунктам. Хотелось бы
также открыть страницу с подобными документами для ознакомления тех,
кто желает присоединиться.
On 8 сен, 13:06, Алексей Неботов <anebo...@gmail.com> wrote:
> Получил от Андрея (au100) письмо с документом, описывающим принципы
> проектирования ПО, документ доступен здесьhttps://docs.google.com/fileview?id=1Vfl2zNvrFJhuBzh9NaXuAP8GZx1IKr2e...
Алексей Неботов
ворд попутал :)))) но несмотря на это, идея понята правильно.
Андрей, доступ на редактирование wiki и т.п. я тебе дал.
Мои требования/идеи:
Разрабатываемая программа должна:
1) Уметь получать, и передавать в сторонние приложения историю
торговых данных
2) Уметь получать, и передавать в сторонние приложения реалтайм
торговые данные
3) Уметь получать и передавать в сторонние приложения заявки. И
передавать обратно статусы заявок/сделки/остатки
4) Хранить полученные из других приложений данные. И отдавать их
повторно.
Интерфейсы с другими программами должны реализовываться так, чтобы их
можно было легко заменят один другим, и использовать совмесно.
Как поставщиков, так и потребителей данных может быть произвольное
количество (в том числе ноль). На первом этапе предлагаю реализовать
интеграцию с:
Источником исторических - сайт Финама
Источником реалтайм данных - Quik
Потребителем данных - Wealth-Lab Dev 6
Кроме того предлагаю реализовать потребителя данных (WLEmulator)
позволяющий запускать робота, написанного в нотации WealthLab, без
использования самого WealthLab. Это позволит не использовать не
лицензионные компоненты на бою.
Требует расшифровки:
Что такое торговые данные
Возможные типы заявок и возможные действия с заявками
Потребуется дедубликация данных, т.к. источников одних и тех же данных
может будет несколько. Т.е. каждый источник, видимо, должен иметь
уникальный приоритет.
Сергей Войтов
Неплохо было бы этой "программе" вести свою базу данных котировок, как
это делает Омеговский Глобалсервер.
//Крайне нужен (по крайней мере мне) статик адаптер QuotesPlus - WLD6.
В четвертой версии WL он был встроенный.
au100
, где ипостарался описать проблему в основном. прошу добавлять и
раскритиковывать.
Алексей Неботов
функционала монстров, типа Metastock и Wealth-Lab. Гораздо легче
сделать интеграцию с ними, и использовать их функционал, постепенно
замещая его своим. Пытаясь сделать что то очень большое, можно в итоге
не получить ничего, убив массу усилий. Поэтому я вижу этапность
разработки:
1) разработка интеграции Quik <-> Wealth-Lab (придаст проекта
большую популярность в России)
2) разработка WLEmulator (при этом достаточно запуска простейших
роботов, позволит отказаться от WL на бою)
3) разработка системы бэктестинга (позволит отказаться от WL при
разработке робота)
4) разработка прочих надстроек к системе, которые постепенно будут
покрывать функционал монстров.
5) локализация для ENG (позволит привлечь большее к-во
пользователей/разработчиков)
Но делая первый шаг, надо уже думать о следующих, чтобы потом небыло
мучительно больно переделывать всё на корню.
по пункту 16:
"16. Возможность использования внутреннего языка для проектирования
торговых сделок "
думаю это не нужно, мы используем .NET (кстати, это надо
фиксировать? :) да ещё и опенсоурс. Т.е. гораздо правильнее позволить
пользоваться интерфейсами системы.
На предложения Сергея:
от своей базы данных котировок уйти не удастся. Вопрос в каком формате
она должна быть. Можно придумать что то своё, можно сделать
совместимым с каким либо форматом. Плюсы и минусы есть у обоих
подходов.
статик адаптер для QuotesPlus это хорошо, это ещё один модуль
интеграции, который, как я думаю, не повлияет на остальную систему.
Вопрос кто его будет реализовывать.
Думаю под каждой хотелкой должно быть написано: в жизнь готов
воплотить тот-то. Я готов подписаться под первыми тремя пунктами, при
этом ваша помощь позволит сократить сроки разработки. Воплощать
интеграцию с QuotesPlus я в данный момент не готов, может быть позже,
в качестве пункта 4. Но Вы можете начинать уже после первого этапа,
модульность позволит распараллеливать задачи.
au100
> сделать интеграцию с ними, и использовать их функционал, постепенно замещая его своим. Пытаясь сделать что то очень большое, можно в итоге
> не получить ничего, убив массу усилий. Поэтому я вижу этапность разработки:
Именно эту мысль я и пытаюсь донести, не замахиваясь на монстров (пока
не замахиваясь, замахнуться другие, если эту возможность им
предоставить). Как было написано в проблемах:"Данный документ является
просто короткой формулировкой проблем и ни в коей мере не претендует
на будущую архитектуру, но уже закладывает ее основания. Здесь
перечисляются то, что мы хотим получить в общих чертах безо всяких
намеков на то, как мы собираемся это реализовать. Данный документ
необходим лишь для представления общих целей будущего ПО. Как и каждый
документ в процессе работы он может претерпевать изменения, которые
будут вноситься в него." Я пытаюсь донести мысль о простоте дополнений
в будущем, легкости модификации и добавления новых возможностей в ПО.
Если это будет реализовано, то проект пойдет и найдется масса желающих
добавлять в него новые функционалы.
Так что этот документ - просто пожелания, что мы хотим достичь в
конечном итоге. Основной упор я сделал на легкое расширение
возможностей. А начинать надо с какой-либо кокретной интеграции.
Например, ты хочешь Quik <-> Wealth-Lab. всеми конечностями - "за".
Просто делать взаимодействие не жесткофиксированным, а проработать
так, чтобы легко в ядро можно было адаптировать другие расширения. А
об этом надо думать уже сейчас. У тебя, Алексей, явно есть свое
видение интеграции (больше чем уверен, что ты уже думал над
возможностями расширения). По поводу внутреннего языка - я не против
этой идеи, но все же высказал ее. В данном случае предпочтительнее на
мой взгляд пользоваться стандартынми методом и просто динамически
добавлять функционал в ПО. Причем это будущий функционал не
обязательно должен быть написан на NET. Если определить правила
интегрирования в систему и точки входа, то для себя пусть пишут на чем
угодно, так как динамичкеские библиотеки - это стандарт. Но есть
вопрос о разработке не только под Винды. Достаточно много
пользователей, которые используют другие системы. Что об этом? Это
вопрос будущего, но опять же - продумать надо сейчас
По поводу своей базы котировок: "пункт 13. Ведение по желанию
пользователя собственной базы данных с динамическим форматом хранения,
определяемым пользователем".
Алексей Неботов
> вопрос о разработке не только под Винды. Достаточно много
> пользователей, которые используют другие системы. Что об этом? Это
> вопрос будущего, но опять же - продумать надо сейчас
я не имею опыта разработки не под винды (небольшие скрипты не в счет)
и не представляю как можно заложить в систему создающуюся на .NET
возможности интеграции с чем то *nix.
переходить на java не хочу ... есть ещё варианты?
вообще, насколько актуальны *nix системы для клиентских приложений?
может не заморачиваться на мультиплатформность?
Елисей Саватеев
я не имею опыта разработки не под винды (небольшие скрипты не в счет)
и не представляю как можно заложить в систему создающуюся на .NET
возможности интеграции с чем то *nix.
переходить на java не хочу ... есть ещё варианты?
Я разрабатываю свою торговую платформу на С++ и Qt - абсолютно кросс-платформенное решение. Другое дело, что на данный момент реализованы только платформа-зависимые модули интеграции с QUIK и версия под Linux, например, может пока только читать ценовые данные в заданном формате из текстового файла. А вот модуль, реализующий, например, протокол Plaza2 будет уже переносимым. Важно заметить, что разрабатывать переносимые приложения на связке C++ и Qt ничуть не сложнее обычных, разве что неперносимый код приходится обрамлять директивами #ifdef <ПЛАТФОРМА> ... #endif. Кстати, для C# под Linux есть Mono, но я сильно сомневаюсь что перенесенный код будет работать без малейших изменений и проблем.
вообще, насколько актуальны *nix системы для клиентских приложений?
может не заморачиваться на мультиплатформность?
Алексей, я думаю это тебе нужно для себя решить - какая основная цель. Ты в списке приоритетов на данный момент ставишь интеграцию с WLD 6, это автоматически ограничивает текущие целевые ОС только Windows. В свою очередь, я при выборе инструментов разработки опирался во-первых на свой опыт C++ и Qt, во-вторых на то, что для меня Linux основная платформа, и в третьих я адепт открытых технологий :)
P. S. А в Renaissance Tech похоже тоже пишут на C++ под Unix. Proof link - https://www.renfund.com/vm/data_programming.vm
--
С уважением,
Елисей Саватеев.
Алексей Неботов
> списке приоритетов на данный момент ставишь интеграцию с WLD 6, это
> автоматически ограничивает текущие целевые ОС только Windows.
я не имею опыта ни в разработках для *nix, ни в с++
тратить пол года на их изучение очень не хочется
переносимость важна в серверных технологиях. Пока предлагаю отложить
кроссплатформенность.
но вот что меня насторожило, посмотрел аналитику по сайту
http://code.google.com/p/open-wealth-project/
10% посещений - linux (хотя похоже это один пользователь)
1% - Macintosh
остальное windows
и хотя это посещения, а не посетители (посетителей не смог
выципить), статистика меня напрягла.
Елисей Саватеев
но вот что меня насторожило, посмотрел аналитику по сайту
10% посещений - linux (хотя похоже это один пользователь)
1% - Macintosh
остальное windows
и хотя это посещения, а не посетители (посетителей не смог
выципить), статистика меня напрягла.
С большой долей вероятности все 10% относятся ко мне :)
Mikhail Sukhov
Осталось найти еще 9-ых под Win =)
Может пятница на меня действует, но я опять стал слабо понимать суть
разработки. А что будет за первая версия продукта и что она будет
уметь? Какие отличительные особенности (уникальные вещи) по сравнению
с Велс? И нужен ли будет Велс для работы OWP?
On 10 сен, 17:37, Елисей Саватеев <elisey.savat...@gmail.com> wrote:
> 10 сентября 2010 г. 19:16 пользователь Алексей Неботов
> <anebo...@gmail.com>написал:
au100
тоже работаю с Qt и C++, но в основном в Mono - очень мощный
инструмент. Статистика хоть и аппологет вранья, но иногда дает
правильные ответы. Именно 10% пользователей в мире сидят по NIXами.
Это очень большой сегмент. Отбрасывать его просто не надо. И под эти
ОСи клиентские приложения очень актуальны. И полгода тратить на
изучение другой операционки не надо, ни к чему это. Просто разделить
переносимое ядро от внешнего интерфейса. Это по силам. Но опять я не
призываю это делать сейчас. Это надо иметь ввиду при разработке
модульности. Для первого варианта минимальная необходимая
функциональность с большими потенциальными возможностями для
совершенствования. Поэ
тому и стоит задача; определить минимальную функциональнсть первого
варианта и создать его, но не жестким, а определить дальнейший путь
развития и создать возможности дополнения функциональности.
С уважением. Андрей Ушаков
Алексей Неботов
я правильно понимаю что *nix и .Net слабо совместимы?
Mono мне в своё время показался монстром.
> А что будет за первая версия продукта и что она будеn уметь?
Первую версию системы вижу такой:
Quik -> [ Модуль интеграции с Quik -> Модуль данных -> Модуль
интеграции с WL ] -> WL
т.е. даже без интерфейса.
Модуль интеграции с WL - заготовки кода готовы
Модуль данных - сейчас делаю (но много вопросов о правильности
пути!!!)
Модуль интеграции с Quik - конь не валялся
вторая версия (не путать с этапом) - добавится работа с заявками.
> Какие отличительные особенности (уникальные вещи) по сравнению
> с Велс? И нужен ли будет Велс для работы OWP?
Я вижу три этапа:
1) "Без Велс никуда" и бэктестинг и торговля происходят в Велс. OWP
для интеграции с Quik и Историей Финама
2) "Велс для бэктестинга" Бэктестинг происходит в Велс, а торговля на
бою происходит в OWP без использования каких либо компонентов Велса
3) "Чистый OWP" - в OWP реализован модуль бэктестинга
отличительная особенность OWP от WealthLab:
1) сама платформа OpenSource - т.е. открыта и бесплатна
2) платформа имеет интеграцию с Quik, и я надеюсь, что и с другими
системами представленными на российском рынке.
ГОСПОДА! (а интересно, дамы среди нас есть?)
какие требования к модулю ДАННЫЕ? Свои наброски я накидал в ветке
"WLProvider"
предложите свой интерфейс данного модуля (естественно, что, пока, без
реализации)
что непонятно в моей реализации? какие минусы?
au100
добавлено соглашение о стиле. Естественно это не окончательный
вариант, Если есть возражения, сомнения, поправки, добавки - прошу не
стесняться
С уважением
Андрей