Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Модели, документы. Языки, нотации, понятия.

1. Общие замечания.
Изложение будет примерно соответствовать описанию продуктных классов (product classes) ISO 24744, хотя вполне возможно, что моя трактовка некоторых его положений по-русски будет эээ... творческой и неожиданной для авторов стандарта.

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




Глоссарий (русский и английский варианты) -- http://ailev.livejournal.com/816938.html

2. Модели и документы: идеи и их изображение
Начнем с того, что Модель -- это нематериальное "представление в голове", идеальный объект, про который можно сказать только то, что он может быть изображен (depict) в Документе -- прежде всего для коммуникации с кем-либо (включая себя любимого, нарисовавшего Модель на бумажке для разглядывания самим же собой "вне головы", ибо не гроссмейстер моделировать по памяти) или чем-либо (напомним, что Акторы -- это и люди, и инструменты. Поэтому в Акторах вполне может быть компьютер, и его софт -- в том числе репозитории и прочие хранилища данных).

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


3. Язык и нотации
Для отображения Моделей в Документах используется Нотация. Этот факт трудно обнаружить, но ВидДокумента может отражать (depict) любые ВидыРабочихПродуктов, в число которых входят наряду с ВидамиСоставныхРабочих продуктов, ВидамиОборудования и ВидамиПО как ВидыМоделей, так даже и сами ВидыДокументов.

Для отражения одного или нескольких ВидовМодели в каком-то ВидеДокументов используются Нотации, поддерживающие (supports) тот Язык, который использует (uses) тот или иной ВидМоделей. Язык, который использует ВидМодели. Один Язык может быть использован множеством ВидовМоделей, а ВидМодели использует только один Язык.

Язык (не ВидЯзыка, а просто Язык -- это Не-Шаблон!) состоит из ВидовПонятий и связей между ними, и поддержан минимум одной Нотацией (нотация -- это тоже Не-Шаблон).

Пример, поясняющий разницу шаблонов (ВидовТого-сего, уровень методологии) и не-шаблонов (уровень предпринятия) для:
-- ВидаМоделей (ModelKind, порождаются инженером-методологом в момент Порождения Методологии): Для выбора зрелого арбуза при его покупке нужно создать модель арбуза. С этой целью инженер-методолог создает ВидМодели арбуза, который будет использован каждый раз для создания Модели арбуза, когда будет осуществляться покупка арбуза.
-- Модели (Model, порождаются Разработчиком в момент предпринятия): при покупке арбуза 25 мартобря 2010г. Разработчиком было создано 8 различных Моделей арбуза для разных арбузов -- он остановился в создании Моделей арбуза только тогда, когда последняя созданная им Модель арбуза его удовлетворила.

Тем самым Язык примерно соответствует:
-- общепринятому понятию языка (это подчеркивается в Стандарте), как набору символов и правилам их сочетания
-- OIM в ISO 15926-7,8 (там тоже не гарантируется поддержка нотацией -- нотации идут отдельно от Языка)
-- методу описания (viewpoint) из ISO 42010, особенно если вспомнить возможность снабжать Наставлениями все ЭлементыМетодологии (но помним, что в ISO 42010 метод описания включает в себя также и нотации, и инструкции по собственно описанию)
-- тому, что описывается в SBVR для концептуального комьюнити (а нотация там -- хинт! -- относится к словарному комьюнити).
-- предметной области (domain), имеющей свою группу описаний (ВидМодели) объекта (предмет -- это в действительности, а объект -- в реальности!).
-- поскольку каждый ВидМодели пользуется ровн один Язык, то можно считать Язык метамоделью (и в этом плане говорить, например, о Языке ISO24744 или Языке OMG BMM, считая слова "Язык" и "метамодель" синонимами).

Отметьте себе: словарная часть -- это к нотации. Может быть один Язык, а Словари/нотации для него разные. Впрочем, одна Нотация тоже может подходить к разным Языкам.

4. ВидыПонятий и ГенеральнаяМетамодель
Каждый ВидМодели состоит из ВидовИспользованияПонятий. Каждый ВидИспользованияПонятий ссылается (ReferTo) на ВидПонятий.

Пример:
-- ВидаПонятий (ModelUnitKind, определяются инженером-методологом в момент Порождения Методологии): для выбора спелых арбузов инженер-методолог выбрал подход сухого хвостика (отбросив метод щелкания по боку). Для того, чтобы передать точную семантику каждого из понятий, необходимых для моделирования арбуза в целях определения его зрелости, были определены ВидыПонятий "хвостик" и "атрибут хвостика -- сухость".
-- Понятий (ModelUnit, напомню, что они определяются Разработчиком в ходе Предпринятия): модели зрелости каждого из потенциально покупаемых арбузов в предпринятии его покупки 25 мартобря 2010г. содержат (используют) "хвостик" с атрибутом "сухость" -- эти "хвостик" и "сухость" и есть Понятия.

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

Тем самым общность ВидовПонятий обеспечивает существование мыслимой, но в жизни редко реализуемой (тут нужно применить любимое СМД-Методологами "как бы") ВидаГенеральнойМодели (ГенеральногоЯзыка, ГенеральнойМетамодели) для той или иной Методологии. ВидаГенеральнойМодели как множества всех доступных ВидовПонятий в Стандарте нет, но прописанная в Стандарте возможность адаптации МетамоделиСтандарта вполне такое может обеспечить, если возникает такая потребность. А потребность с внедрением САПР возникает: модели, полученные в разных САПР очень хочется совмещать, и для этого иметь ГенеральныйЯзык для создания ГенеральнойМоделиСистемы. ISO 15926 как раз претендует на роль такого языка -- объединителя разных OIM.

Общность ВидовПонятий не дана нам изначально, обычно ее требуется получить -- для этого требуется mapping потребных для моделирования в рамках ВидаМетодологии Языков. Общность ВидовПонятий и ВидГенеральнаяМодели обеспечиваются специальными онтологическими средствами -- ISO 15926 именно про это.

5. Содержательное расширение Метамодели ISO 24744: SOA, управление конфигурацией акторов/процессов/продуктов, обоснования.
Дальше поговорим о самом ISO 24744 с использованием представленного его собственного Языка и русскоязычной его Нотации. Можно, конечно, декомпозировать Язык (метамодель) ISO 24744, следуя предложениям самого стандарта: можно их выделять по-разному, но бросается в глаза ЯзыкПредметнойОбластиМетодологии, ЯзыкПредметнойОбластиПредпринятия в одном варианте разбиения и главные три Языка -- ЯзыкПроцесса, ЯзыкАкторов, ЯзыкПродукта -- в другом разбиении. Выделение этих подъязыков дает возможность использовать для них альтернативные нотации (например, диаграммы Гантта для ЯзыкаПроцесса, и диаграммы классов для ЯзыкаПродукта).

Расширение ISO 24744 некоторыми другими ВидамиПонятий (это, как я понимаю, возможно встроенной в Стандарт процедурой его расширения) и позволяющих с ними работать Языков и Нотаций дает возможность:
-- при добавлении ВидовПонятийSOA: строить ВидыМоделей и отражающие их Документы, при помощи которых можно обсуждать хранение самих ВидовМоделей в компьютерах, порождение Документов из Моделей (что включает автоматизацию работы с Языками, Нотациями, ВидамиПонятий),
-- при добавлении ВидовПонятийУчета -- управление конфигурацией Продуктов (включая Документы и Модели!).
-- при добавлении ВидовПонятийОбоснования: строить ВидыМоделей, обосновывающие необходимость Постановки (enactment) тех или иных ЭлементовМетодологии.

А вот всякие там ВидыПонятий и Языки обоснований/assurance case или целеориентированности в инженерии требований -- это уже штатная предметная работа (а не расширение ВидовПонятийМетамоделиISO24744).

6. Язык моделеориентированной инженерии требований
Теперь сверхкраткий и неполный, но пример рассуждений в предложенном Языке на тему интеграции языков моделеориентированной инженерии требований и языков инженерных обоснований (http://ailev.livejournal.com/811715.html).

Язык логических обоснований с нотацией на естественном языке изучается на курсах логики. В этот язык входят ВидыПонятий Аргумент, Причина, Следствие, Доказательство, Факт и так далее. В предметной области инженерных обоснований (assurance case) используются Языки и нотации, в которых задействован почти такой же набор ВидовПонятий.

Языки целеориентированной инженерии требований и поддерживающие его нотации определены стандартом URN, подходом i*, OMG BMM, подходом NOMOS и т.д. В эти языки входят ВидыПонятий Актор, Цель и Средство, Вариант, но используются различные нотации (в том числе слова, обозначающие эти ВидыПонятий) -- поэтому прямое сравнение невозможно.

Эти языки и нотации позволяют создавать Документы, в которых отображать Модели для конкретного предпринятия (инженерного проекта). В ходе инженерных проектов возникает потребность не только моделировать Цели и средства, но и обосновывать выбор их Вариантов. С этой целью необходимо создание Документов, позволяющих выражать данные как Моделей целей, так и Моделей обоснований.

Это возможно сделать различными методами:
а) создать Документы, в которых отражаются разные Модели, использующие разные Языки -- Язык целей и Язык обоснований. Нотацию и язык выбрать из набора стандартов. При этом совмещение Моделей будет происходить "в голове инженера". В Акторе-компьютере эти Модели будут храниться независимо, ибо семантической работы (по отождествлению -- mapping) ВидовПонятий, составляющих эти модели, проведено не будет.
б) Осознать, что Средства -- это архитектурные решения. Использовать Язык архитектурного моделирования (например, SysML, Modelica или любой другой подходящий), и выполнить отображение (mapping) ВидаПонятий Средства из Языков целей и Факты из Языков обоснований с Языком архитектуроно моделирования. После этого возможно автоматизированное составление Документов с использованием трех Моделей (архитектурной, целей, обоснований) и разной нотацией.
в) создать новый Язык (метамодель) целей-и-обоснований, при помощи которого создать новый ВидМоделей, и предложить для этого языка подходящую нотацию (например, нотацию UML-стереотипов с иконками для соответствующих ВидовПонятий и отношений между ними). При этом возможно составление Документов, в которых наглядно будет выражена связь между целями, архитектурными решениями и обоснованиями достижения целей предлагаемыми средствами.
Subscribe
  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 6 comments