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

Размещено на http://www.allbest.ru/

Содержание

ВВЕДЕНИЕ

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

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

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

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

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

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

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

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

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

ЗАКЛЮЧЕНИЕ

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

ПРИЛОЖЕНИЕ

ВВЕДЕНИЕ

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

Rational Rose 2000 имеет достаточно простой и интуитивно понятный интерфейс пользователя, позволяющий создавать модели сложных программных продуктов с помощью унифицированного языка программирования UML

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

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

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

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

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

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

В разделе пять описывается диаграмма классов для прецедента "Открыть вклад".

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

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

программа валютный вклад прецедент

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

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

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

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

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

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

ВЫВОД:

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

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

Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграммы позволяет отразить последовательность передачи сообщений между объектами, акцентирует внимание на временной упорядоченности сообщений. Диаграммы последовательности отражают поток событий, происходящих в рамках варианта использования. Например, вариант использования "Открыть вклад" предусматривает несколько возможных последовательностей, таких как вести вариант вклада или вести неправильный вариант вклада . Ввод данных о открытие вклада представлен на данной диаграмме последовательностей. Под сценарием понимается конкретный экземпляр потока событий. Эта диаграмма последовательности отображает поток событий в рамках варианта использования "Открыть вклад" (рисунок А.2). Проанализировав составные части системы, наглядно видно, что наиболее главная задача работы банковского работника это ввод данных о вкладах. Получив всю нужную информацию, составляем описание сценариев: Банковский работник создает новый вклад. Банковский работник вводит данные в базу данных. Банковский работник вводит данные в базу данных, но при ее сохранении в базе данных возникает ошибка. Действующее лицо на диаграмме - Банковский работник. Используемые объекты: Выбор вклада ( класс - Vinvestment), Форма вклада (класс F Investment), Вклад №0055, Управляющий вкладами(класс - Mgrbivestment), Управляющий транзакциями (класс - Mgr Transactions). Т.к. все взаимодействие в объектно-ориентированных системах осуществляется при помощи сообщений между объектами, то классы должны позволять отправку или прием сообщений. При обмене сообщениями одни классы являются клиентами и принимают сообщения, а другие - серверами и отправляют сообщения. На диаграмме присутствуют следующие сообщения, которые сообщения соотнесены с операциями:

1. Создать() Создать новую форму вклада. Между Банковским работником и объектом Выбор вклада.

2. Открытъ(). Открыть форму вклада. Между объектом Выбор вклада и Форма вклада.

3. Ввести номер(). между Банковским работником и объектом Форма вклада.

4. Сохранить(). Между Банковским работником и объектом Форма вклада.

5. Сохранить(). Между объектами Форма вклада и Управляющий вкладами.

6. Создать(). Между объектами Управляющий вкладами и Вклад №0055.

7. Ввести номер(). Между объектами Управляющий вкладами и Вклад №0055.

8. Сохранить(). Между объектами Управляющий вкладами и Упрвляющий транзакциями.

9. Информация(). Между объектами Вклад№0055 и Управляющий транзакциями.

10. Message to Self (Сообщение себе) - Сохранить( ) объекту Управляющий транзакциями.

ВЫВОД:

Данная объектно-ориентированная модель информационной подсистемы, должна отражать поток событий, происходящие в рамках варианта использования "Открыть вклад".

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

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

У диаграмм сотрудничества есть два свойства, которые отличают их от диаграмм последовательности:

1. Наличие пути. Для описания связи одного объекта с другим к дальней концевой точке этой связи можно присоединить стереотип пути (например, local, показывающий, что помеченный объект является локальным по отношению к отправителю сообщения). Имеет смысл явным образом изображать путь связи только в отношении путей типа local, parameter, global и self (но не associations).

2. Порядковый номер сообщения. Для обозначения временной последовательности перед сообщением можно поставить номер (нумерация начинается с единицы), который должен постепенно возрастать для каждого нового сообщения. Для обозначения вложенности сообщений используется десятичная нотация Дьюи (1-первое сообщение; 1.1-первое сообщение, вложенное в сообщение 1; 1.2- второе сообщение, вложенное в сообщение 1). В данном проекте была разработана диаграмма сотрудничества, описывающая ввод новой ведомости в систему отражающую учет успеваемости студентов. Действующее лицо - Банковский работник. Используемые объекты: Выбор вклада (класс- ВВклада), Форма вклада (класс Ф Вклада), Вклад № 675979 (класс Вклад), Управляющий транзакциями, Управляющий Вкладами (класс Упр Вкладами). На диаграмму были добавлены следующие сообщения, соотнесенные с операциями:

1. Создать() Создать новую форму договора. Между Банковским работником и объектом Выбор вклада.

2. Открыть(). Открыть форму вклада. Между объектом Выбор вклада и объектом Форма вклада.

3. Ввести номер( ) между Банковским работником и объектом Форма вклада.

4. Сохранить(). Между Банковским работником и объектом Форма вклада.

5. Сохранить () Между объектами Форма вклада и. Управляющий вкладами.

6. Создать( ) Между объектами Управляющий вкладами и Вклад №0055.

7. Ввести номер( ). Между объектами Управляющий вкладами и Вклад №0055.

8. Сохранить( ). Между объектами Управляющий вкладами и Управляющий транзакциями.

9. Информация( ). Между объектами Управляющий транзакциями и Вклад №0055 .

10. Message to Self (Сообщение себе) - Сохранить БД() объекту Управляющий транзакциями.

ВЫВОД:

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

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

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

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

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

Наконец, применяют комбинацию двух указанных подходов. Для дальнейшей организации классов разрешается вкладывать пакеты друг в друга. На высоком уровне абстракции можно сгруппировать классы по функциональности, создав пакет Security. Внутри него можно создать другие пакеты, сгруппировав отвечающие за безопасность классы по функциональности или по стереотипу. Ознакомившись с классами модели, объединим эти классы в пакеты по стереотипу. Были созданы следующие пакеты: Entities (Сущности), Boundaries (Границы) и Control (Управление). В эти пакеты были помещены советующие им классы (рисунок А.4).

Классы-сущности (entity classes) отражают основные понятия (абстракции) предметной области и, как правило, содержат хранимую информацию. В данный пакет были добавлены класса Вклад и ВкладВалюты.

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

Граничные классы (boundary classes) - позволяют действующему лицу взаимодействовать с системой. Каждому взаимодействию между действующим лицом и вариантом использования должен соответствовать по крайней мере один граничный класс. В данном проекте в этот пакет с включены следующие классы УпрВкладами и УпрТранзакциями.

Граничные классы (boundary classes) - это классы, которые расположены на границе системы и окружающей среды. Они включают все формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

В данной модели была создана диаграмма классов (рисунок А.4) для сценария "Открыть новый вклад".

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

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

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

В данный проект был добавлен вспомогательный класс Vedomostitem. Он предназначен для того, чтобы облегчить контроль вводимых данных. С этой целью данному классу были добавлены следующие атрибуты:

HoмepBклaдa(Integer),ДaнныKлиeнтa(String),ДaтaBклaдa(Date),ЗaпoлнитьДaтy Вклада (Date). В этот класс были так же добавлены следующие операции: создать (создание вклада), ввести номер (добавление информации), информация (просмотр информации).

ВЫВОД: В данной объектно-ориентированной модели информационной подсистемы, к описаниям операций добавили детали, включая параметры, типы возвращаемых значений и определили атрибуты классов.

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

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

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

Проектируя класс Вклад, видно, что за его поведением нужно наблюдать. Многие требования к классу значительно изменяются при изменении состояния его экземпляра. Чтобы убедиться, что проект удовлетворяет всем требованиям, создается диаграмма состояний для класса Вклад. С ее помощью В проекте была создана диаграмма состояния (Приложение А, рисунок 5).

На диаграмме используются следующие состояния:

1. Начальное состояние

2. Конечное состояние

3. Отменен.

4. Выполнен

5. Инициализация

6. Вложения вклада приостановлено

Использованы следующие переходы:

1. От состояния "Начальное состояние" к состоянию "Инициализация"

2. От состояния "Инициализация" к состоянию "Вложение вклада" приостановлено

3. От состояния "Вложение вклада" приостановлено к состоянию Выполнен.

4. От суперсостояния "Вложения вклада" приостановлено к состоянию "Отменен".

5. От состояния "Отменен" к конечному состоянию.

6. От состояния "Выполнен" к конечному состоянию.

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

На главной диаграмме компонентов системы отражаются три пакета создаваемых компонентов (Приложение А, рисунок 6): Entities, Control, Boundaries. Все компоненты этих пакетов содержат классы соответствующего пакета логической системы.

На диаграмма System (Приложение А, рисунок 5) показаны все компоненты системы, а также все зависимости между всеми компонентами проектируемой системы.

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

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

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

Каждый узел на диаграмме размещения представляет собой некоторый тип вычислительного устройства - в большинстве случаев часть аппаратуры. Эта аппаратура может быть простым устройством или датчиком, а может быть и мэйнфреймом. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. В нашем примере банковская система состоит из большого количества подсистем, выполняемых на отдельных физических устройствах, или узлах (node). Диаграмма размещений для данного проекта (Приложение А, рисунок 7) показывает физическое размещение системы. Клиентские программы будут работать в нескольких местах.. Через закрытые сети будет осуществляться сообщение этой части программы с главным сервером системы, с работающим программным обеспечением. В свою очередь, главный сервер посредством локальной сети будет сообщаться с сервером базы данных, используемой в кассе и работающей под управлением FoxPro. Наконец, с главным сервером соединен принтер.

ВЫВОД:

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

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

На основании созданных моделей компонентов, представленных в данном проекте была произведена генерация программного кода для клиентской части приложения. Для генерации программного кода был выбран язык C++. Фрагмент сгенерированного Rational Rose листинга кода приложения на языке C++ приведен в приложении Б.

ЗАКЛЮЧЕНИЕ

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

Представлена основная характеристика предметной области.

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

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

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

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

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

4. Кураев Е.А. Банковские системы: Издательский дом "Глория", 2002.-225 с.,ил (Валютные операции с вкладами)

5. Родионова В.М. Банковские операции: Под ред. Родионовой В.М.,2001 .- 112с,ил (Валютные операции с вкладами)

Приложение А

Основные диаграммы UML

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



Рисунок А.2 - Диаграмма последовательности



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



Рисунок А.4 - Диаграмма классов



Рисунок А.5 - Диаграмма состояний для классов



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

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

Приложение Б

Листинг кода приложения на языке С++

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