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

Рис. 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.    Отчеты по перекрестным ссылкам включают списки всех вызывающих и вызываемых модулей; списки объектов репозитария, к которым имеет доступ конкретный разработчик; сводки диаграмм, использующих конкретные данные, маршруты движения данных от входа к выходу. 

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