Кратко об SDL, его отличии от UML. Пример модели на SDL.
А так же ссылки на источники о диаграммах потоков данных

В статье не обнаружилось как такового сравнения. Скорее, рассуждения на тему плюсов и минусов UML.
Но сама идея DSL (Domain Specific Languages) возможно будет интересна в качестве создания (программной) модели на этапе разработки. + еще один инструмент от компании Microsoft, непосредственно связанный с моделями.

Что-то мне не нравится то, что для работы с SDM необходима VS 2005 Team Suite for System Architecture. Пока не могу найти где можно бесплатно скачать эту версию Visual Studio.

Судя по содержанию, в пятой главе "Архитекторы" есть упоминание о SDM.

Краткий взгляд на "Белую лошадку" от Microsoft ;-)

http://www.microsoft.com/downloads/details.aspx?FamilyId=944994B9-81E1-4A99-913F-788C3FE3EF49&displaylang=en

В статье есть абзац "Next Stop: DSI" в котором как раз написано о том, что много обсуждали: в чем отличие подхода Microsoft по сравнению с Sun, IBM, HP. Кратко о том, что DSI это XML, а SDM - "схема", базирующаяся на этом формате. Продукт моделирования - Whitehorse. В общем, кратко рассказывается о задумках и идеях Microsoft

ОТСМ - Общая теория сильного мышления

ТРИЗ - Теории решения изобретательских задач

Куда только не попадаешь в поисках моделей!!! ;-)

Это очень полезная работа, я имею в виду эту выборку из текста. Польза методологическая, определяется подход. Понятно, что все это целиком UML\RUP базированное, но ценность от этогоне уменьшается.
Мне кажется, что в нашем случае несколько иное назначение моделей или модели- специализация\ориентация на качество обслуживания\производительность.
ТБД

При моделировании системы в целом и ее подсистем:

1) Специфицируйте вид системы с точки зрения вариантов использования или прецедентов, которые описывают поведение системы таким, каким оно представляется конечным пользователям, аналитикам и тестировщикам.

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

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

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

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

6) Смоделируйте архитектурные образцы (паттерны) и образцы проектирования с помощью коопераций.

Моделирование архитектуры системы:

1) Идентифицируйте виды, которые вы будете использовать для представления архитектуры. Чаще всего это виды с точки зрения прецедентов, процессов, реализации и развертывания

2) Специфицируйте контекст системы, включая и окружающие ее актеры.

3) При необходимости разложите систему на элементарные подсистемы.

Саша, все правильно.
Фактически ищется модель архитектуры. Еще не вполне понятно, какие частные задачи окажутся возможными, но модель как формализованное\интерпретируемое предствление архитектуры ценна сама по себе. Microsoft SDM интересно не только как сбъектное представление систем. Там же еще должен быть и run time для параметрического определения этих моделей. Имеет смысл поработать.
В то же время мне кажется, что распределенность в случае, когда могут окзаться рапределенными данные, что представляет особый случай в отношении отказоустойчивости и влияния на качество работы вообще. Здесь может проявиться или использоваться\рекомендоваться\не рекомендоваться репликация. Очень интересно подумать.

До конца недели необходимо устроить обсуждение.

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

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

Попробую сегодня этим заняться, что-нибудь "порисовать".

Пока искал только в интернете, но не нашел подходящего материала именно по моделям РВС, моделям архитектуры. В основном только технические решения.

Саша, хорошо, что есть движение, но пока складывается впечатление, что видится направление скорее аппаратное (архитектурно) с вытекающими отсюда вопросами резервирования, мажоритарных моделей обнаружения нарушений в работе (к тому же за минимальное время) и тому подобное. Это действительно область обеспечения отказоустойчивости (вплоть до катастрофоустойчивости).
Мне представляется, что для такой работы едва ли имеются необходимые ресурсы (нужно быть в таком деле внутри). тогда и исследование можно замыслить.
Я думаю, что интересной задачей является само представление архитектуры распределенной системы т.е модели архитектуры в виде, дающем основу для дальнейшего использования модели в проектном процесс: может быть сопоставлении вариантов, моделировании (и здесь могут использоваться разные инструменты, вплоть до GPSS) и т.д.
В этом меня и заинтересовал подход MS.
Это нужно обговорить, звони и договоримся.
ТБД

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

Общее время недоступности сервиса фиксируется в соглашении об уровне сервиса SLA - Service Level Agreement

Соответственно, возможно в зависимости от значения SLA можно говорить об отказоустойчивости системы, или даже о ее катастрофоустойчивости!

Много исследований в статье, но в основном о GRID, а это к вопросу об отказоустойчивости имеет, на мой взгляд, достаточно посредственное отношение

Нельзя не согласиться, наверно:

"..на начальном этапе нужно спроектировать систему, полностью определив информацию о ее объектах"

Одной из особенностей распределенной ВС является возможное отсутствие информации, необходимой для доступа к ее удаленным объектам...

Я не совсем понял эту фразу. Интересно, какую именно информацию авторы имеют в виду???

Есть упоминание о Прологе и БД

Возможно использовать понятие о компонентах системы: что должно быть, чтобы получить платформу для проектирования, реализации, эксплуатации, поддержки и т.д.

В дальнейшем из этой статьи можно использовать условия развития (переработанные под "нашу" embedded область)

необходимо учесть, что под "вычислительной системой" здесь понимается "вычислительная сеть"

И под областью применения - бизнес-процессы и т.п.