Разделите проект, когда это станет слишком комплексным для одного человека, чтобы знать все детали. Сложность увеличивается с размером проекта и размером команды, например,
Размер проекта и сложность:
Тысячи блоков
Сотни логических решений
Сотни вводов и выводов
Промышленные примеры, в некоторых случаях в сотни раз большие
Множество различных настроек той же функциональности
Интегрирование команды:
Несколько человек, работающих над проектом
Люди расположенные в различных местах
Люди из различных компаний
Разделение вашего проекта на компоненты помогает вам работать с крупномасштабными проектами. Разделение проекта на компоненты позволяет применять модульный принцип, чтобы помочь вам уменьшать сложность, сотрудничать при разработке, тесте и компонентах повторного использования, и успешно справиться с крупномасштабным модельно-ориентированным проектированием. Компонентно-ориентированное моделирование помогает:
Включите эффективную и устойчивую разработку системы.
Уменьшайте сложность общего замысла путем решения меньших проблем.
Получите выигрыши в производительности та шкала.
Компоненты повторного использования через несколько проектов.
Упростите сотрудничество
Алгоритмы раздела, физические модели и тесты. Задайте архитектуру с точки зрения структурного и функционального разбиения проекта с помощью заданных интерфейсов.
Сотрудничайте с командами через организационные контуры на разработке нового продукта. Команды могут разработать отдельные компоненты независимо, чтобы сделать моделирование объекта, проект алгоритма и разработку тестовых обвязок.
Управляйте проектом с инструментами системы контроля версий.
Улучшенная итерация, разработка и рабочие процессы верификации
Выполните итерации быстрее через более эффективное тестирование и повторное использование.
Устраните перетестирование на неизменные компоненты.
Модели среды повторного использования и алгоритм разрабатывают в различных проектах.
Создайте варианты проектов.
Тщательно продуманные компоненты независимо через четко определенные интерфейсы.
Справьтесь с эволюцией проекта с инструментами управления конфигурацией.
Компонентно-ориентированное моделирование требует:
Механизмы для разделения моделей и определения интерфейсов
Инструменты и процессы для данных об управлении, моделей и среды
Используйте следующие методы для компонентно-ориентированного моделирования.
Компонентизация предоставляет преимущества для крупномасштабных проектов, но не нужна для маленьких проектов. Разделение вашего проекта на компоненты требует дизайнерской работы и может увеличить время, потраченное, чтобы обновить схемы. Используйте отдельные компоненты только, когда ваш проект будет достаточно большим, чтобы извлечь выгоду из компонентизации.
Чтобы решить, нужно ли для вашего проекта разделение, см. рекомендации в Инструкциях для Размера Компонента и Функциональности.
После того, как модели становятся большими и объединяют в зависимости от времени, трудно разделить их на компоненты, чтобы позволить нескольким инженерам работать над ними параллельно. Разделение модели Simulink® на компоненты легче, если модель разработана для компонентизации от запуска. Разработка для компонентизации во-первых может помочь вам избежать этих трудностей:
Если один инженер разрабатывает модель с самого начала, добавляя блоки и группируя их в подсистемы, когда сложность модели увеличивается, трудно позже разделить модель на компоненты. Подсистемы в модели являются часто “виртуальными” и неатомарными. Когда вы преобразовываете их в атомарные подсистемы и затем в компоненты модели - ссылки, можно ввести нежелательные алгебраические циклы, которые трудно диагностировать и решить.
Подсистемы, выращиваемые в зависимости от времени, не всегда представляют лучший способ разделить модель. “Лучше всего” здесь может означать самую полезную структуру для допускающих повторное использование компонентов в других моделях, или для генерации кода, который объединяется с устаревшей функциональностью, или для выполнения Оборудования в тестах цикла, и т.д.
При попытке расшириться, чтобы быть параллельными разработке, не разбивая на компоненты модели, трудно совместно использовать, работают в командах без длительного и подверженного ошибкам слияния подсистем.
Эти проблемы походят на взятие большой части кода (C, Java или код MATLAB®) и попытка разломать его на много отдельных функций. Значительное усилие требуется и может потребовать обширных модификаций к некоторым частям кода, если код не был разработан, чтобы быть модульным во-первых. То же самое верно для моделей Simulink.
Отсутствие компонентизации вызывает общие типы отказа при попытке поместить модели Simulink в управление конфигурацией, когда они растут, и вы хотите, чтобы больше чем один инженер работал над ним параллельно. Лучший способ избежать этих проблем состоит в том, чтобы разработать для компонентов от запуска. Можно использовать следующие функции Simulink, чтобы разработать модель, подходящую для компонентизации.
Если у вас уже есть проект, который вы хотите разделить на компоненты, видеть Раздел Существующий Проект.
Чтобы настроить ваш проект для команды продолжить работать, рассмотрите следующие инструкции по архитектуре модели для компонентов. Полезные компоненты:
Имейте четко определенные контуры интерфейса I/O.
Выполните заданный набор функций (действия), заданные требованиями.
Явитесь частью большей системы.
Имейте “правильный” размер:
Достаточно большой, чтобы быть допускающим повторное использование
Достаточно маленький, чтобы быть протестированным
Только один инженер, вероятно, захочет отредактировать каждую модель за один раз
Правильный размер может зависеть от размера команды. У вас могут быть большие компоненты, если только один человек работает над каждым, но если необходимо совместно использовать компоненты между несколькими людьми, вероятно, необходимо разделить проект на меньшие логические части. Это помогает двум голам: понимание проекта и сокращение конкуренции файла и время потрачены на слияние.
Рекомендации:
В большинстве случаев, если у вас есть меньше чем 100 блоков, не делите проект на компоненты. Вместо этого используйте подсистемы, если вы хотите создать визуальную иерархию. Например, модель vdp в качестве примера не является достаточно большой, чтобы извлечь выгоду из компонентизации.
Если вы имеете 500–1000 блоков, полагаете, что создание модели - ссылки содержит тот компонент в отдельном файле. Стоимость верификации может уменьшать размер для компонентов. Например, если вы имеете маленький компонент 100 блоков с высокими затратами на тестирование и частыми изменениями, полагаете, что распадение что компонент в отдельный файл делает верификацию легче.
Рассмотрите деление основанного на модели на:
Физические компоненты (например, объект и контроллер, для генерации кода)
Логика алгоритма
Возможность многократного использования в других моделях
Тестируемость, например, для выполнения Оборудования в тестах цикла
Частота дискретизации; рассмотрите группирующиеся компоненты, которые имеют ту же частоту дискретизации
Скорость симуляции; использование других решателей для компонентов с различными числовыми свойствами может увеличить скорость симуляции
Доступность другим командам или другим в вашей команде.
В то время как вы не можете всегда планировать размер модели, если вы ожидаете, что несколько человек будут работать над проектом, можно извлечь выгоду из методов компонентизации. Рассмотрите управление конфигурацией управления с помощью проекта и деля проект с помощью Модели - ссылки так, чтобы команда могла работать над отдельными файлами одновременно.
| Размер компонента | Рекомендуемые методы компонентизации | Примечания |
|---|---|---|
Маленький <500 блоков | Создайте визуальную иерархию с помощью подсистем. | Маленькие проекты не извлекают выгоду из деления на отдельные файлы. Однако более многочисленные команды, которые вызывают конкуренцию файла или высокую стоимость верификации, могут сделать его стоящим делящих меньших компонентов в отдельные файлы вместо того, чтобы использовать подсистемы. |
| Большой> 500 блоков | Разделите компоненты на отдельные файлы с помощью Модели - ссылки или Библиотек. | Для нескольких инженеров или команд, работающих над проектом, лучшой практикой является один файл на компонент. Чтобы уменьшать конкуренцию файла, стремитесь к компонентам, в которых только один инженер должен отредактировать каждую модель за один раз. |
Маленький <500 блоков, но ожидаемый расти в зависимости от времени | Используйте атомарные подсистемы для функционального блока, группирующегося вместо виртуальных подсистем. Атомарные подсистемы легче переместить, чтобы разделить компоненты файла позже. | Если возможно, план ваши компоненты от запуска, чтобы избежать боли миграции. |
Если ваш проект или команда являются достаточно большими, чтобы извлечь выгоду из распадающихся компонентов в отдельные файлы, эта таблица суммирует, когда применить каждый метод.
| Характеристики компонента | Метод | Преимущества | Затраты |
|---|---|---|---|
| Маленькие, низкоуровневые служебные функции, снова использованные во многих местах в проекте | Модель Library, содержащая одну допускающую повторное использование атомарную подсистему |
|
|
| Группы блоков для совместного использования среди пользователей | Библиотека для группировки и хранения блоков Simulink Библиотека palette ссылок на компоненты |
|
|
Компоненты верхнего уровня для крупномасштабных моделей:> 500 блоков Большие компоненты: запуск в ~ 500–5000 блоков для один или несколько допускающих повторное использование экземпляров, или меньший, если много экземпляров Компоненты на любом уровне иерархии модели, где команды должны работать независимо | Образцовая ссылка |
| Производительность может уменьшать немного при обновлении модели (схема обновления), потому что каждая эталонная модель проверяется на изменения, чтобы включить инкрементные сборки. То, когда компоненты являются достаточно большими (> 500 блоков), обновляют схему, быстрее в большинстве случаев. Смотрите раздел проект Используя модель - ссылку. |
Чтобы выполнить параллельную разработку, вам нужно компонентно-ориентированное моделирование. Лучшая практика для успешной основанной на команде разработки состоит в том, чтобы разделить модели в рамках проекта так, чтобы только один пользователь работал над каждой частью за один раз. Компонентизация позволяет вам избежать или минимизировать длительное слияние. Чтобы настроить ваш проект для работы команды, рассмотрите следующие инструкции по архитектуре модели.
Эта таблица сравнивает подсистемы, библиотеки и ссылку модели для основанной на команде разработки.
| Моделирование процесса разработки | Подсистемы | Библиотеки | Образцовая ссылка |
|---|---|---|---|
Основанная на команде разработка | Не поддерживаемый Для подсистем в модели Simulink не обеспечивает прямого интерфейса с инструментами системы контроля версий. Чтобы создать или изменить подсистему, необходимо открыть файл родительской модели. Это может привести к конкуренции файла, когда несколько человек хотят работать над несколькими подсистемами в модели. Слияние подсистем является медленным и подверженным ошибкам, так же лучше всего избегаемое как процесс рабочего процесса. Однако Simulink обеспечивает инструменты, чтобы помочь вам объединить подсистемы. Смотрите Слияние Модели Simulink из Отчета Сравнения. | Поддерживаемый, с ограничениями Можно поместить файлы библиотеки в систему контроля версий для системы контроля версий и управления конфигурацией. Можно использовать проект взаимодействовать с системой контроля версий. Можно поддержать одну истину путем распространения изменений от одного блока библиотеки до всех блоков, которые соединяются с той библиотекой. Чтобы уменьшать конкуренцию файла, используйте одну подсистему на библиотеку. Можно соединиться с тем же блоком библиотеки от многоуровневых моделей. Можно ограничить доступ для записи к компонентам библиотеки. | Хорошо удовлетворенный Можно поместить файлы модели - ссылки в систему контроля версий для системы контроля версий и управления конфигурацией. Можно использовать проект взаимодействовать с системой контроля версий. Вы сохраняете модель, на которую ссылаются, в отдельном файле из модели, которая ссылается на него. Используя отдельные файлы помогает избежать конкуренции файла. Можно разработать, создать, моделировать и протестировать модель, на которую ссылаются, независимо из модели, которая ссылается на нее. Simulink не ограничивает доступ для изменения модели - ссылки. |
Большинство больших моделей использует комбинацию методов компонентизации. Никакой единый подход не подходит для широкого спектра пользователей Simulink. Следующий совет описывает некоторые типичные процессы, чтобы показать то, что можно сделать с инструментами MathWorks®, чтобы выполнить основанную на команде разработку.
Чтобы выполнить эффективную параллельную разработку, повредите большую модель во многие отдельные файлы, так, чтобы члены команды могли работать независимо, и можно поместить каждый файл при управлении версиями. Компонентизация позволяет вам избежать или минимизировать длительное слияние. Чтобы настроить ваш проект для работы команды, рассмотрите совет в Инструкциях для Размера Компонента и Функциональности.
Основная цель компонентно-ориентированного моделирования состоит в том, чтобы позволить параллельную разработку, где различные инженеры могут работать над компонентами большей системы параллельно. Можно достигнуть этого, если каждый компонент является одним файлом. Можно затем управлять и проследить изменения в каждой системе контроля версий проекта использования компонента. Смотрите управление конфигурацией.
Если у вас уже есть проект, который вы хотите разделить на компоненты, сначала решить, где разделить модель. Существующие подсистемы, которые растут в зависимости от времени, являются не всегда лучшим способом разделить модель. Рассмотрите деление основанного на модели на совете в Инструкциях для Размера Компонента и Функциональности.
Достижение соглашения об интерфейсе является полезным первым шагом в решении, как сломать функциональность большой системы в субкомпоненты. Можно сгруппировать данные о разделе и сигналы. Смотрите Дизайн интерфейса.
После того, как вы решаете, как разделить ваш проект, инструменты Simulink могут помочь вам разделить существующую модель на компоненты.
Simulink может помочь вам модели раздела путем преобразования подсистем в файлы. Можно преобразовать в файлы с помощью Модели - ссылки или Библиотек. См. Инструкции для Размера Компонента и Функциональность для предложений на том, когда применить каждый метод.
Используйте Модель - ссылку, чтобы разделить компоненты на отдельные файлы так, чтобы команда могла работать над отдельными файлами одновременно. Можно также снова использовать модели в других моделях. Чтобы разделить модель с помощью модели - ссылки, см. Ссылочные Существующие Модели или Преобразуйте Подсистемы в Модели, на которые Ссылаются.
Пользуйтесь Библиотеками, содержащими одну подсистему, чтобы содержать компонент в одном файле. Пользуйтесь библиотеками, чтобы сохранить блоки, которые можно снова использовать в моделях. Соединенные блоки наследовали атрибуты от окружающих моделей, таких как типы данных и частота дискретизации. Используя этот метод для компонентизации имеет управление наверху ссылками библиотеки, описанными ниже.
Пользуйтесь Библиотеками, чтобы снова использовать блоки в многоуровневых моделях. Библиотеки работают хорошо на группировку и хранение блоков Simulink, чтобы совместно использовать. Лучшая практика для библиотек состоит в том, чтобы использовать их для хранения блоков, чтобы совместно использовать со многим пользователем и блоками, которые нечасто обновляются. Как грубая инструкция, уместно использовать Библиотеку Simulink, если ее содержимое обновляется один раз в несколько месяцев. Если вы обновляете его более часто, то библиотекой, вероятно, пользуются, чтобы выполнить управление конфигурацией. В этом случае заботьтесь, чтобы избежать типичных проблем, описанных в управлении Ссылкой Библиотеки.
Чтобы сделать блоки библиотеки доступными для повторного использования при сокращении конкуренции файла и применении управления версиями, используйте палитры библиотеки. Палитра является библиотекой, содержащей ссылки на другие компоненты. Если каждый компонент является одной подсистемой в отдельной библиотеке или файлом модели - ссылки, можно достигнуть одного файла на лучшую практику компонента для компонентно-ориентированного моделирования. Можно использовать управление отдельной версией для каждого компонента, и можно также управлять палитрой.
Когда вы перетаскиваете блок от палитры библиотеки в вашу модель, Simulink переходит по ссылке назад на файл, где подсистема или модель - ссылка реализованы. Модели, которые используют компонент, содержат ссылку на компонент а не на палитру.
Ссылки библиотеки могут ввести управление наверху, если вы используете их для управления конфигурацией. Всего хорошего, чтобы справиться:
Отключенные ссылки — Могут вызвать конфликты слияния и отказ обновить все экземпляры того же компонента модели. В иерархии ссылок можно случайно отключить все ссылки, не будучи знающими об этом, и только восстановить одну ссылку, в то время как отъезд других отключил.
Неработающие ссылки — Случайно неработающие ссылки являются тяжелой проблемой решить, потому что проектом вы не можете обнаружить что неработающая ссылка, соединенная с ранее.
Параметризованные данные о ссылке — может быть полезно изменить значение данных о параметре, таких как значение усиления в блоке усиления, не отключая ссылку библиотеки. Это генерирует “данные о ссылке” для того экземпляра только. Однако для управления конфигурацией это может вызвать проблему, если вы принимаете, что все экземпляры идентичны, когда у каждого теперь есть различные свойства.
Инструменты Simulink помогают вам управлять ссылками библиотеки, чтобы избежать проблем:
Заблокируйте ссылки, чтобы предотвратить редактирование. Смотрите Ссылки Блокировки на Блоки в Библиотеке.
Используйте диагностические опции, чтобы проверять целостность ссылки библиотеки каждый раз, когда вы сохраняете модель. Можно установить проверки предупреждать, ошибка, или игнорировать, что модель отключила или параметризовала ссылки библиотеки. Вы выбираете эти настройки на модель. В диалоговом окне Configuration Parameters смотрите Diagnostics> Saving.
Смотрите, что диагностическая Блок-схема настроек содержит отключенные ссылки библиотеки, и Блок-схема содержит параметризованные ссылки библиотеки.
Используйте проверки Model Advisor, чтобы сообщить относительно целостности ссылки библиотеки. Советник проверяет на отключенные и параметризованные ссылки в модели. Можно использовать получившийся отчет в качестве артефакта, чтобы зарегистрироваться в системе управления конфигурацией.
Смотрите проверки Model Advisor:
Используйте Инструмент ссылок, чтобы просмотреть и восстановить отключенные и отредактированные ссылки. Смотрите Восстановление Отключенные или Параметризованные Ссылки.
Эти инструменты управления ссылки могут обнаружить проблемы ссылки, но не могут предотвратить редактирование неправильных файлов. Если это - проблема, то используйте Модель - ссылку в качестве механизма разделения, чтобы избежать рисков, сопоставленных с отключенными, разорванными, и параметризованными связями.