Деятельность с ценными бумагами в коммерческих банках
структуры, редактирования интерфейсов (первая генерация CASE-I);
. CASE - средств генерации исходных текстов и реализации интегрированного
окружения поддержки полного жизненного цикла (ЖЦ) разработки ПО (вторая
генерация CASE-II).
CASE-I является первой технологией, адресованной непосредственно
системным аналитикам и проектировщикам, и включающей средства для поддержки
графических моделей, проектирования спецификаций, экранных редакторов и
словарей данных. Она не предназначена для поддержки полного Ж Ц и
концентрирует внимание на функциональных спецификациях и начальных шагах
проекта - системном анализе, определении требований, системном
проектировании, логическом проектировании БД.
CASE-II отличается значительно более развитыми возможностями,
улучшенными характеристиками и исчерпывающим подходом к полному ЖЦ. В ней в
первую очередь используются средства поддержки автоматической
кодогенерации, а также обеспечивается полная функциональная поддержка
порождения графических системных требований и спецификаций проектирования,
контроля, анализа и связывания системной информации, а также информации по
управлению проектированием; построения прототипов и моделей системы;
тестирования, верификации и анализа сгенерированных программ; генерации
документов по проекту; контроля на соответствие стандартам по всем этапам
ЖЦ. СА5Е-Н может включать свыше 100 функциональных компонентов,
поддерживающих все этапы ЖЦ., при этом пользователям предоставляется
возможность выбора необходимых средств и их интеграции а нужном составе.
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 - средств лежат следующие
положения:
1. Человеческий фактор, определяющий разработку ПО как легкий, удобный и
экономичный процесс.
2. Широкое использование базовых программных средств, получивших массовое
распространение в других приложениях (БД и СУБД, компиляторы с различных
языков программирования, отладчики, документаторы, издательские системы,
оболочки экспертных систем и базы знаний, языки четвертого поколения и
др.).
3. Автоматизированная или автоматическая кодогенерация, выполняющая
несколько видов генерации кодов; преобразования для получения
документации, формирования БД, ввода/модификации данных, получения
выполняемых машинных кодой из спецификаций ПО, автоматической сборки
модулей из словарей и моделей данных и повторно используемых программ,
автоматической конверсии ранее используемых файлов н форматы новых
требований.
4. Ограничение сложности, позволяющее получать компоненты, поддающиеся
управлению, обозримые и доступные для понимания, а также обладающие
простой и ясной структурой.
5. Доступность для разных категорий пользователей.
6. Рентабельность.
7. Сопровождаемость , обеспечивающая способность адаптации при изменении
требований и целей проекта.
Интегрированный СА5Е-пакет содержит четыре основные компонента:
1. Средства централизованного хранения всем информации о проектируемом ПО в
течении всего ЖЦ ( репозитарий ) являются основой 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 - средств и
разделение системной информации между разработчиками. При этом возможности
репозитария обеспечивают несколько уровней интеграции: общий
пользовательский интерфейс по всем средствам, передачу данных между
средствами, интеграцию этапов разработки через единую систему представлений
фаз ЖЦ, передачу данных и средств между аппаратурными платформами.
Репозитарий является базой для стандартизации документов по
проекту и контроля состоятельности проектных спецификаций. Все отчеты
строятся автоматически по репозитарию, ниже перечислены основные их типы:
1. Отчеты по содержимому включают сводки потоков данных и их компонентов,
сводки всех пар интерфейсов в описывающих межмодульные отношения
структурных диаграммах, списки входных и выходных потоков для каждого
функционального блока диаграмм, списки измененных за определенный период
объектов, истории всех изменений объектов, описания модулей, планы
тестирования модулей и подпрограмм, списки всех данных и их атрибутов, а
также отношений между их компонентами и правил их обработки.
2. Отчеты по перекрестным ссылкам включают списки всех вызывающих и
вызываемых модулей; списки объектов репозитария, к которым имеет доступ
конкретный разработчик; сводки диаграмм, использующих конкретные данные,
маршруты движения данных от входа к выходу.
Страницы: 1, 2, 3, 4, 5
|