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