Enterprise architect на русском руководство

Время на прочтение
9 мин

Количество просмотров 57K

Дорогой Хабр, мы решили поделиться заметками и нашим базовым рецептом о приготовлении проектов в Sparx Enterprise Architect. Причем под проектом мы подразумеваем создание какой-либо информационной системы. Впереди вас ждет рассказ о том, как у нас все организовано – примеры диаграмм, структура проекта в Enterprise Architect, немного о требованиях, проектировании и постановках на разработку.

Источник

1. Вместо предисловия

1.1. Про начало

Давным-давно, в далёкой-далёкой галактике… Не, не то. Давным-давно, кажется, в прошлую пятницу мы решили, что, пожалуй, хватит ворда, бумаги, отдельных задач jira и т.п. – пора использовать что-то более подходящее. Стало неудобно, так как всё путалось в кросс-ссылках, в разных способах поддерживать историчность и нескольких подходах. Так начался наш путь к использованию Enterprise Architect (EA). Почему хватит? Причин очень много. У каждого из участников процесса она своя. Основная причина – абсолютная власть.

Дарт Сидиус проводит анализ влияния. Синим цветом показаны зависимости (кадр из фильма “Звёздные войны: Эпизод 3 – Месть Ситхов”)

Абсолютная власть в том смысле, что нам очень хотелось

влиять на умы и править всеми

понимать связи между элементами создаваемых информационных систем (элементы в широком смысле — не только то, что разрабатывается и работает потом, но и требования, и спецификации и прочее, что использовано при создании системы) и не просто понимать, а ещё и быстро эти самые связи находить, анализировать, показывать заказчику, для которого “любое изменение можно реализовать за один день и непонятно, почему вам нужно две недели”.

Совершенно справедливый вопрос — “Почему вы выбрали именно Enterprise Architect, а не любой другой инструмент?” На момент, когда процесс начался, в нашем активе были jira, confluence, MS office, SP, Sybase Power Designer (сейчас это SAP Power Desiner) и Sparx Enterprise Architect. Собственно, вопрос решили личные предпочтения и навыки EA на тот момент (это были 2011-2012 годы), а также люди, которые были первопроходцами и отдали сердца и умы Enterprise Architect. Возможно, это было ошибкой.

1.2. Немного капитанства

Основные этапы жизни проекта по созданию информационной системы (да и в целом, наверно, почти любого проекта с точностью до определения каждого этапа) вполне очевидны – как по ГОСТ, так и просто исходя из здравого смысла. Это:

1. концепция,
2. эскиз,
3. техническое задание (сбор и выявление требований),
4. техническое проектирование (разработка архитектуры),
5. рабочее проектирование (разработка и дизайн),
6. внедрение,
7. эксплуатация и сопровождение.

Примечание: номера здесь для наглядности – этапы могут быть совмещены, не иметь чётких границ, уходить в итерации и т.п.

Для концепций мы пока не применяем Enterprise Architect, так как обычно нужно все делать быстро, срочно, очень красиво. Так что это word, visio c различными расширениями или иные рисовалки (где ну вообще красота). Эскиз, к сожалению, заказчика не интересует, хотя мы бы и рады готовить его в EA. Два последние пункта – это или про ошибки (они решаются (во всяком случае у нас) иными средствами и инструментами) или про доработки, и тогда это всё заворачивается в пункты 3-5.

Поэтому поговорим про такие этапы, как техническое задание (сбор и выявление требований), техническое проектирование (разработка архитектуры), рабочее проектирование (разработка и дизайн).

1.3. Для тех, кому не терпится попробовать результат (спойлер)

Диаграмма компонентов (в данном случае каждый компонент – это один модуль развёртывания), связей между ними, базовых протоколов.

Диаграмма развёртывания общего программного обеспечения по узлам, с указанием основных связей

2. Про рецептуру

2.1. Ингредиенты

Вот основное, что вам нужно.

• Дискомфорт – если вам комфортно в вашем текущем процессе создания информационной системы, если всё устраивает, значит или у вас уже есть EA (может, что-то подобное), или вам он не нужен, и у вас и так всё отлично.
• Метамодель системы – понимание и описание того, как и в каких понятиях система будет описана.
• Формальный язык – естественный язык не очень хорошо подходит для того, чтобы точно и компактно передать смысл сообщения (на наш взгляд). И тут приходит на помощь формальный язык. Мы использовали UML.
• Знания Enterprise Architect – хотя бы минимальные, но чем больше у вас желаний вроде версионирования, разграничения доступа, работы в одном проекте и т.п., тем глубже погружение – вплоть до разработки своих модулей к EA (у нас их пока нет).

Не помешает:

• Терпение и гибкость. Несгибаемая жёсткость — не наш девиз. Внедрение нового подхода, какие-то серьёзные изменения в старом – это тяжело (особенно в первый раз). Будет много вопросов, ошибки, инертность, откровенное сопротивление, поэтому нужно терпеть и приходить к компромиссам и учитывать это в вашем персональном рецепте. Например, мы теперь совершенно спокойно относимся к исключительным ситуациям, когда EA становится просто инструментом, чтобы документировать и хранить уже сделанное. Дальше мы остановимся на этом на примере работы с требованиями.
• Здоровая лень и вкусный кофе. Лень в том смысле, что лень делать много рутины, которую можно автоматизировать. Это правильно, на наш взгляд. Так, например, мы окончательно обленились писать документы – создаём их из EA. Правда, в ряде случаев это документы по ГОСТ, и тогда мы это делаем в два этапа – сначала «мясо» из EA, а потом скриптами VBA наши доблестные технические писатели превращают это в ГОСТ. Ну а кофе – без него, конечно, можно, но куда без него? Мы очень любим сорт java.

Ах да, чуть не забыл – еще нужна дружная и заражённая энтузиазмом команда. Без этого никуда. У нас как раз такая.

2.1.1. Про дискомфорт

Для нас этим были:

• Разные инструменты – хотим один.
• Отсутствие централизации в описаниях системы (хочется перестать вести себя как белка, которая где-то спрятала орех и забыла где) – одно хранилище для всего.
• У нас нет абсолютной власти возможности провести быстрый анализ влияния – хотим знать, что развалится, если мы разделим компонент на два или что заденет изменение сценария работы системы и т.п.
• Надоело писать документы – хочется, чтобы «щёлк» и документ был.

2.1.2. Про метамодель

На наш взгляд, осознанно или подсознательно практически любая команда людей, вовлечённая в процесс создания чего-либо, может про это рассказать: что она создаёт, из чего это состоит, как работает и т.д. Может быть, не очень красиво или связно, может, с «дырами» в изложении. Но, тем не менее, может. Так и в случае с созданием информационной системы. На верхнем уровне мы наверняка все представляем, что есть требования – функциональные и какие-то ещё, важные и не очень, чёткие и размытые, есть что-то, что показывает базовые принципы воплощения этих требований – какие блоки в системе, какие основные технологии использованы, что систему окружает, как всё это между собой связано. Есть детализация и требований, и принципов реализации, описание структур данных и т.п. Все эти основные части и правила связи между ними мы и назвали «метамоделью».

Наша метамодель. Красавица!

В нашем рецепте метамодель достаточно фигуриста – наметим её контуры и дальше рассмотрим каждую часть чуть детальнее:

• требования,
• структура информационной системы,
• постановки,
• дизайн.

2.1.3. Про язык

Не можем похвастаться долгими муками выбора, так как мы практически сразу выбрали UML как наиболее распространённый вариант. Ну и «понеслась». Наверняка можно бы использовать различные связки различных языков и нотаций и, наверно, мы к этому придём, выбрав для каждой из частей метамодели свой, но пока мы счастливо избавлены и от мук выбора, и от скрещивания нотаций и языков.

2.1.4. Про знания Enterprise Architect

В самом начале знаний не было. В смысле, конечно, были, но фрагментарные, о том, как работать одному или как формировать простые документы. В общем, глядя назад, поражаешься нашим

слабоумию и отваге

уверенности в себе и скорости обучения. С тех пор, погружаясь всё больше в пучины Enterprise Architect, мы всё равно открываем для себя новые горизонты. Сейчас мы владеем следующими аспектами: работа с проектом EA и элементами, версионирование, разграничение доступа, генерация документов.

2.2. Готовка

Итак, у нас есть дискомфорт, метамодель, формальный язык, знания Enterprise Architect, дружная команда, лень, кофе, терпение и гибкость.
Теперь нужно взять EA, создать в нём проект, создать структуру согласно нашей метамодели и начать вносить элементы и связи.
Пробуем – смотрим на результат, оцениваем – понравилось, применяем дальше. Не понравилось – корректируем метамодель, обновляем элементы, связи и так пока не приготовим.

Как понять, что не понравилось? Вам не нравится, вам ещё больше неудобно, вы не ощущаете пользы. Как-то очень банально и неопределённо, да? Вы совершенно правы, дорогие читатели. Но каких-то очень чётких и строгих критериев для общего случая предложить сложно, да и, наверно, не нужно. Но мы, конечно, поделимся нашим опытом.

2.2.1. Про проект (который в EA)

Проект в Enterprise Architect состоит из набора корневых пакетов.

В свою очередь, каждый корневой пакет может содержать другие пакеты. А каждый обычный пакет – элементы (здесь под элементами подразумеваются элементы EA) и диаграммы.
Корневые каталоги могут быть размещены локально – в EAP файле, а могут – централизованно в базе данных. Кроме этого каждый пакет может быть сохранён в виде xml в репозиторий системы контроля версий.

С хранением проекта в БД мы не справились. Сначала это было классно – изменения отражались у всех, но спустя какое-то время у нас начались ошибки, какие-то непонятные ситуации с исчезновением элементов и т.п. В итоге мы плюнули это лечить и на время забыли. Но систему контроля версий мы потянули и прикрутили SVN.

Проект в Enterprise Architect

В самом примитивном варианте вы можете создать основные части вашей метамодели как корневые пакеты или пакеты первого уровня и получить структуру для хранения элементов модели и связей между ними. В нашем примере чуть сложнее, так как какие-то из этих частей размазаны по пакетам первого уровня. Но в целом принцип прослеживается. Кроме этого, «прикрутив» SVN мы получили возможность работы с ветками и релизами и разграничение доступа по принципу «один пакет – один владелец».

2.2.2. Про требования

Требование (как элемент EA) выглядит вот так:

Пример требования про обеспечение электронного взаимодействия

Так выглядит преобладающее большинство элементов EA для UML (так что видел один – видел и остальные).

Метамодель, в части требований, у нас достаточно скучная – ниже как раз эта часть более крупным планом.

В целом сказать чего-то особенного нечего – создаём требование, формулируем его и, при необходимости, связываем с другими требованиями. Но есть одно «но» – у нас требования в стадии активного выявления и сбора не прижились в EA. И мы шлёпаем их по старинке – напрямую в word.

Неоднократно задумывались, почему так происходит. На текущий момент мы пришли к следующим выводам.

• Заказчики у нас любят (и для нас это немного странно) word и excel. Ну, понятно, презентации (да ещё и красивые). Ничего другого не хотят видеть.
• Мы не научились быстро и удобно для себя работать с EA в части требований, когда их нужно формировать и согласовывать очень быстро. Но мы думаем, что у нас в итоге получится, работаем над этим, и есть надежда, что следующий вал требований уйдёт именно в EA.

Как только мы согласовали все наши требования, мы их тут же загрузили в EA в соответствующую часть метамодели. И вот все изменения требований проходят только через EA.

2.2.3. Про структуру

Когда базовые требования были собраны, мы начали набрасывать проектные решения – структуру ИС, технологии, связи между компонентами, отдельные технические решения согласно вот этой части метамодели:

Это происходило так. Создавалась диаграмма для несуществующего пока решения. Благодаря этому мы накапливали в проекте Enterprise Architect элементы, описывающие систему и при формировании решений, в которых эти элементы были задействованы, мы просто повторно их использовали, перетаскивая на нужные диаграммы. В этом случае как раз и начинают работать связи, необходимые для анализа влияния.

Для описания структуры мы использовали четыре типа диаграмм – вариантов использования, компонентов, развёртывания и классов (для описания логической модели данных). Плюс к этому в ряде случаев в ход шли возможности EA по использованию внешних объектов – рисунков, файлов, rich-text документов.

Вот как, например, выглядит описания одного физического компонента (эквивалента модуля развёртывания) на диаграмме, в проекте EA и его связи, и ничего сложного.

2.2.4. Про постановки

После того, как базовые решения выработаны, можно приступать к дизайну и разработке программного кода, но для последнего нужны «постановки на разработку».

Постановка включает в себя описание того, как детально должна работать ИС в части какой-то функции или сценария работы, какие компоненты и методы в это вовлечены, какие сущности логической модели данных использованы.

На всякий случай – здесь и далее под функцией системы (описанной как пиктограмма варианта использования) подразумевается некий сложный процесс работы системы, например, обработка заявления на открытие накопительного счёта от пользователя может скрывать «развесистый» процесс взаимодействия нескольких системы или же частей одной системы.

На данном этапе функция системы – центр. Вокруг центра строятся следующие работы.

• Спецификация сценария работы функции.
• Алгоритмы, используемые в сценарии.
• Архитектурные требования – ограничение, которые необходимо соблюсти при реализации или алгоритмизации того или иного шага.
• Детализация и уточнения логической модели данных.
• Формирование физической модели данных.
• Формирование «бизнес-интерфейсов» для компонентов – набора операций, значимых с точки зрения предметной области, которые потом необходимо реализовать. Здесь надо отметить, что методы, показанные в метамодели пиктограммой варианта использования, избыточны – мы таким образом связываем шаги спецификации сценария работы функции и соответствующий интерфейс.
• Уточнение связей между элементами.

После этих работ мы использовали эту информацию для дизайна и разработки кода и его тестирования.

Сам процесс передачи организован через jira – создаётся задача, в ней указано место в проекте EA, где находится постановка, а также ветка SVN.

Постановка выглядит так:

2.2.5. Про дизайн

Дизайн включает описание базовых классов, программных интерфейсов, пакетов (в терминах java) и их связей с со структурой системы.

Помимо этого в дизайне у нас есть порядок взаимодействия компонентов и классов, показывающих реализацию функций системы.

Эту часть рецепта мы пока держим в секрете.

3. Вместо заключения

Пройдя несколько сумбурно описанные шаги нашего рецепта, мы получили наше блюдо – проект в EA.

Кому-то наш рецепт покажется странным, нелепым. Кто-то почерпнёт для себя новое. Кто-то начнёт готовить и будет рад результату, а кто-то нет.
И это нормально – ведь это только наш рецепт, для нашей IT-кухни.

Мы

уверены

надеемся, что наши заметки не будут приняты в штыки и что будет конструктивная критика и полезные вопросы, отталкиваясь от которых мы сможем подкорректировать наш рецепт и продолжить наши заметки про использование Enterprise Architect и их публикацию на Хабре.

Enterprise Architect 15 Руководство пользователя обучение

Добро пожаловать в руководство пользователя корпоративного архитектора

Это руководство содержит информацию о том, как использовать инструменты, характеристики и функции. Эти инструменты делают корпоративного архитектора предпочтительным инструментом для предприятий, бизнеса, систем, стандартов и технического моделирования. В этой статье вы узнаете, как использовать силу корпоративного архитектора, чтобы упростить ваши рабочие методы, равномерно перекрестные команды, модели для создания работ по выполнению, перекрестной программы и использования проектов и повторного использования активов.

Это руководство включает в себя три основные части:

• Информация о продукте -Прокции и другие люди могут понять модель авторизации, доступную версию, варианты поддержки и т. Д.
• Преимущества и функции -это поможет менеджерам и лидерам понять, что такое корпоративная архитектура, а также основные преимущества и ценностные претензии инструмента
• Использование инструмента -основная часть руководства, включая моделирование, проектирование, спрос, структура, автоматизация и т. Д.

Как использовать это руководство

Мы понимаем различные способы обучения людей, поэтому руководящая организация предоставляет ряд входных точек. Вот несколько полезных методов и доступных методов навигации для некоторых рекомендаций по использованию:

Просмотрите тему руководства

Многие читатели могут хотеть много страниц в разделе в общем руководстве, чтобы более глубокое понимание темы. Метод навигации состоит в том, чтобы расширить непрерывный уровень списка контента для просмотра и выбора конкретных тем или суб -тему.

 

Кроме того, меню перхоти для хлеба можно использовать для перемещения обратно в иерархическую структуру темы. Это эффективно позволяет вам отслеживать стопы и вернуться к части, которую вы ходили раньше. Представьте себе это как дерево, вы достигнете точки, а затем вам нужно вернуться в ветвь ветви, чтобы взять другой путь.

Вы также можете использовать «предыдущую кнопку» и «следующую кнопку» для навигации по руководству. Эти две кнопки позволяют просмотреть недавно открытую страницу.

Руководство по поиску

Инструмент предоставляет мощный инструмент поиска, который может легко найти темы, главы и страницы.

В этом примере пользователи ищут, как использовать инструмент для моделирования. Они вводят ключевое слово «симуляция», и руководство ответит на серию доступной информации. Эта информация поступает не только из руководства, но и с веб -сайта, видео библиотеки, общих вопросов и библиотек PDF.

Инструмент также предоставляет функцию поиска с высоким уровнем уровня, которая позволяет пользователям гибко использовать логику или гармонию, включая поиск фразы и средства, чтобы указать результаты того, какие источники используют. В этом примере пользователи надеются получить информацию о контексте бизнес -процесса, поэтому используйте опцию для поиска результатов.

Внутренний доступ к теме руководства от корпоративного архитектора

Одним из наиболее распространенных методов для доступа к руководящим принципам пользователей является перейти по ссылке в пользовательском интерфейсе Enterprise Architect. Ссылки из инструмента предоставит соответствующий контекст страницы, чтобы помочь вам использовать деталь инструмента.

Ваш отзыв

Sparx Systems любит поддерживать связь с потребностями пользователей Enterprise Architect, чтобы эффективно выполнять свои задачи. Мы ценим любые предложения, обратную связь и комментарии по этому продукту, документу или процессу установки.

Вы можете просмотреть нашу веб -страницу онлайн -ответа:

sparxsystems.com/bug_report.htm

sparxsystems.com/feature_request.htm

В качестве альтернативы, вы можете связаться с Sparx Systems: [email protected]

Содержание

• направления
• Начиная проект
• Добавление предварительного просмотра
• Добавление пакета в шаблон
• Добавление диаграммы в пакет
• Добавление элементов
• Добавление разъемов
• чаевые
• Что вам нужно

Работа корпоративного архитектора сложна, поскольку включает в себя подробный анализ потребностей компании в настоящем и будущем и детали того, как удовлетворить эти потребности. Инструмент проектирования Enterprise Archiect UML от Sparx Systems был разработан специально для использования профессионалами для обширного управления документами и шаблонами дизайна. Раскрытие всего потенциала программы может быть длительным процессом, требующим специального и практического изучения программного обеспечения совместно с другими членами команды. К счастью, запуск проекта может быть простым и полезным опытом.

направления

Начиная проект

1. Запустите Enterprise Architect, щелкнув значок на рабочем столе, созданном во время установки, или открыв меню «Пуск» Windows и разместив программу в ее папке.

2. Нажмите «Создать новый проект» на домашней странице и введите имя своего проекта в поле «Имя файла». Нажмите «Сохранить», чтобы сохранить новый проект.

3. Выберите один или несколько шаблонов, которые появляются в диалоговом окне «Выбор шаблонов», установив флажок рядом с каждым. Эти модели предоставляют базовые рамки, пакеты и диаграммы для проекта, а также полезные ресурсы.

4. Нажмите «ОК», чтобы запустить программу. Пакеты с выбранным шаблоном будут отображаться в «Project Explorer» в правой части экрана.

Добавление предварительного просмотра

1. В проводнике проекта щелкните правой кнопкой мыши имя шаблона и выберите опцию «Новый вид».

2. Введите имя для этого представления в поле Имя.

3. Выберите стиль предварительного просмотра из меню и нажмите «ОК». Существует шесть различных моделей, полезных для разных целей, а также стиль «Простой», который позволяет создавать собственный стиль.

Добавление пакета в шаблон

1. Нажмите на список пакетов в Project Explorer.

2. Нажмите значок «Новый пакет» на панели инструментов Проводника и введите имя в текстовое поле для этого пакета.

3. Снимите флажок «Автоматически добавлять новую диаграмму» и нажмите «ОК». Эта опция автоматически создаст диаграмму для пакета, который по умолчанию выбранных пресетов. Хотя это полезно, его не следует выбирать во время выполнения учебника.

Добавление диаграммы в пакет

1. Нажмите новый пакет в проводнике проекта и нажмите «Новая диаграмма» на панели инструментов.

2. Щелкните категорию диаграммы в «Выбрать из», чтобы отобразить список типов диаграмм.

3. Выберите тип диаграммы на панели «Типы диаграмм» и нажмите «ОК».

Добавление элементов

1. На панели инструментов слева щелкните нужный элемент диаграммы. Перетащите его на диаграмму.

2. Выберите, на каком стереотипе основан элемент, если это элемент «Объект». Они могут определить, что является элементом объекта, для простоты интерпретации диаграммы.

3. Дважды щелкните элемент на диаграмме. Откроется диалоговое окно «Свойства элемента». Используйте это диалоговое окно, чтобы определить все его характеристики, включая имя. Нажмите «ОК», чтобы сохранить элемент в диаграмме и Explorer в пакете, где была создана диаграмма.

Добавление разъемов

1. Создайте два элемента на диаграмме.

2. Щелкните соединитель на панели инструментов, а затем щелкните элемент источника в отношении. Перетащите элемент источника к элементу назначения.

3. Дважды щелкните соединитель, чтобы открыть диалоговое окно «Свойства соединителя». Определите характеристики отношений между двумя на отображаемых экранах.

чаевые

• Выполнив эти шаги, вы инициируете самые фундаментальные уровни приложения. Все остальные операции производятся в основном из этих основных шагов. Тем не менее, он имеет гораздо более сложные операции. Используйте Руководство пользователя, чтобы узнать все функции этого программного обеспечения.
• Помните, что если вы используете Enterprise Edition или выше, вам потребуется адекватная поддержка сервера. Если вы не собираетесь работать с поддержкой серверной системы, рекомендуется оставаться на уровне ниже программного обеспечения Corporate Edition.

Что вам нужно

• Enterprise Architect (Полная версия)

Как освоить Enterprise Architect за месяц?(Прочитано 39887 раз)

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

В этой статье я хочу показать возможности Sparx Enterprise Architect 13, на конкретном примере моделирования деятельности ресторана. В примере будут задействованы следующие модели:

• Balanced Scorecard diagram (диаграмма сбалансированных показателей)
• Mind Mapping Diagram (ментальная диарамма,  карта мыслей, интеллект-карта)
• Organizational Structure diagram (диаграмма организационной структуры)
• Use Case Diagram (диаграмма прецедентов, диаграмма вариантов использования)
• Requirements Diagram (диаграмма требований)
• Custom Diagram (пользовательская диаграмма)

Все диаграммы были созданы с использованием стандартных шаблонов, предлагаемых SPARX EA 13 по мотивам тестового примера, предложенного в одном из руководств пользователя (на английском языке).

Структура примера, с указанием связи диаграмм, приведена на пользовательской диаграмме:

Получается следующая последовательность диаграмм (сверху-вниз):

1. Диаграмма сбалансированных показателей (перспектива “Процессы”)
2. Ментальная  карта
3. Элемент “Управлять персоналом” ментальной карты
4. Диаграмма организационной структуры
5. Элемент “Обслуживание клиентов” диаграммы оргструктуры
6. Диаграмма прецедентов
7. Вариант использования “Заполнить лист учёта рабочего времени” диаграммы прецедентов
8. Диаграмма требований

Диаграмма имеет классическую структуру из четырёх перспектив. При желании можно добавить дополнительные перспективы. С перспективы “Процессы”, в которой заявлена одна цель “Простая система учёта рабочего времени” идёт детализация на интеллект-карту:

Предполагается, что в ходе мозгового штурма родилась идея создать вебсайт ресторана, в закрытой части которого можно будет учитывать данные по персоналу в части учёта рабочего времени. С идеи “Управлять персоналом” детализация идёт на диаграмму организационной структуры:

Все работники, занимающиеся обслуживанием клиентов собраны под элементом “Обслуживание клиентов”. Именно для них и предполагается к разработке система учета рабочего времени основанная на таймшитах (листах учёта рабочего времени), диаграмма вариантов использования для которой приведена на следующей картинке:

И, наконец, финальная часть. Диаграмма требований для сценария “Заполнить лист учёта рабочего времени”:

И, напоследок, короткое видео (на 1 минуту, без звука), с демонстрацией всего того, о чём говорилось в этой статье:

Успехов в освоении инструментов по моделированию корпоративной архитектуры!