ВОЛЖСКИЙ  УНИВЕРСИТЕТ ИМ. ТАТИЩЕВА (ИНСТИТУТ)

КАФЕДРА «Промышленная информатика»
УТВЕРЖДАЮ

Проректор по учебной работе

__________ Никифорова Е.В.

от «____» _________ 2004 г.
РАЗРАБОТКА КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ НА ОСНОВЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА
Учебное пособие
по дисциплине «Корпоративные информационные системы»

для студентов специальности 071900 «Информационные системы»
дневного и заочного отделения
Тольятти 2004


Куралесова Н.О. Разработка корпоративной информационной системы на основе объектно-ориентированного подхода. Учебное пособие. –Тольятти: Волжский университет им.В.Н.Татищева, 2004
Рецензент: к.т.н., доцент кафедры «Информатика и системы управления»

                   Трубачева С.И.
Рассмотрено и утверждено на заседании кафедры

«Промышленная информатика»

«___»_______________2004 года

Протокол № ____ от «____» __________ 2004 г.




Содержание

1. Разработка модели автоматизации системы банковского обслуживания 1.1. Анализ требований и предварительное проектирование 1.2. Построение объектной модели 1.2.1. Определение объектов и классов 1.2.2. Подготовка словаря данных 1.2.3. Определение зависимостей 1.2.4. Уточнение атрибутов 1.2.5. Организация системы классов с использованием наследования 1.2.6. Усовершенствование модели 1.2.7. Определение подсистем 1.2.8. Интерфейсы и окружения 1.3. Динамическая модель системы или подсистемы 1.4. Функциональная модель подсистемы 1.4.1. Диаграммы потоков данных 1.4.2. Описание операций 1.4.3. Ограничения 2. Конструирование системы 2.1. Разработка архитектуры системы 2.1.1. Разбиение системы на модули 2.1.2. Выявление асинхронного параллелизма 2.1.3. Распределение модулей и подсистем по процессорам и задачам 2.1.4. Управление хранилищами данных 2.1.5. Реализация управления программным обеспечением 2.1.6. Пограничные ситуации 2.1.7. Архитектур прикладных систем 2.2. Разработка объектов 2.2.1. Совместное рассмотрение трех моделей 2.2.2. Разработка алгоритмов, реализующих полученные операции 2.2.3. Оптимизация разработки 2.2.4. Реализация управления 2.2.5. Уточнение наследования классов 2.2.6. Разработка зависимостей 3. Реализация объектно-ориентированного проекта

1. Разработка модели автоматизации системы банковского обслуживания

1.1. Анализ требований и предварительное проектирование

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

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

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




Рисунок 1.1 – Схема объектов автоматизации
Цель анализа - обеспечить правильную постановку и адекватное понимание рассматриваемой прикладной задачи, помочь убедиться, что предварительно спроектированная прикладная система сможет удовлетворить заказчика. Хороший анализ охватывает все существенные особенности задачи, не внося каких-либо реализационных особенностей в предварительный проект системы. Тем самым обеспечивается свобода реализационных решений на этапе реализации.

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

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

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

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

Для построения объектной модели рассматриваемой системы нам необходимо выполнить:

определение объектов и классов;

подготовка словаря данных;

определение зависимостей между объектами;

определение атрибутов объектов и связей;

организация и упрощение классов при использовании наследования;

дальнейшее исследование и усовершенствование модели.
1.2.1. Определение объектов и классов

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

БМ (банкомат)	Кассир	Программное обеспечение
Банк	Кассовый терминал	Система
Банковская_сеть	Квитанция	Проверка_безопасности
Данные_проводки	Клиент	Служба_ведения_записей
Данные_счета	Компьютер_банка	Счет
Деньги	Консорциум	Цена
Доступ	Пользователь	Центральный_компьютер
Карточка	Проводка

Исследуем этот список, исключая из него имена классов:

избыточные классы: т.к. клиент и пользователь означают одно и то же понятие; для банковской системы более естественно оставить класс клиент;

нерелевантные классы: таким классом является класс - цена (этот класс не имеет непосредственного отношения к работе банковской сети);

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

атрибуты: данные проводки, данные счета, деньги (имеются в виду реальные деньги, выдаваемые клиенту кассиром или банкоматом, либо принимаемые кассиром), квитанция (выдается клиенту вместе с деньгами) более естественно иметь в качестве атрибутов;

реализационные конструкции: например, программное_обеспечение и доступ.

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


1.2.2. Подготовка словаря данных

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

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

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

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

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

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

Клиент - держатель одного или нескольких счетов в банке. Клиент может состоять из одного или нескольких лиц, или организаций. То же самое лицо, держащее счет и в другом банке рассматривается как другой клиент.

Компьютер_банка - компьютер, принадлежащий банку, который взаимодействует с сетью БМ (банкоматов) и собственными кассовыми_терминалами банка. Банк может иметь свою внутреннюю компьютерную сеть для обработки счетов, но здесь мы рассматриваем только тот компьютер_банка, который взаимодействует с сетью БМ.

Консорциум - объединение банков, которое обеспечивает работу сети БМ (банкоматов). Сеть передает в консорциум проводки банков.

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

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

Центральный_компьютер - компьютер, принадлежащий консорциуму, который распределяет проводки и их результаты между БМ (банкоматами) и компьютерами_банков. Центральный_компьютер проверяет коды банков, но не выполняет проводок самостоятельно.
1.2.3. Определение зависимостей

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

Глагольные обороты (явные и неявные):

Банковская сеть включает кассиров и БМ

Консорциум распределяет результаты проводок по БМ

Банк владеет компьютером банка

Компьютер банка поддерживает счета

Банк владеет кассовыми терминалами

Кассовый терминал взаимодействует с компьютером банка

Кассир вводит проводку над счетом

БМ взаимодействуют с центральным компьютером во время проводки

Центральный компьютер взаимодействует с компьютером банка

БМ принимает карточку

БМ общается с пользователем

БМ выдает наличные деньги

БМ печатает квитанции

Система регулирует коллективный доступ

Банк предоставляет программное обеспечение

Консорциум состоит из банков

Консорциум владеет центральным компьютером

Система обеспечивает протоколирование

Система обеспечивает безопасность

Клиенты имеют карточки

Карточка обеспечивает доступ к счету

В банке служат кассиры

Затем исключаем ненужные или неправильные зависимости:

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

нерелевантные зависимости и зависимости, связанные с реализацией: зависимость «Система регулирует коллективный доступ» исключается как связанная с реализацией;

действия описываются такими зависимостями как «БМ принимает карточку» и «БМ общается с пользователем»; мы исключаем эти зависимости;

тренарные зависимости: зависимость «Кассир вводит проводку над счетом» раскладывается на две бинарные зависимости «Кассир вводит проводку» и «Проводка относится к счету». Зависимость «БМ взаимодействуют с центральным компьютером во время проводки» раскладывается на «БМ взаимодействуют с центральным компьютером» и «Проводка начинается с БМ»;

производные зависимости: зависимость «Консорциум распределяет БМ» является следствием зависимостей «Консорциум владеет центральным компьютером» и «БМ взаимодействуют с центральным компьютером».

Удалив избыточные зависимости, получим следующий список зависимостей:

Банк владеет компьютером банка

Компьютер банка поддерживает счета

Банк владеет кассовыми терминалами

Кассовый терминал взаимодействует с компьютером банка

Кассир вводит проводку

Проводка относится к счету

БМ взаимодействуют с центральным компьютером

Проводка начинается с БМ

Центральный компьютер взаимодействует с компьютером банка

Консорциум состоит из банков

Консорциум владеет центральным компьютером

Клиенты имеют карточки

Карточка обеспечивает доступ к счету

В банке служат кассиры

Уточним семантику оставшихся зависимостей следующим образом:

переименуем неверно названные зависимости, чтобы смысл их стал более понятен; так зависимость «Компьютер_банка поддерживает счета» удобнее заменить зависимостью «Банк держит счета».

имена ролей можно не использовать, например, зависимость «БМ взаимодействуют с центральным компьютером»;

неучтенные зависимости: «Проводка начинается с кассового_терминала», «Клиенты имеют счета», «Проводка регистрируется карточкой» следует добавить в модель.

После уточнения зависимостей можно составить начальную объектную диаграмму (рис. 1.2).


Рисунок 1.2 -  Первая версия объектной диаграммы для банковской сети
1.2.4. Уточнение атрибутов

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

После внесения перечисленных изменений диаграмма примет вид, представленный на рис 1.3
1.2.5. Организация системы классов с использованием наследования

В рассматриваемом примере естественно определить суперклассы для объектов, определяющих различные терминалы: кассовый_терминал и БМ (банкомат), и для объектов, определяющих проводки: проводка_кассира и удаленная_проводка (с банкомата).

Внеся соответствующие изменения, получим объектную диаграмму, представленную на рисунке 1.4.



Рисунок 1.3 - Объектная диаграмма для банковской сети после уточнения атрибутов и добавления квалификаторов


Рисунок 1.4 - Объектная диаграмма для банковской с учетом наследования
1.2.6. Усовершенствование модели

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

Класс проводка удобно представить как агрегацию классов изменение, так как проводка - это согласованная последовательность внесения изменений в счета и другие банковские документы; при работе с банковскими документами рассматривается три вида изменений: снятие, помещение и запрос.

Класс банк естественно объединить с классом компьютер_банка, а класс консорциум - с классом центральный_компьютер.



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

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

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

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

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

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

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

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

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

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


Рисунок 1.6 -  Объектная диаграмма банковской сети, в которой указан интерфейс с системным окружением


Рисунок 1.7 - Объектная диаграмма банковской сети и ее системного окружения
1.2.8. Интерфейсы и окружения

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

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

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

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

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


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

3. Реализация объектно-ориентированного проекта

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

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

В объектно-ориентированной программе действия выполняются путем создания объектов и вызова методов объектов. Однако какое-то действие должно начать этот процесс. В языке Си++ программа начинает выполняться со специальной функции main. Эта функция может вызвать другие функции и создать какие-либо объекты, которым она может передать сообщения.

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

Данный фрагмент программы реализует два вида счетов - расчетный счет (класс CheckingAccount) и депозитный счет (класс DepositAccount) - с помощью наследования из базового класса Account.

Класс Account - это абстрактный класс с чисто виртуальным методом GetAccountTypc. Кроме того, он задает общие для всех порожденных из него классов методы- Deposit, Withdraw и Balance. Вызывая эти методы, программы, работающие с базовым классом, будут использовать ограниченный полиморфизм.

Атрибут amount - остаток на счету - помещен в защищенную часть класса для того, чтобы порожденные классы могли с ним работать. Атрибут accountNumber - номер счета - помещен во внутреннюю часть класса, поскольку базовый класс полностью контролирует создание уникальных номеров счетов.
//

// Класс Account - базовый класс для всех типов счетов

//

class Account

{

// внешняя часть класса, его интерфейс

public:

// перечисление всех возможных типов счетов

enum AccountType ( CHECKING, DEPOSIT );

Account() ( amount = 0; );                  // Создание пустого счета

Account(long _accountNumber);       // Создание объекта для

// имеющегося счета

virtual ~Account() ;

// Хотя класс Account абстрактный, он проводит

// стандартные реализации методов "положить на счет"

// (Deposit), "снять со счета" (Withdraw) и

// "остаток на счете" (Balance), хотя они могут быть

// переопределены в порожденных классах

virtual void Deposit(float _amount);             //Положить на счет

virtual bool Withdraw(float _ainount);          //Снять со счета

virtual float Balance(void) const;        //Остаток на счете

// Метод GetAccountType возвращает тип конкретного счета

// и определен только в порожденных классах

virtual AccountType GetAccountType(void) consfc = 0;

// Узнать номер счета

long GetAccountNumber(void) const

{ return accountNumber; } ;

// Защищенная часть класса доступна порожденным классам

protected:

float amount;             // Атрибут - сумма на счете

// Внутренняя часть класса

private:

long accountNumber;    // Атрибут - номер счета

};
Класс DatabaseObject - абстрактный класс, который задает интерфейс для сохранения и восстановления объектов в базе данных. Порожденные из него классы обязаны определить два метода: Save - для сохранения самого себя в базе данных, и Restore - для восстановления состояния из базы данных. В данном классе показано, что в абстрактном классе могут задаваться конкретные методы (MarkModifled, IsModifled, GetDatabaseConnection). Если первые два метода относятся к интерфейсу класса, то третий - это защищенный метод, необходимый для реализации методов Save и Restore в порожденных классах. (Мы исходим из предположения, что операции с базой данных требуют установления соединения с базой данных через объект типа DBConnection, который и возвращает метод GetDatabaseConnection.)

//

// Базовый класс для всех'объектов,

// которые могут храниться в базе данных

//

class DatabaseObject

{

public:

DatabaseObject () :niodifiedFlag( false) {}

virtual ~DatabaseObject() ;

virtual boot Save(void) = 0;

virtual boot Restore(void) = 0;

// Два дополнительных метода устанавливают или проверяют

// признак того, что объект был модифицирован и должен

// быть сохранен в базе данных

void MarkModified(void) ;

boot IsModified(void) const;

protected:

DBConnection* GetDatabaseConnection(void);

private:

boot modifiedFlag;

};
Два следующих класса: CheckingAccount и DepositAccount - это конкретные классы, реализующие два типа счетов - расчетный счет и депозит. Они используют множественное наследование. В качестве базовых классов выступают классы Account и DatabaseObject. Класс Account задает интерфейс и стандартную реализацию свойств счета, а класс DatabaseObject - необходимый интерфейс для хранения объектов в базе данных.
//

// Класс Расчетный счет - конкретный счет, который

// может храниться в базе данных

//

class CheckingAccount : public Account, DatabaseObject

{

public:

CheckingAccount() {} ;

CheckingAccount(long _accountNumber) •;

Account (_accountNuinber) {} ;

// При конструировании нового объекта данного

// класса мы вначале конструируем его

// базовую часть

virtual ~CheckingAccount ();

// Класс переопределяет метод снятия со счета, потому

// что имеется требование минимального остатка на счете,

// оставляя неизменными методы "положить на счет"

//и "проверить остаток"

virtual boot Withdraw(float _amount);

// Метод GetAccountType определен и возвращает тип

// счета - расчетный счет

virtual AccountType GetAccountType(void) const

( return CHECKING;) ;

// Поскольку объекты данного класса можно хранить

//в базе данных - класс выведен из DatabaseObject,

//в нем определяются методы Save и Restore для

// сохранения и восстановления из базы данных
virtual boot Save(void) ;

virtual boot Restore(void) ;

private:

// Класс определяет один дополнительный атрибут

//минимальный остаток на счете

float minBalance;

};
//

// Класс счет-депозит, аналогичный предыдущему

// расчетному счету

//

class DepositAccount : public Account, DatabaseObject

{

DepositAccount() {}; ,

DepositAccount (long _accountNurnber) :

Account (_accountNuinber) {};

virtual ~DespositAccount() ;

// Класс переопределяет метод снятия со счета и метод

// "положить на счет", потому что имеется ограничение,

//в какие сроки можно их производить,

// метод "проверить остаток" также переопределен,

// поскольку на сумму начисляется процент

virtual void Deposit(float _amount);

virtual boot Withdraw(float amount);

virtual float Balance(void) const;

// Метод GetAccountType определен и возвращает тип

// счета - депозит

virtual AccountType GetAccountType(void) const

( return DEPOSIT;);

// Поскольку объекты данного класса можно хранить

//в базе данных - класс выведен из DatabaseObject,

// в нем определяются методы Save и Restore для

// сохранения и восстановления из базы данных

virtual boot Save(void) ;

virtual boot Restore(void) ;

// Два дополнительных метода определяют, прошел ли срок

// депозита и каков процент на этот вклад

bool IsMature(void) const;

float GetInterestRate(void) const;

private :

// Два дополнительных атрибута хранят срок

// депозита и процент на этот вклад

Date maturityDate;

float interestRate;

};
Класс AccountFactory - это пример использования понятия фабрики объектов в языке Си++. Фабрика объектов - это класс, результатом вызова метода которого являются новые объекты другого класса. Хотя непосредственно новые объекты создаются с помощью вызова оператора new, фабрика объектов позволяет инкапсулировать процесс создания объектов разных конкретных классов (CheckingAccount, DepositAccount) в одном статическом методе CreateAccount.

Кроме того, этот класс иллюстрирует статические (static) методы класса. Эти методы не требуют объекта для своего выполнения, Они выполняются от имени класса. Таким образом, класс AccountFactory эмулирует метакласс, поскольку «настоящие» метаклассы отсутствуют в Си++.
//

// Класс AccountFactory используется для создания

// новых счетов

//

class AccountFactory

{

public:

// метод CreateAccount создает новый счет определенного

// типа с начальным вкладом _initialAmount, процентом

//по вкладу _interestRate и сроком _maturityDate.

// Последние два аргумента необязательны и не

// задаются для расчетных счетов

static Account* CreateAccount(Account::AccountType _t,

float _initialAmount,

float _interestRate = 0,

Date _maturityDate ^e «»);

// Глобальный метод GetNewAccountNumber

// генерирует новые, уникальные номера счетов

static long GetNewAccountNumber(void);

}:




Литература
1.                       Иванова Г.С. Технология программирования: Учебник для вузов. –2-е изд., степеотип. –М.:Изд-во МГТУ им Н.Э.Баумана, 2003.

2.                       Корпоративные системы на основе CORBA. Пер. с англ. : Уч.пос. –М.:Издательский дом «Вильямс», 2000.

3.                       Ларман К. Применение UML и шаблонов проектирования. М.:Издательский дом «Вильямс», 2001.

4.                       Мацяшек Л.А. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. Пер. с англ. –М.: Издательский дом «Вильямс», 2002