Речь идёт именно о фактах, а не о гипотезах. Хотя в данной области следовало бы применять другую терминологию. А факт
«задокументированное наблюдение»
— явление относительное и его задокументированность не гарантирует его правильное понимание. Факт можно понимать по-разному в зависимости от квалификации исследователя и от ракурса наблюдения. За примером далеко ходить не надо, достаточно посмотреть как журналисты на разных каналах освещают то или иное событие, которое по сути является фактом.
Никто не отрицает наличия и необходимость методов научных исследований. Они и составляют основу для этих исследований. Сомнению подверглась идея использования подобных методов в ситуации, когда факты разбросаны в сети интернет, и исследователю достаточно знать о их наличии и иметь сиюминутный доступ к ним. При таком подходе эффективность будет такой же, как и в случае с горой разноцветных картинок.
Каждый факт должен тщательным образом проверяться на практике и приминительно к данной конкретной исследуемой проблеме. Только в этом случае возмежен синтез нового знания. Исключение составят только те факты, которые проверялись годами или десятилетиями разными группами исследователей, а их результаты такое же продолжительное время использовались в народном хозяйстве. Даже в этом случае остаются белые пятна на этих самых фактах.
Каждый новый факт — это как элемнт мазаики, из которой собирается цельная картина того или иного исследуемого объекта. Если этот факт не вписывается в существующую теорию об этом объекте, то теория пересматривается, обобщаются её положения, формулируются новые постулаты. Так развивалась и развивается наука.
От ставшего ненужным заучивания множества фактов и технологий к обучению когнитивным методикам: поиску, систематизации, анализу, сопоставлению, обобщению и синтезу новых знаний.
Дело в том, что ни одна из перечисленных когнетивных методик не будет полезна до тех пор, пока человек не обретёт достаточного количества знаний в конкретной специальной области и достаточного опыта, на основе чего сможет выполнить систематизацию или синтез. Здесь всегда действовал и действует принцип превращения количества в качество. Ни один доктор наук не напишет диссертацию посредствам бесконечного щёлкания интернет-ссылок.
С сегодняшним финансированием вузов скоро на всех курсах студенты начнут учить себя сами, готовя самостоятельные доклады. Средний возраст преподавателей перевалил за 60, а средняя зарплата осталась на уровне 12000 руб.
Ну не объектной, а постреляционной (или что то изменилось?).
Нет, ничего не изменилось, я имел в виду объектное представление данных.
В полной мере наследование лучше не использовать. Т.к. оно сделано через одно место. Будет создаваться две сущности (не помню уже как там конкретно в терминах на уровне Cach'e), со связями один к одному.
Создадутся две таблицы в реляционном представлении. Но все данные хранятся в разреженных многомерных массивах. И в случае создания и сохранения объектов класса наследника, в БД создастся один глобал, а не два, но в реляционном виде будет две таблице, в одной из которых появится несколько записей по числу сохранённых объектов.
Но раз мы уж говорим о объектах на уровне СУБД, то какая часть функционала вынесена в эти объекты? Так ли вам нужны объекты на уровне СУБД? Или вам будет, опять таки, достаточно объектного представления реляционной модели?
Некоторый функционал по обработке данных у нас вынесен на уровень классов Cache, что конечно же не делает это панацеей. Безусловно, можно было бы использовать ORM, ровно как его и не использовать, и работать напрямую с БД, будь она реляционной.
Я почитал. Возможно это оправданно. Зачем придумывать костыли, если есть уже готовое решение для вашей задачи.
О каком готовом решении для нашей задачи идёт речь?
Если уж вам так важно использовать каше, то может лучше реализовать часть функционала (самое необходимое) Jade на стороне Cach'e?
Может в этом и есть какой-то смысл, но на это точно нет ресурсов.
Но скорее всего, я бы пришел к выводу, что Cach'e есть лишняя технология. Объектное представление данных вам даст любая ORM технология
А любая другая реляционная СУБД с ORM надстройкой лишней технологией уже являться не будет?
Это представитель объектной СУБД, в которой генерируются проекции на java, что позволяет реализовать объектную связку с java-классами нашей системы. Какие ещё есть кандидаты с таким функционалом?
Насколько оправданно использование агентов? Неужели нельзя было решить задачу на стороне Cach'e? После чего реализовать ряд SOAP сервисов на стороне Cach'e и дергать их из флекса.
Тогда нам бы пришлось написать на Cache мультиагентную платформу аналогичную JADE в соответствие со стандартом FIPA. Использование мультиагентной платформы обусловлено сложностью задачи. В комментариях к первой части объясняются причины выбора мультиагентного подхода.
Ну и собственно почему именно Cach'e + java + flex? Три больших технологии, которые при разработке надо знать. Более того, Cach'e, не самая распространенная технология на нашем рынке, а flex то уже отмирает. Чем обусловлен этот выбор? Ну кроме того, что если мы используем Cach'e, нас поощряет InterSystems?
Не всегда распространённость технологии говорит о её преимуществах и является критерием её выбора. В нашей организации есть лицензия на Cache и разработаны некоторые системы, также используются и другие технологии и СУБД. Здесь Cache была выбрана из-за её объектности и java-проекций, не считая других её качеств как СУБД.
Что касается flex, то здесь не всё так однозначно, возможно другие модули системы уже будут реализовываться на HTML5.
Приложение на флеше не зависит от браузеров, а только от флэшплеера.
Разработка на HTML5 ещё не гарантирует преимуществ перед flex, т.к. находится в стадии становления.
Основной сложностью считаем проектирование архитектуры, которая позволяет разработать мультиагентную систему в web не нарушая самой концепции мультиагентного подхода. Здесь стоит отметить, что сама платформа JADE соответствует специальному стандарту для мультиагентных систем: FIPA. Соединение теории в реализации прикладной системы — это и есть основная сложность. Также стоит отметить сложность подбора и соединения разных технологий разработки ПО для создания этой системы.
Что касается ускорения или замедления разработки, ответить сложно, т.к. здесь было бы правильно сравнивать с другими подходами разработки именно мультиагентных систем, которые кроме прочего функцианируют в web. Но здесь существует масса платформ или готовых специализированных мультиагентных систем, но ничего неизвестно о технологиях их разработки.
В данной статье освещена только часть проекта, касающаяся рассмотренной комбинации Caché + Java + Flex. Сам проект направлен на создание мультиагентной системы управления учебным планированием, в которой каждому пользователю будет предоставлен его собственный агент, через который он и будет взаимодействовать с другими агентами системы. К использованию мультиагентного подхода нас подтолкнула сложность задачи согласования всех учебных планов института и интеграции их друг с другом, в результате чего должны появляться общие лекционные потоки. Мы рассматривали и другой вариант — постановка и решение задачи глобальной оптимизации. Такая задача может быть решена при наличии всех данных, но на данном этапе у нас их нет, да и решение задачи глобальной оптимизации не всегда бывает оптимальным, а внашем случае только количество измерений (искомых параметров) более 20 и достаточно много нетривиальных ограничений.
Использование мультиагентного подхода позволит решить такую задачу итерационным способом, когда агенты заведующих кафедрами будут взаимодействовать друг с другом, и поэтапно согласовывать учебные планы. В выбранной нами платформе (JADE) реализованы основные механизмы управления жизненным циклом агентов и их взаимодействием. Поэтому мы и используем JADE.
В основу архитектуры положена платформа JADE, т.к. одним из основных требований было создание мультиагентной системы. На данном этапе это плохо прослеживается и в статье не очень заметно, но в дальнейшем на это будет сделан серьёзный упор. Поэтому MySQL+PHP к решению такой задачи не подходят совсем.
Каждый факт должен тщательным образом проверяться на практике и приминительно к данной конкретной исследуемой проблеме. Только в этом случае возмежен синтез нового знания. Исключение составят только те факты, которые проверялись годами или десятилетиями разными группами исследователей, а их результаты такое же продолжительное время использовались в народном хозяйстве. Даже в этом случае остаются белые пятна на этих самых фактах.
Дело в том, что ни одна из перечисленных когнетивных методик не будет полезна до тех пор, пока человек не обретёт достаточного количества знаний в конкретной специальной области и достаточного опыта, на основе чего сможет выполнить систематизацию или синтез. Здесь всегда действовал и действует принцип превращения количества в качество. Ни один доктор наук не напишет диссертацию посредствам бесконечного щёлкания интернет-ссылок.
Нет, ничего не изменилось, я имел в виду объектное представление данных.
Создадутся две таблицы в реляционном представлении. Но все данные хранятся в разреженных многомерных массивах. И в случае создания и сохранения объектов класса наследника, в БД создастся один глобал, а не два, но в реляционном виде будет две таблице, в одной из которых появится несколько записей по числу сохранённых объектов.
Некоторый функционал по обработке данных у нас вынесен на уровень классов Cache, что конечно же не делает это панацеей. Безусловно, можно было бы использовать ORM, ровно как его и не использовать, и работать напрямую с БД, будь она реляционной.
О каком готовом решении для нашей задачи идёт речь?
Может в этом и есть какой-то смысл, но на это точно нет ресурсов.
А любая другая реляционная СУБД с ORM надстройкой лишней технологией уже являться не будет?
Это представитель объектной СУБД, в которой генерируются проекции на java, что позволяет реализовать объектную связку с java-классами нашей системы. Какие ещё есть кандидаты с таким функционалом?
Тогда нам бы пришлось написать на Cache мультиагентную платформу аналогичную JADE в соответствие со стандартом FIPA. Использование мультиагентной платформы обусловлено сложностью задачи. В комментариях к первой части объясняются причины выбора мультиагентного подхода.
Не всегда распространённость технологии говорит о её преимуществах и является критерием её выбора. В нашей организации есть лицензия на Cache и разработаны некоторые системы, также используются и другие технологии и СУБД. Здесь Cache была выбрана из-за её объектности и java-проекций, не считая других её качеств как СУБД.
Что касается flex, то здесь не всё так однозначно, возможно другие модули системы уже будут реализовываться на HTML5.
Разработка на HTML5 ещё не гарантирует преимуществ перед flex, т.к. находится в стадии становления.
Что касается ускорения или замедления разработки, ответить сложно, т.к. здесь было бы правильно сравнивать с другими подходами разработки именно мультиагентных систем, которые кроме прочего функцианируют в web. Но здесь существует масса платформ или готовых специализированных мультиагентных систем, но ничего неизвестно о технологиях их разработки.
Использование мультиагентного подхода позволит решить такую задачу итерационным способом, когда агенты заведующих кафедрами будут взаимодействовать друг с другом, и поэтапно согласовывать учебные планы. В выбранной нами платформе (JADE) реализованы основные механизмы управления жизненным циклом агентов и их взаимодействием. Поэтому мы и используем JADE.