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

Содержание:

Введение

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

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

Прежде чем приступить к реализации автоматизированной системы управления (АСУ), необходимо четко определить назначение каждого компонента и выбрать метод реализации каждой из его функций. Функциональные аспекты компонентов проектируемой ИС удобно представлять в виде диаграмм использования UML (унифицированный язык моделирования). При разработке данного проекта использовался UML и Rational Rose – мощное CASE - средство, помогающее строить модели систем.

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

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

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

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

Предмет исследования – процесс моделирования предметной области.

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

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

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

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

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

Основные услуги, которые оказывает компания:

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

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

Логистика. Компания осуществляет маркетинговые и информационные а также консалтинговые услуги в области логистики для предприятий, организаций и ИП.

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

Организационная структура рассматриваемого предприятия является традиционной для коммерческих организаций и включает в себя следующие подразделения (рис.1):

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

Рис.1.1. Организационно-штатная структура управления

Модель функционирования склада (рисунок 1.2) показывает, что на склад поступают товарно-материальные ценности (ТМЦ) от поставщиков, и результатом деятельности склада является отгрузка товара потребителям [7, с.55].

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

Входные документы – накладная на внутреннее перемещение и приходная накладная.

Выходные документы – журнал отгрузок, журнал прихода, отчет по остаткам, отчет по качеству, отчет по инвентаризации.

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

Рис. 1.2. Контекстная диаграмма модели деятельности склада

Декомпозиция модели (рисунок 1.3) характеризует основные бизнес-процессы склада, такие как [8]:

• приемка товара;
• хранение товара;
• учет товаров на складе;
• комплектация и отгрузка;
• управление остатками на складе.

Рис. 1.3. Декомпозиция контекстной диаграммы

На рисунке 1.3 видно, что приемкой товара на складе занимается отдел снабжения, т.к. этот отдел занимается размещением заказа поставщику на производство и поставку товара. За комплектацию и отгрузку товара со склада отвечает руководство отдела сбыта, т.к. этот отдел занимается сбором заявок и распределением товаров. Также отдел сбыта принимает участие в процессе управления остатками. Бухгалтерия занимается приемкой и отгрузкой товара со склада с позиции ведения бухгалтерского учета.

Процессы приемки товара на склад, хранения, комплектации и отгрузки описаны на рисунках 1.4-1.7.

1. При поступлении машины с грузом, кладовщик проверяет товарно-транспортные накладные или прочие документы. Если документы оформлены в соответствии с требованиями компании, то принимается решение о начале разгрузки товара. В Журнале приемки грузов делается запись о прибытии машины, содержащая данные: дата, время прибытия машины, поставщик, наименование товара, номер накладной, фамилия кладовщика и менеджера, присутствовавшего при разгрузке, комментарий.

Рис.1.4. Декомпозиция бизнес-процесса «Приемка товаров на складе»

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

Рис.1.5. Бизнес-процесс «Приемка товаров на складе по качеству»

Бизнес-процесс хранения товара включает следующие действия (рисунок 1.6):

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

Рис.1.6. Декомпозиция бизнес-процесса «Хранение товара на складе»

Бизнес-процесс «Комплектация и отгрузка» (рисунок 1.7) характеризуется следующими положениями:

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

Рис.1.7. Декомпозиция бизнес-процесса «Комплектация и отгрузка товаров на складе»

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

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

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

Опишем основные функции, которые должна выполнять автоматизированная система [16, с.39]:

1. Ведение базы данных запчастей на складе (наименование, количество, цена и др.).
2. Ведение базы данных всех произошедших операций прихода-расхода.
3. Ведение справочников (товары, категории товаров, поставщики, сотрудники).
4. Получение аналитической и статистической информации (остатки на складе, данные по количеству произведенных операций, отчет за месяц).
5. Получение справочной информации в печатном виде (счет-фактура, накладная, наименование товаров, отчеты по продажам).

Задачи проектирования [14, с.67]:

1. Максимально упростить и ускорить процедуру учета материальных ценностей.
2. Обеспечить жесткую связь между складом и процедурой регистрации заказа для исключения ситуации оформления заказов на изделия при отсутствии соответствующих наименований на оперативном складе.
3. Обеспечить все бизнес - операции возможностью сопроводить их необходимыми документами.
4. Создать гибкую систему статистических отчетов, как по работе склада, так и по учету и регистрации заказов.
5. Обеспечить при необходимости возможность автоматического резервирования БД.
6. Запретить некорректные действия пользователя.
7. Обеспечить целостность информации в базе данных.
8. Обеспечить приемлемую безопасность данных на случай несанкционированного доступа.
9. Минимизировать затраты системных ресурсов, необходимых для нормальной работы АРМ.

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

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

В настоящее время унифицированный язык моделирования UML [5] является визуальным языком моделирования, который позволяет системным архитекторам представить свое видение системы в стандартной и легкой для понимания форме. Кроме того, UML представляет эффективный механизм совместного использования проектных решений и взаимодействия разработчиков друг с другом.

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

• • Диаграмма вариантов или прецедентов использования (use case diagram)
  • Диаграмма классов (class diagram)
  • Диаграммы поведения (behavior diagrams)
  • Диаграмма состояний (statechart diagram)
  • Диаграмма деятельности (activity diagram)
  • Диаграммы взаимодействия (interaction diagrams)
  • Диаграмма последовательности (sequence diagram)
  • Диаграмма кооперации (collaboration diagram)
  • Диаграммы реализации (implementation diagrams)
  • Диаграмма компонентов (component diagram)
  • Диаграмма развертывания (deployment diagram)

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

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

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

Преимущества от использования:

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

- ускорение разработки;

- увеличение продуктивности.

Поскольку проектируемый АРМ будет состоять из программного приложения и базы данных, целесообразным является разработать диаграмму вариантов использования, диаграммы последовательностей и кооперативную диаграмму средствами JUDE. Разработка базы данных будет производится специализированным case-средством с возможностью генерации исходного кода – ER Win.

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

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

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

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

Разработка данной диаграммы преследует следующие цели:

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

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

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

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

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

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

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

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

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

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

• информационные (informative) – сообщения, снабжающие объект-получатель информацией для обновления его состояния;
• сообщения – запросы (interrogative) – сообщения, запрашивающие выдачу информации об объекте-получателе;
• императивные (imperative) – сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

• последовательности (sequence diagrams);
• кооперативные (collaboration diagrams).

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

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

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

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

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

Рис. 2.2. Диаграмма вариантов использования модуля «ЗИП»

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

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

Дополнительные требования к АРМу: разграничение уровней доступа (в частности руководитель площадки должен иметь права на регистрацию и просмотр заявок, а инженер по снабжению права на закрытие заявок и т.п.).

Диаграмма вариантов использования (Use case diagram)

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

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

Диаграммы взаимодействия (interaction diagrams)

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

Существует два вида диаграмм взаимодействия: диаграммы последовательности (Sequence diagrams) и диаграммы кооперации (collaboration diagrams).

Диаграммы последовательности

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

Рис.2.5. Диаграмма последовательности: составление заявки на ЗИП

Диаграммы сотрудничества

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

Рис. 2.6. Диаграмма сотрудничества

Диаграммы активности (Activity diagrams)

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

Рис. 2.7. Диаграмма активности

Проектирование базы данных реализовано при помощи CASE-средства ErWin версии 7.3. С его помощью сначала строится логическая модель базы данных, соответствующая структуре бизнес-процесса, который построен другим CASE-средством JUDE COMMUNITY. Логическая модель показана на рис.2.8.

Рис.2.8. Логическая модель

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

В сущности «Группа» от ключа «идентификационный_номер_группы» зависят атрибуты: «название», «доплнительная_информация», «идентификатор_для_авторизации», «пароль_для_авторазации», «роль_в_системе». В сущности «Резерв» от ключа «id_резерва» зависят атрибуты: «какая_группа_эксплуатирует», «количество_системных_блоков», «количество_мониторов», «количество_матричных_принтеров», «количество_лазерных_принтеров», «количество_клавиатур», «количество_мышей», «количество_хабов», «количество_сетевых_карт», «количество_патчкордов», «количество_ИБП». В сущности «Заказ» от ключа «идентификационный_номер_заказа» зависят атрибуты: «какой_ЗИП_входит», «какая_группа_заказывает», «количество», «дата_поступления_заявки», «дата_закрытия_заявки», «дополнителная_информация». В сущности «ЗИП» от ключа «идентификационный_номер_ЗИП» зависят атрибуты: «наименование», «код», «наименование_единиц_исчисления», «количество». В сущности «Техника» от ключа «id_техники» зависят атрибуты: «какая_группа_эксплуатирует», «тип_устройства», «модель», «серийный_номер», «инвентарный_номер»,» балансовая_принадлежность». В сущности «Ремонт» от ключа «id_ремонта» зависят атрибуты: «какая_техника_отправлена»,«группа_эксплуатирующая_отправленную_технику», «неисправность», «дата_отправки_с_площадки», «дата_поступления_на_площадку», «дата_отправки_в_ремонт», «дата_получения_из_ремонта», «результат_ремонта», «эксплуатация».

Отношения между сущностями «Группа» и «Резерв», «Группа» и «Заказ», «Группа» и «Техника», «Техника» и «Ремонт», «ЗИП» и «Заказ» представляют собой связи один ко многим.

Заключение

Главной целью работы было моделирование деятельности отдела снабжения по управлению логистическими процессами. Для разработки данной системы был использован унифицированный язык моделирования UML и Jude Community – case-средство, помогающее строить модели UML.

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

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

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

1. Бритов Г., Осипова Т. Моделирование бизнес-процессов. - М.:LAP, 2014. – 124 с.
2. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб.:Питер, 2015. – 368 с.
3. Голицына, О.Л. Базы данных: Учебное пособие / О.Л. Голицына, Н.В. Максимов, И.И. Попов. - М.: Форум, 2012. - 400 c.
4. Давыдова Е. М. Базы данных Учеб. пособие для вузов / Е. М. Давыдова, Н. А. Новгородова. - 3-е изд., перераб. и доп. - Томск : В-Спектр, 2012. - 128 с.
5. Данелян Т.Я. Организация и функционирование больших информационных систем. – М.: МЭСИ, 2007
6. Дейт К.Дж. Введение в системы баз данных. - К.: Диалектика, 2012. - 360 c.
7. Илюшечкин В. Основы использования и проектирования баз данных. Учебник. - М.:Юрайт, 2014. - 214с.
8. Информационные системы в экономике /Под ред. В.В. Дика. - М.: Финансы и статистика, 2006.
9. Исаев Г. Проектирование информационных систем. Учебное пособие. - М.: Омега-Л, 2015. - 432с.
10. Карпова, И.П. Базы данных: Учебное пособие / И.П. Карпова. - СПб.: Питер, 2013. - 240 c.
11. Кириллов, В.В. Введение в реляционные базы данных.Введение в реляционные базы данных / В.В. Кириллов, Г.Ю. Громов. - СПб.: БХВ-Петербург, 2012. - 464 c.
12. Коваленко В. Проектирование информационных систем. - М.: Форум, 2012. - 320с.
13. Крис Дейт. Введение в базы данных, 6-е изд. Киев, Диалектика, 1998.
14. Лешек А. Мацяшек. Анализ требований и проектирование систем. Разработка информационных систем с использованием UML. — Москва-Санкт-Петербург-Киев: Вильямс, 2002.
15. Маклаков С.В. CASE-средства разработки информационных систем. – М.:ДИАЛОГ МИФИ, 2001. – 304 с.
16. Мартин Фаулер и Кендалл Скотт, UML. Основы.- СПб: Символ-Плюс, 2002
17. Розенберг Д, Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.— Москва: ДМК-издательство, 2002.