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

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

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

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

История [ править ]

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

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

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

Нормализация [ править ]

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

Контекст [ править ]

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

Цели и средства действия [ править ]

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

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

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

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

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

Краткое описание функции [ править ]

Метод ARCADIA:

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

Методологический подход [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Связь [ править ]

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

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

См. Также [ править ]

• Метамоделирование
• Модельно-ориентированная инженерия

Ссылки [ править ]

Внешние ссылки [ править ]

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

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