Previous Entry Share Next Entry
Архитектурные языки, архитектурные подходы (frameworks), UML profiles и 4D extensionalism
2011
ailev wrote in dot15926
DoDAF 2.02 (Department of Defence Architecture Framework Version 2.02, принят в августе 2010г., http://cio-nii.defense.gov/sites/dodaf20/index.html) -- это обязательный для использования архитектурный подход министерства обороны США. Во всех военных проектах США используют предопределенный набор тематических групп описаний.

Этот набор описаний выражен в терминах метамодели MD2 (http://cio-nii.defense.gov/sites/dodaf20/DM2.html), so the architectures can be integrated, analyzed, and evaluated to mathematical precision. Эта метамодель представляет собой ограниченный словарь, в терминах которого описываются модели этой архитектуры. Фишка в том, что логический уровень этой метамодели представляет собой UML-профиль для IDEAS, которая является 4D upper ontology (http://cio-nii.defense.gov/sites/dodaf20/Ontology1.html), ближайшим родственником Части 2 ISO 15926.

Недавно была выложена книжка Chris Partridge "Business Objects: Re-Engineering for Re-Use", 2000г., с изложением основных идей технологии BORO (http://www.brunel.ac.uk/%7Ecssrcsp/BusObj.pdf). Именно технология BORO и легла в основу 4D онтологии IDEAS. В этой книжке педантично расписано (хотя и не в терминологии ISO 15926), какие проблемы решаются переходом от описаний в объектно-атрибутивной парадигме к логической (классы), и почему нужно было вводить 4D. Я бы считал, что для промышленных онтологов это обязательное чтиво, там есть множество объяснений, до которых не снисходят авторы текстов по ISO 15926. Конечно, при этом не нужно забывать, что тамошняя онтология совсем не похожа на ISO 15926, и учиться нужно не представленной там онтологии, а излагаемому в книжке куску философской логики.

А теперь критика DoDAF 2.02:
1. IDEAS там появилась из понимания, что архитектурной информацией нужно обмениваться между разными архитектурными системами. Идея интеграции (в данном случае архитектурных) данных неминуемо влечёт вызов онтологических духов, а современные онтологические духи всё чаще и чаще выбирают 4D, чтобы не запутаться в отслеживании превращения гусеницы Дуси в куколку Дусю, а затем и бабочку Дусю.
Мы вполне могли бы выбрать ISO 15926 для тех же целей: интеграции архитектурной информации, в том числе информации enterprise architecture. Но мы лучше выберем ISO 15926 не для задач outside (как была выбрана модель IDEAS), а для задач offsite и inside. Я пока не чувствую острой необходимости перегонять модели ARIS в модели DoDAF или ToGAF. Мне бы эти модели разрабатывать, и вряд ли с использованием этих архитектурных подходов. Тем не менее, я бы использовал ISO 15926 непосредственно в качестве метамодели: so the architectures can be integrated, analyzed, and evaluated to mathematical precision.

2. Идея сделать UML-профиль для ISO 15926, чтобы работать с UML-редакторами, мне представляется сугубо неправильной. Тут два возможных варианта:
-- поступить, как в BORO, и вместо диаграмм Части 7 придумать богатый графический язык для выражения ISO 15926 (в том числе расширяемый микротеориями, задающими "профили", как в UML)
-- сделать свой "похожий на UML" графический язык с онтологическими расширениями, пройдя по пути OPML (http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371).
-- считать, что будет много разных DSL, и принципиально не заморачиваться одним каким-то базовым графическим или текстовым языком. Много-много projectional editors, показывающих в разных DSL кусочки общей семантической сетки. И сосредоточиться на придумывании этих DSL для разных views. Пока склоняемся к этому варианту, ибо остальные являются частными случаями этого.

3. Что касается использования IDEAS, то два уровня неадекватности (UML-профиль, а поверх него давно критикуемый жестко определенный набор методов описаний собственно архитектуры) полностью закрывают возможные достоинства использования IDEAS -- я писал об этом механизме нивелирования достоинств технологий неудачностью использующих их приложений тут: http://ailev.livejournal.com/936771.html.
Мы тем самым должны отойти от жесткой заданности набора методов описаний, но дать все необходимые механизмы для ситуативного его построения (см. http://praxos.livejournal.com/12468.html).

?

Log in

No account? Create an account