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

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

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

Вышеизложенная методология схематично отображена на рис 1.

Рис. 1. Методология создания системы документооборота

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

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

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

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

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

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

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

В настоящей статье предлагается методология, которая предполагает проведение декомпозиции процесса документооборота до совокупности элементов и их отношений между собой. Эти элементы можно разделить на три категории: участники, состояния документов и действия участников. Участники документооборота - это сотрудники организации, производящие генерирование, движение и терминирование документов. По сути, участники воспринимаются системой через совокупность их обязанностей и могут описываться как ключевые участники, на роли которых назначаются реальные исполнители. Состояния документов - это конечный список состояний, которые могут принимать документы в процессе моделируемого документооборота. Представление документов в виде конечного дискретного списка состояния получается в результате применения декомпозиции к общему жизненному циклу документа. Действия участников - это конечный список возмущающих воздействий, инициируемых участниками, возникновение которых приводит к изменению текущего состояния одного или нескольких документов.

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

- формальная модель документооборота;

- множество участников;

- множество действий;

- множество состояний документов.

Эта нотация означает следующее: «Документооборот - это множество действий, производимых множеством участником над множеством состояний документов». Множество определяется как конечное множество ролей, которые могут быть назначены фактическим участникам документооборота. определяется как конечное множество действий, выполнение которых допустимо в пределах рассматриваемой системы документооборота. - конечное множество состояний, которые могут принимать документы после произведения действий из множества участником из множества .

3.1. Концептуальная модель

Концептуальная модель основывается на подходах, описанных в работах признанного специалиста в области создания систем корпоративного документооборота Майкл Саттона [3], В.М. Глушкова [2] и автора этой статьи [8]. В концептуальной модели на уровне концепции решаются вопросы масштабности системы и ее интеграции в общую систему организации. Для создания модели устанавливается взаимосвязь между необходимостью внедрения системы электронного документооборота и ее будущими пользователями.

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

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

Страницы: 1, 2, 3