Обсуждение

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

Запись на быструю флешку -- 10MB/сек, то есть тоже втрое быстрее, чем на обычную (там 3MB/сек).

> Менеджеров интересует нормология, айтишников -- даталогия. А инфология обычно оказывается бесхозной: специалисты не дотягивают до формы (да им и не дают шанса), а айтишники не дотягивают до содержания (впрочем, и им тоже не дают шанса). А как же системные (бизнес) аналитики?

C ними сложно: сейчас они обычно приходят или из айтишников (и тогда собственно бизнес им пофиг, на выходе -- тексты BPML и подобное), или из менеджеров или специалистов (и тогда им не до формальных моделей, на выходе "отчеты" и "аналитические записки").

На Западе есть целая куча продакт менеджеров и бизнес аналитиков. Они бегают и собирают всякие требования, которые собственно и содержат в себе инфологию (т.е. смысловое описание системы). А программеры типа это преобразуют в даталогию (в байтики всякие). Или Вы имеете в виду создание формальных моделей а-ля Гелиш?

Да, формальных моделей типа Gellish, формальных систем для assurance case и прочих требующих формальных нотаций разбирательств со смыслом фактов-информации (а не просто копированием, хранением, пересылкой).

С этим конечно тяжело. Хуже того, если взять софтостроение, то крайне мало людей понимают разницу между Архитектурой ПО и Дизайном ПО. Хотя эти вопросы разбираются в соответствующей литературе (ОО парадигма различает ОО Анализ, ОО Дизайн и ОО программирование), на практике, человек, носящий гордое звание Архитектор, не знает чего делать и занимается обычно какой-то фигней. Параллели с инфо/дата-логией легко провести: Архитектура - взгляд на систему с точки зрения пользователей - работа со смыслами - инфология Дизайн - взгляд на систему с точкиз зрения реализации - преставление в байтиках - даталогия

Если опять-таки обратиться к софтостроению, то, честно говоря, я даже не знаю ни одного моделлера, который позволял бы полноценно делать ОО Анализ. Всеразличные UML-моделлеры и им подобные годятся только для ОО дизайна, подразумевая, что задачу ОО анализа и ОО дизайна можно считать идентичной (так называемый Direct OO Design). Это обстоятельство делает их малопригодными на практике: из соображений производительности/надежности часто требуется адаптировать дизайн, но ведь прдеметная область от этого не должна меняться. Фактически проблема отображения ОО Анализа на ОО Дизайн игнорировалась все время существования ОО подхода.

Ну в правильных ОО языках, метод является объектом, так что моделировать можно в термнах объектов :). Собственно, в приводимой ссылке, дядька так и предлагает делать - отложить процессные решения на потом.

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

Потому как "объект-ориентированного функционала" нет, функционал не объектен (нет разделения на объекты и процессы в этот момент). Адресуется появлением особого шага, на котором сначала разрабатывается онтология, а только затем производится разбиение на объекты. Об этом как раз говорит Chris Partridge, критикуя текущую методологию ОО-разработки: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2007_07_05 (например, сначала говорится о наличии бухгалтерского "баланса", а только затем определяется, будет это "метод" или "объект").

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

Нет, не могу раскрыть. Некогда и неинтересно.