Агент-ориентированный дизайн в реальном мире?


Мы изучалиагент-ориентированное программирование в моем классе разработки программного обеспечения, и мой профессор является большим сторонником этого, работая с ним всю свою жизнь.

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

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

2 7

2 ответа:

Использование термина " агенты "в ИИ (который, скорее всего, является тем, что вы имеете в виду, это наиболее распространенная академическая ссылка) на самом деле является синонимом"программы, которая действует от имени пользователя". Агент видится более привлекательным, потому что это несколько персонифицированный термин, являющийся прокси для пользователя; кроме того, он имеет тенденцию ассоциироваться с функциональностью более высокого порядка (планирование для агентов, обучение для агентов, автономные агенты и т. д.). Подробнее о происхождении термина on Википедия:

Http://en.wikipedia.org/wiki/Software_agent

Учитывая это, термин "агент" больше относится к цели и типу программного обеспечения, а не к тому, как оно программируется. ООП имеет больше общего с тем, как он технически разработан/реализован.

Так что нет ничего плохого в разработке ваших агентов с использованием принципов ООП. Эти два предмета не являются взаимоисключающими.

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

Http://ootips.org/agent-orientation.html

Чего мне не хватает во всех ответах и что я считаю наиболее важными различиями между агент / актор-ориентированным программированием и "нормальным" ООП, так это:

  • АОП - это более высокий слой или" уровень " поверх ООП (часто реализуемый с помощью ООП).

  • AOP - это все о том, чтобы упростить параллельное (многопоточное) программирование, иметь четко определенный стандартный способ его выполнения (для каждого языка или фреймворка) и тем самым сделать его более четко структурированным. Параллелизм функциональность реализована в рамках или языке AOP, в то время как многопоточность в OOP оставлена на усмотрение разработчика и может быть реализована любым способом, который ему нравится (одним из которых может быть AOP :P).

Примеры языков, которые имеют некоторую реализацию, позволяющую использовать AOP из коробки: более новые версии Ni Labview и Erlang. Вики есть примеры.

Интуитивно я бы предположил, что в целом: чем больше функциональности вы добавляете в программное обеспечение, тем больше вы будете польза от использования AOP. Если вы не используете AOP (или какой-либо другой многопоточный фреймворк), вы, вероятно, столкнетесь со всеми проблемами, которые AOP уже решил для вас, такими как: мертвые блокировки, условия гонки, неэффективное взаимодействие между потоками (очереди событий, очереди сообщений, очереди данных и т. д.).

Хороший пример (случайной) архитектуры, ориентированной на актора: интернет. Поскольку он состоит из" агентов " (узлов/серверов/клиентов), которые функционируют одновременно и могут терпеть отказы другие серверы и каналы связи.