Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - Borland Together Architect.
Borland Together - CASE-средство, предназначенное для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющее моделировать как компоненты программного обеспечения, так и бизнес-процессы. Borland Together обладает открытой архитектурой. Использование технологий Borland Together 2006 для проектирования и реализации IT - архитектуры значительно ускоряет процесс разработки приложений, начиная от определения требований и заканчивая написанием кода. Возможности Together обеспечивают синхронную работу разработчиков архитектур, аналитиков и программистов при создании новых приложений или в процессе извлечения проектной информации из существующих приложений, и обеспечивают общее визуальное представление об архитектуре модели. http://www.borland.com
Технологии 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.3 Проектирование логической модели (построение диаграммы классов)
Для разработки логической модели системы применяется диаграмма классов. Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений. На данной диаграмме не указывается информация о временных аспектах функционирования системы. С этой точки зрения диаграмма классов является дальнейшим развитием концептуальной модели проектируемой системы. Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы типа "классификатор", которые связаны различными типами структурных отношений. Следует заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы. Диаграмма классов состоит из множества элементов, которые в совокупности отражают декларативные знания о предметной области.
Рис 2.10 Диаграмма классов.
Описание:
Класс сотрудники:
Содержит следующие необходимые атрибуты: № трудового договора, ФИО, № и серия паспорта. В его полномочия входят следующие операции: сохранение записи в реестре валютно-обменных операций, то есть при совершении валютно-обменной операции ему каждый раз необходимо сохранять в реестре данные о совершаемой операции; формирование справки о проведении операции с наличной валютой и чеками; составление справки о приеме на экспертизу денежного знака; создание мемориального ордера, необходимо для обоснование бухгалтерской проводки; формирование квитанции о приеме на инкассо, в случае если денежный знак поврежден.
Класс реестр:
Данный класс содержит атрибуты № операции, дата, код вида операции, код валюты принятой, курс валюты принятой, сумма валюты принятой, комиссия, подоходный налог, код валюты выданной, сумма валюты выданной, кассир. Его операциями являются сохранение записи и печать реестра, а так же реестр можно отправить с использованием internet.
Класс общероссийский классификатор валют:
Этот класс является справочником, и его атрибутами являются: идентификатор валюты, код валюты буквенный, наименование, краткое наименование стран и территорий. С ним можно выполнять следующие операции: сохранять, изменять, удалять, добавлять.
Класс мемориальный ордер:
Его атрибутами являются следующие: №, вид операции, дебет счета, кредит счета, код валюты, сумма, шифр страны, срок валютирования, плательщик, получатель, основание, кассир. Операции: сохранить, печать, отправить.
Класс справка о проведенной операции с валютой и чеками:
Содержит следующие атрибуты: №, дата, время, клиент, документ №, код вида операции, курс (кросс-курс), код валюты принятой, сумма валюты принятой, наименование валюты принятой, код валюты выданной, наименование валюты выданной, сумма валюты выданной, кассир. С данным классом можно выполнять следующие операции: сохранить и печать.
Класс курсы (кросс-курсы):
Данный класс имеет следующие атрибуты: идентификатор валюты, код валюты, курс покупки в рублях, курс продажи в рублях, за единицу, время/дата установки. Операции: добавить, сохранить, печать.
Класс операции:
Атрибуты: код операции, наименование. Операции: добавить, сохранить, удалить.
Класс документы:
Содержит следующие атрибуты: код, наименование. Операции: добавить, сохранить.
Класс клиент:
Его атрибуты: код, страна Гражданство, ФИО, документ, серия, номер, выдан, дата выдачи. С данным классом можно совершать следующие операции: добавить, изменить, сохранить.
Класс квитанция о приеме на инкассо:
Данный класс имеет следующие атрибуты: №, дата, ФИО, документ, удостоверяющий личность, №, серия, каким органом выдан, дата выдачи, адрес, дополнительные реквизиты (наименование, серия, номер, год эмиссии, для чеков: наименование, № дата, сумма, наименование эмитента, лицо, выдавшее чек), кассир. Его операциями являются: сохранить, печать.
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13
