Г Р А Ф И Т — б а з и с

Приложение 4.
Элементы организации познавательной работы

В приложении даны материалы для самостоятельной работы по (авто)формализации. Включены элементы алгоритмизации и программирования для информашин. Вместе с Приложением 3 оно относится к когнитивному обеспечению информатизации и выделено для удобства использования.

Приложение предназначено для обучения специалистов в различных предметных областях основам формализации профессиональных знаний.

К сему прилагается | Элементы организации познавательной работы | Основа

Стр. 1 2 3

Здесь даны материалы, раскрывающие процесс формализации, как правило, в виде примерных методик проведения работы в целом или её отдельных составляющих.

Содержание

Принципы реферативного описания задач

Понятие о реферативном описании

Технология реферирования

Понятие о реализации реферативного описания

Принципы реферативного описания задач

Здесь приведено описание методологии (авто)формализации профессиональных знаний в форме реферата задачи.

Понятие о реферативном описании

Фактически для разных классов процессов по-разному выделяются из обобщённого описания конкретные задачи и методы их решения; нужно иметь адекватные формы и методы такого описания. Постановка задачи – это её описание по определённым правилам, которое дает представление о сущности задачи (что дано и что надо) и о логике процессов, ведущих к получению результатов. Теорией систем и практикой автоматизации выработано представление задачи в виде реферата; с учетом положений информатики следует создать инвариант формы описания, который мы называем формуляром.

Можно говорить о методологии реферативного описания задач (РОЗ), результатом применения которой является обобщённое описание в форме реферата; центральная идея РОЗ – целостное описание задачи в расчете на различные инструментальные ИТ как средства её решения. Классы инструментария мы выделили в п. 2.6.1.

Предполагается, что исходным при постановке задачи для автоматизации является представление «в уме» человека (будущего пользователя системы) о решении конкретной задачи вручную; обычно оно неясно, неформально и неполно. Описание задачи по формуляру ведет к уточнению формулировок, повышению определённости языка изложения, явному описанию того, что часто «держится в уме» при ручном решении, но требует формализованного изложения для автоматизации.

Первым шагом формализации является представление рассматриваемой задачи как т.н. бизнес-процесса, входящего как часть в систему процессов организации; обычно модель деятельности в целом составляется при проведении реинжиниринга бизнес-процессов (РБП) или внедрении системы менеджмента качества (СМК); в действующей СМК процесс РБП является частью функционирования.

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

Языковые средства описания выбираются, исходя из классификации отчуждённого знания: структура отражается на графических языках, а состав и свойства — на текстово-табличных. Целостность описания обеспечивается тем, что частные описания интегрированы в шаблон реферата в трафаретной форме; структура шаблона отражает содержание задачи и стандартна для делопроизводства (содержание делится на разделы, подразделы, пункты и подпункты), а трафаретный текст связует частные описания и написан деловой прозой.

Сразу отметим, что возможны разные пути разработки решения. Прежде всего мы исходим из того, что разработка и документирование — это двуединый процесс, т.е. ход и результаты создания решения сразу отражаются в некоей согласованной сторонами форме. Если сначала разработать, а потом документировать — как правило, потребуются лишние усилия, и часто документация не будет качественной (и даже м.б. просто незаконченной в каких-то аспектах). Тогда решение «вырастает» из постановки задачи.

Однако вне зависимости и от этого возможны по крайней мере два пути. Очевидным является подробный, когда решение с самого начала документируется в максимально полной форме. Её общий состав и структуру, предлагаемые здесь, можно видеть в документации на Задачу 1.1.1. Видно, что выделяются сущностная модель задачи вкупе с её предметной областью и модель пожицикла решения. Первая определяется как инвариант-формуляр задачи. Вторая фиксирует проектные решения во времени в соответствии с современной теорией систем — от замысла до завершения утилизации1.

Однако во многих случаях это может оказаться «стрельбой из пушки по воробьям» - предметная область задачи столь проста, что пока стороны заполнят такую форму — уже можно было сделать решение :), а те или иные данные из этой формы не понадобятся ни разработчику, ни заказчику. Поэтому объективно нужен и сокращённый процесс разработки. В этом случае прежде всего уменьшается требуемый состав реквизитов документации решения. Возможный путь — отказаться от подробной сущностной модели. Тогда многие её элементы реализуются в самом решении. Это возможно прежде всего в т.н. сентенциальной формализации, когда знания принимают форму не инфопрогизделий, а документов. Многие вопросы в этом случае м.б. зафиксированы как общие для разных задач требования в составе формуляр-образцов применяемой УСД. Также можно понизить подробность модели процесса. Однако не менее интересное решение — принять процессную часть за основу описания, совместив в ней процесс разработки с процессом применения (тогда для конечных пользователей можно выделить вторую часть как руководство). Именно так сделано для Задачи 1.1.1. При этом можно не описывать детально ход процессов, а детализировать только некоторые операции (вместе с их предметной средой); эту детализацию, как видно, предлагается оформить как третью составляющую документации. Первоначально она м.б. незаполненной, т.к. детализацию проводят по мере необходимости (полагаясь в остальном на здравый смысл пользователя, его общие ЗУН и специфические, накопленные при решении сходных задач).

Отметим, что сокращённую формализацию может когда-то понадобиться привести к полной.

Если же всё-таки почему-либо нужно подробно зафиксировать решение (для анализа и совершенствования, или «обязательно требуют» внутренние и/или внешние стандарты :)) - добро пожаловать на путь, описанный ниже. Как уже сказано, его итогом является, кроме самого решения, формуляр задачи. Общий состав его будет очевиден из нижеизложенного; форму же мы не устанавливаем — человек грамотный в описании найдёт её сам, а остальным имеет смысл сначала поучиться :) - кстати, поиск подходящей формы для заданного содержания есть один из основных способов получения навыков в формализации знаний.

Основные положения РОЗ для сведения отражаются в формуляре задачи (см. п. «Общие положения» Разд. I Приложения 8).

В начало страницы

Технология реферирования

Вначале проводится анализ сущности задачи и её решения «как есть».

Результатом эскизной формализации является первичное и общее понимание задачи автором реферата, которое фиксируется в описании сущности задачи. Оно содержит следующие компоненты:

Конечно, все модели должны использовать единый набор сущностей (объектов, операций).

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

Модель процесса описывает структуру деятельности в общем (непроцедурном) виде, т.е. какие функции выполняются для решения задачи и как они взаимодействуют между собой. Здесь указывается и распределение деятельности по исполнителям (внутрисистемным, а если задача имеет связи за пределами оргсистемы – также и внешним).

Модель ресурсов (данных) описывает, какие типы базовых объектов используются (возникают, преобразуются) при решении задачи.

Ресурсы задачи классифицируются по ряду оснований. Так, изначально выделяют их рода: объекты-источники собственно входных данных задачи; объекты-справочники условно-постоянных данных, используемых (но не изменяемых) при решении; объекты-результаты, содержащие выходные данные. В пределах каждого рода выделяют виды по источнику поступления: из памяти (внутренней или внешней) или извне (в виде сообщения или документа). Также в соответствии с обычной практикой различают объекты по форме представления: символьной (натуральной, напр. бумажные, фото-, фонодокументы, голосовые или жестовые сообщения) и предметной (машинной, напр. файлы на диске, сообщения в ячейках основной памяти ОП). Следует иметь в виду, что в задаче могут использоваться разные формы одного объекта (и символьная, и предметная).

В информатике как ресурсы рассматривают обычно лишь данные. В единоличном решении задачи могут также участвовать неотчужденные знания человека (прошлый опыт, актуальные сведения, выводы на будущее); если задача становится коллективной, то такие знания отчуждаются как данные, насколько это возможно. В задачах использования знаний также возможно, что фигурирующие среди входных объектов знания (отчуждённые и/или неотчуждённые) преобразуются (напр. уточняются, сжимаются) и/или используются для порождения новых знаний. Неотчуждённые знания – это информация для задачи, получаемая из внутренней памяти человека; «извне» же для человека - это либо от другого человека, либо от средств отображения машины. Для машины «извне» значит либо по техническим каналам связи (с другой машиной или окружением), либо по каналам ручного ввода от оператора (клавишного набора, с голоса, с документа). Изнутри машина (ЭВМ, ВС, ВК) получает информацию из памяти; при этом входные/выходные объекты могут представляться как массивы в ОП только внутри одной машины (системы с общим полем ОП) и только если предполагается, что другие задачи (источники/потребители этих объектов) всегда выполняются в течение одного сеанса с данной задачей.

Модель исполнителя описывает, кто кому передает те или иные исходные, промежуточные и результатные данные и у кого ведутся массивы входных и выходных данных задачи.

Понятно, что при наличии модели системы все частные модели определяются по ней; если такой модели нет, то возможные стратегии зависят от представления о задаче.

Наиболее простой путь моделирования процесса решения — описать его в виде ряда текстовых посылок; по мере их накопления у автора появляется возможность перейти к графическому представлению структуры решения. Для этого рекомендуется стандарт IDEF0 (см. /11/) либо ДПД. Детализацию (декомпозицию функциональной схемы) коллективно выполняемой задачи следует вести так, чтобы в итоге для каждой функции определился единственный исполнитель (рабочее место).

Если задача информационная, то можно описать её решение моделью на некотором языке движения данных; напр., для задач учета подходит язык описания движения стоимостей (см. Прил. 8). Если задача вычислительная, то можно пользоваться языком схем действий (см. Прил. 8).

Модель ресурсов удобно составить на языке схем данных; на схеме перечисляются все типы объектов (входных, справочных и результатных). Следует классифицировать объекты, исходя из вышесказанного; кроме того, нужно выделить классы объектов по общности тех или иных свойств, т.е. с точки зрения их наследования внутри задачи (а впоследствии и между задачами).

Содержание объекта или его части может описываться различным образом. Для реферата удобно смешанное текстово-табличное описание на языке атрибуции данных (см. Прил.8).

Нужно уточнить, не обеспечивают ли те или иные данные, описанные в задаче, решение также и других задач; для таких данных (т.н. регламентных) следует выработать единое определение, согласованное с требованиями всех задач.

Модель исполнителя задается либо как обычная структурная схема, либо на структурно-топологическом языке.

Описание сущности уточняется и конкретизируется автором в последующих разделах реферата. Их состав и содержание определяется следующим образом.

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

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

На полностью схематизированной модели задачи любому потоку, массиву данных должен соответствовать один тип базового объекта (логическое отношение 1:1).

Поток или массив данных образуется из экземпляров базового объекта (документа, сообщения).

Для машинного решения в реферате нужно также определить для каждого типа базового объекта его символьную форму, т.е. вид, в котором ИС показывает его человеку. В общем случае результат документируется, при этом у объекта существует две символьных формы: экранная и печатная; каждая может иметь свой формат, порядок реквизитов и атрибуты их оформления.

Рекомендуется следовать давно известному принципу WYSWYG (What You See – What You Get): формы одного и того же объекта на экране и на печати должны максимально совпадать.

Предметная форма базового объекта в ИС – массив машинных кодов, занимающий в некоем узле системы программно-доступный элемент, зависящий от функции узла: при обработке – регистр процессора (контроллера), при хранении – блок (сегмент) ОП и файл на внешнем ЗУ, при обмене – кодограмма (посылка, кадр) в канале связи; единичный элемент может включать часть объекта.

Отметим следующие особенности представления, специально не выделяемые в формуляре.

Мультимедийные данные при выводе из ИС не всегда полностью отражаются на экране; часть их воспроизводится по звуковому каналу, часть – в манипуляциях исполнительных органов (для средств автоматизации научных или технических задач); соответственно различаются и формы документирования таких данных (звуко- и видеозапись, измерения манипуляций и пр.).

В каждом узле ИС объект приобретает свою предметную форму, определённую разработчиком узла.

В соответствии с классификацией объектов в задаче, все они разделяются на группы исходных, справочных и результатных. Описание любого объекта (как и общей части класса) содержит:

Наименование объекта: основное (используемое как заголовок) и краткое (используемое как метка).

Формы объекта. Указывается:

Для сведения можно приложить формы документа (сообщения), употребляемые на момент составления реферата. Можно описать параметры (метаданные) форматирования реквизитов формы; удобно представить форматирование наглядно.

Содержание объекта. Указать:

Структуру описывают, если она сложна и недостаточно очевидна. Большинство реквизитов группируются в записи о сущностях того или иного рода; обычно такая группировка очевидна из формы объекта (записям соответствуют строки и/или столбцы таблиц в документе).

Задание значений допустимо символически описать внутри формы (формулами, операциями). При этом пользуются некоторым формальным языком; следует придерживаться стандартных языковых норм, принятых в математике и программировании (иные соглашения описываются в Разд. 1).

Поток объекта. Указать:

Далее описывается алгоритм решения, т.е. все возможные пути, которыми из исходных данных при участии условно-постоянных получаются результатные. Должны рассматриваться и ситуации, когда все или часть исходных данных заданы некорректно; на этот случай пользователь должен указать желаемые действия программы.

Обычно алгоритм получается как результат элементарного анализа действий пользователя при решении задачи; существенную помощь здесь должны оказать ранее сформулированные посылки. Если содержание деятельности не поддается элементарному анализу, можно действовать по одной из методик алгоритмизации (напр., по описанной в Прил. 7).

Для записи алгоритмов рекомендуется использовать техноязык ДРАКОН. В реферате возможно описание структурированным текстом (псевдокод, таблицы решений).

Следующий раздел содержит характеристику текущей реализации решения. Описывается, что в задаче на момент составления реферата уже выполняется на машинах, какие должностные лица являются операторами этих машин. Машинная реализация описывается унктами:

1. Виды используемых информашин, критичные параметры конфигурации и их допустимые (минимальные) значения, при которых задача выполнима.

2. Характеристика программы решения (командной модели действий информашины) в зависимости от избранного способа машинного решения задачи (подзадачи):

При сочетании разных способов решения их программы описываются отдельно.

3. Следующие данные включаются для контроля целостности инфопрогизделий:

Раздел методического обеспечения содержит инструкцию по решению (командную модель действий пользователя), а также контрольный пример. При эскизной формализации инструкция необязательна; её составляет разработчик программы (модуля) решения задачи. Пользователь для составления контрольного примера (а также для тестирования) предоставляет ряд наборов исходных данных и заведомо правильных результатов решения при этих данных (включая варианты, когда те или иные исходные данные некорректны).

Заключительный раздел определяет цели и результаты, т.е. чего собственно хочет автор реферата от его адресатов (потенциальных партнёров по совершенствованию решения). Следует сформулировать, что в текущей реализации задачи не устраивает автора и какие результаты (хотя бы качественно, а если возможно - то количественно) ожидаются от автоматизации её решения. Можно указать, как должна выглядеть, по мнению пользователя, модель задачи после автоматизации.

Законченный пользователем реферат задачи обретает качество технического задания для исполнителя работ по автоматизации; по нему можно ожидать качественного выполнения работ и вполне конкретно спрашивать их результат (в зависимости от точности разд. «Цели и результаты»).

Важно иметь в виду, что реферат, составленный пользователем, отражает его точку зрения на автоматизацию; у исполнителя работ будет своя точка зрения, по объективным (иная роль) и субъективным (сложившиеся взгляды, квалификация и пр.) причинам не совпадающая с пользовательской.

В процессе работ по автоматизации согласуются точки зрения сторон, углубляется понимание задачи; поэтому описание может уточняться, что требует той или иной корректировки реферата. Итоговая версия принимается как окончательное ТЗ, которым руководствуются при приемке системы.

При постановке задачи часто автор, описывая содержание одного раздела, в то же время излагает сведения касательно других. Это вполне естественно, ведь в человеческом сознании любая проблема изначально представлена целостно, без выделения разделов и пунктов. Искусственно ограничивать себя в изложении не нужно; следует лишь по мере накопления разнородного материала относить его к соответствующим частям структуры реферата.

На следующем этапе выбираются перспективные средства решения задачи (системы и технологии автоматизации).

Подразумевается, что средством автоматизации служит программа для стандартной информашины. Возможны особые требования к конфигурации оборудования, включая настройки отдельных устройств. Сконфигурированная машина с установленной программой образуют информатическую систему решения задачи. Человек вместе с ИС образует информационную систему.

Результат автоматизации задачи – т.н. командная модель решения задачи информационной системой, состоящая из двух частей: для человека (инструкция пользователю) и для компьютера (машинные коды программы); составление этой модели для точно определённых условий и есть та работа, которая делается при автоматизации. Содержание первой части необходимо пользователю и составляется на основе его требований к диалогу с машиной (уточнённых совместно с разработчиком) и алгоритма работы программы. Из содержания второй пользователю нужны некоторые данные о программе и её требованиях к оборудованию. Источником второй части являются исходные тексты на языке программирования, составляемые разработчиком программы; содержание текстов и кодов пользователя не интересует (и даже м. б. недоступно ему, если машинное решение охраняется правом как интеллектуальная собственность разработчика и/или как один из видов законной тайны).

Следующим этапом будет проверка реферата. Можно выделить два её подэтапа:

В любом случае выявляются недочёты и ошибки как несоответствия качества реферата уровню, необходимому для технического задания. Именно процесс исправления несоответствий и служит наиболее эффективному согласованию точек зрения разработчика и пользователя будущей системы решения задачи.

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

Далее по реферату разрабатывается система решения задачи. При этом происходит уточнение средств и способов информатизации; программирование машинного решения и информатизация методической части; выпуск решения.

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

Возможно решение задачи с использованием нескольких модулей; они взаимосвязаны по данным последовательно, параллельно или по смешанной схеме. Сочетание исполняемых модулей с транслируемыми (особенно в разных приложениях) обычно не так эффективно и удобно для пользователя.

По готовому решению отдельные разделы (прежде всего «Алгоритм решения», «Методическое обеспечение» и «Машинная реализация») наполняются сведениями от разработчика; после внесения этих сведений в реферат получается отдельный документ – паспорт задачи, используемый при сопровождении. Поэтому для некоторых разделов указано, что требуется от пользователя (для реферата) и что от разработчика (для паспорта).

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

Следующим этапом является тестирование и паспортизация задачи. Здесь реферат перерабатывается разработчиком по следующим направлениям.

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

Описания объектов и классов приводятся к виду, согласованному с требованиями системы разработки решения (программирования, конфигурирования, конструирования).

Оформляется описание алгоритма для пользователя.

Описание реализации наполняется сведениями о новой системе решения.

На основе окончательного алгоритма составляется инструкция пользователю, включающая описание форм объектов, управляющих органов (экранов отображения данных).

Формулируются результаты с указанием отклонений от целей, поставленных в реферате; по возможности указываются перспективы развития созданной системы (новые возможности решения, устранение недостатков, применимость для других задач).

В начало страницы

Понятие о реализации реферативного описания

Основной способ реализации РОЗ — организационный, т.е. усилиями человека. Техника преимущественно используется для подготовки документов. Главными средствами автоматизации изначально будут инфорсимы поддержки машинного документооборота (офисные пакеты, установленные на сетевых АРМ).

Методология РОЗ оставляет больше свободы в выборе средств дальнейшего (частного) описания и менее технологически сложна чем, например, методология чисто функционального моделирования; вместе с тем в ней целостно отражены базовые компоненты знания и разные точки зрения на задачу.

В начало страницы | Оглавление | Версия для печати

Copyright © Жаринов В.Н.

1 Напомним, что в ОТС этот термин понимается в широком смысле, а не только как «переработка отходов» ;).

Hosted by uCoz