Модели, документы. Языки, нотации, понятия.
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-стереотипов с иконками для соответствующих ВидовПонятий и отношений между ними). При этом возможно составление Документов, в которых наглядно будет выражена связь между целями, архитектурными решениями и обоснованиями достижения целей предлагаемыми средствами.
Изложение будет примерно соответствовать описанию продуктных классов (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-стереотипов с иконками для соответствующих ВидовПонятий и отношений между ними). При этом возможно составление Документов, в которых наглядно будет выражена связь между целями, архитектурными решениями и обоснованиями достижения целей предлагаемыми средствами.