Здравствуйте, eao197, Вы писали:

E>Но что, если отказаться от использования зоопарка языков и компиляторов? А взять всего один C++ компилятор. И компилировать все одним компилятором с одинаковыми настройками (release, multithreading shared rtl)? Можно ли тогда получать в C++ компонентность?

E>Да. И без особых проблем. И тому есть примеры.
Угу. Особенно удачными получаются примеры сращивания, к примеру, библиотек, построенных на борландовых AnsiString c MFCшными CString. От тут то лепота просто преть.
Самое приятное, что эти заразы до сих пор с std::string дела иметь не хотят. Так бы хоть способ был кошерный трансформации строк...
К чему это я? Да к тому, что вот у Java все в порядке именно благодаря во-первых широкому охвату базовой библиотеки (сразу при выходе Java разработчику почти не оставалось места под велосипедостроительство) а во-вторых благодаря динамичной стандартизации. Поэтому можно писать EJB приложение не особо беспокоямь, что за сервер будет его хостить. Можно писать сайт на JSP, а уж потом выбирать между Resin и Tomcat. Если я пищу JDBC драйвер, то у меня есть спецификация. Есть ли невиндовый стандарт доступа к данным в плюсах?

E>А удалось достичь этого благодоря тому, что инструмент был расчитан только на C++ и на то, что все компоненты будут создаваться с использованием именно этого инструмента (как я понимаю, в Обероне и Зононе точно такая же ситуация). Конечно, наша технология не позволит создать инструменты типа Януса, Ворда или Konquerer-а. Но вот построить несколько черных ящиков, обрабатывающих какие-то события и обменивающихся данными между собой -- легко. А все остальное можно с помощью KParts в KDE сделать (Linux forever! )
E>)
Сам по себе язык — гол. Даже если затачиваться не только на язык, но и на конкретный компилятор. Надо еще и с логарифмической линейкой в руках следить за используемыми библиотеками.
E>Собственно резюмируюя хочу сказать, что успех Java (как и .Net) в области интероперабельности связан с тем, что Java не платформенно-независимый язык, а платформа.
Точно. Кстати, у дотнета пока что есть огромный шанс облажаться. Потому как пока что-то не видно инициатив МС по стандартизации типовых решений. То есть опять мы имеем триста разных подходов к проектированию форм, а стало быть огребем себе и нестандартных почт, и много чего еще... Дотнет пока что спасается благодаря наличию толстого API, доступного через интероп. Потому нет особого риска нарваться на два независимых интерфейса к 3d, к примеру. Все едино это будет ДиреетХэ, как ты его ни оберни...
E>А в рамках единой платформы можно делать все, что угодно. C++ -- это действительно платформенно-независимый язык. Он не зависит ни от .Net, ни от Windows, ни от Unix. Но его пытаются притянуть на чуждые ему платформы (имеется в виду OLE/COM/.Net), потому и результат получается такой, как получается. Но вот если платформу сделать родной для C++ (как в KDE или в нашей агентной технологии), то компонентность на C++ вполне достижима. Однако такая компонентность будет являться вещью в себе (как Java со своими Java-технологиями сейчас), а это, вероятно, в настоящий момент не слишком востребованно

Здравствуйте, Sinclair

Согласен почти со всем написанным за исключением, разве что:

S>- поэтому можно просто пойти туда, скачать доку, и начать разработку

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

Здравствуйте, eao197, Вы писали:

E>То все не так просто, то ли я был туповат, то ли не в ту команду попал, но именно освоение непомерного множества разных стандаров и их имплементаций, а так же переход с одного устаревшего стандарта на другой, более новый, а затем на следующий, еще более новый, как раз разработку и не ускоряли, и не упрощали, и не делали ее более качественной и надежной.
E>Сам такое видел. Может быть это и единичный случай, но осадок остался.
Конечно. Просто в Java удельный вес языка гораздо ниже. Смысл — именно в том, что мы после недельного тренинга получаем человека, способного читать на Java. Учить человека читать на плюсах нужно как минимум полгода, и то он будет периодически вставать в паузу при виде кода гуру.
После того, как программер научился читать, его можно постепенно учить писать. Вот для этого уже нужны библиотеки, и стандартизованность и наличие доки здесь только плюс.
Да, типовой интернет-проект имеет дело с 5-10 стандартами. И совсем новичку сначала довольно тяжело. Однако уже следующий интернет-проект ему делать легче.

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

Здравствуйте, Владик, Вы писали:

В>>>Что ты будешь делать на Обероне, если при преобразовании длинного целого в короткое возникнет ошибка?

СГ>>Какая ошибка?

В>Ошибка невозможности представления преобразовываемого значения в виде короткого целого.

Так ведь, при преобразовании, например, от 64 к 16 битному представлению берутся младшие (или старшие, в зависимости от архитектуры процессора) 16 битов из 64 и просто копируются. Все дела. То что исходное число могло быть больше или меньше ни кого уже не волнует:

http://www.rsdn.ru/Forum/Message.aspx?mid=1241852&only=1

Автор: Сергей Губанов
Дата: 27.06.05

Проверить вхождение числа в диапазон допустимых значений — дело программиста

IF (MIN(SHORTINT) <= i64) & (i64 <= MAX(SHORTINT)) THEN
  i16 := SHORT(SHORT(i64))
ELSE
  делай что хочешь...
END

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так ведь, при преобразовании, например, от 64 к 16 битному представлению берутся младшие (или старшие, в зависимости от архитектуры процессора) 16 битов из 64 и просто копируются. Все дела. То что исходное число могло быть больше или меньше ни кого уже не волнует:

СГ>http://www.rsdn.ru/Forum/Message.aspx?mid=1241852&only=1

Автор: Сергей Губанов
Дата: 27.06.05

СГ>Проверить вхождение числа в диапазон допустимых значений — дело программиста
СГ>

СГ>IF (MIN(SHORTINT) <= i64) & (i64 <= MAX(SHORTINT)) THEN
СГ>  i16 := SHORT(SHORT(i64))
СГ>ELSE
СГ>  делай что хочешь...
СГ>END
СГ>

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

TYPE
  WHAT_TO_DO_IF_OUT_OF_RANGE =
  ( alert,    (* кинуть исключение *)
    rollover, (* перекрутить по модулю - т.е., в данном случае, срезать старшие биты *)
    limit,    (* прижать к границе *)
    garbage   (* вернуть что попало *)
    default   (* выполнить стандартное преобразование и будь что будет *)
  );

PROCEDURE i64to16(x: LONGINT, hint: WHAT_TO_DO_IF_OUT_OF_RANGE): SHORTINT
BEGIN
  IF (x & ~0xFFFF) # 0 THEN
    (* анализируем hint *)
    CASE hint OF
      alert: THROW(OutOfRange) |
      rollover: x := (x & $FFFF) |
      limit: IF x<0 THEN x := MIN(SHORTINT) ELSE x := MAX(SHORTINT) |
      garbage: x := 0 |
      default: x := x
    END
  END;
  RETURN SHORT(SHORT(x))
END

И то, можно предположить, что параметр hint будут использовать случайным образом (стратегия Garbage In, Garbage Out, — если x заведомо в пределах, то нечего и беспокоиться).

А в минимальном случае (и с прицелом в сторону производительности — чтобы не вызывать лишний раз функцию, да ещё с доп.параметром) — будут писать по месту:

z := SHORT(SHORT(x)) + SHORT(SHORT(y)); (* N.B. не забыть где-нибудь сделать ловлю исключения *)

Собственно, ариановцы примерно это и сделали.

Здравствуйте, Sinclair, Вы писали:

S>- все API стандартизуются централизованно. Есть авторитативный центр, который может дать четкий ответ на вопрос "какие стандарты действуют в этой области".

Может это от молодости технологии и пока еще небольшой ниши применения?
Вот, кстати, что сейчас является стандартом на GUI в Java: awt, Swing или SWT?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так ведь, при преобразовании, например, от 64 к 16 битному представлению берутся младшие (или старшие, в зависимости от архитектуры процессора) 16 битов из 64 и просто копируются. Все дела. То что исходное число могло быть больше или меньше ни кого уже не волнует:

А ведь ничего хорошего в этом нет.

Здравствуйте, Sinclair, Вы писали:

S>Точно. Кстати, у дотнета пока что есть огромный шанс облажаться. Потому как пока что-то не видно инициатив МС по стандартизации типовых решений. То есть опять мы имеем триста разных подходов к проектированию форм, а стало быть огребем себе и нестандартных почт, и много чего еще... Дотнет пока что спасается благодаря наличию толстого API, доступного через интероп. Потому нет особого риска нарваться на два независимых интерфейса к 3d, к примеру. Все едино это будет ДиреетХэ, как ты его ни оберни...

Насколько я знаю OpenGL в C# тоже доступен, и уже есть приложения на C# + OpenGL.
Вообще с 3D API и в С++ не большой выбор.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Так ведь, при преобразовании, например, от 64 к 16 битному представлению берутся младшие (или старшие, в зависимости от архитектуры процессора) 16 битов из 64 и просто копируются. Все дела. То что исходное число могло быть больше или меньше ни кого уже не волнует:

Мда... И после этого кто-то позиционирует этот язык как высокоуровневый и безопасный??? С "оверхедом" и так давно все ясно. Все, я окончательно разочаровался в его хоть какой-то практической ценности.

P.S. Присоединяюсь к просьбам показать решение реальных задач на обероне.

Здравствуйте, eao197, Вы писали:
E>Вот, кстати, что сейчас является стандартом на GUI в Java: awt, Swing или SWT?
А меня-то что спрашивать? Я на джаве только читаю. В последний раз с ней имел дело в 2001.
Рекомендую обратить свое внимание на http://java.sun.com/

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, eao197, Вы писали:
E>>Вот, кстати, что сейчас является стандартом на GUI в Java: awt, Swing или SWT?
S>А меня-то что спрашивать? Я на джаве только читаю. В последний раз с ней имел дело в 2001.
S>Рекомендую обратить свое внимание на http://java.sun.com/

А я к тому, что в Java со временем ситуация со стандартами будет не такая однозначная, как сейчас. Насколько мне известно, Swing (который как бы стандартный) проигрывает в популярности SWT (который из Eclipse). И вот если бы я был Java разработчиком, то в какую сторону мне нужно было бы смотреть?

eao197 wrote:

> S>А меня-то что спрашивать? Я на джаве только читаю. В последний раз с
> ней имел дело в 2001.
> S>Рекомендую обратить свое внимание на http://java.sun.com/
> А я к тому, что в Java со временем ситуация со стандартами будет не
> такая однозначная, как сейчас. Насколько мне известно, Swing (который
> как бы стандартный) проигрывает в популярности SWT (который из
> Eclipse). И вот если бы я был Java разработчиком, то в какую сторону
> мне нужно было бы смотреть?

Без разницы, на самом деле. Те кому нравится SWING — пишут на нем, кому
нравится SWT — на SWT. Хотя SWING чуть лучше подходит для сложных GUI.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>eao197 wrote:

>> S>А меня-то что спрашивать? Я на джаве только читаю. В последний раз с
>> ней имел дело в 2001.
>> S>Рекомендую обратить свое внимание на http://java.sun.com/
>> А я к тому, что в Java со временем ситуация со стандартами будет не
>> такая однозначная, как сейчас. Насколько мне известно, Swing (который
>> как бы стандартный) проигрывает в популярности SWT (который из
>> Eclipse). И вот если бы я был Java разработчиком, то в какую сторону
>> мне нужно было бы смотреть?

C>Без разницы, на самом деле. Те кому нравится SWING — пишут на нем, кому
C>нравится SWT — на SWT. Хотя SWING чуть лучше подходит для сложных GUI.

Я вообще-то к тому, что сейчас в Java стараются все стандартизировать, чтобы затем были независимые реализации этих стандартов. Но, поскольку нельзя объять необъятного, то ситуация со стандартностью библиотек должна рано или позно ухудшиться. Вот не устраивает же людей стандартный Swing -- сделали нестандартную альтернативу SWT. Т.е. процесс пошел. Так же в свое время и C++ на части разорвали, когда вместо согласованных библиотек каждый делал что хотел. Ну да это совсем другая история...

eao197 wrote:

> C>Без разницы, на самом деле. Те кому нравится SWING — пишут на нем, кому
> C>нравится SWT — на SWT. Хотя SWING чуть лучше подходит для сложных GUI.
> Я вообще-то к тому, что сейчас в Java стараются все стандартизировать,
> чтобы затем были независимые реализации этих стандартов. Но, поскольку
> нельзя объять необъятного, то ситуация со стандартностью библиотек
> должна рано или позно ухудшиться. Вот не устраивает же людей
> стандартный Swing -- сделали нестандартную альтернативу SWT. Т.е.
> процесс пошел. Так же в свое время и C++ на части разорвали, когда
> вместо согласованных библиотек каждый делал что хотел. Ну да это
> совсем другая история...

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>У Java другая проблема — есть стандарты, но они достаточно ограниченные.
C>Вот каждый и делает свои нестандартные велосипеды.

Велосипедисты всюду пролезли! Как там говорилось в анекдоте — "спаси нацию, бей жидов и велосипедистов", видно товарищ был прозорлив.

Кодт wrote:

> C>У Java другая проблема — есть стандарты, но они достаточно
> ограниченные.
> C>Вот каждый и делает свои нестандартные велосипеды.
> Велосипедисты всюду пролезли!

А как же, они как и евреи — везде есть.

> Как там говорилось в анекдоте — "спаси нацию, бей жидов и
> велосипедистов", видно товарищ был прозорлив.

Ну про евреев — все понятно

А велосипедистов-то зачем? Они хорошие — из их велосипедов вырастают
мотоциклы, автомобили и Боинги-747.

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, CrystaX, Вы писали:

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

CX>Кстати, я тут недавно приводил

Автор: CrystaX
Дата: 23.05.05

примерную реализацию на C++ систем единиц. Сам ею пользуюсь теперь. Что интересно, результат получился довольно приличный.
CX>1. Переменные, обозначающие разные физические понятия (такие как масса и длина, например), не приводятся друг к другу автоматически.
CX>2. В случае присвоения одной переменной значения другой (обозначающей то же понятие, но в другой системе единиц), происходит аквтоматический пересчет из одной системы в другую.

Очень интересный пример. Спасибо!
Вообще, в ходе данной дискуссии я познакомился с очень интересными фрагментами кода: Ваш пример; пример, который привел eao197 (тема: а generic-и так могут?), и ответ на это Sinclair.
Но, честно говоря, когда я "ляпнул" фразу о разных типах данных для разных единиц измерения, я имел в виду более простую вещь: не дать типам приводиться друг к другу произвольно. В переложении на Си++: завести на каждую единицу измерения класс и определить над этими классами набор операторов, позволяющих контролировать соответствующие преобразования.
Это была "беглая" мысль, которую я сразу "излил" на клавиатуру. И, возможно, зря. (Хотя я рад, что благодаря этому познакомился с Вашим кодом.)
Во-первых, eao197 правильно сказал, что, скорее всего, программисты, скорее, использовали такие понятия, как "дистанция", чем конкретно "метры" или "футы". Т.е. они и ввели бы тип "дистанция", а не "метры" и "футы". Но все же из этого можно извлечь урок на будущее.
Во-вторых, как раз Оберон в "классическом" своем варианте (правда, есть и другие разновидности Оберона) и не позволил бы ввести естественным образом такие типы, т.к. в нем нет перегрузки операторов. Поэтому пришлось бы использовать процедуры-функции.
Подробнее см. ниже.

CX>Что примечательно, работает это вообще без оверхеда в run-time. Посему вопрос — можно ли в Обероне, или в Ада, или в Модула-2 сделать подобное же? Если можно, то можно ли сделать это с нулевым run-time оверхедом? Если да, то останется ли использование этих переменных синтаксически таким же?
CX>Вопросы не флейма ради, а действительно интересно.

Здесь я отвечу только на вопрос об Обероне. (Думаю, что для Модулы-2 ответ будет близким. А вот насчет Ады — не уверен. По крайней мере, там есть перегрузка операторов.)
Действительно, в Си++ решение проблемы не должно создавать "оверхеда" в run-time. (Такова, собственно, была цель создателя языка.)
Создаем классы для единиц измерения, операторы (бинарные, а для перевода родственных единиц измерения из одной системы елиниц в другую — explicit конструкторы) преобразования их друг в друга. Благодаря тому, что операторы будут объявлены как inline, оверхеда не будет. Конечно, немного муторно, но чего не сделаешь ради благородной цели — предотвращения ошибок.
Ваш вопрос заключался в том, как это сделать на Обероне.
Например, реализация для ETH Oberon была бы схожей с реализацией на Си++ и, возможно, не приводила бы к "оверхеду".
(Возможно, потому что я не знаю точно, позволяет ли ETH Oberon встраивать процедуры, наподобие того, как это делает XDS.)
Вот как это могло бы выглядеть:

TYPE
  Meters*  = RECORD [NOTAG]
    x: REAL
  END;
  Feet*    = RECORD [NOTAG]
    x: REAL
  END;

  PROCEDURE "+" * (a, b: Meters): Meters;
    VAR c: Meters;
  BEGIN
    c.x := a.x + b.x;
    RETURN c;
  END "+";

  (* и далее - куча других операторов *)

Надо сказать, что ETH Oberon (в современном виде) позволяет многое из того, что не входит в "дубовые требования" (стандарт Оберона-2 de facto).
Например:
— перегрузка операторов (ради чего специально разрешен возврат структурных переменных);
— при импорте SYSTEM можно игнорировать возвращаемое значение функции (что прежде всего применяется
к возвращаемым значениям Windows API, котрые программист считает возможным игнорировать).
Как и большинство компиляторов Оберона, используемых в "чужеродной" среде, ETH Oberon позволяет создавать структурные типы без "тэга". В основном, чтобы взаимодействовать с кодом, написанным на Си и других языках.
"Тэг" обероновской записи отчасти похож на указатель на таблицу виртуальных функций в Си++. Но в одном дескрипторе обероновского типа содержится сразу три таблицы:
— присоединенных процедур (аналог виртуальных функций в Си++);
— базовых типов;
— указателей, входящих в состав записи (для поддержки работы сборщика мусора).
Обыкновенно, обероновская запись (аналог структуры или класса в Си++) имеет "тэг", что скрыто увеличивает размер экземплятра на 4 байта. (Примерно то же самое происходит с классом Си++, когда в нем "заводятся" виртуальные функции.)
Но, используя специальные модификаторы (NOTAG в ETH Oberon, untagged в BlackBox и т.д.), можно отказаться от этого "оверхеда".
Короче, решение в ETH Oberon сходно с Си++.
Но стандарт Оберона всего этого не поддерживает.
Поэтому большинство известных мне компиляторов Оберона не позволяет перегрузку операторов.
А это значит, что синтаксически решение на "стандартном" Обероне будет выглядеть иначе: придется использовать процедуры, а не инфиксные операторы.
Возможно, перегрузка операторов слишком изменила бы язык.
С этой точки зрения, показательна дискуссия вокруг поддержки в Обероне-2 типа COMPLEX (по просьбе представителя NASA), отраженная в материалах "дубовых требований".
Среди прочих названных Джозефом Темплом причин была следующая:

3.3.3.8 Structured function returns
A common misbelief is that introducing structured function returns would eliminate the
discussion about COMPLEX, because then one could define complex operations as functions.
It should be noted that this is only half the way since the mathematicians still want
to have infix notation which would require the introduction of a more general overloading
concept including infix operators. This in turn would break the idea of always qualifying
imported objects by the module name.

(Вообще, причин было названо десять. )
Проще говоря, назначение Оберона (поддержка компонентного программирования) отличается от назначения Си++ (поддержка ООП и обобщенного программирования в рамках отдельной программы, избегая ненужного "оверхеда" в run-time).
Программист, пишущий на Обероне, иногда испытывает некоторые трудности, реализуя то, что на Си++ выразить сравнительно легко.
Программист, пишущий на Си++, зачастую вообще не представляет, чего он лишен.

Здравствуйте, AVC, Вы писали:

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

Если Вы посмотрите в той же ветке чуть выше, Вы найдете там более упрощенную реализацию. Там нет систем единиц, а есть только разные физические понятия — длина, масса, время. К системам единиц я пришел, будучи подталкиваемым Кодтом.

AVC>Во-вторых, как раз Оберон в "классическом" своем варианте (правда, есть и другие разновидности Оберона) и не позволил бы ввести естественным образом такие типы, т.к. в нем нет перегрузки операторов. Поэтому пришлось бы использовать процедуры-функции.

Ок, понятно.

AVC>Проще говоря, назначение Оберона (поддержка компонентного программирования) отличается от назначения Си++ (поддержка ООП и обобщенного программирования в рамках отдельной программы, избегая ненужного "оверхеда" в run-time).
AVC>Программист, пишущий на Обероне, иногда испытывает некоторые трудности, реализуя то, что на Си++ выразить сравнительно легко.
AVC>Программист, пишущий на Си++, зачастую вообще не представляет, чего он лишен.

Допускаю. Но как-то в голову ничего не приходит. Если Вас не затруднит, не могли бы Вы привести примерный список возможностей? Как известно, язык не только расширяет, но и ограничивает мышление.

Здравствуйте, eao197, Вы писали:

E>А удалось достичь этого благодоря тому, что инструмент был расчитан только на C++ и на то, что все компоненты будут создаваться с использованием именно этого инструмента (как я понимаю, в Обероне и Зононе точно такая же ситуация). Конечно, наша технология не позволит создать инструменты типа Януса, Ворда или Konquerer-а. Но вот построить несколько черных ящиков, обрабатывающих какие-то события и обменивающихся данными между собой -- легко. А все остальное можно с помощью KParts в KDE сделать (Linux forever! )
E>)

В отношении Оберона ты прав.
Собственно, это идея была использована Виртом еще при создании Lilith и основывалась тогда на Модула-2.

E>Алексей мне будет очень интересно узнать твое мнение о нашем SObjectizer. Если найдешь время, глянь краем глаза, пожалуйста (равно как и другие читатели, если таковые доберутся до этого постсриптума) -- я буду признателен любому мнению.

Евгений, я обязательно прочту. (Может быть, это потребует немного времени.)

Здравствуйте, eao197, Вы писали:

E>Алексей мне будет очень интересно узнать твое мнение о нашем SObjectizer. Если найдешь время, глянь краем глаза, пожалуйста (равно как и другие читатели, если таковые доберутся до этого постсриптума) -- я буду признателен любому мнению.

Пока только начал знакомиться с твоей книгой SObjectizer-4 Book.
Конечно, сначала — "наискосок".
Но тут нахлынули эмоции. ("Вспомнились годы ушедшие..." )
Знаешь, была в свое время интересная книжка Shlaer, Mellor "Object lifecycles: modeling the world in states".
У нас ее еще издавали под каким-то безликим названием, что-то вроде "Объектно-ориентированного анализа".
Я ее когда-то прочитал, а впоследствии это пригодилось.
Из нее я усвоил метод анализа с помощью моделей состояний (=конечных автоматов).
В одном из проектов это позволило нам избавиться от лишней аппаратуры и одновременно организовать корректную работу системного ретранслятора, отвечающего за обмен информацией между центральной станцией и абонентами в условиях довольно жесткого реального времени (задержка не должна была превышать 1 миллисекунды). (Собственно, я писал эту программу; меня тогда даже чуть не побили за то, что я мог говорить только о конечных автоматах. )
Мне кажется (наверное, это поверхностное впечатление; просто нахлынуло ), что их метод хорошо бы "лег" на вашу систему. Их метод анализа назывался OOA (и еще последние две цифры, обозначающие год). Кажется, последняя версия была OOA96. Затем все методы были "подмяты" UML-ем. Но ребята не растерялись, и создали xUML — исполняемый UML. Если не ошибаюсь, их фирма называлась Project Technology.
Ну и еще, конечно: датчики температуры, датчики дыма...
"Жизнь моя, иль ты приснилась мне?" (c) Есенин