Разработка объектно-ориентированной модели информационной подсистемы для пункта обмена валюты

К КУРСОВОМУ ПРОЕКТУ НА ТЕМУ:

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

1.3 Формулировка задач проектирования

Рисунок 2.1 - Диаграмма прецедентов

7. Назовем его «Кассир».

8. Повторив шаги шесть и семь, поместим на диаграмму действующее лицо «Клиент»

9. С помощью кнопки Unidirectional Association (Однонаправленная ассоциация) добавим ассоциации между действующим лицом «Кассир» и всеми вариантами использования.

10. Повторим то же самое для действующего лица «Клиент».

Рассмотренные выше варианты использования инициируют последовательность действий (транзакций) в базе данных в ответ на действия со стороны кассира.

Выводы

1. Была разработана диаграмма прецедентов, состоящая из двух актеров и четырех вариантов использования. Основным действующим лицом является кассир. Он выполняет три действия: «Продажа валюты», «Конверсия валюты», «Покупка валюты».

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

3 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ

Рисунок 3.1 - Диаграмма последовательности для варианта использования «Добавление сведений по ведомостям»

На приведенной выше диаграмме выделены следующие объекты соответствующих классов:

- выбор валюты - объект класса Валюты, форма отвечающая за выбор валюты;

- проверка наличия валюты - объект класса Проверка, отвечает за проверку требуемого количества указанной валюты;

- ввод данных о покупателе - объект класса ФормаПродажи, форма для заполнения данных о покупателе;

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

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

1. Кассир создает новую операцию продажи.

2. При этом он открывает необходимую форму для выбора продаваемой валюты.

3. Выбирает в открытой форме валюту и вводит ее количество.

4. Нажимает на клавишу «Проверить».

5. При этом происходит проверка наличие требуемого количества выбранной валюты.

6. Если требуемое количество валюты есть открывается форма для заполнения данных о покупателе.

7. Кассир заполняет поля формы на основании паспорта покупателя.

8. Нажимает на клавишу «Сохранить».

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

Выводы

1. Была разработана диаграмма последовательности для варианта использования «Продажа валюты».

2. При создании диаграммы были созданы четыре класса: два управляющих и два формы».

4 СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА

Диаграммы сотрудничества - второй тип диаграмм взаимодействия - Collaboration Diagram - Г. Буч называет диаграммой объектов. Эта диаграмма не акцентирует внимание на последовательности передачи сообщений, она отражает наличие взаимосвязей вообще, то есть на этой диаграмме отражается наличие сообщений от клиентов к серверам.

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

В курсовом проекте была разработана диаграмма сотрудничества, описывающая продажу валюты (рисунок 4.1). Действующее лицо - Кассир. Используемые объекты:

- форма выбора валюты ( класс - Валюта);

- проверка наличия валюты (класс Проверка);

- форма продажи (класс ФормаПродажи);

- продажа (класс Продажа);

На диаграмму были добавлены следующие сообщения, соотнесенные с операциями:

1. ОткрытьФорму() - создать новую форму продажи валюты.

2. ВыборВалюты() - выбор валюты и ее количества.

3. СохранениеДанных() - нажать на кнопку проверка на форме.

4. НаличиеТребуемойВалюты(String, Double) - проверка наличия требуемой валюты.

5. ОткрытьФорму(String, Double) - создает новую форму продажи.

6. ВводДанныхНаФорму() - ввод паспортных данных покупателя.

7. СохранениеДанных() - нажать на кнопку сохранить на форме.

8. РасчетСуммы(String, Double, String, String, Date) - рассчитывает сумму покупки.

9. РегистрацияОперации() - регистрация проведенной операции в базе данных банка.

10. ПечатьОтчета() - вывод на печать сведений о проведенной операции.

Рисунок 4.1 - Диаграмма сотрудничества

Выводы

1. Была спроектирована диаграмма сотрудничества для варианта использования «Продажа валюты». Во многом от правильности выполнения этого прецедента будет зависеть в дальнейшем успешность оперативного учета и функционирования всей системы в целом.

2. На диаграмму были добавлены десять сообщений, соотнесенные с соответствующими операциями.

5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ

Class diagram (диаграммы классов) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. На диаграммах классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними.

Ознакомившись с классами модели, для более наглядного представления, они были сгруппированы по стереотипу (рисунок 5.1). Стереотипы - это механизм, позволяющий разделять классы на категории. В языке UML основными стереотипами являются: Boundary (граница), Entity (сущность) и Control (управление).В проектируемой подсистеме были созданы следующие пакеты: Boundary (граница) и Control (управление). В эти пакеты были помещены советующие им классы.

Рисунок 5.1 - Диаграмма пакетов

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами. В пакет «Boundaries» были добавлены следующие классы: класс Валюта(форма выбора валюты и ввода её количества) и класс ФормаПродажи(ввод паспортных данных покупателя).

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

Выводы

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

2. Была разработана диаграмма пакетов, являющаяся одной из форм диаграммы классов.

6 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

Рисунок 6.1 - Диаграмма классов для сценария

«ввести новую запись о студенте»

Как видно из диаграммы, для регистрации операции, необходимо ввести следующую информацию(атрибуты класса Продажа):

- Валюта: String - валюта;

- СуммаВ_уе: Double - сумма продоваемой валюты;

- СуммаВ_руб: Double - сумма за продоваемую валюту в рублях;

- ФИО: String - фамилия, имя и отчество покупателя;

- Номер_паспорта: String - номер паспорта;

- Дата: Date - дата.

Назначение и описание основных методов классов были рассмотрены выше, в третьем и четвертом разделах.

Выводы

1. Была разработана диаграмма классов для сценария «Продажа валюты». Как видно из диаграммы, между классами существует определенная семантическая связь.

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

7 СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ

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

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

Многие требования к классу Продажа значительно изменяются при изменении состояния его экземпляра.

На рисунке 7.1 приведена диаграмма состояния для класса Продажа. Этапы создания диаграммы состояний:

1. Найти в браузере класс Продажа.

2. Щелкнуть на классе правой кнопкой мыши и в открывшемся меню указать пункт New->Statechart Diagram (создать диаграмму состояний).

Добавление начального и конечного состояний:

1. Нажать кнопку Start State (Начальное состояние) панели инструментов.

2. Поместить это состояние на диаграмму.

3. Нажать кнопку End State (Конечное состояние) панели инструментов.

4. Поместить это состояние на диаграмму.

Добавление состояний:

1. На панели инструментов нажать кнопку State (Состояние).

2. Поместить состояние на диаграмму.

3. Назвать состояние Инициализация.

4. На панели инструментов нажать кнопку State (Состояние).

5. Поместить состояние на диаграмму.

6. Назвать состояние Отмена операции.

7. На панели инструментов нажать кнопку State (Состояние).

8. Поместить состояние на диаграмму внутрь суперсостояния.

9. Назвать состояние Завершение операции.

10. На панели инструментов нажать кнопку State (Состояние).

11. Назвать состояние Расчет суммы.

Рисунок 7.1 - Диаграмма состояния для класса Zapis

Описание состояний:

1. Дважды щелкнуть мышью на состоянии Инициализация.

2. Перейти на вкладку Detail (Подробно).

3. Щелкнуть правой кнопкой мыши в окне Actions (Действия).

4. В открывшемся меню выберать пункт Insert (Вставить).

5. Дважды щелкнуть мышью на новом действии.

6. Назвать его Получение даты.

7. Убедиться, что в окне When (Когда) указан пункт On Entry (На входе).

8. Повторив шаги 3 -- 7, добавить следующее действие: Определение номера операции, в окне When ук On Entry (На входе).

9. Нажать два раза на ОК, чтобы закрыть спецификацию.

10. Дважды щелкнуть мышью на состоянии Завершение операции.

11. Повторив шаги 2 -- 7, добавить действия:

? Печать отчета, указав On Exit (На выходе);

? Регистрация операции, указав On Entry (На входе).

12. Нажать два раза на ОК, чтобы закрыть спецификацию.

13. Дважды щелкнуть мышью на состоянии Расчет суммы.

14. Повторив шаги со второго по седьмой, добавить действие Расчет суммы в рублях, указав On Entry (На входе).

15. Нажать два раза на ОК, чтобы закрыть спецификацию.

Добавление переходов:

1. Нажать кнопку Transition (Переход) панели инструментов.

2. Щелкнуть мышью на начальном состоянии.

3. Провести линию перехода к состоянию Инициализация.

4. Повторив шаги с первого по третий, создать следующие переходы:

- от состояния Инициализация к состоянию Отмена операции;

- от Расчет суммы к состоянию Завершение операции;

- от состояния Завершение операции к состоянию конечному состоянию;

- от состояния Отмена операции к конечному состоянию;

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

Рисунок 7.2 - Диаграмма компонентов

Вывод

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

8 СОЗДАНИЕ ДИАГРАММЫ РАЗМЕЩЕНИЯ

Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть «железа», а не программ. В прямом переводе с английского Deployment означает «развертывание», но термин «топология» точнее отражает сущность этого типа диаграмм. Иногда диаграммы топологии называют диаграммами размещения.

Рисунок 8.1 - Диаграмма размещения

Добавление узлов к диаграмме размещения:

1. Дважды щелкнув мышью на представлении размещения в браузере, открыть диаграмму размещения.

2. Нажать кнопку Processor (Процессор) панели инструментов.

3. Щелкнув мышью на диаграмме, поместить туда процессор.

4. Ввести имя процессора «Сервер базы данных Банка».

5. Повторив шаги 2--4, добавить следующий процессор «АРМ Кассира пункта обмены валюты».

6. На панели инструментов нажать кнопку Device (Устройство).

7. Щелкнув мышью на диаграмме, поместить туда устройство.

8. Назвать его «Принтер».

Добавление связей:

1. Нажать кнопку Connection (Связь) панели инструментов.

2. Щелкнуть мышью на процессоре «Сервер базы данных Банка».

3. Провести линию связи к процессору «АРМ Кассира пункта обмены валюты».

4. Повторив шаги 1 ? 3, добавить следующую связь от процессора «Сервер базы данных Банка» к устройству «Принтер».

Добавление процессов:

1. Щелкнуть правой кнопкой мыши на процессоре «Сервер базы данных Банка» в браузере.

2. В открывшемся меню выберать пункт New > Process (Создать > Процесс).

3. Ввести имя процесса - MSSQL.exe.

4. Повторить шаги 1 ? 3, добить процесс ПродажаВалюты.exe на процессоре «АРМ Кассира пункта обмены валюты».

Показ процессов на диаграмме:

1. Щелкнуть правой кнопкой мыши на процессоре «Сервер базы данных Банка».

2. В открывшемся меню выбрать пункт Show Processes (Показать процессы).

3. Повторив шаги 1 и 2, показать процесс на процессоре «АРМ Кассира пункта обмены валюты».

Выводы

1. Из диаграммы видно, что информационная подсистема пункта обмена валюты построена на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких операторов ПК к базе данных.

2. Клиентские программы будут работать в нескольких местах. Через локальную вычислительную сеть банка будет осуществляться сообщение этой части программы с сервером базы данных банка.

9 ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++

В результате выполнения курсового проекта была разработана объектно-ориентированная модель информационной подсистемы для пункта обмена валюты. Данная разработка написана с помощью языка UML, с использованием среды разработки - программного продукта Rational Rose 2003.

Были разработаны следующие диаграммы:

- диаграмма прецедентов;

- диаграмма последовательности;

- диаграмма сотрудничества;

- диаграмма классов;

- диаграмма состояния для классов;

- диаграмма компонентов;

- диаграмма размещения.

Основным действующим лицом является кассир. Он выполняет три действия: «Продажа валюты», «Покупка валюты», «Конверсия валюты».

Для более подробного проектирования был выбран вариан использования «Продажа валюты». Для решения этой задачи были созданы четыре класса: два «управляющих» и два «граничных»(Boundaries).

Информационная подсистема пункт обмена валюты на технологии «клиент-сервер». Это позволяет организовать одновременный доступ нескольких пунктов обмена к базе данных банка.

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

Были сгенерированы 8 файлов кода на языке С++ общим размером 2,93 КБ.

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

Спецификация UML не определяет конкретный процесс разработки, поэтому перспективным направлением разработки темы курсового проекта является наполнение сгенерированной модели функциональным кодом.

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

1. Буч Г., Рамбо Д., Джекобсон А. Язык UML для пользователя: Пер. с англ. - М.: ДМК, 2000.- 432 с., ил. (Серия «для программистов»).

2. Боггс У., Боггс М.. UML и Rational Rose: Пер. с англ. - М.: Издательство «Лори», 2000.- 581 с., ил.

3. Буч Г., Рамбо Д., Джекобсон А. UML: специальный справочник. - СПб.: Питер, 2002.- 432 с., ил.

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

5. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам

6. ГОСТ 2.004-88 ЕСКД. Общие требования к выполнению конструкторских и технологических документов на печатающих и графических устройствах ввода ЭВМ

7. ГОСТ 2.104-68 ЕСКД. Основные надписи

8. ГОСТ 2.106-68 ЕСКД. Текстовые документы

9. ГОСТ 2.109-73 ЕСКД. Основные требования к чертежам

10. ГОСТ 2.301-68 ЕСКД. Форматы

Приложение А

Листинги кода приложения пункт обмена валюты, сгенерированные Rational Rose на языке С++

A.1 Листинг файла Валюта.h

#ifndef ВАЛЮТА2_H_HEADER_INCLUDED_B2066042

#define ВАЛЮТА2_H_HEADER_INCLUDED_B2066042

//##ModelId=4DE4AE1503C8

class Валюта

{

public:

//##ModelId=4DE4B78402FD

ОткрытьФорму();

//##ModelId=4DF22E4A03D9

СохранениеДанных();

private:

//##ModelId=4DF2312401F8

String Валюта;

//##ModelId=4DF23E8202AA

Date Дата;

//##ModelId=4DF23F8D0341

Double СуммаВ_уе;

};

#endif /* ВАЛЮТА2_H_HEADER_INCLUDED_B2066042 */

A.2 Листинг файла Валюта.cpp

#include "Валюта.h"

//##ModelId=4DE4B78402FD

Валюта::ОткрытьФорму()

{

}

//##ModelId=4DF22E4A03D9

Валюта::СохранениеДанных()

{

}

A.3 Листинг файла Проверка.h

#ifndef ПРОВЕРКА2_H_HEADER_INCLUDED_B2064898

#define ПРОВЕРКА2_H_HEADER_INCLUDED_B2064898

//##ModelId=4DE4B1F1009C

class Проверка

{

public:

//##ModelId=4DE4B2140167

Boolean НаличиеТребуемойВалюты(String Валюты, Double СуммаВ_уе);

};

#endif /* ПРОВЕРКА2_H_HEADER_INCLUDED_B2064898 */

A.4 Листинг файла Проверка.cpp

#include "Проверка.h"

//##ModelId=4DE4B2140167

Boolean Проверка::НаличиеТребуемойВалюты(String Валюты, Double СуммаВ_уе)

{

}

A.5 Листинг файла Продажа.h

#ifndef ПРОДАЖА2_H_HEADER_INCLUDED_B2062574

#define ПРОДАЖА2_H_HEADER_INCLUDED_B2062574

//##ModelId=4DF22026003E

class Продажа

{

public:

//##ModelId=4DF221850195

Currency РасчетСуммы(Single Валюта, Double СуммаВ_уе, String ФИО, String Номер_паспорта, Date Дата);

private:

//##ModelId=4DF221CA000E

РегистрацияОперации();

//##ModelId=4DF221E60204

ПечатьОтчета();

//##ModelId=4DF2360E0361

Integer Номер_операции;

//##ModelId=4DF2359F0376

String Валюта;

//##ModelId=4DF2359600A7

Double СуммаВ_уе;

//##ModelId=4DF2357C039E

Double СуммаВ_руб;

//##ModelId=4DF9A7F90227

String ФИО;

//##ModelId=4DF9A80B0165

String Номер_пвспорта;

//##ModelId=4DF9A963039C

Date Дата;

};

#endif /* ПРОДАЖА2_H_HEADER_INCLUDED_B2062574 */

A.6 Листинг файла Продажа.cpp

#include "Продажа.h"

//##ModelId=4DF221850195

Currency Продажа::РасчетСуммы(Single Валюта, Double СуммаВ_уе, String ФИО, String Номер_паспорта, Date Дата)

{

}

//##ModelId=4DF221CA000E

Продажа::РегистрацияОперации()

{

}

//##ModelId=4DF221E60204

Продажа::ПечатьОтчета()

{

}

A.7 Листинг файла ФормаПродажи.h

#include "ФормаПродажи.h"

//##ModelId=4DE4B40201B5

ФормаПродажи::ОткрытьФорму(String Валюта, Double СуммаВ_уе)

{

}

//##ModelId=4DE4B51F00EA

ФормаПродажи::СохранениеДанных()

{

}

A.8 Листинг файла ФормаПродажи.cpp

#ifndef ФОРМАПРОДАЖИ2_H_HEADER_INCLUDED_B2062B10

#define ФОРМАПРОДАЖИ2_H_HEADER_INCLUDED_B2062B10

//##ModelId=4DE4B321001F

class ФормаПродажи

{

public:

//##ModelId=4DE4B40201B5

ОткрытьФорму(String Валюта, Double СуммаВ_уе);

//##ModelId=4DE4B51F00EA

СохранениеДанных();

private:

//##ModelId=4DF232EB01FE

String Валюта;

//##ModelId=4DF233D603B2

Double СуммаВ_уе;

//##ModelId=4DF724FA037A

String ФИО;

//##ModelId=4DF7253E03B9

String Номер_паспорта;

};

#endif /* ФОРМАПРОДАЖИ2_H_HEADER_INCLUDED_B2062B10 */

Размещено на Allbest.ru