Поиск

Полнотекстовый поиск:
Где искать:
везде
только в названии
только в тексте
Выводить:
описание
слова в тексте
только заголовок

Рекомендуем ознакомиться

'Учебно-методический комплекс'
Тема 1. Финансовые технологии: общие понятия Понятие финансовых технологий. Основные операционные элементы финансовых технологий. Основные проблемы ф...полностью>>
'Документ'
эксплуатация оборудования (стоимость смазочных и обтирочных материалов, стоимость потребленных топлива и энергии, услуги вспомогательных производств)...полностью>>
'Программа'
развития школы Концепция модернизации российского образования на период до 2010 года; Концепция профильной школы (приказ Министерства образования РФ ...полностью>>
'Анкета'
то укажите, пожалуйста, дату (период) последней аудиторской проверки Организационно – правовая форма: Отраслевая принадлежность....полностью>>

М. В. Красильникова проектирование информационных систем раздел: Теоретические основы проектирования информационных систем Учебное пособие

Главная > Учебное пособие
Сохрани ссылку в одной из сетей:

Создание функциональных моделей и диаграмм

Сбор информации

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

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

  • чтение документов;

  • наблюдение за выполняемыми операциями;

  • анкетирование;

  • использование собственных знаний;

  • составление описания.

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

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

Анкетирование проводится для того, чтобы опросить большие группы экспертов в сжатые сроки. Анкетирование при опросе экспертов позволяет выявить, какие части системы более всего нуждаются в улучшении.

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

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

Типы опроса

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

  • опросы для сбора фактов;

  • опросы для определения проблем;

  • совещания для принятия решений;

  • диалоги автор/читатель.

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

Процесс опроса

Приведем несколько советов, которые позволяют понять основные шаги в процессе опроса:

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

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

Умение проводить хорошие опросы так же важно, как и умение строить хорошие диаграммы и модели.

Дополнения к диаграммам и моделям

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

SADT-диаграммы могут быть дополнены информацией в виде текстов, рисунков и глоссариев.

Текст обычно представляет собой рассказ об одной из частей диаграммы.

Рисунки – это картинки, поясняющие отдельные моменты.

Глоссарий – набор определений объектов и функций, представленных на диаграмме.

Рассмотрим составление глоссария на примере процесса "подготовить рабочее место" в экспериментально-механическом цехе (рис. 25).


Рис. 25. SADT-диаграмма процесса "подготовить рабочее место".



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

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

Рис. 26. Пример глоссария для процесса "подготовить рабочее место".

Оценка и выбор CASE-средств

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

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

  • оценка нескольких CASE-средств и выбор одного или более из них;

  • оценка одного или более CASE-средств и сохранение результатов для последующего использования;

  • выбор одного или более CASE-средств с использованием результатов предыдущих оценок.

Р
ис. 27. Процесс выбора
CASE-средства.

Как видно из рисунка 27, входной информацией для процесса оценки является:

  • определение пользовательских потребностей;

  • цели и ограничения проекта;

  • данные о доступных CASE-средствах;

  • список критериев, используемых в процессе оценки.

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

Элементы процесса включают:

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

  • потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам;

  • критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе;

  • формализованные результаты оценок одного или более средств;

  • рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка).

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

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

Определение списка критериев основано на пользовательских требованиях и включает:

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

  • определение дополнительных критериев;

  • определение области использования каждого критерия (оценка, выбор или оба процесса);

  • определение одной или более метрик для каждого критерия оценки;

  • назначение веса каждому критерию при выборе.

Критерии оценки и выбора

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

  • числовые меры в широком диапазоне значений, например, объем требуемой памяти;

  • числовые меры в ограниченном диапазоне значений, например, простота освоения, выраженная в баллах от 1 до 5;

  • двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript;

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

Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.

С
труктура набора критериев приведена на рисунке 28. Каждый критерий должен быть выбран и адаптирован экспертом с учетом особенностей конкретного процесса. В большинстве случаев только некоторые из множества описанных ниже критериев оказываются приемлемыми для использования, при этом также добавляются дополнительные критерии. Выбор и уточнение набора используемых критериев является критическим шагом в процессе оценки и/или выбора.

Рис. 28. Функциональные характеристики.

Критерии первого класса предназначены для определения функциональных характеристик CASE-средства. Они, в свою очередь, подразделяются на ряд групп и подгрупп.

1. Среда функционирования

Проектная среда:

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

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

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

ПО/технические средства:

  • требуемые технические средства. Оборудование, необходимое для функционирования CASE-средства, включая тип процессора, объем оперативной и дисковой памяти.

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

  • требуемое ПО. ПО, необходимое для функционирования CASE-средства, включая операционные системы и графические оболочки.

  • поддерживаемое ПО. Программные продукты, которые могут использоваться CASE-средством.

Технологическая среда:

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

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

  • поддерживаемая методология. Набор методов и методик, поддерживаемых CASE-средством. Примерами являются структурный или объектно-ориентированный анализ и проектирование.

  • поддерживаемые языки. Все языки, используемые CASE-средством. Примерами таких языков являются языки программирования (Кобол, Ада, С), языки баз данных и языки запросов (DDL, SQL), графические языки (Postscript, HPGL), языки спецификации проектных требований и интерфейсы операционных систем (языки управления заданиями).

2. Функции, ориентированные на фазы жизненного цикла

Моделирование:

Данные критерии определяют способность выполнения функций, необходимых для спецификации требований к ПО и преобразованию их в проект:

  • построение диаграмм. Возможность создания и редактирования диаграмм различных типов, представляющих интерес для пользователя. Наиболее распространенные типы диаграмм описаны в разделе 2.

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

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

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

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

  • моделирование процессов. Возможность ввода и редактирования информации, описывающей процессы системы и их отношения.

  • проектирование архитектуры ПО. Проектирование логической структуры ПО – структуры модулей, интерфейсов и др.

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

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

  • генерация экранных форм. Возможность генерации экранных форм на основе спецификаций требований и/или проектных спецификаций.

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

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

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

  • автоматизированное проектирование отчетов.

Реализация:

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

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

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

  • компиляция кода.

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

  • анализ надежности. Возможность количественно оценивать параметры надежности ПО, такие, как количество ошибок и др.

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

  • реструктуризация исходного кода. Возможность модификации формата и/или структуры существующего исходного кода.

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

  • отладка. Типичные функции отладки – трассировка программ, выделение узких мест и наиболее часто используемых фрагментов кода и т.д.

Тестирование:

Критерии тестирования включают следующее:

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

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

  • автоматический запуск тестовых примеров.

  • регрессионное тестирование. Возможность повторения и модификации ранее выполненных тестов для определения различий в системе и/или среде.

  • автоматизированный анализ результатов тестирования. Типичные возможности включают сравнение ожидаемых и реальных результатов, сравнение файлов, статистический анализ результатов и др.

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

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

  • анализ исключительных ситуаций в процессе тестирования.

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

3. Общие функции

Приведенные ниже критерии определяют функции CASE-средств, охватывающие всю совокупность фаз ЖЦ. Поддержка всех этих функций осуществляется посредством репозитория.

Документирование:

  • редактирование текстов и графики. Возможность вводить и редактировать данные в текстовом и графическом формате.

  • редактирование с помощью форм. Возможность поддерживать формы, определенные пользователями, вводить и редактировать данные в соответствии с формами.

  • возможности издательских систем.

  • поддержка функций и форматов гипертекста.

  • соответствие стандартам документирования.

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

Управление конфигурацией:

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

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

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

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

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

  • архивирование. Возможность автоматического архивирования элементов данных для последующего использования.

Управление проектом:

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

  • оценка. Возможность оценивать затраты, график и другие проектные параметры, вводимые пользователями.

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

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

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

Характеристики CASE-средств

Silverrun

CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для анализа и проектирования ИС бизнес-класса и ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для поддержки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").

Структура и функции

Silverrun имеет модульную структуру и состоит из четырех модулей:

  • Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (BPM – Business Process Modeler) позволяет моделировать функционирование обследуемой организации или создаваемой ИС. Диаграммы могут изображаться в нескольких предопределенных нотациях, включая Yourdon/DeMarco и Gane/Sarson.

  • Модуль концептуального моделирования данных (ERX – Entity-Relationship eXpert) обеспечивает построение моделей данных "сущность-связь", не привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную систему, позволяющую создать корректную нормализованную модель данных посредством ответов на содержательные вопросы о взаимосвязи данных. Возможно автоматическое построение модели данных из описаний структур данных. Анализ функциональных зависимостей атрибутов дает возможность проверить соответствие модели требованиям третьей нормальной формы и обеспечить их выполнение. Проверенная модель передается в модуль RDM.

  • Модуль реляционного моделирования (RDM – Relational Data Modeler) позволяет создавать детализированные модели "сущность-связь", предназначенные для реализации в реляционной базе данных. В этом модуле документируются все конструкции, связанные с построением базы данных: индексы, триггеры, хранимые процедуры и т.д.

  • Менеджер репозитория рабочей группы (WRM – Workgroup Repository Manager) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает интеграцию модулей Silverrun в единую среду проектирования.

Взаимодействие с другими средствами

Для автоматической генерации схем баз данных у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi.

Среда функционирования

Имеются реализации Silverrun трех платформ – MS Windows, Macintosh и OS/2 Presentation Manager – с возможностью обмена проектными данными между ними.

Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.

Структура и функции

Vantage Team Builder обеспечивает выполнение следующих функций:

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

  • проектирование диаграмм архитектуры системы – SAD (проектирование состава и связи вычислительных средств, распределения задач системы между вычислительными средствами, моделирование отношений типа "клиент-сервер", анализ использования менеджеров транзакций и особенностей функционирования систем в реальном времени);

  • генерация кода программ на языке 4GL целевой СУБД с полным обеспечением программной среды и генерация SQL-кода для создания таблиц БД, индексов, ограничений целостности и хранимых процедур;

  • программирование на языке C со встроенным SQL;

  • управление версиями и конфигурацией проекта;

  • многопользовательский доступ к репозиторию проекта;

  • генерация проектной документации по стандартным и индивидуальным шаблонам;

  • экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляется в различных конфигурациях в зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) .

Среда функционирования

Vantage Team Builder функционирует на всех основных UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) и VMS.

Vantage Team Builder можно использовать в конфигурации "клиент-сервер", при этом база проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть клиентами.

Uniface

Uniface 6.1 – продукт фирмы Compuware (США) – представляет собой среду разработки крупномасштабных приложений в архитектуре "клиент-сервер" и имеет следующую компонентную архитектуру:

  • Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС (прикладные модели, описания данных, бизнес-правил, экранных форм, глобальных объектов и шаблонов). Репозиторий может храниться в любой из баз данных, поддерживаемых Uniface;

  • Application Model Manager поддерживает прикладные модели (E-R модели), каждая из которых представляет собой подмножество общей схемы БД, с точки зрения данного приложения, и включает соответствующий графический редактор;

  • Rapid Application Builder – средство быстрого создания экранных форм и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов управления (Open Widget Interface) для существующих графических интерфейсов – MS Windows (включая VBX), Motif, OS/2. Универсальный интерфейс представления (Universal Presentation Interface) позволяет использовать одну и ту же версию приложения в среде различных графических интерфейсов без изменения программного кода;

  • Developer Services (службы разработчика) используются для поддержки крупных проектов и реализуют контроль версий (Uniface Version Control System), права доступа (разграничение полномочий), глобальные модификации и т.д. Это обеспечивает разработчиков средствами параллельного проектирования, входного и выходного контроля, поиска, просмотра, поддержки и выдачи отчетов по данным системы контроля версий;

  • Deployment Manager (управление распространением приложений) – средства, позволяющие подготовить созданное приложение для распространения, устанавливать и сопровождать его (при этом платформа пользователя может отличаться от платформы разработчика). В их состав входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер), средства распространения приложений и управления базами данных. Uniface поддерживает интерфейс практически со всеми известными программно-аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами и менеджерами транзакций;

  • Personal Series (персональные средства) используются для создания сложных запросов и отчетов в графической форме (Personal Query и Personal Access – PQ/PA), а также для переноса данных в такие системы, как WinWord и Excel;

  • Distributed Computing Manager – средство интеграции с менеджерами транзакций Tuxedo, Encina, CICS, OSF DCE.

В состав компонент Uniface 7 входят:

  • Uniface Application Server – сервер приложений для распределенных систем;

  • WebEnabler – серверное ПО для эксплуатации приложений в Internet и Intrаnet;

  • Name Server – серверное ПО, обеспечивающее использование распределенных прикладных ресурсов;

  • PolyServer – средство доступа к данным и интеграции различных систем.

В список поддерживаемых СУБД входят DB2, VSAM и IMS; PolyServer обеспечивает также взаимодействие с ОС MVS. Среда функционирования Uniface – все основные UNIX – платформы и MS Windows.

Designer/2000 + Developer/2000

CASE-средство Designer/2000 2.0 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средствами разработки приложений Developer/2000 поддержку полного ЖЦ ПО для систем, использующих СУБД ORACLE.

Структура и функции

Designer/2000 представляет собой семейство методологий и поддерживающих их программных продуктов.

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

На этапе реализации создается БД, строятся прикладные системы, производится их тестирование, проверка качества и соответствия требованиям пользователей. Создается системная документация, материалы для обучения и руководства пользователей. На этапах эксплуатации и сопровождения анализируются производительность и целостность системы, выполняется поддержка и, при необходимости, модификация ИС.

В состав Designer/2000 входят следующие компоненты:

  • Repository Administrator – средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

  • Repository Object Navigator – средства доступа к репозиторию, обеспечивающие многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

  • Process Modeller – средство анализа и моделирования деловой деятельности, основывающееся на концепциях реинжиниринга бизнес-процессов (BPR – Business Process Reengineering) и глобальной системы управления качеством (TQM – Total Quality Management);

  • Systems Modeller – набор средств построения функциональных и информационных моделей проектируемой ИС, включающий средства для построения диаграмм "сущность-связь" (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

  • Systems Designer – набор средств проектирования ИС, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

  • Server Generator – генератор описаний объектов БД ORACLE (таблиц, индексов, ключей, последовательностей и т.д.). Помимо продуктов ORACLE, генерация и реинжиниринг БД может выполняться для СУБД Informix, DB/2, Microsoft SQL Server, Sybase, а также для стандарта ANSI SQL DDL и баз данных, доступ к которым реализуется посредством ODBC;

  • Forms Generator (генератор приложений для ORACLE Forms). Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки. Дальнейшая работа с приложением выполняется в среде Developer/2000;

  • Repository Reports – генератор стандартных отчетов, интегрированный с ORACLE Reports и позволяющий русифицировать отчеты, а также изменять структурное представление информации.

Взаимодействие с другими средствами

Designer/2000 можно интегрировать с другими средствами, используя открытый интерфейс приложений API (Application Programming Interface). Кроме того, можно использовать средство ORACLE CASE Exchange для экспорта/импорта объектов репозитория с целью обмена информацией с другими CASE-средствами.

Developer/2000 обеспечивает разработку переносимых приложений, работающих в графической среде Windows, Macintosh или Motif. В среде Windows интеграция приложений Developer/2000 с другими средствами реализуется через механизм OLE и управляющие элементы VBX. Взаимодействие приложений с другими СУБД (DB/2, DB2/400, Rdb) реализуется с помощью средств ORACLE Client Adapter для ODBC, ORACLE Open Gateway и API.

Среда функционирования

Среда функционирования Designer/2000 и Developer/2000 – Windows 3.x, Windows 95, Windows NT.

Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)

ERwin – средство концептуального моделирования БД, использующее методологию IDEF1X (ERD). ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress и др.) и реинжиниринг существующей БД. ERwin выпускается в нескольких различных конфигурациях, ориентированных на наиболее распространенные средства разработки приложений 4GL. Версия ERwin/OPEN полностью совместима со средствами разработки приложений PowerBuilder и SQLWindows и позволяет экспортировать описание спроектированной БД непосредственно в репозитории данных средств.

Для ряда средств разработки приложений (PowerBuilder, SQLWindows, Delphi, Visual Basic) выполняется генерация форм и прототипов приложений. Сетевая версия Erwin ModelMart обеспечивает согласованное проектирование БД и приложений в рамках рабочей группы.

BPwin – средство функционального моделирования, реализующее методологию IDEF0 (SADT).

S-Designor 4.2 представляет собой CASE-средство для проектирования реляционных баз данных. По своим функциональным возможностям и стоимости он близок к CASE-средству ERwin, отличаясь внешне используемой на диаграммах нотацией. S-Designor реализует стандартную методологию моделирования данных и генерирует описание БД для таких СУБД, как ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др. Для существующих систем выполняется реинжиниринг БД.

S-Designor совместим с рядом средств разработки приложений (PowerBuilder, Uniface, TeamWindows и др.) и позволяет экспортировать описание БД в репозитории данных средств. Для PowerBuilder выполняется также прямая генерация шаблонов приложений.

CASE.Аналитик 1.1 является практически единственным в настоящее время конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с методологией. Его основные функции:

  • построение и редактирование DFD;

  • анализ диаграмм и проектных спецификаций на полноту и непротиворечивость;

  • получение разнообразных отчетов по проекту;

  • генерация макетов документов в соответствии с требованиями ГОСТ 19.ХХХ и 34.ХХХ.

Среда функционирования: процессор – 386 и выше, основная память – 4 Мб, дисковая память – 5 Мб, MS Windows 3.x или Windows 95.

База данных проекта реализована в формате СУБД Paradox и является открытой для доступа. С помощью отдельного программного продукта (Catherine) выполняется обмен данными с CASE-средством ERwin. При этом из проекта, выполненного в CASE.Аналитике, экспортируется описание структур данных и накопителей данных, которое по определенным правилам формирует описание сущностей и их атрибутов.

Объектно-ориентированные CASE-средства (Rational Rose)

Rational Rose – CASE-средство фирмы Rational Software Corporation (США) – предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: Буча, Рамбо и Джекобсона. Разработанная ими универсальная нотация для моделирования объектов (UML – Unified Modeling Language) претендует на роль стандарта в области объектно-ориентированного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вариант – Rational Rose/C++ – позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

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

В составе Rational Rose можно выделить 6 основных структурных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реинжиниринг – восстановление модели проекта по исходным текстам программ.

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

Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в логической и физической моделях проекта, формируют файлы заголовков и файлы описаний классов и объектов. Создаваемый таким образом скелет программы может быть уточнен путем прямого программирования на языке С++. Анализатор кодов С++ реализован в виде отдельного программного модуля. Его назначение состоит в том, чтобы создавать модули проектов в форме Rational Rose на основе информации, содержащейся в определяемых пользователем исходных текстах на С++. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. Анализатор обладает широкими возможностями настройки по входу и выходу.

Таким образом, Rational Rose/С++ обеспечивает возможность повторного использования программных компонент.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

  • диаграммы классов;

  • диаграммы состояний;

  • диаграммы сценариев;

  • диаграммы модулей;

  • диаграммы процессов;

  • спецификации классов, объектов, атрибутов и операций;

  • заготовки текстов программ;

  • модель разрабатываемой программной системы.

Среда функционирования

Rational Rose функционирует на различных платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

БИБЛИОГРАФИЧЕСКИЙ СПИСОК

  1. Вендров А.М. Один из подходов к выбору средств проектирования баз данных и приложений. – "СУБД", 1995, № 3.

  2. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем: интернет-издание. Адрес сайта: /library/vendrov/index.htm

  3. Зиндер Е.З. Бизнес-реинжиниринг и технологии системного проектирования. Учебное пособие. – М.: Центр Информационных Технологий, 1996.

  4. Калянов Г.Н. CASE. Структурный системный анализ (автоматизация и применение). – М.: "Лори", 1996.

  5. Марка Д.А., МакГоуэн К. Методология структурного анализа и проектирования. – М.: "МетаТехнология", 1993.

КРАСИЛЬНИКОВА Мария Владимировна

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

Рецензент доц. Громов С.В.

Редактор Г.В. Атмашкина

________________________________________________________

Уч.-изд. л. 1,8 Тираж 100 экз.

Заказ Цена «С» Регистрационный №

Электростальский политехнический институт (филиал)

Московского государственного института стали и сплавов

(Технологического университета) (ЭПИ МИСиС)

144000, Московская обл., г. Электросталь, ул. Первомайская, д. 7.

1 Редуцированный – уменьшенный, пониженный



Скачать документ

Похожие документы:

  1. Программы учебных дисциплин Допущено Учебно-методическим объединением по направлениям педагогического образования Министерства образования и науки РФ в качестве учебно-методических материалов по направлению «050700 Педагогика»

    Документ
    П 44 Подготовка магистра в сфере дошкольного и начального образования (программы учебных дисциплин). В 3-х ч. Часть 2./ Под ред. Г.И.Вергелес, М.И.Калинина, Л.
  2. Секция 4 Учебники и учебные пособия

    Учебники и учебные пособия
    In the work questions of merit of use of electronic learning means for students are considered. The possibility of freedom of choice of different parameters of acquisition knowledge process is singled out as basic merit.
  3. Т. В. Дергилева формирование и развитие информационно-библиотечной системы российской академии наук (организационно-методический аспект) Учебное пособие

    Учебное пособие
    В учебном пособии изложена история формирования и развития информационно-библиотечной системы Российской академии наук с момента организации первых академических библиотек до 2003 г.
  4. В. В. Гура Теоретические основы педагогического проектирования личностно-ориентированных электронных образовательных ресурсов и сред

    Монография
    Гура В.В. Теоретические основы педагогического проектирования личностно-ориентированных электронных образовательных ресурсов и сред. Ростов н/Д: Изд-во Южного федерального ун-та, 2007.
  5. 1992 2010 Анисимов О. С

    Документ
    Анцупов А.Я. Социально-психологические проблемы: предупреждение и разрешение межличностных конфликтов во взаимоотношениях офицеров. - М.: ГА ВС, 1992.

Другие похожие документы..