Работа коммерческих банков с ценными бумагами - (курсовая)

Примечание: На момент построения модели данная операция не проводилась

    ПРОЦЕСС: Залог

Примечание: На момент построения модели данная операция не проводилась

    ПРОЦЕСС: Договор РЕПО

Примечание: В банке данная операция заменялась парой операций ПОКУПКА-ПРОДАЖА

ПРОЦЕСС: Выбор операции и отчет по результату (технологический) Описание:

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

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