Файл: Метод указания магистерская диссертация магистратура ПИ.docx

2.3 Информационное обеспечение задачи

2.3.1 Информационная модель и её описание

Методика разработки информационной модели предполагает моделирование нового варианта организации информационной системы предметной области («КАК ДОЛЖНО БЫТЬ»), а именно:

1. полного состава информации, необходимой для решения комплекса задач данного АРМа;

2. отражение этой информации на всех типах носителей;

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

4. состава исходных первичных документов и распределение их по задачам;

5. источники и способы получения первичной информации;

6. состава файлов с первичной, условно-постоянной, промежуточной и результатной информацией;

7. информационную потребность для каждой задачи комплекса;

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

В описании информационной модели необходимо объяснить, на основе каких входных документов и какой нормативно-справочной информации происходит выполнение функций по обработке данных и формирование конкретных выходных документов.

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

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

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

Правило 1 Модель читается исключительно сверху вниз

Правило 2 У каждого элемента на модели должен быть как вход, так и выход.

Это правило не относится к источникам и получателям информации для моделируемой ИС, так как у них бывает либо выход (у источников), либо вход (у получателей).

Правило 3 Вход обозначается в центре верхней части элемента, а выход – в центре нижней части. Вход и выход у элемента должен быть только 1.

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

Правило 5 Если в рамках работы информационной системы происходит изменение состояния объекта (файла, таблицы, справочника), то это должно быть обозначено любым из символов ( «`», «!», «@», «#», «^», «&», «*» ). Под изменением, например, могут пониматься добавление записи в таблицу (insert), изменение записи в таблице (update), изменение любого байта в уже существующем файле.

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

• внешние информационные системы или технические средства

  • сигналы от любых датчиков или любого оборудования («Direct data» )

  • файлы, которые были экспортированы какой-то ИС (модулем нашей ИС) и которые мы будем импортировать ( )

  • мы напрямую получаем доступ к таблицам БД внешней ИС ( )

  • мы получаем доступ к файловому хранилищу ИС, работающей в рамках архитектуры файл-сервер ( )

  • взаимодействие по какому-либо прикладному протоколу по сети ( , где название – это название или код сообщения в соответствии с прикладным протоколом)

• пользователь (человек)

  • вводит какой-либо документ, регламентируемый законодательством РФ, международным законодательством, внутренней учётной политикой в целях бухгалтерского и налогового учёта (НК РФ, ПБУ, 129-ФЗ «О бухгалтерском учёте»), иной внутрикорпоративной документацией («Document» )

  • вводит данные во внутреннюю экранную форму, не являющуюся формой ввода документа из п. 1 («Display» )

• собственно сама моделируемая ИС или её модули (в случае если информационная модель строится отдельно для подсистем ИС работающих по отдельности)

  • получает доступ к своим таблицам ( ), справочникам ( ), файлам ( ).

При построении модели в рамках неё можно выделить семь логических уровней (присутствие всех из них одновременно не обязательно и зависит от содержания процесса обработки информации):

1. источники информации ;

2. первичные документы или файлы ;

3. таблицы с первичными документами ;

4. таблицы с промежуточной информацией ;

5. таблицы с результатной информацией ;

6. результатные документы или файлы ;

7. получатели информации .

Далее приведён условный пример части информационной модели задачи по приёму оплаты за мобильную связь кассиром \ операционистом банка.

Область 1 отображает процесс конфигурирования ИС в части ввода пользователей ИС, которые необходимы в рамках задачи для того, чтобы можно было зафиксировать информацию о принявшем платёж сотруднике. Форма «Управление пользователями» предполагает выполнение двух видов операций:

• редактирование справочника прав пользователей (ролей);

• редактирование справочника пользователей.

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

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

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

• сначала делается запись (либо производится обновление записи) в справочнике клиентов. Под клиентом понимается ФИО плательщика и какие-либо его данные (например паспортные данные).

• затем делается запись, отражающая факт совершения платежа. В рамках задачи предполагается два варианта его совершения:

  • платёж принимается без открытия счёта;

  • платёж выполняется с какого-либо счёта; (связь со справочником лицевых счетов при изменении «Т* «Проводки»«);

• в любом случае платёж должен поступить какому-либо оператору, что отражается связью со справочником «Спр «ОператорыМобСв»«, откуда получается номер его счёта.

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

Область 4 отображает то, что моделируема ИС предоставляет на выходе:

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

  • Из справочника «Спр «Клиенты»« используем текстовое наименование клиента;

  • Из справочника «Спр «ОператорыМобСв»« получаем текстовое наименование оператора-получателя

  • Из таблицы «Т «Проводки»« остальные реквизиты платежа.

• клиент (в случае, если у него открыт счёт) может получить выписку по нему:

  • «Т «Остатки по л\счетам»« необходим, чтобы привести входящий и исходящий остатки на период выписки

  • «Спр «Лицевые счета»« - получение наименование счёта и срока его действия

  • «Т «Проводки»« - собственно операции

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

  • из «Спр «ОператорыМобСв»« получаем номер счёта оператора;

  • из «Т «Проводки»« - собственно операции

2.3.2. Характеристика нормативно-справочной, входной и оперативной информации

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

• при описании входных документов необходимо:

  • привести в приложении формы(макеты) документов и экранные формы для их ввода в систему;

  • привести перечень содержащихся в них первичных показателей;

  • привести источник получения документа;

  • описать структуру документа, число строк, объемные данные, частоту возникновения документа;

• при описании входных файлов необходимо:

  • привести перечень содержащихся в них первичных показателей;

  • привести источник получения файла;

  • описать структуру файла, объемные данные, частоту поступления файла;

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

• при описании справочников необходимо:

  • построить сводную таблицу, содержащую:

    • название справочника;

    • ответственного за его ведение;

    • средний объём справочника в записях;

    • среднюю частоту актуализации;

    • средний объем актуализации (в записях или в процентах);

  • по каждому справочнику необходимо описать его реквизитный состав.

2.3.3 Характеристика результатной информации

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

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

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

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

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

Для результатных файлов описывается:

• их структура и реквизитный состав;

• частота их формирования;

• на основе каких таблиц они формируются;

• каким способом доставляются до ИС – получателя файла.

2.4 Программное обеспечение задачи

2.4.1.Общие положения (дерево функций и сценарий диалога)

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

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

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

Пример фрагмента дерева функций

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

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

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

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

Пример фрагмента сценария диалога

2.4.2. Характеристика базы данных

ER модель предполагает определение состава и взаимосвязей таблиц, отражающих содержание информационной модели в терминах конкретной СУБД, выбранной в п.1.4.

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

Пример фрагмента описания структуры записей таблицы «Контрагенты»

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