Доклад: Деятельность с ценными бумагами в КБ
CASE
- модель жизненного цикла ПО
CASE
- технологии предлагают новый, основанный на автоматизации подход к концепции
ЖЦ, ПО. При использовании CASE изменяются все фазы ЖЦ, при этом наибольшие
изменения касаются фаз анализа и проектирования . На рис. 1.1а приводится
простейшая модель ЖЦ, и соответствующая CASE - модель ( рис.1.1б), в которой
фаза прототипирования заменяет традиционную фазу системного анализа. Необходимо
отметить, что наиболее автоматизируемыми фазами являются фазы контроля проекта
и кодогенерации хотя все остальные фазы также поддерживаются CASE -
средствами).
В
таблице 1.1 приведены оценки трудозатрат по фазам ЖЦ . Первая строка таблицы
соответствует традиционной разработке, вторая - разработке с использованием
структурных методологий проектирования, третья - разработке с использованием
CASE - технологий. В таблицу 1.2 сведены основные изменения в ЖЦ при
использовании CASE - технологий по сравнению с традиционной разработкой.
Прототипирование
а)
б)
Рис.
1.1 Модель жизненного цикла ПО.
Таблица
1.1
Анализ |
Проектирование |
Кодирование |
Тестирование |
20% |
15% |
20% |
45% |
30% |
30% |
15% |
25% |
40% |
40% |
5% |
15% |
Таблица
1.2
NN |
Традиционная разработка |
CASE |
1 |
Основные усилия - на кодирование и
тестирование |
Основные усилия - на анализ и
проектирование |
2 |
“Бумажные” спецификации |
Быстрое итеративное Прототипирование |
3 |
Ручное кодирование |
Автоматическая кодогенерация |
4 |
Ручное документирование |
Автоматическая генерация документации |
5 |
Тестирование кодов |
Автоматический контроль проекта |
6 |
Сопровождение кодов |
Сопровождение спецификаций
проектирования |
Состав,
структура и функциональные особенности CASE-средств
CASE
- средства служат инструментарием для поддержки и усиления методов структурного
анализа и проектирования. Эти инструменты поддерживают работу пользователей при
создании и редактировании графического проекта в интерактивном режиме, они
способствуют организации проекта в виде иерархии уровней абстракции, выполняют
проверки соответствия компонентов. Фактически CASE- средства представляют собой
новый тип графически-ориентированных инструментов, восходящих к системе
поддержки ЖЦ ПО. Обычно к ним относят любое программное средство,
обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или
деятельности по управлению проектом, и проявляющее следующие дополнительные
черты:
мощная
графика для описания и документирования систем ПО, а также для улучшения
интерфейса с пользователем, развивающая творческие возможности специалистов и
не отвлекающая их от процесса проектирования на решение второстепенных
вопросов;
интеграция,
обеспечивающая легкость передачи данных между средствами и позволяющая
управлять всем процессом проектирования и разработки ПО непосредственно через
процесс планирования проекта;
использование
компьютерного хранилища ( репозитария )для всей информации о проекте, которая
может разделяться между разработчиками и исполнителями как основа для
автоматического продуцирования ПО и повторного его использования в будущих
системах.
Помимо
перечисленных основополагающих принципов графической ориентации, интеграции и
локализации сей проектной информации в репозитарии в основе концептуального
построения CASE - средств лежат следующие положения:
Человеческий
фактор, определяющий разработку ПО как легкий, удобный и экономичный процесс.
Широкое
использование базовых программных средств, получивших массовое распространение
в других приложениях (БД и СУБД, компиляторы с различных языков
программирования, отладчики, документаторы, издательские системы, оболочки
экспертных систем и базы знаний, языки четвертого поколения и др.).
Автоматизированная
или автоматическая кодогенерация, выполняющая несколько видов генерации кодов;
преобразования для получения документации, формирования БД, ввода/модификации
данных, получения выполняемых машинных кодой из спецификаций ПО, автоматической
сборки модулей из словарей и моделей данных и повторно используемых программ,
автоматической конверсии ранее используемых файлов н форматы новых требований.
Ограничение
сложности, позволяющее получать компоненты, поддающиеся управлению, обозримые и
доступные для понимания, а также обладающие простой и ясной структурой.
Доступность
для разных категорий пользователей.
Рентабельность.
Сопровождаемость
, обеспечивающая способность адаптации при изменении требований и целей проекта.
Интегрированный
СА5Е-пакет содержит четыре основные компонента:
Средства
централизованного хранения всем информации о проектируемом ПО в течении всего
ЖЦ ( репозитарий ) являются основой CASE - пакета. Соответствующая БД должна
иметь возможность поддерживать большую систему описаний и характеристик и
предусматривать надежные меры по защите от ошибок и потерь информации.
Репозитарий должен обеспечивать:
инкрементный
режим при вводе описаний объектов,
распространение
действия нового ил и скорректированного описания на информационное пространство
всего проекта;
синхронизацию
поступления информации от различных пользователей;
хранение
версий проекта и его отдельных компонентов;
сборку
любой запрошенной версии;
контроль
информации на корректность, полноту и состоятельность.
2.
Средства ввода предназначены для ввода данных в репозитарий, а также для
организации взаимодействия с САSE - пакетом. Эти
средства должны поддерживать различные методологии и использоваться на всем ЖЦ
разными категориями разработчиков: аналитиками, проектировщиками, инженерами,
администраторами и т.д.
3.
Средства анализа, проектирования и разработки предназначены для того, чтобы
обеспечить планирование и анализ различных описаний, а также их преобразования
в процессе разработки;
4.
Средства вывода служат для документирования, управления проектом и кодовой
генерации.
Все
перечисленные компоненты в совокупности должны:
поддерживать
графические модели;
контролировать
ошибки;
организовывать
и поддерживать репозитарий;
поддерживать
процесс проектирования и разработки.
Поддержка
графических моделей
Графическая
ориентация CASE заключается в том, что программы являются схематическими
проектами и формами, которые много проще в использовании, чем многостраничные
описания. Для представления программ применяются структурные диаграммы
различных типов, дополнительное достоинство которых заключается в их
использовании в качестве наглядной “двумерной” документации по проекту.
Для
CASE существенны 4 типа диаграмм: диаграммы функционального проектирования (для
этих целей наиболее часто употребляются DFD-диаграммы потоков данных), диаграммы моделирования данных (как
правило, ERD -диаграммы “сущность-связь”), диаграммы
моделирования поведения (как правило, STD-диаграммы
переходов состояний) и структурные диаграммы (карты), применяющиеся на этапе
проектирования и описывающие отношения между модулями и внутри модульную
структуру. Создание н модификация подобных диаграмм осуществляется с помощью
специальных графических редакторов диаграммеров, являющихся сервисными
средствами на этапах анализа требований и проектирования спецификами.
Современные диаграммеры обеспечивают:
создание
иерархически связанных диаграмм, в которых комбинируются графические и
текстовые объекты;
создание
и редактирование объектов в любом месте диаграммы;
создание,
перемещение и выравнивание групп объектов, изменение их размеров,
масштабирование;
сохранение
связей между объектами при их перемещении и изменении размеров,
автоматический
контроль ошибок и др.
Реализация
подобных возможностей позволяет пользователю целиком сосредоточиться на
собственно проектировании, не отвлекаясь на решение второстепенных просев,
связанных с размещением элементов диаграмм, их компоновкой и т.п.
Полученные
диаграммы дают ясное понимание и решение проблемы, позволяют проанализировать
функционирование создаваемого ПО, фиксируют с вязи между разработчиками,
пользователями и руководителями, обеспечивают стандартизацию представления
структуры программы и данных.
Контроль
ошибок
Важность
контроля ошибок на этапах анализа требований и проектирования спецификаций
обуславливается возможностью их автоматического обнаружения на ранних этапах
ЖЦ. CASE обеспечивает автоматическую верификацию и контроль проекта на полноту
и состоятельность на ранних этапах ЖЦ, что влияет на успех разработки в целом.
В подтверждение этого можно привести следующие статистические данные,
основанные на отчетах фирмы TRW по анализу 5
крупных проектов :
при
традиционной организации работ ошибки проектирования и кодирования составляют,
соответственно, 64% и 32% от общего числа ошибок;
ошибки
проектирования в 100 раз труднее обнаружить на этапе сопровождения ПО, чем на
этапах анализа требований и проектирования спецификаций.
В
CASE диаграммеры и верификаторы способны осуществлять следующие типы контроля:
1.
Контроль синтаксиса диаграмм и типов их элементов. Обычно такой контроль
осуществляется при вводе и редактировании элементов диаграмм.
Примеры
контролируемых ситуаций:
по
синтаксису: любой функциональный элемент диаграммы должен иметь по крайней мере
один входной и один выходной поток, два элемента данных не могут быть
непосредственно связаны;
по
типам функциональный элемент должен всегда использоваться для представления
процедурного компонента; поток данных всегда должен быть представлен
компонентом данных.
2.
Контроль полноты и состоятельности диаграмм все элементы диаграмм должны быть
идентифицированы и отражены в репозитарии. Например для DFD контролируются неименованные или
несвязанные потоки данных, процессы и хранилища данных, источники и стоки данных
(внешние сущности) вне контекстной диаграммы, хранилища данных на контекстной
диаграмме и т.д. При анализе словаря данных необходимо выявлять циклические
определения, эквивалентные определения, неопределенные объекты.
3.
Контроль декомпозиции функций включает оценку качества на основе различных
метрик ПО и частичный семантический контроль.
4.
Сквозной контроль диаграмм одного или различных типов на предмет их
состоятельности по уровням - вертикальное и горизонтальное балансирование
диаграмм. При вертикальном балансировании (диаграммы одного типа) выявляются
несбалансированные потоки данных между детализируемой и детализирующей
диаграммами. Горизонтальное балансирование определяет некорректности между DFD, ERD, STD, словарями данных и миниспецификациями процессов.
Так при балансировании DFD-ERD контролируется соответствие каждого
хранилища данных на DFD сущности или отношению на ERD. Контроль DED-STD осуществляется по следующим правилам:
каждый управляющий процесс на DFD
детализируется спецификацией управления STD, и наоборот, каждой STD
должен соответствовать управляющий процесс, каждое условие (действие) в STD должно соответствовать входному
(выходному) управляющему потоку на DFD, и
наоборот, каждому управляющему потоку в зависимости от его направленности должно
соответствовать условие/действие на STD. При
балансировании DFD-словарь данных - миниспецификация должны
проверяться следующие правила:
каждый
поток и хранилище данных должны быть определены в словаре данных (контроль
неопределенных значений), и наоборот, каждое определение в словаре должно быть
отражено на диаграмме, в миниспецификации или другом определении (контроль
неиспользуемых значений);
каждый
процесс на DFD должен детализироваться с помощью DFD или миниспецификации (но не тем и другим
одновременно), и наоборот, каждая миннспецификация должна соответствовать
единственному процессу;
ссылки
к данным в миниспецификациях должны соответствовать объектам на диаграммах и в
словаре данных;
по
возможности должна контролироваться семантика миниспецификации: например, если
входные и/или выходные потоки связаны с хранилищем данных то это должно быть
отражено в миниспецификации (операторами READ, GET, WRITE, PUT и т.п.).
Организация
и поддержка репозитария.
Основные
функции средств организации и поддержки репозитария - хранение, доступ,
обновление, анализ и визуализация всей информации по проекту ПО. Содержимое
репозитария включает не только информационные объекты различных типов, но и
отношения между их компонентами, а также правила использования или обработки
этих компонентов (рис. 1.3). Репозитарий может хранить свыше 100 типов
объектов, примерами которых являются структурные диаграммы, определения экранов
и меню, проекты отчетов, описания данных, логика обработки, модели данных,
модели организации, модели обработки, исходные коды, элементы данных и т.п.
Рис.
1.3 Содержимое репозитария
Каждый
информационный объект в репозитарии описывается перечислением его свойств:
идентификатор, имена-синонимы, тип, текстовое описание, компоненты,
файл-хранилище, область значений. Кроме этого, хранятся все отношения с другими
объектами (например, все объекты, в которых данный объект используется, все
перекрестные ссылки), правила формирования и редактирования объекта, а также
контрольная информация о времени порождения объекта, времени его последнего
обновления, кем и в каком проекте он был порожден, номере версии, возможности
обновления и т.п.
На
основе репозитария осуществляется интеграция CASE - средств и разделение системной информации между разработчиками.
При этом возможности репозитария обеспечивают несколько уровней интеграции:
общий пользовательский интерфейс по всем средствам, передачу данных между
средствами, интеграцию этапов разработки через единую систему представлений фаз
ЖЦ, передачу данных и средств между аппаратурными платформами.
Репозитарий
является базой для стандартизации документов по проекту и контроля
состоятельности проектных спецификаций. Все отчеты строятся автоматически по
репозитарию, ниже перечислены основные их типы:
Отчеты
по содержимому включают сводки потоков данных и их компонентов, сводки всех пар
интерфейсов в описывающих межмодульные отношения структурных диаграммах, списки
входных и выходных потоков для каждого функционального блока диаграмм, списки
измененных за определенный период объектов, истории всех изменений объектов,
описания модулей, планы тестирования модулей и подпрограмм, списки всех данных
и их атрибутов, а также отношений между их компонентами и правил их обработки.
Отчеты
по перекрестным ссылкам включают списки всех вызывающих и вызываемых модулей;
списки объектов репозитария, к которым имеет доступ конкретный разработчик;
сводки диаграмм, использующих конкретные данные, маршруты движения данных от
входа к выходу.
Отчеты
по результатам анализа включают сводки балансирования диаграмм по уровням,
списки неопределенных информационных объектов, списки неполных диаграмм, сводки
результатов анализа структуры проекта, списки несогласованных в диаграммах и
репозитарии объектов, списки неиспользуемых объектов, списки удаленных
объектов.
Отчеты
по декомпозиции объектов включают таблицы иерархии всех объектов модели.
Пример
отчета по функциональным блокам SADT-модели
управления банком, автоматически создаваемого пакетом Desing/IDEF, приведен ниже.
Activity Report
[A0] Банк
Inputs:
Платежные документы
Outputs: Деньги
Controls:
Законы, Время, Баланс
Mechanisms :
Техника, Сотрудники
Sub-Activities: [А1] Операционные залы,
[А2]
Управление банком,
[АЗ]
Центральный банк
[А1]
Операционные залы
Inputs:
Платежные документы
Outputs:
Принятые платежные документы
Controls:
Законы, Продолжит. раб. дня. Остатки счетов клиентов
Mechanisms :
Сотрудники, Терминал БД
[А2]
Управление банком
Inputs: Принятые
платежные документы
Outputs: (Unlabled), Деньги,
(Unlabled)
Controls: Спец.
законы. Расчет баланса. Срок обработки
Mechanisms:
Управленческий персонал. Компьютеры
[АЗ]
Центральный банк
Inputs: (Unlabled)
Outputs : Деньги, ( Unabled )
Controls: Срок
отправки
Mechanisms:
Экспедиторы, Автомашины
Done
Важные
функции управления и контроля проекта также реализуются на основе репозитария.
В частности, через репозитарий может осуществляться контроль безопасности
(ограничения доступа, привилегии доступа), контроль версии, контроль изменений
и др.
Поддержка
процесса проектирования и разработки
При
поддержке процесса проектирования и разработки основную роль играют следующие
возможности CASE - проектов: покрытие ЖЦ, поддержка прототипирования, поддержка
структурных методологий, автоматическая кодогенерация.
При
покрытии ЖЦ, наибольшее внимание уделяется его критическим этапам - анализу
требований и проектированию спецификаций. Последние являются основой проекта,
поэтому их полнота и корректность влияют на успех разработки в целом.
Важную
роль при автоматизации ранних этапов ЖЦ грают возможности поддержки
прототипирования. Соответствующие средства используются для определения
системных требований и ответа на вопросы об ожидаемом поведении системы. Такие
средства как генераторы меню, экраном и отчетов позволяют быстро построить
прототипы пользовательских интерфейсов и снабдить моделью функционирования
системы с позиций конечного пользователя . Использование языков четвертого
поколения ( 4Gl ) позволяет строить более сложные модели,
при этом прототип позволяет промоделировать основные функции системы, но не
способен контролировать ее ожидаемое поведение. Исполняемые языки спецификаций
Страницы: 1, 2, 3, 4
|