sparx enterprise architect обучение
Пример моделирования на Sparx Enterprise Architect 13
Пример моделирования на Sparx Enterprise Architect 13
В этой статье я хочу показать возможности Sparx Enterprise Architect 13, на конкретном примере моделирования деятельности ресторана. В примере будут задействованы следующие модели:
Все диаграммы были созданы с использованием стандартных шаблонов, предлагаемых SPARX EA 13 по мотивам тестового примера, предложенного в одном из руководств пользователя (на английском языке).
Структура примера, с указанием связи диаграмм, приведена на пользовательской диаграмме:
Получается следующая последовательность диаграмм (сверху-вниз):
Диаграмма имеет классическую структуру из четырёх перспектив. При желании можно добавить дополнительные перспективы. С перспективы «Процессы», в которой заявлена одна цель «Простая система учёта рабочего времени» идёт детализация на интеллект-карту:
Предполагается, что в ходе мозгового штурма родилась идея создать вебсайт ресторана, в закрытой части которого можно будет учитывать данные по персоналу в части учёта рабочего времени. С идеи «Управлять персоналом» детализация идёт на диаграмму организационной структуры:
Все работники, занимающиеся обслуживанием клиентов собраны под элементом «Обслуживание клиентов». Именно для них и предполагается к разработке система учета рабочего времени основанная на таймшитах (листах учёта рабочего времени), диаграмма вариантов использования для которой приведена на следующей картинке:
И, наконец, финальная часть. Диаграмма требований для сценария «Заполнить лист учёта рабочего времени»:
И, напоследок, короткое видео (на 1 минуту, без звука), с демонстрацией всего того, о чём говорилось в этой статье:
Успехов в освоении инструментов по моделированию корпоративной архитектуры!
Готовим проект в Sparx Enterprise Architect. Наш рецепт
Дорогой Хабр, мы решили поделиться заметками и нашим базовым рецептом о приготовлении проектов в 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. Немного капитанства
Основные этапы жизни проекта по созданию информационной системы (да и в целом, наверно, почти любого проекта с точностью до определения каждого этапа) вполне очевидны – как по ГОСТ, так и просто исходя из здравого смысла. Это:
Для концепций мы пока не применяем Enterprise Architect, так как обычно нужно все делать быстро, срочно, очень красиво. Так что это word, visio c различными расширениями или иные рисовалки (где ну вообще красота). Эскиз, к сожалению, заказчика не интересует, хотя мы бы и рады готовить его в EA. Два последние пункта – это или про ошибки (они решаются (во всяком случае у нас) иными средствами и инструментами) или про доработки, и тогда это всё заворачивается в пункты 3-5.
Поэтому поговорим про такие этапы, как техническое задание (сбор и выявление требований), техническое проектирование (разработка архитектуры), рабочее проектирование (разработка и дизайн).
1.3. Для тех, кому не терпится попробовать результат (спойлер)
Диаграмма компонентов (в данном случае каждый компонент – это один модуль развёртывания), связей между ними, базовых протоколов.
Диаграмма развёртывания общего программного обеспечения по узлам, с указанием основных связей
2. Про рецептуру
2.1. Ингредиенты
Вот основное, что вам нужно.
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.
Неоднократно задумывались, почему так происходит. На текущий момент мы пришли к следующим выводам.
2.2.3. Про структуру
Когда базовые требования были собраны, мы начали набрасывать проектные решения – структуру ИС, технологии, связи между компонентами, отдельные технические решения согласно вот этой части метамодели:
Это происходило так. Создавалась диаграмма для несуществующего пока решения. Благодаря этому мы накапливали в проекте Enterprise Architect элементы, описывающие систему и при формировании решений, в которых эти элементы были задействованы, мы просто повторно их использовали, перетаскивая на нужные диаграммы. В этом случае как раз и начинают работать связи, необходимые для анализа влияния.
Для описания структуры мы использовали четыре типа диаграмм – вариантов использования, компонентов, развёртывания и классов (для описания логической модели данных). Плюс к этому в ряде случаев в ход шли возможности EA по использованию внешних объектов – рисунков, файлов, rich-text документов.
Вот как, например, выглядит описания одного физического компонента (эквивалента модуля развёртывания) на диаграмме, в проекте EA и его связи, и ничего сложного.
2.2.4. Про постановки
После того, как базовые решения выработаны, можно приступать к дизайну и разработке программного кода, но для последнего нужны «постановки на разработку».
Постановка включает в себя описание того, как детально должна работать ИС в части какой-то функции или сценария работы, какие компоненты и методы в это вовлечены, какие сущности логической модели данных использованы.
На всякий случай – здесь и далее под функцией системы (описанной как пиктограмма варианта использования) подразумевается некий сложный процесс работы системы, например, обработка заявления на открытие накопительного счёта от пользователя может скрывать «развесистый» процесс взаимодействия нескольких системы или же частей одной системы.
На данном этапе функция системы – центр. Вокруг центра строятся следующие работы.
Сам процесс передачи организован через jira – создаётся задача, в ней указано место в проекте EA, где находится постановка, а также ветка SVN.
Постановка выглядит так:
2.2.5. Про дизайн
Дизайн включает описание базовых классов, программных интерфейсов, пакетов (в терминах java) и их связей с со структурой системы.
Помимо этого в дизайне у нас есть порядок взаимодействия компонентов и классов, показывающих реализацию функций системы.
Эту часть рецепта мы пока держим в секрете.
3. Вместо заключения
Пройдя несколько сумбурно описанные шаги нашего рецепта, мы получили наше блюдо – проект в EA.
Кому-то наш рецепт покажется странным, нелепым. Кто-то почерпнёт для себя новое. Кто-то начнёт готовить и будет рад результату, а кто-то нет.
И это нормально – ведь это только наш рецепт, для нашей IT-кухни.
Мы уверены надеемся, что наши заметки не будут приняты в штыки и что будет конструктивная критика и полезные вопросы, отталкиваясь от которых мы сможем подкорректировать наш рецепт и продолжить наши заметки про использование Enterprise Architect и их публикацию на Хабре.
UML&Enterprise Architect: проектируем целевой процесс при создании автоматизированной системы
Советский плакат «Автоматическую систему управления производством — народному хозяйству!», художник Р. Сурьянинов, 1972
«Рассказ о моделировании именно сложных систем»
Предыстория
К одной из моих статей по моделированию «сказочной» предметной области (часть 1, часть 2) был оставлен комментарий, цитирую:
И я пообещала подобрать что-то из реальной жизни.
Несколько слов о языке моделирования, среде моделирования, методологии и соглашении по моделированию
Среда моделирования
В качестве инструмента моделирования используется Enterprise Architect от австралийской компании Sparx Systems [2].
Методология и соглашение по моделированию
До начала проектирования необходимо установить определенные правила и подходы, которым мы будем следовать при разработке диаграмм, эти же правила будут использоваться при «чтении» диаграмм. Подробно основные подходы описаны в [3, 4].
Этап 1. Разрабатываем карту процессов с помощью Use-case диаграммы, на нее помещаем все выявленные целевые процессы – элементы Use-case, а также участников процессов – элементы Actor, стараемся процессы сразу сгруппировать по смыслу (по возможности, конечно).
Этап 2. Описываем каждый процесс в виде диаграммы Activity. Для процесса, в котором выделено более 10 шагов, имеет смысл применить принцип декомпозиции шагов процесса, чтобы повысить читабельность диаграммы. Для диаграмм Activity нижнего уровня применяем структурирование поля диаграммы с помощью «плавательных» дорожек – Swim lanes. Имя дорожки будет соответствовать типу элементов диаграммы, которые будут размещены на этой дорожке. «Вх./вых. объекты»: на этой дорожке будут располагаться элементы Objects – объекты, которые используются или являются результатом выполнения некоторого шага процесса. «Деятельность»: сюда поместим элементы Activity – действия участников процесса. «Роль»: дорожка для элементов, которые будут обозначать роли исполнителей действий в нашем процессе, для них мы будем использовать все тот же моделирующий элемент Object – объект, но добавим ему стереотип «Actor». Следующая дорожка называется «Правила» и на этой дорожке разместим в текстовом виде правила выполнения шагов процесса, а использовать для этого будем моделирующий элемент Note – примечание. Дорожку «Инструменты» будем использовать для сбора сведений об уровне автоматизации процесса.
Этап 3. Выделяем то, что можно автоматизировать. У нас будет три типа шагов: ручное выполнение, автоматизированное и полностью автоматическое.
Этап 4. Автоматизируемому шагу нужно поставить в соответствие функцию или функции системы (отношение может быть многие-ко-многим), рисуем Use-case диаграмму. Это функции нашей системы.
Этап 5. Опишем внутреннюю организацию системы с помощью диаграммы классов – Class. Плавательная дорожа «Вх./вых. объекты» на диаграмме Activity – это основа для построения объектной модели и модели сущность-связь.
Этап 6. Проанализируем заметки на дорожке «Правила», они дают различного рода ограничения и условия, которые постепенно трансформируется в нефункциональные требования.
Этап 7. Элементы на дорожке «Инструменты» говорят нам об уровне автоматизации процесса.
Полученная совокупность диаграмм дает формализованное описание в достаточно строгой нотации, т.е. имеет однозначное прочтение. Теперь можно разрабатывать техническое задание, уточнять спецификацию требований и т.д.
Моделирующие элементы диаграммы Use-case для карты процессов
Моделирующие элементы диаграммы Activity
Краткие сведения об объекте автоматизации
Объектом автоматизации являются процессы обеспечения качества производства медицинских изделий.
Процесс изготовления медицинских изделий характеризуется наличием большого количества ручных операций. Управление качеством регламентировано в соответствии со стандартом ГОСТ ISO 13485-2011. Изделия медицинские. Системы менеджмента качества. Системные требования для целей регулирования.
Для осуществления контроля качества необходимо осуществлять контроль и регистрацию всех операций при производстве медицинского изделия для последующего расследования возможных происшествий.
В качестве носителя регистрационной информации используется штрих-код. Для считывания информации используется дистанционный считыватель штрих-кодов.
Разрабатываемая автоматизированная система (АС) контроля изготовления медицинских изделий предназначена для:
Карта процессов — диаграмма Use-case
На Рисунке 1 представлена карта процессов АС контроля изготовления медицинских изделий. Зеленым цветом выделены процессы, для которых далее будут приведены сценарии выполнения.
Рисунок 1. Карта процессов автоматизируемой системы контроля изготовления медицинских изделий
Примеры сценариев выполнения процессов – диаграммы Activity
На Рисунках 2-5 представлены примеры сценариев выполнения процессов АС контроля изготовления медицинских изделий.
Рисунок 2. Подготовка к работе (начало смены)
Рисунок 3. Изготовление мед. изделия (макрошаги)
Рисунок 4. Начало изготовления мед.изделия
Рисунок 5. Изготовление мед.изделия
Жизненный цикл объекта – диаграмма State Chart
На диаграммах Activity состояния обозначены в квадратных скобках до или после имен объектов.
Полный жизненный цикл изготовления медицинского изделия представлен на диаграмме состояний – State Chart (Рисунок 6).
Рисунок 6. Диаграмма состояний изготовления мед.изделия
Структура системы
Система логически разделена на подсистемы по функциональному признаку:
Автоматизируемые процессы в разрезе подсистем и модулей представлены на рисунке ниже (Рисунок 7).
Рисунок 7. Автоматизируемые процессы в разрезе подсистем и модулей
Это, конечно, не все диаграммы, но для того, чтобы дать представление о модели, думаю, достаточно.
Вместо заключения
Когда приступали к разработке системы, знания о предметной области основывались только на упомянутом в начале ГОСТ ISO 13485-2011 про медицинские изделия и описании потребностей заказчика на полстраницы. Модели обсуждали с заказчиком, особых трудностей в «чтении» моделей не наблюдалось.
UML-моделирование с использованием Sparx Enterprise Architect
Описание
Программный продукт Enterprise Architect, поставляемый компанией Sparx Systems, является удобным инструментальным средством для построения моделей в процессе проектирования программного обеспечения. Этот продукт поддерживает большое количество разнообразных нотаций для построения моделей, но в курсе рассматривается только одна из них – UML (Unified Modeling language).
Работа с UML-диаграммами изучается в ходе выполнения практических упражнений, каждое из которых посвящено построению одного из видов диаграмм в рамках единого проекта. Навыки работы с Enterprise Architect, полученные в ходе курса, будут полезны и при освоении других нотаций, поддерживаемых продуктом.
В практических занятиях используется версия Enterprise Architect, являющаяся наиболее актуальной на момент проведения курса.
Разбираемые темы
Обзор возможностей системы и интерфейса пользователя (теория 60 мин, практика 40 мин).
Целевая аудитория
Предварительная подготовка
Так как курс является инструментальным, предполагается, что слушатели уже знакомы с основами использования UML при проектировании программного обеспечения (см. раздел «Связанные курсы»).
Желательно наличие опыта участия в проектах по разработке программного обеспечения на основе объектно-ориентированного подхода.
Рекомендуется знание принципов работы с требованиями и написания сценариев использования.
В ИТ-отрасли Дмитрий работает с 1992 г. Начинал свою карьеру как разработчик и архитектор, принимал участие в разработке систем автоматизированного проектирования (САПР), систем расчета заработной платы, учетных систем и даже русско-украинского переводчика.
Смена мест работы лишь расширяла кругозор и ставила новые более интересные задачи, но не меняла направленности – во всех компаниях, где работал Дмитрий, он управлял ИТ-подразделениями и/или ИТ-проектами. При этом он всегда стремился сделать разрабатываемые системы «умными» и удобными для конечных пользователей, превратить компьютер из «продвинутой пишущей машинки» в инструмент анализа и управления бизнесом.
То, что успешность ИТ-проекта зависит от правильно сформулированных требований, он понял достаточно быстро на основе собственного опыта. А чтобы требования были выявлены и описаны корректно, необходимо понять специфику бизнеса компании-заказчика, выяснить истинные потребности стейкхолдеров и суметь потом всю полученную информацию передать разработчикам. Так постепенно интересы Дмитрия смещались от просто разработки программного обеспечения к повышению эффективности деятельности компаний.
В 2004 г. он окончательно перешел в сферу бизнес- и системного анализа, но при этом сохранил верность ИТ, поэтому практически все его проекты так или иначе связаны с автоматизацией и оптимизацией бизнес-процессов.
Начиная с 2006 г. Дмитрий продолжает свою карьеру исключительно в ИТ-компаниях, профессионально создающих программное обеспечение. Это зависело от нескольких факторов. Во-первых, появляется возможность в ходе каждого очередного проекта изучить новую предметную область, новый вид бизнеса, нового заказчика, что прекрасно расширяет кругозор и тренирует способность поиска эффективных решений. Во-вторых, именно в «фабриках программного обеспечения» процесс разработки ПО построен по-настоящему полно и качественно.
В ряде проектов Дмитрий выполнял роль руководителя проекта, но роль аналитика – специалиста, отвечающего за выявление и удовлетворение потребностей заказчика, – всегда была ему ближе. Для того чтобы лучше понимать современные подходы к управлению бизнесом (а значит лучше понимать потребности, мотивы и опасения заказчиков), Дмитрий получил в 2012 г. второе высшее образование – степень МВА (Master of Business Administration).
Одна из составляющих роли аналитика в ИТ-проектах – необходимость объяснять простыми словами порой достаточно сложные понятия: разработчикам – нюансы бизнеса заказчика, заказчику – нюансы ИТ-технологий и решений. Умение объяснять, в котором, кроме всего, Дмитрию помогает его давнее увлечение психологией, постепенно стало превращаться в самостоятельную деятельность – проведение тренингов, мастер-классов, консалтинг ИТ-команд.
В итоге с 2012 г. Дмитрий стал штатным экспертом по бизнес-анализу Luxoft Training.
В качестве эксперта Дмитрий проводил курсы для сотрудников таких компаний, как Райффайзен Банк Аваль, АСТЕЛИТ, Альфа-банк Украина, МТС Украина, Киевстар, ELEKS, ГРУППА КОМПАНИЙ FOZZY GROUP, Миратех, УкрСиббанк, Энвижн Групп, iBox, Инфопульс Украина, ПриватБанк, Укрэксимбанк, РОВНОАЗОТ OSTCHEM, ЮРИЯ-ФАРМ, Укрсоцбанк, ПроКредит Банк и других.