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

Министерство образования и науки Российской Федерации ГОУ ВПО СЕВЕРО-КАВКАЗСКИЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ Факультет информационных технологий и телекоммуникаций Кафедра прикладной информатики

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

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

Разработка объектно-ориентированной модели информационной

подсистемы для пункта обмена валюты

информационная подсистема обмен валюта программный

Автор курсового проекта: Марченко Фёдор Сергеевич

Направление: 80 800.62 «Прикладная информатика»

шифр, наименование

Группа: ПИБ-081

Обозначение курсового проекта

КП-СевКавГТУ-80 800.62−61 833−11

Руководитель проекта: к.т.н., доцент В.Ф. Ляхов_

подпись, дата, инициалы, фамилия

Ставрополь, 2011

Содержание

• ВВЕДЕНИЕ
• 1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ
• 1.1 Общая характеристика
• 1.2 Актуальность разрабатываемой подсистемы
• 1.3 Формулировка задач проектирования
• 2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ
• 3 СОЗДАНИЕ ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ
• 4 СОЗДАНИЕ ДИАГРАММЫ СОТРУДНИЧЕСТВА
• 5 СОЗДАНИЕ ДИАГРАММЫ КЛАССОВ
• 6 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ
• 7 СОЗДАНИЕ ДИАГРАММЫ СОСТОЯНИЙ ДЛЯ КЛАССОВ И ДИАГРАММЫ КОМПОНЕНТОВ
• 9 ГЕНЕРАЦИЯ ПРОГРАММНОГО КОДА C++
• ЗАКЛЮЧЕНИЕ
• БИБЛИОГРАФИЧЕСКИЙ СПИСОК
• Приложение А

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, информационных систем, организационно-экономических систем, технических систем и других систем различной природы.

Разработка языка UML преследовала несколько различных целей. Прежде всего, UML создавался как язык моделирования общего характера. UML не является частной собственностью, он основан на соглашении большинства специалистов в компьютерной области. В него были включены основные понятия из наиболее известных методологий, поэтому он может использоваться совместно с ними. Как минимум UML заменяет модели Object Modeling Technique (OMT), модель Буча и Objectory, а также модели других разработчиков UML. UML разрабатывался для поддержки таких ценных наработок проектирования, как инкапсуляция, разделение сущностей и выявление сути конструкции модели. UML отвечает требованиям современной разработки программного обеспечения, в том числе таким, как крупномасштабность, параллелизм, распределенность, возможность использования образцов и удобство при командной работе.

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

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

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

В третьем разделе пояснительной записки рассматривается создание диаграммы последовательности (sequence diagrams). Данная диаграмма предназначенная для моделирования процесса обмена сообщениями между объектами;

В разделе четыре рассматривается диаграмма сотрудничества для прецедента информационной подсистемы «Добавить новую запись о студенте».

В пятом разделе описывается диаграмма классов для прецедента «Добавление новой записи».

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

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

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

В девятом разделе пояснительной записки приводится и описывается порядок генерации программного кода на языке С++ для данной информационной подсистемы.

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

В приложение вынесены листинги кода проектируемой программы, сгенерированные RationalRose.

1 КРАТКАЯ ХАРАКТЕРИСТИКА ПРЕДМЕТНОЙ ОБЛАСТИ

1.1 Общая характеристика

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

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

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

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

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

— Продажа валюты иностранного государства клиенту за национальную валюту;

— Покупка у клиента валюты иностранного государства за национальную валюту;

— Коверсия (обмен) валюты одного иностранного государства на валюту другого иностранного государства.

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

2 СОЗДАНИЕ ДИАГРАММЫ ПРЕЦЕДЕНТОВ

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

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

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

На рисунке 2.1 приведена диаграмма использования, спроектированная в среде RationalRose. Основным действующим лицом (актером) является кассир. Он выполняет три основных действия:

— продажа валюты;

— покупка валюты;

— конверсия валюты.

Для создания диаграммы прецедентов:

1. Запустим интегрированную среду разработки Rational Rose 2003.

2. Перейдем к главной диаграмме (Main) Use case:

— в браузере щелкнем на значке «+» рядом с представлением Use case, чтобы открыть представление;

— дважды щелкнув на главной диаграмме, откроем её.

3. С помощью кнопки Use Case (вариант использования) панели инструментов поместим на диаграмму новый вариант использования.

4. Назовем его «Продажа валюты».

5. Повторив этапы 3 и 4, поместим на диаграмму остальные варианты использования:

— покупка валюты;

— конверсия валюты.

6. С помощью кнопки Actor (действующее лицо) панели инструментов поместим на диаграмму новое действующее лицо.

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

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

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

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

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

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

Выводы

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

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

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

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

Рассмотрим вариант использования «Продажа валюты». Диаграмма последовательности приведена на рисунке 3.1.

Рисунок 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 ДОБАВЛЕНИЕ ДЕТАЛЕЙ К ОПИСАНИЯМ ОПЕРАЦИЙ И ОПРЕДЕЛЕНИЕ АТРИБУТОВ КЛАССОВ

После того как была, разработана диаграмма классов для варианта использования «Продажа валюты», начинается ее заполнение. В качестве языка программирования был выбран C++, что позволило добавить к классам параметры операций, типы данных и типы возвращаемых значений.

Атрибут — это элемент информации, связанный с классом. Они содержатся внутри класса, поэтому они скрыты от других классов. В связи с этим иногда требуется указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility). Для определения атрибутов и операций классов было произведено обращение к потоку событий. В результате к классам были добавлены дополнительные атрибуты и связи между классами (рисунок 6.1).

Рисунок 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++

Язык С++ является одним из наиболее широко применяемых на практике объектно-ориентированных языков. Rational Rose интегрируется с С++ посредством генерации кода и обратного проектирования. В Rational Rose 2003 предусмотрена возможность генерации программного кода С++.

Для генерации программного кода на стандартном С++ необходимо:

1. Создать компоненты (необязательно).

2. Определить компоненты для классов (необязательно).

3. Установить свойства генерации программного кода (необязательно).

4. Выбрать класс или компонент для генерации на диаграмме Классов или Компонентов.

5. Выбрать в меню Tools -> С++ -> Code Generation.

6. Выбрать в меню Tools -> С++ -> Browse Header или Browse Body для просмотра сгенерированного программного кода.

Первый этап процесса генерации программного кода — создание компонентов для классов. Это файлы с расширениями *.срр (файл реализации) и *.h (заголовочный файл). В С++ данный этап не является обязательным. Если не описать компоненты, Rational Rose сгенерирует файлы *.срр и *.h для каждого класса. Тем не менее, настоятельно рекомендуется создавать компоненты, что позволит управлять отображением классов на компоненты и моделировать зависимости между компонентами.

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

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

Выводы

1. На основании созданных моделей компонентов, представленных в проекте была произведена генерация программного кода на языке C++.

2. Листинги сгенерированного Rational Rose кода приложения для пункта обмена валюты на языке С++ приведены в Приложении А. Общий размер сгенерированных файлов составляет 2,93 КБ.

ЗАКЛЮЧЕНИЕ

В результате выполнения курсового проекта была разработана объектно-ориентированная модель информационной подсистемы для пункта обмена валюты. Данная разработка написана с помощью языка 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 */