Валютно-обменные операции, совершаемые в выносных обменных пунктах и порядок их осуществления
Анализ существующих разработок
Постановка задачи
Выбор средства проектирования
Проектирование логической модели (построение диаграммы классов)
Проектирование структуры базы данных
Проектирование экранных форм
Разработка баз данных
Разработка пользовательского интерфейса. Руководство пользователя
Экспериментальная проверка программного комплекса
Часа - дипломный руководитель
Единовременные расходы системы при внедрении автоматизированных рабочих мест (АРМ)
Навигация
Выбор средства проектирования
Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line
105495
знаков
28
таблиц
31
изображение
2.1.2 Выбор средства проектирования
Для выбора средства проектирования будем использовать метод «бальных оценок». Основными критериями отбора выбраны: объектный подход, простота в обучении, поддержка UML, быстрота создания и изменения программ. Описание и результаты отбора средства для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:
Таблица 2.2 Выбор средства проектирования.
| Параметр технология | Объектный подход | Простота в обучении | Поддержка UML | Быстрота создания и изменения диаграмм |
| Microsoft Visio | 3 | 4 | 4 | 5 |
| Borland Together Architect | 5 | 5 | 5 | 4 |
| ЗНАЧИМОСТЬ β | 4 | 3 | 5 | 2 |
|
| ||||
| Microsoft Visio | 12 | 12 | 20 | 10 |
| Borland Together Architect | 20 | 15 | 25 | 8 |
| ∑ | ||||
| Microsoft Visio | 52 | |||
| Borland Together | 68 | |||
1Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - Borland Together Architect.
Borland Together - CASE-средство, предназначенное для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющее моделировать как компоненты программного обеспечения, так и бизнес-процессы. Borland Together обладает открытой архитектурой. Использование технологий Borland Together 2006 для проектирования и реализации IT - архитектуры значительно ускоряет процесс разработки приложений, начиная от определения требований и заканчивая написанием кода. Возможности Together обеспечивают синхронную работу разработчиков архитектур, аналитиков и программистов при создании новых приложений или в процессе извлечения проектной информации из существующих приложений, и обеспечивают общее визуальное представление об архитектуре модели.[13]
Технологии Borland Together 2006 помогают:
преодолевать технологические сложности путем создания концептуальных моделей, обеспечивающих эффективное взаимодействие членов команды в процессе проектирования решений на уровне архитектуры;
создавать гибкие решения, идущие в ногу с развитием бизнеса и изменениями технологических требований, используя платформо-независимые модели;
добиваться более высокой эффективности и качества при разработке программных продуктов.
2.2 Проектирование функциональной структуры
Моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели:
Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.
Сформулировать общие требования к функциональному поведению проектируемой системы.
Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей.
Подготовить исходную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями.
Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого - представить совокупность требований к поведению проектируемой системы. В языке UML диаграмма получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".
Рис 2.2 Диаграмма вариантов использования.
Для более детального рассмотрения проектируемого процесса построим системную диаграмму вариантов использования. Системная диаграмма вариантов использования – это детализированная пользовательская, которая детализируется с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. Подобная детализация может выполняться в двух основных направлениях. Первое, детализация может быть выполнена на основе установления дополнительных отношений для уже имеющихся компонентов диаграммы вариантов использования. Второе из основных направлений детализации диаграмм вариантов использования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм.
Актер (actor) – это оператор, далее актер, лицо, совершающее операции с валютой и чеками, а также формирует отчеты и постоянно редактирует базу данных. Были определены варианты использования, то есть, описаны те функциональные возможности системы, которые должны быть реализованы. Рассмотрим каждый вариант использования более детально.
Прием на экспертизу – актер направляет денежный знак на экспертизу при выявлении сомнения платежеспособности, для этого составляется справка о приеме денежного знака на экспертизу.
Рис. 2.3 Прием на экспертизу.
Покупка валюты – актер проверяет документы клиента, далее заносит информацию о клиенте и совершает операцию: вносит необходимые данные в реестр, рассчитывается комиссия и подоходный налог, формирует справку о проведении операции и выдает ее клиенту. Данная операция совершается за рубли.
Рис. 2.4 Покупка валюты.
Продажа валюты – данный вариант использования аналогичен предыдущему.
Рис. 2.5 Продажа валюты.
Конверсия – аналогична предыдущим, но совершается непосредственно со свободно конвертируемыми валютами.
Рис. 2.6 Конверсия.
Размен денежного знака – актер проверяет документы клиента, заносит необходимую информацию о клиенте, формирует справку о проведении операции, а также сохраняет необходимые данные в реестр. Этот вид операции используется, если у клиента возникла необходимость в размене денежного знака на денежные знаки более низкого номинала либо наоборот.
Рис. 2.7 Размен денежного знака.
Замена денежного знака – оператор принимает поврежденный денежный знак на инкассо. Для этого оператор проверяет документы клиента. Далее формирует квитанцию о приеме на инкассо и один экземпляр выдает клиенту.
Рис.2.8 Замена денежного знака.
Похожие работы
... западных странах является именно необходимость замены уже имеющегося оборудования для обслуживания карт старых типов. 2. Анализ системы расчетов пластиковыми карточками Сбербанка РФ 2.1 Общая характеристика Ставропольского банка Сбербанка РФСтавропольский банк Сбербанка РФ (далее - банк) – крупнейшее банковское учреждение на Северном Кавказе и один из крупнейших в системе Сберегательного банка ...
... цены на аренду мест под терминалы, то компаниям придется сокращать число терминалов, расположенных в наименее рентабельных точках», - пояснил г-н Деев[14]. 4 Перспективы кассовых операций коммерческих банков 4.1 Динамика кассы российских банков В таблицах 4.1 и 4.2 представлена структура пассивов кредитных организаций в динамике в разрезе основных видов привлеченных средств: остатков на ...
... , практически, не используются. Проблема информатизации Минторга может быть решена путем создания Автоматизированной Информационной системы Министерства Торговли РФ (АИС МТ РФ) в соответствии с настоящим Техническим предложением. ГЛАВА 2. МАТЕМАТИЧЕСКОЕ ОБЕСПЕЧЕНИЕ КОМПЛЕКСА ЗАДАЧ "СИСТЕМА ДОКУМЕНТООБОРОТА УЧЕРЕЖДЕНИЯ”. функции поиска и архивации 2.1. Постановка задачи и её спецификация ...
... Рисунок 10 - Количество банковских пластиковых карточек в обращении по состоянию на 1 июля 2009 года За первое полугодие 2009 года на территории Республики Беларусь осуществлено 192 184 053 операции с использованием банковских пластиковых карточек в белорусских рублях на сумму 19 271 591.33 млн. рублей. Удельный вес безналичных операций в общем количестве операций с использованием банковских ...
0 комментариев