Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9 | Следующая страница реферата

Целый ряд опросов, проведенных журналом «Банковские технологии», показал парадоксальную картину: среди банков-респондентов, имеющих АБС собственной разработки, довольных этой АБС оказалось значительно меньше, чем среди тех, кто работает на «фирменной» АБС. Объясняется это просто: во- первых, собственные системы в большинстве случаев выполнялись на тех же
FoxPro или Clipper; во-вторых, коллективы разработчиков, которых могут позволить держать у себя в штате банки, весьма немногочисленны; в-третьих, разработка ведется по принципу «латания дыр», что исключает системный подход и нормальное взаимодействие отдельных модулей. «Доморощенные» АБС очень трудно, да и практически невозможно, подвергнуть серьезной модернизации, так как нормальная документация проекта обычно не ведется.
Именно такие АБС скорее всего потребуют замены. Если какие-то банки еще питают иллюзии, что им удастся «довести до ума» подобную разработку собственными силами и в срок, и поэтому тянут с решением о переходе на АБС, созданную внешними фирмами, то их ожидают большие разочарования.

Совершенно очевидно, что многие банки будут вынуждены «менять коней на переправе», так как имеющиеся у них АБС неадекватны, и любые попытки как- то удержаться на старой платформе приведут к большим потерям. В этом случае следует помнить одно: переход на новый План счетов будет успешным только там, где вовремя проведена тщательная его организационная подготовка (жаль только, что методичность и скрупулезность не свойственны нашему национальному характеру). Руководство банка должно было уже в октябре составить и утвердить детальный план перехода, в котором следует четко распределить обязанности и ответственность подразделений и должностных лиц.
Этот план должен быть расписан по неделям, а с декабря — по дням, с соответствующей оперативной отчетностью.

Чтобы более нагляднее представить, что такое современная АБС, постараемся более подробно разобрать ее строение.

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

Архитектурное построение

Вся система состоит из трех компонентов:
1) клиентской части системы;

2) объектов сервера данных;

3) процедур сервера приложений.

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

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

На сервере приложенией выполняются специализированные AS-процедуры, которые вызываются по запросам от процедур сервера данных.

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

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

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

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

Системные объекты реализуют задачи “секретности” и управления доступом (этим правом обладает только уполномоченный оператор — так называемый “офицер безопасности”).

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

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

Рис. 1. Архитектура построения системы.

Все объекты на сервере данных создаются при инсталляции системы системным администратором. Этот процесс проходит в пакетном режиме, когда с клиента на сервер посылаются запросы на создание процедур и таблиц, а также на их заполнение.

Процедуры сервера приложений. Сервер приложений организуется средствами Open-Server Sybase. Он может функционировать на том же компьютере, что и сервер данных, но может быть реализован и на другом компьютере. Различают два вида процедур сервера приложений: первые из них отвечают за функционирование системы безопасности и управления доступом, вторые выполняют ту часть прикладных операций, которая неэффективно реализуется средствами сервера данных.

Независимо от назначения, все AS-процедуры вызываются только по запросам от хранимых процедур. Последние могут обращаться на сервер данных либо непосредственно к таблицам, используя запрос, динамически формируемый на AS-сервере, либо к внутренним хранимым процедурам, применяя средства
Open-Client Sybase.

Технологическое построение

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

Рис.2. Технологическое построение системы.

Рекомендуем скачать другие рефераты по теме: отчет по практике, рассказы.



Предыдущая страница реферата | 1  2  3  4  5  6  7  8  9 | Следующая страница реферата

Поделитесь этой записью или добавьте в закладки