МОДЕЛИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ «УЧЕТ ТОВАРОВ » С ПОМОЩЬЮ UML

Содержание:

Введение

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

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

На сегодняшний день в качестве средства, реализующего методологию процессного подхода к программирования, чаще всего применяется язык моделирования UML [2, 3].

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

Объектом исследования является склад товарной продукции.

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

Цель работы – осуществить моделирование предметной области «Учет товаров» при помощи UML.

Для достижения поставленной цели необходимо выполнить следующие задачи:

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

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

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

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

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

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

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

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

Актуальность разработки процессной модели информационной подсистемы для учета движения товаров на складе аргументирована применением языка UML (Unified Modeling Language).

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

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

В качестве среды разработки информационной подсистемы был выбран программный продукт Rational Rose.

В результате проектирования должна быть получена процессная модель информационной подсистемы для учета движения товаров на складе [6, c.55]. Модель будет включать в себя:

- диаграмму вариантов использования;

- диаграмму последовательности;

- диаграмму сотрудничества;

- диаграмму классов;

- диаграмму состояний;

- диаграмму компонентов.

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

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

- первый этап - проверка операций с материальными ценностями;

- второй этап - инвентаризация товарно-материальных ценностей.

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

Во-первых, упростить оформление операций по приходу и расходу товарно-материальных ценностей [7, c.87].

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

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

Решение этих и прочих проблем даст возможность наладить более действенный и менее трудоемкий учет и аудит за наличием, движением и использованием материальных ресурсов, а также достичь их экономии.

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

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

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

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

Осуществленные исследования дают возможность предложить определенные рекомендации по увеличению эффективности функционирования предприятия:

- контроль за соблюдением условий договоров;

- ввиду уменьшения себестоимости продукции идентифицировать внутренние резервы по ее снижению [10, c.76].

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

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

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

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

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

Далее нужно сопоставить несколько CASE-средств и выбрать самое оптимальное. В данной работе целесообразно сравнить самые популярные CASE-средства: Borland Together, MS Visio, Rational Rose. Данные продукты поддерживают нотацию UML 2.0.

Преимуществом MS Visio является тот факт, что этот продукт распространяется как надстройка к MSOffice. Размер дистрибутива у данного продукта не очень большой, что дает возможность скачать его с сайта разработчика без существенных затрат [15, c.65].

Недостатком MS Visio является то, что оно поддерживает не все диаграммы нотации UML 2.0. Еще один минус - это отсутствие технической поддержки пользователей. Существенным достоинством является тот факт, что можно применять нестандартные графические примитивы.

CASE-средство Rational Rose является коммерческой разработкой компании IBM. Последняя версия этого продукта поддерживает нотацию UML 2.0 в полном объеме [17, c.44]. При установке пакета разработчику предоставляется немало утилит и сопутствующих продуктов, упрощающих разработку систем. Также в пакете можно генерировать исходный код приложения на основе моделей. Из преимуществ также выделяется очень красивый интуитивно понятный и эргономичный интерфейс продукта.

Недостатком является слишком высокая цена за лицензионную копию продукта.

CASE-средство Borland Together идет в комплекте с пакетом Borland Developer Studio. Этот пакет направлен на создание приложений на языках Delphi, C++ и Java. Интегрированное CASE-средство в данный пакет дает возможность разрабатывать модели и генерировать исходный код из диаграммы классов. Данный пакет изначально ориентирован на написание исходного кода приложения, его компиляцию и отладку. Функции разработки моделей в данном пакете являются дополнительными [20, c.54].

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

В идеальном случае для разработки моделей и осуществления моделирования предметной области целесообразно применять CASE-средство от компании IBM - Rational Rose.

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

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

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

Элементы диаграммы:

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

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

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

Рисунок 2.1 - Диаграмма прецедентов

В качестве актеров на диаграмме (рисунок 2.1) используются объекты:

- «zav_sklad» (заведующий складом), управляющий вариантами использования:

- «oborot_mes» (оборот за месяц);

- «reviziya» (ревизия);

- «klad» (кладовщик), управляющий следующими вариантами использования:

- «get_tovar» (принять товар);

- «send_tovar» (отправить товар);

- «inventar» (инвентаризация).

Между вариантами использования и действующими лицами используется связь коммуникации (communication). Направление стрелки дает возможность понять, кто инициирует коммуникацию.

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

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

В диаграммах последовательности действий взаимодействие объектов в системе осуществляется путем приема и передачи сообщений объектами-клиентами и обработки данных сообщений объектами-серверами. В данном случае в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов [20, c.54].

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия именуется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в ходе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, помимо всего прочего, отразить самоделегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни [22, c.89].

В этой модели для создания диаграммы последовательности был использован вариант использования «get_tovar» (принять товар), взятый из предыдущей диаграммы прецедентов (рисунок 2.2).

Рисунок 2.2 - Диаграмма последовательности «get_tovar» (принять товар)

На данную диаграмму помещены следующие объекты:

- «klad» (кладовщик) - действующее лицо;

- «Add/Select Tovar Form» - содержит форму ввода или выбора товара;

- «Add/Select Postav Form» - содержит форму ввода или выбора поставщика товара;

- «Card Sklad_Uchet» - форма карты складского учета, которая создается после ввода всех данных и является итоговым документом;

- «DataBase» - содержит информацию о поставщиках и товарах, на основании информации этого объекта формируется карта складского учета

Сообщения между объектами на диаграмме:

- «Open» - открыть форму;

- «Cancel» - отмена действия;

- «Query to DataBase» - запрос к базе данных на выбор товара;

- «Answer from DataBase» - наименование товара;

- «Query to DataBase on generation Sklad_Uchet card» - запрос к базе данных на выбор поставщика и генерацию карты складского учета;

- «Generate» - карта складского учета.

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

Вторым видом диаграммы взаимодействия является кооперативная диаграмма (collaboration diagram).

Подобно диаграммам последовательности, кооперативные диаграммы отображают поток событий через конкретный сценарий варианта использования. Кооперативные диаграммы заостряют внимание на взаимосвязях вообще, то есть на них отражается наличие сообщений от клиентов к серверам [3, c.6].

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

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

Согласно созданной выше диаграмме «get_tovar» (принять товар), была создана диаграмма сотрудничества (рисунок 2.3).

На диаграмме расположены объекты:

- «sklad»;

- «Add/Select Tovar Form»;

- «Add/Select Postav Form»;

- «Card Sklad_Uchet»;

- «DataBase».

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

Была создана диаграмма сотрудничества «get_tovar» (принять товар), на которой представлена вся та информация, которая была и на диаграмме последовательности, но кооперативная диаграмма по-другому описывает поток событий. Из нее легче понять связи между объектами, однако труднее разобраться в последовательности событий [24, c.55].

Рисунок 2.3 - Диаграмма сотрудничества для варианта использования «get_tovar» (принять товар)

Диаграммы классов (class diagram) позволяет создавать логическое представление системы, на основе которого создается исходный код описанных классов. Значки диаграммы позволяют отображать сложную иерархию систем, взаимосвязи классов (сlasses) и интерфейсов (interfaces). На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Данный тип диаграмм противоположен по содержанию диаграмме сотрудничества, на которой отображаются объекты системы [9, c.114].

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

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

Рисунок 2.4 - Главная диаграмма классов информационной подсистемы

Внутри каждого пакета также имеется «главная диаграмма», включающая в себя все классы этого пакета (рисунок 2.5, 2.6).

Рисунок 2.5 - Диаграмма классов «form»

Рисунок 2.6 - Диаграмма классов «DataBase»

После создания главой диаграммы классов создается диаграмма классов для сценария «get_tovar» (принять товар), на которой отражаются все классы, атрибуты и связи между ними (рисунок 2.7).

Рисунок 2.7 - Диаграмма классов «get_tovar» (принять товар)

На диаграмме классов «get_tovar» (принять товар) были представлены все классы и взаимосвязи между ними.

Указанная множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Так же были добавлены атрибуты и методы в некоторые классы [18, c.15].

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

На диаграмме имеются два специальных состояния - начальное (start) и конечное (stop). Процессы, происходящие в тот момент, когда объект находится в определенном состоянии, называются действиями (actions).

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

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

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

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

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

Событие (event) - это то, что вызывает переход из одного состояния в другое. Событие размещают на диаграмме вдоль линии перехода.

Большинство переходов должны иметь события, так как именно они, прежде всего, заставляют переход осуществиться [10, c.41].

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

В данном курсовом проекте диаграмма состояний создается для варианта использования «get_tovar» (принять товар). Она представлена на рисунке 2.8.

Рисунок 2.8 - Диаграмма состояний для варианта использования «get_tovar» (принять товар)

На диаграмме состояний расположены следующие состояния:

- начальное состояние «Start»;

- конечное «exit» состояние;

- «Initialization» (инициализация);

- «SomeStop» (выполнение приостановлено);

- «Cancel» (отменен);

- «Get» (выполнен).

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

- «StoreDate» (сохранить дату) на входе для состояния «Initialization» (инициализация);

- «Info Tovar» (собрать информацию о товаре и поставщиках);

- «Add» (добавить к набору товаров);

- «StoreData» (сохранить дату отмены) на выходе;

- «Card Ucheta» (карта учета) - на выходе формируется складская карта учета.

Диаграммы компонентов (component diagram) предназначены для распределения классов и объектов по компонентам при физическом проектировании системы. На них изображены компоненты программного обеспечения и связи между ними [6, c.11]. При этом на такой диаграмме выделяют два типа компонентов: исполняемые компоненты и библиотеки кода. Часто данный тип диаграмм называют диаграммами модулей.

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

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

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

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

На рисунке 2.9 показаны компоненты пакета «Form». Они содержат классы пакета «Form» логического представления системы.

Рисунок 2.9 - Диаграмма компонентов пакета «Form»

На рисунке 2.10 показаны компоненты пакета «DataBase». Они содержат классы пакета «DataBase» логического представления системы.

Рисунок 2.10 - Диаграмма компонентов пакета «DataBase»

Общая диаграмма компонентов для рассматриваемого варианта использования «get_tovar» (принять товар) на рисунке 2.11.

Рисунок 2.11 - Диаграмма компонентов для варианта использования «get_tovar» (принять товар)

Так как система разрабатывается на языке C++, то у каждого класса имеется свой собственный заголовочный файл и файл с расширением *.cpp.

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

Заключение

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

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

- диаграмма вариантов использования;

- диаграмма последовательности;

- диаграмма сотрудничества;

- диаграмма классов;

- диаграмма состояний;

- диаграмма компонентов.

В качестве среды разработки информационной подсистемы был использован программный продукт Rational Rose 2000 Enterprise v6.5.

Список использованных источников

1. Бабич, А. В. UML. Первое знакомство. Пособие для подготовки к сдаче теста UMO-100 (OMG Certified UML Professional Fundamental) (+ CD-ROM) / А.В. Бабич. - М.: Бином. Лаборатория знаний, 2008. - 176 c.

2. Боггс, М. UML и Rational Rose / М. Боггс. - Москва: РГГУ, 2010. - 385 c.

3. Бородакий, Ю. В. Эволюция информационных систем / Ю.В. Бородакий, Ю.Г. Лободинский. - Москва: СИНТЕГ, 2011. - 368 c.

4. Буч, Гради Введение в UML от создателей языка / Гради Буч , Джеймс Рамбо , Ивар Якобсон. - М.: ДМК Пресс, 2015. - 496 c.

5. Буч, Грейди Язык UML. Руководство пользователя / Грейди Буч , Джеймс Рамбо , Айвар Джекобсон. - М.: ДМК, 2015. - 432 c.

6. Гома, Хассан UML. Проектирование систем реального времени, параллельных и распределенных приложений / Хассан Гома. - М.: ДМК Пресс, 2016. - 700 c.

7. Грекул, В. И. Управление внедрением информационных систем / В.И. Грекул, Г.Н. Денищенко, Н.Л. Коровкина. - Москва: РГГУ, 2014. - 224 c.

8. Гультяев, А. К. Проектирование и дизайн пользовательского интерфейса / А.К. Гультяев, В.А. Машин. - М.: Корона-Принт, 2010. - 350 c.

9. Данелян, Т. Я. Экономические информационные системы (ЭИС) предприятий и организаций / Т.Я. Данелян. - М.: Юнити-Дана, 2015. - 284 c.

10. Зенков, В. В. Методы и алгоритмы компьютерной обработки геологической и маркшейдерской информации. Практика обработки заводских данных / В.В. Зенков, О.А. Поляков, В.Е. Юрченко. - М.: Ленанд, 2013. - 268 c.

11. Йордон, Эдвард Объектно-ориентированный анализ и проектирование систем / Эдвард Йордон , Карл Аргила. - М.: ЛОРИ, 2014. - 264 c.

12. Карпов, Ю. Г. Model Checking. Верификация параллельных и распределенных программных систем (+ CD-ROM) / Ю.Г. Карпов. - М.: БХВ-Петербург, 2010. - 552 c.

13. Киммел, Пол UML. Основы визуального анализа и проектирования / Пол Киммел. - М.: НТ Пресс, 2008. - 272 c.

14. Коберн, Алистер Современные методы описания функциональных требований к системам / Алистер Коберн. - Москва: Машиностроение, 2012. - 264 c.

15. Ларман, Крэг Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку / Крэг Ларман. - М.: Вильямс, 2013. - 736 c.

16. Лоусон, Гарольд Путешествие по системному ландшафту: моногр. / Гарольд Лоусон. - М.: ДМК Пресс, 2016. - 368 c.

17. Льюис, Ф. Теоретические основы проектирования компиляторов / Ф. Льюис, Д. Розенкранц, Р. Стирнз. - М.: Мир, 2004. - 656 c.

18. Модели глобальной атмосферы и Мирового океана. Алгоритмы и суперкомпьютерные технологии. - Москва: Машиностроение, 2013. - 144 c.

19. Мюллер, Роберт Дж. Проектирование баз данных и UML / Мюллер Роберт Дж.. - М.: ЛОРИ, 2013. - 422 c.

20. Пайлон, Д. UML 2 для программистов / Д. Пайлон. - М.: Питер, 2012. - 198 c.

21. Приемы процессного проектирования. Паттерны проектирования / Э. Гамма и др. - Москва: СИНТЕГ, 2016. - 366 c.

22. Роберт, А. Максимчук UML для простых смертных / Роберт А. Максимчук, Эрик Дж. Нейбург. - Москва: СИНТЕГ, 2014. - 272 c.

23. Фаулер, Мартин UML. Основы. Краткое руководство по стандартному языку объектного моделирования / Мартин Фаулер. - Москва: СИНТЕГ, 2011. - 192 c.

24. Фельдман, Я. А. Создаем информационные системы (+ CD-ROM) / Я.А. Фельдман. - М.: Солон-Пресс, 2007. - 120 c.

25. Шилин, К. Ю. Макропроектирование компьютерных обучающих систем / К.Ю. Шилин. - М.: Издательский дом "Дело" РАНХиГС, 2013. - 184 c.