Выделение информационных задач
Проектирование ИС начинается со сбора и предварительного анализа информационных потребностей пользователя. Основная цель этого этапа построения макета системы — выделение информационных задач (рис. 1.6).
Основным методологическим приемом, употребляемым при спецификации требований пользователя в МПС-технологии, является построение действующего макета системы. На макете можно сначала грубо, а потом все более детально показать пользователю, как работает система при решении его практических задач. С помощью макета пользователю легче формулировать и вносить исправления и дополнения в спецификацию требований. На основе обновленной спецификации формируется новый макет, и цикл отработки повторяется. Полученная в результате этих действий спецификация требований называется спецификацией макета системы.
Кроме знаний о статике и динамике предметной области спецификация макета содержит также описание взаимодействия пользователя с системой (сценарий диалога). Сценарии диалога и выходные отчеты требуются не только для построения действующего макета системы, так как они являются той конструктивной основой в совместной работе проектировщика и пользователя, в ходе которой устанавливается понимание проектировщиком задач пользователя, а пользователем — особенностей их автоматизированного решения.
Во время предварительного обследования предметной области прежде всего выделяются группы пользователей и слабосвязанные части ПО — функциональные области.
В каждой функциональной области выделяются информационные задачи. На этапе предварительного обследования трудно ожидать от проектировщиков и пользователей подробные спецификации информационных задач и экранных форматов, формируемых ими. На этом этапе достаточно лишь указать перечень событий, происходящих в ходе решения информационной задачи, и условия вызова каждой из них теми или иными группами пользователей.
Рассмотрим пример, приведенный на рис. 1.7. Предположим, что целью разрабатываемой ИС является автоматизация служб повышения квалификации работников в некоторой области народного хозяйства. В результате предварительного обследования удалось выяснить, что среди пользователей будущей системы имеются работники институтов повышения квалификации (ИПК) и работники отделов подготовки кадров (ОПК) предприятий, отвечающих за повышение квалификации своих сотрудников. Из-за слабой связи между задачами, решаемыми в ИПК и ОПК, всю предметную область можно разбить на две функциональные области: ИПК и ОПК. В каждой из них выделяются информационные задачи, автоматизирующие деятельность пользователей ИПК и ОПК. К задачам функциональной области ИПК могут относиться: прием преподавателя на работу, справки о преподавателях, справки о курсах, составление расписания и др.
Рассмотрим одну из задач — ПРИЕМ ПРЕПОДАВАТЕЛЯ. Пусть при предварительном обследовании удалось установить следующее:
1) задача предназначена для работников ИПК, отвечающих за прием преподавателей;
2) выполнение задачи может быть начато только после того, как произойдет событие ПРИЕМ РАЗРЕШЕН (устанавливаемое другой информационной задачей);
3) эта задача изменяет состояние функциональной области (событие ПРИНЯТ ЕЩЕ ОДИН ПРЕПОДАВАТЕЛЬ). Предположим, что требуется сообщать в ОПК предприятия (функциональная область ОПК) информацию о том, что новый преподаватель является совместителем и сотрудником данного предприятия (событие ПРИНЯТ ЕЩЕ ОДИН СОВМЕСТИТЕЛЬ).
Абстрагируясь от формы передачи этой информации (телефон, телефакс, телекс, сеть ЭВМ и т. д.), можно утверждать, что в функциональной области ОПК должна быть предусмотрена информационная задача ВВОД ИНФОРМАЦИИ О СОВМЕСТИТЕЛЯХ.
В отношении самой задачи ПРИЕМ ПРЕПОДАВАТЕЛЯ можно лишь пока утверждать, что в ходе ее выполнения должны произойти следующие события: ЗАПОЛНЕНА АНКЕТА; ПРОВЕРЕНЫ ДОКУМЕНТЫ; ЗАПОЛНЕНО ЗАЯВЛЕНИЕ; ПОДТВЕРЖДЕНИЕ С КАФЕДРЫ ПОЛУЧЕНО; ПОЛУЧЕН ПРИКАЗ О ЗАЧИСЛЕНИИ.
Процесс наступления событий, происходящих в ходе решения информационной задачи, может быть представлен сетью Петри, показанной на рис. 1.8. Здесь используется проверенная на практике [75] интерпретация сети УСЛОВИЕ — СОБЫТИЕ. Позиции в сети (показанные на рисунке кружками) обозначают условия, которые в зависимости от состояния сети (разметки) либо истинны (есть метка), либо ложны (метка отсутствует). События рассматриваются как переходы в сети (на рисунке они представлены вертикальными линиями с входящими и выходящими стрелками). Переходы в сети происходят, если все условия, связанные с входящими стрелками (предусловия события), истинны. Результатом перехода является свершение события, в результате которого истинными становятся условия, связанные выходящими стрелками (постусловия события).
При последующей реализации информационной задачи этим переходам могут соответствовать блоки прикладной программы или ее подпрограммы. На этапе предварительного обследования анализируются только события и их взаимосвязи.
Кроме отношения следования взаимосвязь событий может отражать отношения «целое — часть» и «обобщение — специализация». Например, на рис. 1.9 показано, что события ДОКУМЕНТЫ УДОВЛЕТВОРЯЮТ ТРЕБОВАНИЯМ и ДОКУМЕНТЫ НЕ УДОВЛЕТВОРЯЮТ ТРЕБОВАНИЯМ являются взаимоисключающими специализациями события ДОКУМЕНТЫ ПРОВЕРЕНЫ.
В описании для каждого события могут быть заданы дополнительные условия свершения (по времени, в зависимости от величины значения параметра задачи или характеристики функциональной области).
При последующем детальном рассмотрении событий должны быть проанализированы и другие их характеристики. Так, все сложные события (связанные с изменением состояния нескольких объектов) должны быть разбиты на простые (элементарные) и соотнесены с объектами определенного класса. Сложные события могут отражать наличие связи сразу между несколькими объектами.
Вся последовательность этапов получения спецификации МАКЕТА показана на рис. 1.9. Там же показаны метаобъекты, составляющие основу спецификации требований пользователя.
