Татьяна Михайловна, ваши наработки радуют. Вы пишите: В процессе совещания состав
объектов может изменяться и связываться не только в последовательность, но и в
иерархию. Что представляет собой иерархия иерархия объектов?
Татьяна Михайловна, ваши наработки радуют. Вы пишите: В процессе совещания состав
объектов может изменяться и связываться не только в последовательность, но и в
иерархию. Что представляет собой иерархия иерархия объектов?
Спасибо за вопрос.
Помимо запланированных предметов обсуждения (последовательность), в процессе
обсуждения какого-то вопроса, может возникнуть необходимость и в декомпозиции
вопроса на ряд вспомогательных, которые, в свою очередь становятся предметами
обсуждения.
И это создает смысловую иерархию объектов, которая отражается в структуре
протокола.
Почему базовая модель протокола названа объектно ориентированной? Имеет ли она отношение к объектно ориентированному подходу в программировании? Если да, то в чем сходство? С уважением В.Калмыков
Почему базовая модель протокола названа объектно ориентированной? Имеет ли она отношение к объектно ориентированному подходу в программировании? Если да, то в чем сходство? С уважением В.Калмыков
Спасибо за вопрос.
Собственно говоря, базовая модель и возникла в результате
объектно-ориентированного анализа совещания, в результате чего и были выявлены соответствующие
объекты, среди которых наиболее важен – предмет обсуждения.
Собственно в этом и заключается объектно-ориентированый подход, т.е.
осуществляется выявление обьектов, определение их параметров и процессов и
определение порядка их порождения и завершения.
И здесь, сценарий и фактическая деятельность в процессе совещания определяют
порядок порождение объектов, функционирования и завершения.
А протокол является описанием содержания завершенных объектов в порядке их
порождения.
С уважением. Т. Власова
Ну вот, дошли у меня руки до Вашего доклада с соавторами. И
странная картина открылась взору. Вы ссылаетесь на публикации, описывающие «основные
принципы создания и функционирования СЦ» и «отдельные вопросы реализации ПТК…»,
но почему-то забыли о нашей совместной работе, прямо посвящённой заявленной
теме, а именно:
Малышев О. В., Власова
Т. М.Протоколирование совещаний экспертов,
проводимых в условиях ситуационного
центра. – Системи підтримки прийняття рішень. Теорія і практика: Збірник
доповідей науково-практичної конференції з міжнародною участю. – 6 червня 2011. – Київ: Інститут проблем математичних машин і систем НАН
України. – 2011. – С. 85-88.
Вы описываете «объектно-ориентированную базовую модель
документа «Протокол совещания».
А помните, что все данные по совещанию, в том числе, получаемые
оперативно в ходе совещания, хранятся в разработанной мной базе данных? И Вы
спокойно формировали по этим данным, пускай не «протоколы», но отчёты по проведенному
совещанию. Хотя, почему не протоколы (см. выше ссылку на публикацию).
Вас в моей модели что-то не устраивало? Там не хватает
каких-то данных? В чём отличие того, что вы (с соавторами) предлагаете от того,
что мы с Вами совместно сделали, и оно как-то, но работает?
В вашем докладе отсутствует, на мой взгляд, главное –
рассмотрение соотношения между данными, хранящимися и обслуживаемыми СЭД, и
данными, поддерживающими полнофункциональный СЦ с учётом всей специфики
получения данных, в т.ч., от нестандартного оборудования.
Спасибо за вопрос!
Существующий макет проведения совещания по прежнему ориентирован на Вашу "Модель данных", но доработан с
целью автоматического создания именно «традиционного» протокола, от которого Вы "открестились" в ст.
ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ ЭКСПЕРТОВ,ПРОВОДИМЫХ В УСЛОВИЯХ СИТУАЦИОННОГО ЦЕНТРА.
В нашем случае, весь пройденный путь совещанием проецируется на протокол.
Протокол м.б. выполнен в виде HTML документа или в текстовом виде.
При построении упомянутых Вами отчетов использовались списки выступлений, докладов и пр.
Соответствующее приложение использовалось для выбора нужных, например, выступлений для их прослушивания или
распечатки на табло и на принтере.
Возможно, вручную можно было бы составить протокол на основании этих отчетов, но мы предпочли составлять протокол
автоматически.
С уважением Т. Власова
Спасибо за вопрос!
Существующий макет проведения совещания по прежнему ориентирован на Вашу "Модель данных", но доработан с
целью автоматического создания именно «традиционного» протокола, от которого Вы "открестились" в ст.
ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ ЭКСПЕРТОВ,ПРОВОДИМЫХ В УСЛОВИЯХ СИТУАЦИОННОГО ЦЕНТРА.
В нашем случае, весь пройденный путь совещанием проецируется на протокол.
Протокол м.б. выполнен в виде HTML документа или в текстовом виде.
При построении упомянутых Вами отчетов использовались списки выступлений, докладов и пр.
Соответствующее приложение использовалось для выбора нужных, например, выступлений для их прослушивания или
распечатки на табло и на принтере.
Возможно, вручную можно было бы составить протокол на основании этих отчетов, но мы предпочли составлять протокол
автоматически.
С уважением Т. Власова
Добрый
день, Олег Васильевич!
Дополню ответ Власовой Т.М. ответом на последний абзац Вашего замечания:
"В вашем докладе отсутствует, на мой взгляд,
главное – рассмотрение соотношения между данными, хранящимися и обслуживаемыми
СЭД, и данными, поддерживающими полнофункциональный СЦ с учётом всей специфики
получения данных, в т.ч., от нестандартного оборудования."
Соотношение здесь достаточно
простое.
Управление деятельностью СЦ
осуществляется посредством документов. Поддержка этого процесса обеспечивается
СЭД.
Совещание является одним из
видов деятельности в СЦ и имеет следующие фазы ЖЦ: подготовка, проведение и
реализация решений.
Понятно, что первая и
последняя фазы совещания поддерживаются СЭД в соответствии с регламентом
организации привычным для сотрудников образом.
Теперь, подсистема проведения
совещания. Назначение – автоматизация деятельности в ситуационном зале в
процессе совещания.
Она имеет вход и выход по
данным и временное хранилище данных.
В общем случае, на входе
повестка дня и необходимые рабочие материалы. В частности, эти материалы могут
представляться и ссылками на потоковые данные.
На выходе – протокол и другие
материалы, как исходные, так и порожденные в процессе совещания. Размещение и хранение
этих данных определяется регламентом СЦ и поддерживается СЭД с учетом
соответствующих прав доступа.
Ну а хранилище данных
совещания имеет, конечно, и временную базу фактографических данных, необходимых
для управления ходом совещания.
Таким образом, связь СЭД с
подсистемой проведения совещания осуществляется с помощью двух конверторов. И
это делает подсистему проведения совещания независимой от окружающего
программного и информационного обеспечения.
В спроектированной мной БД
предусмотрено размещение практически всей информации по процессу подготовки и
проведения совещания. Если чего и нет, то можно добавить. Кстати, в этом
направлении я и развиваю свою модель данных. Совершенно очевидно, что у меня в
БД хранится достаточно информации для формирования «традиционного» текстового протокола.
И этот, «традиционный», протокол, естественно, делается не вручную, а автоматически,
для чего пишется – 1 раз! – соответствующее приложение.
Ваш «автоматический» протокол –
это такое же приложение. Ни больше, ни меньше. И его «объектная ориентация»
ровно ничего к этому не добавляет.
Кроме того, в моей БД хранится
много другой информации, которая в «традиционный» протокол в принципе попасть
не может, но чрезвычайно ценна для дела.
Поэтому в проигнорированной
Вами непонятно почему нашей статье я и ставил задачу в общем – нужна информационно-поисковая
система (ИПС), с помощью которой заинтересованное лицо сможет добраться до любой
информации по совещанию, и не только по совещанию. Разумеется, в частности, и
сформировать любой текстовый протокол.
При этом я чётко понимаю,
откуда и как в мою БД попадает информация. А откуда Вы берёте информацию для
Вашего «автоматического» протокола?
Постарайтесь дать чёткий ответ
на этот чёткий вопрос.
И подсказываю:
1. Если она берётся из моей БД,
то вся Ваша со товарищи разработка – это всего лишь одна из возможных реализаций
заявленной мной в той пресловутой статье ИПС. И на статью надо было сослаться.
2. Если же она берётся
непонятно откуда, то так прямо и скажите. Тогда понятно, какова цена всему
Вашему «параллельному» начинанию.
Спасибо за вопрос.
Нашу работу можно рассматривать, как «параллельное» начинание или как одно из существенных дополнений к настоящему макету проведения совещания, это зависит от точки зрения. Простите, ради бога, за "открестились"
Вот фраза из статьи «ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ…»:
«Мы будем исходить из предположения, что для многих совещаний, проводимых в
условиях Ситуационного центра (СЦ), требуется не просто формальный протокол, а
информационный конгломерат… ».
Т.е. создание формального протокола не было нашей с Вами темой в тот момент, а через 3 года мы (Сёмик, Соломонов и Власова) реализовали автоматическое создание протокола совещания и описали его в обсуждаемой статье.
Да, пожалуй, стоило сослаться на статью «ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ…».
И еще из этой же статьи:
«Итак, если совещание запрограммировать, и процесс его проведения сделать
процессом выполнения программы с применением соответствующих средств [3], то
полученный компонент протокола совещания будет представлять собой дискретную
многоуровневую древовидно-сетевую конструкцию, отражающую деление всего процесса
на последовательность отдельных составляющих, а также их декомпозицию».
В обсуждаемой статье мы подошли к описанию компонента протокола несколько конкретнее.
Попробую достичь понимания дополнением к этой статье:
Требование структурного оформления протокола побудило нас к формированию «единицы» структуры совещания, которая может быть представлена структурой предмета обсуждения с такими ее полями (компонентами):
- наименование предмета обсуждения;
- информирование о предмете обсуждения (звуковой файл);
- вопросы и ответы относительно предмета обсуждения (звуковые файлы);
- выступления (предложения) относительно предмета обсуждения (звуковые файлы);
- голосование относительно предмета обсуждения (результаты голосования);
При рассмотрении протокола проведенного совещания могут быть выделены стандартные предметы обсуждения:
- повестка дня;
- регламент проведения совещания;
- проект решения;
- доклады;
- выступления.
По ходу совещания могут быть дополнительно включены для обсуждения и представлены на общем экране видео, аудио или пр. файлы.
Объект предмета обсуждения формируется при выборе председателем совещания одного из этих предметов обсуждения.
Новый (сформированный) объект добавляется в массив соответствующих объектов.
Регламентные процедуры обсуждения объединены в Список регламентных процедур, в котором задан и порядок выбора этих процедур:
- включение выступления о предмете обсуждения;
- запуск процедуры «вопросы и ответы» относительно предмета обсуждения;
- запуск процедуры выступлений относительно предмета обсуждения;
- запуск процедуры голосования относительно предмета обсуждения;
После выбора предмета обсуждения председатель, ориентируясь на регламент и обстоятельства, может выбрать последовательно (из Списка) регламентные процедуры обсуждения или одну из них. Впрочем, он может решить, что выбранный предмет не стоит обсуждать, и перейти к следующей проблеме совещания.
После выполнения регламентных процедур их результаты сохраняются в текущих объектах.
Т.о. изложенный метод позволяет при проведении совещания строго следовать регламенту, при этом фиксировать только фактический ход совещания и, как следствие, помогает оформить фактический Протокол совещания.
Теперь четкий ответ на четкий вопрос: фактический Протокол совещания «разворачивается» из массива объектов (не напрямую из БД), в которых подчиненность компонентов переориентирована на текущий предмет обсуждения.
Протокол совещания, к тому же, становится самостоятельным и исчерпывающим (насколько этого требует регламент) документом, например, html-документом, и нет нужды сохранять прошедшее совещание в БД, если его сохранять в БД не требует регламент.
Я предлагаю перенести нашу дискуссию на наш семинар и там обсудить обе статьи «о ПРОТОКОЛИРОВАНИИ СОВЕЩАНИЙ» и имеющиеся в них отличия.
С уважением, Власова Т.М.
Спасибо за вопрос.
Нашу работу можно рассматривать, как «параллельное» начинание или как одно из существенных дополнений к настоящему макету проведения совещания, это зависит от точки зрения. Простите, ради бога, за "открестились"
Вот фраза из статьи «ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ…»:
«Мы будем исходить из предположения, что для многих совещаний, проводимых в
условиях Ситуационного центра (СЦ), требуется не просто формальный протокол, а
информационный конгломерат… ».
Т.е. создание формального протокола не было нашей с Вами темой в тот момент, а через 3 года мы (Сёмик, Соломонов и Власова) реализовали автоматическое создание протокола совещания и описали его в обсуждаемой статье.
Да, пожалуй, стоило сослаться на статью «ПРОТОКОЛИРОВАНИЕ СОВЕЩАНИЙ…».
И еще из этой же статьи:
«Итак, если совещание запрограммировать, и процесс его проведения сделать
процессом выполнения программы с применением соответствующих средств [3], то
полученный компонент протокола совещания будет представлять собой дискретную
многоуровневую древовидно-сетевую конструкцию, отражающую деление всего процесса
на последовательность отдельных составляющих, а также их декомпозицию».
В обсуждаемой статье мы подошли к описанию компонента протокола несколько конкретнее.
Попробую достичь понимания дополнением к этой статье:
Требование структурного оформления протокола побудило нас к формированию «единицы» структуры совещания, которая может быть представлена структурой предмета обсуждения с такими ее полями (компонентами):
- наименование предмета обсуждения;
- информирование о предмете обсуждения (звуковой файл);
- вопросы и ответы относительно предмета обсуждения (звуковые файлы);
- выступления (предложения) относительно предмета обсуждения (звуковые файлы);
- голосование относительно предмета обсуждения (результаты голосования);
При рассмотрении протокола проведенного совещания могут быть выделены стандартные предметы обсуждения:
- повестка дня;
- регламент проведения совещания;
- проект решения;
- доклады;
- выступления.
По ходу совещания могут быть дополнительно включены для обсуждения и представлены на общем экране видео, аудио или пр. файлы.
Объект предмета обсуждения формируется при выборе председателем совещания одного из этих предметов обсуждения.
Новый (сформированный) объект добавляется в массив соответствующих объектов.
Регламентные процедуры обсуждения объединены в Список регламентных процедур, в котором задан и порядок выбора этих процедур:
- включение выступления о предмете обсуждения;
- запуск процедуры «вопросы и ответы» относительно предмета обсуждения;
- запуск процедуры выступлений относительно предмета обсуждения;
- запуск процедуры голосования относительно предмета обсуждения;
После выбора предмета обсуждения председатель, ориентируясь на регламент и обстоятельства, может выбрать последовательно (из Списка) регламентные процедуры обсуждения или одну из них. Впрочем, он может решить, что выбранный предмет не стоит обсуждать, и перейти к следующей проблеме совещания.
После выполнения регламентных процедур их результаты сохраняются в текущих объектах.
Т.о. изложенный метод позволяет при проведении совещания строго следовать регламенту, при этом фиксировать только фактический ход совещания и, как следствие, помогает оформить фактический Протокол совещания.
Теперь четкий ответ на четкий вопрос: фактический Протокол совещания «разворачивается» из массива объектов (не напрямую из БД), в которых подчиненность компонентов переориентирована на текущий предмет обсуждения.
Протокол совещания, к тому же, становится самостоятельным и исчерпывающим (насколько этого требует регламент) документом, например, html-документом, и нет нужды сохранять прошедшее совещание в БД, если его сохранять в БД не требует регламент.
Я предлагаю перенести нашу дискуссию на наш семинар и там обсудить обе статьи «о ПРОТОКОЛИРОВАНИИ СОВЕЩАНИЙ» и имеющиеся в них отличия.
С уважением, Власова Т.М.
Добрый день, Олег Васильевич!
Если позволите, то я вклинюсь
в Ваш диалог с Татьяной Михайловной, как сотоварищ.
В дополнение к предыдущему комментарию
хочу добавить следующее.
Для быстрого программного
макетирования используется модифицированный фрагмент Вашей базы данных.
Но с пониманием, что этот набор данных является необходимым и достаточным
для проведения совещания в ситуационном зале.
Кроме того, если взять
нормативные документы, связанные исключительно с Совещанием: Повестку дня, Протокол
совещания и Регламент, передать их двум разным разработчикам подсистемы
управления совещанием, то созданные ими структуры данных для Совещания будут практически
идентичны.
Ну и, кроме того, по функциональному назначению данный макет ни в коем
случае не может являться «всего
лишь одной из возможных реализаций заявленной мной в той пресловутой статье ИПС».
