• Единый репозиторий для управления Enterprise Architecture
    0
    Да. Это стандартный подход. Я даже подозреваю, что и типы вьюшек получаются похожими. Различие в их вариациях и количестве. Что в свою очесредь в основном зависит от того, как много и какой сложности достоверных данных для этих вьюшек сможет поддержать предприятие.
  • Единый репозиторий для управления Enterprise Architecture
    0
    Смотрели безусловно. Его идеи очевидны в нашем варианте. Но все-же Archimate значительно сложнее. И это ответ, почему мы его не используем. Конечно, такая кастомная модель — это изобретение велосипеда, но этот велосипед очень уж хорошо нам подходит. По этому поводу, я встречал классное высказывание писателя Артура Хейли. Дословно не помню, но приблизительно так: «Всю музыку уже написал Чайковский, но все равно ее пишут и пишут.»
  • Единый репозиторий для управления Enterprise Architecture
    0
    Кстати, разработчики Sparx EA уже выпустили бета версию тонкого клиента. Скоро обещают стабильную версию. Тогда интерактивность будет настоящей.
  • Единый репозиторий для управления Enterprise Architecture
    0
    Репозиторий один, поскольку, все элементы хранятся в одной базе данных. С интерактивностью сложнее. Это в Sparx EA организовывается по- разному. Как правило, от одного элемента можно перейти к другому при наличии связей между ними. Другими словами, если в вашей модели предусмотрена трассировка от одного слоя к другому в виде связей, то вперед. Только не забудьте, что заведение связей – это ваше дело. Если они есть, то можно блуждать между элементами и слоями. Если говорить про настоящие гиперссылки, то тогда нужно экспортировать репозиторий в html- представление. Здесь интерактивность будет получше. Но на практике, для анализа табличное представление гораздо эффективнее. Тогда при правильной вьюшке не придется терять на экране информацию о предыдущем элементе, переходя к следующему. Именно об этом говорится в последнем абзаце статьи.
    В нашем случае от Use Cases можно дойти по «гиперссылкам» до Типов Данных. От компонентов прямой трассировки нет. Но есть вьюшка, которая обеспечивает такую информацию на одной странице через более сложный SQL-запрос.
  • Единый репозиторий для управления Enterprise Architecture
    0
    В нашем случае, проблема решена следующим образом. Типы данных относятся к элементам уровня архитектура данных. Сами типы иерархические. Типы топового уровня, как правило, обладают небольшим набором атрибутов самого общего характера. Далее в зависимости от важности типа, от частоты его использования, от ваших возможностей и желания он (тип) может детализироваться на более низкие уровни иерархии. Например, Болванка (ну очень важный в данном примере тип) имеет атрибуты Длина и Вес. И его (тип) можно разобить на ERP Болванка (с дополнительным атрибутом Код) и Станочная Болванка. Ну и так далее.
    Уровень детализации не обязательно одинаков для всех объектов. Чем важнее объект, тем больше внимания мы ему уделяем, тем больше атрибутов и сложнее иерархия.
    Причем мы всегда остаемся на логическом уровне представления типов. Физический уровень систем или баз данных мы не поддерживаем принципиально. Это очень сложно.
    И не забудьте, что чрезмерная детализация будет требовать чрезмерных усилий при поддержке актуальности репозитория. Ну а что такое «чрезмерный»- каждый решает сам.