Аркадия (инженерное дело)

В этой статье есть несколько проблем. Помогите улучшить ее или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалять эти сообщения ) Данная статья содержит рекламный контент .Пожалуйста, помогите улучшить его, удалив рекламный язык и неуместные внешние ссылки , а также добавив энциклопедический текст, написанный с нейтральной точки зрения . ( март 2019 г. )( Узнайте, как и когда удалить это сообщение ) Эта статья может оказаться слишком сложной для понимания большинством читателей .Пожалуйста, помогите улучшить его, чтобы сделать его понятным для неспециалистов , не удаляя технические детали. ( март 2019 г. )( Узнайте, как и когда удалить это сообщение ) ( Узнайте, как и когда удалить это сообщение )

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

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

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

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

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

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

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

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

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

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

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

Метод АРКАДИЯ:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Метамоделирование
• Проектирование на основе моделей

Найдите слово arcadia (инженерное дело) в Викисловаре, бесплатном словаре.

• Веб-страница, посвященная методу
• Официальный форум
• Фалес, основатель метода