Содержание:

Введение

Предметом данной работы является методы и средства проектирования информационных систем.

Целью данной курсовой работы является Моделирование предметной области «Управление домашними финансами» посредством UML.

Для достижения целей необходимо решить следующие задачи

1. Описать предметную область

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

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

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

Для чего и ради чего работает экономика? Главная цель экономики - повышение благосостояния людей. Согласно[5, c.181], экономика предназначена для работы помимо государственного бюджета еще и с семейным. Государство также удовлетворяет часть потребностей семьи. Не случайно поэтому Нобелевская премия по экономике за 1992 год была присуждена американскому ученому Гэри Беккеру, сумевшему доказать, что поведение людей и в сфере личной жизни подчиняется общим правилам экономической рациональности.

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

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

Поэтому разработка программного обеспечения для расчета и учета семейного бюджета имеет актуальность.

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

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

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

Рисунок 1.1. – Средняя структура доходов семьи

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

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

Рисунок 1.2. – Средняя структура расходов семьи

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

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

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

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

1. Приложение «Семейный бюджет». Данное ПО помогает упорядочить расходы, доходы, счета и управлять ими. Имеется синхронизация с web-ресурсом, что позволяет вести семейную бухгалтерию как с персонального компьютера, так и с мобильного устройства. Так же возможно вести отдельную статистику по расходу коммунальных услуг.
2. Приложение «Личные финансы» EasyFinance.ru. Приложение EasyFinance, так же, как и предыдущее приложение позволяет фиксировать свои доходы и группировать их. Так же есть возможность создавать шаблоны для частых операций.
3. Toshi финансов. У данного приложения интересный подход к реализации. У него есть выждете, которые дают советы пользователю, есть push-уведомления о перерасходах. Так же есть таймеры, напоминающие об оплате счетов услуг ЖКХ и т.д.
4. Дзен-мани: учет расходов. Приложение умеет распознавать и учитывать о расходах и доходах посредством push- и sms-уведомлений.
5. Деньги ОК: личные финансы и бюджет. Программа легка в усвоении, имеет наглядную статистику, как в общем виде, так и отдельно, по категориям расходов и доходов.

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

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

1. Доходы (заработная плата, пенсия, дополнительный заработок, льготы, пособия, вклады, сбережения);
2. Расходы (кредиты, долги, учеба, курсы, квартплата, ЖКХ, продукты питания, одежда, развлечения, медицинское обслуживание).

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

1. Практическая часть

   1. Выбор средства для моделирования предметной области

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

Основным требованием к CASE-системе – поддержка UML нотации 2.0 и выше, а также свободное встраивание графических объектов пользователем. Рассмотрим следующие CASE-средства: Borland Together, Rational Rose и MSVisio. У всех имеется поддержка UML 2.x.

Преимуществом MSVisio в том, что данное ПО идет, как дополнение к Microsoft Office, и установка ее не займет больших усилий. Минус данного ПО в том, что имеется не полная поддержка UML 2.x.

Rational Rose является коммерческой разработкой компании IBM. Последняя версия данного ПО поддерживает нотацию UML 2.x в полном объеме, но из-за большой цены, не целесообразно применение для разового решения задачи. Преимуществом данной системы в том, что имеется возможность генерации кода на основе построенных моделей.

Borland Together поставляется в комплекте со средой разработки Borland Developer Studio. Данное CASE-средство так же позволяет генерировать код на основе построенных диаграмм. Стоимость данного пакета так же, как и Rational Rose, высокое, но более доступно. Подробное сравнение представлено в таблице 2.1.

BPWin и ERWin поддерживающие IDEF0, IDEF3, DFD и IDEF1.x не являются альтернативой выше перечисленных CASE-средств, так как настроены на решение иного спектра задач.

Таблица 2.1 – сравнение CASE-систем

	MSVisio	RationalRose	BorlandTogether
Поддержка UML 2.x	+	+	+
Генерация кода	+	+	+
Работа в комплексе		+	+
Поддержка		+	+
Оценка	Удовл	Отл	Хор
Цена	Бесплатно	>130 000 руб	>50 000 руб

Исходя из этого, оптимально использовать MSVisio, т.к. тот же RationalRose не каждая компания может себе позволить.

• 1. Моделирование предметной области «Управление домашними финансами» с использованием объектно-ориентированного подхода к проектированию

На первом этапе создадим диаграмму вариантов использования (use case diagram), отражающую отношения между актерами и прецедентами. Данный вид диаграммы является исходным концептуальным представлением разрабатываемой системы при помощи так называемых, вариантов использования.

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

Согласно[3, c.204] UML актера изображают в виде человечка, но встречаются и иные варианты изображений (рисунок 2.1).

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

Вариант использования, согласно нотации UML изображается в виде эллипса (рисунок 2.2), в котором идет описание какой-либо операции или действия.

Рисунок 2.1 – Примеры вариантов использования.

Связи между актерами и вариантами использования определяются четырьмя типами:

1. ассоциации;
2. обобщения;
3. включения;
4. расширения.

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

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

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

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

В нашей модели актером, как и в диаграмме вариантов использования, выступает семья (family). Данный объект передает данные, для планирования расходов и доходов в класс планирования (planning), в которые входит запланировав заработная плата (payPlan), запланированная пенсия (pensionPlan), запланированные подработки (underworkPlan) и проценты от вкладов в банк (deposinPlan). Такие параметры поступат из класса доходов (income), после чего, классу family передается разница между запланированным и реальным доходом, посредством функции differentIncome().

По аналогии идет расчет расходов, разница лишь в переменных, кредит (creditPlan), транспорт (autoPlan), образование (educationplan), квартплата (rentPlan), одежда и обувь (clothesPlan), отдых и развлечения (relaxPlan), медицинская страховка и лечение (medPlan) и остальные расходы (otherConPl). Далее, на серверной части идет расчёт разницы между реальным и планируемым доходом, посредством функции differentConsuption().

Так же Planning возвращает суммарные значения доходов и расходов, посредством функций summaryIncome() и summaryConsuprion(). И в конце подводится итог того, сбалансирован ли бюджет или бюджет имеет дефицит, на основе бинарного значения if(summaryIncome()>=summaryConsuprion()). Данная диаграмма представлена в приложении Б.

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

Стоит отметить на схеме еще блок alt, который является некоторым аналогом условного блока if-else[2.c.403].

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

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

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

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

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

Событие времени – спецификация факта, обозначающего наступление конкретного момента времени (англ. absolute time) или истечение определенного промежутка времени (англ. relative time). В UML данный факт обозначается с помощью ключевых слов «at» (например, at 9:00:00) и «after» (например, after 2 seconds).

Изменение состояния – спецификация логического условия, соответствующего изменению состояния экземпляра сущности. В UML оно обозначается с помощью ключевого слова «when» (например, when A < B) или сторожевого условия (например, [A < B]).

При разработке данной диаграммы следует придерживаться следующих рекомендаций[4. c.56]:

1. Наличие нескольких состояний у экземпляра сущности, отличающихся от простой схемы «исправен – неисправен» или «активен – неактивен», служит признаком необходимости построения диаграммы автоматов. При выделении состояний и переходов следует помнить, что длительность срабатывания переходов должна быть существенно меньшей, чем нахождение моделируемого объекта в соответствующих состояниях. Каждое из состояний должно характеризоваться определенной устойчивостью во времени.
2. Автомат (диаграмма) обязательно должен начинаться знаком начального состояния и заканчиваться знаком конечного. Начальное состояние указывается только один раз, а конечных может быть несколько в целях минимизации пересечений переходов. Для подавтоматов рекомендуется придерживаться этого же правила или использовать точки входа / выхода. Допускается не указывать начальных / конечных состояний и точек входа / выхода для составных состояний или подавтоматов, когда начальное подсостояние (подсостояния) очевидны.
3. Для облегчения восприятия диаграммы рекомендуется использовать декомпозицию со скрытием составных состояний.
4. Диаграмма не должна содержать изолированных состояний и переходов. Переходы и их спецификация должны быть заданы таким образом, чтобы на графе каждое состояние было потенциально достижимо из начального и из любого состояния было потенциально достижимо конечное.
5. Триггерные переходы по условию на диаграмме можно показать тремя способами, согласно рисунку 2.3.

Рисунок 2.3 – Способы отображения триггерных переходов

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

Диаграмма автоматов для моделирования системы, представлена в приложении В.

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

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

Основными элементами диаграммы являются: исполняемые узлы, объекты, переходы, управляющие узлы, коннекторы, группирующие элементы.

К исполняемым узлам относятся действия и деятельности. На блок-схемах их аналогами являются процессы и предопределенные процессы. Обычное использование исполняемых узлов заключается в моделировании одного шага выполнения алгоритма (процедуры) или потока управления. Графически исполняемые узлы отображаются, как простые и составные состояния. Внутри фигуры записывается выражение действия, записываемое на естественном языке, некотором псевдокоде или языке программирования.

К объектам относятся непосредственно объекты в традиционном понимании UML, отправка сигнала, прием сигнала и событие времени. Отображение сигнала на диаграмме может вызвать затруднения – рисовать его как отправку или прием? В частности, сигнал может рассматриваться как в одном, так и в другом смысле. Если в результате действия генерируется сигнал для последующей обработки (из символа действия исходит стрелка и входит в символ сигнала), то он отображается как «отправка сигнала». Когда сигнал поступает на обработку (из символа сигнала исходит стрелка и входит в символ действия), то он отображается как «прием сигнала».

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

Рисунок 2.4 – Примеры переходов

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

Управляющим узлам на диаграмме деятельности соответствуют псевдосостояния на диаграмме автоматов.

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

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

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

1. При построении диаграмм рекомендуется использовать классические принципы моделирования – декомпозиции и иерархического упорядочения. Т.е. при моделировании алгоритма вначале строится контекстная диаграмма с деятельностями, которые после детализируются с помощью соответствующих диаграмм декомпозиции.
2. Количество пересечений линий следует минимизировать. При этом считается, что пересекающиеся линии не имеют логической связи друг с другом. Другими словами потоки данных или управления в местах пересечений не меняют своего направления.
3. Если на диаграмме имеется ветвление / решение на параллельные или альтернативные потоки, то должно указываться и соответствующее соединение / слияние этих потоков.
4. При использовании альтернативных потоков каждый из них должен быть специфицирован с помощью сторожевого условия. Сторожевые условия не должны допускать одновременного срабатывания двух и более переходов.
5. В целях определения зоны ответственности (набора действий) сущностей рекомендуется использовать разделы деятельности.

Построенная диаграмма деятельности, касательно заданной темы, представлена в приложении Г.

Диаграмма классов отражает различные взаимосвязи между остальными сущностями (объектами) а так же описывает их внутреннюю структуру.

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

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

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

В секции имени класса может быть указан стереотип (например, "entity", "boundary", "interface" и т. п.).

Во второй секции каждому атрибуту соответствует отдельная строка со следующей спецификацией:

[видимость] [/] имя [: тип [‘[‘кратность‘]‘] [ = исходное значение]] [‘{‘модификаторы’}’].

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

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

- "+" – общедоступный атрибут (англ. public) – доступен для чтения и модификации из объектов любого класса;

- "#" – защищенный атрибут (англ. protected) – доступен только объектам описываемого класса и его потомкам при наследовании;

- "–" – закрытый атрибут (англ. private) – доступен только объектам описываемого класса;

- "~" – пакетный атрибут (англ. package) – доступен только объектам классов, входящих в тот же пакет.

Символ "/" перед именем атрибута указывает на то, что он является производным (т.е. его значение вычисляется из значений других атрибутов или ассоциаций).

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

Тип атрибута выбирается исходя из семантики значений, которые должны храниться в атрибуте, и, как правило, возможностей целевого языка программирования по представлению этих значений. Он соответствует одному из стандартных типов, определенных в этом языке (например, String, Boolean, Integer, Color и т. д.) или имени класса, на объект которого в этом атрибуте будет храниться ссылка. Во втором случае класс, имя которого указано в качестве типа, должен быть определен на диаграмме или в модели.

Кратность атрибута характеризует количество значений, которые можно хранить в атрибуте. Если кратность атрибута не указана, то по умолчанию принимается ее значение, равное 1, т. е. атрибут является атомарным. Такой вариант допускает и отсутствие значения в атрибуте (null). Для атрибута, представляющего собой массив, множество, список и т. п., требуется указание кратности, которая записывается после типа в квадратных скобках. Варианты указания кратности, имеющие смысл, могут быть следующие:

- [0..*] или [*] – количество хранимых значений может принимать любое положительное целое число, большее или равное 0. Такой вариант задания кратности характерен для множеств, списков и других атрибутов, допускающих добавление или удаление элементов;

- [0..<число>] – количество хранимых значений, может быть не более указанного числа. Данный вариант применяется при описании массивов фиксированного размера. При этом не обязательно, чтобы все элементы массива имели конкретные значения;

- [0..<число>] [0..<число>] – применяется при описании двумерных массивов. Аналогичным образом можно описать трехмерные, четырехмерные и т.д. массивы.

Исходное значение служит для задания некоторого начального значения атрибута в момент создания отдельного экземпляра класса (объекта).

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

1. За основу диаграммы классов при ее разработке берется диаграмма классов анализа.
2. Для классов должны быть определены и специфицированы все атрибуты и методы. Их спецификация, как правило, выполняется с учетом выбранного языка программирования.
3. При определении методов рекомендуется использовать сообщения с ранее разработанных диаграмм последовательности и коммуникации.
4. Детальное проектирование граничных классов, как правило, не требуется. Большинство современных средств разработки поддерживает визуальную разработку интерфейса системы – меню, диалоговых форм, элементов диалоговых окон, панелей инструментов и т. д. В качестве исходных данных для их проектирования служат прототипы пользовательских интерфейсов. В связи с этим при проектировании таких классов основное внимание следует уделять особенностям отображения информации и специфичным операциям, которые возникают при диалоге пользователя с системой. Граничные классы, определяющие интерфейс взаимодействия с другими системами, требуют детального проектирования.
5. Для проектирования классов-сущностей можно применять подходы, используемые при проектировании БД, особенно в том случае, если данные будут храниться в таблицах БД. Если представление данных в БД и классах отличается друг от друга и в качестве хранилища информации будет применяться реляционная база данных, то рекомендуется разработать отдельную диаграмму классов, описывающую состав и структуру БД. Современные Case-средства позволяют разрабатывать такие диаграммы и синхронизировать их с БД.
6. Несмотря на то, что каждому объекту при выполнении программы автоматически назначается уникальный идентификатор, рекомендуется для классов-сущностей явно определять атрибуты, хранящие значения первичного ключа.
7. В отличие от реляционных БД поощряется использование в классах многозначных атрибутов в виде массивов, множеств, списков и т. д.
8. Управляющие классы следует проектировать только в случаях крайней необходимости – управления сложным взаимодействием объектов, реализации сложной бизнес-логики и вычислений, контроля целостности объектов и т. п. В противном случае функциональность этого класса лучше распределить между соответствующими граничными классами и классами-сущностями.
9. Для атрибутов рекомендуется назначать видимость private (закрытый) или protected (защищенный). Если требуется чтение значения такого атрибута из объектов других классов, то следует предусмотреть для него get-метод, а если возможность установки нового значения – set-метод.
10. Для методов видимость public (общедоступный) следует устанавливать только в случае крайней необходимости.
11. Ввиду большого количества классов в системе рекомендуется диаграммы классов разрабатывать отдельно для каждого пакета. По умолчанию Case-средства поддерживают именно такой подход проектирования, хотя и допускают разработку диаграмм, на которых присутствуют классы из разных пакетов.
12. При проектировании диаграммы и отдельных классов рекомендуется пользоваться шаблонами проектирования.

Полученная диаграмма классов представлена в приложении Д, а код, составленный посредством Java SE представлен в приложении Е.

ЗАКЛЮЧЕНИЕ

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

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

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

Во второй главе были рассмотрены системы моделирования UML диаграмм и отобрана система, для последующей работы в ней.

Во второй части второй рассмотрены теоретические основы при моделировании UML диаграмм с их непосредственным применением, касательно темы курсовой работы. На выходе имеем набор UML диаграмм с разным уровнем детализации и представления работы системы (приложение А-Д). Так же, на основе этих диаграмм, составлен код, посредством Java SE.

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование, 2-е изд.: Пер с англ. – СПб: Символ-Плюс, 2007. – 624 с., ил.
2. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. 2-е изд.: Пер. с англ. – М.: ДМК Пресс. – 496 с.: ил.
3. Гома Х. UML. Проектривание систем реального времени, прааллельных и распределенных приложений: Пер с англ. – М: ДМК Пресс, 2011. – 704 с., ил.
4. Крэг Ларман. Применение UML 2.0 и шаблонов проектирования. Практическое руководство. 3-е издание.: Пер с англ. – М: ООО И.Д. Вильямс, 2013. – 736 с., ил.
5. Тюгашев Е. А. Экономика семьи и домашнего хозяйтсва: Учебное пособие. – Новосибирск: СибУПК, 2002. – 249 с.

ПРИЛОЖЕНИЕ А

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

ПРИЛОЖЕНИЕ Б

Диаграмма взаимодействия

ПРИЛОЖЕНИЕ В

Диаграмма состояний (автоматов)

ПРИЛОЖЕНИЕ Г

Диаграмма деятельности

ПРИЛОЖЕНИЕ Д

Диаграмма классов

ПРИЛОЖЕНИЕ Е

Листинг

public class Family{ // класс параметрами по планированию семейного бюджета

private float payPlan, pensionPlan, underworkPlan, benefidPlan, depositPlan;

private float creditPlan, autoPlan, educationPlan, clothesPlan, relaxPlan, medPlan, otherConPlan;

public float getPayPlan() {return this.payPlan; }

public float getPensionPlan() { return pensionPlan; }

public float getUnderworkPlan() { return underworkPlan; }

public float getBenefidPlan() { return benefidPlan; }

public float getDepositPlan() { return depositPlan; }

public float getCreditPlan() { return creditPlan; }

public float getAutoPlan() { return autoPlan; }

public float getEducationPlan() { return educationPlan; }

public float getClothesPlan() { return clothesPlan;}

public float getRelaxPlan() { return relaxPlan; }

public float getMedPlan() { return medPlan; }

public float getOtherConPlan() { return otherConPlan; }

}

//----------------------------------------------------------------------------

public class Income { // класс с реальным доходом

private float pay, pension, underwork, benefid, deposit;

public float getPay() { return pay; }

public float getPension() { return pension; }

public float getUnderwork() { return underwork; }

public float getBenefid() { return benefid; }

public float getDeposit() { return deposit; }

}

//------------------------------------------------------------------------------

public class Consuption { // класс с реальными расходами

private float credit, auto, education, clothes, relax, med, otherCon;

public float getCredit() { return credit; }

public float getAuto() { return auto; }

public float getEducation() { return education; }

public float getClothes() { return clothes; }

public float getRelax() { return relax; }

public float getMed() { return med; }

public float getOtherCon() { return otherCon; }

}

//-----------------------------------------------------------------------------

public class Planning { // класс с планированием и расчетом бюджета

Family family = new Family();

Income income = new Income();

Consuption consuption = new Consuption();

public static String Balance = "Сбалансированный бюджет";

public static String Defical = "Дефицит";

public float differentIncomePay(){

return family.getPayPlan() - income.getPay();

}

public float differentIncomePension(){ return family.getPensionPlan() - income.getPension(); }

public float differentIncomeUnderwork(){ return family.getUnderworkPlan() - income.getUnderwork(); }

public float differentIncomeBenefit(){ return family.getBenefidPlan() - income.getBenefid(); }

public float differentIncomeDeposit(){ return family.getDepositPlan() - income.getDeposit(); }

public float differentConsuptionCredit(){return family.getCreditPlan() - consuption.getCredit();}

public float differentConsuptionAuto(){return family.getAutoPlan() - consuption.getAuto();}

public float differentConsuptionEducation(){return family.getEducationPlan() - consuption.getEducation();}

public float differentConsuptionClothes(){return family.getClothesPlan() - consuption.getClothes();}

public float differentConsuptionRelax(){return family.getRelaxPlan() - consuption.getRelax();}

public float differentConsuptionMed(){return family.getMedPlan() - consuption.getMed();}

public float differentConsuptionOtherCon(){return family.getOtherConPlan() - consuption.getOtherCon();}

public float SummaryIncome(){

return income.getDeposit() + income.getBenefid() +

income.getUnderwork() + income.getPension() + income.getPay();

}

public float SummaryConsuption(){

return consuption.getCredit() + consuption.getAuto() + consuption.getEducation() +

consuption.getClothes() + consuption.getRelax() + consuption.getMed() +

consuption.getOtherCon();

}

public String Finance(){

float allConsuption = differentConsuptionCredit() + differentConsuptionAuto() +

differentConsuptionEducation() + differentConsuptionClothes() + differentConsuptionRelax() +

differentConsuptionMed() + differentConsuptionOtherCon();

float allIncome = differentIncomePension() + differentIncomeUnderwork() +

differentIncomeBenefit() + differentIncomeDeposit();

if(allIncome>=allConsuption) return Balance;

return Defical;

}

}