sparx enterprise architect что это
СОДЕРЖАНИЕ
Обзор
База пользователей варьируется от программистов и бизнес-аналитиков до корпоративных архитекторов в различных организациях, от небольших компаний-разработчиков, многонациональных корпораций и государственных организаций до международных органов по отраслевым стандартам. Первоначально Sparx Systems выпустила Enterprise Architect в 2000 году. Первоначально разработанный как инструмент моделирования UML для моделирования UML 1.1, продукт эволюционировал и включил другие спецификации OMG UML 1.3, 2.0, 2.1, 2.3, 2.4.1 и 2.5.
Стандарты
Enterprise Architect поддерживает ряд открытых отраслевых стандартов для проектирования и моделирования программного обеспечения и бизнес-систем. Ниже перечислены основные поддерживаемые стандарты:
Enterprise Architect также поддерживает такие отраслевые инфраструктуры, как:
Enterprise Architect поддерживает фреймворки, поставляемые отраслевыми организациями:
Разработка стандартов
Модели, опубликованные органами по разработке отраслевых стандартов с использованием Enterprise Architect, включают:
Моделирование
Общие особенности
Управление требованиями
Общие функции управления требованиями, поддерживаемые Enterprise Architect, включают настройку документирования требований, привязку требований к деталям проектирования и реализации и обеспечение прослеживаемости требований на этапах проектирования и строительства. Эти требования могут быть предметом управления изменениями, обработки рабочего процесса, сравнения базовых показателей и аудита.
Бизнес-моделирование и анализ
Enterprise Architect поддерживает моделирование:
BPMN можно интегрировать с моделями DMN для моделирования. Это включает возможность генерировать исполняемый код из этих бизнес-правил. Бизнес-моделирование можно комбинировать с анализом пробелов, чтобы увидеть потенциальные пробелы в предлагаемых решениях.
Моделирование
Моделирование модели поддерживается для поведенческих диаграмм, включая: конечные автоматы, взаимодействия (диаграммы последовательности) и диаграммы активности. Для конечных автоматов и диаграмм действий поток выполнения определяется с помощью триггеров, средств защиты и эффектов. Моделирование поддерживает повторные запуски с изменением инициированных событий и поддерживает просмотр переменных, стека вызовов и установку маркеров отладки. Моделирование может взаимодействовать с эмулируемыми экранами пользовательского интерфейса, содержащими общие поля пользовательского интерфейса. Графические графики моделирования могут быть созданы.
Также имеется поддержка генерации исполняемого кода из State Machines как для моделирования, так и для использования в приложениях.
Модели BPMN (с использованием BPSim) можно моделировать, создавая табличные результаты для анализа. BPSim также поддерживает моделирование, основанное на вероятности Монте-Карло.
Моделирование SysML поддерживается для IBD и параметрических моделей с использованием Open Modelica или Matlab (с использованием Simulink и Simscape). Математические формулы во внутренних блок-схемах и параметрических моделях SysML можно моделировать для построения графиков, используемых в анализе.
Симуляция также поддерживается для DMN ( модель решения и нотация ). Моделирование включает создание кода, который можно использовать в приложениях, и поддерживает взаимодействие между моделями DMN и моделями BPMN с помощью BPSim.
Разработка системы
В соответствии с принципами разработки, управляемой моделями, Enterprise Architect предоставляет интегрированную среду разработки, которая поддерживает редактирование кода (с подсветкой синтаксиса и Intellisense ) для построения, отладки и тестирования кода изнутри модели.
Вайрфрейминг
Каркасное моделирование поддерживает использование шаблонов для моделирования внешнего вида диалогов, представляемых пользователям при взаимодействии с приложением. Поддерживаемые диалоговые окна устройств включают: экранные диалоги, веб-страницы, телефоны и планшеты Android, Apple и Windows 8.1.
Управление тестированием
Для тестирования на основе кода существует поддержка как xUnit Testing (это включает преобразование MDA классов в классы NUnit или Junit с возможностью генерировать модульные тесты из модели и автоматически записывать результаты по тестируемым классам). и Testpoint-тестирование (тестирование кода на основе модели. Оно аналогично тестовым контрактам, определенным в «Design by Contract», и выполняется с использованием определений отладки. Оба метода поддерживают определения тестов и результаты тестирования, которые регистрируются для связанных классов в модели.
Визуальный анализ исполнения
Системная инженерия
Моделирование данных
Enterprise Architect поддерживает моделирование данных от концептуального до физического уровней, прямое и обратное проектирование схем баз данных и преобразование MDA логической (независимой от платформы) в физическую СУБД (зависит от платформы).
Поддерживаемые типы диаграмм включают: нотацию DDL, нотацию ERD, нотацию IDEF1X, нотацию информационной инженерии.
Управление проектами и изменениями
Интеграция с другими инструментами
Pro Cloud Server Integration поддерживает интеграцию данных от внешних поставщиков, включая Application Lifecycle Management, Jazz (DOORS, Rhapsody DM, Team Concert CCM & QM), Jira, Confluence, TFS, Wrike, ServiceNow, Autodesk, Bugzilla, Salesforce и SharePoint.
Data Miner предоставляет средства извлечения данных из ряда внешних источников данных, включая: базы данных (ODBC, ADO, OLEDB, JET), текстовые файлы (XML, JSON, простой текст), Excel (xls, CSV) и онлайн-файлы. или URL-адреса.
Среди доступных надстроек есть интерфейсы к Microsoft Office и DOORS, а также надстройки сторонних производителей.
Enterprise Architect in 30 minutes
Welcome to the comprehensive overview of the capabilities of Sparx Systems Enterprise Architect 15.2. Each section focuses on a particular aspect of Enterprise Architect, providing an introduction to the purpose and benefits of each capability.
What is Enterprise Architect?
Enterprise Architect is a visual platform for designing and constructing software systems, for business process modeling, and for more generalized modeling purposes.
Enterprise Architect is based on the latest UML ® 2.5 specification (see www.omg.org). UML defines a visual language that is used to model a particular domain or system (either proposed or existing).
Enterprise Architect is a progressive tool that covers all aspects of the development cycle, providing full traceability from the initial design phase through to deployment, maintenance, testing and change control.
What differentiates Enterprise Architect from other UML tools?
How popular is Enterprise Architect now?
With 850,000+ effective users worldwide, Enterprise Architect has proven remarkably popular across a wide range of industries and is used by thousands of companies world-wide. From large, well-known, multi-national organizations to smaller independent companies and consultants, Enterprise Architect has become the UML modeling tool of choice for developers, consultants and analysts in over 130 countries.
Sparx software is used in the development of many kinds of software systems in a wide range of industries, including:
It is also used effectively for UML and business architecture training in many prominent colleges, training companies and universities around the world. Actual implementations range from single users to companies with over 1000 seats working on large, distributed projects.
Summary of Enterprise Architect Features
Enterprise Architect enables you to:
UML, BPMN and SysML
Enterprise Architect supports all UML 2.5 models and diagrams. You can model business processes, web sites, user interfaces, networks, hardware configurations, messages and many other aspects of your development.
In brief, Enterprise Architect:
In addition to UML, Enterprise Architect supports the latest Business Process Modeling Notation (BPMN) and Systems Modeling Language (SysML) specifications. Enterprise modeling notations are also supported out-of-the-box, including ArchiMate© 2.0, SoaML and SOMF©.
Enterprise Architect supports numerous other diagram types that extend core UML diagrams for strategic modeling, mind mapping, formal requirements specifications, data-flow diagrams, user interface prototyping and domain-specific modeling. The tool also provides alternative views that make editing the core UML diagrams more intuitive and effective. One example is the State Table editor, which renders a standard UML State Machine diagram as an editable logic table.
Topic Guide
Information Sheets
What benefits does Enterprise Architect provide?
Model and Manage Complex Information
Enterprise Architect helps individuals, groups and large organizations model and manage complex information. Often this relates to software development and IT systems design and deployment, but it can also relate to business analysis and business process modeling.
Enterprise Architect integrates and connects a wide range of structural and behavioral information, helping to build a coherent and verifiable architectural model, either what-is or what-will-be. Tools to manage versions, track differences, audit changes and enforce security help control project development and enforce compliance with standards.
Model, Manage and Trace Requirements
Capture requirements and use full traceability from base requirements to design, build, deployment and beyond. Use impact analysis to trace from proposed changes to original requirements. Build the ‘right’ system.
Integrate Teams and Share a Vision
A scalable, easily deployed, multi-user environment, Enterprise Architect integrates team members from all sections and all phases of a product’s (or system’s) development and maintenance life-cycle, providing significant benefits from built-in collaboration and inherent information sharing.
A single repository for business analysts, software architects, developers, project managers, testers, roll-out and support staff. A ‘unified’ view of a complex system having many view points and many possible sub-systems.
Design and Build Diverse Systems using UML
UML 2.5, an open standard, provides a rich language for describing, documenting and designing software, business and IT systems in general. Enterprise Architect allows you to leverage the full expressive power of UML 2.5 to model, design and build diverse systems in an open and well understood manner. Generate code, database structures, documentation and metrics. Transform models. Specify behavior and structure as the basis for contractual agreements.
Visualize, Inspect and Understand Complex Software
Software is complex and often hard to understand. Use Enterprise Architect to reverse engineer a wide variety of source code to understand static structure. To complete the picture, use the unique built-in profiling and debugging tools at run-time to capture and visualize executing software. Create run-time instances of model elements and invoke methods using the built in Object Workbench. Integrate existing data models by reverse engineering database schema for a wide range of systems.
Use Full Life-Cycle Modeling and Project Management
Capture and track information about model elements that are important to success: for example, Testing, Project Management and Maintenance details. Use this information to drive and track product development and delivery.
Share and Re-Use Information Across Tools
Enterprise Architect supports a number of mechanisms for exporting and importing models using industry standard XMI. This allows modelers to use information created in other tools, to copy information between Enterprise Architect models and even to write and use custom tools that take XMI directly as input.
Create Platform Independent Models using Model Driven Architecture
Model Driven Architecture (MDA) is an open standard designed to facilitate rapid application development in a platform independent manner. Models can be built at a high level of abstraction and using MDA based tools, transformed into models and code targeting a specific platform or domain. Enterprise Architect has a rich set of tools built-in to support MDA.
Modeling Based on Open Standards
As a contributing member of the Object Management Group, Sparx Systems understands the importance of open standards to communicate effectively to a wide range of stakeholders. To this end, Enterprise Architect helps you to:
Единый репозиторий для управления Enterprise Architecture
Моя история не для всех. В том смысле, что тема не хайповая. Но тем, кто в теме, надеюсь, будет интересно. Она (история) основана на реальном опыте последних лет. Я расскажу об одном из вариантов — с моей точки зрения, эффективном, — управления сложным архитектурным ландшафтом.
Что я подразумеваю под «сложным»: это несколько сотен бизнес-приложений с довольно внушительной дисперсией атрибутов — технологии, разнородность функциональности, связанность с другим приложениями, критичность, возраст, размер и так далее. Добавьте сюда динамику, поскольку ландшафт неустанно меняют несколько десятков внутренних и внешних команд. Иными словами — самый отпетый, или, на устойчивом жаргоне, «кровавый» энтерпрайз.
Очевидно, что в этом бурлящем котле каждая новая инициатива по изменению начиналась с поисков: где и что нужно делать, как определить достаточность и необходимость изменений. То есть проводился анализ. И поскольку котел большой и градус изменений высокий, то анализ, а он должен быть качественным, длился месяцами. Но тщательность не гарантировала 100%-го качества, поскольку на той же поляне, что и ваша инициатива, могли толкаться другие, внося непредвиденные вами изменения.
Кто-то скажет, что это обычная картина для «кровавого» энтерпрайза. То ли дело Agile-команды с единственным владельцем продукта. Всё учтено, и команда знает всё. Не буду спорить. Во многом это правда. Но на рваном лоскутном ландшафте независимых команд не построишь. А действительно крупные задачи одной командой не решишь. Да и в любой методологии должен быть разумный уровень порядка.
Единый архитектурный репозиторий
Именно с наведения порядка мы и начали. Это вылилось в создание единого архитектурного репозитория. Начнем с его мета-модели. По моему мнению, подобные изменения всегда надо начинать с разработки мета-модели. Это лучший способ объяснить заинтересованным сторонам и, самое главное, самим себе, что сможет дать новый репозиторий. Мета-модель покажет, как ваши цели ложатся на возможности систем, где репозиторий будет реализовываться. При её разработке проще всего посмотреть на документы, которые уже есть в вашей компании. Изучите имеющийся опыт. Посмотрите на ванильные модели различных вендоров. Если уж совсем по-серьезному, то почитайте ГОСТы, например, ГОСТ 57100 (ISO 42010).
Для начала включайте в мета-модель только самое необходимое, поскольку начинать лучше с простого. Потом, если окажется, что такой модели недостаточно, то развить её не составит труда. Причем развитие будет осознанным. То есть здесь самый правильный подход — итеративный. Начинайте с небольшого участка архитектуры. Посмотрите, как с ней справляется ваша модель. Достаточно ли в ней элементов, связей и атрибутов для поставленных целей и тогда принимайте решение о ее развитии.
Мы подошли к мета-модели сугубо утилитарно. В качестве перспективных были определены три цели:
Solution в основном повторяет структуру “Current”, но имеет некоторые особенности.
Хотя и сейчас модель остается довольно простой, но первый вариант был значительно проще. Это был только слой Application. Потом репозиторий пополнился компонентами, потом бизнес-объектами и бизнес-слоем.
Время от времени мы ощущаем последствия лаконичности модели, но для нас гораздо важнее не её усложнение, а зона покрытой репозиторием архитектуры и актуальность информации в репозитории. Так что, похоже, мы нашли ту золотую серединку, когда хватает сил на поддержание актуальной информации в репозитории и в тоже время уровень детализации полезен и достаточен для анализа архитектуры и создания решений для инициатив.
В основе нашего репозитория лежит Sparx Enterprise Architect: были использованы почти все возможности, предоставляемые этой системой по кастомизации решения — используется своя мета-модель (технология MDG), поддерживаемая тысячами строк кода на Java и Javascript. Конечно, кастомизация ведет к необходимости самостоятельного развития и поддержки, но мы были к этому готовы.
Current Architecture
Теперь немного подробнее о том, что из себя представляет текущая состояние репозитория.
На уровне бизнес-слоя основными элементами являются бизнес-сервисы и сценарии использования:
И сценарии использования:
В нашем случае сценарии использования детализируют бизнес-сервис в конкретных условиях его применения. Но всё же сценарий — это довольно крупно-гранулярное представление бизнес-функциональности.
Сценарии использования автоматизируются приложениями — это уже уровень Application Architecture, где приложения связаны между собой информационными потоками:
Потоки содержат бизнес-объекты из слоя Data Architrecture:
Основой для Application Architecture является Component Architecture, где каждое приложение имеет представление своей структуры в виде компонентов, а потоки детализируются в виде взаимодействия компонентов через интерфейсы:
Теперь посмотрите еще раз на упомянутые элементы и их взаимоотношения. Всё очень просто, но позволяет на достаточном уровне описать архитектуру крупного банка. После нескольких лет работы в репозитории накопилось почти десять тысяч архитектурных элементов, между которыми сформировалось несколько десятков тысяч связей. И это только Current Architecture.
Solution Architecture
Перейдем ко второму пункту обозначенных выше целей. Нам требуется создавать Solution Architecture для инициатив различных размеров, реализуемых по различным методологиям, включая Agile.
Решение описывается для каждого слоя архитектуры. Мета-модель Solution части репозитория в основном повторяет структуру Current, но имеет отличия. Например, набор атрибутов пересекается лишь частично. Плюс элементы и связи из части Solution имеют набор атрибутов, необходимых для описания решения.
Пройдемся по всем четырем слоям решения.
Бизнес архитектура содержит два вида элементов. Это крупные Use Cases, которые реализуются в проекте, и более детальные Requirements для «водопадных» проектов или User Stories в случае Agile-инициатив. Причем Use Cases обязательно имеют своё зеркало в части Current. При этом Requirements и User Stories — это элементы исключительно части Solution и не имеют представления в части Current. Еще одна важная деталь: Sparx-репозиторий не является для них мастер-системой. Они экспортируются из других систем.
Requirements и User Stories сопоставляются с ответственными за них приложениями.
Оставшиеся слои Solution Architecture имеют диаграммы, похожие на Current Architecture:
Цветовая гамма элементов и связей Solution Architecture передает вид архитектурных изменений. Описание изменений можно заносить как в соответствующие атрибуты элементов и связей, так и в прикрепленные к элементам Notes.
На основе этих данных генерируются соответствующие части архитектурного документа.
Хотя, как показывает практика, наиболее востребованными являются диаграммы. Именно они используются во время обсуждений с Enterprise-архитекторами, командами разработчиков, вендорами и на Архитектурном комитете.
Что самое замечательное, в силу «единственности» репозитория все элементы и связи, используемые на диаграммах, задокументированы и единообразно понимаются всеми участниками дискуссий. Поэтому, изначально все участники находятся на одной волне.
| |
|---|---|
| При анализе больших инициатив Solution-архитектор не тратит время на поиск информации | Software-архитектор при изучении Solution-архитектуры видит хорошо знакомые ему элементы. Он понимает, о чем эта архитектура |
Еще один выдающийся момент. Описание Solution-архитектуры достаточно для актуализации текущего ландшафта. Таким образом, по факту выпуска решения в production, архитектурные изменения с помощью скриптов переносятся из части Solution в часть Current.
Репозиторий благодаря такой взаимосвязи остается актуальным несмотря на постоянные инициативы по изменениям ландшафта.
Поддержка репозитория
Репозиторий с таким значительным количеством элементов и связей, в котором работают десятки пользователей, надо содержать в адекватном состоянии. Например, все обязательные атрибуты должны быть заполнены; связи между элементами должны быть определенного вида. Более того, состояние архитектур Application и Component должно соответствовать одно другому, поскольку они представляют одни и те же приложения, но с разной степенью детализации.
Конечно, обучение пользователей играет важную роль. Но этого крайне мало. Людям свойственно ошибаться. Мы смягчили эту проблему с помощью кода на Java и JavaScript. Каждую ночь по расписанию запускаются скрипты, которые значительно облегчают нашу жизнь:
Выводы
Сравнивая два состояния — сегодняшний день и тот «доисторический» период, — однозначно можно отметить, что требования к архитекторам возросли. Вырос и порог входа для любого человека, которому по тем или иным причинам необходим анализ архитектуры.
Крайне важным является то, что люди, ответственные за ведение репозитория, тратят на это достаточно много времени и, в нашем случае, должны уметь разрабатывать код.
Возвращаясь к мета-модели репозитория, хочу отметить, что в рамках простой модели очень сложно свести воедино мнение многих заинтересованных сторон, и еще сложнее оставаться с нею продолжительное время. И любые изменения в мета-модели должны в том или ином виде отразиться в скриптах автоматизации.
С другой стороны, анализ архитектуры и дизайн решения стали проще и значительно короче. Качество Solution-архитектуры возросло на порядок. Решение стало намного детальнее и всегда остаётся консистентным. В работе архитектора теперь минимизированы рутинные операции, связанные с оформлением документации, с необходимостью поддержки её в актуальном состоянии. Архитектор действительно занимается творчеством.
И в заключении несколько слов об инструменте, который мы использовали для реализации репозитория, о Sparx Enterprise Architect. С моей точки зрения, у него выдающееся соотношение цена/качество. Конечно, в основном это обусловлено его низкой ценой, но присутствует практически вся необходимая нам функциональность.
Что нам не хватает, так это разнообразных интерактивных вьюшек на данные в архитектурном репозитории. Ведь качественный анализ без них крайне затруднен. Начинали мы с простых SQL-запросов напрямую к базе данных Sparx. Но потом решили эту проблему самостоятельной разработкой. Дополнительно к самому Sparx мы смотрим на репозиторий через кастомное веб-приложение, где наиболее популярные вьюшки представлены в табличном виде с возможностью фильтрации, сортировки и трассировки между ними по выбранным значениям:
Готовим проект в 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 и их публикацию на Хабре.