Развитие архитектурного процесса

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

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

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

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

Это можно изобразить следующей логической схемой (рис. 2.13). Заметим, что здесь используется графический язык диаграмм потоков данных, описание которого приведено в приложении 3. Естественно, что ИМО столь высокого уровня абстракции для дела реинжиниринга бизнес-процессов или разработки информационной системы является почти бесполезной.

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

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

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

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

Рис. 2.14. Расширение взгляда ИТ-специалиста на систему

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

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

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

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

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

Схема выполнения заявок

Рис. 2.15. Схема выполнения заявок

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

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

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

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

Итоговая модель предметной области

Рис. 2.16. Итоговая модель предметной области

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

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

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

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

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

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

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

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

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >