Вернуться в электронную библиотеку

Перевод текста Горелова Б. А. "Создание системы планирования, управления и контроля за финансовыми потоками" (автор перевода Бенесько А.О)

Резюме

В этой статье мы рассматриваем проблемы и возможные способы решения, которые могут возникнуть при создании системы планирования, управления и контроля финансовыми потоками юридического лица (университета). Эта система стремится управлять выполнением соглашений, которые Московский технический университет подписывает с третьими лицами. Система также в состоянии предсказать расходы будущих периодов и входящий денежный поток. университета Система учитывает специфические особенности университета, который имеет определенные научные заказы по исследованиям и глубоко вовлечен в коммерческие действия, помимо наличного притока от государства.

Введение

Любое юридическое лицо уделяет финансовым ресурсам наибольшее внимание. Технический Университет имеет множество различных источников прибыли, помимо притока наличности из государственного бюджета. Это вызывает проблемы дифференцирования, планирования и контроля за доходами. Специфические особенности бюджетных объектов России состоят в отличии их плана бухгалтерских счетов от коммерческих компаний. Ежеквартальный баланс подвергается осмотру не только ГНИ, но также и соответствующими министерствами и комитетами.
Таким образом, разумно автоматизировать процесс контроля выполнения соглашений Технического Университета с третьими лицами с журналами будущих расходов и классификациией бюджета. Одно из самых важных условий - срочное обновление данных соглашений. Именно поэтому следующие цели были установлены для этого проекта: обновление данных соглашений и автоматизация их хранения; регулирование и обработка модификации заявлений о расходах.

Выполнение

Создание программного обеспечения методом выбора

При создании качественного программного обеспечения должен использоваться определённый метод. Эти методы могут быть классифицированы на функциональные и объектно-ориентированные . Функциональные методы рассматривают функции и систему отдельно, в то время как объектно-ориентированные объединяют данные объектов и функции. Традиционный способ разработки программного обеспечения представлен следующими функциональными методами: SADT и RDD. Функциональные методы отделяют функции и данные, устанавливая функции для поведения системы и данные для представления информации, которой управляют функции. Система описана как ряд функций, которые обмениваются данными. Единственные недостаток такого пути решения - определенная трудность поддержки таких систем и их модификации.
Объектно-ориентированный метод состоит из идентификации объектов и последующего описания процедур, которые реализуют определенные операции, представляя поведение объекта. Система, созданная таким образом, более легка для модификации, потому что основана на фактических объектах, а не на функциональных требованиях к система непосредственно. Может быть получен проект системы, который не зависит от реализации. Объектно-ориентированные модели помогают понимать требования к системе, упрощать поддержку системы и проектирование. Объект - главный строительный пункт такого метода. Описания объекта состоят из его свойств и методов. Объектно-ориентированное программирование имеет определенные особенности, типа инкапсуляции, наследования и полиморфизма.
Visual FoxPro 5.0 был выбран как инструментальное средство программирования. Visual FoxPro 5.0 (VFP) - новая версия известной системы управления базами данных Microsoft FoxPro. VFP представляет новый программный стиль, которые поднимают его на новый уровень. Это объектно-ориентированный, визуальный язык программирования. Отличительная особенность VFP - поддержка предыдущих версий VFP. VFP использует средства Windows для общения с другими приложениями. Опытный пользователь имеет большое разнообразие возможностей изменять информацию с помощью полнофункционального интегрированного программного поля на VFP. Используя стандарт ODBC [4] VFP поддерживает Microsoft SQL Server, Oracle, Informix, и другие базы данных.

Установка системы

Недостаточно использовать только программные средства, даже такие как 4-уровневый язык для создания безопасных и эффективных программных приложений. Необходима архитектура данных. С помощью таких моделей может быть создан проект системы, который не зависит от его реализации. Объектно-ориентированное моделирование и проектирование помогают понимать требования к системе, упрощает поддержку системы и её проектирование. Объект - главная строительная единица системы. Его описание состоит из его свойств и методов.
Запросная модель была выбрана с целью избежать неудовлетворительного впечатления от приложения. Установка приложения начинается с учета пожеланий пользователя. Это позволяет сделать приложение в соответствии с требованиями пользователя. Сама модель состоит из 3 частей: поведение прложения с точки зрения пользователя, модели объекта и описание интерфейса.
Приложение "Dogovor" установлено для планирования и управления финансовыми потоками Института. Таким образом пользователь - главный пользователь, который анализирует полученные данные и выполняет определённые действия на основе этой информации. Используя приложение "Dogovor" мы можем классифицировать пользователей на 2 неодинаковые группы: операторы и администратор. Оператор делает записи данных о соглашениях, их стадиях, действиях, клиентах, заявлениях о расходах, делают информационные исправления. Администратор ответственен за базу данных вообще.
Его главная обязанность - поддерживать информацию и восстанавливать данные в случае ошибок программы и проблем обслуживания.
"Use case" является представлением внутреннего процесса программы. Каждый "Use case" описывает определенный путь функциональных возможностей приложения и устанавливает взаимодействие пользователя и приложения. Множество "Use case" представляют все возможности приложения.

Проектирование базы данных

Visual FoxPro 5.0 - операционная система реляционных баз данных, которые используются сейчас наиболее часто и стали уже почти стандартом В этой версии установлены все относительные признаки системы управления базами данных. Прежде всего определение базы данных дается здесь, который состоит из группы таблиц. В этой базе данных Вы можете определить условия единства данных с помощью первичного и внешних ключей таблиц. VFP поддерживает механизмы, которые позволяют обеспечить централизованный анализ в любых изменениях базы данных.
Модель ER, как полагают, является одной из самых популярных семантических моделей баз данных. Большинство реляционных баз данных основано на ее использовании. Её предложил Чен в 1976 [6]. Моделирование объектов основано на графическом использовании диаграмм, включая небольшое количество несвязанных компонентов. Модели ER стали широко используемыми в CASE-системах, которые поддерживают автопроектирование реляционных баз данных.

Реализация системы

Стандартная идентификация объектов при создании приложения считается одним из лучших методов роста производства. Такие классы пользователей на основании VFP использовались при разработке приложения "Dogovor". Чтобы достигать полной стандартизации системы, были созданы несколько классов пользователей : класс входных данных, который является доступным только для чтения, класс редактирования входных данных и т.д. Если понадобится изменить стандарт в будущем, будет достаточно изменить классы, которые являются фактически объектами приложения.
Библиотеки класса используются для хранения классов пользователей, созданных в VFP. Все эти классы для приложения "Dogovor" сохранены в 2 библиотеках класса. Мы использовали подклассы при создании приложения, что позволило использовать классы пользователей как основание для следующего создания классов. Так как подкласс наследует все особенности класса предка, было достаточно добавить новые свойства и методы или изменить свойства базового класса.
Давайте впосмотрим, как подклассы использовались на пример е нескольких новых классов для создания входных данных.
- подкласс "Base-textbox" для поля ввода данных, которое могло изменять размер, цвет, шрифт.
- на основании этого класса, были созданы несколько подклассов, которые отличался по типу данных или количеству символов.
Например подкласс "Chr30" позволяет вводить данные длиной 30 символов типа Character, "Nomer" позволяет подобный ввод (длина 6 символов), и "Rpsumm" дает возможность вводить валюту до 99999999,99 RUR.
Если бы былаесть потребность изменить особенности отражений полей ввода данных в целом, было бы достаточно сделать исправления этих особенностей в первом из созданных классов, и исправления распространятся по всей иерархии подклассов, которые обращаются к этому классу.
Структура системы "Dogovor" приведена на следующем рисунке:

Заключение: интерпретация результатов

При решении проблемы было проведено изучение рыночной конъюнктуры программного обеспечения в области планирования деятельности компании. Было рассмотрено несколько систем с точки зрения решения такой проблемы. Юыл проанализирован опыт лругих объектов, имеющих похожие проблемы. Используемое ими программное обеспечение было или несоответствующим для вышеупомянутых целей или слишком дорогостоящим.
Был также проведён анализ пакета программ MEPhI. Все особенности организации и технической системы Института были приняты во внимание. Детальное исследование было также проведено при анализе потоков информации.
Были определены объекты, какие данные должны быть активными после закрытия программы. Эти объекты фактически формируют базу данных. ER-диаграммы были созданы для баз данных приложения. Были разработаны проекты реляционной базы данных. Visual FoxPro 5.0 использовался как система управления баз данных.
Это позволило установить взаимодействие приложения с другим пакетом программ MEPhI. В результате была построена иерархия объектов: иерархия Windows, классов пользователей. Были созданы библиотеки класса, которые служили основанием для интерфейса приложения.