Создание функциональных моделей и диаграммСбор информации Рассмотрим методы, которые использует SADT-аналитик для изучения предметной области и технологии получения от экспертов сведений о системе, подлежащих описанию. На практике эту технологию называют сбором данных, а в информатике она известна как опрос (интервьюирование) или извлечение знаний. Обычно источниками информации служат эксперты. Существует множество различных стратегий для извлечения информации из этих источников. Наиболее используемые стратегии: чтение документов; наблюдение за выполняемыми операциями; анкетирование; использование собственных знаний; составление описания. Документы – наиболее хороший источник информации, потому что они чаще всего доступны и их можно "опрашивать" в удобном для себя темпе. Чтение документов – прекрасный способ получить первоначальное представление о системе и сформулировать вопросы к экспертам. Наблюдение за работой моделируемой системы – хорошая стратегия получения информации. Во время работы системы очень часто возникают вопросы, которые никогда бы не появились в результате чтения документов или после разговоров с экспертами. Анкетирование проводится для того, чтобы опросить большие группы экспертов в сжатые сроки. Анкетирование при опросе экспертов позволяет выявить, какие части системы более всего нуждаются в улучшении. Использование собственных знаний чаще всего доступно очень опытным аналитикам, которые исследовали большое число систем определенного типа, а потому они обладают фундаментальными знаниями в соответствующей предметной области. Еще одна полезная стратегия – придумать описание и дать его экспертам для корректировки. Придуманные описания могут дать альтернативные схемы функционирования системы – схемы. Типы опроса В процессе анализа, независимо от источников информации, проводятся опросы нескольких типов. Выбор того или иного типа зависит от вида необходимой информации и поставленной цели. Наиболее распространены следующие типы опросов: опросы для сбора фактов; опросы для определения проблем; совещания для принятия решений; диалоги автор/читатель. Опросы для сбора фактов проводятся, когда пытаются определить, как функционирует система в настоящее время. Опросы для определения проблем полезны, когда вы хотите выяснить, что в системе не в порядке. Совещания для принятия решений проводятся, когда нужно получить представление о том, как должна функционировать будущая система, чтобы устранить недостатки в настоящей. Диалоги автор/читатель – это неформальные обсуждения между автором и экспертом, когда у них есть какие-то разногласия по поводу будущей системы. Процесс опроса Приведем несколько советов, которые позволяют понять основные шаги в процессе опроса: определите, является ли информация фактом или скорее мнением, задавая уточняющие вопросы; всегда спрашивайте о числах и количествах (когда речь идет о времени, объеме, затратах). Числовые характеристики придают сказанному достоверность. Уточняйте источники и назначение данных, их формат, сроки хранения, предполагаемое использование, требуемые изменения и т.д. Эти представления могут помочь определить, что представляют собой данные. Умение проводить хорошие опросы так же важно, как и умение строить хорошие диаграммы и модели. Дополнения к диаграммам и моделям Диаграммы законченной SADT-модели упорядоченно организуют все важные компоненты и детали системы. Опытные аналитики создают различные дополнения. Дополнения и уточнения, которые не входят в сами диаграммы, обогащают информационное содержание модели. Поскольку дополнительная информация формально не является частью модели, SADT рекомендует помещать такие материалы на отдельных страницах и соединять их с диаграммами модели. SADT-диаграммы могут быть дополнены информацией в виде текстов, рисунков и глоссариев. Текст обычно представляет собой рассказ об одной из частей диаграммы. Рисунки – это картинки, поясняющие отдельные моменты. Глоссарий – набор определений объектов и функций, представленных на диаграмме. Рассмотрим составление глоссария на примере процесса "подготовить рабочее место" в экспериментально-механическом цехе (рис. 25). Рис. 25. SADT-диаграмма процесса "подготовить рабочее место".
Глоссарий используется для того, чтобы собрать вместе и определить новые понятия, которые вводятся диаграммой, декомпозирующей блок, особенно если это первая декомпозиция родительского блока. Для функциональных SADT-диаграмм такими понятиями могут быть новые функции, либо новые объекты, представляемые дугами, либо декомпозиция внешних дуг. Например, дуга выбранный станок проходит только между блоками диаграммы выбрать станок и наладить станок и ранее в модели экспериментального механического цеха не появлялась, поэтому выбранный станок рассматривается как новое понятие и, следовательно, требует определения (рис. 26).
Рис. 26. Пример глоссария для процесса "подготовить рабочее место".
Оценка и выбор CASE-средств Рассмотрим модель процесса оценки и выбора, которая описывает наиболее общую ситуацию оценки и выбора, а также показывает зависимость между ними. Как можно видеть, оценка и выбор могут выполняться независимо друг от друга или вместе, каждый из этих процессов требует применения определенных критериев. Процесс оценки и выбора может преследовать несколько целей, включая одну или более из следующих: оценка нескольких CASE-средств и выбор одного или более из них; оценка одного или более CASE-средств и сохранение результатов для последующего использования; выбор одного или более CASE-средств с использованием результатов предыдущих оценок.
Как видно из рисунка 27, входной информацией для процесса оценки является: определение пользовательских потребностей; цели и ограничения проекта; данные о доступных CASE-средствах; список критериев, используемых в процессе оценки. Результаты оценки могут включать результаты предыдущих оценок. При этом не следует забывать, что набор критериев, использовавшихся при предыдущей оценке, должен быть совместимым с текущим набором. Конкретный вариант реализации процесса (оценка и выбор, оценка для будущего выбора или выбор, основанный на предыдущих оценках) определяется перечисленными выше целями. Элементы процесса включают: цели, предположения и ограничения, которые могут уточняться в ходе процесса; потребности пользователей, отражающие количественные и качественные требования пользователей к CASE-средствам; критерии, определяющие набор параметров, в соответствии с которыми производится оценка и принятие решения о выборе; формализованные результаты оценок одного или более средств; рекомендуемое решение (обычно либо решение о выборе, либо дальнейшая оценка). Процесс оценки и/или выбора может быть начат только тогда, когда лицо, группа или организация полностью определила для себя конкретные потребности и формализовала их в виде количественных и качественных требований в заданной предметной области. Термин "пользовательские требования" далее означает именно такие формализованные требования. Пользователь должен определить конкретный порядок действий и принятия решений с любыми необходимыми итерациями. Например, процесс может быть представлен в виде дерева решений с его последовательным обходом и выбором подмножеств кандидатов для более детальной оценки. Описание последовательности действий должно определять поток данных между ними. Определение списка критериев основано на пользовательских требованиях и включает: выбор критериев для использования из приведенного далее перечня; определение дополнительных критериев; определение области использования каждого критерия (оценка, выбор или оба процесса); определение одной или более метрик для каждого критерия оценки; назначение веса каждому критерию при выборе. Критерии оценки и выбора Критерии формируют базис для процессов оценки и выбора и могут принимать различные формы, включая: числовые меры в широком диапазоне значений, например, объем требуемой памяти; числовые меры в ограниченном диапазоне значений, например, простота освоения, выраженная в баллах от 1 до 5; двоичные меры (истина/ложь, да/нет), например, способность генерации документации в формате Postscript; меры, которые могут принимать одно или более из конечных множеств значений, например, платформы, для которых поддерживается CASE-средство. Типичный процесс оценки и/или выбора может использовать набор критериев различных типов.
Рис. 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). |
|