Вопрос 9. Принципы построения, структура и технология использования систем автоматизи­ро­ванного проектирования и разработки программного обеспечения.


Добавил:DMT
Дата создания:30 декабря 2007, 18:52
Дата обновления:8 января 2008, 19:25
Просмотров:8653 последний сегодня, 7:47
Комментариев: 0

Вопрос 9. Принципы построения, структура и технология использования систем автоматизи­ро­ванного проектирования и разработки программного обеспечения.

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

1. Средства централизованного хранения всей информации о проектируемом ПО в течени и всего ЖЦ ( репозитарий ). Являются основой CASE-пакета. Соответствующая БД должна иметь возможность поддерживать большую систему описаний и характеристик и предусматривать надежные меры по защите от ошибок и потерь информации . Репозитарий должен обеспечивать : инкрементный режим при вводе описаний объектов; распространение действия нового или скорректированного описания объекта на информационное пространство всего проекта; синхронизацию поступления информации от различных пользователей; хранение версий проекта и его отдельных компонентов; сборку любой запрошенной версии; контроль информации на корректность, полноту и состоятельность.

2. Средства ввода . Предназначены для ввода данных в репозитарий , а также для организации взаимодействия с CASE-пакетом. Эти средства должны поддерживать различные методологии и использоваться на всем ЖЦ разными категориями разработчиков: аналитиками, проектировщиками, инженерами, администраторами и т.д.

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

4. Средства вывода . Служат для документирования, управления проектом и кодовой генерации.

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

Поддержка графических моделей. Графическая ориентация заключается в том, что программы представляются схематическими проектами и формами, которые много проще в использовании, чем многостраничные описания. Для представления программ применяются структурные диаграммы различных типов, дополнительное достоинство которых заключается в их использовании в качестве наглядной "двумерной" документации по проекту. Для CASE существенны 4 типа диаграмм : диаграммы функционального проектирования (для этих целей наиболее часто употребляются DFD - диаграммы потоков данных); диаграммы моделирования данных (как правило, ERD - диаграммы "сущность-связь"); диаграммы моделирования поведения (как правило, STD - диаграммы переходов состояний); структурные диаграммы (карты), применяющиеся на этапе проектирования и описывающие отношения между модулями и внутримодульную структуру.

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

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

Контроль ошибок. CASE обеспечивает автоматическую верификацию и контроль проекта на полноту и состоятельность на ранних этапах ЖЦ, что влияет на успех разработки в целом. В CASE диаграммеры и верификаторы способны осуществлять следующие типы контроля :

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

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

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

4. Сквозной контроль диаграмм одного или различных типов на предмет их состоятельности по уровням - вертикальное и горизонтальное балансирование диаграмм . При вертикальном балансировании диаграмм одного типа выявляются несбалансированные потоки данных между детализируемой и детализирующей диаграммами. Горизонтальное балансирование определяет некорректности между DFD, ERD, STD, словарями данных и миниспецификациями процессов. Так при балансировании DFD - ERD контролируется соответствие каждого хранилища данных на DFD сущности или отношению на ERD. Контроль DFD - STD осуществляется по следующим правилам: каждый управляющий процесс на DFD детализируется спецификацией управления STD, и наоборот, каждой STD должен соответствовать управляющий процесс; каждое условие/действие в STD должно соответствовать входному/выходно­му уп­равляющему потоку на DFD, и наоборот, каждому управляющему потоку в за­ви­­симости от его направленности должно соответствовать условие/действие на STD. При балансировании DFD - словарь данных - миниспецификация должны проверяться следующие правила: каждый поток и хранилище данных должны быть определены в словаре данных (контроль неопределенных значений), и наоборот, каждое определение в словаре должно быть отражено на диаграмме, в миниспецификации или другом определении (контроль неиспользуемых значений); каждый процесс на DFD должен детализироваться с помощью DFD или миниспецификации (но не тем и другим одновременно), и наоборот, каждая миниспецификация должна соответствовать единственному процессу; ссылки к данным в миниспецификациях должны соответствовать объектам на диаграммах и в словаре данных; по возможности должна контролироваться семантика миниспецификации .

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

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


ОПИСАНИЕ ОБЪЕКТА

ОТНОШЕНИЯ

С ДРУГИМИ ОБЪЕКТАМИ

КОНТРОЛЬНАЯ ИНФОРМАЦИЯ

ПРАВИЛА ОБРАБОТКИ

Репозитарий является базой для стандартизации документов по проекту и контроля состоятельности проектных спецификаций. Все отчеты строятся автоматически по репозитарию . Основные типы отчетов : 1. Отчеты по содержимому включают сводки потоков данных и их компонент, списки входных и выходных потоков для каждого функционального блока диаграмм, списки измененных за определенный период объектов, истории всех изменений объектов, описания модулей, планы тестирования модулей и подпрограмм, списки всех данных и их атрибутов, а также отношений между их компонентами и правил их обработки. 2. Отчеты по перекрестным ссылкам включают списки всех вызывающих и вызываемых модулей; списки объектов репозитария , к которым имеет доступ конкретный разработчик; сводки диаграмм, использующих конкретные данные; маршруты движения данных от входа к выходу. 3. Отчеты по результатам анализа включают сводки балансирования диаграмм по уровням, списки неопределенных информационных объектов, списки неполных диаграмм, сводки результатов анализа структуры проекта, списки несогласованных в диаграммах и репозитарии объектов, списки неиспользуемых объектов, списки удаленных объектов. 4. Отчеты по декомпозиции объектов включают таблицы иерархии всех объектов модели.

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

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

Кодогенерация осуществляется на основе репозитария и позволяет автоматически построить до 80-90% объектных кодов или текстов программ на языках высокого уровня. При этом различными CASE-пакетами поддерживаются практически все известные языки программирования, однако, наиболее часто в качестве целевых языков выступают С , COBOL и ADA.

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

Идея автоматической кодогенерации на основе модели заключается в следующем (рис).

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

Схема базы данных может быть легко сгенерирована на основании модели "сущность-связь", и современные средства информационного моделирования (например, ERwin , Designer /2000 и др.) обеспечивают такую генерацию.

Логика обработки генерируется на основе диаграмм потоков данных: известны алгоритмы автоматического преобразован ия ие рархии DFD в структурные карты и есть CASE -средства это выполняющие, а с задачей получения из структурных карт соответствующих кодов легко справляется теория компиляции.

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

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

up