Для многих разработчиков диаграммы архитектуры являются не только незаменимым навыком, но и ключевым инструментом для понимания, планирования и создания программных систем. Однако перед лицом разнообразных системных требований и сложной бизнес-логики построение диаграммы архитектуры стало общей проблемой, с которой сталкиваются многие программисты. Сегодня мы специально пригласили г-на Ли Чжихуэя, старшего архитектора Tongcheng Travel и Tencent Cloud TVP. Г-н Ли также является автором бестселлера «Архитектура с высоким параллелизмом на практике: от анализа требований к проектированию системы». использовать свои глубокие технические навыки и богатый опыт. Практический опыт помогает нам раскрыть тайну общих архитектурных схем и проанализировать принципы их выбора и сценарии применения на разных этапах разработки программного обеспечения.

//////////

«Жуйи, У Цзин, У Нэн — особенности «черного мифа» в мире операционных систем» Прямая трансляция «Программисты Goose Factory лицом к лицу» продолжится в среду вечером. Запишитесь на просмотр, и у вас будет возможность поймать Гуся. Заводские периферийные подарки!

01. Введение

в разработке программного обеспечения,Стать архитектором — «запредельная мечта» многих программистов.。Архитектура Технические возможности, необходимые учителям, многомерны и всеобъемлющи.。но стать Архитектураразделение,Первой способностью должно быть рисование диаграммы архитектуры.,Потому что системе нужен дизайн,нужен дизайн Архитектура фотография,А учитель Архитектуры — это тот, кто нарисовал картину Архитектуры. Как говорится «картинка стоит тысячи слов».,Диаграмма Архитектуры служит языком и мостом для общения между инженерами Архитектуры и различными должностями, такими как менеджеры по продуктам, инженеры-разработчики и инженеры-испытатели.,Ее важность очевидна.

Давайте сначала посмотрим на архитектурную диаграмму об архитектуре. Архитектурная диаграмма — это диаграмма, описывающая основные компоненты системы и их взаимосвязи. Так из чего же состоит сама архитектура? Какие части с ним связаны? Какова связь между этими частями?

Как показано на картинке выше,Для каждой системы есть своя Архитектура,Архитектура состоит из элементов Архитектуры и связей между ними.,Эти элементы и отношения передаются через Архитектура Документация для отображения。Архитектура Документация должна удовлетворять потребности различных заинтересованных сторон.сосредоточиться на какой-то момент, например, инженер-разработчик сосредоточить внимание Как реализовать код, сосредоточен инженер по эксплуатации и техническому обслуживанию; система Какое оборудование необходимо и какова схема сети? Какие функции реализованы в документе Архитектура для удовлетворения различных задач? наточка,Необходимо представить через различные представления архитектуры. Эти виды Архитектуры — это то, что мы часто называем картинками Архитектуры.,так,В реальной работе архитекторам не нужно рисовать одну архитектурную схему, а нужно рисовать множество архитектурных схем в соответствии с различными потребностями.

02. Диаграммы общей архитектуры UML

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

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

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

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

• Временная диаграмма

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

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

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

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

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

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

• Схема развертывания

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

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

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

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

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

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

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

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

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

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

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

• диаграмма деятельности

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

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

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

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

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

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

04. Заключение

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

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

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

Здесь я рекомендую простой онлайн-инструмент для рисования: https://app.diagrams.net/ Нарисуйте свою первую архитектурную схему и начните свой путь в качестве архитектора. Если вы хотите обратиться к некоторым конкретным случаям и увидеть, как диаграмма архитектуры конкретно выражает определенную идею дизайна и как несколько диаграмм архитектуры составляют документ проекта архитектуры, я рекомендую вам прочитать мою статью «Практика архитектуры с высоким параллелизмом: из анализа требований». к системному дизайну.

Об авторе

Ли Чжихуэй, старший архитектор Tongcheng Travel и Tencent Cloud TVP, уже давно занимается исследованиями и разработками в области больших данных и архитектуры больших веб-сайтов. Он работал техническим экспертом в Alibaba, архитектором Азиатско-Тихоокеанского центра исследований и разработок Intel и техническим директором Zhaimi и других компаний. Мастер-ключ Wi-Fi. Автор исходного кода Apache Spark, автор бестселлеров «Архитектура с высоким параллелизмом на практике: от анализа требований к проектированию системы», «Техническая архитектура больших веб-сайтов: основные принципы и анализ примеров» и книги Geek Time «Изучение больших данных с нуля». "автор колонки.

-End-

Автор оригинала｜Ли Чжихуэй