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

Кратность атрибута характеризует количество значений, которые можно хранить в атрибуте. Если кратность атрибута не указана, то по умолчанию принимается ее значение, равное 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();}