Моделирование предметной области «Управление домашними финансами» с помощью UML»

Содержание:

Введение

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

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

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

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

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

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

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

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

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

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

Целью и задачей данной курсовой работы является исследование выбранной мной предметной области и получение практических навыков создания UML-моделей.

• Описание предметной области

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

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

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

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

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

1 Язык моделирования UML

1.1 Общие сведения

Многие методы объективно-ориентированного анализа и проектирования включают как язык программирования, так и описание процесса моделирования. Язык моделирования – это нотация (в основном представленная в графическом виде), которая используется методом для описания проектов. Нотация — это совокупность графических объектов, которые применяются в моделях. Нотация является синтаксисом языка моделирования. К примеру, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия как ассоциация, класс и множественность.

Процесс – это описание шагов, которые необходимо выполнить при разработке проекта.

Унифицированный язык моделирования UML (Unified Modeling Language) – язык моделирования, создание которого началось в конце 1994 года.

При разработке языка UML были выделены следующие цели:

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

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

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

• обеспечить формальную основу для понимания этого языка моделирования;

(язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

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

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

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

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

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

Важным качеством объектного подхода является согласованность моделей деятельности организации и моделей проектируемой системы от стадии формирования требований до стадии реализации.^[2] Требование согласованности моделей выполняется благодаря возможности применения абстрагирования, модульности, полиморфизма на всех стадиях разработки. Модели ранних стадий могут быть непосредственно подвергнуты сравнению с моделями реализации.^[3] По объектным моделям может быть прослежено отображение реальных сущностей моделируемой предметной области (организации) в объекты и классы информационной системы.^[4]

1.2 История создания языка UML

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

За короткий промежуток времени с 1989 года по 1994 год, количество объектно-ориентированных инструментов выросло с десятка до полусотни. Многие разработчики затруднялись подобрать язык моделирования, который полностью отвечал бы всем их потребностям для достижения необходимого результата. В результате выделилось новое поколение методов разработки, среди, которого особую популярность приобрели метод Booch, созданный Якобсоном Object-Oriented Software Engineering (OOSE) и разработанный Рамбо Object Modeling Technique (OMT).

Разработка UML началась в октябре 1994 года. Гради Буч и Джеймс Рамбо из компании Rational Software начали совместную работу по унифицированию таких методов как Booch и OMT. Данные два метода развивались независимо друг от друга и считались одними из лучших методов объектно-ориентированного подхода в разработке программных систем. Booch был ориентирован на проектирование программных систем, а OMT на анализ. Было принято решение объединить эти два метода и уже в октябре 1995 года, спустя год после начала разработки, вышла пробная версия нового языка (0.8), получившая название Unified Method.

Осенью 1995 года к компании Rational Software присоединился Ивар Якобсон, автор метода Object-Oriented Software Engineering — OOSE.

В конце 1996 года ряд крупных компаний были готовы рассмотреть UML в качестве основной стратегии своего бизнеса. В этом же году был основан некоммерческий консорциум OMG, который впоследствии объединил таких ведущих производителей программного обеспечения, как DEC, HP, IBM, Microsoft, Oracle, Rational Software и др.

В январе 1997 была выпущена новая версия UML 1.0. К OMG присоединились компании IBM, Objectime, Platinum Technology и Softeam. Результатом этого сотрудничества стал выпуск версии UML 1.1, который содержал улучшения нотации и некоторые расширения семантики.

В 2003 была выпущена версия 1.5.

Спецификация версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года.^[5]

1.3 Описание и структура языка

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) - язык графического описания для объектного моделирования в области разработки программного обеспечения. UML считается языком широкого профиля, так как это открытый общепринятый стандарт, использующий графические обозначения для создания абстрактной модели системы, называющейся UML-моделью. Данный язык был создан для определения, визуализации, проектирования и документирования программных систем.

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

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

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

1. Нотация языка UML представляет собой графическую нотацию для визуального представления семантики языка. Под графической составляющей и визуальным представлением языка подразумевается диаграммы UML. Подробнее тему диаграмм и их видов я затрону в следующем параграфе.^[6][7]
   1. Виды диаграмм

В данном параграфе речь пойдет о диаграммах UML, об их спецификациях и разновидностях.

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

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

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

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

• • • Диаграмма вариантов использования;
    • Диаграмма классов;
    • Диаграмма состояний;
    • Диаграммы взаимодействия;
    • Диаграмма деятельности;
    • Диаграмма пакетов;
    • Диаграмма компонентов;
    • Диаграмма размещения.

Подробное описание каждой диаграммы представлено ниже.^[8]

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

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

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

Вариант использования (use case).

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

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

Работая с вариантами использования необходимо следовать нескольким правилам:

1. У каждого варианта использования есть как минимум одно действующее лицо (пользователь).

2. У каждого варианта использования есть инициатор.

3. Каждый вариант использования приводит к результату и описывает конкретное действие.

Действующее лицо (actor).

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

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

Действующие лица имеют два типа связей с вариантами использования: простая ассоциация и направленная ассоциация. ^[9]

Простая ассоциация отображается линией между действующим лицом и вариантом использования, а направленная ассоциация показывает, что вариант использования инициируется актером и обозначается стрелкой. ^[10]

Ниже на схеме я представил пример диаграммы вариантов использования. (см. рисунок 1 – Пример диаграммы вариантов использования) ^[11]

Рисунок 1 – Пример диаграммы вариантов использован

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

Диаграмма классов UML необходима для обозначения отношений классов и их экземпляров. Они необходимы для моделирования прикладной области.

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

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

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

Например, исходя из параметра видимости, элемент может быть:

- приватным (доступным только внутри класса, который задается символом "-" и отображается в виде квадрата);

-защищенным (доступным внутри класса, а так же внутри классов-наследников, задается символом "#", отображается в виде ромба);

-открытым (доступным всем, задается символом "+" и отображается в виде круга).

Структурно диаграмма классов представляет из себя таблицу разделенную на три раздела, в которых указываются имя, операции и атрибуты, о которых подробно было сказано выше.^[12]

1.3.3 Диаграммы состояний

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

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

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

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

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

Входное действие – поведение, которое выполняется когда переходит в данное состояние.^[13]

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

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

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

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

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

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

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

Деятельность (Activity) - это этап выполнения задачи, который сводится некоторому действию (Action), которое в свою очередь состоит из вычислений, приводящих к изменению состояния системы.

Обычно диаграмма деятельности состоит из: состояний деятельности/действий, переходов и элементов ветвления.

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

1.3.6 Диаграмма пакетов

Диаграмма пакетов (Package) - конструкция языка UML которая предназначена для упорядочивания моделей, а так же группировки классов.

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

1.3.7 Диаграмма компонентов

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

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

Для представления физических сущностей в языке UML используется термин - компонент.

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

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

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

1.3.8 Диаграмма размещения

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

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

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

2 Моделирование предметной области «Управление домашними финансами» с помощью UML

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

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

Если брать тему учета домашних финансов, то необходимо определиться, сколько действующих лиц будет в системе (людей использующих общий бюджет). ^[14]

Если необходим учет финансов для группы лиц, например это будет семья из трех человек, то в диаграмме вариантов использования необходимо создать три действующих лица. Если же бюджет личный, то действующее лицо будет одно. В моем случае, действующее лицо будет одно. ^[15]

Итого, в моей диаграмме вариантов использования будет одно действующее лицо и варианты использования, такие как "Создать транзакцию", "Добавить категорию расходов и доходов", "Сформировать отчет" и тд. Более наглядно я представил это на диаграмме ниже (см. рисунок 2 – диаграмма вариантов использования).^[16]

Рисунок 2 – Диаграмма вариантов использования

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

На диаграмме классов представлена ассоциация (связь) владельца программы управления финансами и его денежного счета. В данном случае именем класса будет считаться «счет», а атрибутом будет считаться «баланс», над которым можно провести три операции: «проверить баланс», «пополнить счет» и «снять деньги со счета». (см. рисунок 3 – диаграмма классов).^[17]

Рисунок 3 – Диаграмма классов

2.3 Диаграмма состояния

Что бы подробнее описать требуемые действия будущей программы, необходимо создать диаграмму состояний. В данном случае она включает себя описание процесса совершения транзакции и все варианты исхода данного действия. На диаграмме наглядно показано как происходит проверка и соотношение имеющихся средств со стоимостью покупки какого-либо товара. Любое действие в программе должно привести к конечному результату и диаграмма предусматривает необходимые варианты действий пользователя. Непосредственно сама диаграмма представлена ниже (см. рисунок 4 – диаграмма состояния).^[18]

Рисунок 4 – диаграмма состояния

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

Данная диаграмма отображает кооперацию связанных между собой компонентов. В данном случае на диаграмме показано, как компонент программы такие как «Транзакции», «Бюджеты», «Финансовые цели» и «Отчеты» взаимодействуют друг с другом. (см. рисунок 5 – диаграмма взаимодействия).

Рисунок 5 – диаграмма взаимодействия

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

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

Рисунок 6 – диаграмма деятельности

2.6 Диаграмма пакетов

Диаграмма пакетов отображает общую структуру будущей программы, показывает все компоненты системы и их отношения. (см. рисунок 7 – диаграмма пакетов).

Рисунок 7 – диаграмма пакетов

Заключение

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

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

Список литературы

1. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472
2. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений / Х. Гома - СПб.: ДМК Пресс, 2011. – С. 246
3. Фаулер М. UML. Основы / М. Фаулер - М.: Символ Плюс, 2004. – С. 302
4. Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование / Д. Арлоу - М.: Символ Плюс, 2006. – С. 320
5. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка / Д. Рамбо - СПб.: Питер, 2007. – С. 358
6. Боггс У., Боггс М. UML и Rational Rose 2002 / У. Боггс., М. Боггс - М.: Лори, 2004. – С. 264
7. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон - СПб.: Питер, 2002. – С. 448

1. Фаулер М. UML. Основы / М. Фаулер - М.: Символ Плюс, 2004. – С. 302 ↑

2. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472 ↑

3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка / Д. Рамбо - СПб.: Питер, 2007. – С. 358 ↑

4. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон - СПб.: Питер, 2002. – С. 448 ↑

5. Фаулер М. UML. Основы / М. Фаулер - М.: Символ Плюс, 2004. – С. 302 ↑

6. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472 ↑

7. Фаулер М. UML. Основы / М. Фаулер - М.: Символ Плюс, 2004. – С. 302 ↑

8. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон - СПб.: Питер, 2002. – С. 448 ↑

9. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон - СПб.: Питер, 2002. – С. 448 ↑

10. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472 ↑

11. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка / Д. Рамбо - СПб.: Питер, 2007. – С. 358 ↑

12. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472 ↑

13. Буч Г., Рамбо Дж., Якобсон И. Язык UML. Руководство пользователя / Г. Буч - СПб.: ДМК Пресс, 2007. – С. 472 ↑

14. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений / Х. Гома - СПб.: ДМК Пресс, 2011. – С. 246 ↑

15. Арлоу Д., Нейштадт А. UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование / Д. Арлоу - М.: Символ Плюс, 2006. – С. 320 ↑

16. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения / А. Якобсон - СПб.: Питер, 2002. – С. 448 ↑

17. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений / Х. Гома - СПб.: ДМК Пресс, 2011. – С. 246 ↑

18. Гома Х. UML. Проектирование систем реального времени, распределенных и параллельных приложений / Х. Гома - СПб.: ДМК Пресс, 2011. – С. 246 ↑