Очевидно, что моделирование в нашем UML2 контексте будет
Детерминированное, Статическое или Динамическое, Дискретное (дискретно-непрерывное), Мысленное(Символическое и Математическое)

1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).
2. А существует ли альтернатива UML? Для моделирования, например игрового сервера, бизнес процессов и включающая в себя математическое моделирование. Потому что, возвращаясь к теме конференции - что-то UML мне не "ICE" особенно не нравится большая привязанность UML к ООП. И вообще стоит ли искать альтернативу или продолжать изучение UML? потому как лучшего на сегодняшний день не существует.

И вообще стоит ли искать альтернативу или продолжать изучение UML?

Смотря для чего?

1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).

Давно уже это писалось. И почему написалось именно так, не помню.
Тем не менее не вижу проблемы.

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

Смотря для чего?

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

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

Если игровой сервер - это программная система или комплекс программных систем, то UML вполне подходит, поскольку он впитал в себя многие нотации и методы описания взаимодействия, структуры и поведения программных компонентов

1. Не совсем понятно как связаны UML и математическое моделирование? (приведите пожалуйста пример).
2. А существует ли альтернатива UML? Для моделирования, например игрового сервера, бизнес процессов и включающая в себя математическое моделирование. Потому что, возвращаясь к теме конференции - что-то UML мне не "ICE" особенно не нравится большая привязанность UML к ООП. И вообще стоит ли искать альтернативу или продолжать изучение UML? потому как лучшего на сегодняшний день не существует.

Сначала ставится задача, потом выполняется проектирование.
Чем проектировать - сугубо личное дело. Можно карандашом на бумажке нарисовать. Относитесь к этому проще, UML это лишь один из множества способов представления ваших концепций и возможных решений. Вас никто не ограничивает в использовании любых других инструментов или придумывании своих - которые будут удобны лично вам (если не стоит задача промышленной разработки).
Поэтому вопросы "а существует ли альтернатива.. для.." бессмысленны - любой инструмент хорош только на своем месте и тогда, когда умеешь им пользоваться.

1. Выбор модели оказывает определяющее влияние на подход к решению проблемы и на то, как будет выглядеть это решение.

Ну а как? Ты же не по самой предметной области будешь систему делать. Раз ты пользуешься моделью, то она тебе и заменяет саму задачу, а если нет, то ты её не используешь, так как модель по своему определению есть заменяющий объект, значит выбор модели определяет представление задачи, ну а представление задачи определяет подход к её решению. Это всё равно как выбор языка оказывает определяющее влияние на набор используемых при общении слов. А как иначе? Нельзя говорить по-русски английскими словами. Нельзя решать задачу математическими методами, выбрав в качестве модели макет, если только перед непосредственно решением не построить математическую модель уже макета (модель модели, видимо метамодель). Нельзя, выбрав модель в приращениях, принимать решения об управляющих воздействиях на печь в полных уровнях и наоборот.

2. Каждая модель может быть представлена с различной степенью точности.

И как же интересно можно зафиксировать уровень детализации?

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

Больше свойств воспроизведёшь - модель точнее, меньшее - наоборот. Те же свойства адекватнее воспроизведёшь - модель точнее, загрубишь - наоборот. Но модель то в любом случае можно менять, при этом меняются, добавляются, или убираются свойства.

3. Лучшие модели - те, что ближе к реальности.

А как ещё? Вот представь: делаешь ты текстовый редактор с поддержкой иврита, а твоя модель не учитывает, что евреи пишут с права налево. Не годна твоя модель и редактор будет без поддержки иврита, а если это единственные его язык, то вообще не получится и всё только из-за того, что модель далека от реальности. Или по-твоему лучше ничего не сделать и свалить вину на моделиста?

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

Вторая модель - это другие аспекты предметной области, которые ты мог пропустить при создании первой модели, но только в том случае, когда они не зависимы, иначе это просто две формы одной модели, возможно два уровня её детализации, но замыленный шараповский глаз (см "Место встречи изменить нельзя") так и не прочищен.

Модель должна упрощать реальность.

Упрощать, но не перевирать и в меру. Вот представь математическую модель релятивистского ускорителя (БАК, например). Если заложить ньютоновские формулы для ускоряемых частиц, то модель проще, но дальше от реальности и ускоритель вообще не сможет работать. Но кварки в бетоне стен туннеля того же ускорителя можно не моделировать.

Так и до чего договорились?
Уточняем принципы моделирования или ?

"Любое правило, любой принцип, любое условие можно и должно подвергать сомнению, поскольку они имеют ограниченную область действия..."

Как раз этот принцип  входит в морфологический подход

В 1942 г. швейцарский астрофизик Ф.Цвикки обнародовал ряд методов, которыми рекомендовалось пользоваться при решении научных и технических задач. Сначала этих методов было семь, впоследствии Цвикки остановился на трех основных, сочтя остальные либо недостаточно эффективными, либо недостаточно самостоятельными. В их числе:

1) метод отрицания и конструирования (МОК);
2) метод систематического покрытия поля (МСПП);
3) метод морфологического ящика (ММЯ).

Совокупность методов Цвикки получила название "морфологический подход".

Есть также статья Принципы моделирования систем различной природы

скажите пожалуйста,  как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?

скажите пожалуйста,  как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?

Описывать поведение кнопок в варианте использования категорические не рекомендуется. Поскольку ВИ - это требования, а требования диктуют то, ЧТО следует сделать, но не КАК.

Кнопки и их поведение вероятно следует описывать на стадии проектирования графического интерфейса, принимая во внимания стиль программной реализации, архитектурные принципы и другие требования, обычно нефункциональные.

Порция некротрединга.

скажите пожалуйста,  как лучше (правильно) описывать поведение кнопок в интерфейсе в варианте использования или в интерфейсе или дублировать?

Если вариант использования имеет область действия "система как белый ящик" или "подсистема", то можно описывать поведение кнопок в нём. Если вариант использования имеет область действия "система как чёрный ящик" (как правило, те ВИ, которыми описывают требования, имеют эту область действия), то поведение кнопок (как и других составных частей системы) в нём описывать не следует.
Те варианты использования, который писал Айвар Якобсон, когда их изобретал, были "с кнопками", к слову сказать.

Он не Айвар, а Ивар

https://forvo.com/word/ivar_jacobson/

Я не раз предупреждало, что мой ксенолингвист барахлит (как и у многих переводчиков литературы на русский). Не удивляйтесь.
Радо возможному проявлению широкого взгляда на ВИ, допускающему для него более чем одну разновидность, т. е. не только "цель пользователя".