Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

Воскресенье вечер

Лекция А.А.Зализняка "О профессиональной и любительской лингвистике" на фестивале науки в МГУ 11 октября 2008 -- http://lingvofreaks.narod.ru/zaliznyak.htm. Крайне рекомендую.
* * *
Дискуссия 2000г. про Процессы, Время и Причинность в логике -- http://www.jfsowa.com/ontology/psl_pn.htm. Суть: John Sowa круто наезжает на Process Specification Language, размахивая дубинкой Petri Nets. Обсуждаются такие вопросы, как предпочтительность time points перед event instances или бесконечная скорость света в PSL (я удивляюсь, как они еще запутанные частицы не обсудили).
* * *
Познакомился еще с одним видом танцев -- контактным жонглированием: http://www.abditus.ru/2008/09/kontaktnoe-zhonglirovanie/, http://community.livejournal.com/ru_juggling/68859.html.
* * *
Вышел обзорчик CMS Watch 2008г. по Enterpise Social Software -- в нем предложен сценарый подход (scenario-based approach) к оценке социального софта. Интересны сами сценарии -- как используется социальный софт в организации. Полные описания сценариев доступны в самом отчете (платном), но интересны и их названия (http://cmswatch.com/Feature/187-Social-Software?source=EM1108-1): работа через файерволл -- бреновые клиентские сообщества, взаимодействие с клиентом/читателем, коллаборация с партнерами, профессиональные "знакомства". Работа внутри фаервола -- проектная коллаборация, корпоративная коллаборация, корпоративная дискуссия, организация и фильтрование информации, управление знаниями, сообщества практики, корпоративные "знакомства".
* * *
Имели с vvagr вчера и сегодня две трехчасовых рабочих сессии с использованием Google Talk и Google Doc. Удивительное качество звука -- вчера без единого сбоя, сегодня из трех часов испорчено было секунд двадцать. Этот VoIP год становится год от года все лучше и лучше. К Google Docs больше вопросов: он обновляет страничку на одной стороне через 8 секунд после окончания ее правки на другой стороне. Это крайне неудобно, правка одного слова затягивается впятеро: с 2 секунд до 2+8 секунд, диалог по факту разрывается. Есть ли способ как-то ускорить процесс пересылки изменений?
* * *
Начинали мы эти страдания вокруг выбора слов для датацентрического (концептоцентрического) и документоцентрического (символоцентрического) описаний мира в http://ailev.livejournal.com/611877.html. В результате трех часов споров с vvagr пришли к совершенно парадоксальным и неожиданным переводческим решениям (в большинстве случаев сводящихся к тому, что "cat" с английского договариваемся переводить "животинка"):

1. Model в большинстве случаев не переводится как "модель", а переводится как "описание", при этом мы намеренно игнорируем разницу в датацентрическом и концептоцентрическом описаниях. Ср. картинки
треугольник моделирования -- Dietz
и
Треугольник моделирования
и

(семиотический треугольник, http://ecolotrain.uni-saarland.de/index.php?id=1814&L=1)
и

(семиотический треугольник, http://www.db.dk/bh/core%20concepts%20in%20lis/articles%20a-z/semiotic_triangle.htm).
Таких картинок со слегка меняющейся терминологией столько же, сколько авторов пишет на эту тему. Так что речь идет не столько о конкретном слове "модель", сколько о принципе. Пусть будет у нас "символ/ (информационная) модель / знак" = "описание".

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

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

3. Тем самым model из ISO 42010 (см. прошлые попытка перевода в http://ailev.livejournal.com/612830.html) по факту тоже переводим как "описание", а если это датацентрика, то можем перевести и "модель".

4. Viewpoint из ISO 42010 переводим как "метод описания" -- способ конструирования, интрерпретации и использования наборов описаний, адресующих предписанный набор интересов (concerns) для набора стейкхолдеров.

5. View из ISO 42010 -- это "группа описаний" (полностью -- группа описаний, выполненных по данному методу", например "группа организационных описаний DEMO").

6. Слово framework -- это, безусловно, набор гомонимов.
Одно из значений -- это "подход", понимаемый как набор методов, правил их применения, набор стейкхолдеров, набор интересов, приводящие к созданию, интерпретации и использованию вкачестве норм связанной группы описаний деятельности. Архитектурный подход, процессный и проектные подходы, процессный подход ISO 15288, подход PMBoK, подход ITIL и т.д. Сразу замечу: то, что такое использование чаще всего не совпадает с ипользованием слова "подход" СМД-методологами. Меня больше волнует мнение простых инженеров, с которыми это все придется обсуждать. "Подход" (framework) как по сути своей "метод" отличается от "метода описания" тем, что описывает саму целевую деятельность, а "метод описания" -- описывает только деятельность по описанию деятельности.
Другое значение -- группа.
В зависимости от контекста process famework будем переводить либо как процессный подход, либо процессная группа.

Тем самым фразы типа
"Архитектурный фреймворк -- набор архитектурных интересов, типовых стейкхолдеров, предписанных вьюпойнтов и правил согласования вьюпойнтов, которые были определены для учёта общепринятой практики архитектурных описаний в конкретных предметных областях или сообществах стейкхолдеров"
переводим как
"Архитектурный подход -- набор архитектурных интересов, типовых стейкхолдеров, предписанных методов описания и правил согласования методов описания, которые были определены для учета общепринятой практики архитектурных описаний в конкретных предметных областях или сообществах стейкхолдеров".

Наработано еще много чего, но пока и этого довольно для осмысления.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 15 comments