Не рассказали про самую главную фичу C4, а именно то, что данную модель можно описывать в стиле "архитектура в виде кода" используя Structiruzr, что позволяет хранить всю архитектуру в репозитории кода. Когда попробуете такой подход никакие archimate даже видеть не захочется
Это особенность конкретного инструмента, а не нотации в целом. Модели Archi вы аналогично можете версионировать в гите немного заморочившись. Вот пример статьи где описывается как это делать www.dsec.nl/2016/12/enabling-team-collaboration-with-archimate-3-0/
Еще лет 10 пройдет, тогда человечество наконец определится с нотацией. А пока что из однозначных и неоспоримых лично для меня винов имеем: 1) диаграмма последовательности, 2) диаграмма классов, 3) диаграмма обмена, хотя и используется редко, 4) функциональная схема, внезапно из разработки электроники, но заходит на отлично, 5) деплой, очень хорошая и нужная штука, но всем впадлу ее делать, 6) вездесущая пакетная диаграмма, чтобы у кустомера аж в глазах зарябило от обилия функционала. Остальные либо слишком редко используются, либо от них никакой пользы.
Мое мнение о нотациях - это как синтаксис для языков программирования. Языки популярными делает не столько синтаксис (хотя и он в том числе), сколько платформа вокруг - компиляторы, интерпритаторы и т.п. Холивары вокруг нотаций будут ходить до тех пор, пока не появятся мощные инструменты, дающие неоспоримые преимущества от их использования. Собственно разработкой такого инструмента мы и занимаемся с командой, но анонсируем его когда будет что-то готово) Вам спасибо за коммент. Интересно было бы взглянуть что за функциональная схема такая из электроники
@@Archyxioru а ничего прямо особенного. Квадратики, связанные линиями. В квадратике пишется что функционально это за хрень, по линиям можно понять какой функционал с каким связан, иногда прям на самой линии написано что она из себя представляет. Даёт общее понимание функционирования системы и даже позволяет найти узкие места или примерно прикинуть, идея вообще взлетит или не взлетит и что для этого нужно. К функциональным требованиям просто на ура трассируется. С аски графикой на ютубе не важно, поэтому в качестве примеров приведу только то, что соединяется одно за другим последовательно. Первый пример из электроники, вот, у нас, к примеру, есть музыкальная шкатулка. Она состоит из памяти, управляющего автомата, устройства воспроизведения звука. По этой простой схеме вы можете реализовать как традиционную механическую музыкальную шкатулку, так и электронную, возможно вам потребуется её конкретизировать, но базово все будет соответствовать именно такой функциональной схеме. В случае с механической шкатулки у вас будет в качестве памяти валик с крючками, в качестве управляющего автомата - рукоятка, вращающая валик и молоточки, а в качестве устройства воспроизведения звука будут колокольчики. Если вы будете делать электронную шкатулку, то у вас будет флешка, микросхема кодека и простенький динамик. Вы можете даже комбинировать подходы в этом случае, пусть у вас будет механический валик, вы его будете вращать рукой, а крючки будут замыкать контакты миди-синтезатора, аудио сигнал которого пущен на усилитель. Вы можете и по-другому, взять электронную драм-машину и её миди-сигнал конвертировать в удары молоточков по колокольчикам. С разработкой софта, к примеру, у вас есть интерпретатор какого-нибудь языка. У вас функционально будет токенайзер, парсер и виртуальная машина. Подозрительно похоже на музыкальную шкатулку, правда? :) Требования к каждому блоку накидать - легко, структура системы ниппель уже вырисовывается и это очень просто, понять что лишнее, чего нехватает, отладить это - элементарно. А главное нет вот этих долбанутых заявлений от разрабов: "Вот эта правка должна быть здесь, а не вот здесь, так как для архитектуры лучше будет ". PS: я тоже как-то раз так задолбался от того, что из скриптов сборки вообще нихрена не понятно, проблема эта вечная, начал думать о том, а не запилить ли мне свой Gnu make с блек-джеком и шлюхами, решил сделать графической, так как граф зависимостей сборки гораздо проще описывать именно так, провел небольшое исследование и понял, что это просто будет невостребовано, это будет ещё пару месяцев выматывающих бессонных ночей и дней на энергетиках вникуда, ничего другого я с этого не получу. А вам желаю удачи в ваших начинаниях, чтобы было достойное продолжение.
Конечно, иногда помоделировать необходимо и полезно. Вопрос в том будет ли это одноразовая акция или постоянный процесс с поддержкой актуальности схемы и насколько в реальности будет требоваться следование стандарту нотации или обходится просто какими-то квадратиками со стрелочками. Расскажите как у вас?
Очень информативно, крутая картинка и монтаж! Желаю набрать аудиторию, с таким контентом она точно будет!
Спасибо, такие комменты греют!
Спасибо за видео! Очень информативно
Спасибо!)
Не рассказали про самую главную фичу C4, а именно то, что данную модель можно описывать в стиле "архитектура в виде кода" используя Structiruzr, что позволяет хранить всю архитектуру в репозитории кода. Когда попробуете такой подход никакие archimate даже видеть не захочется
Это особенность конкретного инструмента, а не нотации в целом. Модели Archi вы аналогично можете версионировать в гите немного заморочившись. Вот пример статьи где описывается как это делать www.dsec.nl/2016/12/enabling-team-collaboration-with-archimate-3-0/
Еще лет 10 пройдет, тогда человечество наконец определится с нотацией. А пока что из однозначных и неоспоримых лично для меня винов имеем:
1) диаграмма последовательности,
2) диаграмма классов,
3) диаграмма обмена, хотя и используется редко,
4) функциональная схема, внезапно из разработки электроники, но заходит на отлично,
5) деплой, очень хорошая и нужная штука, но всем впадлу ее делать,
6) вездесущая пакетная диаграмма, чтобы у кустомера аж в глазах зарябило от обилия функционала.
Остальные либо слишком редко используются, либо от них никакой пользы.
Мое мнение о нотациях - это как синтаксис для языков программирования. Языки популярными делает не столько синтаксис (хотя и он в том числе), сколько платформа вокруг - компиляторы, интерпритаторы и т.п. Холивары вокруг нотаций будут ходить до тех пор, пока не появятся мощные инструменты, дающие неоспоримые преимущества от их использования. Собственно разработкой такого инструмента мы и занимаемся с командой, но анонсируем его когда будет что-то готово)
Вам спасибо за коммент. Интересно было бы взглянуть что за функциональная схема такая из электроники
@@Archyxioru а ничего прямо особенного. Квадратики, связанные линиями. В квадратике пишется что функционально это за хрень, по линиям можно понять какой функционал с каким связан, иногда прям на самой линии написано что она из себя представляет. Даёт общее понимание функционирования системы и даже позволяет найти узкие места или примерно прикинуть, идея вообще взлетит или не взлетит и что для этого нужно. К функциональным требованиям просто на ура трассируется.
С аски графикой на ютубе не важно, поэтому в качестве примеров приведу только то, что соединяется одно за другим последовательно.
Первый пример из электроники, вот, у нас, к примеру, есть музыкальная шкатулка. Она состоит из памяти, управляющего автомата, устройства воспроизведения звука. По этой простой схеме вы можете реализовать как традиционную механическую музыкальную шкатулку, так и электронную, возможно вам потребуется её конкретизировать, но базово все будет соответствовать именно такой функциональной схеме. В случае с механической шкатулки у вас будет в качестве памяти валик с крючками, в качестве управляющего автомата - рукоятка, вращающая валик и молоточки, а в качестве устройства воспроизведения звука будут колокольчики. Если вы будете делать электронную шкатулку, то у вас будет флешка, микросхема кодека и простенький динамик. Вы можете даже комбинировать подходы в этом случае, пусть у вас будет механический валик, вы его будете вращать рукой, а крючки будут замыкать контакты миди-синтезатора, аудио сигнал которого пущен на усилитель. Вы можете и по-другому, взять электронную драм-машину и её миди-сигнал конвертировать в удары молоточков по колокольчикам.
С разработкой софта, к примеру, у вас есть интерпретатор какого-нибудь языка. У вас функционально будет токенайзер, парсер и виртуальная машина. Подозрительно похоже на музыкальную шкатулку, правда? :)
Требования к каждому блоку накидать - легко, структура системы ниппель уже вырисовывается и это очень просто, понять что лишнее, чего нехватает, отладить это - элементарно. А главное нет вот этих долбанутых заявлений от разрабов: "Вот эта правка должна быть здесь, а не вот здесь, так как для архитектуры лучше будет ".
PS: я тоже как-то раз так задолбался от того, что из скриптов сборки вообще нихрена не понятно, проблема эта вечная, начал думать о том, а не запилить ли мне свой Gnu make с блек-джеком и шлюхами, решил сделать графической, так как граф зависимостей сборки гораздо проще описывать именно так, провел небольшое исследование и понял, что это просто будет невостребовано, это будет ещё пару месяцев выматывающих бессонных ночей и дней на энергетиках вникуда, ничего другого я с этого не получу. А вам желаю удачи в ваших начинаниях, чтобы было достойное продолжение.
Проще код писать, чем его моделировать. Спорно. Не всегда так бывает. Например админка
Конечно, иногда помоделировать необходимо и полезно. Вопрос в том будет ли это одноразовая акция или постоянный процесс с поддержкой актуальности схемы и насколько в реальности будет требоваться следование стандарту нотации или обходится просто какими-то квадратиками со стрелочками. Расскажите как у вас?
не стал одевать наушники пролистал не увидел ни одного примера диаграмм, слушать часами без референса, не интересно
Неудачно пролистали. Пример вставлен для каждого типа диаграмм. В тайм кодах с 8 минуты по 11-30.