По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Почитать лекцию №15 про управление потоком пакетов в сетях можно тут.
Совокупность проблем и решений, рассмотренных в предыдущих лекциях, дает некоторое представление о сложности сетевых транспортных систем. Как системные администраторы могут взаимодействовать с очевидной сложностью таких систем?
Первый способ - рассмотреть основные проблемы, которые решают транспортные системы, и понять спектр решений, доступных для каждой из этих проблем. Второй - создание моделей, которые помогут понять транспортные протоколы с помощью:
Помощь администраторам сетей в классификации транспортных протоколов по их назначению, информации, содержащейся в каждом протоколе, и интерфейсам между протоколами;
Помочь администраторам сетей узнать, какие вопросы задавать, чтобы понять конкретный протокол или понять, как конкретный протокол взаимодействует с сетью, в которой он работает, и приложениями, для которых он несет информацию;
Помощь администраторам сетей в понимании того, как отдельные протоколы сочетаются друг с другом для создания транспортной системы.
Далее будет рассмотрен способ, с помощью которого администраторы могут более полно понимать протоколы: модели. Модели по сути являются абстрактными представлениями проблем и решений. Они обеспечивают более наглядное и ориентированное на модули представление, показывающее, как вещи сочетаются друг с другом. В этой лекции мы рассмотрим этот вопрос:
Как можно смоделировать транспортные системы таким образом, чтобы администраторы могли быстро и полностью понять проблемы, которые эти системы должны решать, а также то, как можно объединить несколько протоколов для их решения?
В этой серии лекции будут рассмотрены три конкретные модели:
Модель Министерства обороны США (United States Department of Defense - DoD)
Модель взаимодействия открытых систем (Open Systems Interconnect - OSI)
Модель рекурсивной интернет-архитектуры (Recursive Internet Architecture - RINA)
Модель Министерства обороны США (DoD)
В 1960-х годах Агентство перспективных исследовательских проектов Министерства обороны США (DARPA) спонсировало разработку сети с коммутацией пакетов для замены телефонной сети в качестве основного средства компьютерной связи. Вопреки мифу, первоначальная идея состояла не в том, чтобы пережить ядерный взрыв, а скорее в том, чтобы создать способ для различных компьютеров, используемых в то время в нескольких университетах, исследовательских институтах и правительственных учреждениях, чтобы общаться друг с другом. В то время каждая компьютерная система использовала свою собственную физическую проводку, протоколы и другие системы; не было никакого способа соединить эти устройства, чтобы даже передавать файлы данных, не говоря уже о создании чего-то вроде "Всемирной паутины" или кросс-исполняемого программного обеспечения. Эти оригинальные модели часто разрабатывались для обеспечения связи между терминалами и хостами, поэтому вы могли установить удаленный терминал в офис или общественное место, которое затем можно было использовать для доступа к общим ресурсам системы или хоста. Большая часть оригинальных текстов, написанных вокруг этих моделей, отражает эту реальность.
Одной из первых разработок в этой области была модель DoD, показанная на рисунке 1.
DoD разделяла работу по передаче информации по сети на четыре отдельные функции, каждая из которых могла выполняться одним из многих протоколов. Идея наличия нескольких протоколов на каждом уровне считалась несколько спорной до конца 1980-х и даже в начале 1990-х гг. На самом деле одним из ключевых различий между DoD и первоначальным воплощением модели OSI является концепция наличия нескольких протоколов на каждом уровне.
В модели DoD:
Физический уровень отвечает за получение "0" и "1" модулированных или сериализованных на физическом канале. Каждый тип связи имеет свой формат для передачи сигналов 0 или 1; физический уровень отвечает за преобразование 0 и 1 в физические сигналы.
Интернет-уровень отвечает за передачу данных между системами, которые не связаны между собой ни одной физической связью. Таким образом, уровень интернета предоставляет сетевые адреса, а не локальные адреса каналов, а также предоставляет некоторые средства для обнаружения набора устройств и каналов, которые должны быть пересечены, чтобы достичь этих пунктов назначения.
Транспортный уровень отвечает за построение и поддержание сеансов между коммутирующими устройствами и обеспечивает общий прозрачный механизм передачи данных для потоков или блоков данных. Управление потоком и надежная транспортировка также могут быть реализованы на этом уровне, как и в случае с TCP.
Прикладной уровень - это интерфейс между Пользователем и сетевыми ресурсами или конкретными приложениями, которые используют и предоставляют данные другим устройствам, подключенным к сети.
В частности, прикладной уровень кажется неуместным в модели сетевого транспорта. Почему приложение, использующее данные, должно считаться частью транспортной системы? Потому что ранние системы считали пользователя-человека конечным пользователем данных, а приложение - главным образом способом изменить данные, которые будут представлены фактическому пользователю. Большая часть обработки от машины к машине, тяжелая обработка данных перед их представлением пользователю и простое хранение информации в цифровом формате даже не рассматривались как жизнеспособные варианты использования. Поскольку информация передавалась от одного человека другому, приложение считалось частью транспортной системы.
Два других момента могли бы помочь включению прикладного уровня сделать его более осмысленным. Во-первых, в конструкции этих оригинальных систем было два компонента: терминал и хост. Терминал тогда был дисплейным устройством, приложение располагалось на хосте. Во-вторых, сетевое программное обеспечение не рассматривалось как отдельная "вещь" в системе, маршрутизаторы еще не были изобретены, как и любое другое отдельное устройство для обработки и пересылки пакетов. Скорее, хост был просто подключен к терминалу или другому хосту; сетевое программное обеспечение было просто еще одним приложением, запущенным на этих устройствах.
Со временем, когда модель OSI стала чаше использоваться, модель DoD была изменена, чтобы включить больше уровней. Например, на рисунке 2, на диаграмме, взятой из статьи 1983 года о модели DoD ("Cerf and Cain, "The DoD Internet Architecture Model"), есть семь слоев (семь почему-то являются магическим числом).
Были добавлены три слоя:
Уровень утилит - это набор протоколов, "живущих" между более общим транспортным уровнем и приложениями. В частности, простой протокол передачи почты (SMTP), протокол передачи файлов (FTP) и другие протоколы рассматривались как часть этого уровня.
Сетевой уровень из четырехслойной версии был разделен на сетевой уровень и уровень интернета. Сетевой уровень представляет различные форматы пакетов, используемые на каждом типе канала, такие как радиосети и Ethernet (все еще очень Новые в начале 1980-х годов). Уровень межсетевого взаимодействия объединяет представление приложений и протоколов утилит, работающих в сети, в единую службу интернет-дейтаграмм.
Канальный уровень был вставлен для того, чтобы различать кодирование информации на различные типы каналов и подключение устройства к физическому каналу связи. Не все аппаратные интерфейсы обеспечивали уровень связи.
Со временем эти расширенные модели DoD потеряли популярность; модель с четырьмя слоями является той, на которую чаще всего ссылаются сегодня. На это есть несколько причин:
Уровни утилит и приложений в большинстве случаев дублируют друг друга. Например, FTP мультиплексирует контент поверх протокола управления передачей (TCP), а не как отдельный протокол или слой в стеке. TCP и протокол пользовательских дейтаграмм (UDP) со временем превратились в два протокола на транспортном уровне, а все остальное (как правило) работает поверх одного из этих двух протоколов.
С изобретением устройств, предназначенных в первую очередь для пересылки пакетов (маршрутизаторы и коммутаторы), разделение между сетевым и межсетевым уровнями было преодолено определенными событиями. Первоначальная дифференциация проводилась в основном между низкоскоростными дальнемагистральными (широкозонными) и короткозонными локальными сетями; маршрутизаторы обычно брали на себя бремя установки каналов в широкополосные сети вне хоста, поэтому дифференциация стала менее важной.
Некоторые типы интерфейсов просто не имеют возможности отделить кодирование сигнала от интерфейса хоста, как было предусмотрено в разделении между канальным и физическим уровнями. Следовательно, эти два уровня обычно объединены в одну "вещь" в модели DoD.
Модель DoD исторически важна, потому что
Это одна из первых попыток систематизировать функциональность сети в модели.
Это модель, на которой был разработан набор протоколов TCP / IP (на котором работает глобальный Интернет); Артефакты этой модели важны для понимания многих аспектов проектирования протокола TCP / IP.
В нее была встроена концепция множественных протоколов на любом конкретном уровне модели. Это подготовило почву для общей концепции сужения фокуса любого конкретного протокола, позволяя одновременно работать многим различным протоколам в одной и той же сети.
Сразу к делу. На рисунке 1 показана базовая конфигурация STP (Spanning Tree Protocol).
Рис. 1 Базовая конфигурация STP
По умолчанию функция STP коммутатора включена. Если STP отключен, используйте команду stp enable в системном режиме, чтобы включить STP.
# На S1 установите режим работы связующего дерева на STP. Используйте режим stp {mstp | rstp | stp}, с помощью которой вы можете установить режим MSTP, RSTP или STP. По умолчанию установлен режим MSTP.
<Quidway> system-view
[Quidway] sysname S1
[S1] stp mode stp
# На S2 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S2
[S2] stp mode stp
# На S3 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S3
[S3] stp mode stp
# На S4 установите режим работы связующего дерева на STP.
<Quidway> system-view
[Quidway] sysname S4
[S4] stp mode stp
Даже если STP автоматически выберет корневой мост, мы сначала назначим коммутатор ближе к центру сети. Структура сети показана на рис. 1 простая: S1 и S2 подключены через Интернет, а основные коммутаторы, S3 и S4, являются коммутаторами доступа. Мы можем изменить приоритет моста S1, чтобы гарантировать, что S1 будет выбран в качестве корневого моста. Команда stp priority priority используется для установки приоритета моста устройства; значение приоритета колеблется от 0 до 61440 с шагом 4096. Значение по умолчанию-32 768. Чем меньше приоритет, тем больше вероятность того, что устройство будет выбрано в качестве корневого моста. Вы также можете использовать команду stp root primary для обозначения S1 в качестве корневого моста. После выполнения команды на устройстве значение приоритета моста устройства автоматически устанавливается равным 0. Приоритет моста устройства не может быть изменен после этого с помощью команды stp priority priority.
[S1] stp root primary
Затем мы назначим S2 вторичным корневым мостом, чтобы S2 заменил S1 в качестве нового корневого моста в случае сбоя. После запуска на устройстве команды stp root secondary значение приоритета моста устройства автоматически устанавливается на 4096 и не может быть изменено после этого с помощью команды stp priority priority.
[S2] stp root secondary
На этом базовая конфигурация STP сети завершена. Чтобы проверить состояние и статистику дерева SPT, вы можете запустить display stp [interface interface-type
interface-number] [brief]
На S1 используйте команду display stp brief для отображения основной информации STP.
В выводимых данных видно, что, поскольку S1 является корневым мостом, GE0 / 0/2 и GE0 / 0/1 S1 являются назначенными портами в состоянии normal forwarding.
Следующий вывод - это основная информация STP S4.
Интерфейс GE0/0/2 коммутатора S4 является корневым портом в состоянии normal forwarding. Однако его порт GE0/0/1 является альтернативным портом в состоянии блокировки.
Для чего нужно использовать UML-диаграмму
Лучше один раз увидеть, чем сто раз услышать. Именно для этого был создан унифицированный язык моделирования (UML – Unified Modeling Language) – для того, чтобы сформировать общий язык визуального общения в непростом мире разработки программного обеспечения, который был бы также понятен для коммерческих пользователей и для всех, кто хочет понять, как работает система. Здесь вы сможете изучить основные вопросы, связанные с UML-диаграммами, а также их историю развития, принципы использования, концепции, типы и рекомендации по их построению с помощью нашего инструмента для создания UML-диаграмм.
Что такое UML?
Унифицированный язык моделирования (UML) был создан для формирования общего, семантически и синтаксически богатого языка визуального моделирования, который можно было бы применять для логического построения, проектирования и реализации сложных систем ПО как с точки зрения структуры, так и поведения. UML имеет применение и за пределами разработки программного обеспечения, например, в качестве потока процессов разработки.
Он похож на схематические планы работ, которые используются в других областях, и состоит из различных диаграмм. В целом UML-диаграммы описывают границы, структуру и поведение системы и объектов внутри нее.
UML – это не язык программирования, но существуют различные инструменты, с помощью которых можно написать код на различных языках с помощью UML-диаграмм. UML непосредственно связан с объектно-ориентированным анализом и проектированием.
UML и его роль в объектно-ориентированном моделировании и проектировании
В области теории вычислительных систем, связанной с изучением алгоритмов и данных, существует большое количество парадигм или моделей решения задач. Существует четыре категории моделей решения задач: императивные, функциональные, декларативные и объектно-ориентированные (ООП) языки. В случае объектно-ориентированных языков алгоритмы формулируются через определение «объектов» и их взаимодействия друг с другом. С этими объектами можно выполнять различные действия, и они существуют в реальной практике. Это могут быть здания, графические элементы на рабочем столе или люди.
Объектно-ориентированные языки занимают лидирующие позиции в мире программирования, поскольку они моделируют объекты реального мира. UML – это комбинация нескольких объектно-ориентированных нотаций: объектно-ориентированного проектирования, технологии объектного моделирования и разработки объектно-ориентированного программного обеспечения.
UML использует сильные стороны каждого из этих трех подходов для получения более последовательной методологии, которая являлась бы более простой. UML олицетворяет накопленный опыт создания и документирования различных аспектов моделирования программного обеспечения и коммерческих систем.
История развития UML
«Три Амиго» разработки программного обеспечения (именно так они были известны) разработали каждый свою методологию. Они объединились и создали новые стандарты, которые должны были привнести ясность для программистов. Совместная работа Грэди, Буча и Рамбо сделала эти три метода более эффективными и улучшила конечный продукт.
В 1996 году усилия этих трех мыслителей увенчались выпуском документации для UML 0.9 и UML 0.91. Вскоре выяснилось, что некоторые организации, в том числе Microsoft, Oracle и IBM, считают, что UML является критически важным для развития их бизнеса. Поэтому они, совместно со многими другими отдельными людьми и компаниями, предоставили ресурсы, которые помогли разработать полноценный язык моделирования. В 1999 году «три Амиго» опубликовали руководство «The Unified Modeling Language User Guide», а в 2005 году – во втором издании – обновление, которое включало в себя материалы по UML 2.0.
OMG: это обретает другой смысл
Согласно их веб-сайту, The Object Management Group® (OMG®) (Консорциум по технологии манипулирования объектами) – это международный некоммерческий консорциум технологических стандартов с открытым членством, который был основан в 1989 году. Стандарты OMG продиктованы поставщиками, конечными пользователями, академическими и государственными учреждениями. Целевые группы специалистов OMG разрабатывают стандарты интеграции предприятий для огромного количества технологий и целого ряда отраслей. Стандарты моделирования OMG, в том числе UML и MDA® (Model Driven Architecture® - архитектура на основе моделей, или архитектура, управляемая моделями), обеспечивают мощное визуальное конструирование, работу и сопровождение программного обеспечения и других процессов.
OMG контролирует определение и сопровождение спецификаций UML. Этот контроль дает инженерам и программистам возможность использовать один язык для различных целей на всех этапах жизненного цикла программного обеспечения для систем любого размера.
Цель UML по заявлению OMG
OMG определяет цель UML как:
предоставление разработчикам архитектуры системы, инженерам и разработчикам программного обеспечения инструментов для анализа, проектирования и реализации программных систем, а также для моделирования технологических и подобных процессов.
улучшение состояния отрасли путем обеспечения возможности взаимодействия инструментов визуального моделирования объектов. Однако для того, чтобы обеспечить содержательный обмен информацией о модели между инструментами, необходимо соглашение по семантике и нотации.
UML отвечает следующим требованиям:
UML устанавливает формальное определение общей метамодели на основе метаобъектных средств (MOF – Meta-Object Facility), которая определяет общий синтаксис UML. Общий синтаксис определяет набор концепций UML-моделирования, их атрибуты и отношения, а также правила совмещения этих концепций для построения частных или замкнутых UML-моделей.
UML предоставляет подробное разъяснения семантики каждой концепции UML-моделирования. Семантика определяет то, как концепции UML должны быть реализованы компьютерами вне зависимости от технологии.
UML определяет удобные для восприятия обозначения для изображения отдельных концепций UML-моделирования, а также правил их совмещения в диаграммы, которые соответствуют различным компонентам моделируемых систем.
UML определяет способы согласования инструментов UML cо стандартом. Это требование поддерживается (в отдельном стандарте) стандартом на базе XML соответствующих форматов обмена моделями (XMI - XML Metadata Interchange), которые должны быть реализованы с помощью согласующихся инструментов.
UML и моделирование данных
UML достаточно распространен среди программистов, но, как правило, его не используют разработчики баз данных. Одна из причин – создатели UML просто не уделили должного внимания базам данных. Несмотря на это, UML эффективен для высокоуровневого концептуального моделирования данных и может использоваться в различных UML-диаграммах.
Изменения в UML 2.0
UML совершенствуется снова и снова. UML 2.0 расширяет стандарты UML и охватывает больше аспектов разработки, в том числе Agile. Цель состояла в том, чтобы реструктурировать и усовершенствовать UML так, чтобы упростить использование, реализацию и адаптацию. Ниже представлены некоторые изменения в UML-диаграммах:
Более тесная интеграция между структурными и поведенческими моделями.
Способность определять иерархию и разбивать программную систему на компоненты и подкомпоненты.
UML 2.0 увеличивает количество диаграмм с 9 до 13.
Словарь терминов UML
Ознакомьтесь со словарем UML. Он был взят из документации по UML 2.4.1. Этот словарь предназначен для помощи тем, кто не является членом OMG, чтобы они могли понимать, о чем идет речь.
Соответствие общему синтаксису
. У пользователей есть возможность перемещать модели между различными инструментами, даже если они используют разные обозначения.
Общая метамодель хранилищ данных
(CWM – Common Warehouse Metamodel). Стандартные интерфейсы, которые используются для поддержки обмена метаданными хранилища и бизнес-аналитики между инструментами, платформами хранилища и репозиториями метаданных хранилища в распределенных разнородных средах.
Соответствие конкретному синтаксису
. У пользователей есть возможность использовать обозначения, с которыми они хорошо знакомы, в различных инструментах.
Ядро
. В контексте UML ядро обычно относят к «пакету ядра», который представляет собой замкнутую метамодель, которая предназначена специально для многократного применения.
Языковая единица
. Состоит из набора тесно связанных между собой концепций моделирования, с помощью которых пользователь может изображать аспекты изучаемой системы в соответствии с определенной парадигмой или формальной системой.
Уровень 0
(L0). Нижний уровень соответствия в инфраструктуре UML – самостоятельная языковая единица, с помощью которой можно моделировать структуры на основе классов, которые встречаются в большей части популярных объектно-ориентированных языков программирования.
Метаобъектные средства
(MOF – Meta Object Facility). Стандарт моделирования OMG, который дает основу для определения метамодели в семействе MDA-языков.
Метамодель
. Определяет язык и процессы, из которых формируется модель.
Структурные элементы метамодели
(LM). Второй уровень соответствия в инфраструктуре UML – дополнительная языковая единица для более сложных структур на основе классов, которая используется для построения метамоделей (с использованием CMOF (Complete MOF – полный объем метаобъектных средств)), таких как сам UML. У UML есть только два уровня соответствия.
Архитектура на основе моделей
(MDA – Model Driven Archutecture). Подход и планирование создания целостного набора стандартов технологий на основе моделей.
Язык описания объектных ограничений
(OCL – Object Constraint Language). Декларативный язык описания правил, которые можно применять к унифицированному языку моделирования. OCL дополняет UML благодаря наличию терминов и символов блок-схем, которые являются более точными, нежели естественный язык, и при этом менее сложными для освоения, нежели математика.
Консорциум по технологии манипулирования объектами
(OMG - Object Management Group). Это некоммерческий консорциум стандартов компьютерной отрасли, члены которого определяют и сопровождают стандарт UML.
UML 1.
Первая версия унифицированного языка моделирования.
Унифицированный язык моделирования
(UML – Unified Modeling Language). Язык визуального общения, который предназначен для определения, построения и документирования артефактов систем.
XMI
. Стандарт форматов обмена моделями, основанный на XML.
Концепции моделирования, определяемые UML
Внимание процесса разработки системы направлено на три разные модели системы:
Функциональная
: это диаграммы прецедентов, которые описывают функциональные возможности системы с точки зрения пользователя.
Объектная
: это диаграммы классов, которые описывают структуру системы с точки зрения объектов, атрибутов, ассоциаций и операций.
Динамическая
: диаграммы взаимодействия, диаграммы конечного автомата и диаграммы деятельности, которые используются для описания внутреннего поведения системы.
Эти модели системы изображаются с помощью двух различных типов диаграмм: структурных и поведенческих.
Объектно-ориентированные концепции в UML
Объекты в UML – это реально существующие объекты, которые находятся вокруг нас. В разработке программного обеспечения объекты могут использоваться для описания или моделирования создаваемой системы с точки зрения предметной области. Объекты также позволяют разбивать сложные системы на доступные для понимания компоненты, которые делают возможным то, что можно создавать по одной части системы за раз.
Ниже приведены некоторые фундаментальные объектно-ориентированные концепции:
Объекты
. Олицетворяют сущность и основной модуль.
Класс
. Схема объекта.
Абстрактное представление
. Поведение реально существующего объекта.
Инкапсуляция
. Механизм связки данных и сокрытия их от внешнего мира.
Наследование
. Механизм создания новых классов из уже существующих.
Полиморфизм
. Он определяет механизм существования в различных формах.
Типы UML-диаграмм
Для создания диаграмм, которые отображают статические, или структурные, аспекты системы, а также поведенческих диаграмм, которые отображают динамические аспекты системы UML использует элементы и соединяет их различными способами.
Структурные UML-диаграммы
Диаграмма классов
. Самая часто используемая UML-диаграмма, и она же является главной основой любого объектно-ориентированного решения. Классы в пределах системы, атрибуты и операции и отношения между классами. Для того, чтобы сформировать диаграмму классов или диаграмму большой системы, классы группируются.
Диаграмма компонентов
. Отображает структурные отношения элементов программной системы. Чаще всего ее используют для работы со сложными системами с несколькими компонентами. Компоненты взаимодействуют при помощи интерфейса.
Диаграмма композитных структур
. Эти диаграммы используются для отображения внутренней структуры класса.
Диаграмма развертывания
. Иллюстрирует аппаратное и программное оборудование системы. Это полезно, когда программное решение развертывается на нескольких компьютерах, у каждого из которых своя уникальная системная конфигурация.
Диаграмма объектов
. Демонстрирует взаимосвязь между объектами на примерах из реальной практики и иллюстрирует то, как система будет выглядеть в любой момент времени. Так как внутри объектов есть данные, их можно использовать для конкретизации отношений между объектами.
Диаграмма пакетов
. Есть два типа зависимостей между пакетами: импорт пакетов и слияние пакетов. Пакеты могут символизировать различные системные уровни, предназначенные для демонстрации архитектуры. Зависимости пакетов можно помечать, чтобы продемонстрировать то, как уровни связаны между собой.
Поведенческие UML-диаграммы
Диаграмма деятельности
. Графическое представление рабочих бизнес-процессов, которое необходимо для демонстрации работы любой части или компонента в системе. Диаграммы деятельности – это альтернатива диаграммам конечного автомата.
Диаграмма коммуникаций
. Похожа на диаграмму последовательности действий, но фокус внимания направлен на сообщения, которые передаются между объектами.
Диаграмма обзора взаимодействий
. Существует семь различных типов диаграмм взаимодействий, и эта диаграмма демонстрирует, в какой последовательности они работают.
Диаграмма последовательности действий
. Демонстрирует, как объекты взаимодействуют друг с другом и порядок наступления событий. Они описывают взаимодействие для определенного сценария.
Диаграмма состояний
. Похожа на диаграмму деятельности. Она описывает поведение объектов, которые в своем текущем состоянии ведут себя различно.
Временная диаграмма
. Аналогично диаграмме последовательности действий, эта диаграмма демонстрирует поведение объектов в заданном интервале времени. Если объект всего один, то диаграмма крайне проста. Если объектов несколько, то диаграмма отображает то, как объекты взаимодействуют друг с другом в течение этого конкретного периода времени.
Диаграмма прецедентов
. Отображает конкретную функциональную возможность системы. Она создана для того, чтобы демонстрировать то, как связаны функциональные возможности и их внутренние/внешние управляющие устройства (агенты).
Как построить UML-диаграмму: руководства и примеры
Для того, чтобы показать, как строить различные UML-диаграммы, мы предлагаем попробовать изучить одно или все эти руководства, которые продемонстрируют процесс создания как структурных, так и поведенческих диаграмм.
Примеры руководств по построению структурных диаграмм
ДИАГРАММЫ КЛАССОВ
Диаграммы классов отображают статические структурные элементы системы, в том числе ее классы, атрибуты, методы и объекты. С помощью диаграммы классов можно изобразить вычислительные данные с помощью классов реализации или организационные данные с помощью логических классов. Эти две группы могут пересекаться.
Классы изображаются с помощью прямоугольной фигуры, которая разделена на три части. В верхней части отображается имя класса, в средней – его атрибуты. В нижней части описываются операции классов (которые также известны как методы).
Добавляйте фигуры классов на диаграмму, и моделируйте отношения между ними. Возможно, вам необходимо будет добавить подклассы.
Для изображения ассоциаций, наследования, множественности и других отношений между классами и подклассами используйте линии. Линии могут быть любыми.
ДИАГРАММЫ КОМПОНЕНТОВ
Диаграммы компонентов показывают то, как компоненты собираются в более крупные компоненты или программные системы. Эти диаграммы предназначены для моделирования зависимостей системных компонентов. Компонент нужен для создания стереотипа. Стереотип компонента может состоять из исполняемых файлов, документов, таблиц баз данных, файлов или библиотечных файлов.
Компонент изображается с помощью прямоугольной фигуры. У него должно быть два маленьких прямоугольника сбоку или значок такой формы.
Чтобы изобразить соответствующие отношения, добавьте между фигурами линии.
ДИАГРАММЫ РАЗВЕРТЫВАНИЯ
Диаграмма развертывания моделирует физическое развертывание и структуру аппаратной части системы. Эти диаграммы демонстрируют, где и как системные компоненты будут взаимодействовать друг с другом.
Для построения диаграммы развертывания используются те же обозначения, что и для построения диаграммы компонентов.
Для моделирования узла используйте трехмерный куб, который будет представлять собой физическую или виртуальную машину.
Подпишите узлы также, как и на диаграмме последовательности действий.
Примеры руководств по построению поведенческих диаграмм
ДИАГРАММЫ ДЕЯТЕЛЬНОСТИ
Диаграммы деятельности демонстрируют процедурный поток управления между объектами класса, а также организационные процессы, такие как потоки бизнес-операций. Эти диаграммы строятся с помощью специальных фигур, соединенных стрелками. Набор обозначения для диаграмм деятельности такой же, как и для диаграмм состояний.
Начните построение диаграммы деятельности со сплошного круга.
Соедините круг с первым действием, которое моделируется с помощью прямоугольника со скругленными краями.
Теперь соедините все действия линиями, которые продемонстрируют последовательность всего процесса.
Также вы можете попробовать использовать плавательные дорожки для отображения объектов, выполняющих то или иное действие.
ДИАГРАММЫ ПРЕЦЕДЕНТОВ
Прецедент – это список шагов, которые определяют взаимодействие между агентом (человеком, который взаимодействует с системой или внешней системой) и самой системой. Диаграммы прецедентов отображают характиристики прецедента и моделируют функциональные блоки системы. Эти диаграммы помогают командам разработчиков понимать требования системы, в том числе роль взаимодействия с человеком в ней, и различия между прецедентами. Диаграмма прецедентов может демонстрировать все прецеденты системы или только одну группу с похожими функциональными возможностями.
Для того, чтобы начать рисовать диаграмму прецедентов, добавьте овал в центр рисунка.
Добавьте название прецедента внутрь овала.
Изобразите агентов рядом с овалом (используйте для этого схематичное изображение человечков), а затем смоделируйте отношения между агентами и прецедентами с помощью линий.
ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ ДЕЙСТВИЙ
Диаграммы последовательности действий, также известные как диаграммы событий или сценарии событий, показывают, как процессы взаимодействуют друг с другом, демонстрируя вызовы между различными объектами в порядке их появления. Эти диаграммы имеют два измерения: вертикальное и горизонтальное. Вертикальные линии демонстрируют последовательность сообщений и вызовов в хронологическом порядке, а горизонтальные элементы демонстрируют экземпляры объектов, в которые перенаправляются сообщения.
Для того, чтобы построить диаграмму последовательности событий, запишите имя экземпляра класса и имя класса в прямоугольном блоке.
Чтобы обозначить отправителя и получателя сообщений, нарисуйте линии между экземплярами класса.
Для обозначения синхронных сообщений используйте сплошные стрелки, для асинхронных сообщений – открытые стрелки, а для ответных сообщений – пунктирные линии.