Министерство образования Республики Беларусь

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

информатики и радиоэлектроники

Кафедра информационных технологий автоматизированных систем

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к расчетной работе
по курсу “Объектно-ориентированное программирование и проектирование”
на тему “ Объектно-ориентированный анализ и проектирование
программного обеспечения. Программное обеспечение банкомата”

Выполнила студентка гр. № 720604 _____________ М.В.Гуркова

(подпись)

Руководитель _____________ М.П. Ревотюк

(подпись)

Минск 2010
 Содержание

Содержание....................................................................................................................................2
Введение.........................................................................................................................................3
1. Постановка задачи.....................................................................................................................4
1.1. Цель разработки..................................................................................................................4
1.2. Постановка задачи заказчиком..........................................................................................4
1.3. Глоссарий проекта..............................................................................................................4
1.4. Анализ и определение требований...................................................................................5
2. Проектирование программного продукта...............................................................................7
2.1. Описание модели вариантов использования...................................................................7
2.1.1. Диаграмма вариантов использования............................................................................7
2.2. Описание модели анализа системы..................................................................................7
2.2.1. Диаграммы деятельности................................................................................................7
2.2.2. Диаграммы последовательностей и кооперации..........................................................9
2.2.3. Диаграммы состояний...................................................................................................10
2.2.4. Диаграмма классов........................................................................................................11
2.3. Описание модели реализации..........................................................................................13
2.3.1. Диаграмма компонентов...............................................................................................13
3. Процесс генерации программного кода............................................................................14
Заключение...................................................................................................................................15
Список литературы......................................................................................................................16
Приложения..................................................................................................................................17
Приложение 1. Диаграмма вариантов использования.........................................................17
Приложение 2. Диаграмма деятельности для прецедента «Наполнение базы»................18
Приложение 3. Диаграмма деятельности для прецедента «Запрос к базе».......................19
Приложение 4. Диаграмма кооперации для прецедента «Наполнение базы»...................20
Приложение 5. Диаграмма кооперации для прецедента «Запрос к базе»..........................20
Приложение 6. Диаграмма последовательности для прецедента «Наполнение базы»....21
Приложение 7. Диаграмма последовательности для прецедента «Запрос к базе»...........22
Приложение 8. Диаграмма состояний системы....................................................................23
Приложение 9. Диаграмма классов........................................................................................23
Приложение 10. Диаграмма компонентов............................................................................24

2
Введение

Среди всех фирм-производителей CASE-средств именно компания IBM

Rational Software Corp. одна из первых осознала стратегическую
перспективность развития объектно-ориентированных технологий анализа и
проектирования программных систем. Эта компания выступила инициатором
унификации языка визуального моделирования в рамках консорциума OMG,
что, в конечном итоге, привело к появлению первых версий языка UML. И
эта же компания первой разработала инструментальное объектно-
ориентированное CASE-средство, в котором был реализован язык UML как
базовая нотация визуального моделирования.
CASE-средство IBM Rational Rose со времени своего появления
претерпело серьезную эволюцию, и в настоящее время представляет собой
современный интегрированный инструментарий для проектирования
архитектуры, анализа, моделирования и разработки программных систем.
Именно в IBM Rational Rose язык UML стал базовой технологией
визуализации и разработки программных систем, что определило
популярность и стратегическую перспективность этого инструментария.
В рамках общего продукта IBM Rational Rose существуют различные
варианты этого средства, отличающиеся между собой диапазоном
предоставляемых возможностей. Базовым средством в настоящее время
является IBM Rational Rose Enterprise Edition, которое обладает наиболее
полными возможностями. Последней версией этого CASE-средства на
момент написания курса лекций является программа IBM Rational Rose 2003
(release 2003.06.00), возможности которой аккумулируют практически все
современные достижения в области информационных технологий. Наиболее
характерные функциональные особенности этой программы заключаются в
следующем:
интеграция с MS Visual Studio 6, которая включает поддержку на
уровне прямой и обратной генерации кодов и диаграмм Visual Basic и Visual
С++ с использованием ATL (Microsoft Active Template Library), Web-Классов,
DHTML и протоколов доступа к различным базам данных;непосредственная
работа (инжиниринг и реинжиниринг) с исполняемыми модулями и
библиотеками форматов EXE, DLL, TLB, OCX.
поддержка технологий MTS (Microsoft Transaction Server) и ADO
(ActiveX Data Objects) на уровне шаблонов и исходного кода, а также
элементов технологии Microsoft - COM+ (DCOM);полная поддержка
компонентов CORBA и J2EE, включая реализацию технологии
компонентной разработки приложений CBD (Component-Based Development),
3
языка определения интерфейса IDL (Interface Definition Language) и языка
определения данных DDL (Data Definition Language);
полная поддержка среды разработки Java-приложений, включая
прямую и обратную генерацию классов Java формата JAR, а также работу с
файлами формата CAB и ZIP.
Унифицированный язык моделирования UML (Unified Modeling
Language) – это преемник того поколения методов объектно-
ориентированного анализа и проектирования, которые появились в конце 80-
х и начале 90-х годов.
UML находится в процессе стандартизации, проводимом
консорциумом OMG (Object Management Group), в настоящее время он
принят в качестве стандартного языка моделирования и получил широкую
поддержку. UML принят на вооружение практически всеми крупнейшими
компаниями – производителями программного обеспечения (Microsoft,
IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все
мировые производители CASE-средств, помимо Rational Software (Rational
Rose), поддерживают UML в своих продуктах (Paradigm Plus (CA), System
Architect (Popkin Software), Microsoft Visual Modeler и др.

4
1. Постановка задачи

1.1. Цель разработки

Цель расчетной работы – закрепление и углубление знаний,

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

1.2. Постановка задачи заказчиком

Вариант 7.
Банкомат – это автомат для выдачи наличных денег по кредитным
пластиковым карточкам. В его состав входят следующие устройства:
дисплей, панель управления с кнопками, приемник кредитных карт,
хранилище денег и лоток для их выдачи, хранилище конфискованных
кредитных карт, принтер для печати справок, сервисная консоль. Банкомат
подключен к линии связи для обмена данных с банковским компьютером,
хранящим сведения о счетах клиентов.
Обслуживание клиента начинается с момента помещения пластиковой
карточки в банкомат. После распознавания типа пластиковой карточки,
банкомат выдает на дисплей приглашение ввести персональный код.
Персональный код представляет собой четырехзначное число. Затем
банкомат проверяет правильность введенного кода, сверяя с кодом,
хранящимся на карте. Если код указан неверно, пользователю
предоставляются еще две попытки для ввода правильного кода. В случае
повторных неудач карта перемещается в хранилище карт, и сеанс
обслуживания заканчивается. После ввода правильного кода банкомат
предлагает пользователю выбрать операцию. Клиент может либо снять
наличные со счета, либо узнать остаток на его счету.
При снятии наличных со счета банкомат предлагает указать сумму
(100, 200, 500, 1000, 5000, 10000 рублей). После выбора клиентом суммы
банкомат запрашивает, нужно ли печатать справку по операции. Затем
банкомат посылает запрос на снятие выбранной суммы центральному
компьютеру банка. В случае получения разрешения на операцию, банкомат
проверяет, имеется ли требуемая сумма в его хранилище денег. Если он
может выдать деньги, то на дисплей выводится сообщение "Выньте карту".
После удаления карточки из приемника, банкомат выдает указанную сумму в
лоток выдачи. Банкомат печатает справку по произведенной операции, если
она была затребована клиентом.
Если клиент хочет узнать остаток на счету, то банкомат посылает
запрос центральному компьютеру банка и выводит сумму на дисплей. По
требованию клиента печатается и выдается соответствующая справка.

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

1.3. Глоссарий проекта

Банкомат Устройство, посредством которого, клиент получает доступ к

денежным средствам на своём банковском счёте.
Пин-код Четырёхзначный цифровой код, используемый для подтверждения
принадлежности клиенту пластиковой карточки.
Транзакция Группа последовательных операций, которая приводит к желаемому
результату работы с устройством.
Вклад Сумма денег, принадлежащая клиенту и хранящаяся на банковском
счёте.
Аутентификация Процесс подтверждения принадлежности клиенту пластиковой
карточки.
Клиент Физическое или юридическое лицо, обслуживаемое банковской
системой.
Банковская Совокупность технических средств автоматического обслуживания
система клиента.
Банковский счёт Счёт, открываемый банком юридическим или физическим лицам для
их участия в безналичном денежном обороте и аккумулировании на
счете безналичных денежных средств.
Пластиковая Устройство, используемое клиентом при работе с банкоматом, которое
карточка вкупе с пин-кодом даёт доступ клиента к своему банковскому счёту
посредством банкомата.
Расчётный счёт Счёт, используемый банком для учёта денежных операций клиентов.

Банк Финансово-кредитный институт, основной функцией которого

является оказание финансовых услуг юридическим и физическим
лицам.

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

{Генеалогическое дерево состоит из персон и связей между ними. Эти

списки хранятся в базе данных в виде таблиц с несколькими полями.

Поля таблицы «Персона»:

1. Код персоны
2. Имя
3. Пол
4. Дата рождения

6
 5. Дата смерти
6. Биография

Поля таблицы «Связь»:

1. Код связи
2. Код персоны 1
3. Код персоны 2
4. Код вида связи
5. Название связи

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

структурой:

Необходимые функции системы:

1. Наполнение базы информацией. Должна быть предусмотрена
возможность добавлять записи о новых персонах и связях, редактировать
данные о персонах и удалять ненужные записи.
При создании связи соблюдается непротиворечивость. Должны
выполняться следующие условия:
 участники связи не могут быть одной и той же персоной;
 между каждой парой персон нельзя создавать более одной связи;
 для создания связи «мужья – жены» участники должны иметь разный
пол;
 для создания связи «мужья – жены» участники не должны состоять в
такой же связи с другими персонами (т.е. у персоны не может быть
несколько супругов);
 для создания связи «родители дети» первый участник (родитель)
должен быть старше второго участника (ребенок).

Доступны для изменения следующие поля таблицы «Персона»: имя,

дата смерти, биография.
Во избежание нарушений целостности данных доступны для удаления
только те персоны, которые не состоят в связях.
2. Вывод запрошенной информации. Должна быть предусмотрена
возможность получать следующие сведения о персоне:
- список детей;
- список родителей;
- список братьев и сестер;

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

8
2. Проектирование программного продукта

2.1. Описание модели вариантов использования

2.1.1. Диаграмма вариантов использования

Были выбраны следующие актеры и прецеденты.

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

2.2. Описание модели анализа системы

2.2.1. Диаграммы деятельности

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

предыдущем этапе.
Основной поток событий для включения «Аутентификация»

Позволяет банковской системе убедиться в правомерности использования

клиентом пластиковой карточки.

1. Вариант использования начинается, когда клиент вставляет карточку в

банкомат.
2. Банкомат выводит приветствие и предлагает пользователю ввести пин-код.
3. Клиент вводит пин-код.
4. Банкомат подтверждает введённый пин-код. Если код не подтверждается,
выполняется альтернативный поток А1.
5. Банкомат выводит список доступных действий: «Снять деньги», «Посмотреть
баланс», «Совершить платёж».
6. После выбора данный вариант использования завершается и продолжается
вызывающий.

Основной поток событий для прецедента «Снять деньги со счёта»

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

банковского счёта.

1. Вариант использования начинается, когда клиент вставляет карточку в

банкомат.

9
 2. Выполняется вариант использования «Аутентификация».
3. Клиент выбирает пункт «Снять деньги».
4. Банкомат запрашивает сумму.
5. Клиент вводит сумму.
6. Банкомат запрашивает банковскую систему о наличии нужной суммы на счёте.
Если денег на счёте недостаточно, выполняется альтернативный поток А2. При
возникновении ошибки выполняется поток ошибки Е1.
7. Банкомат вычитает сумму из счёта.
8. Банкомат выдаёт требуемую сумму.
9. Выполняется запрос на печать чека. При необходимости выполняется вариант
использования «Печать чека».
10. Банкомат возвращает клиенту карточку.
11. Вариант использования завершается.

Основной поток событий для прецедента «Посмотреть баланс»

Позволяет клиенту получить информацию о текущем балансе своего

банковского счёта.

1. Вариант использования начинается, когда клиент вставляет карточку в

банкомат.
2. Выполняется вариант использования «Аутентификация».
3. Клиент выбирает пункт «Посмотреть баланс».
4. Банкомат запрашивает банковскую систему о величине баланса.
5. Банкомат выводит сообщение с указанием баланса. При возникновении ошибки
выполняется поток ошибки Е1.
6. Выполняется запрос на печать чека. При необходимости выполняется вариант
использования «Печать чека».
7. Банкомат возвращает клиенту карточку.
8. Вариант использования завершается.

Основной поток событий для прецедента «Совершить платёж»

Позволяет клиенту совершить платёж посредством списания со своего счёта

суммы платежа и переводе её на расчётный счёт получателя.

1. Вариант использования начинается, когда клиент вставляет карточку в

банкомат.
2. Выполняется вариант использования «Аутентификация».
3. Клиент выбирает пункт «Совершить платёж».
4. Банкомат запрашивает расчётный счёт и сумму платежа.
5. Клиент вводит расчётный счёт и сумму платежа.
6. Банкомат запрашивает банковскую систему о существовании введённого
расчётного счёта и наличии нужной суммы на счёте. Если денег на счёте
недостаточно, выполняется альтернативный поток А2. Если расчётный счёт
введён неверно, выполняется альтернативный поток А3. При возникновении
ошибки выполняется поток ошибки Е1.
7. Банкомат вычитает сумму из счёта.
8. Банкомат совершает платёж.
9. Выполняется запрос на печать чека. При необходимости выполняется вариант
использования «Печать чека».
10
10. Банкомат возвращает клиенту карточку.
11. Вариант использования завершается.

Основной поток событий для расширения «Печать чека»

Позволяет клиенту получить чек с информацией о проведённой транзакции.

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

2. Выполняется печать чека. При возникновении ошибки выполняется поток
ошибки Е1.
3. Вариант использования завершается.

Альтернативный поток событий А1 «Неверно введён пин-код»

1. Вариант начинается по вызову из основного потока событий.

2. Банкомат выдаёт сообщение о неверном вводе с предложением повторить ввод.
3. Клиент повторяет ввод.
4. Если неверный ввод повторился, вывод предупреждения о последней попытке,
иначе – возврат к основному потоку событий.
5. Клиент повторяет ввод.
6. Если последняя попытка неудачна – карточка блокируется и перемещается в
хранилище карт и сеанс обслуживания завершается. Иначе – возврат к
вызывающему потоку.

Альтернативный поток событий А2 «Недостаточно денег на счёте»

1. Вариант начинается по вызову из основного потока событий.

2. Банкомат выдает сообщение о недостатке денег.
3. Банкомат предлагает завершить или продолжить работу.
4. Если выбран вариант завершения, банкомат возвращает карточку, иначе
переход к списку доступных операций основного потока событий.

Альтернативный поток событий А3 «Неверно введён расчётный счёт»

1. Вариант начинается по вызову из основного потока событий.

2. Банкомат выдаёт сообщение о неверном вводе с предложением повторить ввод.
3. Клиент повторяет ввод.
4. Если ввод снова неверен, перейти к п.2 потока, иначе – возврат к вызывающему
потоку.

Поток ошибок Е1

1. Вариант начинается по вызову из основного потока событий.

2. Банкомат выдаёт сообщение об ошибке.
3. Сеанс обслуживания завершается, карточка возвращается клиенту.

Вариант использования «Наполнение базы»

11
Основные потоки событий:
1. Пользователь выбирает, какое действие выполнить.
1.1. Работа с персонами
1.1.1. Добавить персону.
1.1.1.1. Система запрашивает данные о персоне.
1.1.1.2. Пользователь вводит данные о персоне.
1.1.1.3. Система проверяет, введено ли имя.
1.1.1.4. Если имя введено, новая запись добавляется в базу.
1.1.2. Изменить персону
1.1.2.1. Пользователь выбирает персону из списка.
1.1.2.2. Система запрашивает новые данные о персоне.
1.1.2.3. Пользователь вводит данные о персоне.
1.1.2.4. Система проверяет, введено ли имя.
1.1.2.5. Если имя введено, изменения вносятся в базу.
1.1.3. Удалить персону.
1.1.3.1. Пользователь выбирает персону из списка.
1.1.3.2. Система проверяет, состоит ли персона в связях.
1.1.3.3. Если не состоит, запись о персоне удаляется из базы.
1.2. Работа со связями.
1.2.1. Добавить связь.
1.2.1.1. Система проверяет, имеется ли хотя бы 2 записи в
таблице персон.
1.2.1.2. Если имеется, пользователь выбирает участников и тип
связи.
1.2.1.3. Система проверяет, возможна ли связь между
выбранными персонами.
1.2.1.4. Если возможна, в базу добавляется новая запись.
1.2.2. Удалить связь.
1.2.2.1. Пользователь выбирает нужную связь.
1.2.2.2. Из базы удаляется запись о связи.

Альтернативные потоки событий:

1. При удалении персоны выясняется, что удаляемая персона состоит в
связях.
1.1. Выводится сообщение об ошибке, и прецедент завершается.
2. При добавлении связи выясняется, что таблица персон содержит
менее двух записей.
2.1. Выводится сообщение об ошибке и прецедент завершается.

Предусловия.
1. Система должна находиться в состоянии «Ожидание действий от
пользователя».

Постусловия.
12
 1. Система возвращается в состояние «Ожидание действий от
пользователя».

Вариант использования «Запрос к базе»

Основные потоки событий:

1. Пользователь выбирает, какой запрос выполнить.
1.1. Исходными данными для запроса служит одна персона.
1.1.1. Пользователь выбирает нужный запрос в контексном меню
для нужной персоны.
1.2. Исходными данными для запроса служит 2 персоны.
1.2.1. Пользователь выбирает нужных персон из списка.
2. Система выполняет поиск в базе по запросу.
3. Система отображает результат запроса.

Предусловия.
1. Система должна находиться в состоянии «Ожидание действий от
пользователя».

Постусловия.
1. Система возвращается в состояние «Ожидание действий от
пользователя».

2.2.2. Диаграммы последовательностей и кооперации

Диаграммы последовательности отражают поток

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

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

будущей программы на основе диаграмм прецедентов и деятельности. Затем
были построены диаграммы последовательности, описывающие переход
активности между классами во времени, на основании которых средствами
Rational Software Architect автоматически были созданы диаграммы

13
кооперации.
Для построения диаграмм взаимодействия были выбраны следующие
объекты:
1. Актер Пользователь.
2. Объект класса CGenealogicalTreeView – класса вида, содержащего
методы-обработчики пользовательских действий.
3. Объект класса CGenealogicalTreeDoc – класса документа.

Вариант использования «Наполнение базы»

Выполняется одно из следующих действий.

1. Пользователь добавляет персону.
1.1. В базу данных добавляется новая запись (функция
CGenealogicalDoc::AddPerson()).
2. Пользователь изменяет персону.
2.1. В базу данных вносятся изменения
(CGenealogicalDoc::ChangePerson()).
3. Пользователь удаляет персону.
3.1. Проверяется, не участвует ли персона в связях
(CGenealogicalDoc::CheckRelationshipExist()).
3.2. Если не участвует, выполняется удаление записи из базы
(CGenealogicalDoc::DeletePersona()).
4. Пользователь добавляет связь.
4.1. В базу данных добавляется новая запись
(CGenealogicalDoc::AddRelationship).
4.1.1. Если создали связь типа «родители - дети»,
автоматически создаются связи «брат-сестра» между
новым ребенком и другими детьми родителя, при этом
выполняется функция
CGenealogicalDoc::CheckCorrectRelationship().
5. Пользователь удаляет связь.
5.1. Выполняется удаление записи из базы
(CGenealogicalDoc::DeleteRelationship()).

Вариант использования «Запрос к базе»

Выполняется один из следующих запросов.

1. Получить список детей персоны.
1.1. Выполняется поиск детей и выводится результат (функция
CGenealogicalDoc::ShowChild()).
2. Получить список родителей персоны.
2.1. Выполняется поиск родителей и выводится результат
(CGenealogicalDoc::ShowParent()).
3. Найти братьев и сестер персоны.
3.1. Выполняется поиск братьев и сестер и выводится результат
14
 (функция CGenealogicalDoc::ShowBrotherSister()).
4. Получить список всех предков персоны.
4.1. Выполняется поиск предков и выводится результат
(CGenealogicalDoc::ShowAncestor()).
4.1.1. Выполняется рекурсивная функция поиска родителей
CGenealogicalDoc::FindAllAncestors().
5. Получить список всех потомков персоны.
5.1. Выполняется поиск потомков и выводится результат
(CGenealogicalDoc::ShowDescendant()).
5.1.1. Выполняется рекурсивная функция поиска детей
CGenealogicalDoc::FindAllDescendants().
6. Получить список всех родственников персоны.
6.1. Выполняется поиск родственников и выводится результат
(CGenealogicalDoc::ShowRelative()).
6.1.1. Выполняется рекурсивная функция поиска ближайших
родственников CGenealogicalDoc::FindAllRelatives().
7. Проследить цепочку родственных связей между персонами.
7.1. Выполняется поиск связей и выводится результат
(CGenealogicalDoc::TraceRelationship()).
7.1.1. Выполняется рекурсивная функция поиска связей
CGenealogicalDoc::FindAllRelationships().

2.2.3. Диаграммы состояний

Система может находиться в следующих состояниях:

1. Ожидание действий от пользователя.
2. Ввод данных о новой персоне.
3. Изменение данных о персоне.
4. Ввод данных о связи.
5. Загрузка базы.
6. Сохранение базы.

Поскольку выполнение запросов и поиск информации в базе системой

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

15
2.2.4. Диаграмма классов

На диаграмме классов были размещены следующие классы:

CPersona – класс, описывающий строку в таблице «Персона».

Атрибуты:
 int id_persona; //код персоны
 CString name; //имя
 int gender; //пол
 COleDateTime birthdate; //дата рождения
 COleDateTime deathdate; //дата смерти
 CString bio; //биография

Функции:
 int GetId(); //возвращает идентификатор персоны
 CString GetName(); //возвращает имя персоны
 int GetGender(); //возвращает пол персоны
 COleDateTime GetBirthdate(); //возвращает дату рождения персоны
 COleDateTime GetDeathdate();//возвращает дату смерти персоны
 CString GetBio(); //возвращает биографию персоны
CRelationship – класс, описывающий строку в таблице «Связь».

16
 Атрибуты:
 int id_relationship; //идентификатор связи
 int pers1; //идентификатор первой персоны
 int pers2; //идентификатор второй персоны
 int variety; //идентификатор типа связи
 CString variety_name; //название типа связи

Функции:
 int GetId(); //возвращает идентификатор связи
 int GetPers1(); //возвращает идентификатор первой персоны
 int GetPers2(); //возвращает идентификатор второй персоны
 int GetVarietyNumb(); //возвращает идентификатор типа связи
 CString GetVariety(); //возвращает название типа связи

Поскольку используется MFC-приложение с архитектурой «Документ-

вид», в диаграмму классов были добавлены классы CGenealogicalTreeDoc и
CGenealogicalTreeView.

CGenealogicalTreeDoc – класс документа.

Атрибуты:
//таблица персон
 CTypedPtrArray<CObArray,CPersona*> PersonaTable();
//таблица связей
 CTypedPtrArray<CObArray,CRelationship*> RelationshipTable();

Функции:
 void AddPerson(); //добавить персону в базу
 void AddRelationship(); //добавить связь в базу
 void ChangePerson(); //отредактировать персону
//проверить возможность создания связи между указанными
//персонами
 bool CheckCorrectRelationship();
//проверить, есть ли связи между указанными персонами
 bool CheckRelationshipExist();
 void DeletePersona(); //удалить персону из базы
 void DeleteRelationship(); //удалить связь из базы
 void FindAllAncestors(); //рекурсивная функция поиска родителей
 void FindAllDescendants(); //рекурсивная функция поиска детей
//рекурсивная функция поиска ближайших родственников
 void FindAllRelatives();
 void FindRelationship(); //рекурсивная функция поиска связей

17
  void ShowAncestor(); //функция поиска предков
 void ShowBrotherSister(); //функция поиска братьев и сестер
 void ShowChild(); //функция поиска детей
 void ShowDescendant(); //функция поиска потомков
 vod ShowParent(); //функция поиска родителей
 void ShowRelative(); //функция поиска родственников
//функция прослеживания связи между персонами
 void TraceRelationship();
Атрибуты и функции класса CGenealogicalTreeView в проекте не
рассмотрены, т.к. это класс, обеспечивающий ввод-вывод данных
пользователем, который не несет реализации алгоритмов функционирования
системы. По этой же причине опущены прочие классы реальной программы
и нкоторые атрибуты и функции выше описанных классов.

2.3. Описание модели реализации

2.3.1. Диаграмма компонентов

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

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

Компонент Описанный класс

Persona.h/cpp
Relationship.h/cpp
GenealogicalTreeDoc.h/cpp
GenealogicalTreeView.h/cpp
MFC
CPersona
CRelationship
CGenealogicalTreeDoc
CGenealogicalTreeView
Библиотека MFC, подключенная к проекту

18
3. Процесс генерации программного кода

Была выполнена генерация кода программы с помощью IBM Rational

Software Architect по инструкции по кодогенерации UML модели в C++.
В результате были получены *.h и *.cpp файлы для следующих классов из
модели проектирования: CPersona, CRelationship, CGenealogicalTreeDoc,
CGenealogicalTreeView.

19
Заключение

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

Rational Software Architect, ставшая основой для написания программы в
среде Microsoft Visual Studio 2008 на языке C++.
Проект не отвечает признаку успешного проекта «написан в срок».
Конечная система реализует все заданные заказчиком требования.
Реализованная программа может иметь практическое применение для
составления семейных или иных не слишком сложных генеалогических
деревьев.
Дальнейшее развитие системы может включать в себя расширение
сроков существования рода (существующее ограничение – 14.09.1752 –
31.12.9999), более строгую проверку непротиворечивости создаваемых
связей, улучшение алгоритмов поиска информации в базе данных,
добавление графической визуализации деревьев.

20
Список литературы

1. Вендров А.М., Малышко В.В. Объектно-ориентированный анализ и

проектирование с использованием языка UML. М.: Издательский отдел
факультета ВМиК МГУ, 2002
2. Леоненков А.В. Самоучитель UML 2. БХВ-Петербург, 2007 г.

21
Приложения

Приложение 1. Диаграмма вариантов использования.

uc Use Case Model

банкомат

индификация ввод пин-кода

пользователя «include»

снить деньги

клиент

«include» банкомат
«include»
выполнить
операции
«include» пополнить счет предоставление
«include» услуг

«include»
«include»

просмотреть остаток
счета

22
23
Приложение 2. Диаграмма деятельности для прецедента «Наполнение
базы»
sd ми

карта банкомат банк

клиент

ввод

считывает номера

запрос пин-кода

отправка пин-кода

ввод пин-кода

сравнение пин-кода

вывод результата

24
 

 
cd s


банкомат


 
корпус
n
 
1
 
ПО 1 состоит 1 табло

 
1

1
1 

 
отображает
выполняет панель кнопок

 
n
n
1

 
информацию
операции


осуществляет
выбор



n 


операций


 

 

 

 

 

 

 

 

 

 

 
25
 
26
Приложение 3. Диаграмма деятельности для прецедента «Запрос к
базе»

27
 Приложение 4. Диаграмма кооперации для прецедента «Наполнение
базы»

Приложение 5. Диаграмма кооперации для прецедента «Запрос к базе»

28
Приложение 6. Диаграмма последовательности для прецедента
«Наполнение базы»

29
Приложение 7. Диаграмма последовательности для прецедента «Запрос
к базе»

30
Приложение 8. Диаграмма состояний системы

Приложение 9. Диаграмма классов.

class Class Model

карта операции

+ номер : int + выполнение() : void

+ проверка пин-кода() : boolean

«use»

банкомат
банк

+ номер: int + выбор операции() : void

«use» + запрос пин-кода() : double
+ пин-код: double
+ счет: int + запрос счета() : int
+ передача пин-кода() : double

«use»

новая операция

+ выполнение() : void

31
32
Приложение 10. Диаграмма компонентов.

33