ВВЕДЕНИЕ
Введение в CASE - технологии.
Введение в предмет деятельности.
1. Используемая нотация
2. Представление модели
3. Спецификации процессов деятельности с ценными бумагами
3.1. Пассивная деятельность с ценными бумагами
3.1.1.Операции с векселями
3.1.2.Операции с депозитными сертификатами
3.2. Активная деятельность с ценными бумагами
3.2.1. Операции с ГКО
3.2.2. Операции с КО
3.2.3. Операции с ВО
Приложение 1. Диаграммы потоков данных
Приложение 2. Концептуальные основы CASE - технологии
Приложение 3. Ценные бумаги
П.3.1. Классификация ценных бумаг
П.3.2. Регулировка рынка ценных бумаг.
ВВЕДЕНИЕ
Лавинообразное расширение областей применения ЭВМ, возрастающая сложность программного обеспечения и повышающиеся к нему требования привели к необходимости индустриализации производства программной продукции, а именно: необходимости применения высокоэффективных технологий создания программного обеспечения. Важное направление в развитии программных технологий составили разработки интегрированных инструментальных систем, базирующихся на концепциях жизненного цикла и управления качеством программной продукции и представляющих собой комплексные технологии, ориентированные на создание сложных программных систем и поддержку их полного жизненного цикла или ряда его основных этапов. Дальнейшее развитие работ в данном направлении привело к созданию ряда концептуально целостных, оснащенных высокоуровневыми средствами проектирования и реализации, доведенных по качеству и легкости тиражирования до уровня программных продуктов технологических систем, которые и получили название CASE - систем или CASE - технологии .
В настоящее время CASE - системы прочно вошли в практику программной индустрии. При этом они используются не только как комплексные технологические конвейеры для производства программных систем, но и как мощный инструмент решения исследовательских и проектных задач, таких как структурный анализ предметной области, спецификация проектов средствами языков программирования четвертого поколения, выпуск проектной документации, тестирование реализаций проектов, планирование и контроль разработок, моделирование деловых приложений с целью решения задач оперативного и стратегического планирования и управления ресурсами и т.п.
В данной курсовой работе мы попытались дать описание одного из основных методов структурного анализа и проектирования программного обеспечения систем обработки информации, наиболее распространенным способом – диаграммами потоков данных. Поскольку большинство понятий системного анализа к нам пришло из за рубежа – дадим основные варианты их определений на английском языке:
* DFD (Data Flow Diagrams) – диаграммы потоков данных. Метод демонстрируется на функциональной модели, рассмотренной в данном курсовом проекте ниже. По сути, он определяет функциональную страту изучаемого объекта.
* ERD (Entinity-Relationship ) – диаграммы “сущность-связь”. Метод широко используется при описании структуры систем и применяется главным образом в теории баз данных. В отечественной литературе он в основном описан как метод диаграмм ER- типа.
* STD (State Transmition Diagrams) – Диаграммы переходов состояний. Используются для описания функционирования рассматриваемой системы во времени. Аналогом этому является метод пространства состояний, с успехом применяемый при моделировании систем.
Основным источником нашего проекта является книга написанная на основе оригинального семестрового курса лекций по CASE - технологиям, подготовленного и читаемого автором в высшей компьютерной школе при НИВЦ. МГУ им. Ломоносова в течение четырех последних лет, которая предназначена прежде всего для аналитиков предметной области, руководителей программных проектов, системных аналитиков, проектировщиков и разработчиков информационных систем и систем реального времени. Сделанный в книге акцент на последовательное рассмотрение наиболее важных аспектов системного структурного анализа делает эту книгу особенно полезной для пользователей, которые выбирают CASE - системы в качестве инструмента для решения прикладных задач, а также для студентов, начинающих постигать основы современных информационных технологий.
Введение в CASE - технологии.
За последнее десятилетие сформировалось новое направление в программотехнике - CASE (Computer - Aided Software/System Engineering). В настоящее время не существует общепринятого определения CASE. Содержание этого понятия обычно определяется перечнем задач, решаемых с помощью CASE, а также совокупностью применяемых методов и средств. Грубо говоря, CASE - технология представляет собой совокупность методологий анализа, проектирования, разработки и сопровождения сложных систем программного обеспечения (ПО), поддержанную комплексом взаимосвязанных средств автоматизации. CASE - это инструментарий для системных аналитиков, разработчиков и программистов, позволяющий автоматизировать процесс проектирования и разработки ПО.
К настоящему моменту дисциплина CASE оформилась в самостоятельное наукоемкое направление в программотехнике, повлекшее за собой образование мощной САSE - индустрии, объединившей сотни фирм и компаний различной ориентации. Среди них выделяются компании-разработчики средств анализа и проектирования ПО с широкой сетью дистрибьюторских и дилерских фирм; фирмы-разработчики специальных средств с ориентацией на узкие предметные области или на отдельные этапы жизненного цикла ПО; обучающие фирмы, которые организуют семинары и курсы подготовки специалистов; консалтинговые фирмы, оказывающие практическую помощь при использовании CASE- пакетов для разработки конкретных приложений; фирмы, специализирующиеся на выпуске периодических журналов и бюллетеней по CASE. Основными покупателями CASE-пакетов за рубежом являются военные организации, центры обработки данных и коммерческие фирмы по разработке ПО.
Существует мнение, что CASE является наиболее перспективным направлением в программотехнике. С этим ложно спорить, но то, что CASE - наиболее бурно и интенсивно развиваемое направление , является в настоящее время фактом. Практически ни один серьезный зарубежный программный проект не осуществляется без использования CASE - средств. Известная методология структурного системного анализа SАDТ (точнее ее подмножество IDEF0) принята в качестве стандарта на разработку ПО Министерством обороны США. Более того, среди менеджеров и руководителей компьютерных фирм считается чуть ли не правилом хорошего тона знать основы SADT и при обсуждении каких-либо вопросов нарисовать простейшую диаграмму, поясняющую суть дела.
CASE позволяет не только создавать "правильные" продукты, но и обеспечить "правильный" процесс создания. Основная цель CASE состоит в том, чтобы отделить проектирование ПО от его кодирования и последующих этапов разработки, а также скрыть от разработчиков все детали среды разработки и функционированию. Чем больше деятельности будет вынесено в проектирование не из кодирования , тем лучше.
При использовании CASE - технологий меняются этапы жизненного цикла программной системы, при этом наибольшие изменения касаются этапов анализа и проектирования. В большинстве современных CASE - систем применяются методологии структурного анализа и проектирования, основанные на наглядных диаграммных техниках, при этом для описания модели проектируемой системы используются графы, диаграммы, таблицы и схемы. Такие методологии обеспечивают строгое и наглядное описание проектируемой системы, которое начинается с ее общего обзора и затем детализируйся, приобретая иерархическую структуру со все большим числом уровней.
CASE - технологии успешно применяются для построения практически всех типов систем ПО, однако устойчивое положение они занимают в следующих областях:
1. Обеспечение разработки делового и коммерческого ПО. Широкое применение CASE - технологий обусловлено массовостью этой прикладной области, в которой CASE применяется не только для разработки ПО, но и два создания моделей систем, помогающих коммерческим структурам решать задачи стратегического планирования, управления финансами, определения политики фирм, обучения персонала и т.д. (это направление получило свое собственное название - бизнес-анализ),
2. Разработка системного и управляющего ПО. Активное применение CASE - технологий связано с большой сложностью данной проблематики и со стремлением повысить эффективность работ.
CASE - не революция в программотехнике, а результат естественного эволюционного развития всей отрасли средств, называемых ранее инструментальными или технологическими. Однако это и не Confuse Array of Software that does Evrything существует ряд признаков и свойств, наличие которых позволяет классифицировать некоторый продукт как CASE - средство. Одним из ключевых признаков является поддержка методологий структурного системного анализа и проектирования.
С самого начала CASE - технологии развивались с целью преодоления ограничений при использовании структурных методологий проектирования 60-70-х годов (сложности понимания, большой трудоемкости и стоимости использования, трудности внесения изменений в проектные спецификации и т.д.) за счет их автоматизации и интеграции поддерживающих средств. Таким образом, CASE -технологии не могут считаться самостоятельными методологиями, они только развивают структурные методологии и делают более эффективным их применение за счет автоматизации.
Помимо автоматизации структурных методологий и, как следствие, возможности применения современных методов системной и программной инженерии, CASE обладают следующими основными достоинствами:
* улучшают качество создаваемого ПО за счет средств автоматического контроля (прежде всего, контроля проекта),
* позволяют за короткое время создавать прототип будущей системы, что позволяет на ранних этапах оценить ожидаемый результат, · ускоряют процесс проектирования и разработки;
* освобождают разработчика от рутинной работы, позволяя ему целиком сосредоточиться на творческой части разработки;
* поддерживают развитие и сопровождение разработки;
* поддерживают технологии повторного использования компонент разработки.
Большинство CASE - средств основано на парадигме методология/метод/нотация/средство . Методология определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы и их последовательность, а также правила распределения и назначения методов. Метод - это систематическая процедура или техника генерации описаний компонентов ПО (например, проектирование потоков и структур данных). Нотации предназначены для описания структуры системы, элементов данных, этапов обработки и включают графы, диаграммы, таблицы, блок-схемы, формальные и естественные языки. Средства - инструментарий для поддержки и усиления методов. Эти инструменты поддерживают работу пользователей при создании и редактировании графического проекта в интерактивном режиме, они способствуют организации проекта в виде иерархии уровней абстракции, выполняют проверки соответствия компонентов.
В приложении 2 содержатся концептуальные основы CASE - технологии.
Введение в предмет деятельности.
Финансовое обеспечение декларированного перехода нашей экономики в фазу стабильного роста является важнейшей проблемой текущего момента и обозримого будущего. Очевидно, что создание фондового рынка является единственной альтернативой существовавшему еще недавно, а теперь существенно подорванному дефицитом централизованных средств, волевому распределению финансовых ресурсов. Развитый внутренний финансовый рынок мог бы существенно облегчить задачу интеграции в мировой финансовый рынок и создать канал для инвестирования иностранного капитала в нашу экономику через размещение наших ценных бумаг.
Организация крупномасштабного рынка для обращающихся ценных бумаг, очевидно, является сложным и длительным процессом. Массовому обращению акций должно предшествовать массовое создание корпоративных предприятий. Этот процесс идет с большим трудом. И сегодня мы стоим перед фактом , что фондовый рынок функционирует на 10 %. Причем эти самые 10 % , являясь только частью структуры фондового рынка, по сути растянуты на 100%, и наш фондовый рынок представляет из себя исключительно спекулятивный рынок.
Существующие в развитых странах финансовые рынки опираются на обширные сбережения частных лиц. Общая бедность нашего населения и нехватка свободных сбережений - объективное препятствие на пути развития широкого финансового рынка. Население психологически не подготовлено к восприятию вложения своих средств в долговые обязательства неизвестных ему новых организаций. Кроме того горький опыт некоторых финансовых пирамид, сделал свое черное дело, и существует некоторая категория населения которая видит в финансовом рынке исключительно отрицательные черты.
Не малое давление на долгосрочные инвестиции оказывает инфляция. Сильная инфляция в странах Запада всегда была разрушителем финансовых рынков, у нас она препятствует их стихийному развитию.
Для функционирования рынка требуется возникновение уверенности в возможности вверить свои сбережения посредническим институтам. Это доверие общества должно воспитываться постепенно на положительных примерах, кроме того можно отметить, что в недавние социалистические времена уже существовал развитый государственный фондовый рынок, предназначенный для привлечения частных средств граждан в развитие народного хозяйства. Этот рынок существовал в форме государственных облигаций вещевой и денежной лотереи. Так как зарубежный опыт функционирования фондового рынка, представляет из себя несомненный интерес мы попытаемся представить возможную модель технологии деятельности с ценными бумагами для абстрактного коммерческого банка, находящегося на территории РФ. Отметим, что банк работает лишь с государственными ценными бумагами (ГКО, КО, ВО), а также осуществляет эмиссию своих собственных векселей и депозитных сертификатов (ДС).
Модель не является проектом соответствующей автоматизированной информационной системы (АИС) – она фиксирует применяемую в банке технологию работы с ценными бумагами. Исследование модели позволяет выявить ряд недостатков в применяемой технологии, предложить варианты ее усовершенствования, а также сформулировать основные требования к функциональной и информационной частям возможной проектируемой АИС.
1. Используемая нотация
Перед тем как перейти к рассмотрению моделируемого объекта представим составные элементы языка описания. В его основе лежит методология структурного системного анализа Гейна-Сарсона. На верхнем уровне система представлена DFD диаграммой. Итак составными частями диаграмм являются следующие элементы:
Внешняя сущность. Обычно это логические классы предметов или физических лиц, представляющие собой источник или приемник информации, например физические и юридические лица, банки, биржи, различные фирмы и т.д. Внешняя сущность обозначается квадратом, бросающим тень на диаграмму (см рис. 1.1).
Рис. 1.1. Изображение внешней сущности на диаграммах.
Процесс. Логически процесс является неким устройством, принимающим входные потоки и преобразующим их в выходные в соответствии со своей внутренней логикой. Обозначается он прямоугольником с закругленными углами, разделенными на три поля (см рис. 1.2). Каждому процессу дается имя, отражающее его функцию. Для идентификации процессы в пределах одной диаграммы уникально пронумерованы.
Рис. 1.2. Условное обозначение процесса.
Накопитель данных. Представляет собой некое устройство для хранения информации, куда ее можно поместить и через некоторое время изъять. Обозначается он двумя горизонтальными параллельными линиями, замкнутыми из одного края – рис. 1.3. Каждый накопитель данных идентифицируется для ссылки буквами “БД” и числом в квадрате с левой стороны.
Рис. 1.3. Условное обозначение накопителя данных.
Информационный канал. Это среда передачи информации, куда данные поступают из различных источников, которые не входят в рассмотрение в данную систему. Условное обозначение канала содержит идентифицирующую ссылку (буквы “ИК” и номер) – см рис. 1.4.
Рис. 1.4. Условное обозначение накопителя информационный канала.
Информационный поток. Логически информационный поток – это некоторое соединение, по которому информация от источника передается приемнику. Обозначение см рис. 1.5.
Рис. 1.5. Условные обозначения информационных потоков.
2. Представление модели
Функциональная модель деятельности с ценными бумагами в коммерческом банке, приведена на рис. П.1.1–П.1.9.
На рис. П.1.1 изображен фрагмент диаграммы потоков данных с процессом Ценными бумаги и внешними объектами, с которыми данный процесс взаимодействует (эти взаимодействия обозначены с помощью входных и выходных информационных потоков). Роль внешних для данного информационного процесса объектов играют внешние сущности: ЮЛ (Юридическое лицо), ФЛ (Физическое лицо), Уполномоченный депозитарий, Консалтинговая фирма, ММВБ, информационный (технологический) канал поступления в банк из различных источников котировок ценных бумаг а также процессы, моделирующие внутреннюю бухгалтерскую, сводную бухгалтерскую, операционную, кредитную и валютную деятельность банка.
На рис. П.1.2 изображена диаграмма потоков данных второго уровня, детализирующая процесс Ценные бумаги содержащая процессы Анализ рынка ЦБ, Пассивная деятельность с ЦБ, Активная деятельность с ЦБ, Связь с внутренней бухгалтерией (технологический процесс) и Формирование поправочных операции.
Процессы 1, 4, 5 рис. П.1.2 являются элементарными, и их логика описывается миниспецификациями, т.е. естественным языком (см далее пункт 3). Диаграмма, детализирующая процессы 2 и 3 того же рисунка, приведены далее на рис. П.1.3 и П.1.4, соответственно. Диаграммы, детализирующие процессы более нижнего уровня, приведены на рис. П.1.5-П.1.9.
3. Спецификации процессов деятельности с ценными бумагами
В зависимости от сложности и необходимости, при детализации процессов верхнего уровня на нижнем, применяется либо их спецификация диаграммами DFD типа, либо описание естественными языковыми средствами. В качестве альтернативы последним можно было бы предложить и другие методы – например, структурированный естественный язык или визуальный язык спецификаций; однако мы ограничились естественным, т.к. на наш взгляд он наилучшим образом (более понятно) описывает происходящие процессы.
Процесс: Анализ рынка ценных бумаг.
На рис. П.1.2 обозначен под номером 1.
Описание:
1) Анализ процентных ставок по векселям и депозитным сертификатам других банков и формирование процентных ставок своего банка
2) Формирование отчетности по проданным и/или погашенным депозитным сертификатам и выданным и/или оплаченным векселям.
3) Анализ доходности ЦБ различных типов. Принятие решений по операциям с ЦБ и формирование заявок на ресурсы.
4) Формирование отчетности по проведенным операциям с ЦБ.
Процесс: Пассивная деятельность с ЦБ
Детализация процесса (под номером 2 рис. П.1.2) в диаграмме потоков данных рис. П.1.3 и в пункте 3.1.
Процесс: Активная деятельность с ЦБ
Детализация процесса (номер 3 на рис. П.1.2) в диаграмме потоков данных рис. П.1.3 и пункте 3.2.
Процесс: Связь с внутренней бухгалтерией (технологический процесс)
Имеет номер 4 на рис. П.1.2. Здесь осуществляется сбор документов по ценным бумагам для процесса 10 "Внутренняя бухгалтерская деятельность".
Процесс: Формирование поправочных операций
Формирование поправочных операций для процесса 10 рис. П.1.2 “Внутренняя бухгалтерская деятельность” в случае обнаружения ошибок в операциях с ценными бумагами
3.1. Пассивная деятельность с ценными бумагами
Процесс: Операции с векселями
Детализация процесса в диаграмме потоков данных рис. П.1.5 и пункте 3.1.1.
Процесс: Операции с депозитными сертификатами
Детализация процесса в диаграмме потоков данных рис. П.1.6 и пункте 3.1.2.
Процесс: Распределение входов и формирование выходов (технологический)
Описание:
Производится распределение потоков документов по деятельностям с векселями и депозитными сертификатами, а также сбор отчетности по пассивной деятельности
3.1.1.Операции с векселями
ПРОЦЕСС: Выдача
Описание:
1) Оформление договора по векселям и подшивка экземпляра в папку договоров
2) Оформление и выдача сертификата ЦБ
3) Оформление расходно-мемориального ордера по ценному бланку и передача его в документы дня по ЦБ
4) Формирование отчетности по ИД по выданному векселю (сумма, процентная ставка, дата оплаты)
5) Занесение в БД векселей информации по договору (номер векселя, дата выдачи векселя, номер договора, дата заключения договора, процентная ставка, номинал, срок вращения, наименование векселедержателя, банковские реквизиты векселедержателя)
6) Запись в журнал операций
Примечание: Проводки при выдачи векселя
К -199, Д 50 (р/сч) - сумма под вексель
Д - 9959 - учет бланка под вексель
ПРОЦЕСС: Передача
Описание:
1) Регистрация цессии в договоре
2) Регистрация операции в журнале операций
3) Изменение записи в БД векселей (наименование векселедержателя, банковские реквизиты векселедержателя)
ПРОЦЕСС: Залог
Описание:
1) В БД векселей регистрируется информация по залогу (срок залога, наименование кредитора, банковские реквизиты кредитора, размер кредита)
2) Регистрация операции в журнале операций
ПРОЦЕСС: Оплата
Описание:
1) Погашение сертификата ЦБ
2) Передача погашенного сертификата и договора в документы дня по ЦБ
3) Оформление и передача распоряжения в отдел внутрибанковских операций со всеми атрибутами векселя для начисления процентов, налогов и осуществления проводок
Примечание: Проводки при оплате векселя
Д 199, К р/с клиента - номинал векселя
Д 970, К р/с клиента - проценты за вычетом налога
Д 970, К 904 - налог 15% в бюджет
ПРОЦЕСС: Разбор документов и отчетность (технологический процесс)
Производится распределение потоков входных документов по процессам - операциям с векселями, а также сбор и формирование отчетности по операциям
3.1.2.Операции с депозитными сертификатами
ПРОЦЕСС: Продажа
Описание:
1) Оформление договора по ДС и подшивка экземпляра в папку договоров
2) Оформление и выдача сертификата ЦБ
3) Оформление расходно-мемориального ордера по ценному бланку и передача его в документы дня по ЦБ
4) Формирование отчетности по ПД по выданному ДС (сумма, процентная ставка, дата оплаты)
5) Занесение в БД Де информации по договору (номер ДС, дата выдачи ДС, номер договора, дата заключения договора, процентная ставка, номинал, срок обращения, наименование держателя, банковские реквизиты держателя)
6) Запись в журнал операций
Примечание: Проводки при выдачи ДС
Д 9959 - учет бланка под ДС
К 199 Д р/сч - сумма под ДС
ПРОЦЕСС: Залог
Описание:
1) В БД Де регистрируется информация по залогу (срок залога, наименование кредитора, банковские реквизиты кредитора, размер кредита)
2) Регистрация операции в журнале операций
ПРОЦЕСС: Передача
Описание:
1) Регистрация индоссамента в доге воре
2) Регистрация операции в журнале операций
3) Изменение записи в БД Де (наименование держателя банковские реквизиты держателя)
ПРОЦЕСС: Погашение
Описание:
1) Погашение сертификата ЦБ
2) Передача погашенного сертификата и договора в документы дня по ЦБ
3) Оформление и передача распоряжения в отдел внутрибанковских операций со всеми атрибутами ДС для начисления процентов, налогов и осуществления проводок
Примечание: Проводки при Погашении ДС
ДТ-199, КТ - р/с клиента - номинал ДС
ДТ-970, КТ -р/с клиента - проценты за вычетом налога
ДТ-970, КТ -904 - налог 15% в бюджет
3.2. Активная деятельность с ценными бумагами
Процесс представлен на рис. П.1.4.
ПРОЦЕСС: Операции с ГКО
Детализация процесса в диаграмме потоков данных рис. П.1.7 и пункте 3.2.1
ПРОЦЕСС: Операции с КО
Детализация процесса в диаграмме потоков данных П.1.8 и пункте 3.2.2.
ПРОЦЕСС: Операции с ВО
Детализация процесса в диаграмме потоков данных П.1.9 и пункте 3.2.3.
3.2.1. Операции с ГКО
ПРОЦЕСС: Покупка
Описание:
Для каждого выпуска ГКО по каждой операции покупки вносится запись журнал лицевого учета
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)
Если ИТОГО(3)>0 то Д 904
Если ИТОГО(3)
Если ИТОГО(4)>0 то К 960
Если ИТОГО(4)
ИТОГО(7) Д 970, К 904
ИТОГО(8) Д 950, К 904
3.2.2. Операции с КО
Процесс представлен на рис. П.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) Осуществляется формирование отчетности по проведенной операции с ВО
Приложение 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
Анализ
Проектирование
Кодирование
Тестирование
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- средства представляют собой новый тип графически-ориентированных инструментов, восходящих к системе поддержки ЖЦ ПО. Обычно к ним относят любое программное средство, обеспечивающее автоматическую помощь при разработке ПО, его сопровождении или деятельности по управлению проектом, и проявляющее следующие дополнительные черты:
* мощная графика для описания и документирования систем ПО, а также для улучшения интерфейса с пользователем, развивающая творческие возможности специалистов и не отвлекающая их от процесса проектирования на решение второстепенных вопросов;
* интеграция, обеспечивающая легкость передачи данных между средствами и позволяющая управлять всем процессом проектирования и разработки ПО непосредственно через процесс планирования проекта;
* использование компьютерного хранилища ( репозитария )для всей информации о проекте, которая может разделяться между разработчиками и исполнителями как основа для автоматического продуцирования ПО и повторного его использования в будущих системах.
Помимо перечисленных основополагающих принципов графической ориентации, интеграции и локализации