От Константин
К All
Дата 12.11.2009 13:48:49
Рубрики В стране и мире;

Вопрос к софтверным людям

Хотел обсудить один технический вопрос.

Общая ситуация такая. Есть некая электроэнергетическая программа. Содержание я считаю достаточно удачным. Идеологию разработал один старый спец, весьма авторитетный в нашей области, а код ваял , извините, я.
Но на оболочке дело застопорилось.
Сначала её писала трое программистов на С# (какие-то web-сервисы, SOAP и др. птичьи слова ) брались за год и очень красиво. Потом два других программиста брались на яве с помощью web-интерфейсов, за полгода, умеренно красиво. По различным причинам дело не пошло, всех уволили.
Назначили одного парня, дали ему два месяца, чтобы сделать минимальный вариант. Он собирался с помощью .NET Framework сделать . Но у него возникли проблемы и он ушёл в отпуск.
Сейчас появилось предложение сделать на Visual FoxPro

!-------------------------------------------------
Вопрос такой , можно ли всё-таки сделать оболочку более или менее современного вида и относительно быстро (1-3 месяца)?
Если да, то как ?
Ресурсы - один IT программист + 1-2 инженера , умеющих программировать.

Минимальные требования , есть БД , вычислительные модули, пользователь (один, коллективное пользование не обязательно)? интерфейс - табличный, действия относительно простые - заведение данных в БД, заведение данных с текстовых файлов одного формата, просмотр исходных данных и результатов расчётов в таблицах, сортировка и фильтрация, запуск вычислений, некоторые средства анализа, типа выдачи интегральных показателей по группам, экспорт в Excel. Всё на Windows. БД - на MS-SQL Server

Также нужна возможность работы с графическими схемами (электрические сети), сами графические средства есть, нужно состыковаться. Пока можно и без схем, но чтобы можно было потом приделать.
В дальнейшем желательна возможность строить графики от времени, по данным из БД.
От Evgeniy~K
К Константин (12.11.2009 13:48:49)
Дата 14.11.2009 11:38:16

Изучайте MS Access (-)
От Константин
К Evgeniy~K (14.11.2009 11:38:16)
Дата 16.11.2009 11:36:13

Зачем? (-)
От Кудинoв Игорь
К Константин (12.11.2009 13:48:49)
Дата 12.11.2009 16:27:05

Re: Вопрос к...

>Хотел обсудить один технический вопрос.

> Общая ситуация такая. Есть некая электроэнергетическая программа. Содержание я считаю достаточно удачным. Идеологию разработал один старый спец, весьма авторитетный в нашей области, а код ваял , извините, я.
>Но на оболочке дело застопорилось.
>Сначала её писала трое программистов на С# (какие-то web-сервисы, SOAP и др. птичьи слова ) брались за год и очень красиво. Потом два других программиста брались на яве с помощью web-интерфейсов, за полгода, умеренно красиво. По различным причинам дело не пошло, всех уволили.
> Назначили одного парня, дали ему два месяца, чтобы сделать минимальный вариант. Он собирался с помощью .NET Framework сделать . Но у него возникли проблемы и он ушёл в отпуск.
>Сейчас появилось предложение сделать на Visual FoxPro

>!-------------------------------------------------
>Вопрос такой , можно ли всё-таки сделать оболочку более или менее современного вида и относительно быстро (1-3 месяца)?
>Если да, то как ?
>Ресурсы - один IT программист + 1-2 инженера , умеющих программировать.

> Минимальные требования , есть БД , вычислительные модули, пользователь (один, коллективное пользование не обязательно)? интерфейс - табличный, действия относительно простые - заведение данных в БД, заведение данных с текстовых файлов одного формата, просмотр исходных данных и результатов расчётов в таблицах, сортировка и фильтрация, запуск вычислений, некоторые средства анализа, типа выдачи интегральных показателей по группам, экспорт в Excel. Всё на Windows. БД - на MS-SQL Server

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

Но, как обычно, кадры решают все - если кадры имеют опыт работы с Visual Fox, то проблем быть не должно.

>Также нужна возможность работы с графическими схемами (электрические сети), сами графические средства есть, нужно состыковаться. Пока можно и без схем, но чтобы можно было потом приделать.
эээ. не скажу. по идее, через OLE должны быть возможности добраться.

>В дальнейшем желательна возможность строить графики от времени, по данным из БД.
в Фоксе должна быть стандартная приблуда MSGraph для этих дел.
От Константин
К Кудинoв Игорь (12.11.2009 16:27:05)
Дата 12.11.2009 17:14:04

Thanks



>Народ еще хвалит visualBasic или как он там теперь называется.
Да вот это тоже вариант, надо обсудить с коллегами

>Но, как обычно, кадры решают все - если кадры имеют опыт работы с Visual Fox, то проблем быть не должно.

Некоторые имеют, а некоторые нет


!----------------------------------
Вообще, я посмотрел сеть, выяснил, что проклятые янки как всегда и на эту тему сказали и обобщили:
на общетеоретическом уровне
http://en.wikipedia.org/wiki/Rapid_application_development
и на практическом
http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools
От Alex~1
К Константин (12.11.2009 17:14:04)
Дата 12.11.2009 17:37:31

Re: Thanks



>>Народ еще хвалит visualBasic или как он там теперь называется.
>Да вот это тоже вариант, надо обсудить с коллегами

>>Но, как обычно, кадры решают все - если кадры имеют опыт работы с Visual Fox, то проблем быть не должно.
>
>Некоторые имеют, а некоторые нет


>!----------------------------------
>Вообще, я посмотрел сеть, выяснил, что проклятые янки как всегда и на эту тему сказали и обобщили:
>на общетеоретическом уровне
> http://en.wikipedia.org/wiki/Rapid_application_development
> и на практическом
> http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools

Все это теоретическое/практическое великоление - фигня.
1) Раз Microsoft со своим Excel - значит, тулзы должны быть Microsoft'овские.
2) Дальнейшее роли не играет, просто смотришь, что умеют те люди, которые готовы взяться. Результат будет принципиально одинаковый.
3) Ни фига не понял, при чем здесь SOAP, Web-сервсиы и прочая лабуда. :)
От Павел Чайлик
К Alex~1 (12.11.2009 17:37:31)
Дата 12.11.2009 21:12:35

А что непонятного? :))



>>>Народ еще хвалит visualBasic или как он там теперь называется.
>>Да вот это тоже вариант, надо обсудить с коллегами
>
>>>Но, как обычно, кадры решают все - если кадры имеют опыт работы с Visual Fox, то проблем быть не должно.
>>
>>Некоторые имеют, а некоторые нет
>

>>!----------------------------------
>>Вообще, я посмотрел сеть, выяснил, что проклятые янки как всегда и на эту тему сказали и обобщили:
>>на общетеоретическом уровне
>> http://en.wikipedia.org/wiki/Rapid_application_development
>> и на практическом
>> http://en.wikipedia.org/wiki/List_of_rapid_application_development_tools
>
>Все это теоретическое/практическое великоление - фигня.
>1) Раз Microsoft со своим Excel - значит, тулзы должны быть Microsoft'овские.
>2) Дальнейшее роли не играет, просто смотришь, что умеют те люди, которые готовы взяться. Результат будет принципиально одинаковый.
>3) Ни фига не понял, при чем здесь SOAP, Web-сервсиы и прочая лабуда. :)

Ну, надо людям CV разукрасить. Стандартненько... :)))
У нас тут есть одна, как обычно, исторически сложившаяся программа, так она построена аж на CORBA и на Windows и к ней "пристроек" и примочек на всех технологиях какие только придумывались. Зато масса людей, поработав годик и пополнив свой CV, отправилась на поиски счастья по заграницам. :)))

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

А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?
От Константин
К Павел Чайлик (12.11.2009 21:12:35)
Дата 12.11.2009 22:11:30

Re: А что...

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

>А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?

Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.
В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД. Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.

Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:


[99K]



!---------------------------------------
По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
От Кудинoв Игорь
К Константин (12.11.2009 22:11:30)
Дата 13.11.2009 00:03:38

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

>Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.

и в фоксе же обрабатывать. Красиво можно сделать... если хорошо продумать все эти MouseOver и MouseLeave.

>В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
>Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД.
да, обрабатывать правую мышь над каждым объектом, навешивая контекстное меню или показывая панель инструментов. Хотя нынешнее увлечение кнопками до добра не доводит - тут в одной приблуде без текстового меню лектору приходилось говорить "нажимаем белую руку", "нажимаем руку негра"... Описывать или вникать в такой интерфейс просто невозможно, особенно в ч/б документе .

>.... Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.


>Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:

>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.

да, попильные проекты изрядно отягощают обслуживание.
От Павел Чайлик
К Константин (12.11.2009 22:11:30)
Дата 12.11.2009 23:17:33

На чем помешан я...

>Насчёт CV - это да , была такая тенденция - потренироваться на местных проектах, сбить команду и постараться свалить за границу .

>>А мне вот еще интересно (к Константину) что же там за формат представления электрических цепей и как и для чего надо эти схемы стыковать с Вашим приложением? Просто для удобства или для решения каких-то задач?
>
>Это графическое представление реальной высоковольной сети - от 10 кВ (у нас реально от 110 кВ) и выше. Минимальный набор изображений довольно простой - линии, шины подстанций или электростанций, генераторы, нагрузки, трансформаторы + ещё несколько устройств, например батареи конденсаторов.
>В более развитых вариантах делают уже развёрнутые схемы подстанций и станций.
>Всё это привязано к записям в БД о реальных объектах. С графического изображения менять параметры в БД. Наиболее типичное изменение - отключить линию и провести расчёт - посмотреть как измениться состояние сети. При расчётах на схему выводятся результатах, напряжения перетоки мощности и т.д.

Ух... интересно. А в БД фактически граф?
Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме? Я физику тут подзабыл малость, но в общем картину представляю. Вопрос, собственно вот в чем.
Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
Например, можно все представить, для начала, как набор утилит или, чуть глубже, библиотек для конвертации форматов туда-сюда между БД и этими графическими (напишите о каких идет речь). Вот утилитки лучше всего строить (это я со своей колокольни) на xsl:fo. Мы тут внедрили открытый пакет FOP (на Java) с помощью которого можно писать шаблоны ("сценарии") такой вот конвертации. Диапазон возможностей весьма широкий. Пока используем его в отчетности (PDF,XML) и в генерации печатных форм документов в PDF.
Но общие возможности весьма широкие.

Если хотите сэкономить и добиться рабочего состояния за преемлемые сроки, то я рекомендую пойти именно по такому сценарию.
Вместо GUI на первоначальном этапе набор утилиток запускаемых с коммандной строки. Это я предлагаю с учетом того, что с приложением работает один (значить квалифицированный) пользователь и этот пользователь, похоже, инженер. Сами утилитки, тогда, есть просто написанные с использованием каких-то открытых бибилотек собственные библиотечки классов (пакеты Java или библиотеки C) и построенные на их основе элементарные конвертеры. Ковертер, если использовать xsl:fo, будет представлять собой простой процессор (могу помочь с его написанием), который трансформирует один набор данных (представленных в XML) в какой-то другой формат по правилу, описанному в шаблоне (обычно xsl-файл). Шаблон - текстовый файл. Редактировать удобно в массе свободных открытых редакторах со встроенной проверкой синтаксиса, а есть и со встроенными процессорами - сразу протестить процесс конвертации. Если заинтересует - подброшу ссылки по теме.
Ну, еще нужна утилитка экспортирующая данные из БД (нужный набор) в файл XML для дальнейшей трансформации.

Другой вопрос - это, собственно, ваша работа с БД.

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

>Вот пример с одной из наиболее используемых в России программ, довольно старой кстати:

>
>[99K]


> !---------------------------------------
>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.

Ну, или проекты, на поддержку которых не жалеют средств :)))

А вообще, все зависит от того как меняется работа на предприятии. Если не очень, то можно долго работать на одном и том же и даже не самого лучшего качества. Там где все постоянно перестраивают проблем не изюежать.

З.Ы. Мне интересна ваша задача. Я все больше по другим делам.
От Константин
К Павел Чайлик (12.11.2009 23:17:33)
Дата 13.11.2009 12:12:39

Re: На чем

>
>
>Ух... интересно. А в БД фактически граф?
Ну да две таблицы Узлы (шины) и Ветви. Ветви (линии и трансформаторы) связывают узлы в сеть.
>Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме?
Там свои уравнения - фактически закон Ома и первый закон Киргофа. Главная сложность в том, что задаются не источники ЭДС и тока , как в обычной электротехнике, а мощности. Из-за этого уравнения получаются нелинейными, а квадратичными (мощность это U на I). Но их давно умеют решать итерациями , например по методу Ньютона.
Дифференциальная форма там явно не используется, но в скрытом виде входит в поправки сопротивления длинных линий (длинные это скажем более 300-500 км)


>Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
Программа расчёта полностью наша. Но она общается только с БД , через ODBC (так кажется это называется). Оболочка работает только с БД.

Про графику мне говорить трудно, это разработка моего соседа по комнате, я знаю что она есть :).
На утилитках , работающих из командной строки - не пойдёт. Такой товар точно не возьмут .


>>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
>
>Ну, или проекты, на поддержку которых не жалеют средств :)))
Как показывает мой опыт последних лет, деньги необходимое, но отнюдь не достаточное условие успеха. И наличие квалифицированных программистов и технологов тоже.
Это отдельная история, можно как-нибудь обсудить .
От Павел Чайлик
К Константин (13.11.2009 12:12:39)
Дата 13.11.2009 12:48:07

Все интересатее и интересатее :)))

>>
>>
>>Ух... интересно. А в БД фактически граф?
>Ну да две таблицы Узлы (шины) и Ветви. Ветви (линии и трансформаторы) связывают узлы в сеть.

Понятно. Конкретная организация структуры данных не так и важна. Важно на первом этапе понять что за структура в основе.

>>Т.о. вы хотите моделировать все это дело? А движок ваш - это уравнения Кирхгофа в диф. форме?
>Там свои уравнения - фактически закон Ома и первый закон Киргофа. Главная сложность в том, что задаются не источники ЭДС и тока , как в обычной электротехнике, а мощности. Из-за этого уравнения получаются нелинейными, а квадратичными (мощность это U на I). Но их давно умеют решать итерациями , например по методу Ньютона.
>Дифференциальная форма там явно не используется, но в скрытом виде входит в поправки сопротивления длинных линий (длинные это скажем более 300-500 км)


>>Насколько программа, которая, моделирование проводит ваша "родная" или тоже какая-то сторонняя приспособленная разработка? От этого зависят ваши возможности в выборе сценариев.
>Программа расчёта полностью наша. Но она общается только с БД , через ODBC (так кажется это называется). Оболочка работает только с БД.

Ваша, это хорошо. Теперь как я это понял.
Надо:
Читать структуру сети в память (наверное целиком) и проводить некий рассчет с измененными параметрами. Т.е. необходимо создавать копии (проекты) энергосети (ЭС) и проводить с ним процесс "моделирования".
Эксперимент моделирования имеет результаты - набор получаемых характеристик, возможных пределов системы и параметров. Нужно хранить, пусть пока просто "где-то", как этот "экземпляр" ЭС так и результаты его "тестирования" - моделирования нагрузок и всяких "напастей".
Т.е. сами по себе отдельные экземпляры ЭС - изолированны.
Если все именно так, как я понял, и нет никакой дополнительной связи со статистическими данными работы реальных ЭС или они существуют в отдельных структурах (БД и прочее) и программах, то мне кажется, что гораздо удобнее хранить данные не в БД, а в файловой системе. Так как работа тут именно проектная.


>Про графику мне говорить трудно, это разработка моего соседа по комнате, я знаю что она есть :).
>На утилитках , работающих из командной строки - не пойдёт. Такой товар точно не возьмут .

Так это вы на продажу? :)
Я думал сами свои нужны решаете...



>>>По моим наблюдениям - у нас более жизнеспособными оказываются проекты , которые сделаны попроще , побыстрее и меньшим числом людей.
>>
>>Ну, или проекты, на поддержку которых не жалеют средств :)))
>Как показывает мой опыт последних лет, деньги необходимое, но отнюдь не достаточное условие успеха. И наличие квалифицированных программистов и технологов тоже.
>Это отдельная история, можно как-нибудь обсудить .

З.Ы. Стало настолько интересно, что хочу попросить Вас предоставить мне алгоритмы моделирования и структуры ЭС. Я бы поиграл с многопоточной их реализацией (на досуге развлекаюсь обработкой графов многопоточно на Java). Потом подкину Вам библиотеку (пакет). Многопоточно сейчас очень актуально, особенно после того, как можно вполне приобрести рабочую станцию, в которой напихано 4 и больше процессора. А на работе я для своего хобби выпросил себе эккаунт на 16-ти процессорном ящике, где радиоинженеры покрытие рассчитывают. По своему опыту знаю, что вся "старая" реализация математики однопоточная, что несколько удручает.
От Константин
К Павел Чайлик (13.11.2009 12:48:07)
Дата 13.11.2009 18:59:13

Re: Все интересатее...




>
>Ваша, это хорошо. Теперь как я это понял.
>Надо:
>Читать структуру сети в память (наверное целиком) и проводить некий рассчет с измененными параметрами. Т.е. необходимо создавать копии (проекты) энергосети (ЭС) и проводить с ним процесс "моделирования".
>Эксперимент моделирования имеет результаты - набор получаемых характеристик, возможных пределов системы и параметров. Нужно хранить, пусть пока просто "где-то", как этот "экземпляр" ЭС так и результаты его "тестирования" - моделирования нагрузок и всяких "напастей".
>Т.е. сами по себе отдельные экземпляры ЭС - изолированны.
>Если все именно так, как я понял, и нет никакой дополнительной связи со статистическими данными работы реальных ЭС или они существуют в отдельных структурах (БД и прочее) и программах, то мне кажется, что гораздо удобнее хранить данные не в БД, а в файловой системе. Так как работа тут именно проектная.

Да большинство таких программ работают на файлах, в одном случае - используют встроенную БД типа SQLite. В нашем случае переход на БД был вызван следующими обстоятельствами.
1. В программу входил (сейчас уже нет) модуль для работы с телеизмерениями в сети,
2. Планировалась интеграция с БД оборудования. Т.е. не вводить ветку и её сопротивления, а запрашивается параметры скажем воздушной линии длина , марка провода и т.д.
3. Планировалось использовать программу прогнозирования потребления электроэнергии, работающую на статистическом материале.

Т.е. к БД перешли в расчёте на существенное расширение программы.


>Так это вы на продажу? :)
>Я думал сами свои нужны решаете...

Для своих задач вполне хватает, что есть.


>З.Ы. Стало настолько интересно, что хочу попросить Вас предоставить мне алгоритмы моделирования и структуры ЭС. Я бы поиграл с многопоточной их реализацией (на досуге развлекаюсь обработкой графов многопоточно на Java). Потом подкину Вам библиотеку (пакет). Многопоточно сейчас очень актуально, особенно после того, как можно вполне приобрести рабочую станцию, в которой напихано 4 и больше процессора. А на работе я для своего хобби выпросил себе эккаунт на 16-ти процессорном ящике, где радиоинженеры покрытие рассчитывают. По своему опыту знаю, что вся "старая" реализация математики однопоточная, что несколько удручает.

Если кратко, то в тех задачах, что мы делаем сейчас скорость расчётов отнюдь не главная проблема.

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

Параллелизацией таких задач занимались и занимаются. Я посмотрю , что есть на этот счёт .
Задача состоит в многократном решении относительно больших (ну скажем 3-10 тысяч переменных) систем линейных уравнений, при слабозаполненности матриц. Там варианта , как мне представляется два. Можно одну систему решать параллельно. Или правильно распределить всю работу между процессорами если нужно перебрать 1000 вариантов , то поставить перебор так , что на одной 500 и на другой 500.