Деятельность с ценными бумагами

|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. Отчеты по перекрестным ссылкам включают списки всех вызывающих и

вызываемых модулей; списки объектов репозитария, к которым имеет доступ

конкретный разработчик; сводки диаграмм, использующих конкретные данные,

маршруты движения данных от входа к выходу.

3. Отчеты по результатам анализа включают сводки балансирования диаграмм по

уровням, списки неопределенных информационных объектов, списки неполных

диаграмм, сводки результатов анализа структуры проекта, списки

несогласованных в диаграммах и репозитарии объектов, списки

неиспользуемых объектов, списки удаленных объектов.

4. Отчеты по декомпозиции объектов включают таблицы иерархии всех объектов

модели.

Пример отчета по функциональным блокам 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 ) позволяет строить более сложные модели,

при этом прототип позволяет промоделировать основные функции системы, но не

способен контролировать ее ожидаемое поведение. Исполняемые языки

спецификаций

преобразуют процесс разработки в следующий итеративный процесс:

спецификации определяются и выполняются затем производится переопределение

или корректировка

Созданные таким образом прототипы позволяют определять, является ли

проектируемая система полной и корректной.

Поддержка структурных методологий осуществляется за счет средств

их автоматизации на следующих двух уровнях:

. подготовка документации, графическая поддержка построения структурных

диаграмм различных типов, продуцирование спецификаций для детализации

функциональных блоков в диаграммах и структур данных на нижних уровнях;

. корректное использование шагов обработки в методологиях.

Кодогенерация осуществляется на основе репозитария позволяет

автоматически построить до 80-90% объектных кодов или текстов программ на

языках высокого уровня. При этом различными CASE - пакетами поддерживаются

практически все известные языки программирования, однако наиболее часто в

качестве целевых языков выступают COBOL, C и ADA. Средства кодогенерации по

отношению к полноте целевого продукта разделяются на средства генерации

каркаса ПО и средства генерации полного продукта. В первом случае

автоматически строится откомментированная логика (потоки управления) ПО, а

также коды для БД, файлов, экранов, отчетов и т.п., остальные фрагменты ПО

кодируются вручную. Во втором случае из проектных спецификаций генерируется

полная документированная программа, включая выполняемый код,

пользовательскую и программную документацию, наборы тестов и т.д. Все эти

компоненты полной программы связываются в единый объект, хранящийся в

депозитарии для облегчения доступа и сопровождения.

Приложение 3. Ценные бумаги

П.3.1. Классификация ценных бумаг

Ценная бумага представляет собой документ, который выражает

связанные с ним имущественные и неимущественные права, может

самостоятельно обращаться на рынке и быть объектом купли-продажи и других

Страницы: 1, 2, 3, 4, 5