Предположим, у вас есть идея нового программного продукта. Поскольку продукт довольно сложен, вы знаете, что правильным курсом действий является предварительное проектирование его архитектуры. Как вы подходите к этой задаче? Если вы цените свое время и хотите достичь наилучших возможных результатов, вам следует рассмотреть Sparx Enterprise Architect, инструмент визуального моделирования и проектирования, который охватывает все аспекты цикла разработки и обеспечивает полную прослеживаемость от начальной фазы проектирования до развертывания, обслуживания и т.д. тестирование и контроль изменений.
Что такое Sparx Enterprise Architect?
Sparx Enterprise Architect — это инструмент моделирования полного жизненного цикла на основе UML, который используется для планирования, проектирования и создания программно-интенсивных систем и бизнес-процессов. Разработанный Sparx Systems, австралийской компанией-разработчиком программного обеспечения, основанной Джеффри Спарксом в 1996 году, Enterprise Architect доступен в четырех различных редакциях (вводная профессиональная версия, корпоративная командная версия, многофункциональная унифицированная версия и, наконец, версия Ultimate), каждая настроены для различных сценариев использования.
Using the Sparx Edge Checker
На момент написания у Enterprise Architect более 850,000 XNUMX пользователей по всему миру. Его пользователи охватывают широкий спектр отраслей, включая аэрокосмическую и оборонную, автомобильную, банковскую и финансовую, электротехническую, медицинскую, исследовательскую и академическую сферы, розничную торговлю, транспорт и коммунальные услуги. С момента своего первого выпуска Enterprise Architect стал предпочтительным инструментом моделирования UML для разработчиков, консультантов и аналитиков, которые используют его не только для моделирования архитектуры своих систем, но и для обработки реализации этих моделей на протяжении всего жизненного цикла разработки приложений. .
Несмотря на свое название, Sparx Enterprise Architect используется также архитекторами решений, которые отличаются от архитекторов предприятий по нескольким важным параметрам. Для начала архитекторы решений обычно сосредотачиваются на меньшем количестве проектов, чем архитекторы предприятий, которые, как правило, работают над несколькими проектами одновременно. В то время как архитекторы решений несут ответственность за создание и разработку конкретных продуктов, архитекторы предприятий стремятся стандартизировать методологии, подходы к проектированию, инструменты и технологии в масштабах всей организации.
Основные возможности Sparx Enterprise Architect
Sparx Enterprise Architect может похвастаться множеством впечатляющих функций, которые возвышают его над многими другими инструментами моделирования на основе ULM и позволяют ему превосходно моделировать и управлять сложной информацией, собирать и отслеживать требования от проектирования до развертывания и далее, объединяя команды из всех подразделений и всех этапов жизненный цикл продукта, понимание сложного программного обеспечения, совместное использование и повторное использование информации в различных инструментах и многое другое.
Introducing Sparx
Поддержка всех моделей и диаграмм UML 2.5
Enterprise Architect — первый инструмент UML, который представил всестороннюю поддержку UML 2 в апреле 2004 года, и он поддерживает все модели и диаграммы UML 2.5, позволяя моделировать бизнес-процессы, веб-сайты, пользовательские интерфейсы, сети, конфигурации оборудования, сообщения и многое другое. .
Помимо UML, Enterprise Architect также поддерживает новейшие спецификации Business Process Modeling Notation (BPMN) и System Modeling Language (SysML). BPMN — это графическое представление, основанное на технике блок-схем, очень похожее на диаграммы действий из UML, и используется для определения бизнес-процессов в модели бизнес-процессов. SysML — это язык моделирования общего назначения для приложений системной инженерии, который определяется как расширение подмножества UML с использованием механизма профилей UML.
Простое управление надстройками
Функциональность Enterprise Architect можно расширить с помощью надстроек, которые позволяют разработчикам программного обеспечения улучшать пользовательский интерфейс, добавляя новые меню, подменю, окна и другие элементы управления для выполнения широкого спектра функций. Надстройки можно публиковать как XMI и повторно использовать в различных моделях с помощью службы Reusable Asset Service (RAS), а активация динамической надстройки — это процесс, контролируемый безопасностью, который контролируется только администратором или другим уполномоченным лицом.
Майнер данных
Последняя версия Enterprise Architect упростила абстрагирование данных из ряда внешних источников данных, таких как базы данных, текстовые файлы и URL-адреса, и создание воспроизводимого процесса импорта, определенного в формате модели. Импортированные данные можно использовать для поддержки сложных визуальных представлений программных проектов или бизнес-процессов.
Настраиваемые таблицы и отчеты
Пользователи Enterprise Architect могут определять свои собственные настраиваемые таблицы и устанавливать цвета и границы ячеек, выравнивание, добавление ячеек, а также объединение ячеек. Они также могут воспользоваться функцией автоматизации для вычисления значений строк на основе данных модели и возможности заполнения из запроса SQL в пакете.
Enterprise Architect поддерживает принятие решений с помощью своих настраиваемых отчетов, которые можно создавать на лету, просто перетаскивая любое содержимое модели на артефакт открытого документа и выбирая подходящий шаблон во всплывающем диалоговом окне.
Наборы значков Google и AWS
Архитекторы решений и корпоративные архитектуры, работающие с Amazon Web Service или Google Web Service, могут оценить наличие наборов значков Google и AWS в последней версии Enterprise Architect, которые охватывают изображения, необходимые для моделирования диаграмм Amazon / AWS и диаграмм Google / GCP.
Интеграция Sparx Enterprise Architect с ALM
Sparx Enterprise Architect разработан для бесшовной интеграции с другими бизнес-инструментами, такими как платформа управления требованиями ALM, которая интегрируется в той же среде, поддержка других процессов, таких как управление рисками, управление тестированием, отслеживание проблем и дефектов и управление изменениями.
Благодаря интеграции Sparx Enterprise Architect с Visure Requirements ALM становится возможным отправлять требования, собранные Visure на этапе анализа, в Enterprise Architect и использовать их в качестве отправной точки для моделирования и проектирования. Это помогает повысить продуктивность жизненного цикла разработки программного обеспечения и систем, проводить анализ воздействия и расстановку приоритетов, сообщать о требованиях в течение жизненного цикла, а также четко определять и документировать требования.
Визуальные требования ALM предоставляет возможность выражать требования не только в виде текста, но и в виде высокоуровневых вариантов использования. Более того, информационная метамодель в Visure Requirements позволяет представить варианты использования и их отношения, исходящие от Enterprise Architect внутри Visure Requirements, вместе с требованиями и тестовыми примерами, чтобы иметь возможность выполнять сквозные изменения. анализ воздействия.
Все это и многое другое делает сочетание Sparx Enterprise Architect с Visure Requirements настолько эффективным, когда дело доходит до предоставления полной прослеживаемость от начального этапа проектирования до развертывания и далее.
Источник: visuresolutions.com
Sparx Enterprise Architect — инструмент системного аналитика
Sparx Enterprise Architect (EA) — программный продукт австралийской компании Sparx Systems.
Аннотация к статье: в нескольких абзацах мысли стараемся понять, почему система Sparx — инструмент системного аналитика по подготовке проектных документов, а не средство проектирования Enterprise-уровня. Проводится сравнение (преимущества и недостатки) с российском системой арх.моделирования СиММА (входит в реест российского ПО) и финской системой моделирования QPR EA (пока поставки в РФ прекращены).
Sparx Systems — австралийская компания-разработчик программного обеспечения, основанная Geoffrey Sparks в 1996 в Австралии (Creswick, Victoria).
Sparx Systems специализуется на разработке визуальных инструментов планирования, дизайна и разработки программного обеспечения. Sparx Enterprise Architect — наиболее известный продукт компании (существует с 2000 года), признаваемый самым продвинутым инструментом моделирования на UML. В 2006 компания Sparx Systems была первой, кто поддержал OMG Systems Modeling Language (SysML). Sparx Systems — член консорциума Object Management Group (OMG).
Sparx Enterprise Architect наиболее распространен среди системных аналитиков, как инструмент создания спецификаций на доработку или интеграцию систем. В чем причины популярности продукта в России:
- качественная реализация поддержки языка UML.
- низкая цена.
- широкое распространие взломанных версий, позволяющих попробовать продукт или использовать его время от времени.
- наличие шаблонов для создания моделей практически в любых современных нотациях (UML, BPMN, Archimate и еще несколько десятков других нотаций).
- поддержка возможностей реверс-инжиниринга (например, парсинг WSDL или построение ERD-диаграммы на базе уже готовой схемы базы данных).
Таковы сильные стороны. Англоязычные аналитики в своих обзорах подчеркивают одно свойство: способность Sparx EA генерировать автоматически нужную документацию.
Наиболее сильная сторона — возможность начать разработку диаграммы сразу после установки системы. Причем предлагаются десятки уже настроенных шаблонов. Однако истинная сила продукта состоит в том, что он ориентирован на UML во всём своём внутреннем строении.
Такая строгость нужна для того, чтобы по данным Sparx EA можно было бы автоматически генерировать полузаконченные куски программного кода. Однако, следует признать, что мы таких людей, генерирующих код из Sparx, не встречали на своем пути. То есть по факту наблюдаемой практики использования, Sparx — это не инструмент программиста, а инструмент аналитика. Остаётся понять, какого именно аналитика: бизнес-аналитика или системного?
Давайте вспомним, а чем собственно озабочен аналитик? С одной стороны — попыткой зафиксировать или смоделировать требования бизнеса. С другой стороны — выдать строгую спецификацию в адрес программистов. Побеждает конечно же бизнес-заказчик с требованиями нарисовать ему красивые диаграммы. Иначе требования не согласуют.
Работая с фантазиями бизнеса, бизнес-аналитик будет выбирать Visio, как инструмент не только более гибкий, но и доступный бизнесу для понимания. Visio-файл бизнес-заказчик умеет открывать и комментировать, добавляя туда не только замечания, но и новые элементы на схему. Sparx тоже предлагает множество нотаций (шаблонов различных нотаций много — десятки).
Но чтобы их хотя бы немного изменить, придется фактически программировать новый шаблон на UML — эта сложность, сложность кастомизации шаблонов, их строгость и костность отталкивают пользователей. В лучшем случае Sparx всё же будет использован (приживается) в качестве рисовалки диаграмм отдельными нердами команды, но не более того. Оправданием этих мучений станет автоматическое фомирование проектных документов, которые так не любят готовить дизайнеры систем. В результате, единственная надежная ниша для Sparx — это строгие шаблоны UML и возможность сгенерировать по ним документ типа Требование, Техническое Задание, Спека. Однако здесь нужно помнить, что ориентация проектирования на создание проектных документов уже надежно канула в лету, так как в погоне за формализмами документов проектировщики совершенно потеряли смысл проектирования, суть которого — поиск оптимальных системных решений.
Добавление одного атрибута в шаблон или тем более создание нового шаблона потребует не менее недели чистого времени в изучении англоязычных форумов. На это не у каждого хватает сил и терпения. Добавление одного нового атрибута занимает примерно 11 минут! 11 минут строго выверенных кликов с остановкой работы всех пользователей и даже возможно с перемиграцией данных вашей модели!
Но может быть наличие множества готовых шаблонов нивелирует как-то сложность их коррекции? Ведь в названии продукта от Sparx есть слово «Enterprise». Для нас пока остаётся загадкой, что вкладывают в данное понятие разработчики из Sparx Systems. Наша гипотеза: «Enterprise» означает возможность применять продукт EA в каждом отделе предприятия, ведь для каждого отдела найдется хотя бы один нужный для него шаблон какой-либо нотации.
Однако модели Sparx EA, построенные по разным шаблонам, не совместимы и не связываются друг с другом. Поэтому даже несмотря на поддержку таких нотаций и методологий как TOGAF и Archimate, Sparx EA не в состоянии создать в своей базе полноценный архитектурный репозиторий, содержащий строгие реестры ABB (Architecture building block). Наш анализ внедрений EA в РФ показывает, что дублирование данных является основной проблемой таких внедрений, превращая Sparx-репозиторий в обычную свалку схем из различных проектов. Другой интересный вывод нашего исследования: системой Sparx EA ввиду сложности ее интерфейса пользуются только сотрудники ИТ-отделов. Бизнес-подразделения предпочитают более дружественные инструменты, не перегруженные ИТ-шной спецификой.
Последним недостатком Sparx, как инструмента Enterprise-класса, является полное отсутствие функций навигации в моделях. Если у вас более сотни систем, функций или объектов данных, будьте готовы выучить их наизусть или дублировать внутри проекта почаще, чтобы они были у вас всегда под рукой в нужном месте.
Sparx EA позволяет организовать данные внутри своей модели только в виде одной иерархии вложенности объектов. Для крупных предприятий и масшабных проектов — это просто фатальное ограничение инструмента. Может быть поэтому типовой круг пользователей Sparx EA — это 1-2-3 человека, причем каждый использует однопользовательскую версию. О какой же групповой работе и тем более enterprise-архитектуре может идти речь? Даже инсталяции на 10-15 пользователей показывают, что продукт изначально создавался как однопользовательский и фичеров по обеспечению и облегчению групповой работы в нем практически не заложено.
Как итог, Sparx — отличный инструмент, облегчающий рутинные задачи системного аналитика по подготовке документов, специфицирующих работу создаваемого или изменяемого программного обеспечения. Для остальных задач, как то дизайн архитектуры ИТ или архитектуры предприятия, планирование трансформации, стоит поискать другие инструменты.
Для сравнения, QPR Enterprise Architect и российская СиММА позволяют:
- менять метамодель на лету прямо по ходу моделирования. Добавление одного атрибута или нового класса составляет около 10 секунд.
- сливать любые базы или фрагменты архитектурных баз, чтобы быстро решать задачи reuse’а проектных артефактов (данные, процессы, системы, функции, API, интеграции).
- смешивать любые нотации в любой пропорции, включая переопределение внешнего вида объектов в рамках любой диаграммы.
- вести данные в виде табличного набора сущностей (системы, процессы, транзакции, данные, интеграции, цели, задачи, продукты и т.п.), образуя тем самым первичные реестры сущностей. Диаграммы — вторичны, хотя можно начать создание репозитория путем размещения элементов на пустой диаграмме.
- представлять реестры сущностей (каталоги объектов) в виде неограниченного количества редактируемых VIEW (иерархические табличные представления данных репозитория), позволяющих трассировать объекты и связи в любом направлении с любого уровня.
Sparx всё это делать не умеет. Цель Sparx — нарисовать схему. Цель QPR или СиММА — создать репозиторий объектов и их связей. Поэтому для QPR/СиММА не важно сколько в репозитории объектов — 100, 200 или тысячи. Объекты будут эффективно (разнообразно и многократно соответственно задачам) представлены для обзора и анализа.
Sparx же практически ничего не может сделать без диаграммы, можно даже утверждать, что диаграмма является первичным артефактом моделирования. Нет диаграммы — нет и объектов в репозитории. Что, согласитесь, странно: сущности есть, но ввести их в систему можно только методом их рисования.
Еще одним индикатором «популярности» Sparx является полное отсутствие на рынке РФ профессиональных услуг по этой системе. Никто вас не научит, никто вам не поможет. Справедливости ради, стоит сказать, что число пользователей Sparx в мире достаточно велико и поэтому доступны многочисленные конференции на тему, кто и как справился с системой.
Существует и market place по плагинам и скриптам для Sparx. Так что если выбор тернистых путей — ваш выбор, то не отказывайтесь. В нашем опыте есть разные случаи: купили Sparx на 20 пользователей (имя компании не расскрываем) и через год обнаружили, что все пользователи рисуют свои диаграммы в draw.io, а система Sparx за год так и не пополнилась проектными артефактами. Деинсталлировали, тихо забыли. Другой пример — крупный банк (опыт описан на хабре): за 4 года эксплуатации ребята написали над Sparx свой application сервер, без которого репозиторий Sparx — просто мертвая банка с данными.
Более полное сравнение Sparx EA и QPR EA смотри во вложенном PDF-файле. По запросу файл может быть дополнен сравнением с СиММА.
Иногда говорят, что строгость Sparx импонирует больше, чем свобода QPR/СиММА. Но навести дисиплину в QPR все же возможно с помощью скриптов, а вот сделать Sparx свободным от его ограничений не получится никогда. Поэтому следует выбирать для работы то, что содействует вашему успеху и вашей эффективности, а не то, что просто стоит дешевле. Проектирование — это сегодня наиболее дорогой процесс, и любой инструмент, делающий проектирование эффективным, окупается именно через повышение производительности труда проектировщика (аналитик, архитектор, программист). Не говоря уже о том, что проектирование — это творчество, а творчество требует свободы!
Источник: marcus-aurelius.ru
Готовим проект в 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. Ингредиенты
Вот основное, что вам нужно.
- Дискомфорт – если вам комфортно в вашем текущем процессе создания информационной системы, если всё устраивает, значит или у вас уже есть 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.
2.2.3. Про структуру
Когда базовые требования были собраны, мы начали набрасывать проектные решения – структуру ИС, технологии, связи между компонентами, отдельные технические решения согласно вот этой части метамодели:
Это происходило так. Создавалась диаграмма для несуществующего пока решения. Благодаря этому мы накапливали в проекте Enterprise Architect элементы, описывающие систему и при формировании решений, в которых эти элементы были задействованы, мы просто повторно их использовали, перетаскивая на нужные диаграммы. В этом случае как раз и начинают работать связи, необходимые для анализа влияния.
Для описания структуры мы использовали четыре типа диаграмм – вариантов использования, компонентов, развёртывания и классов (для описания логической модели данных). Плюс к этому в ряде случаев в ход шли возможности EA по использованию внешних объектов – рисунков, файлов, rich-text документов.
Вот как, например, выглядит описания одного физического компонента (эквивалента модуля развёртывания) на диаграмме, в проекте EA и его связи, и ничего сложного.
2.2.4. Про постановки
После того, как базовые решения выработаны, можно приступать к дизайну и разработке программного кода, но для последнего нужны «постановки на разработку».
Постановка включает в себя описание того, как детально должна работать ИС в части какой-то функции или сценария работы, какие компоненты и методы в это вовлечены, какие сущности логической модели данных использованы.
На всякий случай – здесь и далее под функцией системы (описанной как пиктограмма варианта использования) подразумевается некий сложный процесс работы системы, например, обработка заявления на открытие накопительного счёта от пользователя может скрывать «развесистый» процесс взаимодействия нескольких системы или же частей одной системы.
На данном этапе функция системы – центр. Вокруг центра строятся следующие работы.
- Спецификация сценария работы функции.
- Алгоритмы, используемые в сценарии.
- Архитектурные требования – ограничение, которые необходимо соблюсти при реализации или алгоритмизации того или иного шага.
- Детализация и уточнения логической модели данных.
- Формирование физической модели данных.
- Формирование «бизнес-интерфейсов» для компонентов – набора операций, значимых с точки зрения предметной области, которые потом необходимо реализовать. Здесь надо отметить, что методы, показанные в метамодели пиктограммой варианта использования, избыточны – мы таким образом связываем шаги спецификации сценария работы функции и соответствующий интерфейс.
- Уточнение связей между элементами.
Сам процесс передачи организован через jira – создаётся задача, в ней указано место в проекте EA, где находится постановка, а также ветка SVN.
Постановка выглядит так:
2.2.5. Про дизайн
Дизайн включает описание базовых классов, программных интерфейсов, пакетов (в терминах java) и их связей с со структурой системы.
Помимо этого в дизайне у нас есть порядок взаимодействия компонентов и классов, показывающих реализацию функций системы.
Эту часть рецепта мы пока держим в секрете.
3. Вместо заключения
Пройдя несколько сумбурно описанные шаги нашего рецепта, мы получили наше блюдо – проект в EA.
Кому-то наш рецепт покажется странным, нелепым. Кто-то почерпнёт для себя новое. Кто-то начнёт готовить и будет рад результату, а кто-то нет.
И это нормально – ведь это только наш рецепт, для нашей IT-кухни.