Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Управление домашними финансами» с помощью UML (Понятие, история развития, виды информационных систем)

Содержание:

Введение

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

Целью данной курсовой работы является рассмотрение сущности объектно-ориентированного проектирования информационной системы, средств её реализации ипроектирование системы домашних финансов.

Для достижения поставленной цели в курсовой работе выполняется:

    1. Изучение и описание предметной области.
    2. Выбор на основе проведенного анализа инструментальных средств.
    3. Проектирование ИС в объектно-ориентированном подходе.

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

Повышение эффективности будет достигнуто за счет проектирования и последующего внедрения информационной системы домашних финансов.

Обычно учитывают ряд типичных источников дохода и направлений затрат, приложения для учёта домашних финансов помогают их контролировать. Данный реферат будет актуален людям всех возрастов, так как все, рано или поздно, сталкиваются с проблемой организации домашних финансов, с необходимостью структурирования бюджета.

Считается, что ведение домашних финансов - это сложное занятие, требующее определённых навыков. Действительно, управление домашними финансами без знаний о финансах невозможно. Его необходимо осуществлять независимо от объёма денежных поступлений в семейный бюджет. Что такое «домашние финансы»? Говоря о домашних финансах, правильнее употреблять именно термин «финансы», а не «деньги», так как к деньгам люди привыкли относиться потребительски (зарабатывать лишь для того, чтобы тратить), а финансы подразумевают процесс управления деньгами. На основании определения из источника [1], - «Финансы домашнего хозяйства — совокупность отношений по поводу создания и использования фондов денежных средств и финансовых активов, необходимых для обеспечения жизнедеятельности членов домашнего хозяйства.» , автор составил собственное, более понятное определение домашних финансов – «Домашние финансы – это совокупность всех доходов и расходов в семье».

1 глава. Аналитическая часть

1.1 Понятие, история развития, виды информационных систем

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

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

Добавление  к понятию "система" слова "информационная" отражает цель ее создания и функционирования. Информационные системы  обеспечивают сбор, хранение, обработку, поиск, выдачу информации, необходимой в  процессе принятия решений  задач из любой  области. Они помогают анализировать проблемы и создавать новые  продукты.

Информационная  система - взаимосвязанная  совокупность средств, методов и персонала, используемых для  хранения, обработки  и выдачи информации в интересах достижения поставленной цели.

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

Процессы  в информационной системе

Процессы, обеспечивающие работу информационной системы  любого назначения, условно можно  представить в  виде схемы, состоящей  из блоков:

- ввод информации из внешних или внутренних источников;

- обработка входной информации и представление ее в удобном виде;

- вывод информации для представления потребителям или передачи в другую систему;

- обратная связь - это информация, переработанная людьми данной организации для коррекции входной информации

Информационная система определяется следующими свойствами:

1. любая информационная система может быть подвергнута анализу, построена и управляема на основе общих принципов построения систем;

 информационная  система является  динамичной и развивающейся;

2. при построении информационной системы необходимо использовать системный подход;

выходной  продукцией информационной  системы является  информация, на основе  которой принимаются  решения;

3. информационную систему следует воспринимать как человеко-компьютерную систему обработки информации.

В настоящее время сложилось мнение об информационной системе как о системе, реализованной с помощью компьютерной техники. Хотя в общем случае информационную систему можно понимать и в некомпьютерном варианте.

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

 - уровень  иерархии управления  фирмой, на котором  решение должно  быть принято;

 - принадлежность  решаемой задачи  к той или иной  функциональной сфере  бизнеса;

 - вид  используемой информационной  технологии.

Технология  работы в компьютерной  информационной системе  доступна для понимания  специалистом некомпьютерной  области и может  быть успешно использована  для контроля процессов  профессиональной  деятельности и  управления ими.

Описание предметной области. Постановка задачи.

Ведение учета домашних финансов позволяет решать следующие задачи:

- найти "лишние" деньги в своем кармане;

- понять причины проблем с деньгами, и найти варианты для их решения;

- комфортно жить, не боясь остаться без средств существования;

- выработать в себе привычки, которые будут вести вас к финансовой свободе;

- перестать жить в долг, полностью распоряжаться своей жизнью и своими деньгами;

- реализовать личные финансовые планы и цели;

- обеспечить своим детям финансовое благополучие.

Следовательно, целью данной курсовой работы является создание удобной в использовании ИС, выполненной по архитектуре клиент-сервер с обеспечением максимально возможной независимой клиентской части и БД «Учет домашних финансов», обеспечивающей хранение в электронной форме данных о доходах и расходах семьи.

Предлагаемые мероприятия по улучшению технологии решения задачи

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

Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира.

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

С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: Simula, Smalltalk, C++, ObjectPascal.

Основные понятия объектно-ориентированного подхода – объект и класс. Объект определяется как осязаемая реальность – предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс.

Термины экземпляр класса и объект являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и, наоборот, относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность – это свойства объекта, отличающие его от всех других объектов.

Класс – это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов – одна из самых сложных задач объектно-ориентированного проектирования.

В объектно-ориентированном подходе основная категория объектной модели – класс – объединяет в себе на элементарном уровне как данные, так и операции, которые над ними выполняются (методы). Именно с этой точки зрения изменения, связанные с переходом от структурного к объектно-ориентированному подходу, являются наиболее заметными. Разделение процессов и данных преодолено, однако остается проблема преодоления сложности системы, которая решается путем использования механизма компонентов.

Данные по сравнению с процессами являются более стабильной и относительно редко изменяющейся частью системы. Отсюда следует главное достоинство объектно-ориентированного подхода, которое Гради Буч сформулировал следующим образом: объектно-ориентированные системы более открыты и легче поддаются внесению изменений, поскольку их конструкция базируется на устойчивых формах. Это дает возможность системе развиваться постепенно и не приводит к полной ее переработке даже в случае существенных изменений исходных требований.

Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией. Как правило, в объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса.

На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход «сущность-связь».

Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными се элементами являются:

  • абстрагирование (abstraction);
  • инкапсуляция (encapsulation);
  • модульность (modularity);
  • иерархия (hierarchy).

Кроме основных имеются еще три дополнительных элемента, не являющихся в отличие от основных строго обязательными:

  • типизация (typing),
  • параллелизм (concurrency),
  • устойчивость (persistence).

Достоинства ООП:

  • Основным достоинством объектно-ориентированного программирования по сравнению с модульным программированием является «более естественная» декомпозиция программного обеспечения, которая существенно облегчает его разработку.
  • Кроме этого, объектный подход предлагает новые способы организации программ, основанные на механизмах наследования, полиморфизма, композиции, наполнения.
  • Эти механизмы позволяют конструировать сложные объекты из сравнительно простых. В результате существенно увеличивается показатель повторного использования кодов и появляется возможность создания библиотек классов для раздомашних применений.

Недостатки ООП обуславливаются следующим:

  • Освоение базовых концепций ООП не требует значительных усилий. Однако разработка библиотек классов и их использование требуют существенных трудозатрат.
  • Документирование классов – задача более трудная, чем это было в случае процедур и модулей.
  • В сложных иерархиях классов поля и методы обычно наследуются с разных уровней. И не всегда легко определить, какие поля и методы фактически относятся к данному классу.
  • Код для обработки сообщения иногда «размазан» по многим методам (иначе говоря, обработка сообщения требует не одного, а многих методов, которые могут быть описаны в разных классах).

Основной недостаток ООП - некоторое снижение быстродействия за счет более сложной организации программной системы.

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

К недостаткам объектно-ориентированного подхода относятся некоторое снижение производительности функционирования ПО и высокие начальные затраты. Объектная декомпозиция существенно отличается от функциональной, поэтому переход на новую технологию связан как с преодолением психологических трудностей, так и дополнительными финансовыми затратами. Безусловно, объектно-ориентированная модель наиболее адекватно отражает реальный мир, представляющий собой совокупность взаимодействующих (посредством обмена сообщениями) объектов. Но на практике в на-стоящий момент продолжается формирование стандарта языка объектно-ориентированного моделирования UML, и количество САSЕ-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход.

2 глава. Проектная часть

2.1. Выбор средства для моделирования предметной области решаемой задачи

Рассмотрим описание компании и основные принципы работы подразделения, отвечающего за разработку программного обеспечения.

Рассмотрим описание разработки программного продукта, описываемого в рамках курсовой работы.

В создании программного продукта принимали участие менеджер продукта, менеджер проекта, системный аналитик, команда разработчиков, команда тестирования.

Опишем процесс создания программного продукта в рамках курсовой работы.

Разработка продукта (нового или обновления к уже имеющемуся на рынке) начинается с того, что менеджер продукта собирает со всех заинтересованных лиц (Stakeholders) требования к продукту и описывает их бизнес спецификацию.[8]

Основными заинтересованными лицами являются:

  • Бизнесподразделение (Sales and Marketing).
  • Отдел исследования угроз.
  • Клиенты компании.

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

Далее, документация по проекту передается в подразделение системного анализа в котором есть выделенный аналитик или несколько аналитиков, которые детально прорабатывают требования.

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

Большое и активное участие в рамках разработки ПО принимают участие - проектный менеджер, главный разработчик и технический лидер команды тестирования.

Лидеры разработки и тестирования дают свои оценки по реализации и тестированию требований. На основании этих оценок, руководитель проекта строит проектный план, который обычно состоит из 5 стадий:

  • активная разработка
  • функционального тестирования
  • регрессионной тестирование
  • приемочное тестирование
  • формальная процедура релиза

После того как план готов он предоставляется продуктовому менеджеру на согласование.

Если продуктового менеджера что-то не устраивает, к примеру даты выпуска продукта, на рынок, то запускается процесс пересмотра содержимого проекта. Какие-то требования могут исключиться, чтобы даты были приемлемыми с точки зрения менеджера продукта.

Также, возможен вариант пересмотра состава команды для того, чтобы все необходимые требования были выполнены в срок.

Когда со стороны продуктового менеджера и проектной команды достигнута договоренность происходит формальная процедура о приеме итогового наполнения проекта.

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

Анализ требований и сравнения программных аналогов представлен в таблице 1.

Таблица 1. Сравнение программных аналогов с учетом требований к проектируемой ЭИС

Требования к проектируемой системе

SAP R/3 (SAP ERP)

Oracle E-Business Suite

- статистический расчет потребности в продукции;

+

+

- статистический расчет производства продукции и учет созданной продукции;

+

+

- статистический учет реализованной продукции;

+

+

В вышеперечисленных программных продуктах присутствует избыточный функционал, который компании ОАО «УМПО» не нужен в силу специфики их бизнес-процессов.

Поэтому, например компании совсем не подойдут типовые продукты компании «SAP» или «Oracle» которые являются более типизированными и требуют изменения бизнеса компании-заказчика под свое ПО.

А собственная разработка на данных программных продуктах окажется нерентабельной в силу их дороговизны или отсутствия большого количества специалистов для поддержки эксплуатации и модернизации ЭИС в фазе сопровождения.

В нашем случае, становится очевидным тот факт, что нам необходимо программное обеспечение под заказ, так как автоматизируемая деятельность обладает специфическими особенностями собственных бизнес-процессов организации и конкретным назначением.

При выборе системы программирования были рассмотрены такие среды разработки приложений, как: «MSVisualFoxProv.9.0»; «MicrosoftAccess v.11»; «1С: Предприятие 8.3».

MS Visual Fox Pro v.9.0

Достоинства данной среды разработки приложений следующие:

  • широкий выбор средств, для работы с базами данных;
  • обеспечивается высокая скорость обработки данных, в частности при обработке SQL-запросов;
  • удобный интерфейс с пользователем;
  • возможность генерирования приложения, используя визуальные средства для разработки.

К недостаткам можно отнести следующее:

  • недостаточное внедрение концепции визуального программирования;
  • слабая поддержка объектно-ориентированного подхода к созданию программ;
  • слабый набор средств создания печатных выходных данных.

MicrosoftAccessv.11

MicrosoftAccess является полнофункциональной системой управления реляционной базой данных (СУРБД). Она обеспечивает все возможности определения, обработки и управления данными для работы с большими объемами информации.

Для обработки таблиц Access использует мощный язык баз данных – SQL (StructuredQueryLanguage – язык структурированных запросов). С помощью SQL можно получить набор данных, который необходим для решения конкретной задачи.

MicrosoftAccess предоставляет дополнительные средства разработки приложений баз данных, позволяющие не только обрабатывать данные в собственных структурах базы данных, но и в других распространенных форматах баз данных.

Вероятно, наиболее мощным качеством Access является возможность обработки данных из электронных таблиц, текстовых файлов, файлов dBase, Paradox и FoxPro, а также любых баз данных SQL, поддерживающих стандарт ODBC (OpenDataBaseConnectivity). Это означает, что Access можно использовать для создания Windows-приложений, способных обрабатывать данные как сетевого сервера SQLServer, так и базы данных, размещенной на головном компьютере.

Характеристики языков программирования представлены в таблице 2.

Таблица 2. Сравнительная характеристика языков программирования

VisualFoxpro

Access (VisualBasic)

Принцип обработки кода

Интерпретатор (псевдокомпилятор)

Интерпретатор (псевдокомпилятор)

Язык

DBASE c

с объектами

Basic c Объектами

Система

Закрытая

Закрытая

Создание пользовательских мастеров

-

-

Динамическое создание форм ввода, обработки сообщений

+

+

Модель создания приложения

-

-

Технология

Построители экранов, меню, отчетов (drag-and-drop), классов

Построители экранов, меню, отчетов (drag-and-drop), классов

Вывод из баз данных на печать

Встроенный Report

Встроенный Report

Обработка исключений

Процедура

Процедура

Поддержка CASE-средств

-

+

«1С: Предприятие поддерживает 5 видов СУБД:

  • IBM DB2
  • MS SQL
  • Oracle BD
  • PostgreSQL

Характеристики СУБД представлены в таблице 3.

Таблица 3. Сравнительная характеристика СУБД Microsoft SQL Server, DB2 и Oracle

Признак сравнения

SQL Server

DB2

Oracle

Разработчик

Microsoft

IBM

Oracle Corporation

Язык запросов

Transact-SQL (T-SQL)

Декларативный SQL (SQL DB2)

ANSI SQL и PL/SQL

Протокол передачи данных

Tabular Data Stream (TDS)

TCP/IP, SNA/APPC, NETBIOS, IPX/SPX

TCP/IP, SNA/APPC, NETBIOS, IPX/SPX

Интерфейс взаимодействия приложений с СУБД

Open Database Connectivity (ODBC)

JDBC, SQLJ, ODBS, OLE DB

JDBC, SQLJ, ODBS, OLE DB, VI SAN

Преимущества

поддерживает зеркалирование и кластеризацию БД;

поддерживает избыточное дублирование данных по сценариям: «снимок», «история изменений», «синхронизация с другими серверами»;

включает язык для реализации хранимых процедур и функций;

отличается высокой производительностью

мощный многофазовый оптимизатор SQLDB2 строит эффективный план выполнения запроса;

использование статистического распределения данных в таблицах;

поддержка XML документов;

поддержка реляционных и комплексных данных с помощью объектных расширений;

возможность работы на мультипроцессорных платформах;

поддержка кластеров;

64-битная архитектура памяти;

идентичность кода раздомашних версий сервера баз данных для всех платформ

поддержка XML в хранимых процедурах;

отправка SQL-запросов к БД с применением URL-адресов;

средства объектно-ориентированного конструирования;

система оптимизации одновременного доступа;

высокая надежность;

возможность разбиения крупных баз данных на разделы;

наличие универсальных средств защиты информации;

эффективные методы

Преимущества

распараллеливание запросов;

наличие средств для гетерогенного администрирования и обработки данных;

поддержку выполнения распределенных транзакций

максимального повышения скорости обработки запросов;

распараллеливание операций в запросе;

широкий спектр средств разработки, мониторинга и администрирования;

связанные базы данных OLAP;

поддержка большого объема памяти и симметричной многопроцессорной обработки;

поддержка службы единого каталога;

инструментальные средства разработки схем, генерации запросов и кода

Недостатки

выполнение некоторых операций администрирования требует однопользовательского режима работы;

неполная совместимость T-SQL с ANSISQL;

проблемы недостаточности программных средств;

зависимость от операционной среды (Windows)

в языке SQLDB2 практически отсутствуют подсказки оптимизатору;

плохо развит язык хранимых процедур;

не имеет собственных средств аутентификации

Для реализации возможностей СУБД Oracle требуется большой объем внедрения, причем специалисты по Oracle одни из самых дорогих.

Дальнейшее сопровождение системы также требует либо привлечения специалистов со стороны, либо наличия сертифицированных сотрудников в компании.

Для создания базы данных ИС домашних финансов была выбрана система управления реляционными базами данных Microsoft SQL Server 2012.

2.2 Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию

Для лучшего понимания разрабатываемой информационной системы необходимо построить концептуальную модель данных, а именно UML-диаграмму. Имеется внешний объект — пользователь, который выступает в качестве актера. Актер взаимодействует с системой, в результате этого взаимодействия, он может выполнять одно из трех действий:

  • Вводить данные.
  • Получать данные.
  • Создавать отчет.

Вариант использования [2] «Получить данные» включает такие компоненты, как «Учет доходов» и «Учет расходов». В результате получается следующую use-case диаграмму:

В результате исследования предметной области стало ясно, что основной сущностью является Человек.

Исходя из того, что база данных может хранить информацию о нескольких людях (если оно используется для учета доходов семьи), то сущность человек имеет атрибуты:

  • идентификатор человека;
  • Ф.И.О. Человека;
  • возраст человека.

Человек имеет определенные виды доходов:

  • Основной доход.
  • Дополнительный доход.
  • Государственные пособия.
  • Депозит.

Под «основным доходом» понимается заработная плата по основному месту работы, а также постоянный доход, например, доход от аренды недвижимости или доход от акций.

Следовательно, сущность имеет следующие атрибуты:

  • идентификатор дохода;
  • тип дохода;
  • частота дохода;
  • размер дохода.

Под «дополнительным доходом» понимаются какие-то другие виды заработка, а также различные неожиданные доходы, например, наследство, выигрыш, подарок и т. д.

Сущность «дополнительный доход» имеет следующие атрибуты:

  • идентификатор дохода;
  • тип дохода;
  • размер дохода.

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

«Депозит» выделяется в отдельную сущность, т. к. он имеет отличные от других видов дохода параметры. Депозит – это деньги, которые клиент передаёт банку на ограниченный срок с определёнными условиями. Под условиями понимаются сами проценты, частота начисления.  Следовательно, атрибутами этой сущности будут являться:

  • идентификатор депозита;
  • тип депозита;
  • частота начисления;
  • размер суммы;
  • процент;
  • срок, на который взят депозит.

Сущности «Персональный основной доход», «Персональный дополнительный доход», «Персональные гос-пособия» и «Персональный депозит», являясь альтернативой связи многие-ко-многим, хранят информацию о человеке и его видах доходов. Эти сущности идентичны и имею одинаковые атрибуты:

  • идентификатор персонального дохода;
  • идентификатор человека;
  • идентификатор дохода.

Последняя деталь логической модели — это сущность «Расходы», которая также является справочником и хранит информацию о человеке и произведенном им виде расхода: типе, дате, размере.

Рассмотрим проектирование информационной системы с точки зрения универсального языка моделирования UML.

Диаграмма вариантов использования представлена на рис. 13.

Рисунок 13. «Диаграмма вариантов использования»

Диаграмма развертывания представлена на рис. 14

Рисунок 14. «Диаграмма развёртывания»

Т.к. каждое отношение может быть представлено отдельной таблицей, то с учетом всех известных данных структура БД «Учет личных финансов» состоит из десяти таблиц:

  1. Таблица «Человек»;
  2. Таблица «Основной доход»;
  3. Таблица «Дополнительный доход»;
  4. Таблица «Государственные пособия»;
  5. Таблица «Депозит»;
  6. Таблица «Персональный основной доход»;
  7. Таблица «Персональный дополнительный доход»;
  8. Таблица «Персональные государственные пособия»;
  9. Таблица «Персональный депозит»;
  10. Таблица «Расходы».

Рассмотрим более подробно каждую таблицу:

Man

«Человек»

Таблица 1.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_man

integer

идентификатор человека

+

-

+

+

name

varchar(150)

Ф.И.О. человека

-

-

-

+

age

integer

возраст человека

-

-

-

-

Basic_income

«Основной доход»

Таблица 2.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_bas

integer

идентификатор основного дохода

+

-

+

+

type_bas

varchar (100)

тип основного дохода

-

-

-

+

kind_bas

varchar (100)

вид основного дохода

-

-

-

+

freq_bas_in_month

real

частота основного дохода в месяц

-

-

-

-

size_bas

integer

размер основного дохода

-

-

-

+

Additional_income

«Дополнительный доход»

Таблица 3.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_ad

integer

идентификатор дополнительного дохода

+

-

+

+

type_ad

varchar (100)

тип дополнительного дохода

-

-

-

+

size_ad

integer

размер дополнительного дохода

-

-

-

+

State_grants

«Государственные пособия»

Таблица 4.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_st

integer

идентификатор гос-пособий

+

-

+

+

type_st

varchar (100)

тип гос-пособий

-

-

+

+

freq_st_in_month

integer

частота гос-пособий в месяц

-

-

-

-

size_st

integer

размер гос-пособий

-

-

-

+

Deposit

«Депозит»

Таблица 5.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_dep

integer

идентификатор депозита

+

-

+

+

type_dep

varchar (100)

тип депозита

-

-

-

+

freq_of_charge_in_year

integer

частота начисления депозита в год

-

-

-

+

size_of_sum

integer

размер суммы депозита

-

-

-

+

percents

integer

проценты от депозита

-

-

-

+

period_in_years

real

срок хранения депозита в год

-

-

-

+

Personal_basic_income

«Персональный основной доход»

Таблица 6.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_pers_bas

integer

идентификатор персонального основного дохода

+

-

+

+

id_man

integer

идентификатор человека

-

+

-

+

id_bas

integer

идентификатор основного дохода

-

+

-

+

Personal_additional_income

«Персональный дополнительный доход»

Таблица 7.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_pers_ad

integer

идентификатор персонального дополнительного дохода

+

-

+

+

id_man

integer

идентификатор человека

-

+

-

+

id_ad

integer

идентификатор доп. дохода

-

+

-

+

Personal_state_grants

«Персональные государственные пособия»

Таблица 8.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_pers_st

integer

идентификатор персональных гос-пособий

+

-

+

+

id_man

integer

идентификатор человека

-

+

-

+

id_st

integer

идентификатор гос-пособий

-

+

-

+

Personal_deposit

«Персональный депозит»

Таблица 9.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_pers_dep

integer

идентификатор персонального депозита

+

-

+

+

id_man

integer

идентификатор человека

-

+

-

+

id_dep

integer

идентификатор депозита

-

+

-

+

Expenses

«Расходы»

Таблица 10.

Атрибуты

Тип данных

Description

PK

FK

UNIQUE

NOT NULL

id_exp

integer

идентификатор расходов

+

-

+

+

id_man

integer

идентификатор человека

-

+

-

+

type_exp

varchar(100)

тип расходов

-

-

-

+

size_exp

integer

размер расходов

-

-

-

+

data

date

дата расходов

-

-

-

+

Формы разработанного приложения представлены в приложении.

Заключение

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

Актуальность темы курсовой работы также связанна с применением гибких методологий разработки программного обеспечения в проектах разработки программного обеспечения.

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

Эта работа предназначена для широкого круга специалистов, работающих в области разработки программного обеспечения.

В процессе выполнения курсового проекта была спроектирована информационная подсистема информационной системы домашних финансовсредствами объектно-ориентированного проектирования.

С помощью данного приложения можно отказаться от ведения личного или семейного бюджета посредством бумаги и калькулятора, т. к. абсолютно любой человек может использовать разработанное программное обеспечение для своих нужд в домашних условиях.

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

Гибкие методы используются тогда, когда присутствуют следующие условия:

  • значение проекта четко обозначено,
  • клиент активно участвует на протяжении всего проекта,
  • клиент, дизайнер и разработчики находятся рядом,
  • возможна пошаговая разработка, основанная на функциях,
  • допустима визуальная документация.

В рамках курсовой работы были получены навыки работы с основными инструментами, которые используются в компании для разработки ПО и планирования проектов.

Список использованной литературы

  1. Список электронных ресурсов 1. Adme [электронный ресурс] https://www.adme.ru/svoboda-psihologiya/metodkuvshinov-kotoryj-pomozhet-vam-sekonomit-875510/
  2. Баркан Д.И. Статистика для всех. – Редакционно-издательский центр «Культ-информ-пресс»; социально-коммерческая фирма “Человек” 2006.
  3. Власова В. М. Основы предпринимательской деятельности. – М.: Финансы и статистика, 2015.
  4. Голубков Е. П. Основы производства. – М.: Финпресс, 2010 г.
  5. Горемыкин В. А., Богомолов А. Ю. Планирование предпринимательской деятельности предприятия. – М.: Инфра-М, 2007.
  6. Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник.- М.: Финансы и статистика, 2015.
  7. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем.- М.: Финансы и статистика, 2008.
  8. Смирнова Г.Н.и др. Проектирование экономических информационных систем: Учебник / Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф.- М.: Финансы и статистика, 2011.
  9. Маклаков С. В. BPWin, ERWin, CASE –средства разработки информационных систем. М. ДИАЛОГ-МИФИ, 2009.
  10. Моделирование и анализ IDEF-технологий: практикум / С.В.Черемных, И.О.Семенов, В.С.Ручкин. – М. Финансы и статистика, 2012. – 192 с.:ил.
  11. Цикритизис Д., Лоховски Ф. Модели данных. – М.: Финансы и статистика, 2005.

Приложения

Формы разработанного приложения

Рисунок 1. Справочник «Члены Семьи»

В нем созданы следующие поля:

  1. «Наименование» (системное поле, уже имеется по умолчанию у объекта типа «Справочник»)

Форма справочника в режиме «1С: Предприятие 8» и работа со справочником «Виды доходов» представлена на рисунках 2 и 3.

Рисунок 2. «Форма элемента справочника «Виды доходов»»

Рисунок 3. «Работа со справочником «Виды дохода»»

С учетом требований к информационной системе и к базе данных, были спроектированы, разработаны и реализованы следующие документы, регистры и находящиеся в них бизнес-логика для моей учебной конфигурации – базы данных »:

  • Документ «Доходы»;
  • Документ «Расходы»;
  • Документ «Денежные остатки Семьи»;
  • Регистр «Денежные доходы»;
  • Регистр «Денежные расходы»;
  • Регистр «Денежные остатки Семьи»

Реализованные документы представлены на рисунках 4 – 7.

Рисунок 4. «Документ «Доходы»

Рисунок 5. «Запись движений документа «Доходы» в регистр» «Доходы»

Рисунок 6. «Работа с документом «Расходы»

Рисунок 7. «Работа с документом «Ввод остатков»

В ходе разработки прикладного решения были созданы следующие отчеты:

  • «Расходы семьи»;
  • «Доходы семьи»;
  • «Остатки семь»;

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

На рисунках 8 – 11 представлены отчеты.

Рисунок 8. «Отчет «Денежные остатки»

Рисунок 9. «Отчет «Доходы семьи»

Рисунок 10. Отчет «Расходы семьи»

ПРИЛОЖЕНИЕ 2

Программный код

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,

Заявки.Пользователь,

Заявки.Право,

Заявки.

Заявки.Объект,

Заявки.

ИЗ

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

_РЕГИСТРОВ

/

/регистр Решения

Движения.Решения.Записывать = Истина;

Для Каждого Из Заявка Цикл

Процедура ПечатьСсылка)

ВЫБРАТЬ

Заявки.Период,

Заявки.Регистратор,