Если делать вебнутым - то питон наилучший вариант.

почему это? ну я понимаю, что тот же GNOWSYS использует ZOPE OODB в качестве бекенда для хранения.

но хорошую вещь «зопой» не назовут. нужна хотя бы лисповая ООБД для хранения объектов, и поверх объектов CLOS, MOP и движок правил.

например, реализовать вот такую штуку типа движка interactive fiction поверх такой ООБД.

или, см. пример про uncharted2.pdf из треда про борщъ-архитектора — там на 65 странице как раз описывается DSL (on ... track ), эквивалентный диаграмме последовательности UML

(а борщь, как всегда, по ссылкам не ходит и распинается про то, что UML лучше этого DSL на ракетке, ЛОЛ)

Я вижу кучу несвязанной информации. Потому что доска здоровая, а стирать лень.

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

а как, кстати, к этой хрени типа Dia плагины пишутся? где-то есть внятный туториал?

можно там к примеру сделать плагином кодогенерацию, что там за API для плагинов, есть ли настраиваемое поведение редактора (типа `операция «пересадка лианы» для ДРАКОН), связать фигуры с источниками данных как в том же MS Visio ?

например, связали Excel с Visio => блок-схема автоматом генерится из Excel таблицы.

осталось такие .csv для Excel автоматом генерировать.

Как раз вебнутый - это джава.

или ушли слишком глубоко

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

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

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

Только проблема IDEF0 в узкой специфике и в некоторых моментах его применить не получится, а проблема UML в серьезной избыточности и неочевидности

АВТОМАТИЗИРОВАННЫЙ КОНВЕРТОР МОДЕЛЕЙ IDEF0 В UML-ДИАГРАММЫ: КОНЦЕПТУАЛЬНАЯ ИДЕЯ

ФОРМИРОВАНИЕ КАРКАСА UML–ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ НА ОСНОВЕ ИСПОЛЬЗОВАНИЯ УНИВЕРСАЛЬНЫХ ОБЪЕКТОВ МОДЕЛИ IDEF0

а как, кстати, к этой хрени типа Dia плагины пишутся? где-то есть внятный туториал?

Вобщем-то к диа можно понаписать разные фишки на том же питоне:

https://projects.gnome.org/dia/

Как раз вебнутый - это джава.

Зачем джава?

Вот кстати киллер-фича для dia была бы - возможность «провалиться» в квадратик и оказаться на другой странице, где уже внутренности этого квадратика подробно разрисованы.

Вот именно эта фича и привлекает больше всего в IDEF, там она by design и предусмотрена даже для печати на бумаге. Будет очень хорошо по этому же принципу раширить IDEF для проектирования ПО.

Логичнее было бы взять за основу Dia и дописать к ней функциональность IDEF0.

для моделлера IDEF0 смотри Ramus на жабе: скрины — есть образовательная и Open версия с исходниками.

К слову о Ramus. Оно имеет три серьнзных недостатка:

1. Оно проприетарное.

2. Оно просто неимоверно глючное.

3. Этот набор неимоверных глюков стоит весьма не мало.

а проект не требует граф.ускорения на видеокартах - то его вебнутый вариант считаю наиболее приемлимым.

да хоть бы и требовал. сейчас с WebGL, asm.js и threede.js можно запилить нормальный OpenGL в нормальном браузере, который HTML5 держит.

Затем, что там весь веб давно из коробки.

есть версия с открытыми исходниками. можно её посмотреть, поковырять.

кстати, а что ещё есть для IDEF0 кроме BPwin / process modeller и Ramus?

какая-то старая фигня для windows 3.11 ?

какой-то современный годный моделлер в природе существует, кроме этих двух?

только для временных небольших заметок.

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

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

поэтому нужен простой текстовый формат для описания диаграмм.

вроде XML, JSON, latex pstricks, dot, org-mode babel, FSML из UniMod,

markdown/org-mode + вики

Искал что-то современное, но для своих целей остановился на образовательной версии Ramus'а. Пожалуй это единственное что есть нативного под линукс.

Затем, что там весь веб давно из коробки.

Вот пусть оно в этой коробке и дальше лежит. Джава в этом проекте не уместна.

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

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

Если что пиши мне на мыло valor [et] sincore.ru или jabber (в профиле) Есть опыт в python. немного flask и значительно больше django. Чем смогу помогу.

Всё-таки эстетическое восприятие не запрограммируешь, а в диаграммах оно тоже имеет вес.

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

поэтому и нужно найти другое решение для представления документации.

Гм. Когда это мы успели скатиться в документацию?

Но ты прав, с текущим трендовым code-first подходом, решение вполне очевидное. Картинки должны генерится на основе кода, а не наоборот. Или не дай бог вообще в отрыве.

можно сделать в виде веб-сервиса

Всё можно сделать в виде веб-сервиса. Но не нужно.

Вроде http://ru.wikipedia.org/wiki/ARIS крутой считается.

Кроме того, архитектура, как правило, меняется много быстрее чем схемы (если они вообще когда-нибдуь правятся после первой версии, гг).

а вот именно поэтому у нас не должно быть статичных картинок и устаревающих документов с картинкаме.

вместо этого, должен быть подход как в грамотном программировании Д. Кнута: все эти картинки должны генерироваться org-mode babel из какого-то DSL описания, и разрабатываться совместно, одновременно (single source): картинки, исходники, документация для программиста, документация для пользователя.

код как модель, исполняемый код, который генерирует картинки и описание архитектуры по модели, DSL.

это совсем про другое. совсем другой язык моделирования: нотация, подход, метод, инструментарий. и опять таки, нормальный ARIS CASE инструмент стоит сотни нефти.

взаимодействия нескольких пользователей

Да.

интеграции с сетевыми сервисами

Возможно.

Еще нечего кодить, а уже устроили срач о том, на каком языке кодить. Круто.

Я так и не понил - это должно быть визивиг или пользователь будет вводить схему на каком-то языке?

Где вообще ТЗ?

Вот кстати киллер-фича для dia была бы - возможность «провалиться» в квадратик и оказаться на другой странице, где уже внутренности этого квадратика подробно разрисованы

генерируем SVG со ссылками, сводим страницы по ссылкам в вики-систему с рисовалкой, PROFIT

В настоящее время, только UML ближе всех подобрался к автоматизации этой работы

да ладно, не только он. моделеориентированный UML 2.0 такой моделеориентированный, лол.

любой простой DSL гораздо более моделеориентирован.

UML слишком общий, концептуальный — и плохо подходит для конкретной кодогенерации. кодогенерирует только заглушки, а код вписать надо руками.

посмотри те же SWITCH или ДРАКОН-схемы — генерируется полноценный исполняемый алгоритм.

посмотри тот же DSL типа из uncharted — события, сигналы, акторы, свойства, символьные вычисления на списках свойств, метаданные

Но в нем есть серьезный недостаток - UML черезчур нагружена и те рисульки которые на нем можно рисовать не нужны широкой аудитории, поэтому и нужно найти другое решение для представления документации.

фатальный недостаток не UML этом. а в том, что например, в отличие от BON из Eiffel отсутствует reversability, а в отличие от SWITCH/ДРАКОН схем нельзя более конкретно указать как именно кодогенерировать в этом случае.

две тарелки борща этому господину

Чувак, девяностые закончились, такой фигней уже перестрадали.

Всё-таки эстетическое восприятие не запрограммируешь, а в диаграммах оно тоже имеет вес.

про эстетское восприятие — и рекомендую ознакомиться с ДРАКОНом В. В. Паронджанова и его книгами. там расписаны цели и задачи получения

«эргономичных» описаний алгоритмов, схем — в отличие от обычных как попало, неэргономичных.

и способы преобразования неэргономичных в эргономичные (та же «пересадка лианы»).

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

да, нужно — способы должны быть равноправны. один более детален, конкретен — другой более нагляден.

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

Я так и не понил - это должно быть визивиг или пользователь будет вводить схему на каком-то языке?

Где вообще ТЗ?

ТЗ собирается из обсуждения. ИМХО сейчас вопрос номер один - как эту инфу удобнее представить чисто графически. Можно конечно просто закопипасить все точ-в-точ как IDEF0 но ведь еще нужно это расширить до специфики моделирования ПО.

Прям сейчас можно свести к такому:

1. Выводим на обсуждение способ предоставить проект ПО для человеческого глаза в виде удобных и лаконичных схем. Здесь нужно все хорошо продумать и обсудить.

2. Исходя и п1 решаем в как лучше всего хранить инфу: JSON, XML, свой велосипед и т.д. (обзовем пункт датафайлом)

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

4. После чего датафайл можно будет отобразить в интерактивном виде через вебморду, или гуевину.

5. Создаем гуй/вебморду для проектирования схем без существующего исходного кода (для новых проектов). На выходе получаем тот же датафайл для дальнейшего использования.

6. ...

7. Profit

а вообще нужно пересмотреть и от реверс инжинирить всю практику моделирования, проектирования, кодогенерации и порождающего проектирования

что-то вроде того, что А. И. Левенчук [http://ailev.livejournal.com/1013825.html#]пишет про метанойю :

Обучение просветлению Например, Олег Бахтияров сказал: «давайте мы возьмем восточные практики и разделим их на две части – не связанные с религией «психотехники», и связанные с религией. Давайте откинем всё, связанное богами разного типа — ведическими богами, буддийскими богами, всеми другими богами. Разберемся с психотехниками в их чистом виде, не замутнённом религией. Что адепты восточных практик такое делают у себя внутри головы, что просветляются?». Вы знаете все эти анекдоты, что надо ударить палкой по голове вовремя, чтобы у вас появилось «пустое сознание», чтобы вы «пробудились».

Такая постановка вопроса имеет непосредственное отношение к системной инженерии – примерно так же можно ставить вопрос и о том, «что такое делает внутри своей головы системный инженер, что у него в голове помещается огромная система как целое?». Кстати, и сам Бахтияров начинал эти исследования с близкой предметной области, с космонавтики. Он вместе с Ждановым занялись проблемой здоровья космонавтов, которые в самом начале пилотируемых полётов не могли находиться в невесомости более нескольких часов – вся сердечно-сосудистая система у этих космонавтов приходила в сильное замешательство через несколько часов на орбите, и ни о каких длительных полётах не могло быть и речи: подскакивало давление, учащалось сердцебиение и т.д.

А сейчас космонавты болтаются на орбите по полгода, по году, и ничего фатально страшного с медицинской точки зрения не происходит. Бахтияров и Жданов взяли йогу – самую обычную индийскую практику йоги, отрезали от неё всё религиозное, и приспособили для поддержания в норме сердечно-сосудистой системы в невесомости. Усовершенствованные древние техники управления организмом оказались способными держать космонавтов на орбите сколько хочешь, нормализовать кровоток, унять сердцебиение, привести космонавтам нервы в порядок. После перестройки Бахтияров и Жданов продолжили исследования – Бахтияров занялся психопрактиками, а Жданов продолжил исследовать влияние йоги на физиологию. Бахтияров заинтересовался конечной целью йоги, а также большинства других восточных практик – просветлением, которое он рассматривал с его психопрактической (как режим работы мозга), а не религиозной стороны. Что такое просветление, никто точно не знает – это типичное «искусство».

также задаю все время вопрос о пользе этих просветленческих психопрактик для интеллектуальной деятельности, а не связанной с физическими упражнениями – [..] Так что я вам сейчас рассказываю про скоростное обучение просветлению не как рекламу, чем вам нужно бы заняться, а как пример скоростного обучения тому, что тысячи лет никто не понимал, как оно там в голове устроено, и чему и как именно нужно учить. В среднем у западных людей (по оценкам Кена Уилбера) прохождение просветленческой психопрактики занимает 6 лет, а менее образованные и подготовленные люди Востока (не забываем, что просветлённые происходили главным образом из крестьян, уходящих в монастыри) одолевали переход в этот режим за 6-12 лет, а то и больше. Древние техники просветления иногда срабатывают, иногда нет, иногда они безопасны, иногда нет. Что делает Бахтияров? Он придумывает технологию обучения мозга работать в режиме просветления – гарантированно за три года, а для особо способных – за два года. И утверждает, что сейчас (после более глубокого понимания и проведённых новых экспериментов) планирует существенно сократить и это время. Буддисты пригласили его преподавать просветление в Элисте, где находится крупнейший буддистский храм Европы. Буддисты честно признали, что с религиозной частью они справятся сами, но вот собственно просветление светская технология Бахтиярова даёт надёжнее и быстрее, чем их многотысячелетний опыт. И у них в Элисте получается при этом конкурентное преимущество: традиционных буддистских просветлённых они могут готовить в разы быстрее, чем в любых других религиозных центрах.

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

Вместе с Анатолием Ткачёвым они смотрели множество видео с выступлениями гениев тайцзицюаня, и пытались понять, что же там происходит – но не в традиционно предлагаемых китайских витиеватых метафорах, сопровождающих обучение уже тысячи лет, а во вполне рациональных понятиях. Они выяснили, что там никаких особых чудес нет, всё отлично объясняется физикой и физиологией. Борис Майер затем взял группу деток и по своей технологии за девять месяцев подготовил их так, что они в соревнованиях по тайцзи били группу занимающихся пять-шесть лет –- ускорение за счёт использования контринтуитивной образовательной технологии где-то в семь раз по сравнению с традиционными практиками выращивания людей из тайцзи.

Борису Майеру ставили в упрёк, что он нарушил тысячелетнюю традицию тайцзицюаня, «цепь времён». Но он демонстрирует свои собственные достижения – победы на китайских и корейских соревнованиях, одобрение своего китайского учителя, профессора тайцзицюаня, который тренировал ещё личную гвардию Мао Цзе Дуна. Он просто демонстрирует на всех соревнованиях наличие у своих учеников всех тех умений, которые были предусмотрены многотысячелетней традицией – но предлагает всем желающим научиться этим умениям за многократно более короткое время, чем это было возможно ранее. Упражнения у него другие, слова при этом он говорит другие – на русском, а не китайском языке, а результат при этом получается тот же. Он заменяет метафоры точными формулировками, выраженными тщательно подобранными словами, он точно знает, какие именно рефлексы он тренирует (оказалось, что тайцзицюань задействует довольно древние по эволюционным меркам механизмы работы мозга), и получает за счёт этого резкое ускорение передачи знания – прежде всего за счёт того, что это знание было эксплицировано, выражено явно.

UML черезчур нагружена и те рисульки которые на нем можно рисовать не нужны широкой аудитории, поэтому и нужно найти другое решение для представления документации.

мой вариант: программируемые вики, в которых лежат weaved документы в org-mode babel разметке для грамотного программирования, с семантикой.

как обобщение и дальнейшее развитие идеи грамотного программирования. сюда же, см. Active Essays

все чанки для weaved документа лежат в ООБД (можно написать FUSE интерфейс для ООБД, прикинуться файловой системой). у них есть семантические свойства, которые можно интроспекцией посмотреть и обойти. например как в semantic wiki RDF + SPARQL или попроще — просто ООБД.

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

чанк может быть объектом или метаобъектом (например объектом метакласса GnuBuildSystem с перекрытым методом new который запускает make). объектная система — прототипная как в JS или CLOS как в CL.

документ компилируется в «датафайл» — Skribilo AST документ, который затем транслируется в PDF/html/odf/docx/whatever

систему событий и сигналов объектов и метаобъектов в ООБД можно программировать «изнутри» такой «программируемой вики».

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

поверх можно накрутить MVC типа Dia или википедии.

да, это одно и то же — из-за поддержки interactive scene graph (например, JS + AJAX + Canvas / lambdawiki)

и нужно найти другое решение для представления документации

ваши варианты?

мои варианты способов реализации

1. ДРАКОН, SWITCH-технология, UML. в идеале, редактор диаграмм должен быть ортогонален используемой нотации, но понимать специфические для конкретной нотации расширения. например, идея «прикрутить свой DSL» к редактору, простой язык описания блок-схем типа того что в flowchart.js и т.п.

2. текстовый файл регулярной структуры, который можно писать /читать/ транслировать. понятная DOM этого «объектного» документа, спецификация объекта (и/или, текстового представления DSL).

конкретный формат — не важен. важны требования к прозрачности и нейтральности от реализации.

3. org-mode babel, грамотное программирование. на выходе — чанки, имя файла чанка = метка. в идеале, это не файлы в ФС, а объекты в ООБД, и обоойти их можно произвольным способом.

4. в первом приближении, компиляция org-mode babel в HTML + SVG или pdf. во втором, что-то вроде flowchart.js

5. что-то вроде svg-edit.js или отдельный редактор: Dia с плагинами, пример с хабра на wxPython

....

давайте свои варианты или критику.

Сама идея такая воздушная и похожая на «А давайте сделаем крутую штуку. Ну что бы круто был».

А вместо прояснения

Бэкэндщики, жабаскриптеры, верстальщики/рисовальщики ..кто может нарисовать вменяемый внешний вид.

кстати, для Dia есть dia2code

проблема UML в серьезной избыточности и неочевидности

Ну не знаю... пользуюсь пропирастнм Visual Paradigm for UML - избыточности не вижу, а вижу, - напротив, - отсутствие питонячьих типов и разных мелочей связанных с питонячьми ормами. Кроме того добивает отсутствие кое-каких стереотипов. А так UML - наше фсе!)

и наоборот, из сорцов в UML DSL для картинок

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

1. Зачем это делать?
2. Что именно сделать?
3. Почему именно это надо сделать?
4. Кто именно это будет делать?
5. Во сколько именно это обойдётся?
6. Когда получим результат и во сколько времени это обойдётся?
7. Проблемы и риски?
8. Цели проекта и критерии приёмки?
9. Кому это нинужно? Или нужно?

огласите весь список.

Зачем это делать?

Жаст фор фан + в топике написано зачем.

С пункта 2 по 9 иди на хабр за ответами.

А вместо прояснения

Вместо прояснения читай коменты, проект рождается в них.

давайте свои варианты или критику.

Чуть позднее соберу свои мысли по поводу проекта и размещу сдесь. Насчет ДРАКОН'а идея не плохая, достаточно простой язык. Нужно углубиться в эту сферу.

Насчет ДРАКОН'а идея не плохая, достаточно простой язык.

Это не язык проектирования.

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