Автор Анна Евкова
Преподаватель который помогает студентам и школьникам в учёбе.

Моделирование предметной области «Транспортная доставка заказов» с помощью UML (Предлагаемые мероприятия по улучшению технологии решения задачи)

Содержание:

Введение

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

Цель курсовой работы – моделирование предметной области «Транспортная доставка заказов» с помощью UML

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

1. Описать предметную область «Транспортная доставка заказов»

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

3. Провести моделирование предметной области «Транспортная доставка заказов» с помощью объектно-ориентированного подхода к проектированию

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

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

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

Согласно статистическим данным перевозка более половины всех грузов на территории РФ осуществляется автомобильным транспортом. Поэтому в курсовой работе при описании предметной области «Транспортная доставка заказов» будем опираться на документационный оборот, используемый в автомобильных перевозках.

Правовое регулирование грузового автотранспортного сообщения в России регулируются постановлением Правительство РФ № 272 от 15 апреля 2011 года, которое утвердило новые Правила перевозок грузов автомобильным транспортом. Данное постановление регулирует отношения между перевозчиками, грузоотправителями, грузополучателями и другими участниками процесса транспортировки.

Основными документами этого процесса являются:

1. Перевозка груза осуществляется на основании договора перевозки груза. Заключение договора перевозки груза подтверждается транспортной накладной.

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

Товарно-транспортная накладная (далее – ТТН) оформляется в двух случаях:

  • при перевозке товарно-материальных ценностей силами автотранспортной компании;
  • при перевозке товарно-материальных ценностей самим грузоотправителем.

Картинки по запросу транспортная накладная

Рисунок – Образец транспортной накладной

Транспортную накладную в обязательном порядке подписывает грузоотправитель и перевозчик. Ее заверяют печатями перевозчик и грузоотправитель.

Использования ТТН в электронном виде не представляется возможным. В соответствии с Приказом ФНС РФ от 29.06.2012 года №ММВ-7-6/465@ транспортные накладные могут быть направлены в налоговый орган только в виде сканированных копий.

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

договор фрахтования образец

Рисунок – Образец договора фрахтования

В договор фрахтования должны включаться следующие пункты:

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

3. При определенных обстоятельствах участники транспортного процесса вынуждены оформлять акты (Рисунок 3).

http://allzakon.ru/wp-content/uploads/2018/11/Akt_o_povrezhdenii_gruza__obrazec_i_blank_2018_goda_1.jpg

Рисунок – Образец акта о повреждении груза

В соответствии с Правилами акты составляются в случаях если (п. 79 Правил):

  • груз не вывезен по вине перевозчика;
  • транспортное средство и контейнер под погрузку не предоставлены;
  • утрата или недостача груза, повреждения (порчи) груза;
  • груз для перевозки не предъявлен;
  • фрахтователь отказался от пользования транспортным средством;
  • доставка груза просрочена;
  • транспортные средства задержаны или простаивают

Акт, должен обязательно должен содержать (п. 82 Правил) следующие пункты :

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

Анализирую постановление Правительства РФ № 272, и документы которыми регулируется «Правил перевозок грузов автомобильным транспортом», можно выделить участников процесса «Транспортная доставка заказов»

В «Транспортной доставке заказов» участвуют четыре стороны (Рисунок 4):

  • грузоотправитель,
  • логист,
  • грузоперевозчик
  • грузополучатель.

Рисунок – Участники процесса «Транспортная доставка грузов»

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

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

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

Процесс доставки грузов можно разделить на три этапа (Рисунок 5):

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

2. Второй этап – перевозка груз – это этап транспортировки груза в место, указанное в заявке.

3. Третий этап – разгрузка груза. После доставки груза транспортное средство разгружают.

После выполнения трех этапов «Транспортная доставка заказов» является завершенной.

Рисунок – Общая схема «Транспортной доставки заказов»

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

  • сотрудники
  • материально-техническое обеспечение (Рисунок 6).

Рисунок – Общая схема работы транспортной компании

Процесс, который будет автоматизироваться это первый этап Транспортной доставки грузов, а именно прием груза (Рисунок 7). Прием заказа на транспортную доставку является одной из обязанностей логиста.

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

В любой из этих документов понадобиться внести следующие данные:

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

Рисунок – Процесс оформления заказа на транспортную доставку заказов

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

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

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

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

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

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

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

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

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

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

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

1. С точки зрения планирования работы предприятия выделяют следующие модели:

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

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

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

3. С точки зрения релевантности содержания модели делятся на (Рисунок 8) :

  • Модель «Как есть» («AS IS»): отражает реальное состояние дел во время описания, фактически существующих бизнес процессов предприятия.
  • Модель «Как должно быть» («TO BE»): отражает целевое состояние, которое в будущем предполагается реализовать. Например, модель вновь открытого предприятия или новый (совершенно новый или улучшенный старый) порядок выполнения любой работы.
  • Модель «Как должно бы быть» (английский «SHOULD BE»): отражает «идеализированное» положение дел (например, согласно нормативным документам, тогда как фактическая схема работы в действительности может быть несколько иной). На практике необходимость создания таких моделей встречается редко.

http://poznayka.org/baza1/608564128345.files/image021.jpg

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

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

UML (Рисунок 9) - это объектно-ориентированный язык со следующими характеристиками:

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

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

Картинки по запросу uml логотип

Рисунок – Логотип языка UML

Основными понятиями языка UML являются:

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

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

3. Модель - объект, отображающий наиболее значимые для конкретной задачи характеристики системы. Модели бывают разные – нематериальные и материальные, естественные и искусственные, математические и декоративные.

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

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

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

  1. Rational Rose
  2. Microsoft Visio
  3. Sybase PowerDesigner
  4. Case Complete
  5. Artiso Visual Case

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

1 Rational Rose

Rational Rose (Рисунок 10) - CASE-средство фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации [3]. Rational Rose использует синтез-методологию объектно-ориентированного анализа и проектирования.

Похожее изображение

Рисунок - Логотип Rational Rose

Основной вариант - Rational Rose/C++ - позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на С++.

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

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

2 Microsoft Visio

Microsoft Visio — векторный графический редактор, редактор диаграмм и блок-схем для Windows. Выпускается в трёх редакциях: Standard, Professional и Pro for Office 365 (Рисунок 12[12].

Картинки по запросу Microsoft Visio логотип

Рисунок - Логотип Microsoft Visio

Visio предоставляет множество различных объектов, с которыми можно взаимодействовать. Они организованы в виде иерархии, которая точно соответствует пользовательскому интерфейсу. [17]

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

После ознакомления с программными продуктами для разработки автоматизированных информационных систем и для определения среды разработки для практической части курсовой работы были выделены около 30 критериев. Критерии сгруппированы следующим образом (Таблица 1)

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

— Экспорт – должны быть доступны разные форматы экспорта. Шаблоны документов должны легко модифицироваться..

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

— Минимизация рутины - инструмент делает некоторые вещи сам – например, генерируем тест-кейсы, объектный дизайн из БД, куски кода.

Таблица 1 Сравнение CASE-средств

Программный продукт/

Критерии

Проектирование системы

Экспорт

Удобство пользования

Минимизация рутины

Rational Rose

+

-

+

-

Microsoft Visio

+

+

+

-

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

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

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

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

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

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

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

Связь – взаимодействие действующих лиц и соответствующих вариантов использования [3].

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

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

Таблица 2. Описание диаграммы вариантов использования

Варианты использования

Оформление документов, Оформление заявки, оплата перевозки, Проверка возможности оплаты груза.

Основные актеры

Логист, Грузоотправитель

Краткое описание

Грузоотправитель приходит в транспортную компанию отправить груз. Логист оформляет груз. Формируются ТТН и чек

Цель

Более качественное и быстрое обслуживание грузоотправителей. Формирование базы данных грузоотправителей.

Диаграмма последовательности (англ. sequence diagram) — диаграмма, на которой для некоторого набора объектов на единой временной оси показан жизненный цикл какого-либо определённого объекта (создание-деятельность-уничтожение некой сущности) и взаимодействие акторов (действующих лиц) ИС в рамках какого-либо определённого прецедента (отправка запросов и получение ответов). Используется в языке UML. [6]

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

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

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

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

Используются следующие условные обозначения:

  • Круг, обозначающий начальное состояние.
  • Окружность с маленьким кругом внутри, обозначающая конечное состояние (если есть).
  • Скруглённый прямоугольник, обозначающий состояние. Верхушка прямоугольника содержит название состояния. В середине может быть горизонтальная линия, под которой записываются активности, происходящие в данном состоянии.
  • Стрелка, обозначающая переход. Название события (если есть), вызывающего переход, отмечается рядом со стрелкой. Охраняющее выражение может быть добавлено перед «/» и заключено в квадратные скобки (название_события[охраняющее_выражение]), что значит, что это выражение должно быть истинным, чтобы переход имел место. Если при переходе производится какое-то действие, то оно добавляется после «/» (название_события[охраняющее_выражение]/действие).
  • Толстая горизонтальная линия с либо множеством входящих линий и одной выходящей, либо одной входящей линией и множеством выходящих. Это обозначает объединение и разветвление соответственно.

Рисунок – Диаграмма состояний

Далее разрабатываем диаграмму классу (Рисунок 17). Диаграмма классов (англ. Static Structure diagram) — диаграмма, демонстрирующая классы информационной ссистемы и взаимосвязи между ними. [9]

Существует два вида:

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

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

Существуют разные точки зрения на построение диаграмм классов в зависимости от целей их применения: [10]

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

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

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

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

Диаграммы деятельности состоят из ограниченного количества фигур, соединённых стрелками. Основные фигуры: [11]

  • Прямоугольники с закруглениями — действия
  • Ромбы — решения
  • Широкие полосы — начало (разветвление) и окончание (схождение) ветвления действий
  • Чёрный круг — начало процесса (начальное состояние)
  • Чёрный круг с обводкой — окончание процесса (конечное состояние)
  • Стрелки идут от начала к концу процесса и показывают последовательность переходов.

Заключение

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

Спроектированная информационная система позволит автоматизировать процесс оформление документов на доставку грузов и сократить время на оформление логистом транспортной компании.

Основные бизнес-процессы рассмотренные в курсовой работе, транспортная доставка заказов:

  • Оформление документов (ТТН),
  • Оформление заявки
  • оплата перевозки (формирование чека),
  • Проверка возможности оплаты груза.

На UML в среде MS Visio были разработаны следующие схемы:

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

Следующим этапом после проведения логического проектирования системы является физическое проектирование.

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

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

  1. Буч, Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ / Г. Буч. – М.: Бином, 2016. – 560 с.
  2. Буч, Г. Язык UML. Руководство пользователя / Г. Буч, Дж. Рамбо, А. Якобсон. - СПб.: Питер, 2014. - 432 с.
  3. Вендров, А.М. CASE-технологии. Современные методы и средства проектирования информационных систем / А.М. Вендров. – М. : Финансы и статистика, 1998. – 176 с.
  4. Википедия. [Электронный ресурс] ru.wikipedia.org. Режим свободного доступа. Дата обращения 25.09.2019
  5. ГОСТ Р ИСО/МЭК 12207–02. Информационная технология. Процессы жизненного цикла программных средств.
  6. Йордан, Э. Объектно-ориентированный анализ и проектирование систем / Э. Йордан, С. Аргила. - М.: Издательство «ЛОРИ», 2017. - 264 с.
  7. Ларман, К. Применение UML и шаблонов проектирования: Уч. Пос / К. Ларман. - М.: Издательский дом «Вильямс», 2015. - 496 с.
  8. Леоненков, А.В. Объектно-ориентированный анализ и проектирование с использованием UML / А.В. Леоненков. – www.intuit.ru.
  9. Маклаков, С.В. Создание информационных систем с AllFusion Modeling Suite / С.В. Маклаков. – М. : ДИАЛОГ-МИФИ, 2016. – 432 с.
  10. Петров, В.И. Информационные системы / В.Н. Петров. – СПб. : Питер, 2002. – 688 с.
  11. Фаулер, М. UML. Основы. Третье издание. / М. Фаулер. – М.: Символ-Плюс, 2016. – 192 с.
  12. Элиенс, А. Принципы объектно-ориентированной разработки программ / А. Элиенс. – М.: Издательский дом «Вильямс», 2012. – 496 с.
  13. Якобсон, А. Унифицированный процесс разработки программного обеспечения / А. Якобсон, Г. Буч, Дж. Рамбо. - СПб.: Питер, 2012. - 496 с.