Практическая работа по дисциплине «Методы и средства проектирования информационных систем» для ОАТК



ПРАКТИЧЕСКАЯ РАБОТА «ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА
ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ»
Оглавление
Классификация CASE-средств………………………………………………………………………………………………………………………1
Примеры различных CASE-средств………………………………………………………………………………………………………………5
Вспомогательные средства поддержки жизненного цикла ПО……………………………………………………………………15
Порядок выполнения практической работы: ……………………………………………………………………………………………..20
Цель работы: ознакомиться с инструментальными средствами проектирования
информационных систем, их классификацией и примерами.
Краткие теоретические сведения
Классификация CASE-средств
Таблица 1. Классификация CASE-средств
Все CASE-средства делятся на типы, категории и уровни. Классификация по
типам отражает функциональную ориентацию CASE- средств в технологическом
процессе.
1) Анализ и проектирование. Средства данной группы используются для
создания спецификаций системы и ее проектирования; они поддерживают широко
известные методологии проектирования. К таким средствам относятся: CASE,
Аналитик (Эйтэкс), The Developer (ASYST Technologies), POSE (Computer Systems
Advisers), ProKil*Workbench (McDonnell Douglas), Excelerator (Index Technology),
Design-Aid (Naslec), Design Machine (Optima), MicroStep (Meta Systems), vsDesigner
(Visucil Sofhvctrr), Anuijsl’Designer (Yourdon), Design/lDEF (Meta Soft\vare), BPWin (Logic
Works). SELECT (Select Sofhvare Tools), System Architect (Popkin Software & Systems),
Wesfmounl I-C.iSE Youi-don (Westmount Technology B. V. & CADRE Technologies),
CASE/4/0 (microTOOL GmbH). Их целью является определение системных требований
и свойств, которыми система должна обладать, а также создание проекта системы,
удовлетворяющей этим требованиям и обладающей соответствующими свойствами.
На выходе продуцируются спецификации компонент системы и интерфейсов,
связывающих эти компоненты, а также «калька» архитектуры системы и детальная
«калька» проекта, включающая алгоритмы и определения структур данных.
2) Проектирование баз данных и файлов. Средства данной группы
обеспечивают логическое моделирование данных, автоматическое преобразование
моделей данных в Третью Нормальную Форму, автоматическую генерацию схем БД и
описаний форматов файлов на уровне программного кода: ERWin (Logic Works), Chen
Toolkit (Chen & Asssociales), S-Designor (SDP), Designer2000 (Oracle), Silverrun (Computer
Systems Advisers).
3) Программирование. Средства этой группы поддерживают этапы
программирования и тестирования, а также автоматическую кодогенерацию из
спецификаций, получая полностью документированную выполняемую программу:
COBOL 2/Workhench (Mikro Focus), DECASE (DEC), NETRON/CAP (Netron), APS (Sage
Softwtire). Помимо диаграммеров различного назначения и средств поддержки
работы с репозиторием. в эту группу средств включены и традиционные генераторы
кодов, анализаторы кодов (как в статике, так и в динамике), генераторы наборов
тестов, анализаторы покрытия тестами, отладчики.
4) Сопровождение и реинжиниринг. К таким средствам относятся
документаторы, анализаторы программ, средства реструктурирования и
реинжениринга: Adpac CASE Tools (Adpac). Scan/COBOL, u Superstructure (Computer
Data Systems), Inspector/Recoder (Language Technology). Их целью является
корректировка, изменение, анализ, преобразование и реинжениринг существующей
системы.
Средства позволяют осуществлять поддержку всей системной документации,
включая коды, спецификации, наборы тестов; контролировать покрытие тестами для
оценки полноты тестируемости; управлять функционированием системы и т.п.
Особый интерес представляют средства обеспечения мобильности (в CASE они
получили название средств миграции) и реинжиниринга. К средствам миграции
относятся трансляторы, конверторы, макрогенераторы и др., позволяющие
обеспечить перенос существующей системы в новое операционное или
аппаратурное окружение.
Средства реинжиниринга включают:
 статические анализаторы для продуцирования схем системы ПО из ее кодов,
оценки влияния модификаций (например, «эффекта ряби» — внесение изменений с
целью исправления ошибок порождает новые ошибки);
 динамические анализаторы (обычно, компиляторы и интерпретаторы с
встроенными отладочными возможностями);
 документаторы, позволяющие автоматически получать обновленную
документацию при изменении кода;
 редакторы кодов, автоматически изменяющие при редактировании и все
предшествующие коду структуры (например, спецификации);
 средства доступа к спецификациям, их модификации и генерации нового
(модифицированного) кода;
 средства реверсного инжиниринга, транслирующие коды в спецификации.
5) Окружение. Средства поддержки платформ для интеграции, создания и
придания товарного вида CASE-средствам: Multi/Cam (AGS Management Systems),
Design/OA (Meta Software).
6) Управление проектом. Средства, поддерживающие планирование, контроль.
руководство, взаимодействие, т.е. функции, необходимые в процессе разработки и
сопровождения проектов: Project Workbench (Applied Business Technology).
Классификация по категориям определяет уровень интегрированности по
выполняемым функциям и включает вспомогательные программы (tools), пакеты
разработчика (toolkit) и инструментальные средства (workbench).
Категория tools обозначает вспомогательный пакет, решающий небольшую
автономную задачу, принадлежащую проблеме более широкого масштаба.
Категория toolkit представляет совокупность интегрированных программных средств,
обеспечивающих помощь для одного из классов программных задач; использует
репозиторий для всей технической и управляющей информации о проекте,
концентрируясь при этом на поддержке, как правило, одной фазы или одного этапа
разработки ПО.
Категория workbench представляет собой интеграцию программных средств,
которые поддерживают системный анализ, проектирование и разработку ПО;
используют репозиторий, содержащий всю техническую и управляющую
информацию о проекте; обеспечивают автоматическую передачу системной
информации между разработчиками и этапами разработки; организуют поддержку
практически полного ЖЦ (от анализа 30 требований и проектирования ПО до
получения документированной выполняемой программы). Workbench, по сравнению
с toolkit, обладает более высокой степенью интеграции выполняемых функций,
большей самостоятельностью и автономностью использования, а также наличием
тесной связи с системными и техническими средствами аппаратно- вычислительной
среды, на которой workbench функционирует. По существу, workbench может
рассматриваться как автоматизированная рабочая станция, используемая как
инструментарий для автоматизации всех или отдельных совокупностей работ по
созданию ПО.
Классификация по уровням связана с областью действия CASE в пределах
жизненного цикла ПО. Однако четкие критерии определения границ между
уровнями не установлены, поэтому данная классификация имеет, вообще говоря,
качественный характер.
Верхние (Upper) CASE часто называют средствами компьютерного
планирования. Они призваны повышать эффективность деятельности руководителей
фирмы и проекта путем сокращения затрат на определение политики фирмы и на
создание общего плана проекта. Этот план включает цели и стратегии их достижения,
основные действия в свете целей и задач фирмы, установление стандартов на
различные виды взаимосвязей и т.д. Использование верхних CASE позволяет
построить модель предметной области, отражающую всю существующую специфику.
Она направлена на понимание общего и частного механизмов функционирования,
имеющихся возможностей, ресурсов, целей проекта в соответствии с назначением
фирмы. Эти средства позволяют проводить анализ различных сценариев (в том числе
наилучших и наихудших), накапливая информацию для принятия оптимальных
решений.
Средние (Middle) CASE считаются средствами поддержки этапов анализа
требований и проектирования спецификаций и структуры ПО. Их использование
существенно сокращает цикл разработки проекта; при этом важную роль играет
возможность накопления и хранения знаний, обычно имеющихся только в голове
разработчика-аналитика, что позволит использовать накопленные решения при
создании других проектов.
Основная выгода от использования среднего CASE состоит в значительном
облегчении проектирования систем, проектирование превращается в итеративный
процесс, включающий следующие действия:
 пользователь обсуждает с аналитиком требования к проектируемой системе;
 аналитик документирует эти требования, используя диаграммы и словари
входных данных;
 пользователь проверяет эти диаграммы и словари, при необходимости
модифицируя их;
 аналитик отвечает на эти модификации, изменяя соответствующие
спецификации.
Кроме того, средние CASE обеспечивают возможности быстрого
документирования требований и быстрого прототипирования.
Нижние (Lower) CASE являются средствами разработки ПО (при этом может
использоваться до 30% спецификаций, созданных средствами среднего CASE). Они
содержат системные словари и графические средства, исключающие необходимость
разработки физических спецификаций. Имеются системные спецификации, которые
непосредственно переводятся в программные коды разрабатываемой системы (при
этом автоматически генерируется до 80-90% кодов). На эти средства возложены
также функции тестирования, управления конфигурацией, формирования
документации. Главными преимуществами нижних CASE являются: значительное
уменьшение времени на разработку, облегчение модификаций, поддержка
возможностей прототипирования (совместно со средними CASE).
Примеры различных CASE-средств
1. Silverrun
CASE-средство Silverrun американской фирмы Сomputer Systems Advisers, Inc.
(CSA) используется для анализа и проектирования ИС бизнес- класса и
ориентировано в большей степени на спиральную модель ЖЦ. Оно применимо для
поддержки любой методологии, основанной на раздельном построении
функциональной и информационной моделей (диаграмм потоков данных и
диаграмм «сущность-связь»). Настройка на конкретную методологию обеспечивается
выбором требуемой графической нотации моделей и набора правил проверки
проектных спецификаций. В системе имеются готовые настройки для наиболее
распространенных методологий: DATARUN (основная методология, поддерживаемая
Silverrun), Gane/Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information
Engineering. Для каждого понятия, введенного в проекте имеется возможность
добавления собственных описателей. Архитектура Silverrun позволяет наращивать
среду разработки по мере необходимости.
Структура и функции
Silverrun имеет модульную структуру и состоит из четырех модулей, каждый из
которых является самостоятельным продуктом и может приобретаться и
использоваться без связи с остальными модулями.
 Модуль построения моделей бизнес-процессов в форме диаграмм
потоков данных (BPM — Business Process Modeler) позволяет моделировать
функционирование обследуемой организации или создаваемой ИС. В модуле BPM
обеспечена возможность работы с моделями большой сложности: автоматическая
перенумерация, работа с деревом процессов (включая визуальное перетаскивание
ветвей), отсоединение и присоединение частей модели для коллективной
разработки. Диаграммы могут изображаться в нескольких предопределенных
нотациях, включая Yourdon/DeMarco и Gane/Sarson. Имеется также возможность
создавать собственные нотации, в том числе добавлять в число изображаемых на
схеме дескрипторов определенные пользователем поля.
 Модуль концептуального моделирования данных (ERX – EntityRelationship
eXpert) обеспечивает построение моделей данных «сущность- связь», не
привязанных к конкретной реализации. Этот модуль имеет встроенную экспертную
систему, позволяющую создать корректную нормализованную модель данных
посредством ответов на содержательные вопросы о взаимосвязи данных.
Возможно автоматическое построение модели данных из описаний структур
данных. Анализ функциональных зависимостей атрибутов дает возможность
проверить соответствие модели требованиям третьей нормальной формы и
обеспечить их выполнение. Проверенная модель передается в модуль RDM.
 Модуль реляционного моделирования (RDM – Relational Data Modeler)
позволяет создавать детализированные модели «сущность-связь»,
предназначенные для реализации в реляционной базе данных. В этом модуле
документируются все конструкции, связанные с построением базы данных:
индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и
расширяемость репозитория позволяют работать по любой методологии.
Возможность создавать подсхемы соответствует подходу ANSI SPARC к
представлению схемы базы данных. На языке подсхем моделируются как узлы
распределенной обработки, так и пользовательские представления. Этот модуль
обеспечивает проектирование и полное документирование реляционных баз
данных.
 Менеджер репозитория рабочей группы (WRM – Workgroup Repository
Manager) применяется как словарь данных для хранения общей для всех моделей
информации, а также обеспечивает интеграцию модулей Silverrun в единую среду
проектирования. Платой за высокую гибкость и разнообразие изобразительных
средств построения моделей является такой недостаток Silverrun, как отсутствие
жесткого взаимного контроля между компонентами различных моделей
(например, возможности автоматического распространения изменений между DFD
различных уровней декомпозиции). Следует, однако, отметить, что этот недостаток
может иметь существенное значение только в случае использования каскадной
модели ЖЦ ПО.
Взаимодействие с другими средствами .
Для автоматической генерации схем баз данных у Silverrun существуют мосты к
наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server,
SQLBase, Sybase. Для передачи данных в средства разработки приложений имеются
мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все
мосты позволяют загрузить в Silverrun RDM информацию из каталогов
соответствующих СУБД или языков 4GL. Это позволяет документировать,
перепроектировать или переносить на новые платформы уже находящиеся в
эксплуатации базы данных и прикладные системы. При использовании моста
Silverrun расширяет свой внутренний репозиторий специфичными для целевой
системы атрибутами. После определения значений этих атрибутов генератор
приложений переносит их во внутренний каталог среды разработки или использует
при генерации кода на языке SQL. Таким образом, можно полностью определить
ядро базы данных с использованием всех возможностей конкретной СУБД:
триггеров, хранимых процедур, ограничений ссылочной целостности. При создании
приложения на языке 4GL данные, перенесенные из репозитория Silverrun,
используются либо для автоматической генерации интерфейсных объектов, либо для
быстрого их создания вручную.
Для обмена данными с другими средствами автоматизации проектирования,
создания специализированных процедур анализа и проверки проектных
спецификаций, составления специализированных отчетов в соответствии с
различными стандартами в системе Silverrun имеется три способа выдачи проектной
информации во внешние файлы:
1. Система отчетов. Можно, определив содержимое отчета по
репозиторию, выдать отчет в текстовый файл. Этот файл можно затем загрузить в
текстовый редактор или включить в другой отчет;
2. Система экспорта/импорта. Для более полного контроля над структурой
файлов в системе экспорта/импорта имеется возможность определять не только
содержимое экспортного файла, но и разделители записей, полей в записях,
маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не
только формировать, но и загружать в репозиторий. Это дает возможность
обмениваться данными с различными системами: другими CASE-средствами,
СУБД, текстовыми редакторами и электронными таблицами;
3. Хранение репозитория во внешних файлах через ODBC-драйверы. Для
доступа к данным репозитория из наиболее распространенных систем управления
базами данных обеспечена возможность хранить всю проектную информацию
непосредственно в формате этих СУБД.
Групповая работа
Групповая работа поддерживается в системе Silverrun двумя способами:
1. В стандартной однопользовательской версии имеется механизм
контролируемого разделения и слияния моделей. Разделив модель на части, можно
раздать их нескольким разработчикам. После детальной доработки модели
объединяются в единые спецификации;
2. Сетевая версия Silverrun позволяет осуществлять одновременную групповую
работу с моделями, хранящимися в сетевом репозитории на базе СУБД Oracle, Sybase
или Informix. При этом несколько разработчиков могут работать с одной и той же
моделью, так как блокировка объектов происходит на уровне отдельных элементов
модели.
Среда функционирования
Имеются реализации Silverrun трех платформ — MS Windows, Macintosh и OS/2
Presentation Manager — с возможностью обмена проектными данными между ними.
Для функционирования в среде Windows необходимо иметь компьютер с
процессором модели не ниже i486 и оперативную память объемом не менее 8 Мб
(рекомендуется 16 Мб). На диске полная инсталляция Silverrun занимает 20 Мб.
2. 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 лежит построение различного рода диаграмм и
спецификаций, определяющих логическую и физическую 35 структуры модели, ее
статические и динамические аспекты. В их число входят диаграммы классов,
состояний, сценариев, модулей, процессов.
В составе Rational Rose можно выделить 6 основных структурных компонент:
репозиторий, графический интерфейс пользователя, средства просмотра проекта
(browser), средства контроля проекта, средства сбора статистики и генератор
документов. К ним добавляются генератор кодов (индивидуальный для каждого
языка) и анализатор для С++, обеспечивающий реинжиниринг – восстановление
модели проекта по исходным текстам программ.
Репозиторий представляет собой объектно-ориентированную базу данных.
Средства просмотра обеспечивают «навигацию» по проекту, в том числе,
перемещение по иерархиям классов и подсистем, переключение от одного вида
диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность
находить и устранять ошибки по мере развития проекта, а не после завершения его
описания.
Генератор отчетов формирует тексты выходных документов на основе
содержащейся в репозитории информации. Средства автоматической генерации
кодов программ на языке С++, используя информацию, содержащуюся в логической
и физической моделях проекта, формируют файлы заголовков и файлы описаний
классов и объектов. Создаваемый таким образом скелет программы может быть
уточнен путем прямого программирования на языке С++. Анализатор кодов С++
реализован в виде отдельного программного модуля. Его назначение состоит в том,
чтобы создавать модули проектов в форме Rational Rose на основе информации,
содержащейся в определяемых пользователем исходных текстах на С++. В процессе
работы анализатор осуществляет контроль правильности исходных текстов и
диагностику ошибок. Модель, полученная в результате его работы, может целиком
или фрагментарно использоваться в различных проектах. Анализатор обладает
широкими возможностями настройки по входу и выходу. Например, можно
определить типы исходных файлов, базовый компилятор, задать, какая информация
должна быть включена в формируемую модель и какие элементы выходной модели
следует выводить на экран. Таким образом, Rational Rose/С++ обеспечивает
возможность повторного использования программных компонент.
В результате разработки проекта с помощью CASE-средства Rational Rose
формируются следующие документы:
1. диаграммы классов;
2. диаграммы состояний;
3. диаграммы сценариев;
4. диаграммы модулей;
5. диаграммы процессов;
6. спецификации классов, объектов, атрибутов и операций
7. заготовки текстов программ;
8. модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом,
содержащим всю необходимую информацию о проекте (в том числе необходимую
для получения всех диаграмм и спецификаций). Тексты программ являются
заготовками для последующей работы программистов. Они формируются в рабочем
каталоге в виде файлов типов .h (заголовки, содержащие описания классов) и .cpp
(заготовки программ для методов). Система включает в программные файлы
собственные комментарии, которые начинаются с последовательности символов
//##.
Состав информации, включаемой в программные файлы, определяется либо по
умолчанию, либо по усмотрению пользователя. В дальнейшем эти исходные тексты
развиваются программистами в полноценные программы. Взаимодействие с
другими средствами и организация групповой работы Rational Rose интегрируется со
средством PVCS для организации групповой работы и управления проектом и со
средством SoDA – для документирования проектов. Интеграция Rational Rose и SoDA
обеспечивается средствами SoDA. Для организации групповой работы в Rational Rose
возможно разбиение модели на управляемые подмодели. Каждая из них
независимо сохраняется на диске или загружается в модель. В качестве подмодели
может выступать категория классов или подсистема.
Для управляемой подмодели предусмотрены операции:
1. загрузка подмодели в память;
2. выгрузка подмодели из памяти;
3. сохранение подмодели на диске в виде отдельного файла;
4. установка защиты от модификации;
5. замена подмодели в памяти на новую.
Наиболее эффективно групповая работа организуется при интеграции Rational
Rose со специальными средствами управления конфигурацией и контроля версий
(PVCS). В этом случае защита от модификации устанавливается на все управляемые
подмодели, кроме тех, которые выделены конкретному разработчику. В этом случае
признак защиты от записи устанавливается для файлов, которые содержат
подмодели, поэтому при считывании «чужих» подмоделей защита их от
модификации сохраняется и случайные воздействия окажутся невозможными.
Среда функционирования Rational Rose функционирует на различных
платформах: IBM PC (в среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS),
Hewlett-Packard (HP UX), IBM RS/6000 (AIX).
Vantage Team Builder (Westmount I-CASE) Vantage Team Builder представляет
собой интегрированный программный продукт, ориентированный на реализацию
каскадной модели ЖЦ ПО и поддержку полного ЖЦ ПО.
Структура и функции
Vantage Team Builder обеспечивает выполнение следующих функций:
1. проектирование диаграмм потоков данных, «сущность-связь», структур
данных, структурных схем программ и последовательностей экранных форм;
2. проектирование диаграмм архитектуры системы – SAD (проектирование
состава и связи вычислительных средств, распределения задач системы между
вычислительными средствами, моделирование отношений типа «клиент-сервер»,
анализ использования менеджеров транзакций и особенностей функционирования
систем в реальном времени);
3. генерация кода программ на языке 4GL целевой СУБД с полным
обеспечением программной среды и генерация SQL-кода для создания таблиц БД,
индексов, ограничений целостности и хранимых процедур;
4. программирование на языке C со встроенным SQL;
5. управление версиями и конфигурацией проекта;
6. многопользовательский доступ к репозиторию проекта;
7. генерация проектной документации по стандартным и индивидуальным
шаблонам;
8. экспорт и импорт данных проекта в формате CDIF (CASE Data Interchange
Format). Vantage Team Builder поставляется в различных конфигурациях в
зависимости от используемых СУБД (ORACLE, Informix, Sybase или Ingres) или средств
разработки приложений (Uniface).
Конфигурация Vantage Team Builder for Uniface отличается от остальных
некоторой степенью ориентации на спиральную модель ЖЦ ПО за счет
возможностей быстрого прототипирования, предоставляемых Uniface. Для описания
проекта ИС используется достаточно большой набор диаграмм, конкретные
варианты которого для наиболее распространенных конфигураций приведены ниже
в таблице 2.
Таблица 2
При построении всех типов диаграмм обеспечивается контроль соответствия
моделей синтаксису используемых методов, а также контроль соответствия
одноименных элементов и их типов для различных типов диаграмм.
При построении DFD обеспечивается контроль соответствия диаграмм
различных уровней декомпозиции. Контроль за правильностью верхнего уровня DFD
осуществляется с помощью матрицы списков событий (ELM).
Для контроля за декомпозицией составных потоков данных используется
несколько вариантов их описания: в виде диаграмм структур данных (DSD) или в
нотации БНФ (форма Бэкуса-Наура).
Для построения SAD используется расширенная нотация DFD, дающая
возможность вводить понятия процессоров, задач и периферийных устройств, что
обеспечивает наглядность проектных решений.
При построении модели данных в виде ERD выполняется ее нормализация и
вводится определение физических имен элементов данных и таблиц, которые будут
использоваться в процессе генерации физической схемы данных конкретной СУБД.
Обеспечивается возможность определения альтернативных ключей сущностей и
полей, составляющих дополнительные точки входа в таблицу (поля индексов), и
мощности отношений между сущностями.
Наличие универсальной системы генерации кода, основанной на
специфицированных средствах доступа к репозиторию проекта, позволяет
поддерживать высокий уровень исполнения проектной дисциплины
разработчиками: жесткий порядок формирования моделей; жесткая структура и
содержимое документации; автоматическая генерация исходных кодов программ и
т.д. – все это обеспечивает повышение качества и надежности разрабатываемых ИС.
Для подготовки проектной документации могут использоваться издательские
системы FrameMaker, Interleaf или Word Perfect. Структура и состав проектной
документации могут быть настроены в соответствии с заданными стандартами.
Настройка выполняется без изменения проектных решений. При разработке
достаточно крупной ИС вся система в целом соответствует одному проекту как
категории Vantage Team Builder. Проект может быть декомпозирован на ряд систем,
каждая из которых соответствует некоторой относительно автономной подсистеме
ИС и разрабатывается независимо от других. В дальнейшем системы проекта могут
быть интегрированы. Процесс проектирования ИС с использованием Vantage Team
Builder реализуется в виде 4-х последовательных фаз (стадий) – анализа,
архитектуры, проектирования и реализации, при этом законченные результаты
каждой стадии полностью или частично переносятся (импортируются) в следующую
фазу.
Все диаграммы, кроме ERD, преобразуются в другой тип или изменяют вид в
соответствии с особенностями текущей фазы. Так, DFD преобразуются в фазе
архитектуры в SAD, DSD – в DTD. После завершения импорта логическая связь с
предыдущей фазой разрывается, т.е. в диаграммы могут вноситься все необходимые
изменения.
Взаимодействие с другими средствами
Конфигурация Vantage Team Builder for Uniface обеспечивает совместное
использование двух систем в рамках единой технологической среды
проектирования, при этом схемы БД (SQL-модели) переносятся в репозиторий
Uniface, и, наоборот, прикладные модели, сформированные средствами Uniface,
могут быть перенесены в репозиторий Vantage Team Builder. Возможные
рассогласования между репозиториями двух систем устраняются с помощью
специальной утилиты.
Разработка экранных форм в среде Uniface выполняется на базе диаграмм
последовательностей форм 40 (FSD) после импорта SQL-модели. Технология
разработки ИС на базе данной конфигурации показана на рисунке 1.
Структура репозитория (хранящегося непосредственно в целевой СУБД) и
интерфейсы Vantage Team Builder являются открытыми, что в принципе позволяет
интеграцию с любыми другими средствами.
Среда функционирования
Vantage Team Builder функционирует на всех основных UNIX- платформах (Solaris,
SCO UNIX, AIX, HP-UX) и VMS. Vantage Team Builder можно использовать в
конфигурации «клиент- сервер», при этом база проектных данных может
располагаться на сервере, а рабочие места разработчиков могут быть клиентами.
Рис. 1. Взаимодействие Vantage Team Builder и Uniface
Вспомогательные средства поддержки жизненного цикла ПО
Средства конфигурационного управления Цель конфигурационного управления
(КУ) – обеспечить управляемость и контролируемость процессов разработки и
сопровождения ПО. Для этого необходима точная и достоверная информация о
состоянии ПО и его компонент в каждый момент времени, а также о всех
предполагаемых и выполненных изменениях. Для решения задач КУ применяются
методы и средства обеспечивающие идентификацию состояния компонент, учет
номенклатуры всех компонент и модификаций системы в целом, контроль за
вносимыми изменениями в компоненты, структуру системы и ее функции, а также
координированное управление развитием функций и улучшением характеристик
системы.
Наиболее распространенным средством КУ является PVCS фирмы Intersolv
(США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS
Tracker, PVCS Configuration Builder и PVCS Notify. PVCS Version Manager предназначен
для управления всеми компонентами проекта и ведения планомерной
многоверсионной и многоплатформенной разработки силами команды
разработчиков в условиях одной или нескольких локальных сетей. Понятие «проект»
трактуется как совокупность файлов.
В процессе работы над проектом промежуточное состояние файлов
периодически сохраняется в архиве проекта, ведутся записи о времени сохранения,
соответствии друг другу нескольких вариантов разных файлов проекта. Кроме этого,
фиксируются имена разработчиков, ответственных за тот или иной файл, состав
файлов промежуточных версий проекта и др. Это позволяет вернуться при
необходимости к какому-либо из предыдущих состояний файла (например, при
обнаружении ошибки, которую в данный момент трудно исправить).
PVCS Version Manager предназначен для использования в рабочих группах.
Система блокировок, реализованная в PVCS Version Manager позволяет
предотвратить одновременное внесение изменений в один и тот же файл. В то же
время, PVCS Version Manager позволяет разработчикам работать с собственными
версиями общего файла с полуавтоматическим разрешением конфликтов между
ними.
Доступ к архивам PVCS Version Manager возможен не только через сам Version
Manager, но и из более чем 50 инструментальных средств, в том числе MS Visual C и
MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox и др.
Результатом работы PVCS Version Manager является созданный средствами файловой
системы репозиторий, хранящий в компактной форме все рабочие версии
программного продукта вместе с необходимыми комментариями и метками. PVCS
Version Manager функционирует в среде MS Windows, Windows 95, Windows NT, OS/2,
SunOS, Solaris, HP-UX, AIX и SCO UNIX и может исполняться на любом персональном
компьютере с процессором 80386 или выше, рабочих станциях Sun, HP и IBM (RS6000). Другим средством конфигурационного управления является PVCS Tracker –
специализированная надстройка над офисной электронной почтой, предназначенная
для обработки сообщений об ошибках в продукте, доставке их исполнителям и
контроля за исполнением.
Интеграция с PVCS Version Manager дает возможность связывать с сообщениями
те или иные компоненты проекта. Отчетные возможности PVCS Tracker включают
множество разновидностей графиков и диаграмм, отражающих состояние проекта и
процесса его отладки, срезы по различным компонентам проекта, разработчикам и
тестировщикам. С их помощью можно наглядно показать текущее состояние работы
над проектом и ее временные тенденции.
Персонал, работающий с PVCS Tracker делится на пять групп в зависимости от их
обязанностей: пользователи, разработчики, группа тестирования и контроля
качества, группа технической поддержки и сопровождения, управленческий
персонал. Этим пяти группам персонала соответствуют пять предопределенных групп
PVCS Tracker:
1. пользователи (Submitters) — имеют ограниченные права на внесение
замечаний и сообщений об ошибках в базу данных PVCS Tracker;
2. разработчики (Development Engineers) — имеют право производить основные
операции с требованиями и замечаниями в базе данных PVCS Tracker. Если
разработчики делятся на подгруппы, то для каждой подгруппы могут быть заданы
отдельные списки прав доступа;
3. тестировщики (Quality Engineers) — имеют право производить основные
операции с требованиями и замечаниями;
4. сопровождение (Support Engineers) — имеют право вносить любые замечания,
требования и рекомендации в базу данных, но не имеют прав по распределению
работ и изменению их приоритетности и сроков исполнения;
5. руководители (Managers) — имеют право распределять работы между
исполнителями и принимать решения об их надлежащем исполнении.
Руководителям разных групп могут заданы различные права доступа к базе данных
PVCS Tracker.
В дополнение к этим пяти предопределенным группам, существует группа
администратора базы данных и 11 дополнительных групп, которые могут быть
настроены в соответствии со специфическими должностными обязанностями
сотрудников, использующих PVCS Tracker.
Требование или замечание, поступающее в PVCS Tracker проходит четыре этапа
обработки:
1. регистрация — внесение замечания в базу данных;
2. распределение – назначение ответственного исполнителя и сроков
исполнения;
3. исполнение – устранение замечания, которое в свою очередь может вызвать
дополнительные замечания или требования на дополнительные работы;
4. приемка – приемка работ и снятие их с контроля или направление на
доработку.
Требования и замечания, поступающие в базу данных PVCS Tracker оформляются
в виде специальной формы, которая может содержать до 18 полей выбора
стандартных значений и до 12 произвольных текстовых строк. При разработке формы
следует определить оптимальный набор информации, характерный для всех записей
в базе данных. Для получения содержательной информации о ходе разработки PVCS
Tracker позволяет получать три типа статистических отчетов: частотные, тренды и
диаграммы распределения. Частотные отчеты содержат информацию о частоте
поступающих замечаний за один час тестирования программного продукта. Однако
универсального частотного отчета не существует, т.к. на оценку качества влияют тип
методов тестирования, серьезность выявленных ошибок и значение дефектных
модулей для функционирования всей системы. Малое число фатальных ошибок,
приводящих к полной остановке разработки, хуже большого числа замечаний к
внешнему виду интерфейса пользователя. Следовательно, частотные отчеты должны
быть настроены на выявление какого-либо конкретного аспекта качества для того,
чтобы их можно было использовать для прогнозирования окончания работ над
проектом.
Тренды содержат информацию об изменениях того или иного показателя во
времени и характеризуют стабильность и непрерывность процесса разработки. Они
позволяют ответить на вопросы:
1. успевает ли группа разработчиков справляться с поступающими замечаниями;
2. улучшается ли качество программного продукта и какова динамика этого
процесса;
3. как повлияло то или иное решение (увеличение числа разработчиков,
введение скользящего графика, внедрение нового метода тестирования) на работу
группы и т.п.
Диаграммы распределения – наиболее разнообразные и полезные для
осуществления оперативного руководства формы отчетов. Они позволяют ответить
на вопросы: какой метод тестирования более эффективен, какие модули вызывают
наибольшее число нареканий, кто из разработчиков лучше справляется с конкретным
типом заданий, нет ли перекоса в распределении работ между исполнителями, нет
ли модулей, тестированию которых было уделено недостаточно внимания и т.д.
PVCS Tracker предназначен для использования в рабочих группах, объединенных
в общую сеть. В этом случае центральная база или проект PVCS Tracker находится на
общедоступном сервере сети, доступ к которому реализуется посредством ODBCдрайверов, входящих в состав PVCS Tracker. Главной особенностью PVCS Tracker по
сравнению с обычным приложением СУБД является его способность автоматически
уведомлять пользователя о поступлении интересующей его или относящейся к его
компетенции информации и гибкая система распределения полномочий внутри
рабочей группы. При необходимости PVCS Tracker может использовать для
уведомления удаленных членов группы электронную почту. PVCS Tracker
поддерживает групповую работу в локальных сетях и взаимодействует с СУБД dBase,
ORACLE, SQL Server и SYBASE посредством ODBC. PVCS Tracker может быть
интегрирован с любой системой электронной почты, поддерживающей стандарты
VIM, MAPI или SMTP.
PVCS Version Manager и PVCS Tracker окружены вспомогательными
компонентами: PVCS Configuration Builder и PVCS Notify. PVCS Configuration Builder
предназначен для сборки окончательного продукта из компонент проекта. PVCS
Configuration Builder позволяет описывать процесс сборки как на стандартном языке
MAKE, так и на собственном внутреннем языке, имеющем существенно большие
возможности. PVCS Configuration Builder позволяет осуществлять сборку
программного продукта на основании файлов, хранящихся в репозитории PVCS
Version Manager.
Обычная процедура сборки программного продукта с помощью PVCS
Configuration Builder состоит из трех шагов:
1. строится файл зависимостей между исходными модулями;
2. в полученный файл вносятся изменения с целью его настройки и
оптимизации;
3. осуществляется сборка программного продукта из исходных модулей.
Результатом работы PVCS Configuration Builder является специальный файл,
описывающий оптимальный алгоритм сборки программного продукта, построенный
на основе анализа дерева зависимостей между исходными модулями.
PVCS Notify обеспечивает автоматическую рассылку сообщений об ошибках из
базы данных пакета PVCS Tracker по рабочим станциям назначения.
При этом используется офисная система электронной почты cc:Mail или
Microsoft Mail. PVCS Notify расширяет возможности PVCS Tracker и используется
только совместно с ним. PVCS Notify настраивается из среды PVCS Tracker. Настройка
включает в себя определение интервала времени, через который PVCS Notify
проверяет содержимое базы данных, определение критериев отбора записей для
рассылки уведомлений, определение списков адресов для рассылки. После
настройки PVCS Notify начинает работу в автономном режиме, автоматически
рассылая уведомления об изменениях в базе данных PVCS Tracker.
PVCS Notify предназначен для использования в больших рабочих группах, часть
членов которых хотя и доступна только через средства электронной почты, однако
должна иметь оперативную информацию о требованиях на изменение
программного продукта, замечаниях, ошибках, ходе и результатах его тестирования.
Результатом работы PVCS Notify являются оформленные в соответствии с одним из
стандартов почтовые сообщения, готовые для рассылки посредством системы
электронной почты.
Порядок выполнения практической работы:
1. Выполнить сравнительный анализ рассмотренных ранее методов
проектирования применительно к обследуемому предприятию.
2. Обосновать выбор того или иного средства проектирования.

Узнать сколько стоит решение этого задания
(ответ в течение 5 мин.)
X