Загрузка...
Учебная работа. Учебное пособие: Разработка корпоративной информационной системы на основе объектно-ориентированного подхода
КАФЕДРА «Промышленная информатика»
УТВЕРЖДАЮ
Проректор по учебной работе
__________ Никифорова Е.В.
от «____» _________ 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. Совместное рассмотрение 3-х моделей
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-го либо нескольких счетов в банке. клиент может состоять из 1-го либо нескольких лиц, либо организаций. То же самое лицо, держащее счет и в другом банке рассматривается как иной клиент.
Компьютер_банка — комп, принадлежащий банку, который ведет взаимодействие с сетью БМ (банкоматов) и своими кассовыми_терминалами банка. сеть для обработки счетов, но тут мы рассматриваем лишь тот комп_банка, который ведет взаимодействие с сетью БМ.
Консорциум — объединение банков, которое обеспечивает работу сети БМ (банкоматов). сеть передает в консорциум проводки банков.
Проводка — единичный встроенный запрос на выполнение некой последовательности операций над счетами 1-го клиента. Было изготовлено предположение, что БМ (банкоматы) лишь выдают средства, но для их не следует исключать способности печати чеков либо приема средств и чеков.
Счет — единичный банковский счет, над которым производятся проводки. Счета могут быть разных типов; клиент может иметь несколько счетов.
Центральный_комп — комп, принадлежащий консорциуму, который распределяет проводки и их результаты меж БМ (банкоматами) и компьютерами_банков. Центральный_комп инспектирует коды банков, но не делает проводок без помощи других.
1.2.3. Определение зависимостей
Выделим очевидные и неявные глагольные обороты из подготовительной постановки задачки, рассматривая их как имена вероятных зависимостей.
Глагольные обороты (очевидные и неявные):
Банковская сеть
кассиров и БМ
Консорциум
результаты проводок по БМ
время проводки
Центральный комп
с компом банка
БМ
карточку
БМ
с юзером
БМ
наличные средства
БМ
квитанции
Система
коллективный доступ
Консорциум
банков
Консорциум
центральным компом
Система
протоколирование
Система
сохранность
Клиенты
карточки
Карточка
к счету
В банке
кассиры
Потом исключаем ненадобные либо некорректные зависимости:
исключаются последующие зависимости: Банковская сеть
кассиров и БМ (класс банковская_сеть исключен), БМ
квитанции (класс квитанция исключен), БМ
наличные средства (класс средства исключен), Система
протоколирование проводок (класс служба_ведения_записей исключен), Система
сохранность ведения счетов (класс служба_безопасности исключен), Банки
программное обеспечение (класс программное_обеспечение исключен);
зависимость «Система
коллективный доступ» исключается как сплетенная с реализацией;
описываются таковыми зависимостями как «БМ
карточку» и «БМ
с юзером»; мы исключаем эти зависимости;
зависимость «Кассир
проводку над счетом» раскладывается на две бинарные зависимости «Кассир
проводку» и «Проводка
счету». Зависимость «БМ
с центральным компом во время проводки» раскладывается на «БМ
с центральным компом» и «Проводка
БМ»;
зависимость «Консорциум
БМ» является следствием зависимостей «Консорциум
центральным компом» и «БМ
с центральным компом».
Удалив лишниие зависимости, получим последующий перечень зависимостей:
комп
с компом банка
Консорциум
банков
Консорциум
центральным компом
Клиенты
карточки
Карточка
к счету
В банке
кассиры
Уточним семантику оставшихся зависимостей последующим образом:
ошибочно нареченные зависимости, чтоб смысл их стал наиболее понятен; так зависимость «Компьютер_банка
счета» удобнее поменять зависимостью «Банк
счета».
можно не применять, к примеру, зависимость «БМ
с центральным компом»;
«Проводка
с кассового_терминала», «Клиенты
счета», «Проводка
карточкой» следует добавить в модель.
Опосля уточнения зависимостей можно составить исходную объектную диаграмму (рис. 1.2).
Набросок 1.2 — 1-ая версия объектной диаграммы для банковской сети
1.2.4. Уточнение атрибутов
Карточка содержит код_банка и код_карточки; их можно считать атрибутами объектов класса карточка, но удобнее применять в качестве квалификаторов, потому что код_банка обеспечивает выбор банка, сокращая кратность зависимости Консорциум — банк; для аналогичного использования кода_карточки нужно добавить зависимость системы классов с внедрением наследования
В рассматриваемом примере естественно найти суперклассы для объектов, определяющих разные терминалы: кассовый_терминал и БМ (банкомат), и для объектов, определяющих проводки: проводка_кассира и удаленная_проводка (с банкомата).
Внеся надлежащие конфигурации, получим объектную диаграмму, представленную на рисунке 1.4.
Набросок 1.3 — Объектная диаграмма для банковской сети опосля уточнения атрибутов и прибавления квалификаторов
Набросок 1.4 — Объектная диаграмма для банковской с учетом наследования
1.2.6. Усовершенствование модели
Карточка выступает в 2-ух сущностях: как регистрационная единица в банке (сберкнижка), обеспечивающая клиенту доступ к его счетам, и как структура данных, с которой работает БМ. Потому комфортно расщепить класс карточка на два класса: регистрация_карточки и карточка; 1-ый из этих классов обеспечивает клиенту доступ к его счетам в банке, а 2-ой описывает структуру данных, с которой работает БМ.
Класс проводка комфортно представить как агрегацию классов изменение, потому что проводка — это согласованная последовательность внесения конфигураций в счета и остальные банковские документы; при работе с банковскими документами рассматривается три вида конфигураций: снятие, помещение и запрос.
Класс банк естественно соединить с классом комп_банка, а класс Консорциум — с классом центральный_комп.
Набросок 1.5 — Окончательный вид объектной диаграммы для банковской сети
Опосля внесения перечисленных конфигураций объектная диаграмма воспримет вид, представленный на рисунке 1.5. На этом построение объектной модели шага подготовительного проектирования завершается. Последующие уточнения объектной модели будут выполняться на последующих фазах актуального цикла системы.
1.2.7. Определение подсистем
Любой объект характеризуется набором атрибутов, значения которых определяют состояние объекта, и набором операций, которые можно использовать к этому объекту. При разработке прикладных систем комфортно считать, что все атрибуты объектов являются закрытыми (т.е. они не доступны вне объекта, и для того, чтоб в неком объекте выяснить одной из открытых операций этого объекта, если, естественно, таковая операция определена). Операции объектов могут быть как открытыми, так и закрытыми.
Таковым образом, любой объект имеет строго определенный
, т.е. набор открытых операций, которые можно использовать к этому объекту. Все объекты 1-го класса имеют однообразный интерфейс. Интерфейс класса (для всякого объекта этого класса) задается перечнем сигнатур его открытых (общедоступных) операций (и реализующих их способов); сигнатуры закрытых операций в интерфейс объектов соответственного класса не входят.
Объектная модель системы задает огромное количество взаимозависимых объектов, составляющих систему, и, как следует, описывает набор интерфейсов, доступных снутри системы. Все способности по обработке данных снутри системы (т.е. в любом объекте, входящем в состав системы) определяются сиим набором интерфейсов, который описывает внутреннее свита (либо среду) системы.
Вместе с внутренним окружением системы можно найти ее наружное свита. Оно определяется функциями (операциями), реализованными в составе системного программного обеспечения (т.е. операционной системы, системы программирования, разных редакторов, системы управления базами данных и т.п.), также в остальных прикладных системах и библиотеках, применяемых вместе с системой. Объекты и операции, составляющие наружное свита системы, тоже могут быть доступны снутри системы. Чтоб не упустить этого из виду, можно было бы добавить в объектную модель еще один объект, интерфейс которого представлял бы способности наружного окружения, применяемые в системе (таковой интерфейс обычно представляет только часть способностей наружного окружения). Но это было бы не совершенно буквально, потому что наружное свита реализуется не одним, а несколькими объектами. Выход из обозначенного противоречия во внедрении в рассмотрение еще одной сути — подсистемы.
— это набор объектов и подсистем, обеспечивающих некую функциональность, и взаимодействующих меж собой в согласовании с их интерфейсами.
представляет собой подмножество объединения интерфейсов всех объектов и подсистем, составляющих эту подсистему. В состав подсистемы может заходить один, либо наиболее взаимозависимых объектов и/либо подсистем.
Огромное количество интерфейсов объектов (и подсистем), которые в собственной совокупы составляют некую подсистему, составляет
данной подсистемы. В состав каждой подсистемы обязана быть включена подсистема свита, представляющая
данной подсистемы. Подсистема свита для системы банковского обслуживания, рассматриваемой в качестве сквозного примера представлена на рисунке 1.6. интерфейс подсистемы свита описывает в котором программном окружении будет работать проектируемая система и какие способности этого окружения будут употребляться во время ее работы (это принципиально, когда возникает Потребность модификации либо подмены отдельных компонент окружения).
Отметим, что подсистема свита представляет лишь интерфейс системы банковского обслуживания с ее наружным окружением. Наружное свита системы банковского обслуживания состоит из нескольких подсистем и библиотек, и для него тоже быть может разработана объектная модель, которая может содержать и разрабатываемую систему (в данной объектной модели она будет одной из подсистем).
Объектную модель системы банковского обслуживания и ее системного (наружного) окружения тоже можно изобразить в виде объектной диаграммы (правда, в состав данной объектной диаграммы будут заходить не объекты, а лишь подсистемы; любая подсистема изображается на диаграмме в виде прямоугольника с двойными вертикальными сторонами). Зависимости меж подсистемами, изображенные на данной объектной диаграмме (набросок 1.7), отражают взаимодействие проектируемой системы банковского обслуживания и соответственных подсистем в процессе работы системы. Тем определяются требования проектируемой системы к ее системному окружению.
Введение понятия подсистемы и возможность включать в объектную модель вместе с объектами (классами) и подсистемы описывает иерархическую структуру объектной модели и дозволяет применять методологию OMT при проектировании довольно сложных программных систем, содержащих огромное число разных объектов и классов.
Набросок 1.6 — Объектная диаграмма банковской сети, в какой указан интерфейс с системным окружением
Набросок 1.7 — Объектная диаграмма банковской сети и ее системного окружения
1.2.8. Интерфейсы и окружения
Объекты и подсистемы, составляющие подсистему наиболее высочайшего уровня, будем именовать
крайней. Как уже было отмечено, для всякого компонента, входящего в состав объектной модели подсистемы, определен его
, т.е. набор открытых (общедоступных) операций, которые можно использовать к этому компоненту (объекту либо подсистеме).
интерфейс объекта определяется интерфейсом соответственного класса и задается перечнем сигнатур его открытых операций (способов). интерфейс подсистемы определяется через интерфейсы составляющих ее объектов и подсистем последующим образом: операция быть может включена в интерфейс подсистемы, если в составе данной подсистемы имеется объект (подсистема), интерфейс которого содержит эту операцию. Интерфейсы описываются на языке описания интерфейсов IDL (Interface Definition Language).
Все способности по обработке данных снутри подсистемы определяются набором интерфейсов ее компонент, которые определяют внутреннее свита подсистемы.
Если для некой подсистемы оказывается, что ни один ее компонент не содержит операции, которую лучше включить в ее интерфейс, в ее состав можно добавить объект, реализующий такую операцию. Таковой объект именуется
. Интерфейсные объекты разрешают согласовать наружный интерфейс подсистемы с ее наружным окружением, т.е. с интерфейсами остальных объектов и подсистем, которые вкупе с рассматриваемой подсистемой составляют подсистему наиболее высочайшего уровня.
В составе системы банковского обслуживания можно выделить подсистему несколько экземпляров подсистемы банк — по одной для всякого банка, входящего в Консорциум). При всем этом объектная модель системы воспримет вид, изображенный на рисунке 1.8.
Набросок 1.8. — Объектная диаграмма банковской сети опосля выделения подсистемы Консорциум образуют внутреннее свита системы банковского обслуживания. Ее наружное свита состоит из наружных интерфейсов разных программных систем, применяемых в системе банковского обслуживания (на рисунке показана только часть этих систем), и ее собственного наружного интерфейса.
1.3. Динамическая модель системы либо подсистемы
Объектная модель представляет статическую структуру проектируемой системы (подсистемы). Но познания статической структуры недостаточно, чтоб осознать и оценить работу подсистемы. Нужно иметь средства для описания конфигураций, которые происходят с объектами и их связями во время работы подсистемы. Одним из таковых средств является динамическая модель подсистемы. Она строится опосля того, как объектная модель подсистемы построена и за ранее согласована и отлажена. Динамическая модель подсистемы состоит из диаграмм состояний ее объектов и подсистем.
Текущее состояние объекта характеризуется совокупой текущих значений его атрибутов и связей. Во время работы системы, составляющие ее объекты, ведут взаимодействие друг с другом, в итоге что меняются их состояния. Единицей воздействия является событие: каждое событие приводит к смене состояния 1-го либо нескольких объектов в системе, или к появлению новейших событий. Работа системы характеризуется последовательностью происходящих в ней событий.
Событие происходит в некий момент времени (часто оно употребляется для определения соответственного момента времени).
Одно из событий может логически предшествовать другому, или следовать за остальным, или они могут быть независящими; к примеру, начало проводки и выдача средств клиенту (в итоге данной проводки), проводки, запущенные с различных БМ, и т.п. Если действия не имеют причинной связи (т.е. они логически независимы), такие действия не влияют друг на друга. Действия передают информацию с 1-го объекта на иной.
Сценарием именуется последовательность событий, которая может иметь пространство при определенном выполнении системы. Сценарии могут иметь различные области воздействия: они могут включать все действия, происходящие в системе, или лишь действия, возникающие и действующие лишь на определенные объекты системы.
Последующим шагом опосля разработки и анализа сценариев является определение объектов, генерирующих и принимающих каждое событие сценария. Последовательности событий с привязкой к объектам проектируемой системы комфортно представлять на диаграммах, именуемых трассами событий. Вертикальные полосы изображают на данной диаграмме объекты, а горизонтальные стрелки — действия (стрелка начинается в объекте, генерирующем событие, и завершается в объекте, принимающем событие). Наиболее поздние действия помещены ниже наиболее ранешних, одновременные — на этом же уровне.
состояние определяется совокупой текущих значений атрибутов и связей объекта. к примеру, состояние описывает реакцию объекта на поступающее в него событие. Реакция объекта на событие может включать некое действие и/либо перевод объекта в новое состояние.
объект сохраняет свое состояние в течение времени меж 2-мя поочередными событиями, которые он воспринимает: действия представляют моменты времени, состояния — отрезки времени; состояние имеет длительность, которая обычно равна отрезку времени меж 2-мя поочередными событиями, принимаемыми объектом, но время от времени быть может больше.
При определении состояний мы не рассматриваем тех атрибутов, которые не влияют на время работы системы событиям. Для этого в диаграмму состояний врубаются описания активностей и действий.
Активностью именуется операция, сплетенная с любым состоянием объекта (она производится, когда объект попадает в обозначенное состояние); выполнение активности просит определенного времени. Активность связана с состоянием, потому на диаграмме состояний она обозначается через «do: имя_активности» в узле, описывающем соответственное состояние (рис.1.9).
Набросок 1.9 — Указание активностей и действий на диаграмме состояний
Действием именуется моментальная операция, сплетенная с событием: при появлении действия происходит не только лишь переход объекта в новое состояние, да и производится действие, связанное с сиим событием.
Деяния могут также представлять внутренние операции управления объекта, к примеру, присваивание значений атрибутам либо генерация остальных событий.
В системах, состоящих из нескольких параллельно работающих объектов, нужно согласовать (синхронизировать) их работу. Для этого употребляются действия, потому что синхронизация по существу состоит в необходимости задержать переход 1-го из синхронизируемых объектов в еще одно состояние, пока иной объект не придет в некое фиксированное состояние, а переходы из состояния в состояние управляются событиями. Синхронизирующее событие может вырабатываться в любом из синхронизируемых объектов, или в каком-либо 3-ем объекте.
Если синхронизирующее событие вырабатывается вне синхронизируемого объекта, оно быть может передано ему из другого объекта; на диаграмме это обозначается, как показано на рисунке 1.10.
Набросок 1.10. — Передача действия из 1-го объекта другому
Если объект получает действия из нескольких независящих объектов, то состояние, в которое он перейдет, может зависеть от порядка, в каком будут получены эти действия (а этот порядок случаен, потому что объекты независимы). Это именуется условием конкуренции. одной из задач проектирования является исключение ненужных критерий конкуренции, что достигается при помощи синхронизации.
синхронизация употребляется и в случае, когда в каком-либо состоянии требуется параллельно выполнить несколько активностей. Разглядим устройство вывода БМ (набросок 1.11). Оно сразу (параллельно) выдает наличные средства и карточку; обе эти операции можно разглядывать как составную активность, состоящую из 2-ух параллельно работающих активностей (пунктирная линия на диаграмме состояний разделяет состояние на две области, в каждой из которых производится одна из обозначенных активностей). Разделение управления на два параллельных потока схематически показано в виде стрелки, которая делится на две: событие «готов» вызывает переход из состояния «установка» сходу в два параллельных под состояния: состояния «выдача» и «выкинуть»; переход в последующее состояние происходит по двум событиям «средства взяты» и «карточка взята»; если какое-либо из этих событий произойдет ранее другого, перехода все равно не будет, пока не произойдет и 2-ое событие (в этом и состоит синхронизация). Из рассмотренного примера видно, что в разных состояниях может параллельно работать различное число действий (активностей).
Построим динамическую модель банковской сети. Исходный сценарий:
БМ просит
вставить карточку
вставляет
БМ воспринимает
и читает ее
БМ просит ввести
вводит «1234»
БМ передает
и
в
,
инспектирует
и
, описывает код
— «39» и докладывает БМ, что запрос
БМ просит клиента (при помощи меню на дисплее) избрать вид проводки(
)
выбирает
БМ спрашивает
какова требуемая сумма
вводит $100
БМ убеждается, что введенная сумма в границах
и просит
выполнить проводку,
передает запрос в
БМ выдает сумму и просит
взять ее
берет средства
БМ спрашивает, не надо ли
что еще
вводит
БМ печатает счет, выдает
и просит клиента взять их
берет счет и карточку
БМ просит (другого)
ввести карточку.
Исходный сценарий обслуживания клиента в банковской сети; один из вероятных сценариев, содержащих исключительные ситуации, к примеру:
БМ просит клиента вставить карточку,
вставляет карточку
БМ воспринимает карточку и читает ее номер
БМ просит ввести пароль,
вводит «9999.»
БМ передает номер и пароль в
;
, проконсультировавшись с подходящим
, отторгает запрос
БМ докладывает, что пароль введен
вводит «1234.»
БМ передает номер и пароль в
,
инспектирует номер и пароль, описывает код банка — «39» и докладывает БМ, что запрос принят
БМ просит избрать вид проводки,
выбирает
БМ спрашивает, какова требуемая сумма
(раздумав брать средства) набирает
БМ выдает карточку и просит клиента взять ее
берет карточку
БМ просит (другого) клиента вставить карточку.
Для всякого сценария можно составить подобающую трассу событий (набросок 1.12). Для этого выделяем в сценарии имена событий (событиями являются все сигналы, вводы данных, решения, прерывания, переходы и деяния, выполняемые клиентом либо наружными устройствами), указывая для всякого действия объект, порождающий это событие (активный объект).
Имея трассы событий, можно выстроить диаграммы состояний объектов проектируемой системы. Банковская сеть есть агрегация определенного числа параллельно и независимо работающих объектов 4 классов: Консорциум, банк, БМ (банкомат) и клиент; потому состояние банковской сети определяется как кортеж состояний составляющих ее объектов:
объекта класса Консорциум,
объектов класса банк,
объектов класса БМ (банкомат) и
объектов класса клиент (
— количество БМ, банков и клиентов сети соответственно). систематизация объектов, применяемая при объектно-ориентированном подходе, дозволяет заместо
диаграмм состояний выстроить всего три (диаграммы состояний клиентов строить не надо, потому что их текущее состояние ясно и так).
Построение диаграмм состояний начинается с привязки событий к объектам банковской сети (набросок 1.13), являющимся источниками этих событий. Поначалу рассматриваются обычные действия, позже исключительные действия. Построение диаграммы состояний объекта (класса) может считаться законченным, когда диаграмма обхватывает все рассматриваемые сценарии. Диаграммы состояний объектов классов БМ (набросок 1.14), Консорциум (набросок 1.15) и банк (набросок 1.16).
Набросок 1.13 — Привязка событий к объектам банковской сети
Набросок. 1.14 — Диаграмма состояний объектов класса БМ
Набросок 1.15 — Диаграмма состояний объектов класса Консорциум
Набросок 1.16 — Диаграмма состояний объектов класса порядок и метод реализации вычислений. Многофункциональная модель состоит из набора диаграмм потока данных, которые демонстрируют потоки значений от наружных входов через операции и внутренние хранилища данных к наружным выходам. Многофункциональная модель обрисовывает смысл операций объектной модели и действий динамической модели, также ограничения на объектную модель. Неинтерактивные программки (к примеру, компиляторы) имеют элементарную динамическую модель: их цель состоит в вычислении значения некой функции. Главный моделью таковых программ является многофункциональная модель (хотя если программка имеет нетривиальные структуры данных, для нее принципиальна и объектная модель).
1.4.1. Диаграммы потоков данных
Многофункциональная модель представляет собой набор диаграмм потоков данных (ДПД), которые обрисовывают смысл операций и ограничений. ДПД отражает многофункциональные зависимости значений, вычисляемых в системе, включая входные значения, выходные значения и внутренние хранилища данных. ДПД — это граф, на котором показано движение значений данных от их источников через модифицирующие их процессы к их пользователям в остальных объектах. ДПД содержит процессы: преобразование данных, перенос данных, потребление данных, хранение данных.
Процессы самого нижнего уровня представляют собой функции без побочных эффектов (примерами таковых функций являются вычисление суммы 2-ух чисел, вычисление комиссионного сбора за выполнение проводки при помощи банковской карточки и т.п.). Весь граф потока данных тоже представляет собой процесс (высочайшего уровня). Процесс может иметь побочные эффекты, если он содержит нефункциональные составляющие, такие как хранилища данных либо наружные объекты.
На ДПД процесс изображается в виде эллипса, снутри которого помещается имя процесса; любой процесс имеет фиксированное число входных и выходных данных, изображаемых стрелками (набросок 1.17).
Набросок. 1.17 — Примеры действий
Процессы реализуются в виде способов (либо их частей) и соответствуют операциям определенных классов.
Поток данных соединяет выход объекта (либо процесса) со входом другого объекта (либо процесса). Он представляет промежные данные вычислений. Поток данных изображается в виде стрелки меж производителем и пользователем данных, помеченной именами соответственных данных; примеры стрелок, изображающих потоки данных, представлены на рисунке 1.18. На первом примере изображено копирование данных при передаче одних и тех же значений двум объектам, на втором — расщепление структуры на ее поля при передаче различных полей структуры различным объектам.
Набросок 1.18 — Потоки данных
Активным именуется объект, который обеспечивает движение данных, поставляя либо потребляя их. Активные объекты обычно бывают присоединены к входам и выходам ДПД. Примеры активных объектов показаны на рисунке 1.19. На ДПД активные объекты обозначаются прямоугольниками.
Набросок 1.19 — Активные объекты (экторы)
Хранилище данных — это пассивный объект в составе ДПД, в каком данные сохраняются для следующего доступа. Хранилище данных допускает доступ к хранимым в нем данным в порядке, отличном от того, в каком они были туда помещены. Агрегатные хранилища данных, как к примеру, списки и таблицы, обеспечивают доступ к данным в порядке их поступления, или по ключам. Примеры хранилищ данных приведены на рисунке 1.20.
Набросок 1.20 — Хранилища данных
ДПД указывает все пути вычисления значений, но не указывает в котором порядке рассчитываются значения. Решения о порядке вычислений соединены с управлением программкой, которое отражается в динамической модели. Эти решения, вырабатываемые особыми функциями, либо предикатами, определяют, будет ли выполнен тот либо другой процесс, но при всем этом не передают процессу никаких данных, так что их включение в многофункциональную модель необязательно. Тем не наименее, время от времени бывает полезно включать обозначенные предикаты в многофункциональную модель, чтоб в ней были отражены условия выполнения соответственного процесса. Функция, принимающая решение о запуске процесса, будучи включенной в ДПД, порождает в ДПД поток управления (он изображается пунктирной стрелкой).
Набросок 1.21 — Поток управления
На рисунке 1.21 изображен пример потока управления: клиент, желающий снять часть собственных средств со счета в банке, вводит в БМ пароль и требуемую сумму, но фактическое снятие и выдача средств происходит лишь в этом случае, когда введенный пароль совпадает с его прототипом.
Невзирая на то, что потоки управления время от времени оказываются очень полезными, следует подразумевать, что включение их в ДПД приводит к дублированию инфы, входящей в динамическую модель.
1.4.2. Описание операций
Процессы ДПД должны быть реализованы как операции объектов. При всем этом реализация действий верхних уровней может различаться от их представления на ДПД, потому что при реализации обычно делается их оптимизация: в итоге оптимизации процессы нижних уровней, составляющие процесс наиболее высочайшего уровня могут «слиться», опосля что они станут невидимы.
Все операции должны быть специфицированы. Спецификация операции содержит ее сигнатуру (имя операции, количество, порядок и типы ее характеристик, количество, порядок и типы возвращаемых ею значений) и описание ее эффекта (деяния, преобразования). Для описания эффекта операции можно применять:
математические формулы;
табличные функции: таблицы, сопоставляющие выходные значения входным;
уравнения, связывающие входные и выходные значения;
аксиоматическое определение операций при помощи пред- и пост-условий;
таблицы принятия решений;
псевдокод;
естественный язык.
Наружная спецификация операции обрисовывает лишь те конфигурации, которые видны вне операции. Операция быть может реализована таковым образом, что при ее выполнении будут употребляться некие значения, определенные снутри операции (к примеру, в целях оптимизации), некие из этих значений могут даже быть частью состояния объекта. Эти детали реализации операции укрыты от других объектов и не участвуют в определении наружного эффекта операции. конфигурации внутреннего состояния объекта, не видные вне его, не меняют значения объекта.
Все нетривиальные операции можно поделить на три группы: запросы, деяния и активности. Запросом именуется операция без побочных эффектов над видимым снаружи объекта его состоянием (незапятнанная функция). запрос, у которого нет характеристик, не считая мотивированного объекта, является производным атрибутом. к примеру, для точки на координатной плоскости, радиус и полярный угол — производные атрибуты; из этого примера видно, что меж главными и производными атрибутами нет принципной различия, и выбор главных атрибутов почти во всем случаен.
Действием именуется операция, имеющая побочные эффекты, которые могут влиять на мотивированной объект и на остальные объекты системы, которые достижимы из мотивированного объекта. действие не занимает времени (логически, оно совершается одномоментно). Каждое действие быть может определено через те конфигурации, которые оно производит в состоянии объекта, меняя значения его атрибутов и связей; в котором порядке выполняются эти конфигурации, несущественно: мы считаем, что они все происходят сразу и одномоментно. Более всераспространенным методом описания деяния является задание метода его выполнения на компе.
Активностью именуется операция, выполняемая объектом, либо над объектом, выполнение которой занимает определенное время. Активность имеет побочные эффекты. Активности могут быть лишь у активных объектов, потому что пассивные объекты есть просто склады данных.
1.4.3. Ограничения
Ограничение показывает на зависимость меж соответствующыми значениями 2-ух объектов, или меж разными значениями 1-го объекта. Ограничение быть может выражено в виде некой функции (количественное ограничение), или дела (высококачественное ограничение). Нас заинтересовывают ограничения на атрибуты объектов, также на состояния и действия. Принципиальным видом ограничений являются инварианты: утверждения о том, что
Многофункциональная модель банковской системы указывает, как рассчитываются значения в системе и как они зависят одно от другого. Для конструирования многофункциональной модели нужно выполнить последующее:
найти входные и выходные значения;
выстроить ДПД, показывающие многофункциональные зависимости;
обрисовать функции;
обрисовать ограничения;
сконструировать аспекты оптимизации;
уточнить набор операций в объектной модели.
Выполним все эти шаги, чтоб выстроить многофункциональную модель банковской сети (БМ).
Начнем с определения входных и выходных значений. Эти значения являются параметрами событий меж системой и окружающим ее миром. Входные и выходные значения банковской сети показаны на рисунке 1.22 (пунктирная линия указывает границу системы).
Набросок 1.22 — Входные и выходные значения банковской сети
Так как все взаимодействия меж наружным миром и системой проходят через БМ, все входные и выходные значения являются параметрами событий, связанных с объектом БМ.
ДПД обычно строится по уровням. На верхнем уровне, как правило, демонстрируют один единственный процесс, либо, как в нашем примере (набросок 1.23), процесс ввода, главный процесс вычисления требуемых значений и процесс вывода. Входные и выходные данные на данной диаграмме поставляются и потребляются наружными объектами (клиент, карточка).
Набросок 1.23 — Процессы верхнего уровня в системе обслуживания банковской сети
На ДПД всякого уровня указываются элементы данных наиболее больших уровней, чтоб показать данные, обрабатываемые каждым действием (набросок 1.24). Большая часть систем содержит внутренние хранилища данных, в каких хранятся данные в периодах меж взаимодействиями. Для процесса выполнить проводку таковым хранилищем является объект счет. Внутренние хранилища данных различаются тем, что получаемые ими данные не выдаются немедля, а хранятся в объекте для использования в дальнейшем.
Набросок 1.24 — ДПД процесса выполнить проводку в системе обслуживания банковской сети
ДПД демонстрируют лишь зависимости меж операциями; они не содержат инфы о последовательности выполнения операций. К примеру, пароль должен быть доказан до внесения конфигураций в счет; если он указан ошибочно, конфигурации в счет не вносятся. Последовательность выполнения операций указывается в динамической, а не в многофункциональной модели.
Некие значения данных влияют на выбор последовательности вычислений в динамической модели; тем не наименее, эти значения не влияют конкретно на выходные значения ДПД, потому что ДПД указывает все вероятные пути вычислений. Но может оказаться полезным поместить функции, осуществляющие выбор последовательности вычислений, и в многофункциональную модель, потому что эти функции могут выражать сложные зависимости от входных данных. Такие функции показаны на ДПД, но их выходными значениями являются управляющие сигналы, показанные пунктирными линиями. Примером таковой функции является функция проверить пароль.
Опосля того как ДПД составлена, нужно описание каждой функции из ДПД. Пример описания функции:
изменить_счет (счет, сумма, вид_проводки) -> средства, квитанция
если сумма снимается и больше баланса счета,
то «отменить_проводку»;
если сумма снимается и меньше баланса счета,
то «дебетовать_счет» и «выдать_средства«;
если сумма вносится на счет,
то «кредитовать_счет»;
если запрос,
то «выдать_запрос»;
во всех вариантах: квитанция обязана содержать номер ATM, дату, время,
номер счета, вид проводки, сумму проводки (если она есть), новейший баланс счета
Ограничения — это многофункциональные зависимости меж объектами, не сводящиеся к конкретным зависимостям меж выходами и входами. Ограничения могут накладываться сразу на два объекта, на разные объекты 1-го класса в разные моменты времени (инвариант), либо на объекты различных классов в разные моменты времени (хотя в крайнем случае это, как правило, связи меж входами и выходами). Ограничения, которым должны удовлетворять входные значения функции, именуются ее предусловиями, а ограничения, которым удовлетворяют выходные значения функции, — ее постусловиями.
В банковской сети можно ввести последующие ограничения:
«счет не может иметь отрицательного баланса»;
«отрицательный баланс кредитуемого счета не быть может больше лимита кредитования для этого счета».
Определяем, какие значения нужно максимизировать либо минимизировать в процессе работы системы; если критериев оптимизации несколько и они противоречат один другому, следует найти компромиссные решения. На данной стадии не следует принимать по этому поводу очень четких решений, потому что в процессе предстоящего проектирования аспекты будут уточняться и изменяться.
Оптимизационные аспекты для банковской сети:
минимизировать количество физических пересылок меж разными узлами сети;
минимизировать время, в течение которого счет закрыт для доступа.
Операции вводятся на разных стадиях разработки модели проектируемой системы (см. выше):
при разработке объектной модели;
при определении событий;
при определении действий и активностей;
при определении функций.
На шаге разработки модели проектируемой системы все введенные операции вводятся в ее объектную модель.
К перечисленным операциям добавляются операции, связанные с наружным поведением объектов рассматриваемых классов: эти операции определяются природой объектов, а не качествами разрабатываемой системы. Такие операции расширяют определение объекта, выводя его за рамки конкретных требований со стороны определенной системы. Примерами таковых операций для банковской сети являются: закрыть счет, сделать сбер счет, сделать банковскую карточку и т.п. Исходя из убеждений системы эти операции не имеют смысла, но они отражают настоящие характеристики классов счет и карточка и могут оказаться полезными при использовании этих классов в остальных системах. Дальше следует изучить объектную модель на предмет упрощения операций ее классов.
2. Конструирование системы
Опосля того как прикладная задачка изучена, и результаты ее исследования зафиксированы в виде объектной, динамической и многофункциональной моделей, можно приступить к конструированию системы. На шаге конструирования системы принимаются решения о распределении подсистем по микропроцессорам и остальным аппаратным устройствам. Инсталлируются главные принципы и концепции, которые сформировывают базу детализированной следующей разработки программного обеспечения системы.
Наружная организация системы именуется архитектурой системы. Выбор архитектуры системы является еще одной задачей, решаемой на шаге ее конструирования.
Конструирование системы заканчивается конструированием ее объектов. На этом шаге разрабатываются полные определения классов и зависимостей, применяемые на шаге реализации системы. Не считая того, определяются и конструируются внутренние объекты и оптимизируются структуры данных и методы.
2.1. Разработка архитектуры системы
Во время анализа требований к системе основное внимание уделялось выяснению того, что обязано быть изготовлено, вне зависимости от того, как это создать. На шаге разработки системы решается вопросец, как воплотить решения, принятые на шаге анализа.
Поначалу разрабатывается общая структура (архитектура) системы. Архитектура системы описывает ее разбиение на модули, задает контекст, в рамках которого принимаются проектные решения на последующих шагах разработки. Приняв решения о структуре системы в целом, разраб системы производит ее разбиение на относительно независящие в реализации части (модули), разделяя разработку меж разрабами выделенных модулей, что дает возможность расширить фронт работ, подключить к разработке системы новейших исполнителей.
На шаге конструирования системы ее разраб должен принять последующие решения:
найти разбиение системы на модули;
выявить асинхронный параллелизм в системе;
найти состав вычислительного комплекса, на котором будет работать система;
распределить составляющие системы по микропроцессорам вычислительного комплекса и независящим задачкам;
организовать управление хранилищами данных;
организовать управление глобальными ресурсами;
избрать принципы реализации управления программным обеспечением;
организовать управление пограничными ситуациями.
2.1.1. Разбиение системы на модули
1-ое, что нужно создать, начиная шаг разработки системы, найти ее разбиение на некое количество компонент — модулей. Модуль не является ни объектом, ни функцией; модуль — это набор (пакет) классов и отдельных объектов, подсистем, зависимостей, операций, событий и ограничений, которые взаимосвязаны и имеют довольно отлично определенный и по способности маленькой интерфейс с иными модулями. Нередко модуль включает одну подсистему, являясь ее реализацией. Модуль (подсистема) обычно определяется через службы, которые он обеспечивает.
именуется набор взаимосвязанных функций, которые вместе обеспечивают какую-либо функциональность, к примеру, выполнение ввода-вывода, обрисовку картинок, выполнение арифметических действий. Подсистема описывает согласованный метод рассмотрения одной из сторон прикладной задачки, для решения которой разрабатывается рассматриваемая система. к примеру, система файлов — подсистема операционной системы; она обеспечивает набор взаимосвязанных абстрактных операций, которые в большенный степени (но не стопроцентно) независимы от абстрактных операций, обеспечиваемых иными подсистемами. Эта подсистема быть может реализована в виде отдельного модуля.
Как уже отмечалось, любая подсистема имеет отлично определенный (наружный) интерфейс с остальной частью системы (иными подсистемами). Этот интерфейс описывает форму всех взаимодействий с подсистемой и все потоки данных через ее границы, но не специфицирует внутреннюю структуру и внутреннее свита подсистемы, также индивидуальности ее реализации. Потому любая подсистема может разрабатываться независимо от других подсистем.
Подсистемы должны определяться таковым образом, чтоб большая часть взаимодействий оставалась снутри подсистем, для уменьшения глобальных потоков данных и сокращения зависимостей меж подсистемами. Подсистем обязано быть не весьма много (в границах 10-ка). Некие подсистемы могут быть в свою очередь подразделены на подсистемы.
Две подсистемы могут вести взаимодействие друг с другом или как клиент и поставщик (клиент-сервер), или как равноправные партнеры (сопрограммы). В первом случае
вызывает
, который делает некий запрос клиента и возвращает итог; клиент должен знать интерфейс сервера, но сервер может не знать интерфейсов клиента, потому что
. В случае программного взаимодействия обе подсистемы вызывают друг друга. Воззвание подсистемы к иной подсистеме не непременно соединено с незамедлительным получением ответа. Программное взаимодействие является наиболее сложным, потому что обе подсистемы должны знать интерфейсы друг дружку. Потому необходимо стараться, чтоб большая часть подсистем вела взаимодействие как клиент и .
Подсистемы (и реализующие их модули) могут создавать в системе уровни, или разделы.
Уровневая система может рассматриваться как упорядоченное огромное количество виртуальных миров, любой из которых построен на базе понятий, поддерживаемых его подсистемами; подсистемы 1-го уровня обеспечивают реализацию подсистем последующего уровня. Объекты всякого уровня могут быть независящими, хотя часто объекты различных уровней могут соответствовать друг другу. Любая подсистема понимает о подсистемах наиболее низких уровней и ничего не понимает о наиболее больших уровнях. Зависимость клиент-сервер существует меж верхними (клиентами) и наиболее нижними уровнями (серверы). При всем этом любой уровень может иметь собственный свой набор классов и операций. Любой уровень реализуется через операции объектов и подсистем, наиболее нижних уровней. Уровневые архитектуры бывают 2-ух видов: открытые и замкнутые. В замкнутой архитектуре любой уровень строится на базе конкретно последующего за ним уровня. Это уменьшает зависимости меж уровнями и упрощает внесение конфигураций. В открытой архитектуре любой уровень строится на базе всех последующих за ним уровней. Это уменьшает Потребность в переопределении операций на любом уровне и приводит к наиболее действенному и малогабаритному коду. Но открытая архитектура не удовлетворяет принципу инкапсуляции инфы, так как конфигурации в какой-нибудь подсистеме могут востребовать соответственных конфигураций в подсистемах наиболее больших уровней.
Обычно только подсистемы самого верхнего и самого нижнего уровней могут быть выведены из постановки задачки: самый верхний уровень — это требуемая система, а самый нижний уровень — это доступные ресурсы: аппаратура, операционная система, имеющиеся библиотеки. Промежные уровни вводятся разрабом системы.
Система с уровневой архитектурой при переносе на другую платформу просит переписывания лишь 1-го (самого нижнего) уровня. Пример системы с уровневой архитектурой представлен на рисунке 2.1.
Набросок 2.1 — Пример системы с уровневой архитектурой
Разделы подразделяют систему на несколько независящих либо почти не связанных модулей (подсистем), любая из которых обеспечивает один из видов услуг. К примеру, операционная система компа включает систему файлов, управление действиями, управление виртуальной памятью и управление устройствами.
Обычно система разделяется на модули (подсистемы) с внедрением обоих методов разбиения в самых различных композициях: уровни делятся на разделы, разделы содержат внутри себя уровни.
Набросок 2.2 — Топология звезды
Когда все модули и подсистемы всех уровней названы, нужно показать информационные потоки меж модулями и подсистемами, построив ДПД. Это дозволит осознать топологию системы. Топология системы определяется совокупой потоков инфы в системе; к примеру, у компилятора конвейерная топология, можно представить для себя топологию звезды (набросок 2.2) и т.п.; необходимо стремиться, чтоб топология системы была как можно проще.
2.1.2. Выявление асинхронного параллелизма
В анализируемой модели, как и в настоящем мире и в программном обеспечении все объекты независимы и должны работать асинхронно. Но в реализации не все объекты должны работать независимо и асинхронно, потому что несколько объектов может производиться на одном микропроцессоре, если понятно, что они не могут быть сразу активными. одна из важных целей разработки системы узнать, какие объекты должны быть активными сразу (параллельно), а какие бывают активными лишь в различное время. Эти крайние объекты могут быть соединены в одну нить управления (задачку).
Для определения асинхронности (параллельного существования) объектов употребляется динамическая модель. Два объекта являются значительно асинхронными, если они могут получать действия в одно и то же время, не взаимодействуя вместе. Если действия не синхронизируются, такие объекты не могут быть соединены в одну нить управления.
От асинхронных объектов необходимо различать стопроцентно независящие объекты, которые не только лишь производятся независимо, да и не обмениваются данными в процессе собственной работы. На сто процентов независящие системы комфортны тем, что их можно поместить на различные аппаратные устройства, исключив при всем этом коммуникационные Издержки.
Асинхронные объекты могут производиться и на одном устройстве (микропроцессоре), если оно имеет систему прерываний и поддерживает режим разделения времени. В почти всех вариантах необходимость делать объекты на различных устройствах следует из постановки задачки.
2.1.3. Распределение модулей и подсистем по микропроцессорам и задачкам
Любой асинхронный (независящий) объект (модуль либо подсистема) должен быть приписан к одному из устройств аппаратуры: всепригодному микропроцессору либо спец многофункциональному устройству. Разраб системы должен:
оценить требуемую производительность и требуемые ресурсы;
избрать метод реализации подсистем (аппаратный либо программный);
распределить программные подсистемы по микропроцессорам, стремясь удовлетворить их требования по производительности и в то же время уменьшить межпроцессорные коммуникации.
Решение применять несколько микропроцессоров обычно бывает соединено с потребностью иметь наиболее высшую производительность, чем производительность 1-го микропроцессора. количество требуемых микропроцессоров зависит от размера вычислений и производительности компа. Разраб системы в силах оценить требуемую производительность микропроцессоров, вычисляя постоянную нагрузку как произведение количества транзакций в секунду на время выполнения одной транзакции (для банковской сети транзакция — это проводка). Таковая оценка не учитывает затратных расходов, связанных со случайными переменами перегрузки и некими иными факторами. Ее следует уточнить.
Аппаратуру следует разглядывать как неизменяемое кропотливо оптимизированное программное обеспечение. Каждое устройство может рассматриваться как объект, который работает наряду с иными объектами. Разраб может принять решение о подмене неких объектов пригодными аппаратными устройствами. Обычно такое решение принимается по последующим причинам:
требуемые устройства просто доступны; в наше время легче приобрести микропроцессор с плавающей математикой, чем воплотить подобающую библиотеку;
требуется наиболее высочайшая производительность, чем производительность имеющихся микропроцессоров, а производительность специализированных устройств, постоянно выше.
При распределении модулей и подсистем по микропроцессорам следует подразумевать последующее:
некие задачки необходимо делать на определенных устройствах; к примеру, обработку банковской карточки следует делать на БМ;
время ответа либо скорость информационного потока превосходит пропускную способность канала меж микропроцессором и программкой; к примеру, высокоскоростные графические устройства требуют спаренных контроллеров;
скорости вычислений очень высоки для 1-го микропроцессора, и задачки необходимо расположить на нескольких микропроцессорах; подсистемы, которые нередко ведут взаимодействие, необходимо поместить на одном микропроцессоре.
2.1.4. Управление хранилищами данных
Внутренние и наружные хранилища данных являются четкими точками раздела меж подсистемами с отлично определенными интерфейсами. В качестве хранилищ данных могут употребляться базы данных, файлы и остальные структуры данных, размещенные во наружной либо главный памяти. Выбор вида хранилища данных зависит от ситуации.
В базах данных обычно располагают данные, удовлетворяющие одному из последующих критерий:
данные, для которых требуется доступ на высочайшем уровне детализации со стороны почти всех юзеров;
данные, которые могут отлично управляться командами СУБД;
данные, которые должны переноситься на почти все платформы;
данные, для которых требуется доступ со стороны нескольких прикладных программ.
В файлах комфортно располагать данные, удовлетворяющие одному из последующих критерий:
данные, которых много, но которые плохо поддаются структуризации;
данные с низкой информационной плотностью (к примеру, дампы);
«сырые» данные, подготавливаемые для баз данных;
«летучие» данные, которые хранятся куцее время, а позже удаляются.
2.1.5. Реализация управления программным обеспечением
Во время анализа все взаимодействия представляются в виде событий. Управление аппаратурой соответствует данной модели, но нужно избрать способ управления программным обеспечением системы. Существует два класса способов управления программным обеспечением: способы наружного управления и способы внутреннего управления. Известны три способа наружного управления:
последовательное управление процедурами,
последовательное управление событиями,
параллельное асинхронное управление.
При поочередном управлении процедурами в любой момент времени действует одна из процедур; это более просто реализуемый метод управления. При поочередном управлении событиями управлением занимается монитор (диспетчер). При параллельном асинхронном управлении сиим управляет несколько управляющих объектов (мониторов).
Внутреннее управление соединено с потоками управления в действиях. Оно существует лишь в реализации и поэтому не является лишь поочередным либо параллельным. В отличие от наружных событий, внутренние передачи управления, как, к примеру, вызовы процедур либо воззвания к параллельным задачкам контролируются программкой и могут быть структурированы в случае необходимости.
Тут мы рассматриваем, в главном, процедурное программирование, но, естественно, вероятны и остальные парадигмы, как, к примеру, логические программные системы, многофункциональные программные системы и остальные виды непроцедурных программных систем. В этом курсе такие системы не рассматриваются.
2.1.6. Пограничные ситуации
Нужно предугадать работать, система (объект) обязана быть приведена в фиксированное изначальное состояние: должны быть проинициализированы все константы, исходные значения глобальных переменных и характеристик, задачки и, может быть, сама иерархия классов. Во время инициализации, бывает, доступна только часть способностей системы.
Терминация состоит в освобождении всех наружных ресурсов, занятых задачками системы.
Обвал — это не запланированная терминация системы. Обвал может появиться в итоге ошибок юзера, не хватки ресурсов, либо наружной трагедии. Предпосылкой обвала могут быть и ошибки в программном обеспечении системы.
2.1.7. Архитектур прикладных систем
Существует несколько типов архитектур, обычно применяемых в имеющихся системах. Любая из их отлично подступает к определенному типу систем. Проектируя систему 1-го из нижеперечисленных типов, имеет смысл применять подобающую архитектуру. Мы разглядим последующие типы систем:
— обработка данных делается один раз для всякого набора входных данных;
— обработка данных делается безпрерывно над сменяющимися входными данными;
— системы, управляемые наружными действиями;
— системы, моделирующие поведение объектов наружного мира;
— системы, в каких преобладают строгие временные ограничения;
— системы, обеспечивающие сортировку и обновление данных; имеют коллективный доступ;
является СУБД.
При разработке системы пакетной обработки нужно выполнить последующие шаги:
Разбиваем полное преобразование на фазы, любая из которых делает некую часть преобразования; система описывается диаграммой потока данных, которая строится при разработке многофункциональной модели.
Определяем классы промежных объектов меж каждой парой поочередных фаз; любая фаза понимает о объектах, расположенных на объектной диаграмме до и опосля нее (эти объекты представляют соответственно входные и выходные данные фазы).
Составляем объектную модель каждой фазы. Она имеет такую же структуру, что и модель всей системы в целом. Фаза разбивается на подфазы. Разрабатываем каждую подфазу.
Набросок 2.3 — Система непрерывной обработки: машинная графика
При разработке системы непрерывной обработки нужно выполнить последующие шаги:
Строим диаграмму потока данных; активные объекты в ее начале и в конце соответствуют структурам данных, значения которых безпрерывно меняются; хранилища данных, связанные с ее внутренними фазами, отражают характеристики, которые влияют на зависимость меж входными и выходными данными фазы.
Определяем классы промежных объектов меж каждой парой поочередных фаз; любая фаза понимает о объектах, расположенных на объектной диаграмме до и опосля нее (эти объекты представляют соответственно входные и выходные данные фазы).
Представляем каждую фазу как последовательность конфигураций значений частей выходной структуры данных зависимо от значений частей входной структуры данных и значений, получаемых из хранилища данных (
При разработке системы с интерактивным интерфейсом нужно выполнить последующие шаги:
Выделяем объекты, формирующие интерфейс.
Если есть возможность, используем готовые объекты для организации взаимодействия (к примеру, для организации взаимодействия системы с юзером через экран монитора можно применять библиотеку системы X-Window, обеспечивающую работу с меню, формами, клавишами и т.п.).
Структуру программки определяем по ее динамической модели; для реализации интерактивного интерфейса используем параллельное управление (многозадачный режим) либо механизм событий (прерывания), а не процедурное управление, когда время меж выводом еще одного сообщения юзеру и его ответом система проводит в режиме ожидания.
Из огромного количества событий выделяем физические (аппаратные, обыкновенные) действия и стараемся при организации взаимодействия применять сначала их.
При разработке системы динамического моделирования нужно выполнить последующие шаги:
По объектной модели определяем активные объекты; эти объекты имеют атрибуты с временами обновляемыми значениями.
Определяем дискретные действия; такие действия соответствуют дискретным взаимодействиям объекта (к примеру, включение питания) и реализуются как операции объекта.
Определяем непрерывные зависимости (к примеру, зависимости атрибутов от времени); значения таковых атрибутов должны временами обновляться в согласовании с зависимостью.
Набросок 2.4 — Система с интерактивным интерфейсом: БМ
Моделирование управляется объектами, отслеживающими временные циклы последовательностей событий.
Разработка системы настоящего времени подобна разработке системы с интерактивным интерфейсом.
При разработке системы управления транзакциями нужно выполнить последующие шаги:
Отображаем объектную модель на базу данных.
Определяем асинхронно работающие устройства и ресурсы с асинхронным доступом; в случае необходимости определяем новейшие классы.
Определяем набор ресурсов (в том числе — структур данных), к которым нужен доступ во время транзакции (участники транзакции).
Разрабатываем параллельное управление транзакциями; системе может пригодиться несколько раз повторить неудачную транзакцию до этого, чем выдать отказ.
Система управления банковской сетью, является гибридной системой: это, во-1-х, система с интерактивным интерфейсом (интерактивные действия осуществляются при помощи кассовых терминалов и БМ), а, во-2-х, это система управления транзакциями, потому что она обеспечивает выполнение проводок, которые и есть транзакции.
Архитектура системы управления банковской сетью показана на рисунке 2.5. Система имеет три главных подсистемы: подсистему обслуживания БМ, подсистему Консорциум и подсистему банк. Система имеет топологию звезды, в центре которой — подсистема Консорциум, а на лучах — подсистемы БМ и банк (ясно, что в состав системы заходит одна подсистема Консорциум и по несколько подсистем БМ и банк).
Набросок 2.5 — Архитектура системы управления банковской сетью
Неизменные хранилища данных (счета клиентов и банковская отчетная документация) имеются у подсистем банков. Так как принципиально сохранять целостность данных и обеспечивать параллельное сервис нескольких проводок (транзакций), хранилища данных реализованы на базе баз данных банков (доступ к данным осуществляется через СУБД, которая, а именно, обеспечивает синхронизацию доступа к данным).
Асинхронная параллельность возникает в связи с необходимостью параллельного обслуживания нескольких независимо работающих БМ и кассовых терминалов. Любой терминал может сразу обслуживать лишь одну проводку (транзакцию), но любая проводка связана также с центральным компом консорциума и компом 1-го из банков, которые должны сразу обслуживать несколько проводок. Как видно из рисунка 2.5 любая проводка распределена по трем устройствам, управляющее ее выполнением программное обеспечение состоит из 3-х частей; любая из этих частей быть может реализована в виде отдельного класса.
2.2. Разработка объектов
Разработав архитектуру системы, перебегаем к разработке объектов (классов), составляющих систему. часть объектов была выявлена на шаге анализа системы, эти объекты могут рассматриваться как база системы. На рассматриваемом шаге разработки системы нужно избрать метод их реализации, стремясь минимизировать количество потребляемых ими ресурсов (времени их выполнения, применяемой памяти и др.). При реализации объектов классы, атрибуты и зависимости должны быть реализованы в виде соответственных структур данных, операции — в виде функций. При всем этом может появиться необходимость введения новейших классов (объектов) для промежных данных.
Разработка объектов подразумевает выполнение последующих шагов:
Рассматривая вместе три модели, получаем операции над классами.
Разрабатываем методы, реализующие приобретенные операции.
Оптимизируем пути доступа к данным.
Реализуем управление взаимодействиями с наружными объектами.
Уточняем структуру классов, чтоб повысить степень наследования.
Разрабатываем зависимости.
Определяем представления объектов.
2.2.1. Совместное рассмотрение 3-х моделей
В итоге анализа мы получаем три модели: объектную, динамическую и многофункциональную. При всем этом объектная модель составляет базу, вокруг которой осуществляется предстоящая разработка. При построении объектной модели в ней не постоянно указываются операции над объектами, потому что исходя из убеждений объектной модели объекты это, до этого всего, структуры данных. Потому разработка системы начинается с сравнения действиям и активностям динамической модели и действиям многофункциональной модели операций и внесения этих операций в объектную модель. С этого начинается процесс разработки программки, реализующей поведение, которое описывается моделями, построенными в итоге анализа требований к системе.
одной из его операций; можно любому событию, приобретенному объектом, сравнить операцию над сиим объектом, а любому событию, посланному объектом, сравнить операцию над объектом, которому событие было послано. Активности, запускаемой переходом на диаграмме состояний, может соответствовать еще одна (вложенная) диаграмма состояний.
Результатом этого шага проектирования является уточненная объектная модель, содержащая все классы проектируемой программной системы, в каких специфицированы все операции над их объектами.
2.2.2. Разработка алгоритмов, реализующих приобретенные операции
Каждой операции, определенной в уточненной объектной модели, должен быть сопоставлен метод, реализующий эту операцию. При выбирании метода можно управляться последующими соображениями:
вычислительная сложность метода: для алгоритмов, используемых к довольно огромным массивам данных, принципиально, чтоб оценка их вычислительной трудности была разумной; к примеру, навряд ли имеет смысл избегать косвенности в ссылках, в особенности когда введение косвенности значительно упрощает осознание программки; в то же время подмена пузырьковой сортировки с оценкой трудности n2
на метод сортировки с оценкой n*log n постоянно резко ускоряет вычисления;
: для заслуги этого можно даже пойти на маленькое понижение эффективности; к примеру, введение рекурсии постоянно понижает скорость выполнения программки, но упрощает ее осознание;
: большая часть программ обязана быть изменена; как правило, высокоэффективный метод труден для осознания и модификации; одним из выходов является разработка 2-ух алгоритмов выполнения операции: обычного, но не весьма действенного, и действенного, но сложного; при модификации в этом случае меняется наиболее обычный метод, что обеспечивает работоспособность системы на период разработки наиболее действенного измененного метода.
Выбор алгоритмов связан с выбором структур данных, обрабатываемых этими методами. Успешный выбор структур данных дозволяет значительно улучшить метод.
Еще одним методом упрощения и оптимизации алгоритмов является введение внутренних (вспомогательных) классов. Эти классы не имеют соответствий в настоящем мире; они соединены с реализацией, но могут значительно упростить ее (примеры: класс стек, класс двусвязный перечень и т.п.).
В конце концов, в почти всех вариантах бывает полезным внести некие конфигурации в структуру объектной модели. Эти конфигурации сводятся к введению доп классов и к перераспределению операций меж классами.
При распределении операций по классам руководствуются последующими соображениями:
если операция производится лишь над одним объектом, то она определяется в классе, экземпляром которого является этот объект;
если аргументами операции являются объекты различных классов, то ее следует поместить в класс, к которому принадлежит итог операции;
если аргументами операции являются объекты различных классов, при этом меняется объект;
если классы вкупе с их зависимостями образуют звезду с центром в одном из классов, то операцию, аргументами которой являются объекты этих классов, следует поместить в центральный класс.
2.2.3. оптимизация разработки
Объектная модель, построенная на шаге анализа требований к программной системе, содержит информацию о логической структуре системы; на шаге разработки объектная модель уточняется и дополняется: в нее добавляются детали, связанные с необходимостью обеспечить наиболее действенный доступ к информационным структурам во время работы системы. Цель оптимизации разработки — поменять семантически корректную, но недостаточно эффективную модель, построенную на шаге анализа, наиболее действенной. В процессе оптимизации разработки производятся последующие преобразования:
добавляются лишниие зависимости, чтоб минимизировать утраты, связанные с доступом к данным, и максимизировать удобство работы с ними;
меняется порядок вычислений для заслуги большей эффективности;
сохраняются производные атрибуты, чтоб убрать необходимость вычисления сложных выражений.
На шаге анализа требований к программной системе лишниие зависимости нежелательны, потому что они не заносят в модель новейшей инфы. Внедрение производных атрибутов для исключения повторных вычислений показано на рисунке 2.6:
Набросок. 2.6 — Внедрение производных атрибутов для исключения повторных вычислений
Набросок 2.7 — Внедрение производной зависимости
На рисунке 2.7 показано, как введение производной зависимости дозволяет не вычислять координаты перекрывающихся частей окон в оконной системе для графического монитора.
Производные атрибуты должны изменять свои значения, когда изменяются их базисные значения. Для обеспечения этого пользуются одним из 3-х способов:
любой производный атрибут определяется при помощи 1-го либо нескольких базисных объектов; когда значения базисных объектов изменяются, требуется поменять значения всех производных атрибутов, связанных с ними;
всех производных атрибутов (в момент конфигурации базисного значения производные атрибуты перевычисляются);
активным именуется значения группируются вокруг определяющих их активных значений и перевычисляются синхронно с ними.
2.2.4. Реализация управления
Реализация управления связана с реализацией динамической модели объектов системы. Известны три подхода к реализации динамической модели:
состоянию соответствует определенный фрагмент программки;
очевидная реализация конечного автомата;
Процедурное управление является обычным методом реализации динамической модели; в этом случае состояние объекта определяется текущим оператором программки, а любому переходу соответствует оператор ввода: последующее состояние определяется по текущему состоянию и вводимому имени действия. Пример практического использования процедурного управления представлен на рисунке 2.8.
Набросок 2.8 — Псевдокод, соответственный динамической модели БМ
2.2.5. Уточнение наследования классов
Уточняя определения классов и операций, стараемся прирастить степень наследуемости: чем больше классов находятся в отношении наследования, тем меньше функций, реализующих операции этих классов нужно будет запрограммировать. Для роста степени наследуемости следует:
Перестроить классы и операции.
Выявить схожие (либо взаимно совершенно точно надлежащие) операции и атрибуты классов и найти для этих классов абстрактный суперкласс.
Употреблять делегирование операций, когда наследование семантически неправильно.
время от времени одна и та же операция бывает определена в нескольких классах, что дозволяет ввести общий суперкласс для этих классов, в каком реализуется эта операция. Но почаще операции в различных классах бывают схожими, но не схожими. В таковых вариантах необходимо попробовать внести несущественные конфигурации в определения этих операций, чтоб они стали схожими, т.е. имели однообразный интерфейс и семантику. При всем этом можно применять последующие приемы:
Если операции имеют схожую семантику, но различное число формальных характеристик, можно добавить отсутствующие характеристики, но игнорировать их при выполнении операции; к примеру, операция обрисовки изображения на монохромный монитор не просит параметра цвет, но его можно добавить и не принимать во внимание при выполнении операции.
Некие операции имеют меньше характеристик поэтому, что они являются личными вариантами наиболее общих операций; такие операции можно не реализовывать, сведя их к наиболее общим операциям с надлежащими значениями характеристик; к примеру, добавление элемента в конец перечня есть личный вариант вставки элемента в перечень.
Схожие по смыслу атрибуты либо операции различных классов могут иметь различные имена; такие атрибуты (операции) можно переименовать и перенести в класс, являющийся общим предком рассматриваемых классов.
Операция быть может определена не во всех классах некой группы классов; можно, тем не наименее, вынести ее в их общий суперкласс, переопределив ее в подклассах, как пустую там, где она не нужна.
Внедрение делегирования операций можно объяснить на последующем примере (набросок 2.9). Класс стек близок классу перечень, при этом операциям стека
и
соответствуют тривиальные личные случаи операций перечня
и
. Если воплотить класс стек как подкласс класса перечень, то придется использовать заместо операций
и
наиболее общие операции
и
, следя за их параметрами, чтоб избежать записи либо чтения из середины стека; это неловко и чревато ошибками. Еще лучше объявить класс перечень телом класса стек (делегирование), обращаясь к операциям перечня через операции стека. При всем этом, не меняя класса перечень, мы заменяем его интерфейс интерфейсом класса стек.
Набросок 2.9 — Реализация стека с внедрением наследования (а) и делегирования (б)
2.2.6. Разработка зависимостей
Зависимости — это «клей» объектной модели: конкретно они разрешают разглядывать модель как нечто целое, а не попросту как огромное количество классов.
Однобокие зависимости можно воплотить при помощи ссылок (указателей) (см. набросок 2.10). При всем этом, если кратность зависимости равна единице, ей соответствует один указатель, если кратность больше единицы, то огромное количество указателей.
Набросок 2.10 — Реализация однобокой зависимости
На рисунке 2.11 показан метод реализации двухсторонней зависимости при помощи указателей.
Набросок 2.11 — Реализация двухсторонней зависимости
На рисунке 2.12 показан метод реализации зависимости при помощи таблицы (как в реляционных базах данных).
Рис. 2.12. Реализация зависимости при помощи таблицы
При реализации зависимостей при помощи указателей атрибуты зависимостей (связей) переносятся в один из классов, участвующих в зависимости.
3. Реализация объектно-ориентированного проекта
Любой язык программирования имеет средства для выражения 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). Если 1-ые два способа относятся к интерфейсу класса, то 3-ий — это защищенный способ, нужный для реализации способов 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
]]>