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

АВТОНОМНАЯ НЕКОММЕРЧЕСКАЯ ОРГАНИЗАЦИЯ

«ПРОФЕССИОНАЛЬНАЯ ОБРАЗОВАТЕЛЬНАЯ ОРГАНИЗАЦИЯ»

«ФИНАНСОВО-ЭКОНОМИЧЕСКИЙ КОЛЛЕДЖ»

КУРСОВАЯ РАБОТА

По дисциплине Проектирование и дизайн информационных систем

На тему Банкомат

Студент 2 курса 234Ф-9

САДАЕВ Али

Руководитель: Парий Б.С.



Содержание

• Введение

1. Анализ предметной области

2. Работа над проектом в среде Rational Rose

2.1 Разработка диаграммы вариантов использования

2.2 Анализ вариантов использования и разработка диаграммы классов

2.3 Разработка диаграммы состояний

2.4 Разработка диаграммы последовательности

2.5 Разработка кооперативной диаграммы

2.6 Разработка диаграммы развертывания

2.7 Разработка диаграмм состояний деятельности компонентов и размещения

Заключение



Введение

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

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

UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

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

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

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



1. Анализ предметной области

программный банкомат диаграмма обеспечение

Банкомат или ATM (Automatic Teller Machine) - это электронно-механическое устройство, предназначенное для выдачи и приема денежных средств, имеющее постоянную связь с процессинговым центром банка и выполняющее все финансовые операции с карточным счетом клиента в режиме online.

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

Сейфовая часть банкомата состоит непосредственно из самого сейфа, кодового замка (они бывают механические и электронные), диспенсора (устройства выдачи денег), находящегося внутри сейфа. Диспенсоры различают в зависимости от принципа работы с купюрой, механизма выдачи и количества кассет. В банкоматах фирмы NCR для извлечения купюры из кассеты используется специальные вакуумные присоски, в то время как в банкоматах Wincor Nixdorf и Diebold для этой цели служат резиновые ролики со специальным рисунком протектора. Наиболее распространены диспенсоры с четырьмя кассетами, однако существуют и другие конфигурации с количеством кассет от двух до шести. В кассету помещается до трех тысяч купюр, причем кассета может быть настроена под любую купюру, благодаря наличию в ней специальных направляющих, позволяющих регулировать их высоту и ширину. Информация о номинале и валюте банкноты хранится в специальной флэш-карте на самой кассете и заносится туда при первом использовании кассеты в банкомате.

Рассмотрим механизм выдачи денег. После того, как клиент вставил карту, ввел пин-код и выбрал нужную операцию, идет запрос в процессинговый центр банка, выпустившего карту. Проверяется состояние карточного счета, и, если он не заблокирован и там есть требуемая сумма, банкомату дается команда на выдачу денег. Далее банкомат в соответствии с алгоритмом выдачи набирает необходимое количество купюр в стекере (накопительном устройстве), после чего вся сумма выдается клиенту. Следует отметить, что на пути купюры от кассеты к клиенту находится большое количество датчиков, отслеживающих перемещение купюры. Основным «фильтром» является датчик Double Detect, который проверяет следующие параметры: перекос, наличие слипшихся купюр, загнутые края, толщину. Если купюра не проходит отбор, она попадает в специальную диверт-кассету, которая является хранилищем отбракованных купюр. В случае, если купюра застряла в транспортном пути, либо какое-либо устройство, участвующие в выдаче денег, неисправно, банкомат прекращает работу и выдает соответствующее сообщение об ошибке.

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



2. Работа над проектом в среде Rational Rose

Исходным шагом разработки нового проекта является создание отдельных моделей или представлений в контексте построения канонических диаграмм.

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

2.1 Разработка диаграммы вариантов использования

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

Действующие лица:

Клиент банка - вставляет карту в банкомат.

Система идентификации - проверяет наличие данных о карте.

В среде Rational Rose диаграммы вариантов использования создаются в представлении вариантов использования. Главная диаграмма (Main) предлагается по умолчанию. Для моделирования системы можно затем разработать необходимое количество дополнительных диаграмм.

Построенная диаграмма вариантов использования представлена на



Рисунок 1 Разработка диаграммы варианта использования «Наличие карты в банкомате» в среде Rational Rose

Вариант использования «Снять наличные» позволяет клиенту снять деньги со своего счета.

Основной поток:

1. Вариант начинается, когда клиент вставляет свою карточку в приемник кредитных карт;

2. Банкомат выдает на дисплей приглашение ввести персональный код;

3. Клиент вводит код;

4. Банкомат проверяет введенный код. Если код введен неверно, клиенту предоставляется еще 2 попытки. В случае повторных неудач выполняется альтернативный поток событий А1;

5. Банкомат предлагает пользователю выбрать операцию:

o Узнать остаток по счету,

o Снять наличные.

6. Клиент выбирает «Снять наличные»;

7. Банкомат предлагает указать сумму;

8.

9. Клиент вводит требуемую сумму;

10. Банкомат запрашивает подтверждение на печать справки;

11. Клиент подтверждает;

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

13. Банкомат выводит на дисплей сообщение «Выньте карту»;

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

15. Банкомат печатает справку, если она затребована клиентом;

16. Вариант завершается.

Альтернативный поток А1. Трехкратный неправильный ввод PIN кода:

1. Банкомат информирует клиента, что карта будет перемещена в хранилище карт;

2. Сеанс обслуживания заканчивается;

3. Вариант использования завершается;

Альтернативный поток А2. Недостаточно денег в банкомате:

1. Банкомат информирует клиента, что денег в хранилище недостаточно;

2. Банкомат возвращает клиенту карту;

3. Вариант использования завершается.

Вариант использования «Узнать остаток по счету» позволяет клиенту узнать баланс своего банковского счета

Основной поток:

1. Вариант начинается, когда клиент вставляет свою карточку в приемник кредитных карт;

2. Банкомат выдает на дисплей приглашение ввести персональный код;

3. Клиент вводит код;

4. Банкомат проверяет введенный код. Если код введен неверно, клиенту предоставляется еще 2 попытки. В случае повторных неудач выполняется альтернативный поток событий А1;

5. Банкомат предлагает пользователю выбрать операцию:

o Узнать остаток по счету,

o Снять наличные.

6. Клиент выбирает «Узнать остаток по счету»;

7. Банкомат запрашивает подтверждение на печать справки;

8. Клиент подтверждает;

9. Банкомат посылает запрос на снятие центральному компьютеру банка;

10. Банкомат выводит на дисплей остаток;

11. Банкомат выводит на дисплей сообщение «Выньте карту»;

12. После удаления карточки из приемника банкомат печатает справку, если она затребована клиентом;

13. Вариант завершается.

Альтернативный поток А1. Трехкратный неправильный ввод PIN кода.

1. Банкомат информирует клиента, что карта будет перемещена в хранилище карт;

2. Сеанс обслуживания заканчивается;

3. Вариант использования завершается.

2.2 Анализ вариантов использования и разработка диаграммы классов

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

· граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо - вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации);

· классы-сущности (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования;

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

· Пример набора классов, участвующих в реализации варианта использования «Наличие карты в банкомате», приведен на рисунке 2.

Пример набора классов, участвующих в реализации варианта

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

· эта диаграмма появляется по умолчанию в окне диаграммы после создания нового проекта;

· щелкнуть на кнопке с изображением диаграммы классов на стандартной панели инструментов;

· раскрыть логическое представление в браузере (Logical View) и дважды щелкнуть на пиктограмме Main (Главная);

· через пункт меню Browse->Class Diagram (Браузер->Диаграмма классов).

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

Рисунок 2 Пример графического изображения диаграммы классов в унифицированной нотации

Клиент:

Объекты класса Клиент создаются для каждого клиента, который вставляет карточку в банкомат

Поля класса Клиент:

· Номер карты;

· PIN код - PIN код, который вводит клиент;

· Печать - клиент подтверждает печать справки;

· Операция - выбранная клиентом операция.

Банкомат:

Поля класса Банкомат:

· Количество денег в хранилище;

· Карта вставлена - логическая переменная.

Методы класса Банкомат:

· Проверить PIN код - сверяет PIN код клиента с PIN кодом счета, в случае несовпадения предлагает клиенту ввести PIN код повторно;

· Поместить карту в хранилище - метод срабатывает при трехкратном неправильном вводе PIN кода;

· Выдать деньги - аргументом принимает сумму, введенную клиентом, выдает нужную сумму в случае достаточного количества денег в хранилище;

· Напечатать справку - принимает три аргумента: запрос на печать справки, операцию, выбранную клиентом и баланс;

· Выдать карту - завершает сеанс обслуживания.

Счет:

Объекты класса Счет создаются для каждой новой карты, вставленной в банкомат

Поля класса Счет:

· Номер счета,

· Баланс,

· PIN код счета.

Методы класса Счет:

· Уменьшить баланс - уменьшает остаток по счету на сумму, введенную клиентом; аргументом принимает сумму

Дисплей:

Методы класса Дисплей:

· Запросить сумму - принимает аргументом сумму, запрошенную клиентом;

· Отобразить остаток по счету - принимает аргументом баланс счета.

Описание отношений классов:

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

Рисунок 3 Диаграмма классов

2.3 Разработка диаграммы состояний

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

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

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

· Раскрыть логическое представление в браузере (Logical View), выделить рассматриваемый класс и выбрать пункт контекстного меню Open State Diagram (Открыть диаграмму состояний), раскрывающегося по щелчку правой кнопкой мыши.

· Через пункт меню Browse->State Diagram (Браузер->Диаграмма состояний).

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

Рисунок 4 Пример графического изображения диаграммы активности

2.4 Разработка диаграммы последовательности

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

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

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

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

Через пункт меню Browse->Interaction Diagram (Браузер->Диаграмма взаимодействия).

Рисунок 5 Диаграмма последовательности

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

· Снять наличные,

· Узнать остаток по счету.

Эта диаграмма последовательности показывает поток событий в рамках варианта использования «Узнать остаток по счету».



Рисунок 6 Диаграмма последовательности «Узнать остаток по счету»

Объекты:

· Клиент,

· Приемник банковских карт,

· Дисплей,

· Программа управления банкоматом,

· Счет клиента,

· Принтер для печати справок.

Сообщения:

1. Поместить карту,

2. Распознать карту,

3. Отобразить экран,

4. Запросить PIN код,

5. Ввести PIN код,

6. Проверить PIN код,

7. Открыть счет,

8. Запросить операцию,

9. Выбор операции (узнать остаток по счету),

10. Запросить остаток по счету,

11. Отобразить остаток,

12. Запросить подтверждение печати справки,

13. Подтвердить печать справки,

14. Напечатать справку,

15. ВЕРНУТЬ КАРТУ

Эта диаграмма последовательности показывает поток событий в рамках варианта использования «Снять деньги»

Рисунок 7 Диаграмма последовательности «Снять наличные» клиент информационный банкомат

Объекты:

· Клиент,

· Приемник банковских карт,

· Дисплей,

· Программа управления банкоматом,

· Счет клиента,

· Лоток для выдачи денег,

· Принтер для печати справок.

Сообщения:

1. Поместить карту,

2. Распознать карту,

3. Отобразить экран,

4. Запросить PIN код,

5. Ввести PIN код,

6. Проверить PIN код,

7. Открыть счет,

8. Запросить операцию,

9. Выбор операции (узнать остаток по счету),

10. Запросить сумму,

11. Ввод суммы,

12. Снять запрошенную сумму,

13. Проверить вклад,

14. Уменьшить вклад,

15. Запросить подтверждение печати справки,

16. Подтвердить печать справки,

17. Выдать деньги,

18. Напечатать справку,

19. Вернуть карту.

2.5 Разработка кооперативной диаграммы

Для создания кооперативной диаграммы достаточно открыть диаграмму последовательности и нажать клавишу F5.

Далее необходимо определить обязанности (responsibilities), атрибуты и ассоциации классов Обязанность (responsibility) - действия, которые объект обязан выполнять по запросу других объектов. Обязанность преобразуется в одну или более операций класса на шаге проектирования. Обязанности определяются, исходя из сообщений на диаграммах взаимодействия, и документируются в классах в виде операций «анализа», которые появляются там автоматически в процессе построения диаграмм взаимодействия (соотнесения сообщений с операциями). Так, диаграмма классов VOPC (classes only) после построения диаграмм взаимодействия должна принять вид

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

Перед добавлением атрибутов к классам необходимо выполнить предварительные настройки:

1) в меню модели выберите пункт меню Tools -> Options;

2) перейдите на вкладку Diagram;

3) убедитесь, что переключатель Show All Attributes помечен;

4) убедитесь, что переключатели Suppress Attributes и Suppress Operations не помечены.



Рисунок 8 Пример графического изображения диаграммы развертывания

2.6 Разработка диаграммы развертывания

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

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

Диаграмма состояний приведена на рисунке 9.



Рисунок 9 Пример графического изображения диаграммы развертывания

2.7 Разработка диаграмм состояний, деятельности, компонентов и размещения

Диаграмма состояний для класса «Банкомат» представлена на рисунке 10.

Рисунок 10 Диаграмма состояний

Банкомат может принимать следующие состояния:

· Ожидание карточки;

· Ожидание ввода PIN кода - после того, как карта вставлена;

· Проверка PIN кода - после ввода PIN кода;

· Ожидание выбора операции - после проверки PIN кода;

· Обработка запроса на снятие наличных - когда выбрана операция «Снять наличные»;

· Выдача наличных;

· Отображение остатка по счету - когда выбрана операция «Отобразить остаток по счету»;

· Печать - если запрошена печать справки;

· Возврат карточки;

· Завершение транзакции.

Диаграмма деятельности представлена на рисунке 11.



Рисунок 11 Диаграмма деятельности

1. Клиент вставляет карточку;

2. Клиент вводит PIN код;

Если PIN код введен неверно 3 раза, то карта перемещается в хранилище карт и обслуживание клиента завершается

1. Клиент выбирает действие;

2. Если выбрана операция «Снять наличные», клиенту предлагается ввести сумму;

3. Если сумма не превышает остаток на карте, то происходит выдача наличных;

4. Печать справки, если было запрошено;

5. Клиент получает карту.

Диаграмма компонентов представлена на рисунке 12.

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

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

Диаграмма размещения представлена на рисунке 13.

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

Диаграмма состоит из следующих компонентов:

1. Банкомат, он соединен защищенным каналом связи с региональным сервером;

2. Региональный сервер;

3. Сервер базы данных центрального банковского компьютера.



Заключение

starUML - программный инструмент моделирования, который поддерживает UML (Унифицированный язык моделирования). StarUML ориентирован на UML версии 1.4 и поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0. Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя концепцию профилей UML. Среда разработки StarUML ™ превосходно настраивается в соответствии с требованиями пользователя и имеет высокую степень расширяемости, особенно в области своих функциональных возможностей. Использование StarUML, одного из ведущих программных инструментов моделирования, гарантирует достижение максимальной производительности и качества ваших программных проектов.

* Диаграмма классов (Сlass diagram). Диаграмма классов - визуальное отображение различных статических отношений между класс-подобными элементами. Диаграмма классов может содержать не только классы, но также и интерфейсы, перечислимые типы, пакеты, различные отношения, инстанции и их связи.

* Диаграмма прецедентов (Use case diagram). Диаграмма прецедентов - отображение отношений между вариантами использования (прецедентами) определенной системы или объекта и внешними акторами. Вариант использования отображает функции системы и то, как эти функции взаимодействуют с внешними акторами.

* Диаграмма последовательности (Sequence Diagram). Диаграмма последовательности отображает взаимодействие инстанций. Она является прямым отображением множества взаимных воздействий (InteractionInstanceSet) между элементами множества инстанций (CollaborationInstanceSet). В то время как Диаграмма сообщений роли ориентирована на классификаторы-роли, обычная Диаграмма сообщений - на инстанции.

* Диаграмма сообщений роли (Sequence Role Diagram). Диаграмма сообщений роли отображает взаимодействия в концепции ролей. Она является прямым отображением Interaction (множества взаимных сообщений между классификаторами-ролями) в пределах Collaboration. В то время как Диаграмма сообщений - отображение инстанций, Диаграмма сообщений роли - отображение классификаторов-ролей.

* Диаграмма коллаборации (Collaboration Diagram). Диаграмма коллаборации отображает взаимодействие между инстанциями. Она является прямым отображением модели взаимодействия инстанций, входящих в CollaborationInstanceSet. В то время как диаграмма коллаборации ролей - отображение классификаторов-ролей, обычная диаграмма коллаборации - отображение инстанций.



Литературный список

1. Буч Г., Якобсон А., Рамбо Дж. UML. Классика CS. 2-е изд. / Пер. с англ.; Под общей редакцией проф. С. Орлова. СПб.: Питер, 2016. 736 с. ISBN 5-469-00599-2

2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон Язык UML. Руководство пользователя = The Unified Modeling Language user guide. 2. М., СПб.: «ДМК Пресс», «Питер», 2014. 432 с. ISBN 5-94074-260-2

3. Джозеф Шмуллер Освой самостоятельно UML 2 за 24 часа. Практическое руководство = Sams Teach Yourself UML in 24 Hours, Complete Starter Kit. М.: «Вильямс», 2015. 416 с. ISBN 0-672-32640-X

4. Крэг Ларман Применение UML 2.0 и шаблонов проектирования = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development. 3-е изд. М.: «Вильямс», 2016. 736 с. ISBN 0-13-148906-2

5. Сысоев В.У. Основы работы в Rational Rose 2000 Методические указания по лабораторному практикуму и курсовому проектированию. Москва: ВСЭИ, 2015. 68 с.

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