Аркадия (инженерия) - Arcadia (engineering)

ARCADIA, метод проектирования на основе моделей для архитектурного проектирования систем, аппаратного и программного обеспечения.

АРКАДИЯ (Дугаархитектура Аанализ и Dдизайн яинтегрированный Аpproach) это система и программного обеспечения архитектурно-инженерный метод, основанный на архитектурно-ориентированных и модельно-ориентированная инженерия виды деятельности.

История

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

В качестве ответа на этот вызов метод ARCADIA был создан Фалес в 2007 г., разместив архитектура и сотрудничество в центре практики системной инженерии.

Видение ARCADIA состояло в том, чтобы разрушить «стены» между различными инженерными специальностями, включая архитекторы, команды разработчиков, специалисты, IVVQ Команды, Заказчик и внешние партнеры.

Нормализация

Метод ARCADIA скоро будет стандартизирован как AFNOR экспериментальная норма.[1] Он был опубликован 7 марта 2018 года.

Контекст

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

Цели и средства действий

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

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

ARCADIA основана на следующих общих принципах:

  • Все заинтересованные стороны в проектировании используют один и тот же язык, набор методов инженерных артефактов и информации, описание потребности и сам продукт как общую модель;
  • Каждый набор ограничений (например, безопасность, производительность, стоимость, масса и т. Д.) Формализуется в виде «точки зрения», по которой будет проверяться каждая архитектура-кандидат;
  • Устанавливаются правила проверки архитектуры, и модель сравнивается с ними, чтобы проверить соответствие определения архитектуры ожиданиям как можно раньше в процессе;
  • Совместное проектирование между различными уровнями инженерии поддерживается совместной разработкой моделей. Модели различных уровней архитектуры и компромиссов выводятся, проверяются и / или связываются друг с другом.

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

Обзор возможностей

Метод ARCADIA:

  • Охватывает все структурированные инженерные работы, от регистрации эксплуатационных потребностей клиентов до проверки системной интеграции (IVV);
  • Учитывает несколько инженерных уровней и их эффективное взаимодействие (система, подсистема, программное обеспечение, оборудование и т. Д.);
  • Интегрирует совместный инжиниринг со специальным инжинирингом (безопасность, безопасность, производительность, интерфейсы, логистика ...) и IVV;
  • Предоставляет возможность не только совместно использовать описательные модели, но также совместно проверять свойства определения и архитектуры;
  • Он прошел полевые испытания в полномасштабных промышленных приложениях и в настоящее время используется в десятках крупных проектов в нескольких странах и подразделениях Thales.

Методологический подход

Точки обзора
Точки обзора
Сотрудничество
Сотрудничество

Одна из трудностей, часто встречающихся при разработке сложных систем, возникает из-за наложения нескольких частично независимых функциональных цепочек с использованием общих ресурсов (включая, но не ограничиваясь, вычислительные ресурсы). Метод ARCADIA и лежащие в его основе инструменты используются для определения функциональных цепочек, их перекрывающихся сценариев и желаемой производительности, а также их поддержки архитектурой. Начиная с первого уровня системного анализа, они обеспечивают прослеживаемость на протяжении всего определения процесса и проверяют каждый предложенный архитектурный проект на предмет ожидаемых характеристик и ограничений.

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

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

Презентация подхода и ключевых концепций

Представления первого уровня, используемые для разработки и совместного использования модели архитектуры, описаны ниже:

  • «Определить проблему - Анализ эксплуатационных потребностей клиента»,

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

  • «Формализация требований к системе / ПО - Анализ потребностей системы / ПО»,

Второй шаг теперь сосредоточен на самой системе / ЕО, чтобы определить, как она может удовлетворить прежнюю операционную потребность, а также ее ожидаемое поведение и качества: функции системы / ЕО, которые должны поддерживаться и связанные с ними обмены, нефункциональные ограничения (безопасность, безопасность ...), характеристики, выделенные для границ системы, разделения ролей и взаимодействия между системой и операторами. Он также проверяет выполнимость (включая стоимость, график и технологическую готовность) требований заказчика и, при необходимости, дает средства для пересмотра их содержания. Для этого набрасывается первая ранняя архитектура системы / ПО (модель архитектурного проектирования), исходя из функциональных потребностей системы / ПО; затем требования сравниваются с этой архитектурой, чтобы оценить их стоимость и согласованность. Выходы этого шага в основном состоят из описания функциональности системы / ЕО, функциональной совместимости и взаимодействия с пользователями и внешними системами (функции, обмены плюс нефункциональные ограничения), и требования к системе / ПО.

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

  • «Разработка архитектуры системы / ПО - логическая архитектура»,

Третий шаг направлен на идентификацию частей системы / ЕО (далее называемых компонентами), их содержимого, взаимосвязей и свойств, за исключением реализации или технических / технологических проблем. Это составляет логическую архитектуру системы / ПО. Для того, чтобы эта разбивка на компоненты была стабильной на дальнейших этапах, принимаются все основные [нефункциональные] ограничения (безопасность, производительность, IVV, стоимость, нетехнические и т. Д.) учитывать и сравнивать друг друга, чтобы найти лучший компромисс между ними. Этот метод описывается как «управляемый точками зрения», причем точки зрения представляют собой формализацию того, как эти ограничения влияют на архитектуру системы / ПО. Выходы этого шага состоят из выбранной логической архитектуры: определение компонентов и интерфейсов, включая формализацию всех точек зрения и способ их учета при проектировании компонентов. Поскольку архитектура должна быть проверена на соответствие требованиям, также создаются ссылки на требования и сценарии работы.

  • «Разработка архитектуры системы / ПО - физическая архитектура»,

Четвертый шаг имеет те же цели, что и построение логической архитектуры, за исключением того, что он определяет «окончательную» архитектуру системы / ПО на этом уровне разработки, готовую к разработке (на более низких уровнях разработки). Следовательно, он вводит рационализацию, архитектурные шаблоны, новые технические услуги и компоненты, а также заставляет логическую архитектуру развиваться в соответствии с реализацией, техническими и технологическими ограничениями и вариантами (на этом уровне разработки). Обратите внимание, что для определения физической архитектуры используется тот же метод «на основе точек зрения», что и для построения логической архитектуры. Выходы этого шага состоят из выбранной физической архитектуры: компонентов, которые должны быть произведены, включая формализацию всех точек зрения и способ их применения. учет в конструкции компонентов. Также создаются ссылки с требованиями и рабочими сценариями.

  • «Формализовать требования к компонентам - контракты на разработку и IVVQ»,

Пятый и последний шаг - это вклад в построение EPBS (иерархическая структура конечного продукта) с использованием преимуществ предыдущей архитектурной работы, для обеспечения определения требований к компонентам и подготовки защищенного IVVQ. Все варианты, связанные с выбранной архитектурой системы / ПО, и все гипотезы и ограничения, налагаемые на компоненты и архитектуру в соответствии с потребностями и ограничениями, суммируются и проверяются здесь. Результаты этого шага в основном представляют собой «контракт интеграции компонентов», в котором собраны все необходимые ожидаемые свойства для каждого компонента, который будет разработан.

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

Фазы проектирования ARCADIA
Авария

Коммуникация

В рамках проекта Clarity будет издана книга по методу ARCADIA. Вводный документ в настоящее время доступен для загрузки на веб-сайте Capella.[2]

Метод ARCADIA был представлен на различных мероприятиях:

КонференцияЗаголовокДатаМесто
МОДЕЛИ'16Коротко об ARCADIA[3]02/10/2016Сен-Мало
Международный симпозиум INCOSEВнедрение программы MBSE Cultural Change: организация, коучинг и извлеченные уроки[4]14/07/2015Сиэтл
Международный симпозиум INCOSEОт первоначальных исследований до крупномасштабного внедрения метода MBSE и его вспомогательной рабочей среды: опыт Thales[5]14/07/2015Сиэтл
EclipseCon ФранцияСистемное моделирование с помощью метода ARCADIA и инструмента Capella[6]24/06/2015Тулуза
Симпозиум по модельно-ориентированной системной инженерии (MBSE)Проблемы развертывания решений MBSE[7]28/10/2014Канберра
Симпозиум по модельно-ориентированной системной инженерии (MBSE)Аркадия и Капелла в поле[8]27/10/2014Канберра
EclipseCon ФранцияArcadia / Capella, проверенное на практике решение для моделирования системной и программной архитектуры.[9]19/06/2014Тулуза
MDD4DRES ENSTA Летняя школаОтзывы о системном проектировании - ARCADIA, модельно-ориентированный метод архитектурно-ориентированного проектирования[10]01/09/2014Aber Wrac'h
EclipseCon Северная АмерикаArcadia / Capella, проверенное на практике решение для моделирования системной и программной архитектуры.[11]20/03/2015Сан-Франциско
Комплексное проектирование и управление системами (CSDM)ARCADIA: совместная работа на основе моделей для системной, программной и аппаратной инженерии[12]04/12/2013Париж
Программы и комплексы программ Congrès IngénierieLa Modélisation chez Thales: мажорная поддержка в сотрудничестве с актерами и языковым искусством больших систем[13]10/06/2013Аркашон
МАЧТАНа пути к интегрированному многоуровневому проектированию - передовые практики Thales и DCNS[14]04/06/2013Гданьск
CSDMЯзыки моделирования для функционального анализа подвергаются испытанию в реальной жизни[15]2012Париж
ICASМетоды и инструменты для защиты и поддержки совместной архитектуры ограниченных систем[16]2010Отлично
CSDMПостроение управляемой моделями архитектуры для систем с ограничениями[17]2010Париж
INCOSE; 08 СимпозиумМетоды и инструменты для проектирования систем с ограничениями[18]2008Утрехт

Смотрите также

Рекомендации

  1. ^ "Norme PR XP Z67-140 | Norm'Info". norminfo.afnor.org (На французском). Получено 2018-02-01.
  2. ^ «Вводный документ ARCADIA». Получено 2015-10-23.
  3. ^ «Коротко об ARCADIA». Получено 2016-10-06.
  4. ^ «Внедрение программы MBSE Cultural Change: организация, обучение и извлеченные уроки». Архивировано из оригинал на 2016-03-03. Получено 2015-10-23.
  5. ^ «От первоначальных исследований до крупномасштабного внедрения метода MBSE и его вспомогательных средств: опыт Thales». Архивировано из оригинал на 2016-03-03. Получено 2015-10-23.
  6. ^ «Системное моделирование с помощью метода ARCADIA и инструмента Capella». Архивировано из оригинал на 2015-09-14. Получено 2015-10-23.
  7. ^ «Проблемы развертывания решений MBSE». Получено 2015-10-23.
  8. ^ «Аркадия и Капелла в поле». Получено 2015-10-23.
  9. ^ «Arcadia / Capella, проверенное на практике решение для моделирования архитектуры систем и программного обеспечения». Архивировано из оригинал на 2015-10-21. Получено 2015-10-23.
  10. ^ «Отзывы о системном проектировании - ARCADIA». Получено 2015-10-22.
  11. ^ «Arcadia / Capella, проверенное на практике решение для моделирования системной и программной архитектуры». Архивировано из оригинал на 2016-03-03. Получено 2015-10-23.
  12. ^ «Модельно-ориентированное сотрудничество для системной, программной и аппаратной инженерии». Получено 2015-10-23.
  13. ^ "La Modélisation chez Thales: un support majeur à la сотрудничество де актеров в l'ingénierie des grands systèmes" (PDF). Архивировано из оригинал (PDF) на 2016-03-03. Получено 2015-10-23.
  14. ^ «На пути к интегрированному многоуровневому проектированию - передовые практики Thales и DCNS». Получено 2015-10-23.
  15. ^ Voirin, Жан-Люк (2013). «Языки моделирования для функционального анализа на практике». Проектирование сложных систем и управление ими. С. 139–150. Дои:10.1007/978-3-642-34404-6_9. ISBN  978-3-642-34403-9.
  16. ^ «Методы и инструменты для защиты и поддержки совместной архитектуры ограниченных систем». Получено 2015-10-23.
  17. ^ «Построение управляемой моделями архитектуры для систем с ограничениями». Архивировано из оригинал на 2016-03-03. Получено 2015-10-23.
  18. ^ Voirin, Жан-Люк (2008). «Метод и инструменты для проектирования систем с ограничениями». Международный симпозиум INCOSE. 18: 981–995. Дои:10.1002 / j.2334-5837.2008.tb00857.x.

внешняя ссылка