2
gahcepЕсли речь идет о математических пакетах, то в основе, как правило, лежит подсистема символьной алгебры. В этом случае должна быть продумана схема представления абстрактных алгебраических выражений (например, деревья), должны быть реализованы алгоритмы манипулирования этими выражениями (подстановка, ввод/вывод), а также алгоритмы сопоставлений с образцом (например, вы можете захотеть реализовать функцию раскрытие скобок в выражении, тогда вам понадобиться распознать некоторый образец, типа
и заменить его на
, ну и т.д.). В конечном счете, как сказал
мат-ламер, должно получиться что-то вроде небольшого интерпретируемого языка программирования.
Если речь идет о пакетах моделирования, то обычно при проектировании ядра таких систем акцент делается на реализации алгоритмов численных расчетов (интегрирование/дифференцирование, длинная арифметика, численное решение уравнений), алгоритмов математической оптимизации (симплекс-метод, множители Лагранжа, и т.д.), алгоритмов аппроксимации.
Если подразумевается геометричекое моделирование (САПР, 3D-графика), то понятно, что основное внимание должны быть обращено на представление данных (сцены), должны быть реализована специфические геометрические алгоритмы (геометрическая булева алгебра, системы частиц, etc.), продуманы вопросы взаимодействия с пользователем (нестандарные устройства ввода, визуализация объектов, поддержка распространенных форматов файлов для обмена данными с другим ПО).
Понятно, что необходимо писать ядро с учетом специфики задач, которые ему предстоит решать. Например, если ваша софтина будет работать с разводкой печатных плат, то стоит копать в сторону расчета электро-цепей, укладки графов, поддержки базы стандартных компонентов (деталей); а если ваше ядро планируется использовать для физической симуляции в играх, то упор должен делаться на создание приближенной физической модели мира, дешевых алгоритмов детектирования столкновений, экономичной схемы хранений объектов.
Что касается архитектуры ядра, то возможно стоит делать его изначально модульным, кроссплатформенным, скалируемым, стоит предусмотреть возможности распараллеливания, работы на кластерах, непобрезговать аппаратной оптимизацией (e.g. обеспечить возможность заточки некоторых частей ядра на наилучшую работу с определенным оборудованием). Непомешает поддержка расширений, типа скриптов. плагинов. Хорошую переносимость можно обеспечит тщательно спроектировав и продукоментировав открытый API вашего ядра. Например, в какой-нибудь системе символьной алгебры на основе этого ядра, должно быть возможным при необходимости "научить" её, скажем, решать какие-то необычные типы интегралов, просто подключив дополнительный модуль.
А каких-то особых конкретных советов по проектированию/архитектуре здесь дать, думаю, не получится... Как это часто случается, понимание наиболее подходящей к этому проекту архитектуры появится уже при написании кода, поэтому можно только посоветовать с самого начала писать код так, чтобы в любой момент можно было бы изменить архитектуру, то есть стоит стараться минимизировть связи между модулями, использовать паттерны проектирования и пр.
Очень хотелось бы услышать от автора данной темы, что-же за система проектировалась, какие архитектурные вопросы решались (и как решались). Сам я как-то писал нечто подобное (правда в сфере документооборота, как бы это странно не звучало). Сначала я не понимал какая именно мне нужна архитектура, на какие части поделить проект, поэтому просто начал писать с самых низкоуровневых вещей, в конце концов получив конечный продукт. Но его облик не был спроетирован сначала, он определился стихийно в ходе разработки снизу-вверх. Правда проект этот так и не был внедрен, всестороннего тестирования не проводилось, и, таким образом, узкие места архитектуры себя никак не проявили. Именно поэтому мне тоже очень интересно, как лучше всего проектировать такие вот ядра, решающие математические задачки. В существующих open-source мат. пакетиках каково-то единства архитектурных решений не наблюдается (или я его просто не увидел).
