Создание компонентной диаграммы

Допустим, что наступил момент, когда нужно генерировать коды для классов модели. Для определения компонентов исходного кода используют компонентное представление (Component View) (рис. 17.30). Среда Rational Rose автоматически создает главную компонентную диаграмму.

1. В окне браузера щелкнем по значку + слева от пакета Component View.

2. Для открытия главной компонентной диаграммы выполним двойной щелчок по значку Main.

В общем случае каждому классу должны соответствовать два компонента — компонент спецификации и компонент реализации. В будущем каждому компоненту будет соответствовать свой файл. Например, в языке C++ классу соответствуют два файла-компонента: h-файл (файл спецификации) и срр-файл (файл реализации).

В нашей модели мы создадим один компонент для представления файла спецификации по классу CourseOffering и один компонент для представления файла реализации по классу CourseOffering (рис. 17.31).

Эти файлы будут иметь расширения .ads и .adb соответственно. Файл .ads имеет стереотип Package Specification. Файл .adb имеет стереотип Package Body.

1. На панели инструментов щелкните по значку спецификации пакета Package Specification.

2. Для добавления компонента в диаграмму щелкните в нужном месте диаграммы.

3. Пока новый компонент остается выделенным, введите его имя — CourseOffering.

4. Повторите предыдущие шаги с использованием значка тела пакета Package Body.

5. На панели инструментов щелкните по значку отношения зависимости.

6. Щелкните по компоненту, представляющему .adb-файл (тело пакета), и перетащите стрелку на компонент, представляющий .ads-файл (спецификация пакета).

Рис. 17.30.Компонентное представление — Component View

Рис. 17.31.Компонентное представление

После создания компонентов им должны быть назначены классы модели (рис. 17.32).

1. Выполним двукратный щелчок по значку компонента CourseOffering, представляющего .ads-файл (спецификацию пакета), в окне браузера или компонентной диаграмме. В результате станет видимым окно спецификации компонента.

2. Выберите страницу (вкладку) Realizes. Вы увидете список классов модели.

3. Щелкните правой кнопкой по классу CourseOffering. В результате станет видимым контекстное меню.

4. Выберите команду Assign.

5. Закройте окно спецификации, нажав кнопку ОК.

6. Выполните аналогичные действия для тела пакета, представляющего .adb-файл.

Рис. 17.32.Назначение классов компоненту

Генерация программного кода

Команды для генерации кода на языке Ada 95 содержит пункт Toots главного меню (рис. 17.33).

1. На компонентной диаграмме выделите оба компонента CourseOffering.

2. Выберите команду Tools:Ada95: Code Generation из главного меню.

Итоги генерации кода отображаются в окне Code Generation Status (рис. 17.34).

Все ошибки заносятся в log-окно.

3. Для завершения процесса генерации кода нажмите кнопку Close.

Рис. 17.33. Меню Tools: генерация кода на языке Ada 95

Рис. 17.34.Статус генерации кода

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

Просмотрим код, сгенерированный средой Rational Rose.

Фрагмент содержания .ads-файла, отражающего спецификацию класса CourseOffering,представлен на рис. 17.35. Отметим, что в программный текст добавлено то описание, которое было внесено в модель через окно документации. Более того, система Rational Rose подготавливает код к многократной итеративной модификации, защите выполняемых изменений. Стандартный раздел программного кода имеет вид

--##begin module.privateDeclarations preserve=yes

--##end module.privateDeclarations

Рис. 17.35.Код спецификации класса, сгенерированный средой Rational Rose

Запись module.privateDeclarations обозначает имя раздела. Элемент preserve=(yes/no) говорит системе, можно ли при повторной генерации кода этот раздел изменять или нельзя. После генерации кода программный текст добавляется между операторами ##begin и ##end.

Соответственно, фрагмент содержания .adb-файла, отображающего тело класса CourseOffering, представлен на рис. 17.36.

Рис. 17.36.Код тела класса, сгенерированный Rational Rose

ЛЕКЦИЯ 14. Особенности информационных банковских
систем и технологий

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

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

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

Рассмотрим функциональные подсистемы ИБС. Они отражают одну из особенностей банковских систем - модульный принцип построения, который присущ большинству современных банковских систем.

Модульный принцип

Модульный принцип построения предусматривает разделение информационной банковской системы на ряд элементов по функциональному или объектному принципу. Эти элементы принято называть блоками или модулями, каждый из которых представляет собой программно-информационный модуль. Например, по функциональному принципу можно выделить следующие модули: операционный день банка (банковский учет), расчетно-кассовое обслуживание, кредитование, депозитарий и т.д.; по объектному принципу - модуль головного банка, филиала, отделения, представительства. Как правило, на практике чаще всего используется функциональное разделение, что позволяет пользователю связать отдельные модули в единую информационную систему, максимально отражающую специфику и потребности каждого банка. Однако набор модулей может варьироваться в зависимости от специфики банка, его направленности, масштаба деятельности, от перечня и характера операций, реально выполняемых банком.

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

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

Рассмотрим основные модули на примере системы автоматизации банковской деятельности (САБД) 5NT©BANK (рис. 1.2).

Рис. 1.2. Структура ИБС