1.2.1 Информационные модели. Пример.

1. 2. 1 Информационные модели

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

Рисунок 2 – Интеграция информации через управление метаданными

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

При построении информационной модели последняя должна отвечать следующим основным требованиям:

− адекватно отражать предметную область исследования;

− быть непротиворечивой;

− быть конечной;

− быть легко расширяемой;

− допускать композицию и декомпозицию;

− легко восприниматься разными категориями пользователей.

Пример.

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

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

На самом общем уровне можно сказать, что организация должна:

− принимать заявки на книги;

− проверять заявки;

− проверять платежеспособность заказчика;

− обеспечить отсылку заказных книг вместе с отчетом.

Это можно изобразить следующей логической схемой (рисунок 3).

Рисунок 3 – «Первый взгляд» ИТ-специалиста на деятельность организации

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

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

Рисунок 4 – Расширенный взгляд ИТ-специалиста на систему

К последним можно отнести:

− проверку входящих заявок на правильность указания заглавия и фамилии автора книги, а также уточнение платежеспособности заказчика;

− группировку корректной заявки с другими еще не выполненными заявками на книги одного издателя с целью получения оптимальной скидки на количество экземпляров.

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

Далее разработчик изучает порядок выполнения заявок. На практике наиболее распространена следующая схема:

− издатель с каждой посылкой высылает накладную, описывающую содержание посылки;

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

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

− выписываются накладные, которые будут сопровождать каждую посылку.

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

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

Рисунок 12 – Итоговая модель предметной области

Традиционная схема расчетов в организациях такого рода приведена на рисунке 6.

Рисунок 6 – Диаграмма потоков данных второго уровня, детализирующая процесс «Сопоставление платежа счета»

Она включает почти симметричные фрагменты расчетов с заказчиками книг и издателями:

1. Расчеты с заказчиками:

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

− каждый платеж (оплаченный счет) определенным образом обрабатывается (сопоставляются величины «выставлено-оплачено»), после чего принимаются те или иные управленческие решения;

2. Расчеты с издателями:

− организация принимает выставленные счета издателей и проверяет их на правильность;

− по каждому выставленному издателем счету формируется платеж (выписывается платежное поручение), который реализуется через банк.

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

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

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

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

Сущности, как правило, не показываются внутри границ детализируемых процессов, а выносятся за их пределы. На рисунке … приводится детализация процесса 8 «Сопоставление платежа и счета» при расчетах организации с заказчиком книг. Основные проблемы процесса 8 возникают при обработке неотслеженных платежей. Имеется в виду случай, когда в платеже не указано, к какому счету он относится. Процессы 8. 6, 8. 7 и 8. 9 отражают эту ситуацию. Для выяснения истины делается запрос заказчику, а информация о неотслеженном платеже записывается в накопитель D 8/1 до получения удовлетворительного объяснения. При этом платеж идентифицируется и все идет по «накатанной схеме», или заказчик приходит к выводу, что платеж проведен ошибочно и просит возвратить деньги.

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

Задание для самостоятельной работы:

1. Изучить краткую теорию к лабораторной работе.

2. Разработать информационную модель исследуемого предприятия в нотации DFD, используя средство моделирования бизнес-процессов BPWin.

3. Используя средство моделирования MS Visual Studio 2010 (UML) и результат выполнения задания 2 составить логическую модель для элемента Архитектура информации для модели AS-IS.

4. Используя средство моделирования MS Visual Studio 2010 (UML) и результат выполнения задания 2 составить физическую модель для элемента Архитектура информации для модели AS-IS.

5. Выявить и обосновать недостатки модели AS-IS.

6. Разработать информационную модель для модели TO-BE.

7. Оформить отчет и защитить у преподавателя.

⇐ Предыдущая 12