Comments 17
А Sparx Enterprise Architect поддерживает только SQL или еще SPARQL?
potan, «Толстый» клиент Sparx Enterprise Architect поддерживает только SQL. Внутреннего специализированного языка запросов (SPARQL) нет))) Планируем в ближайшем будущем развернуть сервер приложений с «тонким» клиентом ProCloudServer. Вот еще список поддерживаемых СУБД.
Хотя, в определенных случаях — при составлении шаблонов отчетов или в формах поиска, используются собственные конструкции, которые не тянут на собственный полноценный язык, но могут быть засчитаны как собственный язык запросов, весьма ограниченный в применении и работающий, скажем прямо — не быстро.
EA может сохранять свои артефакты в реляционной БД. Поэтому можно клепать собственные вьюхи артефактов.
SPARQL-он для RDF-наборов.
SPARQL-он для RDF-наборов.
Интересно, «типы данных» где описываются в таком каталоге (если описываются). В компонентах? Меня что озадачивает, что на уровне бизнес логики обычно пропадает, тот факт что представления бизнес объектов в разных системах кардинально отличаются. Например, болванка (бизнес-объект) отправленная на станок с точки зрния ERP имеет код, длину и вес, а с точки зрения датчиков станка — имеет только длину и вес. Аналитик/архитектор может легко забыться и придумать «а от сюда, от станка получаем код, длину и вес», хотя кода то нет. Причем даже «вес» и «длина» могут быть разными и даже не вопрос едениц измерения (например потому что станок взвешивает с какой-нибудь приваренной ерунденью).
Или подобные проблемы вообще не рашаются каталогами архитектуры?
Или подобные проблемы вообще не рашаются каталогами архитектуры?
В нашем случае, проблема решена следующим образом. Типы данных относятся к элементам уровня архитектура данных. Сами типы иерархические. Типы топового уровня, как правило, обладают небольшим набором атрибутов самого общего характера. Далее в зависимости от важности типа, от частоты его использования, от ваших возможностей и желания он (тип) может детализироваться на более низкие уровни иерархии. Например, Болванка (ну очень важный в данном примере тип) имеет атрибуты Длина и Вес. И его (тип) можно разобить на ERP Болванка (с дополнительным атрибутом Код) и Станочная Болванка. Ну и так далее.
Уровень детализации не обязательно одинаков для всех объектов. Чем важнее объект, тем больше внимания мы ему уделяем, тем больше атрибутов и сложнее иерархия.
Причем мы всегда остаемся на логическом уровне представления типов. Физический уровень систем или баз данных мы не поддерживаем принципиально. Это очень сложно.
И не забудьте, что чрезмерная детализация будет требовать чрезмерных усилий при поддержке актуальности репозитория. Ну а что такое «чрезмерный»- каждый решает сам.
Уровень детализации не обязательно одинаков для всех объектов. Чем важнее объект, тем больше внимания мы ему уделяем, тем больше атрибутов и сложнее иерархия.
Причем мы всегда остаемся на логическом уровне представления типов. Физический уровень систем или баз данных мы не поддерживаем принципиально. Это очень сложно.
И не забудьте, что чрезмерная детализация будет требовать чрезмерных усилий при поддержке актуальности репозитория. Ну а что такое «чрезмерный»- каждый решает сам.
Спасибо за ответ. Я правильно понимаю, что и Component Architecture и Use Case диаграммы интерактивны и из них грубо говоря кликами (напр. «Credit Card» для юзе кейсов, кстати диаграма компонент — пережата, я там ничего разобрать не могу), можно дойти до типов данных? Или эти слои Data Architecture, Technology Architecture, Component Architecture, Application Architecture и т.п. — есть разные репозитории (документы?) без возможности «гиперссылки» между ними?
Репозиторий один, поскольку, все элементы хранятся в одной базе данных. С интерактивностью сложнее. Это в Sparx EA организовывается по- разному. Как правило, от одного элемента можно перейти к другому при наличии связей между ними. Другими словами, если в вашей модели предусмотрена трассировка от одного слоя к другому в виде связей, то вперед. Только не забудьте, что заведение связей – это ваше дело. Если они есть, то можно блуждать между элементами и слоями. Если говорить про настоящие гиперссылки, то тогда нужно экспортировать репозиторий в html- представление. Здесь интерактивность будет получше. Но на практике, для анализа табличное представление гораздо эффективнее. Тогда при правильной вьюшке не придется терять на экране информацию о предыдущем элементе, переходя к следующему. Именно об этом говорится в последнем абзаце статьи.
В нашем случае от Use Cases можно дойти по «гиперссылкам» до Типов Данных. От компонентов прямой трассировки нет. Но есть вьюшка, которая обеспечивает такую информацию на одной странице через более сложный SQL-запрос.
В нашем случае от Use Cases можно дойти по «гиперссылкам» до Типов Данных. От компонентов прямой трассировки нет. Но есть вьюшка, которая обеспечивает такую информацию на одной странице через более сложный SQL-запрос.
Благодарю за отличное описание интересного кейса. Сколько времени ушло на описание архитектуры до покрытия 80%？ Сколько человек в реальности использует этот репозиторий？
Спасибо за интересную статью!
Похоже, что вы придумали ArchiMate. Он обладает очень мощной и при этом лаконичной метамоделью. Если вы его не рассматривали как вариант, то посмотрите — найдете очень много общего, а может быть и идей для развития. А если смотрели, то интересно почему отказались?
Похоже, что вы придумали ArchiMate. Он обладает очень мощной и при этом лаконичной метамоделью. Если вы его не рассматривали как вариант, то посмотрите — найдете очень много общего, а может быть и идей для развития. А если смотрели, то интересно почему отказались?
Смотрели безусловно. Его идеи очевидны в нашем варианте. Но все-же Archimate значительно сложнее. И это ответ, почему мы его не используем. Конечно, такая кастомная модель — это изобретение велосипеда, но этот велосипед очень уж хорошо нам подходит. По этому поводу, я встречал классное высказывание писателя Артура Хейли. Дословно не помню, но приблизительно так: «Всю музыку уже написал Чайковский, но все равно ее пишут и пишут.»
UFO just landed and posted this here
Sign up to leave a comment.
Единый репозиторий для управления Enterprise Architecture