Проектирование информационно-справочной системы ГОУ НПО ПУ №33 (стр. 3 из 12)
Также должна существовать возможность определять в контексте карты переменные различных типов, несущие любую смысловую нагрузку и влияющие на ход выполнения работы (допустим, название контрагента по сделке, сумма сделки, дата завершения этапа). Разумеется, должен быть встроенный редактор для создания экранных форм, которые на каждом этапе делового процесса отображают переменные и формируют пользовательский интерфейс workflow-приложения.
Следует помнить, что значения переменных, в идеале, должны считываться не только из базы данных workflow-системы, но и из баз данных прикладных программ, поддерживающих наиболее распространенные промышленные стандарты СУБД. Это позволяет интегрировать систему автоматизации деловых процессов с внешними приложениями в разрезе совместного использования данных. Что же касается встроенного языка программирования, о котором выше уже шла речь, то к нему, вполне очевидно, предъявляются такие требования, как простота (например, он должен быть семантически совместим с каким-либо распространенным языком — на сегодняшний день предпочтительнее всего VBA), эффективность, наличие широких возможностей по управлению деловыми процессами и связанными с ними данными. Крайне желательно, чтобы скрипт мог работать с OLE-серверами, запускать внешние программы, взаимодействовать с MAPI-совместимыми почтовыми системами. Кроме того, учитывая, что workflow-система рассматривается нами как основа КИС, для получения полной интеграции с другими программами и облегчения этого процесса, скорее всего, потребуется наличие открытого программного интерфейса API, который бы позволил управлять системой из внешних программ.
Международной организацией, курирующей разработку стандартов и спецификаций на системы класса workflow, является Workflow Management Coalition (WfMC). Теперь, после небольшого отступления, вернемся к проблеме построения КИС на базе системы автоматизации деловых процессов.
Если workflow-система отвечает большинству вышеперечисленных требований, то это позволит легко объединить вокруг нее любые современные приложения, поддерживающие те или иные стандарты межпрограммного взаимодействия. Ясно, что функциональная направленность интегрированного комплекса в принципе ничем не ограничена, однако некоторые сферы деятельности носят более распространенный характер, нежели другие, и поэтому заслуживают интеграции в первую очередь. Для групповых и корпоративных систем существенно повышаются требования к надежности функционирования и сохранности данных. Эти свойства обеспечиваются поддержкой целостности данных, ссылок и транзакций в серверах баз.
То есть говорят, что мы имеем дело с реальностью, описанием (представлением) реальности и с данными, которые отражают это представление. Данные, используемые для описания предметной области, представляются в виде трехуровневой схемы (так называемая модель ANSI/SPARC):
Рис. 1.2 Процесс предоставления данных в ИС
Внешнее представление (внешняя схема) данных является совокупностью требований к данным со стороны некоторой конкретной функции, выполняемой пользователем. Концептуальная схема является полной совокупностью всех требований к данным, полученной из пользовательских представлений о реальном мире. Внутренняя схема - это сама база данных.
Отсюда вытекают основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:
Концептуальное проектирование - сбор, анализ и редактирование требований к данным. Для этого осуществляются следующие мероприятия:
a) Обследование предметной области, изучение ее информационной структуры выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами моделирование и интеграция всех представлений. По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".
b) Логическое проектирование - преобразование требований к данным в структуры данных. На выходе получаем СУБД-ориентированную структуру базы данных и спецификации прикладных программ. На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей. Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.
Различие уровней представления данных на каждом этапе проектирования представлено в следующей таблице.
Таблица 1.1 Уровни представления данных
| КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ | |
| сущности | Представление аналитика |
| атрибуты | |
| связи | |
| ЛОГИЧЕСКИЙ УРОВЕНЬ | |
| записи | Представление программиста |
| элементы данных | |
| связи между записями | |
| ФИЗИЧЕСКИЙ УРОВЕНЬ | |
| группирование данных | Представление администратора |
| индексы | |
| методы доступа |
В теории проектирования информационных систем предметную область принято рассматривать в виде трех представлений[9]:
- представление предметной области в том виде, как она реально существует
- как ее воспринимает человек (имеется в виду проектировщик базы данных)
- как она может быть описана с помощью символов.
1.2 Этапы проектирования информационно-справочных систем
Проектирование информационно-справочной системы - это один из важнейших этапов ее существования то, с чего, собственно, должна начинаться её жизнь. Любая правильная информационно-справочная система базируется на тщательно спроектированной базе данных, в которой учтены не только все особенности ведения бизнеса, но и заложена возможность будущего развития путем добавления функциональности в информационную систему.
Задача проектирования АИС промышленных предприятий достаточно сложна, так как характер обрабатываемой информации разнороден и сложно формализуем. Однако здесь можно выделить основную модель работы - это работа "от кода проекта". В общем случае код проекта представляет собой аналог (функциональный) лицевого счета, он имеет определенную разрядность, порядок (т.е. конкретная группа цифро-буквенного обозначения характеризует деталь, сборочную единицу, изделие и их уровень взаимосвязи). Причем конкретная часть кода характеризует технологические, конструкторские, финансовые и др. документы. Все это регламентируется соответствующими ГОСТами, поэтому может быть формализовано. При этом модульный подход к реализации АИС наиболее важен.
Двойственный подход к формированию ежедневного производственного плана лег в основу т.н. "принципа дуализма" для АИС промышленных предприятий. Реализация принципа дуализма неизбежно также требовала построения АИС предприятий нового поколения в виде программных модулей, органически связанных между собой, но, в то же время, способных работать и автономно.
Такая многокомпонентная система обеспечивала соблюдение основополагающего принципа построения автоматизированных информационных систем - отсутствия дублирования ввода исходных данных. Информация по операциям, проведенным с применением одного из компонентов системы, могла быть использована любым другим ее компонентом. Модульность построения АИС нового поколения и принцип одноразового ввода дают возможность гибко варьировать конфигурацией этих систем[10].
Кроме того, одно из достоинств принципа многокомпонентности, являющегося базовым при создании АИС нового поколения, состоит в возможности их поэтапного внедрения. На первом этапе внедрения устанавливаются (или заменяются уже устаревшие) компоненты системы на те рабочие места, которые нуждаются в обновлении ПО. На втором этапе происходит развитие системы с подсоединением новых компонентов и отработкой межкомпонентных связей. Возможность применения такой методики внедрения обеспечивает ее достаточно простое тиражирование и адаптацию к местным условиям. Таким образом, автоматизированная информационная система нового поколения - это многокомпонентная система с распределенной базой данных по уровням экспертизы.
Многие предприятия предпочитают разрабатывать АИС собственными силами, так как:
1. стоимость таких разработок относительно низкая (по сравнению с продуктами крупных зарубежных разработчиков). Как правило, к существующим подразделениям департамента информатизации, таким как: управление эксплуатации, управление эксплуатации вычислительной сети и средств связи, экспертно-аналитическое управление (постановка задач), добавляется лишь новая структура: управление развития и разработки АИС, что, как правило, не влечет за собой больших финансовых затрат.
2. собственная разработка - это максимальная ориентация на реализацию бизнес - процессов предприятия или банка, его уникальных финансовых и управленческих технологий, складывающихся годами.
3. это позволяет обеспечивать значительно более высокий уровень безопасности и независимости от внешних факторов.
4. возможна оперативная реакция на изменения правил игры на рынке.
Вместе с тем при собственной разработке необходимо решить целый комплекс организационно-технических задач, которые позволили бы избежать ошибочных решений[11]: