Смекни!
smekni.com

Разработка корпоративной информационной системы на основе объектно-ориентированного подхода (стр. 8 из 11)

"сырые" данные, подготавливаемые для баз данных;

"летучие" данные, которые хранятся короткое время, а потом удаляются.

2.1.5. Реализация управления программным обеспечением

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

последовательное управление процедурами,

последовательное управление событиями,

параллельное асинхронное управление.

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

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

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

2.1.6. Пограничные ситуации

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

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

Терминация состоит в освобождении всех внешних ресурсов, занятых задачами системы.

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

2.1.7. Архитектур прикладных систем

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

системы пакетной обработки - обработка данных производится один раз для каждого набора входных данных;

системы непрерывной обработки - обработка данных производится непрерывно над сменяющимися входными данными;

системы с интерактивным интерфейсом - системы, управляемые внешними воздействиями;

системы динамического моделирования - системы, моделирующие поведение объектов внешнего мира;

системы реального времени - системы, в которых преобладают строгие временные ограничения;

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

типичной системой управления транзакциями является СУБД.

При разработке системы пакетной обработки необходимо выполнить следующие шаги:

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

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

Составляем объектную модель каждой фазы. Она имеет такую же структуру, что и модель всей системы в целом. Фаза разбивается на подфазы. Разрабатываем каждую подфазу.

Рисунок 2.3 - Система непрерывной обработки: машинная графика

При разработке системы непрерывной обработки необходимо выполнить следующие шаги:

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

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

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

При разработке системы с интерактивным интерфейсом необходимо выполнить следующие шаги:

Выделяем объекты, формирующие интерфейс.

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

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

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

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

По объектной модели определяем активные объекты; эти объекты имеют атрибуты с периодически обновляемыми значениями.

Определяем дискретные события; такие события соответствуют дискретным взаимодействиям объекта (например, включение питания) и реализуются как операции объекта.

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

Рисунок 2.4 - Система с интерактивным интерфейсом: БМ

Моделирование управляется объектами, отслеживающими временные циклы последовательностей событий.

Разработка системы реального времени аналогична разработке системы с интерактивным интерфейсом.

При разработке системы управления транзакциями необходимо выполнить следующие шаги:

Отображаем объектную модель на базу данных.

Определяем асинхронно работающие устройства и ресурсы с асинхронным доступом; в случае необходимости определяем новые классы.

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

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

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

Архитектура системы управления банковской сетью показана на рисунке 2.5. Система имеет три основных подсистемы: подсистему обслуживания БМ, подсистему консорциум и подсистему банк. Система имеет топологию звезды, в центре которой - подсистема консорциум, а на лучах - подсистемы БМ и банк (ясно, что в состав системы входит одна подсистема консорциум и по несколько подсистем БМ и банк).

Рисунок 2.5 - Архитектура системы управления банковской сетью

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

Асинхронная параллельность возникает в связи с необходимостью параллельного обслуживания нескольких независимо работающих БМ и кассовых терминалов. Каждый терминал может одновременно обслуживать только одну проводку (транзакцию), но каждая проводка связана также с центральным компьютером консорциума и компьютером одного из банков, которые должны одновременно обслуживать несколько проводок. Как видно из рисунка 2.5 каждая проводка распределена по трем устройствам, управляющее ее выполнением программное обеспечение состоит из трех частей; каждая из этих частей может быть реализована в виде отдельного класса.

2.2. Разработка объектов

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