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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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