Системы реального времени очень сложны в реализации, их работа зачастую связана с многочисленными и независимыми друг от друга потоками входных событий, и отработкой на их основе различной выходной информации. Периодичность поступления событий, в таких системах, в подавляющем большинстве случаев не может быть задана жёстко, т.к. непредсказуема по своей сути, однако реагировать на события необходимо достаточно быстро, чтобы соблюсти временные критерии-ограничения, сформулированные в требованиях к программе. Подобные проблемы можно решить, приняв периодичность поступления событий, как максимальный период поступления данных в наихудшем из вариантов развития событий. Однако следует учитывать, что нередко нельзя предугадать и порядок поступления событий. Кроме того, входная нагрузка может значительно и произвольным образом меняться во времени, представляя собой недетерминированный процесс. Таким образом, новые технологии потребовали пересмотра выработанных ранее требований, предъявляемых к программному обеспечению.
В последнее время, чётко прослеживается тенденция к сближению двух крупнейших областей разработки программного обеспечения - информационных и управляющих систем реального времени. В крупных информационных системах возникает проблема адекватности реакции программного обеспечения при обслуживании большого числа клиентов. Управляющие же системы, как правило, не только управляют каким-то специфическим оборудованием, но и работают со своеобразными базами данных. Для создания такого рода приложений, следует объединить объектно-ориентированный подход в разработке, с методами параллельной обработки.
Большинство современных систем ответственного применения, являются системами реального времени и состоят из множества объектов. Эти объекты взаимодействуют друг с другом, они распределены, и каждый из них, тем или иным способом, поддерживает свое собственное состояние, отличное от других. Во взаимодействии подобных объектов во времени чрезвычайно сложно разобраться, не говоря уже о предсказании их поведения в тот или иной отрезок времени. С такой системы нельзя снять адекватную резервную копию, ее нельзя перезапустить, если в какой-либо части обнаружится сбой. Система в целом должна работать, несмотря на произошедшие сбои, ошибки, или отказ некоторых объектов. Производительность подобных систем часто бывает нелинейной и не может быть предсказана путем простой экстраполяции.
Для решения подобных проблем, можно использовать те же методы, которые применяются инженерами в любой другой области: моделирование, предварительная проработка архитектуры, повторное использование уже отлаженных компонентов и т.д. Однако, применительно к программному обеспечению, проектирование оказывается совершенно неформальным процессом, для которого зачастую не существует моделей и методов прогнозирования требуемого результата.
Предлагается ещё на этапе проектного моделирования продумывать архитектуру будущей системы. Аналитическая модель, в которой основное внимание уделялось бы предметной области, должна соотноситься со средой, где будет эксплуатироваться программа, а в равной степени и с проектной моделью, где акцент переносится на область решения самой проблемы. Следует сформулировать критерии разбиения системы на подсистемы (объекты). Для распределенных систем, наиболее важным является разделение ответственности между их узлами, как с точки зрения централизации, так и с точки зрения распределения данных и управления. Следует также спроектировать интерфейсы для обмена сообщениями, как синхронные, так и асинхронные. И только после этого, следует приступать к проектированию отдельных подсистем.
Библиографическая ссылка
Каражелясков Р.П. ОСОБЕННОСТИ АРХИТЕКТУРЫ СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ // Современные наукоемкие технологии. – 2007. – № 9. – С. 29-30;URL: https://top-technologies.ru/ru/article/view?id=25462 (дата обращения: 03.12.2024).