vrr/doc
2
0
Fork 0
mirror of https://github.com/bpmbpm/doc.git synced 2026-05-10 03:52:30 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update grail.md

Browse source
This commit is contained in:
Dmitry 2025-10-01 21:58:38 +03:00 • committed by GitHub
parent 3f3114148b
commit f6cd7d6599
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 6 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

6
EA/grail.md
View file

@ -32,6 +32,10 @@
**Мое видение на возражения:** пока просто не научились ни модель (метаМодель) / синтаксическую обертку строить, ни под нее разные нотации (синтаксические обертки типа С4, Архимейт и т.п.). Онтология BPM и EA - это пока не изученные области.
В целом: Конечно реальное Предприятие - это не его модель, а модель (полная модель предприятия) - это не диаграмма. Тем не менее набор диаграмм (с правильной Метамоделью \ онтологией) может с определенной точностью описать модель объекта. А модель объекта с определенной точностью может описать сам реальный объект.
Или Реальный Карандаш - это не модель карандаша, а модель карандаша - это не какая-либо одна или две его проекции (разрез) или формула, т.е. на пара диаграмм (чертежей) и расчетов (например, прочностных).
#### 1.1 Аналогия с картографией
В картографии как раз эти проблемы решены: и с проекциями разнообразными договорились и с легендами (на картах). Пересчет координат из одной системы в другую и т.п.
Такой же уровень формализма (формальная семантика) должен быть и у архитекторов. А примеров больше, - тот же ЕСКД.
@ -47,6 +51,8 @@
#### Не важно как рисовать
Как есть разные view, так есть и разные viewpoint-ы, полагаю у каждого они немного свои. Однако на ходу изобретать очередную нотацию - это тоже перебор. ArchiMate + BPMN + UML более чем полный набор для описания всего чего угодно. А если за картинками есть ещё табличные представления со спецификациями и требованиями - получается полноценный архитектурный репозиторий. Если информация в репозитории кому-то полезна - им пользуются, а внешний вид - хорошо, если он соответствует общепризнанным стандартам. Думаю, метрики оценки полноты и качества - важнее собственно языка описания.
Если картинка помогает в принятии решений, то это уже прорыв. Мы сейчас опустим разговоры об уровне зрелости организации, где Большие, Красивые, Цветастые картинки за спиной в кабинете придают вес. Так что, как инструмент коммуникации и принятия решений - схемы/картинки - это прямо киллер фича :)
#### Рисуют, чтобы фиксировать для себя
- Лично мне картинки нужны не для того чтобы кому-то что-то объяснять, а чтобы удерживать целое у себя в голове. Для объяснений есть арх.комы, ВКС-ы, личные встречи - много болтовни и картинки там не главное.
- не только архитекторы для себя рисуют схемы, чтобы самому себе что то объяснить / закрепить. Это нормально. Иногда статьи пишут (и на хабре) ровно для этого: самому себе объяснить: когда читаешь свой же текст - некоторые вещи воспринимаешь иначе.