Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line (стр. 5 из 13)
Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других.
Автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты.
Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов. Методика Oracle CDM определяет следующие фазы жизненного цикла информационной системы:
стратегия;
анализ (формулирование детальных требований к прикладной системе); Q проектирование (преобразование требований в детальные спецификации системы);
реализация (написание и тестирование приложений);
внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);
эксплуатация (поддержка приложения и слежение за ним, планирование будущих функциональных расширений).
Проектирование информационной системы предполагает использование одной из технологии. В основе технологии проектирования лежит понятие технологического процесса, который определяет действия, состав исполнителей, средства и ресурсы, требуемые для выполнения этих действий. Технология проектирования определяет результат проделанной работы, порядок выполнения поставленных задач, а также для кого разрабатывается продукт.
Основные требования к выбираемой технологии проектирования:
соответствие требованиям заказчика конечного продукта.
выбранная технология должна отражать все этапы жизненного цикла проекта;
выбираемая технология должна обеспечивать минимальные трудовые и стоимостные затраты на проектирование и сопровождение проекта;
технология проектирования должна способствовать росту производительности труда проектировщика;
обеспечение надежности процесса проектирования и эксплуатации проекта.
технология должна быть основой связи между проектированием и сопровождением проекта.
Для выбора технологии проектирования будем использовать метод «бальных оценок». Самыми значимыми критериями отбора выбраны доступность; гибкость (отсутствие жестко навязываемых процедур); наличие объектно-ориентированного подхода; модульность (возможность использовать не всю технологию, а только отдельные его компоненты); удобство в применении. Рассмотрев технологии, были проставлены баллы по критериям отбора. Также для каждого критерия
были определены их важности по пятибалльной шкале. Перемножив важность на значимость критерия β и суммировав их для каждой технологии, получаем итоговую оценку. Описание и результаты отбора технологии для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:Таблица 2.1 Выбор технологии проектирования.
ПараметрТехнология | Объектный подход 1 | Гибкость2 | Модульность 3 | Удобство в применении4 |
| RUP | 5 | 5 | 5 | 5 |
| MSF | 4 | 4 | 3 | 4 |
| Oracle | 4 | 3 | 4 | 3 |
| ЗНАЧИМОСТЬ β | 5 | 3 | 4 | 2 |
| * β | ||||
| RUP | 25 | 15 | 20 | 10 |
| MSF | 20 | 12 | 12 | 8 |
| Oracle | 20 | 9 | 16 | 6 |
| ∑ * β | ||||
| RUP | 70 | |||
| MSF | 52 | |||
| Oracle | 51 | |||
Таким образом, методом бальных оценок установлено, что наиболее подходящей технологией является RUP (RationalUnifiedProcess).
В качестве метода проектирования выберем компьютерное проектирование, где для разработки используют специальные программно-инструментальные средства. Средства проектирования должны охватывать в совокупности этапы жизненного цикла ЭИС, быть программно, технически, информационно совместимы, экономически целесообразны, простыми в освоении и применении.
2.1.2 Выбор средства проектирования
Для выбора средства проектирования будем использовать метод «бальных оценок». Основными критериями отбора выбраны: объектный подход, простота в обучении, поддержка UML, быстрота создания и изменения программ. Описание и результаты отбора средства для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:
Таблица 2.2 Выбор средства проектирования.
Параметртехнология | Объектный подход 1 | Простота в обучении 2 | Поддержка UML 3 | Быстрота создания и изменения диаграмм 4 |
| 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 | |||
Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - BorlandTogetherArchitect.
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 Диаграмма вариантов использования.
Для более детального рассмотрения проектируемого процесса построим системную диаграмму вариантов использования. Системная диаграмма вариантов использования – это детализированная пользовательская, которая детализируется с целью более глубокого уточнения предъявляемых к системе требований и конкретизации деталей ее последующей реализации. Подобная детализация может выполняться в двух основных направлениях. Первое, детализация может быть выполнена на основе установления дополнительных отношений для уже имеющихся компонентов диаграммы вариантов использования. Второе из основных направлений детализации диаграмм вариантов использования связано с последующей структуризацией ее отдельных компонентов в форме элементов других диаграмм.