46692 (588431), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка методологических основ и производство инструментальных средств для автоматизации процессов разработки сложных прикладных систем, ориентированных на интенсивное использование баз данных. Методика Oracle COM является развитием давно разработанной версии Oracle CASE-Method, применяемой в CASE-средстве Oracle CASE. Основу CASE-технологии и инструментальной среды фирмы ORACLE составляют:

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

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

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

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

Автоматизация последовательного перехода от одного этапа разработки к следующему. Для этого предусмотрены специальные утилиты.

Жизненный цикл формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов. Методика Oracle CDM определяет следующие фазы жизненного цикла информационной системы:

стратегия;

анализ (формулирование детальных требований к прикладной системе); Q проектирование (преобразование требований в детальные спецификации системы);

реализация (написание и тестирование приложений);

внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

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

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

Основные требования к выбираемой технологии проектирования:

соответствие требованиям заказчика конечного продукта.

выбранная технология должна отражать все этапы жизненного цикла проекта;

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

технология проектирования должна способствовать росту производительности труда проектировщика;

обеспечение надежности процесса проектирования и эксплуатации проекта.

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

Для выбора технологии проектирования будем использовать метод «бальных оценок». Самыми значимыми критериями отбора выбраны доступность; гибкость (отсутствие жестко навязываемых процедур); наличие объектно-ориентированного подхода; модульность (возможность использовать не всю технологию, а только отдельные его компоненты); удобство в применении. Рассмотрев технологии, были проставлены баллы по критериям отбора. Также для каждого критерия были определены их важности по пятибалльной шкале. Перемножив важность на значимость критерия β и суммировав их для каждой технологии, получаем итоговую оценку. Описание и результаты отбора технологии для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:

Таблица 2.1 Выбор технологии проектирования.

Таким образом, методом бальных оценок установлено, что наиболее подходящей технологией является RUP (Rational Unified Process).

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

2.1.2 Выбор средства проектирования

Для выбора средства проектирования будем использовать метод «бальных оценок». Основными критериями отбора выбраны: объектный подход, простота в обучении, поддержка UML, быстрота создания и изменения программ. Описание и результаты отбора средства для проектирования ЭИС методом бальных оценок представлены в таблице 2.1:

Таблица 2.2 Выбор средства проектирования.

Методом бальных оценок установлено, что наиболее подходящее инструментальное средство разработки проекта - Borland Together Architect.

Borland Together - CASE-средство, предназначенное для визуального моделирования и проектирования программных систем на основе стандарта UML, позволяющее моделировать как компоненты программного обеспечения, так и бизнес-процессы. Borland Together обладает открытой архитектурой. Использование технологий Borland Together 2006 для проектирования и реализации IT - архитектуры значительно ускоряет процесс разработки приложений, начиная от определения требований и заканчивая написанием кода. Возможности Together обеспечивают синхронную работу разработчиков архитектур, аналитиков и программистов при создании новых приложений или в процессе извлечения проектной информации из существующих приложений, и обеспечивают общее визуальное представление об архитектуре модели.¹³

Технологии Borland Together 2006 помогают:

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

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

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

2.2 Проектирование функциональной структуры

Моделирование в UML можно представить, как некоторый процесс поуровневого спуска от наиболее обшей и абстрактной концептуальной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования. Диаграмма вариантов использования является исходным концептуальным представлением или концептуальной моделью системы в процессе ее проектирования и разработки. Разработка диаграммы вариантов использования преследует цели:

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

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

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

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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Построение диаграммы вариантов использования является самым первым этапом процесса объектно-ориентированного анализа и проектирования, цель которого - представить совокупность требований к поведению проектируемой системы. В языке UML диаграмма получила название модели вариантов использования и имеет свое специальное стандартное имя или стереотип "useCaseModel".

Характеристики

Список файлов ВКР