В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения )
|
ARCADIA ( интегрированный подход анализа и проектирования архитектуры ) — это метод проектирования систем и архитектуры программного обеспечения, основанный на архитектурно-центрических и модельно - управляемых инженерных действиях .
В цикле разработки системы прежние практики больше фокусировались на определении требований , их распределении по каждому компоненту системного компонента и связанной с этим прослеживаемости. Текущие подходы скорее фокусируются на функциональном анализе , проектировании системы , обосновании архитектурных выборов и этапах проверки. Кроме того, проектирование учитывает не только функциональную точку зрения, но и другие точки зрения, которые влияют на определение и разбивку системы. Например, ограничения, связанные с системной интеграцией, управлением линейкой продуктов , безопасностью , производительностью и осуществимостью . Таким образом, системная инженерия — это не только управление системными требованиями, но и сложная проектная деятельность.
В ответ на этот вызов в 2007 году компания Thales создала метод ARCADIA , поместив архитектуру и совместную работу в центр практики системной инженерии.
Целью ARCADIA было разрушить «стены» между различными инженерными специализациями, включая архитекторов , команды разработчиков, специалистов, команды IVVQ (интеграция, верификация, валидация и квалификация), клиентов и внешних партнеров.
Метод ARCADIA скоро будет стандартизирован в качестве экспериментальной нормы AFNOR . [1] Он был опубликован 7 марта 2018 года.
Метод ARCADIA применяется к проектированию сложных и критических систем и, в более общем плане, архитектур, которые подвержены многочисленным функциональным и нефункциональным ограничениям , включая программное обеспечение, электронные, электрические архитектуры и промышленные процессы. Он определяет набор практик, которые направляют анализ потребностей и проектирование для удовлетворения эксплуатационных требований. В то же время он адаптируется к процессам и ограничениям, связанным с различными типами жизненных циклов, такими как подход снизу вверх , повторное использование приложений, инкрементальная, итеративная и частичная разработка.
ARCADIA — это структурированный инженерный метод для определения и проверки архитектуры сложных систем. Он способствует совместной работе всех заинтересованных сторон на многих этапах проектирования системы. Он допускает итерации на этапе определения, которые помогают архитекторам сблизиться в направлении удовлетворения всех выявленных потребностей.
Даже если текстовые требования сохраняются как поддержка для части захвата потребностей клиента, ARCADIA отдает предпочтение функциональному анализу как основному способу формализации потребности и поведения решения. Это включает операционные, функциональные и нефункциональные аспекты, а также результирующее определение архитектуры, основанное на – и оправданное – этом функциональном анализе.
ARCADIA основана на следующих общих принципах:
Метод ARCADIA реализуется через Capella , инструмент моделирования, который соответствует ограничениям полномасштабного развертывания в эксплуатационном контексте. Capella доступна бесплатно в инженерном сообществе с открытым исходным кодом.
Метод АРКАДИЯ:
Одна из трудностей, часто встречающихся при разработке сложных систем, возникает из-за наложения нескольких частично независимых функциональных цепочек, использующих общие ресурсы (включая, но не ограничиваясь вычислительными ресурсами). Метод ARCADIA и базовые инструменты используются для идентификации функциональных цепочек, их перекрывающихся сценариев и желаемой производительности, а также их поддержки архитектурой. Начиная с первого уровня системного анализа, они обеспечивают прослеживаемость на протяжении всего определения процесса и проверяют каждый предложенный архитектурный проект на предмет ожидаемой производительности и ограничений.
Нефункциональные свойства, ожидаемые от системного решения, также формализуются в «точках зрения». Каждая точка зрения фиксирует ограничения, с которыми система должна столкнуться или которые ей следует выполнить (опасные события, угрозы безопасности, ожидания задержки, ограничения линейки продуктов или повторного использования, вопросы энергопотребления или стоимости и т. д.). Затем модель архитектуры автоматически анализируется для проверки того, что она соответствует этим ограничениям, благодаря выделенным экспертным правилам (вычисление производительности, потребление ресурсов, безопасность или барьеры безопасности и т. д.). Этот анализ можно выполнить на самом раннем этапе цикла разработки, обнаруживая проблемы проектирования как можно скорее («ранняя проверка»).
Подводя итог, можно сказать, что подход к характеристике с помощью представлений (или «точек зрения») позволяет перепроверить, способна ли предлагаемая архитектура обеспечить требуемые функции с желаемым уровнем производительности, безопасности, надежности, массы, масштабируемости, среды, интерфейсов и т. д., обеспечивая согласованность инженерных решений, поскольку все заинтересованные стороны в области проектирования используют одну и ту же инженерную информацию и могут применять к ней свои собственные представления и проверки, чтобы обеспечить общее определение.
Ниже описаны представления первого уровня, используемые для разработки и распространения модели архитектуры:
Первый шаг фокусируется на анализе потребностей и целей заказчика, ожидаемых миссий и действий, выходящих далеко за рамки требований Системы/ПО. Ожидается, что это обеспечит хорошую адекватность определения Системы/ПО в отношении его реального операционного использования – и определит условия IVVQ. Выходы этого шага состоят в основном из «операционной архитектуры», описывающей и структурирующей эту потребность с точки зрения действующих лиц/пользователей, их операционных возможностей и действий, сценариев операционного использования, дающих параметры измерения, операционные ограничения, включая безопасность, надежность, жизненный цикл и т. д.
Второй шаг теперь фокусируется на самой системе/ПО, чтобы определить, как она может удовлетворить бывшую операционную потребность, а также на ее ожидаемом поведении и качествах: поддерживаемые функции системы/ПО и связанные с ними обмены, нефункциональные ограничения (безопасность, защита...), производительность, выделенная для границ системы, распределение ролей и взаимодействие между системой и операторами. Он также проверяет осуществимость (включая стоимость, график и готовность технологий) требований заказчика и при необходимости предоставляет средства для повторного согласования их содержания. Для этого на основе функциональной потребности системы/ПО набрасывается первая ранняя архитектура системы/ПО (модель архитектурного проектирования); затем требования проверяются на соответствие этой архитектуре, чтобы оценить их стоимость и согласованность. Выходные данные этого шага в основном состоят из описания функциональной потребности системы/ПО, взаимодействия и взаимодействия с пользователями и внешними системами (функции, обмены плюс нефункциональные ограничения), а также требований системы/ПО.
Обратите внимание, что эти два шага, составляющие первую часть архитектурного построения, «определяют» дальнейший дизайн и, следовательно, должны быть одобрены/утверждены заказчиком.
Третий шаг направлен на определение частей системы/ПО (далее называемых компонентами), их содержимого, взаимосвязей и свойств, за исключением вопросов реализации или технических/технологических проблем. Это составляет логическую архитектуру системы/ПО. Для того чтобы эта разбивка на компоненты была стабильной на дальнейших шагах, все основные [нефункциональные] ограничения (безопасность, защита, производительность, IVV, стоимость, нетехнические и т. д.) принимаются во внимание и сравниваются друг с другом, чтобы найти наилучший компромисс между ними. Этот метод описывается как «управляемый точками зрения», точки зрения являются формализацией того, как эти ограничения влияют на архитектуру системы/ПО. Выходы этого шага состоят из выбранной логической архитектуры: определение компонентов и интерфейсов, включая формализацию всех точек зрения и способ, которым они учитываются при проектировании компонентов. Поскольку архитектура должна быть проверена на соответствие Потребности, также создаются связи с требованиями и эксплуатационными сценариями.
Четвертый шаг имеет те же намерения, что и логическое построение архитектуры, за исключением того, что он определяет «окончательную» архитектуру системы/ПО на этом уровне проектирования, готовую к разработке (более низкими уровнями проектирования). Поэтому он вводит рационализацию, архитектурные шаблоны, новые технические сервисы и компоненты и заставляет логическую архитектуру развиваться в соответствии с реализацией, техническими и технологическими ограничениями и выборами (на этом уровне проектирования). Обратите внимание, что тот же метод «на основе точек зрения», что и для логического построения архитектуры, используется для определения физической архитектуры. Выходы этого шага состоят из выбранной физической архитектуры: компонентов, которые должны быть созданы, включая формализацию всех точек зрения и способ, которым они учитываются при проектировании компонентов. Также создаются связи с требованиями и эксплуатационными сценариями.
Пятый и последний шаг — это вклад в построение EPBS (структуры разбиения конечного продукта), использующий преимущества предыдущей архитектурной работы, для обеспечения определения требований к компонентам и подготовки защищенного IVVQ. Все варианты, связанные с выбранной архитектурой системы/ПО, а также все гипотезы и ограничения, наложенные на компоненты и архитектуру для соответствия потребностям и ограничениям, суммируются и проверяются здесь. Выходы этого шага в основном представляют собой «контракт на интеграцию компонентов», в котором собраны все необходимые ожидаемые свойства для каждого компонента, который должен быть разработан.
На следующем рисунке показан общий вид, обобщающий рекомендуемый технический процесс, включающий три элемента инженерного триптиха и их производственные действия на протяжении всего процесса определения и проектирования.
В рамках проекта Clarity будет опубликована книга о методе ARCADIA. Вводный документ в настоящее время доступен для скачивания на сайте Capella. [2]
Метод ARCADIA был представлен на различных мероприятиях:
Конференция | Заголовок | Дата | Место |
---|---|---|---|
МОДЕЛИ'16 | АРКАДИЯ в двух словах [3] | 02/10/2016 | Сен-Мало |
Международный симпозиум INCOSE | Внедрение культурных изменений MBSE: организация, коучинг и извлеченные уроки [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/2014 | Абер Врак'х |
EclipseCon Северная Америка | Arcadia / Capella, проверенное на практике решение для моделирования системной и программной архитектуры [11] | 20/03/2015 | Сан-Франциско |
Проектирование и управление сложными системами (CSDM) | ARCADIA: основанное на моделях сотрудничество для системной, программной и аппаратной инженерии [12] | 04/12/2013 | Париж |
Большие программы и комплексы систем Congrès Ingénierie | La modélisation chez Thales: un support majeur à laсотрудничество актеров и инженеров больших систем [13] | 10/06/2013 | Аркашон |
МАСТ | На пути к интегрированной многоуровневой инженерии – передовые практики Thales и DCNS [14] | 04/06/2013 | Гданьск |
CSDM | Языки моделирования для функционального анализа подвергаются испытанию в реальной жизни [15] | 2012 | Париж |
ИКАС | Метод и инструменты для обеспечения и поддержки совместной разработки архитектуры ограниченных систем [16] | 2010 | Хороший |
CSDM | Создание архитектуры на основе моделей для систем с ограничениями [17] | 2010 | Париж |
INCOSE;08 Симпозиум | Метод и инструменты для проектирования систем с ограничениями [18] | 2008 | Утрехт |