Обсуждение

но совершенно непонятно, как объяснить людям, что нужно прикинуть общий вид слона, перед тем как заниматься изготовлением его кончика хобота и фрагментов левой ноги под общим заголовком "план работ по изготовлению слона". Все виденые мной глобальные проекты страдали одним: конфликты вокруг власти и ответственности. Пока одному платят за хобот, а другому за передние ноги, в "общий вид" оии играть не будут. Это, кстати, работает и для open source. Хоть денег тут нет, но психологию никто не отменял.

Про пиджак - сразу стащил. Спасибо!

Извините, если я кажусь Вам назойливым, но (к вопросу параллельного/последовательного движения мысли/предписания, помните?) вот здесь у Вас: "Весь ужас в том, что и общий вид слона невозможно прикинуть без того, чтобы хоть как-то не поразбираться с кончиком его хобота и фрагментами левой ноги -- или можно закончить общим видом ватного слона, или слона-с-картинки вместо того реального слона, которого заказывали. То есть нужно двигаться и от общего к частному, и от частного к общему одновременно." как раз и проявляется необходимость различить эти два захода - частное/общее и абстрактное/конкретное. "Нога и хобот - слон" обдумываются-предписываются как часть-целое (параллельный доступ), а картинка_слона-ватный_слон-реальный_слон - по линии абстрактное-конкретное (последовательный доступ).

не кажется ли, что уже ранее как минимум один раз была поднималась тема разработки такого языка? Возможно именно это послужило причиной того, что помешало строительству вавилонской башни - смешение языков? :) Если серьезно, то какая роль отводится существующим языкам программирования в рамках обсуждаемой модели? На них будет писаться хоть какая-та часть кода, или это будет абстрактная модель, которую и прочитать без соответствующего IDE будет проблематично? И другой сильно отвлеченный вопрос: насколько мощны, перспективны и/или - предметно-целесообразны нынешние системы, чтобы заменить человека в таком деле, как законадательство, судебное делопроизводство, система розыска конфликтующих патентов в некой базе? О каком доменно-ориентированном языке может идти речь в этих плоскостях? Как проектировать такую систему "от общего ключа", а не исходя из "частного"? Ведь слона-то мы хотя бы раз в жизни видели, а вот что должно получится на выходе для участников крупного проекта - иногда большая загадка и сюрприз - в одном флаконе.

Мне кажется, что я тут пишу как раз не о разработке языка (аналога всеядного "естественного"), а как раз о необходимости разработки множества специализированных, но связанных между собой языков (viewpoints с набором viewpoints correspondence rules). Это соответствует необходимости иметь множество различных моделей объекта (специализированных для целей разных заинтересованных сторон описаний системы). В рамках обсуждаемой системы я вообще не обсуждаю роль современных языков программирования. Меня, например, интересует язык представления данных бухгалтерского учета по правилам МСФО и РСБУ -- какая роль языков программирования в представлении таких данных? Какая роль языков программирования в описании теплогидравлических процессов? Что вы вообще описываете языками программирования из того, что нужно описывать простым инженерам, бухгалтерам и экономистам, менеджерам, планировщикам работ? Насчет замены человека считаю вопрос риторическим и не требующим ответа.

Я никак не пойму, зачем вам различать "параллельный доступ" и "последовательный доступ"? Мне представляется, что в мереологии давно и плодотворно разрабатываются разные типы отношений части и целого (физическая включенность, различные частичные описания против более полных, разные уровни абстракции описаний и т.д.). Я признаю, что все эти типы отношений существуют. Меня интересуют два из них (конкретизация из шаблонов-типов в индивидуальные знаковые модели, а также специализация по уровням абстракции типовых описаний) в абсолютно конкретных случаях для моих производственных надобностей, для немедленного употребления. Зачем просто так поминать на каждом шагу, что "бывают такие различения"? Что дает для ситуации, описанной в постинге, предложение что-то делать параллельно или последовательно?

Я бы проблематизировал и это (хотя у меня как минимум один консалтинговый проект идет сейчас, где я обсуждаю именно необходимость начала оплаты за "общий вид слона", чтобы наладить жизнь в одном крупном холдинге). Можно ведь и так подойти: "пока в общий вид не играют, никто платить за общий вид слона не будет". Корреляция понятна, но вот направление каузальности может быть необычным. Сначала нужно убедить людей играть в общий вид (это долго и трудно), а уже затем люди "автомагически" сами приходят к выводу о необходимости платить за целое "под ключ".

Если б в системе не было обратных связей, было б не интересно.

Вот-вот, только эти "обратные связи" двунаправлены, связывают как резиночка -- двигать независимо можно что угодно, но с какого-то момента с неизбежностью будет затронуто другое. Мне кажется, что в данном случае начинать двигать нужно с экспликации понимания важности целого. Без этого можно ожидать, что кто-то догадается за это целое заплатить, до морковкиного заговенья.

Для меня то что вы пишете о том, что так или иначе затрагивает praxos - весьма интересно. Стандарты, на которые даются ссылки по мере изложения, не относятся к свободнодоступным - вполне понятно, почему продолжить черпать дополнительную информацию, не обращаясь к вам - нет никакой возможности. Было бы неплохно, если на praxos в вики завести список глупых вопросов. Возможно это никогда не станет FAQ, но позволит заинтересованным лицам рассмотреть систему с разных сторон - ведь насколько я понимаю, именно на доступность изложения, и создание единой терминологии (в рамках русского языка) нацелен этот проект? И примеров практического применения бы побольше. Как предложение - можно было бы начать создавать некий проект (малобюджетный, но с достаточной сложностью воплощения), на котором будут испытываться жизнеспособность моделей, терминологий, приемов - в том числе таких, каким образом инженеру нужно перестроить собственные мозги, если сталкивается с определенной неразрешимой симптоматикой: к какой группе проблем следует отнести; следует ли озадачится переходом к другому DSL языку (с возможной переадресацией вопроса другому специалисту), или решать в рамках текущего - требуя его расширения; и др. То есть, вести полную историю по обосновании принятых решений, и как это соотносится в рамках модели praxos. Насчет замены функций человека или даже целого отдела - одной программой или их системой, по моему в этом нет ничего необычного в наш век автоматизации: так если раньше на заводах существовали целые отделы с арифмометрами, сейчас справляется один бухгалтер с компьютером (взят несколько утрированный пример для того, чтобы пояснить, что конкретно имелось в виду).

"Что дает для ситуации, описанной в постинге, предложение что-то делать параллельно или последовательно? " Я с большим интересом и искренней симпатией слежу за Вашими попытками выработки единого языка проектирования-программирования. Вы сетуете на то, что некие "инженеры" Вас плохо понимают. На мой взгляд, это происходит потому, что Вы нарушаете вошедшее в думательный навык и автоматически-привычное для "инженера" различение между механизмом и конструкцией, процессом и формой. Вот опять Вы говорите: "разные типы отношений части и целого (... разные уровни абстракции описаний )" Разные уровни абстракции описаний не относятся как часть-целое. Поэтому инженеры Вас и не понимают.

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

Мы сейчас работаем над тем, чтобы снять дурацкие копирайтные ограничения на тексты стандартов и опубликовать их. Тогда, конечно, все будет много проще и легче. Также к концу года у нас будет много больше разъясняющих материалов. В принципе, члены INCOSE уже сейчас получают в рассылке некоторые внутренние материалы, которые не опубликованы в ЖЖ. Но для включения в эту рассылку нужно потратить $105 на http://incose.ru :) Мы как раз создаем разные проекты с нашими клиентами, и на этих проектах отрабатываем терминологию, техники, инструменты и т.д. Ответственность на программу не повесишь. Так что с "перевешиванием функций" все несколько сложнее.

Спасибо за ссылку на incose. Кстати, какого характера ограничения на копирайт? В частности, если касаться цитирования и перевода текста на другой язык? > Мы как раз создаем разные проекты с нашими клиентами, и на этих проектах отрабатываем терминологию, техники, инструменты и т.д. Пример по одной из организаций помог бы вовлечь в управленческую игру владельцев компаний, что считают достаточными принимаемые ими малоэффективные решения. Про ответственность - полностью согласен, да и гибкость человеческого ума вне конкуренции от любого алгоритмизирования - и в хорошем, и в плохом смысле этого слова :)

Стандарты ISO имеют копирайт ISO, это значит, что я не вправе их копировать (например, публиковать в интернет, переводить на другой язык и т.д.), разве что этот перевод вдруг станет ГОСТом, после чего перестает охраняться копирайтом.