Об архитектурные языки и подходы к архитектурным описаниям
Оригинал взят у ailev в Об архитектурные языки и подходы к архитектурным описаниям
1. Поскольку я консультант, то мне постоянно приходится разбираться с целевой системой (в том числе -- организационной системой) на начальных стадиях её жизненного цикла, когда никто ещё ничего не понимает про будущую систему -- т.е. когда еще непонятно, что нужно делать (наличествует Ситуация), какие методы для этих действий использовать. В этот момент ранних стадий жизненного цикла требуется подробное одновременное разбирательство с функциональными требованиями и поддерживающей эти непрерывно уточняемые требования архитектурой. Соответственно, нужно наличие хорошей библиотеки компонент методов инженерии требований и инженерии системной архитектуры и наличие развернутой технологии подобной работой (наличие освоивших эти дисциплины людей и наличие инструментария).
2. Лучшим на сегодня мне известным способом быстро обеспечить архитектурное описание, равно как и зафиксировать требования, является малевание от руки простых диаграммок фломастером на флипчарте (архитектурное описание, с приписанными там да сям отдельными словами, обозначающими требования), сопровождаемые словами из разных статей, учебников и прошлых жизненных ситуаций (ситуационный метод, вытаскиваемый из библиотеки компонент метода -- прямо из головы).
Хихикну в сторону, что аналитические диаграммы ISO 15926 во всём мире сейчас тоже рисуют карандашом на бумажке, в крайнем случае -- в PowerPoint, Word или Visio. Сапожники, как водится, без сапог: кто предлагает универсальные языки описания всего, читаемые машиной, сам остаётся без такого языка.
Итого: технологии по факту нет -- дисциплина не описана, и передаётся исключительно изустно, язык описания требований и архитектуры неформален, инструменты времён изобретения доски с мелом. Самый современный инструмент -- это телефон, на который фотографируют флипчарт.
3. С флипчартом (а иногда и листочком A4, если работают двое-трое человек, а не пять-шесть) быстро, удобно и эффективно, но немасштабируемо на большее число людей и большее число деталей требований и архитектуры. Появляется огромный разрыв между тем, что решено на каком-нибудь "правлении", и последующей работой в крупной организации. Отчуждение от авторов флипчартовых описаний, участвовавших в начальных дискуссиях становится очень проблематичным.
4. Для фиксации требований и архитектурных описаний ISO 42010 рекомендует использовать архитектурные языки и подходы (framework) к архитектурному описанию (тут нужно учесть, что стандарт поминает architectural framework, но вот Open Group свой TOGAF называет не framework, а method. А поскольку мы уже перевели viewpoint как метод описания, относящийся к конкретной группе описаний -- view, то за framework оставляем слово "подход", заодно давая приоритет терминологии ISO 42010 над терминологией частных подходов-frameworks).
На сегодня есть множество популярных архитектурных языков: SysML/UML, AADL, ArchiMate и т.д.. Эти языки обычно объект-ориентированные и позволяют выразить объекты (классы, экземпляры, процессы, их атрибуты, отношения между экземплярами классов и т.д.). Язык мы тут понимаем как пара из языка и нотации (а иногда и нескольких нотаций) ISO 24744.
На сегодня есть множество популярных архитектурных подходов к описанию (architectural, или architecture framework, сводящихся к описанию набора view и их взаимосвязи): Захмановский, RM-ODP, TOGAF, DoDAF, ARIS и т.д..
Архитектурных подходов к описанию (т.е. наборов view) много больше, нежели языков, которые могут обеспечить viewpoints для этих view. С другой стороны, многие языки описания имеют свои предпочтения по поводу подхода к описанию -- ибо они предполагают использование отдельных видов диаграмм, которые легко перепутать с группами описаний (veiw). И люди их путают! Общее правило тут таково:
-- в архитектурных подходах разные view тематические, и могут подразумевать множество моделей для их описания. Например, финансовая группа описаний может требовать моделей баланса и отчёта о прибылях и убытках, группа описаний организации -- конструктивной диаграммы DEMO и органиграммы и т.д.
-- в архитектурных языках разные view прежде всего "онтологические", и чаще всего представляют собой какой-то один вид диаграмм. Так, в UML есть Activity Diagramm и Class Diagram.
Но на каждой общее правило есть множество исключений: если UML еще представляет собой более-менее чистый "язык", то уже ArchiMate содержит в себе существенную долю подхода к архитектурному описанию, а подход ARIS в существенной мере поддержан его же языком.
Это порождает много трудностей по использованию разных языков описания для выражения разных подходов -- по-хорошему, для любых подходов можно было бы использовать любые языки, но это не совсем так. См., например, серию обсуждений использования языка ArchiMate для подхода TOGAF: http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-an-architecture-method.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf.html, http://www.via-nova-architectura.org/artikelen/tijdschrift/using-archimate-with-togaf-2.html.
Более того, разные архитектурные языки могут мэппиться друг ко другу (концепты одного языка могут соотноситься с концептами другого языка, так что обеспечивается "перевод"), и из-за этого возникает дикая путаница между мэппингами языков и использованием языков для изображения разных групп описаний (см., например, https://doc.telin.nl/dsweb/Get/Document-38740/, где сравнивается ArchiMate и UML, RM-ODP, EDOC Profile for UML, BPMN, ARIS -- сам список того, с чем сравнивается ArchiMate поражает своей разнородностью).
5. Главная критика архитектурных языков: они невыразительны. На них нельзя многого выразить из того, что нужно для описания систем. Характерен анализ, данный при разработке онтологически-ориентированного архитектурного языка OPML ( http://www.cesames.net/fichier.php?id=370, http://www.cesames.net/fichier.php?id=371). Еще одно подтверждение невыразительности -- отсутствие имитационного моделирования (см. http://ailev.livejournal.com/819251.html).
Невыразительность, конечно, компенсируется: архитектурные языки просты, их легко выучить. Но это как Basic в языках программирования: недаром говорилось, что начавшего программировать на BASIC потом невозможно уже научить программировать хорошо. Выразить мир девятью корнями матерного диалекта можно, но лучше бы этого не делать в промышленных масштабах.
Проблема в том, что для большинства архитектурных языков за основу берется UML, и (невзирая на все отличия) поэтому вся критика UML относится и к архитектурным языкам. UML -- это такой архитектурый BASIC, коверкающий архитектурное мышление.
ПРЕДЛОЖЕНИЕ по решению ситуации с архитектурными языками: использовать для архитектурного языка какую-то upper ontology (например, ISO 15926-2). Несмотря на полное понимание, что для разных задач нужны разные онтологии ("нет универсального способа представления действительности"), каждая из них разрабатывалась с целью максимальной выразительности и расширяемости.
А для любых отдельных методов описания можно использовать микротеорию, разрабатываемую на основе этой базовой онтологии. Архитектурный язык становится тем самым ситуативным: модульно расширяемым по ситуации без потери выразительности. Каждая ситуация/система требует своего набора микротеорий, требуемых для ее описания.
6. Главная критика архитектурых подходов очень похожа на критику инженерии методов: они неситуативны. Любой архитектурный подход плохо работает в ситуации, хотя бы немного отличающейся от ситуации, для которой он разработан. Например, описание организационной (социотехнической) системы существенно отличается от описания "железной" (киберфизической) системы -- это означает, что подходы описания организационной архитектуры (enterprise architectural framework) должны бы существенно отличаться от подходов описания "просто систем", а ввиду невероятного различия между собой этих "просто систем" и использования в этих подходах архитектурных языков разной степени выразительности, нельзя быстро подобрать хоть как-то подходящий подход к архитектурному описанию.
Так, DoDAF является обязательным подходом для описания систем в военных закупках США. Но единогласное мнение: он заставляет подробно описывать неважное, а важное приходится описывать вне этого подхода!
Многочисленные попытки ввести "легковесные" подходы (типа LAF от Harold Lawson) пока ни к чему не привели, ибо критика относится к самому стилю использования одного и того же набора групп описаний для описания самых разных систем. Это неситуационно: "один размер не удовлетворит всех", даже если этот размер мал.
ПРЕДЛОЖЕНИЕ: аналогом ситуационного архитектурного подхода был бы заведомо избыточный каталог групп описаний, из которого можно было бы набирать небольшое число нужных в данной ситуации групп описаний -- плюс недостающие группы описаний можно было бы порождать каким-то регулярным способом.
7. По итогам двух предложений мы приходим к следующей конструкции:
а) в качестве архитектурного языка выбирается какая-то картина мира (upper ontology), в которую потом гарантированно впишутся многочисленные группы описаний
б) каждая группа описаний поддерживается своей микротеорией и соответствующей ей нотацией (DSL, viewpoint), а объекты разных микротеорий отождествляются друг с другом через correspondence view.
в) все эти DSL можно хранить в каталогах, и использовать по мере потребности -- понимая, что они будут совместимы между собой и всеми остальными описаниями (т.е. решена проблема интеграции данных разных описаний, даже если эти DSL поддерживаются разным софтом).
8. Я пытаюсь тут рассказать не столько о том, что подход (7) позволит формально определять все мэппинги из путаницы (4), оставляя людям возможность работать с лучшим инструментарием (т.е., это способ продолжить работать со множеством диалектов архитектурных Бейсиков). Нет, я не имею ввиду что-то типа "ISO 15926 outside для архитектурного моделирования", чтобы как-то определять correspondence rules для программных средств архитектурного моделирования разных производителей, поддерживающих разные подходы и языки.
Скорее, я имею ввиду развитие чего-то типа "ISO 15926 offsite" (http://dot15926.livejournal.com/22909.html), создание нового расширяемого архитектурного языка для requirements and architecture acquisition -- в форме библиотеки справочных данных (каталога DSL, т.е. микротеорий+нотаций, aka каталога групп описаний, aka каталога ситуационного архитектурного подхода). В этот ситуационный архитектурный подход можно было бы интегрировать удачные находки нынешних архитектурных бейсиков, но оставить возможность развития (т.е. систематического пополнения этой библиотеки).
9. А пока из всего этого разнообразия для целей описания организационной архитектуры мне больше всего нравится ArchiMate (http://www.opengroup.org/archimate/doc/ts_archimate/, свободный моделер -- http://archi.cetis.ac.uk/), за которым я слежу уже некоторое время. Если нужно что-то делать срочно, то я бы брал его за основу. Даже любители ARIS могут его использовать (http://www.ids-scheer.ru/ru/ARIS/ARIS_Software/ARIS_ArchiMate_Modeler/35028.html), равно как и любители другого платного софта (http://www.bizzdesign.com/index.php/tools/architect и т.д.).
Недостатки, как водится, являются отражением достоинств: небольшое количество предметно-ориентированных базовых языковых концептов (микротеории организации), приписанных к четко указанным возможным view (матрице слоёв*аспектов) -- Business Layer (Business actor, Business role, Business collaboration, Business interface ...), Application Layer (Application component, Application collaboration, Application interface, Data object ...), Technology Layer (Node, Device, Network, Communication path ...), Relationships (Association, Access, Used by, Realization, Assignment ...).
В этом языке-подходе переплелись средства как предмет-ориентированные (описание организации и ее технологической инфраструктуры), так и общие (т.е. непредметно-ориентированные, типа объектов representation, отношений aggregation, composition и т.д.). Понятно, что для конкретных целей ситуации моделирования может не хватить ни тех, ни других.
Детализация описания, выход в более специализированные модели, и тем самым обеспечение исполняемости описаний (например, BPMN описания процессов, которые можно было бы скормить какому-нибудь workflow-движку; описание данных, которые можно было бы скормить какой-нибудь СУБД) представляется более чем ограниченными.
Плохо также и то, что за основу явно берется UML -- везде, где только можно. Это существенно ограничивает онтологическую выразительность.
10. Главная критика текущих подходов к архитектурному описанию: их группы описаний пытаются быть недеятельностными, т.е. независящими от используемых методов работы. Это означает, что мы не можем описать финансы так, чтобы было удобно для маржиналистской работы с ними (throughput accounting) и традиционной (cost world, в которой постоянные и переменные издержки перемешаны). Мы не можем описать организационный мир в терминах транзакций, путаемся между функциональным (т.е. типа IDEF0, без развертки во времени) и процессным (т.е. типа IDEF3, с разверткой по времени) описаниями "процессов", не понимаем, как в это упихнуть "проекты" в смысле проектного управления и т.д.
Тезис: разные методы работы с системой (в том числе, организационной/социотехнической системой, но и с киберфизической тоже -- с любой системой) требуют каких-то микротеорий, и разные группы описаний архитектуры должны поддерживать именно нужные для выборанных методов работы описания.
Уйти от этого нельзя, даже если пытаться ограничиться "общим архитектурным языком". Либо ты различаешь физический объект и функциональный объект, используя методы системного подхода, и это отражается в архитектурном языке; или различаешь актора и акторские роли, и это отражается в архитектурном языке, либо этого ничего нет, и получаемые в рамках какой-то пары архитектурного подхода и языка группы описаний оказывается невозможно использовать.
Тем самым задача создания архитектурного подхода к описанию (набора групп описаний и каталога методов описаний) вынуждена быть совмещенной с задачей создания каталога методов, которые используются при разработке. Ежели архитектурный метод (например, ТРИЗ), выделяет "противоречие", как важный элемент архитектурной работы, то и архитектурное описание должно позволять его отображать. Ежели выделяет разницу между механизмом, поведением, структурой, конструкцией и т.д. -- то эта разница должна получить отражение в соответствующих группах описаний.
Об этом я, кажется, уже много раз писал -- но уж лучше написать еще раз прямо, чем потом задаваться вопросом, почему мы не можем использовать готовый софт поддержки давно известных архитектурных языков (т.е. конкретные диаграммные технологии) и готовые архитектурные подходы к описаниям (т.е. наборы предписанных групп описаний).
12. Поэтому задача создания архитектурного подхода к описанию системы вполне укладывается в задачу создания каталога методов: это как раз "язык" и "нотация" из ISO 24744. Трудность тут только в том, что формализм ISO 24744 не позволяет легко выражать связку между всеми этими языками и нотациями. Но на данном уровне рассуждений это и неважно.
Так что, ежели развивать каталог методов организационной работы praxos, то автоматически нужно ставить и задачу создания онтологического (т.е. всеядного, основанного на микротеориях) архитектурного языка для описания организаций как системы связанных разными отношениями людей, оборудования, данных, так и разных взаимоувязанных DSL (язык плюс нотация) для поддержки методов работы с организацией. То есть без понимания, как ты будешь делать, не будет понимания, как ты будешь архитектурить (это про определение обеспечивающей системы, в отличие от понимания, что ты будешь делать, и что архитектурить -- это будет выясняться по ходу работы, это про определение целевой системы).
Поэтому идея Harold Lawson ("LAF следует группам практик из ISO 15288") в целом верная: начинать нужно с каталога методов работы с системой, а не с определений "что обычно входит к корпоративную архитектуру" или "какие группы описаний обычно нужны стейкхолдерам сложного инженерного объекта", "какие группы описаний нужны для работы с PLM" и т.д.
--------------------
Оригинал взят у ailev в Архитектурные языки, архитектурные подходы (frameworks), UML profiles и 4D extensionalism
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).
-------------------
Оригинал взят у ailev в Верхнее образование инженеров-программистов
Мой вариант курсов для ВУЗовского образования по специальности "программная инженерия" (характеристика этих курсов даётся в каждом "кумулятивно", т.е. очень грубо считаем, что эти курсы проходятся последовательно, а не "вперемешку" и умения накапливаются от курса к курсу):
1. Грунтовка мозга: подготовка "думателя"
-- английский язык
-- дискретная математика, классическая логика
-- философская логика (и совсем чуть-чуть философии)
-- лингвистика
-- формальные семантика и прагматика в объеме, чтобы свободно читать теоретические статьи по computer science.
После этого курса выходят очень умные, полностью бесполезные в любом деле люди. Зато их можно потом легко обучить многим и многим профессиям, ибо они после этого курса "быстро схватывают".
2. Предметная ориентация: подготовка "учёного программиста" (computer science)
-- парадигмы программирования и языки программирования
-- моделирование данных (от реляционок до онтологий, от XML до ISO 15926)
-- алгоритмика (методом Кнута без пряника, но не чураясь параллельности)
-- как устроены компиляторы, интерпретаторы, виртуальные машины, моделлеры и прочие редактирующие и исполняющие среды -- в объеме, позволяющем ориентироваться в том, что пишут в рассылке FONC, на сайте Lambda Ultimate, а также примерно понимать, как устроены системы типа помянутых в http://www.languageworkbenches.net/ar.html
Эти люди могут побеждать в олимпиадах по программированию, читать лекции в университетах, но к работе по специальности "программная инженерия" совершенно не приспособлены (ибо у них нет в лексиконе слов "требования", "архитектура", "методология разработки" и т.д.) -- то есть "придумывать алгоритмы умеют, а работать не умеют".
3. Профессиональная ориентация: инженерные компетенции:
-- системный подход, инженерный метод (работа с эвристиками)
-- ситуационная инженерия методов, методологии разработки
-- технические практики системной инженерии (инженерия требований, инженерия системной архитектуры и т.д.): не для "чисто программных систем" (таких нет), а сразу для социотехнической системы, киберфизической системы и т.д.,
-- особенности программной инженерии: методологии разработки (в ассортименте: RUP, SCRUM и все-все-все, понятие о devops etc.), архитектура и моделирование, методы тестирования, методы версионирования и управления конфигурацией, продуктные линии и т.д.. Фишка в том, что это одна строчка в программе, т.е. учить нужно отнюдь не только этому! Всё это дается как "специализация" для практик системной инженерии.
После этого курса выходит инженер-программист ("умеет программировать"), не ориентирующийся в жизни. Он хорошо решает поставленную ему узкую программистскую задачу, но у него нет знаний о том, как устроено производство -- поэтому он постоянно решает ненужные задачи, и не решает нужные ("программировать умеет, программирует всё время что-то не то"). Поэтому требует мелочного внешнего управления.
4. Инженерный менеджмент (как устроено производство)
-- праксеология (формальный анализ человеческой деятельности)
-- enterpise engineering (организационные модели + change management)
-- управленческий учёт
-- проектное управление в связи с методологиями разработки
-- работа с живыми людьми (aka "лидерство")
После этого курса выходит инженер-программист, который ориентируется в производственной жизни, способен встроиться в производственный процесс, "самоорганизующийся" и даже при случае "организующий". Это и есть искомый результат обучения.
Время такого образования -- входное условие (например, 4 года), а вот уровень квалификации выпускника существенно зависит от методики (т.е. выбранных наборов упражнений -- по моей оценке, ежели учить "правильно", т.е. учить тщательно подобранными упражнениями для предварительно отмоделированных мыслительных операций, то получается обычно впятеро быстрее, чем если учить "традиционно").
UPDATE: мой рассказ (1 час 23 минуты видео) этих тезисов в виртуальной академии: http://ailev.livejournal.com/937397.html
* * *
Понятно, что у меня есть собственное понимание, что такое "инженер-программист" (не только теоретическое, но и практическое: у меня многолетний рабочий стаж и программиста-теоретика, и инженера-программиста, и менеджера программистского коллектива, и многолетний стаж работы в проектах, где айтишные задачи представляют только часть работы).
Для понимания моего подхода полезно также ознакомиться с другими моими материалами по общему верхнему образованию:
-- программа общего верхнего образования: http://ailev.livejournal.com/853399.html (июль 2010)
ПРОГРАММА ОБЩЕГО ВЕРХНЕГО ОБРАЗОВАНИЯ
-- тезисы к Программе общего верхнего образования: http://ailev.livejournal.com/855472.html (август 2010)
-- оценки времени верхнего образования: http://ailev.livejournal.com/871079.html (октябрь 2010)
-- системная инженерия верхнего образования http://ailev.livejournal.com/907435.html (февраль 2011)