Моделирование бизнес-процесса организации перевозок транспортно-логистической компанией

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

Объектно-ориентированная методология (ООМ) создания автоматизированных систем состоит из следующих частей:

· объектно-ориентированный анализ (OOA),

· объектно-ориентированное проектирование (OOD),

· объектно-ориентированное программирование (OOР).

ООА - методология анализа сущностей реального мира на основе понятий класса и объекта, составляющих словарь предметной области, для понимания и объяснения того, как они (сущности) взаимодействуют между собой.

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

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

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

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

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

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

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

Атрибут - поименованное свойство класса, определяющее диапазон допустимых значений, которые могут принимать экземпляры данного свойства. Атрибуты могут быть скрыты от других классов, это определяет видимость атрибута: рublic (общий, открытый); private (закрытый, секретный); protected (защищенный).

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

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

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

Между элементами объектной модели существуют различные виды связей:

· ассоциация - это семантическая связь между классами;

· агрегация - более сильный тип связи между целым и его частями;

· зависимость - связь между двумя элементами модели, при которой изменения в спецификации одного элемента могут повлечь за собой изменения в другом элементе;

· обобщение - связь «тип - подтип».

Метод объектно-ориентированного проектирования основывается на:

· модели построения системы как совокупности объектов абстрактного типа данных;

· модульной структуре программ;

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

В объектно-ориентированном проектировании выделяют следующие фундаментальные понятия:

Инкапсуляция.

Концепция сокрытия в как бы "капсуле" всей информации об объекте, то есть объединение в некое целое данных и процедур (методов) их обработки. Единицей инкапсуляции в OOD является объект, в котором содержатся и данные состояния объекта и сообщения, которые объект может обрабатывать. Т.е. Инкапсуляция означает сочетание структур данных с методами их обработки в абстрактных типах данных - классах объектов.

Наследование.

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

Полиморфизм.

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

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

· объект описывается как модель некоторой сущности реального мира;

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

Выделено четыре этапа объектно-ориентированного проектирования:

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

· разработка структуры классов, описывающей связь между классами и объектами;

· разработка диаграмм объектов, показывающих взаимосвязи с другими объектами;

· разработка внутренней структуры программного продукта.

История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя сами по себе эти методы были достаточно популярны, совместная работа была направлена на изучение всех известных объектно-ориентированных методов с целью объединения их достоинств. При этом Г. Буч и Дж. Румбах сосредоточили усилия на полной унификации результатов своей работы. Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя предыдущими.

Вначале авторы методов Booch, ОМТ и OOSE предполагали разработать унифицированный язык моделирования только для этих трех методик. С одной стороны, каждый из этих методов был проверен на практике и показал свою конструктивность при решении отдельных задач ООАП. Это давало основание для дальнейшей их модификации на основе устранения имеющегося несоответствия отдельных понятий и обозначений. С другой стороны, унификация семантики и нотации должна была обеспечить некоторую стабильность на рынке объектно-ориентированных CASE-средств, которая необходима для успешного продвижения соответствующих программных инструментариев. Наконец, совместная работа давала надежду на существенное улучшение всех трех методов.

Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Джекобсон сформулировали следующие требования к языку моделирования. Он должен:

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

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

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

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

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

1. Должна ли данная нотация включать в себя спецификацию требований?

2. Следует ли расширять данную нотацию до уровня языка визуального программирования?

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

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

В это же время стало ясно, что некоторые компании и организации видят в языке UML линию стратегических интересов для своего бизнеса. Компания Rational Software вместе с несколькими организациями, изъявившими желание выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому определению нотации, что привело к появлению версии 1.0 языка UML. В январе 1997 года был опубликован документ с описанием языка UML 1.0, как начальный вариант ответа на запрос предложений RTP. Эта версия языка моделирования была достаточно хорошо определена, обеспечивала требуемую выразительность и мощность и предполагала решение широкого класса задач.

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

Из более чем 800 компаний и организаций, входящих в настоящее время в состав консорциума OMG, особую роль продолжает играть Rational Software Corporation, которая стояла у истоков разработки языка UML. Эта компания разработала и выпустила в продажу одно из первых инструментальных CASE-средств Rational Rose 98, в котором был реализован язык UML.

В январе 1997 года целый ряд других компаний, среди которых были IBM, ObjecTime, Platinum Technology и некоторые другие, представили на рассмотрение OMG свои собственные ответы на запрос предложений RFP. В дальнейшем эти компании присоединились к партнерам UML, предлагая включить в язык UML некоторые свои идеи. В результате совместной работы с партнерами UML была предложена пересмотренная версия 1.1 языка UML. Основное внимание при разработке языка UML 1.1 было уделено достижению большей ясности семантики языка по сравнению с UML 1.0, а также учету предложений новых партнеров. Эта версия языка была представлена на рассмотрение OMG и была одобрена и принята в качестве стандарта OMG в ноябре 1997 года.

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

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

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

Унифицированный язык моделирования UML стал основой для целого спектра различных средств поддержки разработки программного обеспечения - CASE-средств (Computer-Aided Software Engineering).

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

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

К появлению CASE-технологии способствовали и такие факторы, как:

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

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

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

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

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

Все современные CASE-средства можно классифицировать по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы жизненного цикла. Помимо этого CASE-средства можно классифицировать по категориям, применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.

К основным достоинствам CASE-средств можно отнести:

· широкое разнообразие качества и возможностей CASE-средств;

· относительно небольшое время использования CASE-средств в различных организациях и недостаток опыта их применения;

· широкое разнообразие в практике внедрения различных организаций;

· отсутствие детальных метрик и данных для уже выполненных и текущих проектов;

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

· различная степень интеграции CASE-средств в различных проектах.

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

Но все же грамотное, продуманное и обоснованное использование CASE-технологии способно принести следующие выгоды:

· высокий уровень технологической поддержки процессов разработки и сопровождения ПО;

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

· приемлемый уровень отдачи от инвестиций в CASE-средства.

Среди всех фирм-производителей CASE-средств именно компания IBM Rational Software Corp. (до августа 2003 года - Rational Software Corp.) одна из первых осознала стратегическую перспективность развития объектно-ориентированных технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.

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

IBM Rational Rose - популярное средство визуального моделирования, которое считается стандартом де-факто среди средств визуального проектирования приложений. Этот продукт входит в состав пакета IBM Rational Suite и предназначен для моделирования программных систем с использованием широкого круга инструментальных средств и платформ. Инструментальное средство IBM Rational Rose расширяет возможности моделирования программных систем, выходящих за рамки платформы J2EE и инструментальных средств моделирования в составе IBM Rational Professional Bundle.

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

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

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

Rational Rose является ведущим инструментом визуального моделирования в программной индустрии, благодаря полноценной поддержке UML и многоязыковой поддержке командной разработки. Инструмент полностью поддерживает компонентно-ориентированный процесс создания ИС.

Достоинства продукта Rational Rose

· мощный графический язык моделирования предметной области, обладающий высоким уровнем формализации и поддерживающий объектно-ориентированную методологию;

· удобная навигация между элементами модели при помощи "инспектора проекта";

· хранение результатов проектирования в виде единой модели;

· поддержка работы над проектом группы разработчиков;

· данное CASE средство может быть применено для создания разнообразного объектно-ориентированного программного обеспечения, в первую очередь для платформы Windows, а так же на языке Java;

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

· возможность конфигурирования системы с помощью модулей расширения;

· в наибольшей степени подходит для разработки крупных информационных систем, так как реализует большую часть функций ARIS и ERwin/BPwin. И т.д.

Недостатки продукта Rational Rose

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

· сложность самого языка UML также накладывает определенные ограничения на привлечение к работам над проектами непрофессионалов,

· нельзя показать и удалить неиспользуемые объекты в отличие от BPWin;

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

· не поддерживает функционально-стоимостной анализ;

· нет возможности отобразить потоки данных между объектами или процессами.

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы:

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

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

· диаграммы сценариев;

· диаграммы модулей;

· диаграммы процессов;

· спецификации классов, объектов, атрибутов и операций

· заготовки текстов программ;

· модель разрабатываемой программной системы.

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

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

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

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

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

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

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

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

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

автоматизированный объектный ориентированный логистический

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

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

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

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

На рисунке 2 представлена диаграмма классов.

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

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

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

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

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

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

На рисунке 3 представлена диаграмма последовательности действий организации перевозки. При обращении компании-клиента в транспортно-логистическую компанию заключается договор на перевозку, в следствии взаимодействия компании-клиента, менеджера и директора. Затем оформляется заявка на перевозку путем взаимодействия компании-клиента с менеджером. После чего менеджер, взаимодействуя с логистическим отделом получает ТЛС и передает ее и заявку экспедитору. Затем происходит ряд операций по расчету с компанией-перевозчиком, в котором участвуют менеджер, бухгалтер и сама компания-перевозчик. После чего происходит осуществление перевозки с прохождением таможни при взаимодействии экспедитора, таможни и компании-перевозчика. После того как перевозка завершена происходит расчет с компанией-клиентом.

2.4 Диаграмма кооперации