главная полезно рефераты ссылки сатьи контакты

Внимание!!!
Все материалы сайта защищены авторским правом, содержат на момент размещения не менее 60% оригинального текста. Материалы предназначены только для выполнения собственной студенческой работы. Любое воспрозведение или иное использование запрещено законом
Кроме того, просим терпимее относиться ко всем видам рекламы на сайте. Так как за счет её и существует наш проект. Спасибо за понимание и удачи вам в поиске нужной информации.


Разработка подсистемы учёта и регистрации поступлений денежных переводов из-за границы (Программирование на Java)

СОДЕРЖАНИЕ

 

ВВЕДЕНИЕ.. 2

1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ РЕШАЕМОЙ ЗАДАЧИ.. 4

1.1. Страна. 4

1.2. Получатель. 4

1.3. Перевод. 4

1.4. Этапы организации хранилища информации о получении переводов. 6

2. ПОСТАНОВКА ЗАДАЧИ.. 8

3. ОБЗОР МЕТОДОВ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ.. 9

4. ТРЕБОВАНИЯ К СИСТЕМЕ.. 10

5. РАЗРАБОТКА МЕТОДОВ И МОДЕЛЕЙ ПРЕДСТАВЛЕНИЯ СИСТЕМЫ    11

6. РАЗРАБОТКА И ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ   17

7.ОБОСНОВАНИЕ ПРИНИМАЕМЫХ РЕШЕНИЙ ПО ВЫБОРУ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ.. 21

8. ОПИСАНИЕ АЛГОРИТМОВ ПРОГРАММНЫХ МОДУЛЕЙ.. 23

10. ОПИСАНИЕ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ.. 33

ВЫВОДЫ И ЗАКЛЮЧЕНИЯ.. 34

ЛИТЕРАТУРА.. 36

ПРИЛОЖЕНИЯ.. 37

 


ВВЕДЕНИЕ

 

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

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

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

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

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

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

- языки программирования: Java, JavaScript

- технологии программирования: EJB, JSP, Servlets, DHTML

- сервер баз данных: SYBASE 9.0

- сервер приложений/web-сервер: Sun Application Server 8.2.

 


1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ И КЛАССИФИКАЦИЯ СУЩНОСТЕЙ РЕШАЕМОЙ ЗАДАЧИ

 

Кратко опишем предметную область рассматриваемой задачи.

В настоящее время, согласно изменениям законодательства РБ, ведется учет получения гражданами РБ денежных переводов из-за границы.

Учет получения переводов ведется сотрудниками налоговой инспекции. При это осуществляется учет сведений о стране отправителя, получателе перевода и другая информация о переводе.

Сведения о получателе перевода в обязательным порядке сообщаются самим получателем для получения перевода.

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

Таким образом, можно выделить следующие сущности предметной области:

1)    Страна – информация о стране отправителя перевода

2)    Получатель – информация о получателях переводов

3)    Перевод – информация о полученных из-за границы переводах.

 

1.1. Страна

Содержит информацию о стране, из которой осуществляется денежный перевод (название страны).

1.2. Получатель

Сущность содержит о получателе денежного перевода (ФИО, адрес, номер паспорта).

1.3. Перевод

Сущность содержит информацию о денежном переводе. Она характеризуется следующими атрибутами:

- страна

- получатель

- комментарий

- дата отправки

- дата получения

- сумма

- сведения о получении – получен или нет) .

 


1.4. Этапы организации хранилища информации о получении переводов

 

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

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

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

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

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

Для разработки подсистемы учета и регистрации получения денежных переводов из-за границы характерно наличие связей с другими задачами – например, учет жителей города Минска (адресный стол). Поэтому обязательно должно быть зарезервировано время для изучения смежных областей решаемой задачи с целью дальнейшей модернизации и расширения подсистемы.

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

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

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

Сопровождение проекта – силами организации-разработчика проводится сопровождение внедренной подсистемы.

 


2. ПОСТАНОВКА ЗАДАЧИ

 

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

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

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

3.                  Разработать информационную модель системы (структуру уровня представления данных), рассчитанную на реляционную модель БД.

4.                  Разработать структуру (модель) всех остальных слоев приложения (бизнес-логика и слой представления).

5.                  Разработать программy, провести модульное тестирование и обеспечить сборку подсистемы.

6.                  Обеспечить проверку развертываемости разработанной подсистемы учета и регистрации переводов.

7.                  Выполнить функциональное тестирование программы.

8.                  Описать алгоритмы программных модулей.

9.                  Описать тестовый пример, руководство пользователя.

10.               Описать полученные результаты.

11.               Оформить пояснительную записку.


3. ОБЗОР МЕТОДОВ РЕШЕНИЯ ПОСТАВЛЕННОЙ ЗАДАЧИ

 

Существует несколько способов создания готовых программных продуктов. Первый из методов - это  привлечение сторонних компаний-исполнителей. В настоящем случае он не подходит в связи с характером поставленной задачи (самостоятельное выполнение курсовой работы).

Второй метод решения поставленной задачи – самостоятельное решение проблемы. Для этого необходимо:

·                   четкое знание требований к системе

·                   источники информации по теме (литературные источники)

·                   запас времени

·                   компьютер, на котором установлено требуемое для разработки ПО

В силу того, что первый метод неприемлем по экономическим и принципиальным соображениям, для данной работы был выбран второй метод – самостоятельное решение.

 


4. ТРЕБОВАНИЯ К СИСТЕМЕ

 

1.                Система должна обеспечивать  возможность ввода, просмотра, редактирования и удаления данных о переводах, странах и получателях переводов.

2.                Система должна обеспечивать возможность просмотра полученных результатов.

3.                Система должна обеспечивать возможность удаленной работы с приложением.

Курсовой проект должен быть выполнен в архитектуре клиент-сервер на основе технологии J2EE (Java 2 Enterprise Edition ). Курсовой проект должен представлять собой приложение состоящее из следующих частей:

- тонкий клиент (диалог пользователя с системой должен осуществляться через web-браузер).  Интерфейс строится с использованием DHTML.

- уровень представления (реализуется с помощью JSP (Java Server Pages) и Servlets). Данные компоненты генерирует страницы для web-клиента и обрабатывает информацию получаемую с web-клиента.

- уровень бизнес-логики (реализуется с помощью EJB session-компонентов).

-уровень данных. На сервере приложений представляется EJB-entity компонентами  и СУБД Sybase SQL Anywhere 9.0.

Соединение с сервером должно быть реализовано с использованием протокола  HTTP. При разработке необходимо использовать JDK1.5.

В качестве сервера приложений необходимо использовать Sun Application Server 8.0

В качестве сервера БД необходимо использовать SYBASE SQL Anywhere 9.0.


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

 

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

-IDEF0 – моделирование процессов предметной области. Использовалось  CASE средство BPWIN.

-IDEF1.X – информационное моделирование. Использовалось  CASE средство ERWin.

-UML –моделирование разрабатываемой системы. Использовалось  CASE средство Enterprise Architect.

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

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

IDEF1X (IDEF1 Extended) – методология построения реляционных структур. IDEF1X относится к типу методологий “Сущность-взаимосвязь” (ER – Entity-Relationship) и, как правило, используется для моделирования реляционных баз данных, имеющих отношение к рассматриваемой системе.

Графический язык IDEF0 удивительно прост и гармоничен. В основе методологии лежат четыре основных понятия:

Первым из них является понятие функционального блока (Activity Box). Функциональный блок графически изображается в виде прямоугольника (см. рис. 1) и олицетворяет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, “производить услуги”, а не “производство услуг”).

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

·                    Верхняя сторона имеет значение “Управление” (Control);

·                    Левая сторона имеет значение “Вход” (Input);

·                    Правая сторона имеет значение “Выход” (Output);

·                    Нижняя сторона имеет значение “Механизм” (Mechanism).

Каждый функциональный блок в рамках единой рассматриваемой системы должен иметь свой уникальный идентификационный номер.

Рис 1.Функциональный блок.

 

Вторым “китом” методологии IDEF0 является понятие интерфейсной дуги (Arrow). Также интерфейсные дуги часто называют потоками или стрелками. Интерфейсная дуга отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, отображенную данным функциональным блоком.

Графическим отображением интерфейсной дуги является однонаправленная стрелка. Каждая интерфейсная дуга должна иметь свое уникальное наименование (Arrow Label). По требованию стандарта, наименование должно быть оборотом существительного.

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

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

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

Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий классов DFD (Data Flow Diagram) и WFD (Work Flow Diagram).

Третьим основным понятием стандарта IDEF0 является декомпозиция (Decomposition). Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.

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

Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой, и обозначается идентификатором “А-0”.

В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения (Viewpoint).

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

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

В процессе декомпозиции, функциональный блок, который в контекстной диаграмме отображает систему как единое целое, подвергается детализации на другой диаграмме. Получившаяся диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции функционального блока контекстной диаграммы и называется дочерней (Child diagram) по отношению к нему (каждый из функциональных блоков, принадлежащих дочерней диаграмме соответственно называется дочерним блоком – Child Box). В свою очередь, функциональный блок - предок называется родительским блоком по отношению к дочерней диаграмме (Parent Box), а диаграмма, к которой он принадлежит – родительской диаграммой (Parent Diagram). Каждая из подфункций дочерней диаграммы может быть далее детализирована путем аналогичной декомпозиции соответствующего ей функционального блока. Важно отметить, что в каждом случае декомпозиции функционального блока все интерфейсные дуги, входящие в данный блок, или исходящие из него фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF0 – модели. Наглядно принцип декомпозиции представлен на рисунке 4. Следует обратить внимание на взаимосвязь нумерации функциональных блоков и диаграмм - каждый блок имеет свой уникальный порядковый номер на диаграмме (цифра в правом нижнем углу прямоугольника), а обозначение под правым углом указывает на номер дочерней для этого блока диаграммы. Отсутствие этого обозначения говорит о том, что декомпозиции для данного блока не существует.

Последним из понятий IDEF0 является глоссарий (Glossary). Для каждого из элементов IDEF0: диаграмм, функциональных блоков, интерфейсных дуг существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Например, для управляющей интерфейсной дуги “распоряжение об оплате” глоссарий может содержать перечень полей соответствующего дуге документа, необходимый набор виз и т.д. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.

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

В работе представлены диаграммы последовательности, диаграммы классов, кооперирования, состояния и использования, а также диаграммы IDEF0.

 

 


6. РАЗРАБОТКА И ПОСТРОЕНИЕ ИНФОРМАЦИОННОЙ МОДЕЛИ

 

Информационная модель - это спецификация структуры данных и бизнес правил (правил предметной области).

ERwin - средство разработки структуры базы данных. ERwin сочетает графический интерфейс Windows, инструменты для построения ER-диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД и настольных баз данных. С помощью ERwin можно создавать или проводить обратное проектирование (реинжиниринг) баз данных.

Реализация моделирования в ERwin базируется на теории реляционных баз данных и на методологии IDEF1X.

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

Процесс построения информационной модели состоит из следующих шагов:

·                    определение сущностей;

·                    определение зависимостей между сущностями;

·                    задание первичных и альтернативных ключей;

·                    определение атрибутов сущностей;

·                    приведение модели к требуемому уровню нормальной формы;

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

·                    генерация базы данных.

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

В ERwin существуют два уровня представления и моделирования - логический и физический . Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.
Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin.
ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.

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

·                    Режим "сущности" - внутри прямоугольников отображается имя сущности (для логической модели) или имя таблицы (для физического представления модели); служит для удобства обзора большой диаграммы или размещения прямоугольников сущностей на диаграмме.

·                    Режим "определение сущности" служит для презентации диаграммы другим людям.

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

·                    Режим "первичные ключи" - внутри прямоугольников - сущностей показываются только атрибуты/колонки, составляющие первичный ключ.

·                    Режим "пиктограммы". Для презентационных целей каждой таблице может быть поставлена в соответствие пиктограмма (bitmap).

·                    Режим "показ глагольной фразы". На дугах связей показываются глагольные фразы, связывающие сущности (для логического уровня) или имена внешних ключей (для физического уровня).

Диаграмма может занимать более чем один экран и более чем один лист при печати.

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

·                    атрибуты, составляющие первичный ключ;

·                    неключевые атрибуты;

·                    тип сущности (независимая/зависимая).

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

Для каждого первичного ключа ERwin создает при генерации структуры БД уникальный индекс.

Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Зависимая сущность отображается в ERwin прямоугольником с закругленными углами.


7.ОБОСНОВАНИЕ ПРИНИМАЕМЫХ РЕШЕНИЙ ПО ВЫБОРУ ТЕХНИЧЕСКИХ И ПРОГРАМНЫХ СРЕДСТВ РЕАЛИЗАЦИИ

 

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

 Enterprise Architect

 Sun AppServer 8.2

 IDE NetBeans 5.5

Enterprise Architect - это мощный набор UML-инструментов для разработки программного обеспечения через стадии анализа, модели дизайна, испытания и внедрения. Enterprise Architect - это многопользовательский графический инструмент, разработанный для того, чтобы создавать устойчивое и удобное в использовании программное обеспечение.

Для уменьшения стоимости и увеличения скорости проектирования и разработки корпоративного приложения платформа J2EE предлагает компонентный подход к проектированию, разработке, сборке и внедрению корпоративных приложений. Платформа J2EE предлагает модель многоуровневого распределенного приложения, возможность повторного использования компонентов, интегрированный обмен данными на основе XML, унифицированную модель безопасности и гибкое управление транзакциями. Вы не только можете выпускать на рынок инновационное решение для пользователей быстрее, чем раньше, но и Ваши платформо-независимые, основанные на компонентах J2EE-решения больше не привязаны к продуктам и API какого-либо одного производителя. Производители и пользователи обладают свободой выбора продуктов и компонентов, которые наиболее полно удовлетворяют их деловые и технологические требования. Поэтому в  качестве сервера был выбран Sun AppServer.

NetBeans 5.5 – бесплатная среда разработки с открытым кодом, позволяющая упростить многие однотипные действия, например, генерацию EJB и отладку программы.

 

 


8. ОПИСАНИЕ АЛГОРИТМОВ ПРОГРАММНЫХ МОДУЛЕЙ

         Обобщенный алгоритм работы клиента показан на рис. 1.

 

Рис. 1. Обобщенный алгоритм работы.

 

Рис. 2. Многоуровневое J2EE-приложение

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

1)                              клиент обращается посредством веб-браузера по ссылке в Интернете

2)                              сервер приложений обрабатывает запрос пользователя, выполняя ту или иную JSP-страницу

3)                              в ходе обработки запроса клиента осуществляется обращение к EJB, отражающим сущности предметной области

4)                              для обработки запросов клиента через бизнес-методы компонентов EJB Осуществляется обмен данных с СУБД Sybase

5)                              работа с БД осуществляется по протоколу JDBC посредством пула JDBC-соединений Sun Application Server

 

 


9. ОПИСАНИЕ ТЕСТОВОГО ПРИМЕРА. РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ

 

Для запуска разработанного программного средства вначале необходимо зарегистрировать в настроить connection pool для сервера базы данных с именем sybase, и настроить jdbc resource с именем jdbc/sybase.

Подключение производиться по url:

http://localhost:8080/transfers/

Работать можно в любом интернет-браузере с поддержкой CSS, HTML 4.01 и JavaScript (рекомендуется Internet Explorer).

При запуске WEB-браузера появляется окно, показанное на рис. 3.

 

 

Рис. 3. Основное окно веб-клиента.


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

1.                Страны (отображает список всех стран);

2.                Получатели (список получателей платежей);

3.                Переводы (список зарегистрированных денежных переводов).

 

На каждой странице возможны следующие действия:

Редактирование записи. Для этого необходимо нажать на кнопку «...» в той строке таблицы, которую необходимо редактировать. Результат нажатия отображен на Рис.4

 

Рис. 4. Редактирование записи

 

Для сохранения изменений необходимо нажать на кнопку «OK»

Чтобы удалить какую-нить запись необходимо нажать на «Х».

В результате появится диалоговое окно с запросом подтверждения об удалении (Рис. 5)

 

 

 

Рис. 5. Запрос на удаление

 

  После подтверждения запись удаляется и страница обновляется.

 

  Чтобы добавить запись, необходимо нажать кнопку «Добавить» (Рис. 6). При этом в таблице появится новая строка. Для сохранения изменений нужно нажать кнопку «OK».

Рис. 6. Добавление записи.


Чтобы произвести поиск записи, следует вести запрос в текстовое поле «Искать по» (рис.7) и нажать кнопку «Искать». Результат поиска отображен на рис. 8.

Система ищет как по полной строке, так и по части строки.

Рис. 7. Поиск записи – ввод данных

 

Рис.8. Поиск записи – результат

 

Тестовый пример: добавление записи о переводе

Необходимо зарегистрировать денежный перевод в Украину для Зайцева Семена, 10.12.2006 на сумму 990.0.

В результате выполнения  новая запись должна сохраниться в системе.

 


Шаг 1:

Запускаем приложение. Переходим на страницу Переводы (Рис.9)

 

Рис. 7. Страница Переводы.

 

Шаг 2.

Нажимаем кнопку Добавить. В окне вводим все данные. (Рис. 10)

Рис. 10. Добавление записи

 

Шаг 3.

Нажимаем OK. Запись сохраняется и страница обновляется. (Рис.11)

Рис. 11. Запись сохранена

 

Полученные результаты совпадают с ожидаемыми – запись сохранена в системе.

 

 


10. ОПИСАНИЕ ПОЛУЧЕННЫХ РЕЗУЛЬТАТОВ

 

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

В процессе выполнения  работы были получены теоретические сведения, а также закреплены на практике навыки по работе с языком  JAVA, UML, методиками проектирования IDEF0, IDEF1x, СУБД SQL Anywhere 9 и технологией EJB .


ВЫВОДЫ И ЗАКЛЮЧЕНИЯ

 

В ходе выполнения курсового проекта разработано приложение, позволяющее производить хранение информации о денежных переводах из-за границы и их получателях. Программа реализована с использованием языка программирования Java, технологий J2EE и Sun Application Server 8.2 / SQL Anywhere 9. Реализован веб-клиент.

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

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

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

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

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

2) возможность получения отчетов по данным о переводах (для этого особенно удобен HTML-формат)

3) интеграция подсистемы с подсистемами адресного стола города и ИЦ МВД РБ (поиск переводов для так называемых «кардеров» и т.п.)

 

 


ЛИТЕРАТУРА

 

1.                Java 2 в подлиннике. Патрик Ноутон, Герберт Шилдт, 1072 стр., 2007 г. Издательство: BHV. Серия: В подлиннике. ISBN 5-94157-012-0

2.                Java 2 Enterprise Edition. Технологии проектирования и разработки. Максим Вершинин, Елена Иванова, 1088 стр., 2003 г. Издательство: BHV. Серия: Мастер программ. ISBN 5-94157-192-5

3.                UML 2.0. Объектно-ориентированное моделирование и разработка. М. Блаха, Дж. Рамбо, 544 стр., 2006 г. Издательство: Питер. Серия: Библиотека программиста. ISBN 5-469-00814-2

4.                Моделирование и анализ систем. IDEF-технологии. Практикум. В. Ручкин, И. Семенов, С. Черемных, 192 стр., 2006 г. Издательство: Финансы и статистика. ISBN 5-279-02564-X


Внимание! Для данной работы приложения платные. С их описанием и стоимостью можно ознакомиться здесь

Описание приложений!



Скачать курсовую

Задать вопрос                                                      




Если у вас появилось непреодолимое желание пожертвовать средства на развитие сайта или отблагодарить владельца за бесценный материал :), можете перевести любую сумму на кошелек R200818721914 или Z890150328460.

© studlight 2011-2014