ПРОЦЕСС: Продажа
Описание:
1) Оформление договора по ДС и подшивка экземпляра в папку договоров
2) Оформление и выдача сертификата ЦБ
3) Оформление расходно-мемориального ордера по ценному бланку и передача его в документы дня по ЦБ
4) Формирование отчетности по ПД по выданному ДС (сумма, процентная ставка, дата оплаты)
5) Занесение в БД Де информации по договору (номер ДС, дата выдачи ДС, номер договора, дата заключения договора, процентная ставка, номинал, срок обращения, наименование держателя, банковские реквизиты держателя)
6) Запись в журнал операций
Примечание: Проводки при выдачи ДС
Д 9959 - учет бланка под ДС
К 199 Д р/сч - сумма под ДС
ПРОЦЕСС: Залог
Описание:
1) В БД Де регистрируется информация по залогу (срок залога, наименование кредитора, банковские реквизиты кредитора, размер кредита)
2) Регистрация операции в журнале операций
ПРОЦЕСС: Передача
Описание:
1) Регистрация индоссамента в доге воре
2) Регистрация операции в журнале операций
3) Изменение записи в БД Де (наименование держателя банковские реквизиты держателя)
ПРОЦЕСС: Погашение
Описание:
1) Погашение сертификата ЦБ
2) Передача погашенного сертификата и договора в документы дня по ЦБ
3) Оформление и передача распоряжения в отдел внутрибанковских операций со всеми атрибутами ДС для начисления процентов, налогов и осуществления проводок
Примечание: Проводки при Погашении ДС
ДТ-199, КТ - р/с клиента - номинал ДС
ДТ-970, КТ -р/с клиента - проценты за вычетом налога
ДТ-970, КТ -904 - налог 15% в бюджет
Активная деятельность с ценными бумагами
Процесс представлен на рис. П.1.4.
ПРОЦЕСС: Операции с ГКО
Детализация процесса в диаграмме потоков данных рис. П.1.7 и пункте 3.2.1
|
|
ПРОЦЕСС: Операции с КО
Детализация процесса в диаграмме потоков данных П.1.8 и пункте 3.2.2.
ПРОЦЕСС: Операции с ВО
Детализация процесса в диаграмме потоков данных П.1.9 и пункте 3.2.3.
Операции с ГКО
ПРОЦЕСС: Покупка
Описание:
Для каждого выпуска ГКО по каждой операции покупки вносится запись журнал лицевого учета
1) По номеру государственной регистрации выбирается текущая страница соответствующего журнала лицевого учета
2) Заполняется очередная строка страницы
(х,3) = цена сделки в % к номиналу
(х,2) = количество штук
(х,4) = (х,2)*(х,3)
ПРОЦЕСС: Продажа
Описание:
Для каждого выпуска ГКО по каждой операции продажи вносится запись в журнал лицевого учета
1) По номеру государственной регистрации выбирается текущая страница соответствующего журнала лицевого учета
2) Заполняется очередная строка страницы
(x, 5) = количество штук
(x, б) = цена сделки в % к номиналу
(x, 7) = (х,5)*(x,6)
ПРОЦЕСС: Погашение
Описание:
Для каждого выпуска ГКО по каждой операции погашения вносится запись в журнал лицевого учета
1) По номеру государственной регистрации выбирается текущая страница соответствующего журнала лицевого учета
2) Заполняется очередная строка страницы
(х,5) = количество штук
(х,6) = номинал
(х,7) = (х,5)*(х,6)
ПРОЦЕСС: Выбор операции и отчет по результату
Описание:
Для каждого выпуска ГКО формируется страница журнал лицевого учета
1) До исполнения операции осуществляется:
Выбор выпуска по номеру государственной регистрации
1 символ-= 2 - вид ЦБ (долговое обязательство)
2 символа = SU - могут отсутствовать
|
|
1символ= 1/2/3 - тип ЦБ(1 -для трехмесячных, 2 -для шестимесячных, 3-для годовых)
3 символа = порядковый номер выпуска данного типа
4 символа = RMFS
Заполнение 1-й строки страницы журнала
(1,1) = дата проведения операций
Заполнение 2-й строки - остаток на начало дня (берется из предыдущей страницы)
(2,1) = % остаток на начало дня %
(2,2) = количество ГКО данного выпуска в портфеле
(2,3) = цена предшествующего рабочего дня в % к номиналу
(2,4) =(2,2)*(2,3)
2) После исполнения операций в конце дня осуществляется:
Заполнение строки ИТОГО (валовые результаты по покупке и продаже ГКО за день) по колонкам 2,4,5,7
Заполнение строки ОСТАТОК НА КОНЕЦ ДНЯ
ОСТАТОК(2) - ИТОГО(2) -ИТОГО (5)
ОСТАТСК(3)= средняя биржевая цена по данному выпуску
ОСТАТОК(4) = ОСТАТОК(2)* ОСТАТОК(3)
Вычисление показателей
ИЗМЕНЕНИЕ ПОРТФЕЛЯ = ОСТАТОК НА КОНЕЦ(4)-ОСТАТОК НА НАЧАЛО (4)
САЛЬДО РАСЧЕТОВ=ИТОГО(7)-ИТОГО(4)
СУММА ПЕРЕОЦЕНКИ=ИЗМЕНЕНИЕ ПОРТФЕЛЯ + САЛЬДО РАСЧЕТОВ
КОМИССИЯ ММВБ=ИТОГО(4)*0,001
НАЛОГ=ИТОГО(4)*0,001
КОМИССИЯ БРОКЕРА= ИТОГО(4)*(процент комиссии)
ПРОЦЕСС: Переоценка
Описание:
По всем выпускам ГКО заполняется очередная страница журнала оборотов по операциям на основе журналов лицевого учета
1) По каждому выпуску ГКО заполняется одна строка таблицы
(*,1) = номер государственной регистрации
(*,2) = ИЗМЕНЕНИЕ ПОРТФЕЛЯ
(*,3) = САЛЬДО РАСЧЕТОВ
(*,4) = СУММА ПЕРЕОЦЕНКИ
(*,5) = ОСТАТОК НА КОНЕЦ(4)
(*,6) = (*,4) + [старое значение (*,6), которое обнуляется в начале каждого месяца]
(*,7) = КОМИССИЯ ММВБ
(*,8) = НАЛОГ
2) Подводится общий итог по колонкам 2-8 (строка ИТОГО с проверкой ИТОГО(4)=ИТОГО(2)+ИТОГО(3)
Примечание: проводки по итогам переоценки
|
|
Если ИТОГО(2)>0 то Д 194
Если ИТОГО(2)<0 то К 194
Если ИТОГО(3)>0 то Д 904
Если ИТОГО(3)<0 то К 904
Если ИТОГО(4)>0 то К 960
Если ИТОГО(4)<0 то Д 960
ИТОГО(7) Д 970, К 904
ИТОГО(8) Д 950, К 904
Операции с КО
Процесс представлен на рис. П.1.8. Опишем процессы нижнего уровня.
ПРОЦЕСС: Покупка
Описание:
Регистрация КО в журнале учета КО
- регистрационный номер выпуска (7 символов)
1-й (буква) - серия =отрасль народного хозяйства
2-З-й - день выпуска серии
4-5-й - месяц выпуска серии
6-7-й - порядковый номер выпуска
- количество ЦБ
- номинал = 1. млн.руб.
- место хранения
- номер субсчета депо
- статус субсчета
- дата начала погашения
- дата окончания погашения
-дата предъявления для обмена на налоговые освобождения
- ограничения по числу индоссаментов
Примечание: Проводки при Покупке КО
Д 194, К 904
ПРОЦЕСС: Продажа
Внесение изменений в журнал учета КО
Примечание: Проводки при Продаже КО
Д 904, К 194
ПРОЦЕСС: Погашение кредиторской задолженности
Внесение изменений в журнал учета КО
Примечание: Проводки при Погашении кредиторской задолженности
Д 904, К 194
ПРОЦЕСС: Залог
Примечание: На момент построения модели данная операция не проводилась
ПРОЦЕСС: Погашение
Внесение изменений в журнал учета КО
Примечание: Проводки при Погашении КО (по номиналу
Д 904, К 194
ПРОЦЕСС: Обмен на налоговые освобождения
Примечание: На момент построения модели данная операция не проводилась
ПРОЦЕСС: Выбор операции и отчет по результату (технологический)
Описание:
1) Производится выбор операции с КО и формирование заявки на проведение операции
2) Осуществляется формирование отчетности по проведенной операции с КО
3.2.3. Операции с ВО
ПРОЦЕСС: Покупка
Описание:
Занесение информации в журнал учета ВО (номер транша, количество ЦБ, номинал, серия, с номера...., по номер...., срок обращения, дата погашения)
Примечание: Проводки при Покупке ВО (в рублевом эквиваленте)
Д 194, К 904
ПРОЦЕСС: Продажа
Корректировка журнала учета ВО
Примечание: Проводки при Продаже ВО (в рублевом эквиваленте)
Д 904, К 194
ПРОЦЕСС: Мена
Примечание: На момент построения модели данная операция не проводилась
ПРОЦЕСС: Залог
Примечание: На момент построения модели данная операция не проводилась
ПРОЦЕСС: Договор РЕПО
Примечание: В банке данная операция заменялась парой операций ПОКУПКА-ПРОДАЖА
ПРОЦЕСС: Выбор операции и отчет по результату (технологический)
Описание:
1) Производится выбор операции с ВО и формирование заявки на проведение операции с ВО
2) Осуществляется формирование отчетности по проведенной операции с ВО
Приложение 1. Диаграммы потоков данных
Рис. П.1.1 Верхний уровень модели
Рис. П.1.2 Детализация верхнего уровня модели
Рис. П.1.3. Пассивная деятельность с ценными бумагами
Рис. П.1.4. Активная деятельность с ценными бумагами
Рис. П.1.5. Операции с векселями
Рис П.1.6. Операции с депозитными сертификатами
Рис. П.1.7. Операции с Государственными краткосрочными облигациями
Рис. П.1.8. Операции с казначейскими обязательствами
Рис. П.1.9. Операции с валютными облигациями
Приложение 2. Концептуальные основы CASE - технологии
Эволюция CASE - средств
С самого начала CASE - технологии развивались за счет автоматизации и интеграции поддерживающих средств. Таким образом CASE - технологии не могут считаться самостоятельными методологиями, они только делают более эффективными пути их применения. CASE - не революция в программотехнике современные CASE -
средства являются естественным продолжением эволюции всей отрасли средств разработки ПО. Традиционно выделают шесть периодов, качественно отличающихся применяемой техникой и методами разработки ПО, которые характеризуются использованием в качестве инструментальных следующих средств;
ассемблеров, дампов памяти, анализаторов;
компиляторов, и интерпретаторов, трассировщиков;
символических отладчиков, пакетов программ;
систем анализа и управления исходными текстами;
CASE -средств анализа требований, проектирования спецификаций и структуры, редактирования интерфейсов (первая генерация 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 |
| Основные усилия - на кодирование и тестирование | Основные усилия - на анализ и проектирование | |
| “Бумажные” спецификации | Быстрое итеративное Прототипирование | |
| Ручное кодирование | Автоматическая кодогенерация | |
| Ручное документирование | Автоматическая генерация документации | |
| Тестирование кодов | Автоматический контроль проекта | |
| Сопровождение кодов | Сопровождение спецификаций проектирования |
Состав, структура и функциональные особенности 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) позволяет строить более сложные модели, при этом прототип позволяет промоделировать основные функции системы, но не способен контролировать ее ожидаемое поведение. Исполняемые языки спецификаций
преобразуют процесс разработки в следующий итеративный процесс: спецификации определяются и выполняются затем производится переопределение или корректировка
Созданные таким образом прототипы позволяют определять, является ли проектируемая система полной и корректной.
Поддержка структурных методологий осуществляется за счет средств их автоматизации на следующих двух уровнях:
подготовка документации, графическая поддержка построения структурных диаграмм различных типов, продуцирование спецификаций для детализации функциональных блоков в диаграммах и структур данных на нижних уровнях;
корректное использование шагов обработки в методологиях.
Кодогенерация осуществляется на основе репозитария позволяет автоматически построить до 80-90% объектных кодов или текстов программ на языках высокого уровня. При этом различными CASE - пакетами поддерживаются практически все известные языки программирования, однако наиболее часто в качестве целевых языков выступают COBOL, C и ADA. Средства кодогенерации по отношению к полноте целевого продукта разделяются на средства генерации каркаса ПО и средства генерации полного продукта. В первом случае автоматически строится откомментированная логика (потоки управления) ПО, а также коды для БД, файлов, экранов, отчетов и т.п., остальные фрагменты ПО кодируются вручную. Во втором случае из проектных спецификаций генерируется полная документированная программа, включая выполняемый код, пользовательскую и программную документацию, наборы тестов и т.д. Все эти компоненты полной программы связываются в единый объект, хранящийся в депозитарии для облегчения доступа и сопровождения.
Приложение 3. Ценные бумаги
П.3.1. Классификация ценных бумаг
Ценная бумага представляет собой документ, который выражает связанные с ним имущественные и неимущественные права, может самостоятельно обращаться на рынке и быть объектом купли-продажи и других сделок, служит источником получения регулярного или разового дохода. Таким образом, ценные бумаги выступают разновидностью денежного капитала, движение которого опосредует последующее распределение материальных ценностей.
В прошлом ценные бумаги существовали исключительно в физически осязаемой, бумажной форме и печатались типографическим способом на специальных бумажных бланках. Ценные бумаги, как правило, изготовляются с достаточно высокой степенью защищенности от возможных подделок. В последнее время в связи со значительным увеличением оборота ценных бумаг многие из них стали оформляться в виде записей в книгах учета, а также на счетах, ведущихся на различных носителях информации, то есть перешли в физически неосязаемую (безбумажную) форму. Поэтому на рынке ценных бумаг выпускаются, обращаются и погашаются как собственно ценные бумаги,, так и их заменители. Объекты сделок на рынке ценных бумаг также называют инструментами рынка ценных бумаг, фондами (в значении денежные фонды) или фондовыми ценностями.
В случае, если ценные бумаги не существуют в физически осязаемой форме или если их бумажные бланки помещаются в специальные хранилища, владельцу ценной бумаги выдается документ, удостоверяющий его право собственности на ту или иную фондовую ценность. Этот документ называется сертификатом ценной бумаги. Сертификаты ценных бумаг на предъявителя могут выпускаться для замещения собой несколько однородных ценных бумаг (подобно денежным купюрам различного достоинства). В последнем случае сертификат не обязательно содержит информацию о владельце фондовой ценности.
Экономическую суть и рыночную форму каждой ценной бумаги можно одновременно рассматривать с разных точек зрения, в связи с чем каждая ценная бумага обладает целым набором характеристик. Это предопределяет и возможность классификации ценных бумаг по разным признакам, что обычно диктуется практическими потребностями.
Возможно прежде всего разделить все ценные бумаги на две большие группы: денежные и капитальные или фондовые ценные бумаги, то есть те, которые обращаются на рынке капиталов, который называют также финансовым, или фондовым, рынком.
Ценные бумаги денежного рынка - это коммерческие и финансовые векселя сроком до 1 года, банковские акцепты, коммерческие бумаги, имитируемые частными предприятиями и корпорациями на срок от 10 до 180 дней, краткосрочные сберегательные боны и депозитные сертификаты, имитируемые банками, казначейские векселя, имитируемые от правительства сроком 3, 6, 9 и 12 месяцев. Это очень пестрая группа ценных бумаг с точки зрения их конкретного назначения, формы, эмитентов и держателей. Общей чертой всех этих юридических элементов является их назначение оформлять необеспеченное заимствование денег на сравнительно короткие сроки, в связи с чем их называют
долговыми ценными бумагами. Денежными эти бумаги называют по разным причинам: они широко используются в рамках кредитно-банковской сферы, средства, полученные от эмиссии этих ценных бумаг, в дальнейшем используются преимущественно как традиционные деньги для производства текущих платежей или погашения долгов; некоторые из этих ценных бумаг используются в качестве заменителей наличных денег как средство платежа: например, коммерческие векселя используют для оплаты товара, а правительственными казначейскими векселями можно заплатить федеральные налоги.
Денежные обязательства, выражаемые денежными ценными бумагами, в большинстве своем укладываются в срок до 1 года. Доход от покупки и держания таких ценных бумаг носит разовый характер. Форма их не предусматривает специальных атрибутов, являющихся основанием для получения дохода, например, процентных купонов. В процессе рыночной сделки доход реализуется та разница между продажной (более низкой) и нарицательной ценой денежного документа.