Доработать заказ Ч-16097

Язык моделирования должен включать: модельные элементы - фундаментальное моделирование понятий и семантики; нотацию - визуальное представление модельных элементов; руководящие указания характерные способы использования в практических применениях.
В связи с возрастающей сложностью разрабатываемых систем визуализация и моделирование становятся все более существенными. UML представляет собой хорошо определенный и широко признанный ответ на эту потребность. Это - язык визуального моделирования для разработки объектно-ориентированных и компонентных систем. UML воплотил в себе следующие цели:
предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий им разрабатывать осмысленные модели и обмениваться ими; предусмотреть механизмы расширяемости и специализации для расширения базовых концепций;
обеспечить независимость от конкретных языков программирования и процессов разработки;
обеспечить формальную основу для понимания этого языка моделирования;
стимулировать рост рынка объектно-ориентированных инструментальных средств;
предусмотреть поддержку таких высокоуровневых концепций разработки, как сотрудничество, среды, образцы и компоненты;
интегрировать лучший практический опыт.
Как уже отмечалось, UML предназначен для спецификации, конструирования, визуализации и документирования артефактов сложных систем программного обеспечения. Во-первых, важно отметить, что этот язык является сплавом концепций методов Буча, ОМТ и OOSE. В результате такого подхода был создан единый, общий и широко используемый язык моделирования для пользователей этих и других методов.
Во-вторых, UML дает возможность охватить практически все то, что может быть сделано с помощью существующих методов. Так, например, авторы UML принимали во внимание моделирование параллельных распределенных систем с тем, чтобы обеспечить возможность адекватного использования UML в этой области.
В-третьих, в центре внимания разработчиков UML было создание стандартного языка, а не стандартного процесса моделирования. Хотя UML должен быть применимым в контексте любого процесса, опыт показал, что для различных организаций и областей приложений требуются различные процессы. (Например, процесс разработки программного обеспечения сложных систем реального времени, от которых зависят жизни людей, значительно отличается от разработки программного обеспечения для других целей.) Поэтому усилия были, прежде всего сосредоточены на общей метамодели (унифицирующей семантику), а во-вторых, на общей нотации (обеспечивающей воспринимаемое человеком воплощение этой семантики). Авторы UML поддерживают процесс разработки, который управляется случаями использования (use-case), является архитектуро-центрическим, итерационным и пошаговым.
Хотя UML предназначен для того, чтобы упростить и стандартизировать моделирование, он отнюдь не является всеобъемлющим языком. Благодаря этому достигается его гибкость, которая позволяет использовать язык для проектирования разнообразных систем в широком спектре отраслей промышленности.
UML - это язык визуального моделирования. Он не предназначен для визуального программирования в смысле наличия всей необходимой визуальной и семантической поддержки, позволяющей ему заменять языки программирования. UML служит для визуализации, спецификации, конструирования и документирования артефактов сложных систем программного обеспечения, но он в действительности позволяет вырисовывать линии по мере того, как вы продвигаетесь к коду. Для UML разработано строгое отображение в семейство объектно-ориентированных языков.
Таким образом, язык UML дает руки специалиста гибкий и мощный инструмент, позволяющий визуализировать разрабатываемую проблему и стандартизировать процесс реализации поставленной задачи.
Диаграммы UML
UML 2.0 включает набор диаграмм (рис. 7), используемых для разработки различных моделей программных и бизнес систем. Как видно из рис. 7 диаграммы подразделяются на две группы: структурные диаграммы и процессные диаграммы. К структурным диаграммам относятся:
диаграмма классов;
диаграмма объектов;
составная структурная диаграмма;
диаграмма компонент;
диаграмма размещения;
диаграмма пакетов.
К процессным диаграммам относятся:
диаграммы взаимодействия;
диаграммы деятельности;
диаграммы функций;
диаграммы состояний.
В свою очередь диаграммы взаимодействия подразделяются на:
диаграммы последовательностей;
обзорные диаграммы потоков управления;
коммуникационные диаграммы;
временнее диаграммы.
На различных этапах создания программной системы могут использоваться диаграммы UML для создания различных моделей.

Под моделью понимается представление чего-либо с некоторой точки зрения, например программной или бизнес системы. Модель может принимать различные формы, включающие в себя текст, рисунки. Модель имеет семантику и реализуется в определенной нотации. Нотация представляет собой совокупность графических элементов, которые используются в моделях. Она является синтаксисом данного языка моделирования.
Язык UML не содержит понятие процесса разработки программной системы. Методы моделирования не имеют смысла без знания того, как они могут быть использованы процессом разработки. С языком UML можно использовать любой процесс. В работе рассматривается разработка моделей с использованием UML в соответствие с рациональным унифицированный процессом (Rational Unified Process - RUP).
В табл. 1. представлены этапы работ по RUP, модели, разрабатываемые на каждом этапе, и используемые диаграммы UML.
Этапы работ по RUP, модели и диаграммы UML в Rational Rose
Таблица № 1
Этап работ по RUP Модели Диаграммы UML Примечания Бизнес моделирование (Business Modeling) Бизнес процессы (business use case model) Use case diagram Модель отображает процессы, подлежащие автоматизации, связи между процессами, цели, которые они поддерживают, субъектов и объектов, взаимодействующих с бизнес процессами и являющихся внешними по отношению к ним, например клиентами и партнерами. Модель используется для определения целей системы и разбиения системы на подсистемы. Каждому бизнес процессу ставится в соответствие подсистема Описание бизнес
процессов
(business object
model RUP 2002
или business analysis model RUP 2003) Activity
diagram Модель отображает поток работ
по бизнес процессу. Модель
используется для определения
модулей подсистем и их
функций. Описание бизнес сущностей
(business object model RUP 2002
или business analysis model
RUP 2003) Class diagram,
Use case
diagram Модель отображает сущности
реального мира (business entity),
их атрибуты. Модель
используется для
формирования альбомов
входных и выходных форм
системы, проектирования пользовательского интерфейса, баз данных, классов, реализующих функции Описание
состояния бизнес
сущности
(business object
model RUP 2002
или business
analysis model RUP 2003) Activity
diagram,
Statechart
diagram. Модель отображает состояния
сущности реального мира.
Модель используется для
определения скрытых
атрибутов бизнес сущностей и
при определении функций
системы. Роли и автоматизируемые виды деятельности (business object model RUP 2002 или business analysis model RUP 2003) Class diagram,
Use case
diagram Модель отображает роли и их
автоматизируемые виды
деятельности. Модель
используется при определении
функций системы Структура предприятия (business object model RUP 2002 или business analysis model RUP 2003) Class diagram,
Use case
diagram Модель отображает структуру
автоматизируемого
предприятия. Модель
используется для определения
функций системы Бизнес правила Class diagram,
Activity
diagram Модель отображает ограничения, накладываемые на бизнес процессы. Модель используется для определения правил системы Определение требований (Requirements) Функции системы (Use case model) Use case diagram Модель отображает функции системы Экранные формы Class diagram Модель отображает экранные формы системы Сценарии работы пользователя с системой Activity diagram Модель отображает сценарии работы пользователя с системой Анализ и проектирование (Analysis & Design)
Модель размещения (Deployment model) Deployment diagram Модель отображает технические средства и, размещенные на них, программные средства системы и прочие программные средства Модель данных (Data modal) Class diagram Модель отображает логическую и физическую структуру данных. Модель анализа (Analysis modal) Class diagram Модель описывает реализацию требований и служит абстракцией для модели проектирования Модель проектирования (Design modal) Class diagram, Sequence diagram, Activity diagram, Collaboration diagram Модель описывает реализацию требований и служит абстракцией модели реализации и исходного кода Реализация (Implementation) Модель реализации (Implementation model) Component diagram Модель отображает подсистемы и компоненты, из которых они состоят Тестирование (Test) Модель тестирования (Test suite) Class diagram,
Activity
diagram Модель отображает контрольные примеры, тесты, последовательность выполнения тестов, ожидаемые и полученные результаты тестов Размещение
(Deployment) Модель
размещения
(Deployment
model) Deployment
diagram Модель отображает
технические средства и
размещенные на них
программные средства системы и прочие программные средства Цели бизнес-моделирования
Целью бизнес-моделирования является:
понимание бизнес-процессов автоматизации организации заказчиками, конечными пользователями и разработчиками автоматизированных систем;
реорганизация бизнес-процессов организации с целью их усовершенствования;
использование описания бизнес-процессов для стандартизации в соответствии с международными стандартами;
определение требований к автоматизируемой системе, поддерживающей работу автоматизируемой организации.
Разработка требований
На основе анализа модели Марковица и ее практического применения, для разработки формализованного описания была использования методика бизнес - моделирования RUP (Rational Unified Process). Было проведено системное обследование предметной области и выделены бизнес процессы:
анализ рынка ценных бумаг;
первоначальный подбор ценных бумаг;
расчет рекомендуемой к покупке доли ценных бумаг в портфеле;
Расчет количества ценных бумаг на основе рассчитанных значение рекомендуемой доли.
Средствами Enterp. Architect было выполнено полное моделированияе ИС
Модель цели системы
Целью модели «Цели системы» является отображение требуемых значений технических, технологических, производственно-экономических или других показателей объекта автоматизации, которые должны быть достигнуты в результате создания ИС.

Рис. 1. Диаграмма цели системы
Модель смежные системы.
Целью разработки модели «Смежные системы» является отображение состава смежных систем, с которыми будет взаимодействовать ИС.

Рис. 2. Диаграмма смежные системы
Смежной системой для ИС это котировки акций биржи РТС размещаемые на сайте агентства РБК.
Пользователи системы
Целью разработки модели «Пользователи системы» является отображение пользователей системы, документирования режимов их работы, квалификации и прочих их характеристик, оказывающих влияние на создание и внедрение системы.

Рис. 3. Диаграмма пользователи системы
Диаграмма границы системы
Целью разработки модели «Границы системы» является отображение системы и взаимодействующих с ней смежных систем.

Рис. 4. Границы системы
Диаграмма схема функциональной структуры
Целью разработки модели «Схема функциональной структуры» является отображение функциональных требований к системе.

Рис. 5. Схема функциональной структуры

Модели автоматизируемых функций
Целью разработки модели «Связи между системами» является отображение способов и средств связи для информационного обмена между частями системами.Целью разработки модели автоматизируемой функции является отображение последовательности выполнения действий системы и пользователя.


Рис. 6. Диаграмма функции подбор ценных бумаг в портфель

Рис. 7. Диаграмма функции расчет долей



Рис. 8. Диаграмма функции расчет количества акций.

5. Разработка алгоритма и программы решения задачи портфельного инвестирования методом множителей Лагранжа
Разработка информационной системы,
Даталогическая модель базы данных ИС
Даталогическая модель информационной системы выполнена в приложении enterprise architect (рис. 10), это всесторонний набор UML инструментов для анализа и дизайна, охватывающий разработку программного обеспечения через стадии анализа, модели дизайна, испытания и обслуживание. Даталогическая модель построена на основе ER – диаграммы, и содержит реализацию таблиц БД в терминах конкретной СУБД. В качестве СУБД для информационной системы выбрана Microsoft Office Access 2007, она проста в реализации и идеально подходит для нашего небольшого однопользовательского приложения. Таблицы Акции и Котировки акций связаны между собой по полю TICKER тип связи один ко многим, т.к в таблице Котировки акций хранится история значения цены на каждый день. Между таблицами Котировки акций и портфель акций связь многие к одному, т.к. портфель может состоять только из одной акции каждого типа. Эта связь обеспечивает невозможность выбора акций в портфель, по которым нет сведений о котировках. Описание таблиц БД и типы данных полей в таблицах 2-4.
Таблица базы данных Акций
Таблица №2
Наименование поля Тип данных Комментарий № Counter Ключевое поле. СУБД производит автоинкремент этого поля при вводе новой записи. Эмитент Текст Название эмитента TICKER Текст Код акции в системе РТС
Таблица базы данных Котировки акций
Таблица № 3
Наименование поля Тип данных Комментарий Код Counter Ключевое поле. СУБД производит автоинкремент этого поля при вводе новой записи. TICKER Текст Код акции в системе РТС DATEK Long Integer Дата представленная в виде числа. CLOSE Cyrrency Цена акции на соответствующую дату

Таблица базы данных Портфель акций
Таблица № 4
Наименование поля Тип данных Комментарий TICKER Текст Код акции в системе РТС РекомендуемаяДоля Double Вычисленная доля акций в оптимальном портфеле. Количество Long Integer Вычисленное количество акций в оптимальном портфеле



Блок–схема процедуры «РасчетДолей»













































Блок–схема расчетная функция «РасчетДоли»





























Блок–схема расчетная функция «РасчетКоличестваАкций»




























5.2 Экранные формы приложения
На рисунке 11 представлена главная экранная форма приложения. Экранные формы используются для интерактивного взаимодействия с пользователем и вывода отчетов о результатах работы программы. Главная форма “Портфель акций и расчеты”– это основная форма программы все другие формы являются подчиненными главной форме. В главной форме отображается сформированный пользователем портфель и его основные характеристики. На главной форме пользователь выбирает акций эмитентов. Также на главной форме пользователь задает период анализа, сумму имеющихся у него средств и желаемую доходность.

Глава 6 Разработка тестового примера с использованием данных торгов «голубых фишек»
База данных программы содержит результаты торгов акциями за весь периоды проведения торгов. Для проверки корректности ее работы необходимо выбрать на акциях каких эмитентов будет производится тестирование.



Эти инструменты выбираются инвестором из личных предпочтений, основанного, например, на графике риск-доходность. После этого следует установить параметры портфеля желаемую доходность и период, за который эту доходность инвестор ожидает получить, а также временной интервал, статистику по которому программа возьмет за основу.
Поскольку теоретически полученное соотношение на практике достичь достаточно трудно, то дальше пользователю предоставляется возможность задать сумму, которую он готов инвестировать в ценные бумаги и программа рассчитает портфель уже в количестве акций, который необходимо приобрести.
На этой форме пользователь имеет возможность дополнительно отредактировать количество акций, причем в нижней части формы будет отражен риск и доходность сформированного таким образом портфеля. Так же, для сравнения, здесь приведены расчетные значения риск/доходность.

Для проверки корректности работы программы был создан лист Excel, который вычисляет тот же портфель что и созданное приложение результат вычислений изображен на рисунке 13. Результаты совпадают соответственно программный код приложения корректен.

.
Рис. 13. Лист Excel



Заключение
Недостаток метода формирования портфеля Марковица, из-за которого проблематично было применять эту методику на практике. Это большое количество расчетов, которое необходимо выполнять, следуя этой методике. А из-за постоянно меняющейся, рыночной ситуации эти вычисления нужно часто повторять, чтобы актуализировать свойства портфеля и принимать решение об изменении его качественного и количественного состава.
Разработанная многоуровневая информационная система решает данную проблему. Она позволяет на основе аналитической обработки данных, оперативно формировать оптимальный инвестиционный портфель ценных бумаг в условиях различных финансовых возможностей инвестора и с различными сочетаниями доходности и риска.

Список литературы
Евстигнеев В.Р. Портфельные инвестиции в России: выбор стратегии. – М.: Эдиториал УРСС, 2002
Зангвилл У.И. Нелинейное программирование. Единый подход. - М.: Советское Радио, 1973
Касимов Ю.Ф. Основы теории оптимального портфеля ценных бумаг. –М.: Информационно-издательский дом «Филин», 1998.
В.В. Кириллов Основы проектирования реляционных баз данных Учебное пособие
Крянев А.В. Основы финансового анализа и портфельного инвестирования в рыночной экономике. – М.: МИФИ, 2000.
Кюнци В.Ф., Креле М.С. Нелинейное программирование, - М.: Советское радио, 1961.
Муртаф Б. Современное линейное программирование. - М.: Мир, 1984.
Нурминский Е.А., Ащепков Л.Т., Трифонов Е.В. Математические основы теории финансовых рынков. –Владивосток.: Дальневост. Ун-та, 2000.
Пропой А.И., Ядыкин А.Б. Параметрическое квадратичное и линейное программирование. - Автоматика и телемеханика, 1978.
Хедли Дж. Нелинейное и динамическое программирование. - М.: Мир, 1967.
















Приложение А
Требования к информационной системе


введение
Общая структура требований, функций, экранных форм и пользователей изображена на рисунке 1


Рис. 1. Модель описания требования














Общие сведения
Таблица № 1
Название требования Подбор ценных бумаг в портфель Назначение Выбор ценных бумаг составляющих портфель Приоритет требования Высокий Причина возникновения требования Требование заказчика Пользователь Инвестор Источник данных Таблица котировок ценных бумаг
Таблица № 2
Название требования Расчет долей Назначение На основании статистики котировки акций, рассчитать какую долю акций приобрести, чтобы портфель был оптимальным Приоритет требования Высокий Причина возникновения требования Требование заказчика Пользователь Инвестор Источник данных Таблица котировок ценных бумаг
Таблица № 3
Название требования Расчет количества ценных бумаг Назначение На основании уже рассчитанной доли ценных бумаг и суммы имеющейся у инвестора, рассчитать количество акций которые необходимо приобрести Приоритет требования Высокий Причина возникновения требования Требование заказчика Пользователь Инвестор Источник данных Таблица котировок ценных бумаг
Описание требований
Требование «Подбор ценных бумаг в портфель» реализуется с помощью одноименной функции системы. Требование «Расчет долей выбранных акций» реализуется с помощью функций «РассчетДолей». А требование «Расчет количества ценных бумаг» реализуется с помощью функции «РасчетКоличестваАкций»
Описание функции «Подбор ценных бумаг в портфель» представлено на
Рисунке 2.

Рисунок 2. Модель требования «Подбор ценных бумаг в портфель»











Описание требования «Расчет долей выбранных акций» представлено на рисунке 3.
это требование реализовано с помощью двух функций системы «РасчетДолей» и «Рассчет доли»

Рисунок 3. Модель требования «Расчет долей выбранных акций»



Описание требования «Расчет количества ценных бумаг» представлено на рисунке 4.


Рисунок. 4. Модель требования «Расчет количества ценных бумаг»
























Состав экранных форм

Рисунок 5. Состав экранных форм, реализующих требование

Перечень экранных форм, используемых для реализации требования:
№ Название экранной формы Назначение Состав портфеля Просмотр списка записей, вызов операций по добавлению, редактированию, удалению, проверке, авторизации данных Описание экранных форм

Описание экранных форм
О – обязательный атрибут
Н – необязательный атрибут


№ Элемент Тип элемента О/Н Значение по умолчанию Тип данных Правило формирования Источник Дата начала: Элемент для ввода данных О null дата Дата окончания: Элемент для ввода данных О null дата Сумма инвестирования: Элемент для ввода данных О null число Количество периодов: Элемент для ввода данных О null число Ожидаемая доходность: Элемент для ввода данных О null число Расчет доли вложений кнопка Расчет количества акций кнопка ОК кнопка кнопка Список акций включает поля Табличная форма О таблицаБД «Котировки акций» TICKER РекомендуемаяДоля Количество

Описание печатного документа
Печатные формы в ИС отсутствуют
Описание импортируемых/экспортируемых данных
В ИС отсутствуют ипортируемые / экспортируемые данные

Нефункциональные требования, связанные с функциональным требованием
В ИС отсутствуют
Связи с другими функциональными требованиями
В ИС отсутствуют
Правила и ограничения
В ИС отсутствуют

Перечень терминов
Термин Определение Пользователь программы или системы Лицо, участвующее в функционировании ИС или использующее результаты ее функционирования Требование Условия или возможности, которым должна удовлетворять система. Характеристики ПО, необходимые пользователю для удовлетворения своих потребностей или достижения своих целей Функция Реализация алгоритма в программе, посредством которой пользователь программы может частично или полностью выполнить свою задачу
Совокупность действий ИС, направленная на достижение определенной цели
Описание процесса выполнения функции должно включать необходимые пояснения к разделению автоматизированных функций на действия (операции), выполняемые техническими средствами и человеком
Перечень сокращений
ИС Информационная система








Приложение Б
ОБЩИЕ СВЕДЕНИЯ
Наименование

ИС формирование оптимального портфеля
Номер договора
ХХХХХ
Наименование предприятия разработчика и заказчика
ООО «ХХХХХХХХХ»
Перечень документов на основании которых создается система

Система разрабатывается на основании требований к системе
Плановые сроки начала и окончания работ по созданию системы
Датой начала работ считается день подписания технического задания исполнителем и заказчиком, дата окончания определяется календарным планом работ.
Сведения об источниках финансирования работ по созданию системы.

Создание системы финансируется заказчиком на основании актов выполненных работ предъявляемых исполнителем
Порядок оформления и предъявление заказчику результатов работ по созданию системы

Система должна соответствовать документации требованиям. Предварительные испытания должны проводиться Исполнителем в присутствии представителей Заказчика по программе и методике испытаний, составленной Исполнителем и согласованной с Заказчиком.
НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
Назначение системы
Основной автоматизируемый процесс:
Формирование оптимального портфеля, используя модель Марковица
Цели создания системы
Основной целью проведения работ является создание однопользовательской системы
ХАРАКТЕРИСТИКА ОБЪЕКТОВ АВТОМАТИЗАЦИИ
3.1. Краткие сведения об объекте автоматизации
Объектам автоматизации является частный инвестор
3.2.Сведения об условиях эксплуатации объекта автоматизации и характеристиках окружающей среды
Условия эксплуатации системы - внутри помещений пригодных для постоянного наличия i - температура 23 гр. С, влажность 60-80%. Круглосуточно кондиционированное помеще-;рверной, высоко-устойчивая система энергоснабжения.
ТРЕБОВАНИЯ К СИСТЕМЕ В ЦЕЛОМ
Требования к системе в целом
Назначение подсистем и их основные характеристик представлены
Таблица 1.
Назначение подсистем и их основные характеристики

Бизнес процесс Подсистема Подбор акций в портфель Подбор ценных бумаг в портфель Расчет доли акций в портфеле Расчет долей выбранных акций Расчет количества акций, на основании рассчитанных долей Расчет количества ценных бумаг
Требования к способам и средствам связи для информационного обмена между компонентами системы
Система однокомпонентная, требований к средствам связи между системами отсутствуют
Требования к характеристикам взаимосвязей создаваемой системы со смежными системами
Система не использует смежные системы
Требования к режимам функционирования системы
Система должна функционировать непрерывно, за исключением периодов проведения профилактических и других работ, предусмотренных регламентом, а также устранения возникших нештатных ситуаций
.
Требования по диагностированию системы
Система не требует специальных средств диагностики.
Перспективы развития. Модернизация системы
При разработке системы должны быть предусмотрены возможности ее последующей мо-щии по следующим направлениям:
- расширение функций системы;
Требования к численности и квалификации персонала системы и режиму его работы
ИС однопользовательская система, пользователь инвестор, должен имеет навыки работы с Microsoft Office Access 2007 и навыки работы с операционной системой Windows
Показатели назначения
Вероятностно-временные характеристики, при которых сохраняется целевое' назначение системы
Целевое назначение системы должно сохраняться на протяжении всего срока эксплуатации. Срок эксплуатации системы определяется сроком устойчивой работы аппаратных в вычислительных комплексов, своевременным проведением работ по замене (обновлении) аппаратных средств, по сопровождению программного обеспечения системы и его модернизации, при условии постоянного выполнения этих работ целевое назначение системы должно сохранять неограниченно долго. Сроки амортизации не менее 10 лет.

Требования к надежности
Надежность программного обеспечения
Надежность обеспечивается средой разработки приложения Microsoft Office Access 2007
Надежность технических средств
Надежность технических средств системы должна обеспечиваться:
выбором отказоустойчивого оборудования, его резервированием;
дублированием носителей информации.
Требования безопасности

Защита технических средств системы от воздействий электрического тока, электромагнит-лей, акустических шумов и т.п. должна осуществляться специальными службами в соответствии с требованиями по эксплуатации, предъявляемыми к соответствующему оборудованию. Защита технических средств системы от воздействий электрического тока, акустических шумов и т.п. должна быть достаточной для эффективного выполнения техническими средствами системы своего назначения при функционировании.
Требования к транспортабельности системы
Все составные части системы являются стационарными и после монтажа и проведения пусконаладочных работ транспортировке не подлежат.
Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
Эксплуатация системы должна производиться в соответствие с эксплуатационной документацией и регламентом технического обслуживания. При нарушении условий эксплуатации системы данных в эксплуатационной документации и регламентах работы, только пользователь несет ответственность за последствия таких нарушений.
Требования к защите информации от несанкционированного доступа
Специальных средств защиты не требуется и обеспечивается средствами операционной системы

Требования по сохранности при авариях
К авариям относятся:
сбой или выход из строя технических средств, на которых осуществляется эксплуатация ш;
сбои электропитания;
сбой общесистемного программного обеспечения;
сбой или отказ прикладного программного обеспечения;
сбой из-за ошибок в работе персонала.
Сохранность обеспечивается средой разработки Microsoft Office Access 2007.
Требования к функциям, выполняемым системой
Таблица 2.
Функциональные требования к системе

Роль пользователя Функция Инвестор Подбор ценных бумаг в портфель Расчет долей выбранных акций Расчет количества ценных бумаг  ПЕРЕЧЕНЬ СОКРАЩЕНИЙ
ИС Информационная система
БД База данных
ПО Программное обеспечение
 ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ
1)Г0СТ 34.602-89 ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ АВТОМАТИЗИРОВАНОЙ СИСТЕМЫ;















34




78





доход

(p

mp

I1

I2

I3

а) Инвестор с высокой степенью избегания риска

(p

mp

I2

I1

I3

б) Инвестор со средней степенью избегания риска

(p

mp

I3

I2

I1

в) Инвестор с низкой степенью избегания риска

*

mp

(p

I1

I2

I3

Рис. 4 – Выбор оптимального портфеля.



Рис. 5. Рыночные риски

Рис. 6. Логарифмически нормальное распределение для исходов, при которых опцион является выгодным

Рис. 8. ER диаграмма БД

Рис. 9. Логарифмически нормальное распределение для исходов, при которых опцион является выгодным

Рис. 10. Даталогическая модель БД

Да

Нет

Последовательная выборка записи таблицы «Портфель акций»

Начало
(Нажата кнопка «Рассчитать доли» на форме «Портфель акций и расчеты»)
Параметры: нет

Достигнут конец таблицы
«Портфель акций»

Присвоить полю «РекомендуемаяДоля» таблицы «Портфель акций» результат работы функции «РасчетДоли»

Вызов функции «РасчетДоли»
Параметры:ДатаНач,ДатаКон,
КодАкции

Выход из процедуры

Начало
(Вызов из процедуры «РасчетДолей») Параметры:ДатаНач,ДатаКон,КодАкции

Запрос из таблицы «Котировки» для расчета отклонений цены акции за период с ДатаНач по ДатаКон

Вычисление доли акции, которую необходимо приобрести

Конец
Возвращаем вычисленную долю в вызывающую процедуру.

Последовательная выборка записи таблицы «Портфель акций»

Начало
(Нажата кнопка «Рассчитать количество» на форме «Портфель акций и расчеты»)
Параметры: нет

Достигнут конец таблицы «Портфель акций»

Да

Нет

РекомендуемоеКоличество к покупке =«РекомендуемаяДоля»* Сумму имеющихся средств /Цену акции

Запрос к таблице котировки для получения текущей цены акции

Присваиваем полю «Количество» таблице «Портфель акций» округленное до целых значение переменной «РекомендуемоеКоличество»

Конец

Выход из процедуры

Рис. 11. Главная экранная форма приложения

Рис. 12. Выбор инструментов