46692 (Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line), страница 4
Описание файла
Документ из архива "Автоматизированное рабочее место оператора валютно-обменных операций в режиме off-line", который расположен в категории "". Всё это находится в предмете "информатика" из , которые можно найти в файловом архиве . Не смотря на прямую связь этого архива с , его также можно найти и в других разделах. Архив можно найти в разделе "остальное", в предмете "информатика, программирование" в общих файлах.
Онлайн просмотр документа "46692"
Текст 4 страницы из документа "46692"
Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика Oracle COM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE. Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:
Методология структурного нисходящего проектирования, при которой разработка прикладной системы представляется в виде последовательности четко определенных этапов.
Поддержка всех этапов жизненного цикла прикладной системы, начиная с самых общих описаний предметной области до получения и сопровождения готового программного продукта.
Ориентация на реализацию приложений в архитектуре клиент-сервер с использованием всех особенностей современных серверов баз данных, включая декларативные ограничения целостности, хранимые процедуры, триггеры баз данных.
Централизованное хранение проекта системы и управление одновременным доступом к нему всех участников разработки поддерживают согласованность действий разработчиков и не допускают ситуацию, когда каждый проектировщик или программист работает со своей версией проекта и модифицирует ее независимо от других.
Автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты.
Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов. Методика 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 (Rational Unified Process).
В качестве метода проектирования выберем компьютерное проектирование, где для разработки используют специальные программно-инструментальные средства. Средства проектирования должны охватывать в совокупности этапы жизненного цикла ЭИС, быть программно, технически, информационно совместимы, экономически целесообразны, простыми в освоении и применении.
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 | |||
Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - 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".
