From 67fd940ab2b75d0ead4ad9265514a9698739a4f1 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Mon, 12 Jun 2023 16:37:56 +0200 Subject: [PATCH 01/23] Init --- RU/asciidoc/arc42-template.adoc | 100 +++++++++ .../src/01_introduction_and_goals.adoc | 91 ++++++++ .../src/02_architecture_constraints.adoc | 27 +++ RU/asciidoc/src/03_context_and_scope.adoc | 75 +++++++ .../src/03_system_scope_and_context.adoc | 71 ++++++ RU/asciidoc/src/04_solution_strategy.adoc | 32 +++ RU/asciidoc/src/05_building_block_view.adoc | 212 ++++++++++++++++++ RU/asciidoc/src/06_runtime_view.adoc | 51 +++++ RU/asciidoc/src/07_deployment_view.adoc | 94 ++++++++ RU/asciidoc/src/08_concepts.adoc | 73 ++++++ .../src/09_architecture_decisions.adoc | 35 +++ RU/asciidoc/src/10_quality_requirements.adoc | 73 ++++++ RU/asciidoc/src/11_technical_risks.adoc | 25 +++ RU/asciidoc/src/12_glossary.adoc | 42 ++++ RU/asciidoc/src/about-arc42.adoc | 15 ++ RU/asciidoc/src/config.adoc | 9 + 16 files changed, 1025 insertions(+) create mode 100644 RU/asciidoc/arc42-template.adoc create mode 100644 RU/asciidoc/src/01_introduction_and_goals.adoc create mode 100644 RU/asciidoc/src/02_architecture_constraints.adoc create mode 100644 RU/asciidoc/src/03_context_and_scope.adoc create mode 100644 RU/asciidoc/src/03_system_scope_and_context.adoc create mode 100644 RU/asciidoc/src/04_solution_strategy.adoc create mode 100644 RU/asciidoc/src/05_building_block_view.adoc create mode 100644 RU/asciidoc/src/06_runtime_view.adoc create mode 100644 RU/asciidoc/src/07_deployment_view.adoc create mode 100644 RU/asciidoc/src/08_concepts.adoc create mode 100644 RU/asciidoc/src/09_architecture_decisions.adoc create mode 100644 RU/asciidoc/src/10_quality_requirements.adoc create mode 100644 RU/asciidoc/src/11_technical_risks.adoc create mode 100644 RU/asciidoc/src/12_glossary.adoc create mode 100644 RU/asciidoc/src/about-arc42.adoc create mode 100644 RU/asciidoc/src/config.adoc diff --git a/RU/asciidoc/arc42-template.adoc b/RU/asciidoc/arc42-template.adoc new file mode 100644 index 00000000..97e31fca --- /dev/null +++ b/RU/asciidoc/arc42-template.adoc @@ -0,0 +1,100 @@ +// header file for arc42-template, +// including all help texts +// +// ==================================== + +// configure EN settings for asciidoc +include::src/config.adoc[] + += image:arc42-logo.png[arc42] Шаблон +:revnumber: 8.2 RU +:revdate: Январь 2023 +:revremark: (based upon AsciiDoc version) +// toc-title definition MUST follow document title without blank line! +:toc-title: Оглавление + +//additional style for arc42 help callouts +ifdef::backend-html5[] +++++ + +++++ +endif::backend-html5[] + + +include::src/about-arc42.adoc[] + +// horizontal line +*** + +[role="arc42help"] +**** +[NOTE] +==== +Эта версия шаблона содержит подсказки и пояснения. +Используйте для ознакомления с arc42 и понимания концепций. +Для документирования собственной системы лучше использовать _простую(plain)_ версию. + +==== +**** + + +// numbering from here on +:numbered: + +<<<< +// 1. Introduction and Goals +include::src/01_introduction_and_goals.adoc[] + +<<<< +// 2. Architecture Constraints +include::src/02_architecture_constraints.adoc[] + +<<<< +// 3. Context and Scope +include::src/03_context_and_scope.adoc[] + +<<<< +// 4. Solution Strategy +include::src/04_solution_strategy.adoc[] + +<<<< +// 5. Building Block View +include::src/05_building_block_view.adoc[] + +<<<< +// 6. Runtime View +include::src/06_runtime_view.adoc[] + +<<<< +// 7. Deployment View +include::src/07_deployment_view.adoc[] + +<<<< +// 8. Concepts +include::src/08_concepts.adoc[] + +<<<< +// 9. Architecture Decisions +include::src/09_architecture_decisions.adoc[] + +<<<< +// 10. Quality Requirements +include::src/10_quality_requirements.adoc[] + +<<<< +// 11. Technical Risks +include::src/11_technical_risks.adoc[] + +<<<< +// 12. Glossary +include::src/12_glossary.adoc[] + + diff --git a/RU/asciidoc/src/01_introduction_and_goals.adoc b/RU/asciidoc/src/01_introduction_and_goals.adoc new file mode 100644 index 00000000..5977b0e7 --- /dev/null +++ b/RU/asciidoc/src/01_introduction_and_goals.adoc @@ -0,0 +1,91 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-introduction-and-goals]] +== Введение и цели + +[role="arc42help"] +**** +Описывает соответствующие требования и движущие силы, которые должны учитывать архитекторы программного обеспечения и команда разработчиков. +К ним относятся + +* основные бизнес-цели, +* важные особенности, +* основные функциональные требования, +* цели в области качества архитектуры и +* соответствующие заинтересованные стороны и их ожидания +**** + +=== Обзор требований + +[role="arc42help"] +**** +.Содержание +Краткое описание функциональных требований, движущих сил, выжимка требований. Ссылка на (возможно, уже существующие) документы с требованиями +(с номером версии и информацией, где ее найти). + +.Мотивация +С точки зрения конечных пользователей система создается или модифицируется чтобы +улучшить поддержку деловой активности и/или улучшить качество. + +.Форма +Краткое текстовое описание, вероятно, в табличном формате варианта использования. +Если существуют документы с требованиями, этот обзор должен ссылаться на эти документы. + +Сделайте эти выдержки как можно короче. Соблюдайте баланс читабельности этого документа с потенциальной избыточностью по отношению к документам с требованиями + + +.Дальнейшая информация + +Смотрите https://docs.arc42.org/section-1/[Введение и цели] в документации arc42. + +**** + +=== Цели по качеству + +[role="arc42help"] +**** +.Содержание +Три (максимум пять) главных целей в области качества для архитектуры, выполнение которых имеет первостепенное значение для основных заинтересованных сторон. +Здесь действительно имеются в виду цели качества для архитектуры. Не путайте их с целями проекта. +Они не обязательно совпдают. + +Рассмотрите этот обзор потенциальных тем (на основе стандарта ISO 25010): +image::01_2_iso-25010-topics-EN.drawio.png["Категории требований по качеству"] + +.Мотвация +Вы должны знать цели в области качества наиболее важных заинтересованных сторон, поскольку они будут влиять на фундаментальные архитектурные решения. +Убедитесь, что вы очень конкретно говорите об этих качествах, избегайте модных словечек. +Если вы как архитектор не знаете, как будет оцениваться качество вашей работы... + +.Форма +Таблица с целями по качеству и конкретными сценариями, упорядоченными по приоритетам +**** + +=== Заинтересованные стороны + +[role="arc42help"] +**** +.Содержание +Подробный обзор заинтересованных сторон системы, т. е. всех лиц, ролей или организаций, которые + +* должны знать архитектуру +* должны быть уверены в архитектуре +* работать с архитектурой или с кодом +* нуждаются в архитектурной документации для своей работы +* должны принимать решения о системе или ее развитии + +.Мотивация +Вы должны знать все стороны, участвующие в разработке системы или затронутые системой. +В противном случае вы можете получить неприятные сюрпризы позже в процессе разработки. +Эти заинтересованные стороны определяют степень и уровень детализации вашей работы и ее результатов. + +.Форма +Таблица именами людей, их ролями и ожиданиями в отношении архитектуры и ее документации. +**** + +[options="header",cols="1,2,2"] +|=== +|Роль/Имя|Контактные данные|Ожидания +| _<Роль-1>_ | _<Контактные-данные-1>_ | _<Ожидания-1>_ +| _<Роль-2>_ | _<Контактные-данные-2>_ | _<Ожидания-2>_ +|=== \ No newline at end of file diff --git a/RU/asciidoc/src/02_architecture_constraints.adoc b/RU/asciidoc/src/02_architecture_constraints.adoc new file mode 100644 index 00000000..226e501f --- /dev/null +++ b/RU/asciidoc/src/02_architecture_constraints.adoc @@ -0,0 +1,27 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-architecture-constraints]] +== Architecture Constraints + + +[role="arc42help"] +**** +.Contents +Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies. + +.Motivation +Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. +Constraints must always be dealt with; they may be negotiable, though. + +.Form +Simple tables of constraints with explanations. +If needed you can subdivide them into +technical constraints, organizational and political constraints and +conventions (e.g. programming or versioning guidelines, documentation or naming conventions) + + +.Further Information + +See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation. + +**** diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc new file mode 100644 index 00000000..e95083cf --- /dev/null +++ b/RU/asciidoc/src/03_context_and_scope.adoc @@ -0,0 +1,75 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-context-and-scope]] +== Context and Scope + + +[role="arc42help"] +**** +.Contents +Context and scope - as the name suggests - delimits your system (i.e. your scope) from all its communication partners +(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces. + +If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware). + +.Motivation +The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them. + +.Form +Various options: + +* Context diagrams +* Lists of communication partners and their interfaces. + + +.Further Information + +See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation. + +**** + + +=== Business Context + +[role="arc42help"] +**** +.Contents +Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces. +Optionally you can add domain specific formats or communication protocols. + +.Motivation +All stakeholders should understand which data are exchanged with the environment of the system. + +.Form +All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners. + +Alternatively (or additionally) you can use a table. +The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs. + +**** + +**** + +**** + +=== Technical Context + +[role="arc42help"] +**** +.Contents +Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel. + +.Motivation +Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces. + +.Form +E.g. UML deployment diagram describing channels to neighboring systems, +together with a mapping table showing the relationships between channels and input/output. + +**** + +**** + +**** + +**** diff --git a/RU/asciidoc/src/03_system_scope_and_context.adoc b/RU/asciidoc/src/03_system_scope_and_context.adoc new file mode 100644 index 00000000..5e96c070 --- /dev/null +++ b/RU/asciidoc/src/03_system_scope_and_context.adoc @@ -0,0 +1,71 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-context-and-scope]] +== Область дії системи та її контекст + + +[role="arc42help"] +**** +.Зміст +Область дії системи та її контекст - як випливає з назви, відмежовують вашу систему (тобто вашу область) від усіх її партнерів по спілкуванню (сусідні системи та користувачі, тобто контекст вашої системи). Таким чином, вони визначають зовнішні інтерфейси. + +Якщо необхідно, відмежуйте бізнес-контекст (специфічні вхідні та вихідні данні домену) від технічного контексту (канали, протоколи, апаратне забезпечення). + +.Мотивація +Інтерфейси домену та технічні інтерфейси для комунікаційних партнерів є одними з найважливіших аспектів вашої системи. Переконайтеся, що ви їх повністю розумієте. + +.Форма +Різноманітні варіанти: + +* Контекстні діаграми +* Списки комунікаційних партнерів та їх інтерфейси. + + +.Додаткова інформація + +Див. https://docs.arc42.org/section-3/[Контекст і область дії] дії в документації arc42. + +**** + + +=== Бізнес контекст + +[role="arc42help"] +**** +.Зміст +Специфікація *всіх* комунікаційних партнерів (користувачів, ІТ-систем, …​) з поясненнями вхідних і вихідних даних або інтерфейсів, що стосуються конкретного домену. За бажанням ви можете додати специфічні для домену формати або протоколи зв’язку. + +.Мотивація +Усі зацікавлені сторони повинні розуміти, якими даними обмінюються із середовищем системи. + +.Форма +Різноманітні діаграми, які показують систему як чорний ящик і визначають інтерфейси домену для партнерів по спілкуванню. + +Як альтернативу (або додатково) можна використовувати таблицю. Заголовок таблиці – це ім’я вашої системи, три стовпці містять ім’я комунікаційного партнера, вхідні та вихідні данні. + +**** + +**<Діаграма або таблиця>** + +**<опціонально: Пояснення інтерфейсів зовнішнього домену>** + +=== Технічний контекст + +[role="arc42help"] +**** +.Зміст +Технічні інтерфейси (канали та засоби передачі), що з’єднують вашу систему з її середовищем. Крім того, відображення вводу/виводу, специфічного для домену, на канали, тобто пояснення щодо того, для якого вводу/виводу, який канал використовується. + +.Мотивація +Багато зацікавлених сторін приймають архітектурні рішення на основі технічних інтерфейсів між системою та її контекстом. Особливо розробники інфраструктури або апаратного забезпечення вирішують ці технічні інтерфейси. + +.Форма +Наприклад діаграма розгортання UML, що описує канали до сусідніх систем, разом із таблицею відображення, що показує зв’язки між каналами та вводом/виводом. + +**** + +**<Діаграма або таблиця>** + +**<опціонально: Пояснення технічних інтерфейсів>** + +**<Зіставлення вхідних/вихідних даних з каналами>** diff --git a/RU/asciidoc/src/04_solution_strategy.adoc b/RU/asciidoc/src/04_solution_strategy.adoc new file mode 100644 index 00000000..7bf03f7a --- /dev/null +++ b/RU/asciidoc/src/04_solution_strategy.adoc @@ -0,0 +1,32 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-solution-strategy]] +== Solution Strategy + + +[role="arc42help"] +**** +.Contents +A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes + +* technology decisions +* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern +* decisions on how to achieve key quality goals +* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties. + +.Motivation +These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules. + +.Form +Keep the explanations of such key decisions short. + +Motivate what was decided and why it was decided that way, +based upon problem statement, quality goals and key constraints. +Refer to details in the following sections. + + +.Further Information + +See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation. + +**** diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc new file mode 100644 index 00000000..df5c29c8 --- /dev/null +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -0,0 +1,212 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-building-block-view]] + + +== Building Block View + +[role="arc42help"] +**** +.Content +The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, ...) as well as their dependencies (relationships, associations, ...) + +This view is mandatory for every architecture documentation. +In analogy to a house this is the _floor plan_. + +.Motivation +Maintain an overview of your source code by making its structure understandable through +abstraction. + +This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details. + +.Form +The building block view is a hierarchical collection of black boxes and white boxes +(see figure below) and their descriptions. + +image::05_building_blocks-EN.png["Hierarchy of building blocks"] + +*Level 1* is the white box description of the overall system together with black +box descriptions of all contained building blocks. + +*Level 2* zooms into some building blocks of level 1. +Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks. + +*Level 3* zooms into selected building blocks of level 2, and so on. + + +.Further Information + +See https://docs.arc42.org/section-5/[Building Block View] in the arc42 documentation. + +**** + +=== Whitebox Overall System + +[role="arc42help"] +**** +Here you describe the decomposition of the overall system using the following white box template. It contains + + * an overview diagram + * a motivation for the decomposition + * black box descriptions of the contained building blocks. For these we offer you alternatives: + + ** use _one_ table for a short and pragmatic overview of all contained building blocks and their interfaces + ** use a list of black box descriptions of the building blocks according to the black box template (see below). + Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool). + + + * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. +Since there are so many ways to specify interfaces why do not provide a specific template for them. + In the worst case you have to specify and describe syntax, semantics, protocols, error handling, + restrictions, versions, qualities, necessary compatibilities and many things more. +In the best case you will get away with examples or simple signatures. + +**** + +_****_ + +Motivation:: + +__ + + +Contained Building Blocks:: +__ + +Important Interfaces:: +__ + +[role="arc42help"] +**** +Insert your explanations of black boxes from level 1: + +If you use tabular form you will only describe your black boxes with name and +responsibility according to the following schema: + +[cols="1,2" options="header"] +|=== +| **Name** | **Responsibility** +| __ | __ +| __ | __ +|=== + + + +If you use a list of black box descriptions then you fill in a separate black box template for every important building block . +Its headline is the name of the black box. +**** + + +==== + +[role="arc42help"] +**** +Here you describe +according the the following black box template: + +* Purpose/Responsibility +* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. +* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... +* (Optional) directory/file location +* (Optional) Fulfilled requirements (if you need traceability to requirements). +* (Optional) Open issues/problems/risks + +**** + +__ + +__ + +_<(Optional) Quality/Performance Characteristics>_ + +_<(Optional) Directory/File Location>_ + +_<(Optional) Fulfilled Requirements>_ + +_<(optional) Open Issues/Problems/Risks>_ + + + + +==== + +__ + +==== + +__ + + +==== + +... + +==== + + + +=== Level 2 + +[role="arc42help"] +**** +Here you can specify the inner structure of (some) building blocks from level 1 as white boxes. + +You have to decide which building blocks of your system are important enough to justify such a detailed description. +Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. +Leave out normal, simple, boring or standardized parts of your system +**** + +==== White Box __ + +[role="arc42help"] +**** +...describes the internal structure of _building block 1_. +**** + +__ + +==== White Box __ + + +__ + +... + +==== White Box __ + + +__ + + + +=== Level 3 + +[role="arc42help"] +**** +Here you can specify the inner structure of (some) building blocks from level 2 as white boxes. + +When you need more detailed levels of your architecture please copy this +part of arc42 for additional levels. +**** + + +==== White Box <_building block x.1_> + +[role="arc42help"] +**** +Specifies the internal structure of _building block x.1_. +**** + + +__ + + +==== White Box <_building block x.2_> + +__ + + + +==== White Box <_building block y.1_> + +__ diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc new file mode 100644 index 00000000..d13b7f9a --- /dev/null +++ b/RU/asciidoc/src/06_runtime_view.adoc @@ -0,0 +1,51 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-runtime-view]] +== Runtime View + + +[role="arc42help"] +**** +.Contents +The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas: + +* important use cases or features: how do building blocks execute them? +* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems? +* operation and administration: launch, start-up, stop +* error and exception scenarios + +Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection. + +.Motivation +You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. +You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view). + +.Form +There are many notations for describing scenarios, e.g. + +* numbered list of steps (in natural language) +* activity diagrams or flow charts +* sequence diagrams +* BPMN or EPCs (event process chains) +* state machines +* ... + + +.Further Information + +See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation. + +**** + +=== + + +* __ +* __ + +=== + +=== ... + +=== diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc new file mode 100644 index 00000000..22b45c27 --- /dev/null +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -0,0 +1,94 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-deployment-view]] + + +== Deployment View + +[role="arc42help"] +**** +.Content +The deployment view describes: + + 1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and + +2. mapping of (software) building blocks to that infrastructure elements. + +Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments. + +Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips. + +From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture. + +.Motivation +Software does not run without hardware. +This underlying infrastructure can and will influence a system and/or some +cross-cutting concepts. Therefore, there is a need to know the infrastructure. + +.Form + +Maybe a highest level deployment diagram is already contained in section 3.2. as +technical context with your own infrastructure as ONE black box. In this section one can +zoom into this black box using additional deployment diagrams: + +* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, +when your infrastructure is more complex. +* When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure. + + +.Further Information + +See https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentation. + +**** + +=== Infrastructure Level 1 + +[role="arc42help"] +**** +Describe (usually in a combination of diagrams, tables, and text): + +* distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them +* important justifications or motivations for this deployment structure +* quality and/or performance features of this infrastructure +* mapping of software artifacts to elements of this infrastructure + +For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments. +**** + +_****_ + +Motivation:: + +__ + +Quality and/or Performance Features:: + +__ + +Mapping of Building Blocks to Infrastructure:: +__ + + +=== Infrastructure Level 2 + +[role="arc42help"] +**** +Here you can include the internal structure of (some) infrastructure elements from level 1. + +Please copy the structure from level 1 for each selected element. +**** + +==== __ + +__ + +==== __ + +__ + +... + +==== __ + +__ diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc new file mode 100644 index 00000000..591ccf1f --- /dev/null +++ b/RU/asciidoc/src/08_concepts.adoc @@ -0,0 +1,73 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-concepts]] +== Cross-cutting Concepts + + +[role="arc42help"] +**** +.Content +This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. +Such concepts are often related to multiple building blocks. +They can include many different topics, such as + +* models, especially domain models +* architecture or design patterns +* rules for using specific technology +* principal, often technical decisions of an overarching (= cross-cutting) nature +* implementation rules + + +.Motivation +Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) of the architecture. +Thus, they are an important contribution to achieve inner qualities of your system. + +Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety. + + +.Form +The form can be varied: + +* concept papers with any kind of structure +* cross-cutting model excerpts or scenarios using notations of the architecture views +* sample implementations, especially for technical concepts +* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) + +.Structure +A potential (but not mandatory) structure for this section could be: + +* Domain concepts +* User Experience concepts (UX) +* Safety and security concepts +* Architecture and design patterns +* "Under-the-hood" +* development concepts +* operational concepts + +Note: it might be difficult to assign individual concepts to one specific topic +on this list. + +image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"] + + +.Further Information + +See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation. +**** + + +=== __ + +__ + + + +=== __ + +__ + +... + +=== __ + +__ diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc new file mode 100644 index 00000000..51e9aad9 --- /dev/null +++ b/RU/asciidoc/src/09_architecture_decisions.adoc @@ -0,0 +1,35 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-design-decisions]] +== Architecture Decisions + + +[role="arc42help"] +**** +.Contents +Important, expensive, large scale or risky architecture decisions including rationales. +With "decisions" we mean selecting one alternative based on given criteria. + +Please use your judgement to decide whether an architectural decision should be documented +here in this central section or whether you better document it locally +(e.g. within the white box template of one building block). + +Avoid redundancy. +Refer to section 4, where you already captured the most important decisions of your architecture. + +.Motivation +Stakeholders of your system should be able to comprehend and retrace your decisions. + +.Form +Various options: + +* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision +* List or table, ordered by importance and consequences or: +* more detailed in form of separate sections per decision + +.Further Information + +See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 documentation. +There you will find links and examples about ADR. + +**** diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc new file mode 100644 index 00000000..68475e80 --- /dev/null +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -0,0 +1,73 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-quality-scenarios]] +== Quality Requirements + + +[role="arc42help"] +**** + +.Content +This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) + +Here you can also capture quality requirements with lesser priority, +which will not create high risks when they are not fully achieved. + +.Motivation +Since quality requirements will have a lot of influence on architectural +decisions you should know for every stakeholder what is really important to them, +concrete and measurable. + + +.Further Information + +See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation. + +**** + +=== Quality Tree + +[role="arc42help"] +**** +.Content +The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. + +.Motivation +The tree structure with priorities provides an overview for a sometimes large number of quality requirements. + +.Form +The quality tree is a high-level overview of the quality goals and requirements: + +* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root +* a mind map with quality categories as main branches + +In any case the tree should include links to the scenarios of the following section. + + +**** + +=== Quality Scenarios + +[role="arc42help"] +**** +.Contents +Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. + +These scenarios describe what should happen when a stimulus arrives at the system. + +For architects, two kinds of scenarios are important: + +* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. +* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. + +.Motivation +Scenarios make quality requirements concrete and allow to +more easily measure or decide whether they are fulfilled. + +Especially when you want to assess your architecture using methods like +ATAM you need to describe your quality goals (from section 1.2) +more precisely down to a level of scenarios that can be discussed and evaluated. + +.Form +Tabular or free form text. +**** diff --git a/RU/asciidoc/src/11_technical_risks.adoc b/RU/asciidoc/src/11_technical_risks.adoc new file mode 100644 index 00000000..dc5575fc --- /dev/null +++ b/RU/asciidoc/src/11_technical_risks.adoc @@ -0,0 +1,25 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-technical-risks]] +== Risks and Technical Debts + + +[role="arc42help"] +**** +.Contents +A list of identified technical risks or technical debts, ordered by priority + +.Motivation +“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) + +This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning. + +.Form +List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts. + + +.Further Information + +See https://docs.arc42.org/section-11/[Risks and Technical Debt] in the arc42 documentation. + +**** diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc new file mode 100644 index 00000000..192b2353 --- /dev/null +++ b/RU/asciidoc/src/12_glossary.adoc @@ -0,0 +1,42 @@ +ifndef::imagesdir[:imagesdir: ../images] + +[[section-glossary]] +== Glossary + +[role="arc42help"] +**** +.Contents +The most important domain and technical terms that your stakeholders use when discussing the system. + +You can also see the glossary as source for translations if you work in multi-language teams. + +.Motivation +You should clearly define your terms, so that all stakeholders + +* have an identical understanding of these terms +* do not use synonyms and homonyms + + +.Form + +A table with columns and . + +Potentially more columns in case you need translations. + + +.Further Information + +See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation. + +**** + +[cols="e,2e" options="header"] +|=== +|Term |Definition + +| +| + +| +| +|=== diff --git a/RU/asciidoc/src/about-arc42.adoc b/RU/asciidoc/src/about-arc42.adoc new file mode 100644 index 00000000..a9d3ae47 --- /dev/null +++ b/RU/asciidoc/src/about-arc42.adoc @@ -0,0 +1,15 @@ +:homepage: https://arc42.org + +:keywords: software-architecture, documentation, template, arc42 + +:numbered!: +**About arc42** + +[role="lead"] +arc42, the template for documentation of software and system architecture. + +Template Version {revnumber}. {revremark}, {revdate} + +Created, maintained and (C) by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. +See https://arc42.org. + diff --git a/RU/asciidoc/src/config.adoc b/RU/asciidoc/src/config.adoc new file mode 100644 index 00000000..334d5291 --- /dev/null +++ b/RU/asciidoc/src/config.adoc @@ -0,0 +1,9 @@ +// asciidoc settings for EN (English) +// ================================== +:toc-title: table of contents + +// enable table-of-contents +:toc: + +// where are images located? +:imagesdir: ./images From 7ea97879ac3337af4b80bd8ee80001c4fa852206 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Mon, 12 Jun 2023 18:20:11 +0200 Subject: [PATCH 02/23] 2,3,4,5 in progress --- .../src/02_architecture_constraints.adoc | 26 ++-- RU/asciidoc/src/03_context_and_scope.adoc | 61 ++++++--- .../src/03_system_scope_and_context.adoc | 71 ----------- RU/asciidoc/src/04_solution_strategy.adoc | 26 +++- RU/asciidoc/src/05_building_block_view.adoc | 116 ++++++++++++++---- 5 files changed, 168 insertions(+), 132 deletions(-) delete mode 100644 RU/asciidoc/src/03_system_scope_and_context.adoc diff --git a/RU/asciidoc/src/02_architecture_constraints.adoc b/RU/asciidoc/src/02_architecture_constraints.adoc index 226e501f..b1dcba17 100644 --- a/RU/asciidoc/src/02_architecture_constraints.adoc +++ b/RU/asciidoc/src/02_architecture_constraints.adoc @@ -1,27 +1,27 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-architecture-constraints]] -== Architecture Constraints +== Архитектурные ограничения [role="arc42help"] **** -.Contents -Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies. +.Содержание +Любое требование, ограничивающее архитекторов программного обеспечения в их свободе проектирования и решений по реализации или в принятии решений о процессе разработки. Эти ограничения иногда выходят за рамки отдельных систем и действительны для целых организаций и компаний. -.Motivation -Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. -Constraints must always be dealt with; they may be negotiable, though. +.Мотивация +Архитекторы должны точно знать, где они свободны в своих проектных решениях, а где должны придерживаться ограничений. +С ограничениями всегда нужно иметь дело; хотя они могут быть предметом переговоров. -.Form -Simple tables of constraints with explanations. -If needed you can subdivide them into -technical constraints, organizational and political constraints and -conventions (e.g. programming or versioning guidelines, documentation or naming conventions) +.Форма +Простые таблицы ограничений с пояснениями. +При необходимости вы можете разделить их на +технические ограничения, организационные и политические ограничения и +соглашения (например, рекомендации по программированию или управлению версиями, документация или соглашения о наименованиях) -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation. +Смотрите https://docs.arc42.org/section-2/[Архитектурные ограничения] в документации arc42. **** diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc index e95083cf..69c125a3 100644 --- a/RU/asciidoc/src/03_context_and_scope.adoc +++ b/RU/asciidoc/src/03_context_and_scope.adoc @@ -6,25 +6,35 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Contents +.Содержание + Context and scope - as the name suggests - delimits your system (i.e. your scope) from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces. +Контекст и область действия — как следует из названия — разграничивают вашу систему (то есть область действия) от всех ее коммуникационных партнеров. +(соседние системы и пользователи, т.е. контекст вашей системы). Таким образом, он определяет внешние интерфейсы. + If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware). -.Motivation +При необходимости различайте бизнес-контекст (специфические для предметной области входы и выходы) и технический контекст (каналы, протоколы, аппаратное обеспечение). + +.Мотивация The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them. -.Form +.Форма Various options: * Context diagrams * Lists of communication partners and their interfaces. +Различные варианты: -.Further Information +* Контекстные диаграммы +* Списки коммуникационных партнеров и их интерфейсов. -See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation. +.Дальнейшая информация + +Смотрите https://docs.arc42.org/section-3/[Context and Scope] в документации arc42. **** @@ -33,43 +43,60 @@ See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentat [role="arc42help"] **** -.Contents +.Содержание Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces. Optionally you can add domain specific formats or communication protocols. -.Motivation +Спецификация *всех* коммуникационных партнеров (пользователи, ИТ-системы, ...) с пояснениями входных и выходных данных или интерфейсов, специфичных для предметной области. +При желании вы можете добавить специфичные для домена форматы или протоколы связи. + +.Мотивация All stakeholders should understand which data are exchanged with the environment of the system. -.Form +Все заинтересованные стороны должны понимать, какими данными происходит обмен со средой системы. + +.Форма All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners. Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs. +Все виды диаграмм, изображающих систему в виде черного ящика и определяющих интерфейсы домена для коммуникационных партнеров. + +В качестве альтернативы (или дополнительно) можно использовать таблицу. +Заголовок таблицы — это имя вашей системы, три столбца содержат имя партнера по связи, входы и выходы. + **** -**** +**<Диаграмма или таблица>** -**** +**<опционально: объяснение внешних доменных интерфейсов>** -=== Technical Context +=== Технический контекст [role="arc42help"] **** -.Contents +.Содержание Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel. -.Motivation +Технические интерфейсы (каналы и среды передачи), связывающие вашу систему с окружающей средой. Кроме того, сопоставление ввода/вывода, специфичного для предметной области, с каналами, то есть объяснение, какой ввод/вывод использует какой канал. + +.Мотивация Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces. -.Form +Многие заинтересованные стороны принимают архитектурные решения на основе технических интерфейсов между системой и ее контекстом. Особенно разработчики инфраструктуры или оборудования решают эти технические интерфейсы. + +.Форма E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output. +Например. Диаграмма развертывания UML, описывающая каналы к соседним системам, +вместе с таблицей сопоставления, показывающей взаимосвязь между каналами и вводом/выводом. + **** -**** +**<Диаграмма или таблица>** -**** +**<опционально: Пояснения к техническим интерфейсам>** -**** +**<Сопоставление ввода/вывода с каналами>** diff --git a/RU/asciidoc/src/03_system_scope_and_context.adoc b/RU/asciidoc/src/03_system_scope_and_context.adoc deleted file mode 100644 index 5e96c070..00000000 --- a/RU/asciidoc/src/03_system_scope_and_context.adoc +++ /dev/null @@ -1,71 +0,0 @@ -ifndef::imagesdir[:imagesdir: ../images] - -[[section-context-and-scope]] -== Область дії системи та її контекст - - -[role="arc42help"] -**** -.Зміст -Область дії системи та її контекст - як випливає з назви, відмежовують вашу систему (тобто вашу область) від усіх її партнерів по спілкуванню (сусідні системи та користувачі, тобто контекст вашої системи). Таким чином, вони визначають зовнішні інтерфейси. - -Якщо необхідно, відмежуйте бізнес-контекст (специфічні вхідні та вихідні данні домену) від технічного контексту (канали, протоколи, апаратне забезпечення). - -.Мотивація -Інтерфейси домену та технічні інтерфейси для комунікаційних партнерів є одними з найважливіших аспектів вашої системи. Переконайтеся, що ви їх повністю розумієте. - -.Форма -Різноманітні варіанти: - -* Контекстні діаграми -* Списки комунікаційних партнерів та їх інтерфейси. - - -.Додаткова інформація - -Див. https://docs.arc42.org/section-3/[Контекст і область дії] дії в документації arc42. - -**** - - -=== Бізнес контекст - -[role="arc42help"] -**** -.Зміст -Специфікація *всіх* комунікаційних партнерів (користувачів, ІТ-систем, …​) з поясненнями вхідних і вихідних даних або інтерфейсів, що стосуються конкретного домену. За бажанням ви можете додати специфічні для домену формати або протоколи зв’язку. - -.Мотивація -Усі зацікавлені сторони повинні розуміти, якими даними обмінюються із середовищем системи. - -.Форма -Різноманітні діаграми, які показують систему як чорний ящик і визначають інтерфейси домену для партнерів по спілкуванню. - -Як альтернативу (або додатково) можна використовувати таблицю. Заголовок таблиці – це ім’я вашої системи, три стовпці містять ім’я комунікаційного партнера, вхідні та вихідні данні. - -**** - -**<Діаграма або таблиця>** - -**<опціонально: Пояснення інтерфейсів зовнішнього домену>** - -=== Технічний контекст - -[role="arc42help"] -**** -.Зміст -Технічні інтерфейси (канали та засоби передачі), що з’єднують вашу систему з її середовищем. Крім того, відображення вводу/виводу, специфічного для домену, на канали, тобто пояснення щодо того, для якого вводу/виводу, який канал використовується. - -.Мотивація -Багато зацікавлених сторін приймають архітектурні рішення на основі технічних інтерфейсів між системою та її контекстом. Особливо розробники інфраструктури або апаратного забезпечення вирішують ці технічні інтерфейси. - -.Форма -Наприклад діаграма розгортання UML, що описує канали до сусідніх систем, разом із таблицею відображення, що показує зв’язки між каналами та вводом/виводом. - -**** - -**<Діаграма або таблиця>** - -**<опціонально: Пояснення технічних інтерфейсів>** - -**<Зіставлення вхідних/вихідних даних з каналами>** diff --git a/RU/asciidoc/src/04_solution_strategy.adoc b/RU/asciidoc/src/04_solution_strategy.adoc index 7bf03f7a..0a4141fc 100644 --- a/RU/asciidoc/src/04_solution_strategy.adoc +++ b/RU/asciidoc/src/04_solution_strategy.adoc @@ -1,32 +1,46 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-solution-strategy]] -== Solution Strategy +== Стратегия решения [role="arc42help"] **** -.Contents +.Содержание A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes +Краткое изложение и объяснение основных решений и стратегий решения, которые формируют архитектуру системы. Оно включает + +* технологические решения +* решения о декомпозиции системы на верхнем уровне, т.е. использование архитектурного шаблона или шаблона проектирования +* решения о том, как достичь ключевых целей в области качества +* соответствующие организационные решения, т.е. выбор процесса разработки или делегирование определенных задач третьим лицам. + * technology decisions * decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern * decisions on how to achieve key quality goals * relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties. -.Motivation +.Мотивация These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules. -.Form +Эти решения составляют основу вашей архитектуры. Они являются основой для многих других подробных решений или правил реализации. + +.Форма Keep the explanations of such key decisions short. +Делайте объяснения таких ключевых решений короткими. + Motivate what was decided and why it was decided that way, based upon problem statement, quality goals and key constraints. Refer to details in the following sections. +Мотивируйте, что было решено и почему было решено именно так, +на основе постановки задачи, целей в области качества и ключевых ограничений. +Подробности см. в следующих разделах. -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation. +Смотрите https://docs.arc42.org/section-4/[Solution Strategy] в документации arc42. **** diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index df5c29c8..78046442 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -3,27 +3,40 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-building-block-view]] -== Building Block View +== Представление строительных блоков [role="arc42help"] **** -.Content +.Содержание The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, ...) as well as their dependencies (relationships, associations, ...) +Представление стандартных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, платформы, слои, разделы, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...) + This view is mandatory for every architecture documentation. In analogy to a house this is the _floor plan_. -.Motivation +Это представление является обязательным для любой документации по архитектуре. +По аналогии с домом это план этажа. + +.Мотивация Maintain an overview of your source code by making its structure understandable through abstraction. +Следите за своим исходным кодом, делая его структуру понятной с помощью +абстракция. + This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details. -.Form +Это позволяет вам общаться с вашей заинтересованной стороной на абстрактном уровне, не раскрывая деталей реализации. + +.Форма The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions. -image::05_building_blocks-EN.png["Hierarchy of building blocks"] +Представление стандартных блоков представляет собой иерархическую коллекцию черных и белых ящиков. +(см. рисунок ниже) и их описания. + +image::05_building_blocks-EN.png["Иерархия строительных блоков"] *Level 1* is the white box description of the overall system together with black box descriptions of all contained building blocks. @@ -33,17 +46,26 @@ Thus it contains the white box description of selected building blocks of level *Level 3* zooms into selected building blocks of level 2, and so on. +*Уровень 1* представляет собой описание всей системы в белом поле вместе с черным +бокс описания всех содержащихся строительных блоков. + +*Уровень 2* увеличивает некоторые строительные блоки уровня 1. +Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием «черного ящика» их внутренних строительных блоков. -.Further Information +*Уровень 3* увеличивает масштаб выбранных строительных блоков уровня 2 и так далее. -See https://docs.arc42.org/section-5/[Building Block View] in the arc42 documentation. +.Дальнейшая информация + +Смотрите https://docs.arc42.org/section-5/[Представление строительных блоков] в документации arc42. **** -=== Whitebox Overall System +=== Whitebox Система в общем [role="arc42help"] **** +Здесь вы описываете декомпозицию всей системы, используя следующий шаблон белого ящика. Это содержит + Here you describe the decomposition of the overall system using the following white box template. It contains * an overview diagram @@ -54,6 +76,13 @@ Here you describe the decomposition of the overall system using the following wh ** use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool). +* обзорная схема +* мотивация разложения +* Описания черного ящика содержащихся строительных блоков. Для них мы предлагаем вам альтернативы: + +** используйте _one_ таблицу для краткого и практичного обзора всех содержащихся строительных блоков и их интерфейсов +** используйте список описаний составных частей «черного ящика» в соответствии с шаблоном «черного ящика» (см. ниже). +В зависимости от выбранного вами инструмента этот список может состоять из подглав (в текстовых файлах), подстраниц (в Wiki) или вложенных элементов (в инструменте моделирования). * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. @@ -61,20 +90,26 @@ Since there are so many ways to specify interfaces why do not provide a specific restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures. +* (необязательно:) важные интерфейсы, которые не объясняются в шаблонах черного ящика стандартного блока, но очень важны для понимания белого ящика. +Поскольку существует так много способов указать интерфейсы, почему бы не предоставить для них специальный шаблон. +В худшем случае вам придется указать и описать синтаксис, семантику, протоколы, обработку ошибок, +ограничения, версии, качества, необходимые совместимости и многое другое. +В лучшем случае вам сойдут с рук примеры или простые подписи. + **** -_****_ +_**<Обзорная диаграмма>**_ -Motivation:: +Мотивация:: -__ +_<текстовое объяснение>_ -Contained Building Blocks:: -__ +Содержащиеся строительные блоки:: +_<Описание содержащегося стандартного блока (черные ящики)>_ -Important Interfaces:: -__ +Важные интерфейсы:: +_<Описание важных интерфейсов>_ [role="arc42help"] **** @@ -83,17 +118,26 @@ Insert your explanations of black boxes from level 1: If you use tabular form you will only describe your black boxes with name and responsibility according to the following schema: +Вставьте свои объяснения черных ящиков из уровня 1: + +Если вы используете табличную форму, вы будете описывать только свои черные ящики с именем и +ответственности по следующей схеме: + [cols="1,2" options="header"] |=== -| **Name** | **Responsibility** -| __ | __ -| __ | __ +| **Название** | **Ответственность** +| __ | _<Текст>_ +| __ | _<Текст>_ |=== If you use a list of black box descriptions then you fill in a separate black box template for every important building block . Its headline is the name of the black box. + +Если вы используете список описаний черного ящика, то вы заполняете отдельный шаблон черного ящика для каждого важного стандартного блока. +Его заголовок — название черного ящика. + **** @@ -104,6 +148,9 @@ Its headline is the name of the black box. Here you describe according the the following black box template: +Здесь вы описываете <черный ящик 1> +в соответствии со следующим шаблоном черного ящика: + * Purpose/Responsibility * Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. * (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... @@ -111,19 +158,26 @@ according the the following black box template: * (Optional) Fulfilled requirements (if you need traceability to requirements). * (Optional) Open issues/problems/risks +* Цель/ответственность +* Интерфейс(ы), если они не извлекаются как отдельные абзацы. Эти интерфейсы могут включать качества и рабочие характеристики. +* (Необязательно) Характеристики качества/производительности черного ящика, например, доступность, поведение во время выполнения, .... +* (Необязательно) расположение каталога/файла +* (Необязательно) Выполненные требования (если вам нужна прослеживаемость к требованиям). +* (Необязательно) Открытые вопросы/проблемы/риски + **** -__ +_<Цель/обязанности>_ -__ +_<Интерфейс(ы)>_ -_<(Optional) Quality/Performance Characteristics>_ +_<(Необязательно) Характеристики качества/производительности>_ -_<(Optional) Directory/File Location>_ +_<(Необязательно) Папка/Расположение файла>_ -_<(Optional) Fulfilled Requirements>_ +_<(Необязательно) Выполненные требования>_ -_<(optional) Open Issues/Problems/Risks>_ +_<(необязательно) Открытые проблемы/проблемы/риски>_ @@ -145,7 +199,8 @@ __ -=== Level 2 + +=== Уровень 2 [role="arc42help"] **** @@ -154,6 +209,12 @@ Here you can specify the inner structure of (some) building blocks from level 1 You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system + +Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков уровня 1 в виде белых прямоугольников. + +Вы должны решить, какие строительные блоки вашей системы достаточно важны, чтобы оправдать такое подробное описание. +Пожалуйста, предпочтите релевантность полноте. Укажите важные, неожиданные, рискованные, сложные или изменчивые строительные блоки. +Исключите нормальные, простые, скучные или стандартизированные части вашей системы. **** ==== White Box __ @@ -187,6 +248,11 @@ Here you can specify the inner structure of (some) building blocks from level 2 When you need more detailed levels of your architecture please copy this part of arc42 for additional levels. + +Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков уровня 2 в виде белых прямоугольников. + +Если вам нужны более подробные уровни вашей архитектуры, пожалуйста, скопируйте это +часть arc42 для дополнительных уровней. **** From 2693d624cbea05e862a6505524ea5bf1eae5ae09 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Sun, 18 Jun 2023 22:03:44 +0200 Subject: [PATCH 03/23] < 5 --- RU/asciidoc/src/03_context_and_scope.adoc | 4 +- RU/asciidoc/src/04_solution_strategy.adoc | 24 ++---- RU/asciidoc/src/05_building_block_view.adoc | 83 ++++++--------------- 3 files changed, 30 insertions(+), 81 deletions(-) diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc index 69c125a3..104e31cb 100644 --- a/RU/asciidoc/src/03_context_and_scope.adoc +++ b/RU/asciidoc/src/03_context_and_scope.adoc @@ -70,7 +70,7 @@ The title of the table is the name of your system, the three columns contain the **<Диаграмма или таблица>** -**<опционально: объяснение внешних доменных интерфейсов>** +**<необязательно: объяснение внешних доменных интерфейсов>** === Технический контекст @@ -97,6 +97,6 @@ together with a mapping table showing the relationships between channels and inp **<Диаграмма или таблица>** -**<опционально: Пояснения к техническим интерфейсам>** +**<необязательно: Пояснения к техническим интерфейсам>** **<Сопоставление ввода/вывода с каналами>** diff --git a/RU/asciidoc/src/04_solution_strategy.adoc b/RU/asciidoc/src/04_solution_strategy.adoc index 0a4141fc..fa06bd89 100644 --- a/RU/asciidoc/src/04_solution_strategy.adoc +++ b/RU/asciidoc/src/04_solution_strategy.adoc @@ -7,40 +7,26 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** .Содержание -A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes -Краткое изложение и объяснение основных решений и стратегий решения, которые формируют архитектуру системы. Оно включает +Краткое изложение и объяснение основных решений и стратегии, формирующих архитектуру системы. Они включают * технологические решения * решения о декомпозиции системы на верхнем уровне, т.е. использование архитектурного шаблона или шаблона проектирования * решения о том, как достичь ключевых целей в области качества * соответствующие организационные решения, т.е. выбор процесса разработки или делегирование определенных задач третьим лицам. -* technology decisions -* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern -* decisions on how to achieve key quality goals -* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties. - .Мотивация -These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules. - -Эти решения составляют основу вашей архитектуры. Они являются основой для многих других подробных решений или правил реализации. +Эти решения ложатся в основу вашей архитектуры. На них опираются многие другие более специфические решения или правила реализации. .Форма -Keep the explanations of such key decisions short. - -Делайте объяснения таких ключевых решений короткими. - -Motivate what was decided and why it was decided that way, -based upon problem statement, quality goals and key constraints. -Refer to details in the following sections. +Объяснения таких ключевых решений должны быть короткими. -Мотивируйте, что было решено и почему было решено именно так, +Мотивируйте решение (и почему было решено именно так) на основе постановки задачи, целей в области качества и ключевых ограничений. Подробности см. в следующих разделах. .Дальнейшая информация -Смотрите https://docs.arc42.org/section-4/[Solution Strategy] в документации arc42. +Смотрите https://docs.arc42.org/section-4/[Стратегия решения] в документации arc42. **** diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index 78046442..f64a58f0 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -10,47 +10,32 @@ ifndef::imagesdir[:imagesdir: ../images] .Содержание The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, ...) as well as their dependencies (relationships, associations, ...) -Представление стандартных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, платформы, слои, разделы, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...) +Представление строительных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, платформы, слои, разделы, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...) -This view is mandatory for every architecture documentation. -In analogy to a house this is the _floor plan_. - -Это представление является обязательным для любой документации по архитектуре. -По аналогии с домом это план этажа. +Это представление является обязательным для любой архитектурной документации. +По аналогии с домом это _план этажа_. .Мотивация -Maintain an overview of your source code by making its structure understandable through -abstraction. - -Следите за своим исходным кодом, делая его структуру понятной с помощью -абстракция. +Поддерживайте структуру исходного кода понятной с помощью абстракций. -This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details. - -Это позволяет вам общаться с вашей заинтересованной стороной на абстрактном уровне, не раскрывая деталей реализации. +Это позволит вам общаться с заинтересованными лицами на абстрактном уровне, не раскрывая деталей реализации. .Форма -The building block view is a hierarchical collection of black boxes and white boxes -(see figure below) and their descriptions. - Представление стандартных блоков представляет собой иерархическую коллекцию черных и белых ящиков. (см. рисунок ниже) и их описания. image::05_building_blocks-EN.png["Иерархия строительных блоков"] -*Level 1* is the white box description of the overall system together with black +*Уровень 1* is the white box description of the overall system together with black box descriptions of all contained building blocks. +*Уровень 1* представляет собой описание всей системы в виде «белого ящика» вместе с описаниями всех содержащихся строительных блоков в виде «черных ящиков». + *Level 2* zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks. -*Level 3* zooms into selected building blocks of level 2, and so on. - -*Уровень 1* представляет собой описание всей системы в белом поле вместе с черным -бокс описания всех содержащихся строительных блоков. - -*Уровень 2* увеличивает некоторые строительные блоки уровня 1. -Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием «черного ящика» их внутренних строительных блоков. +*Уровень 2* раскрывает детали некоторых строительных блоков уровня 1. +Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием их внутренних строительных блоков как «черных ящиков». *Уровень 3* увеличивает масштаб выбранных строительных блоков уровня 2 и так далее. @@ -60,37 +45,23 @@ Thus it contains the white box description of selected building blocks of level **** -=== Whitebox Система в общем +=== Система в общем («белый ящик») [role="arc42help"] **** -Здесь вы описываете декомпозицию всей системы, используя следующий шаблон белого ящика. Это содержит +Здесь вы описываете декомпозицию всей системы, используя следующий шаблон белого ящика. Описание содержит -Here you describe the decomposition of the overall system using the following white box template. It contains +* обзорную схему +* мотивацию декомпозиции +* описания содержащихся строительных блоков («черный ящик»). Для них мы предлагаем альтернативы: - * an overview diagram - * a motivation for the decomposition - * black box descriptions of the contained building blocks. For these we offer you alternatives: - - ** use _one_ table for a short and pragmatic overview of all contained building blocks and their interfaces - ** use a list of black box descriptions of the building blocks according to the black box template (see below). - Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool). - -* обзорная схема -* мотивация разложения -* Описания черного ящика содержащихся строительных блоков. Для них мы предлагаем вам альтернативы: - -** используйте _one_ таблицу для краткого и практичного обзора всех содержащихся строительных блоков и их интерфейсов +** используйте _одну_ таблицу для краткого и практичного обзора всех содержащихся строительных блоков и их интерфейсов ** используйте список описаний составных частей «черного ящика» в соответствии с шаблоном «черного ящика» (см. ниже). + В зависимости от выбранного вами инструмента этот список может состоять из подглав (в текстовых файлах), подстраниц (в Wiki) или вложенных элементов (в инструменте моделирования). - * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. -Since there are so many ways to specify interfaces why do not provide a specific template for them. - In the worst case you have to specify and describe syntax, semantics, protocols, error handling, - restrictions, versions, qualities, necessary compatibilities and many things more. -In the best case you will get away with examples or simple signatures. -* (необязательно:) важные интерфейсы, которые не объясняются в шаблонах черного ящика стандартного блока, но очень важны для понимания белого ящика. +* (необязательно:) важные интерфейсы, которые не объясняются в шаблонах «черного ящика» строительных блоков, но очень важны для понимания белого «ящика». Поскольку существует так много способов указать интерфейсы, почему бы не предоставить для них специальный шаблон. В худшем случае вам придется указать и описать синтаксис, семантику, протоколы, обработку ошибок, ограничения, версии, качества, необходимые совместимости и многое другое. @@ -113,12 +84,8 @@ _<Описание важных интерфейсов>_ [role="arc42help"] **** -Insert your explanations of black boxes from level 1: -If you use tabular form you will only describe your black boxes with name and -responsibility according to the following schema: - -Вставьте свои объяснения черных ящиков из уровня 1: +Вставьте свои объяснения черных «ящиков» из уровня 1: Если вы используете табличную форму, вы будете описывать только свои черные ящики с именем и ответственности по следующей схеме: @@ -126,22 +93,18 @@ responsibility according to the following schema: [cols="1,2" options="header"] |=== | **Название** | **Ответственность** -| __ | _<Текст>_ -| __ | _<Текст>_ +| _<Черный ящик 1>_ | _<Текст>_ +| _<Черный ящик 2>_ | _<Текст>_ |=== - -If you use a list of black box descriptions then you fill in a separate black box template for every important building block . -Its headline is the name of the black box. - -Если вы используете список описаний черного ящика, то вы заполняете отдельный шаблон черного ящика для каждого важного стандартного блока. +Если вы используете список описаний «черного ящика», то вы заполняете отдельный шаблон «черного ящика» для каждого важного стандартного блока. Его заголовок — название черного ящика. **** -==== +==== <Название черного ящика 1> [role="arc42help"] **** From f0f2a588599016404c20a1e22c690691e4e7f21d Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 20 Jun 2023 23:42:25 +0200 Subject: [PATCH 04/23] 5 --- RU/asciidoc/src/05_building_block_view.adoc | 72 ++++++++------------- 1 file changed, 26 insertions(+), 46 deletions(-) diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index f64a58f0..f74d80f1 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -108,22 +108,13 @@ _<Описание важных интерфейсов>_ [role="arc42help"] **** -Here you describe -according the the following black box template: Здесь вы описываете <черный ящик 1> -в соответствии со следующим шаблоном черного ящика: - -* Purpose/Responsibility -* Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics. -* (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, .... -* (Optional) directory/file location -* (Optional) Fulfilled requirements (if you need traceability to requirements). -* (Optional) Open issues/problems/risks +в соответствии со следующим шаблоном: * Цель/ответственность -* Интерфейс(ы), если они не извлекаются как отдельные абзацы. Эти интерфейсы могут включать качества и рабочие характеристики. -* (Необязательно) Характеристики качества/производительности черного ящика, например, доступность, поведение во время выполнения, .... +* Интерфейс(ы), если они не описаны отдельными абзацами. Эти интерфейсы могут включать качества и характеристики производительности. +* (Необязательно) Характеристики качества/производительности «черного ящика», например, доступность, поведение во время выполнения, .... * (Необязательно) расположение каталога/файла * (Необязательно) Выполненные требования (если вам нужна прослеживаемость к требованиям). * (Необязательно) Открытые вопросы/проблемы/риски @@ -145,20 +136,20 @@ _<(необязательно) Открытые проблемы/проблем -==== +==== <Название черного ящика 2> -__ +_<шаблон черного ящика>_ -==== +==== <Название черного ящика n> -__ +_<шаблон черного ящика>_ -==== +==== <Название интерфейса 1> ... -==== +==== <Название интерфейса m> @@ -167,39 +158,34 @@ __ [role="arc42help"] **** -Here you can specify the inner structure of (some) building blocks from level 1 as white boxes. - -You have to decide which building blocks of your system are important enough to justify such a detailed description. -Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. -Leave out normal, simple, boring or standardized parts of your system - -Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков уровня 1 в виде белых прямоугольников. +Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков первого уровня в виде «белого ящика». Вы должны решить, какие строительные блоки вашей системы достаточно важны, чтобы оправдать такое подробное описание. Пожалуйста, предпочтите релевантность полноте. Укажите важные, неожиданные, рискованные, сложные или изменчивые строительные блоки. Исключите нормальные, простые, скучные или стандартизированные части вашей системы. **** -==== White Box __ +==== Белый ящик _<строительный блок 1>_ [role="arc42help"] **** -...describes the internal structure of _building block 1_. +...описывает внутреннюю структуру _строительного блока 1_. + **** -__ +_<шаблон белого ящика>_ -==== White Box __ +==== Белый ящик _<строительный блок 2>_ -__ +_<шаблон белого ящика>_ ... -==== White Box __ +==== Белый ящик _<строительный блок m>_ -__ +_<шаблон белого ящика>_ @@ -207,35 +193,29 @@ __ [role="arc42help"] **** -Here you can specify the inner structure of (some) building blocks from level 2 as white boxes. - -When you need more detailed levels of your architecture please copy this -part of arc42 for additional levels. - -Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков уровня 2 в виде белых прямоугольников. -Если вам нужны более подробные уровни вашей архитектуры, пожалуйста, скопируйте это +Если вам нужны более подробные уровни вашей архитектуры, скопируйте эту часть arc42 для дополнительных уровней. **** -==== White Box <_building block x.1_> +==== Белый ящик <_строительный блок x.1_> [role="arc42help"] **** -Specifies the internal structure of _building block x.1_. +Specifies the internal structure of _строительный блок x.1_. **** -__ +_<шаблон белого ящика>_ -==== White Box <_building block x.2_> +==== Белый ящик <_строительный блок x.2_> -__ +_<шаблон белого ящика>_ -==== White Box <_building block y.1_> +==== Белый ящик <_строительный блок y.1_> -__ +_<шаблон белого ящика>_ From 35023869fe5acb8831ade64636d2f426a7bab051 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 20 Jun 2023 23:47:28 +0200 Subject: [PATCH 05/23] 6 --- RU/asciidoc/src/06_runtime_view.adoc | 50 ++++++++++++++----- RU/asciidoc/src/07_deployment_view.adoc | 8 +-- RU/asciidoc/src/08_concepts.adoc | 8 +-- .../src/09_architecture_decisions.adoc | 10 ++-- RU/asciidoc/src/10_quality_requirements.adoc | 16 +++--- RU/asciidoc/src/11_technical_risks.adoc | 10 ++-- RU/asciidoc/src/12_glossary.adoc | 10 ++-- 7 files changed, 68 insertions(+), 44 deletions(-) diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc index d13b7f9a..4a03f157 100644 --- a/RU/asciidoc/src/06_runtime_view.adoc +++ b/RU/asciidoc/src/06_runtime_view.adoc @@ -3,10 +3,9 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-runtime-view]] == Runtime View - [role="arc42help"] **** -.Contents +.Содержание The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas: * important use cases or features: how do building blocks execute them? @@ -14,13 +13,29 @@ The runtime view describes concrete behavior and interactions of the system’s * operation and administration: launch, start-up, stop * error and exception scenarios -Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection. +Представление времени выполнения описывает конкретное поведение и взаимодействие строительных блоков системы в виде сценариев из следующих областей: + +* важные варианты использования или функции: как строительные блоки их выполняют? +* взаимодействия на критических внешних интерфейсах: как строительные блоки взаимодействуют с пользователями и соседними системами? +* эксплуатация и администрирование: запуск, запуск, остановка +* сценарии ошибок и исключений + +Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. +It is *not* important to describe a large number of scenarios. +You should rather document a representative selection. -.Motivation +Примечание: Основным критерием выбора возможных сценариев (последовательностей, рабочих процессов) является их *архитектурная релевантность*. +*Не* важно описывать большое количество сценариев. +Вам лучше задокументировать репрезентативный выбор. + +.Мотивация You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view). -.Form +Вы должны понимать, как (экземпляры) строительных блоков вашей системы выполняют свою работу и взаимодействуют во время выполнения. +В основном вы будете фиксировать сценарии в своей документации, чтобы сообщить о своей архитектуре заинтересованным сторонам, которые менее склонны или не способны читать и понимать статические модели (представление стандартных блоков, представление развертывания). + +.Форма There are many notations for describing scenarios, e.g. * numbered list of steps (in natural language) @@ -31,21 +46,30 @@ There are many notations for describing scenarios, e.g. * ... -.Further Information +Существует множество обозначений для описания сценариев, например. -See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation. +* пронумерованный список шагов (на естественном языке) +* диаграммы деятельности или блок-схемы +* диаграммы последовательности +* BPMN или EPC (цепочки событий) +* государственные машины +* ... -**** +.Дальнейшая информация +Смотри https://docs.arc42.org/section-6/[Runtime View] в документации arc42. -=== +**** +=== <Сценарий времени выполнения 1> * __ -* __ +* __ + +* _<вставьте диаграмму выполнения или текстовое описание сценария>_ +* _<вставьте описание важных аспектов взаимодействия между экземплярами стандартных блоков, изображенных на этой диаграмме.>_ -=== +=== <Сценарий времени выполнения 2> === ... -=== +=== <Сценарий времени выполнения n> diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 22b45c27..6972933e 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -20,12 +20,12 @@ Especially document a deployment view if your software is executed as distribute From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture. -.Motivation +.Мотивация Software does not run without hardware. This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. Therefore, there is a need to know the infrastructure. -.Form +.Форма Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can @@ -36,9 +36,9 @@ when your infrastructure is more complex. * When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure. -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentation. +See https://docs.arc42.org/section-7/[Deployment View] в документации arc42. **** diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index 591ccf1f..935a5a92 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -18,14 +18,14 @@ They can include many different topics, such as * implementation rules -.Motivation +.Мотивация Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) of the architecture. Thus, they are an important contribution to achieve inner qualities of your system. Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety. -.Form +.Форма The form can be varied: * concept papers with any kind of structure @@ -50,9 +50,9 @@ on this list. image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"] -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation. +See https://docs.arc42.org/section-8/[Concepts] в документации arc42. **** diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc index 51e9aad9..e6b7b27d 100644 --- a/RU/asciidoc/src/09_architecture_decisions.adoc +++ b/RU/asciidoc/src/09_architecture_decisions.adoc @@ -6,7 +6,7 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Contents +.Содержание Important, expensive, large scale or risky architecture decisions including rationales. With "decisions" we mean selecting one alternative based on given criteria. @@ -17,19 +17,19 @@ here in this central section or whether you better document it locally Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture. -.Motivation +.Мотивация Stakeholders of your system should be able to comprehend and retrace your decisions. -.Form +.Форма Various options: * ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision * List or table, ordered by importance and consequences or: * more detailed in form of separate sections per decision -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 documentation. +See https://docs.arc42.org/section-9/[Architecture Decisions] в документации arc42. There you will find links and examples about ADR. **** diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc index 68475e80..89cc0377 100644 --- a/RU/asciidoc/src/10_quality_requirements.adoc +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -13,15 +13,15 @@ This section contains all quality requirements as quality tree with scenarios. T Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved. -.Motivation +.Мотивация Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable. -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 documentation. +See https://docs.arc42.org/section-10/[Quality Requirements] в документации arc42. **** @@ -32,10 +32,10 @@ See https://docs.arc42.org/section-10/[Quality Requirements] in the arc42 docume .Content The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. -.Motivation +.Мотивация The tree structure with priorities provides an overview for a sometimes large number of quality requirements. -.Form +.Форма The quality tree is a high-level overview of the quality goals and requirements: * tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root @@ -50,7 +50,7 @@ In any case the tree should include links to the scenarios of the following sect [role="arc42help"] **** -.Contents +.Содержание Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. These scenarios describe what should happen when a stimulus arrives at the system. @@ -60,7 +60,7 @@ For architects, two kinds of scenarios are important: * Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. * Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. -.Motivation +.Мотивация Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled. @@ -68,6 +68,6 @@ Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated. -.Form +.Форма Tabular or free form text. **** diff --git a/RU/asciidoc/src/11_technical_risks.adoc b/RU/asciidoc/src/11_technical_risks.adoc index dc5575fc..3b0a2f43 100644 --- a/RU/asciidoc/src/11_technical_risks.adoc +++ b/RU/asciidoc/src/11_technical_risks.adoc @@ -6,20 +6,20 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Contents +.Содержание A list of identified technical risks or technical debts, ordered by priority -.Motivation +.Мотивация “Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning. -.Form +.Форма List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts. -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-11/[Risks and Technical Debt] in the arc42 documentation. +See https://docs.arc42.org/section-11/[Risks and Technical Debt] в документации arc42. **** diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc index 192b2353..91df1ecd 100644 --- a/RU/asciidoc/src/12_glossary.adoc +++ b/RU/asciidoc/src/12_glossary.adoc @@ -5,28 +5,28 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Contents +.Содержание The most important domain and technical terms that your stakeholders use when discussing the system. You can also see the glossary as source for translations if you work in multi-language teams. -.Motivation +.Мотивация You should clearly define your terms, so that all stakeholders * have an identical understanding of these terms * do not use synonyms and homonyms -.Form +.Форма A table with columns and . Potentially more columns in case you need translations. -.Further Information +.Дальнейшая информация -See https://docs.arc42.org/section-12/[Glossary] in the arc42 documentation. +See https://docs.arc42.org/section-12/[Glossary] в документации arc42. **** From fe429622bb70462d077f94dfd012354ab05f93d5 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 20 Jun 2023 23:52:02 +0200 Subject: [PATCH 06/23] 6 --- RU/asciidoc/src/06_runtime_view.adoc | 37 ++++------------------------ 1 file changed, 5 insertions(+), 32 deletions(-) diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc index 4a03f157..0ccb81f3 100644 --- a/RU/asciidoc/src/06_runtime_view.adoc +++ b/RU/asciidoc/src/06_runtime_view.adoc @@ -6,13 +6,6 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** .Содержание -The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas: - -* important use cases or features: how do building blocks execute them? -* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems? -* operation and administration: launch, start-up, stop -* error and exception scenarios - Представление времени выполнения описывает конкретное поведение и взаимодействие строительных блоков системы в виде сценариев из следующих областей: * важные варианты использования или функции: как строительные блоки их выполняют? @@ -20,39 +13,22 @@ The runtime view describes concrete behavior and interactions of the system’s * эксплуатация и администрирование: запуск, запуск, остановка * сценарии ошибок и исключений -Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. -It is *not* important to describe a large number of scenarios. -You should rather document a representative selection. - Примечание: Основным критерием выбора возможных сценариев (последовательностей, рабочих процессов) является их *архитектурная релевантность*. -*Не* важно описывать большое количество сценариев. +*Не* нужно без надобности описывать большое количество сценариев. Вам лучше задокументировать репрезентативный выбор. .Мотивация -You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. -You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view). - Вы должны понимать, как (экземпляры) строительных блоков вашей системы выполняют свою работу и взаимодействуют во время выполнения. В основном вы будете фиксировать сценарии в своей документации, чтобы сообщить о своей архитектуре заинтересованным сторонам, которые менее склонны или не способны читать и понимать статические модели (представление стандартных блоков, представление развертывания). .Форма -There are many notations for describing scenarios, e.g. - -* numbered list of steps (in natural language) -* activity diagrams or flow charts -* sequence diagrams -* BPMN or EPCs (event process chains) -* state machines -* ... - - Существует множество обозначений для описания сценариев, например. * пронумерованный список шагов (на естественном языке) -* диаграммы деятельности или блок-схемы -* диаграммы последовательности -* BPMN или EPC (цепочки событий) -* государственные машины +* диаграммы деятельности (activity diagrams) или блок-схемы +* диаграммы последовательности (sequence diagrams) +* BPMN или EPC (цепочки обработки событий) +* конечные автоматы * ... .Дальнейшая информация @@ -62,9 +38,6 @@ There are many notations for describing scenarios, e.g. === <Сценарий времени выполнения 1> -* __ -* __ - * _<вставьте диаграмму выполнения или текстовое описание сценария>_ * _<вставьте описание важных аспектов взаимодействия между экземплярами стандартных блоков, изображенных на этой диаграмме.>_ From f130d0de1a582107190a1da4a48ef3e4beb3d2d8 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 20 Jun 2023 23:55:11 +0200 Subject: [PATCH 07/23] 7 --- RU/asciidoc/src/07_deployment_view.adoc | 2 +- RU/asciidoc/src/08_concepts.adoc | 2 +- RU/asciidoc/src/10_quality_requirements.adoc | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 6972933e..33553245 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -7,7 +7,7 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Content +.Содержание The deployment view describes: 1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index 935a5a92..72e883ee 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -6,7 +6,7 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Content +.Содержание This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. Such concepts are often related to multiple building blocks. They can include many different topics, such as diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc index 89cc0377..4df0da48 100644 --- a/RU/asciidoc/src/10_quality_requirements.adoc +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -7,7 +7,7 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Content +.Содержание This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) Here you can also capture quality requirements with lesser priority, @@ -29,7 +29,7 @@ See https://docs.arc42.org/section-10/[Quality Requirements] в документ [role="arc42help"] **** -.Content +.Содержание The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. .Мотивация From 6a63f802c65b0a995cbee75867fdf243f1955543 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Wed, 21 Jun 2023 00:02:56 +0200 Subject: [PATCH 08/23] 7 --- RU/asciidoc/src/07_deployment_view.adoc | 62 ++++++++++++++++++------- 1 file changed, 45 insertions(+), 17 deletions(-) diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 33553245..fd396407 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -1,8 +1,6 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-deployment-view]] - - == Deployment View [role="arc42help"] @@ -10,34 +8,57 @@ ifndef::imagesdir[:imagesdir: ../images] .Содержание The deployment view describes: - 1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and +1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and 2. mapping of (software) building blocks to that infrastructure elements. -Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments. +Представление развертывания описывает: + +1. техническая инфраструктура, используемая для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и + +2. сопоставление строительных блоков (программного обеспечения) с этими элементами инфраструктуры. + +Often systems are executed in different environments, e.g. development environment, test environment, production environment. +In such cases you should document all relevant environments. Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips. -From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture. +From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. +Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture. + +Часто системы выполняются в разных средах, например. среда разработки, тестовая среда, производственная среда. +В таких случаях вы должны задокументировать все соответствующие среды. + +Особенно задокументируйте представление развертывания, если ваше программное обеспечение выполняется как распределенная система с более чем одним компьютером, процессором, сервером или контейнером или когда вы проектируете и создаете свои собственные аппаратные процессоры и микросхемы. + +С точки зрения программного обеспечения достаточно зафиксировать только те элементы инфраструктуры, которые необходимы для демонстрации развертывания ваших стандартных блоков. +Архитекторы аппаратного обеспечения могут пойти дальше и описать инфраструктуру с любым уровнем детализации, который им необходим. .Мотивация Software does not run without hardware. -This underlying infrastructure can and will influence a system and/or some -cross-cutting concepts. Therefore, there is a need to know the infrastructure. +This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. +Therefore, there is a need to know the infrastructure. + +Программное обеспечение не работает без аппаратного обеспечения. +Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные концепции. +Поэтому необходимо знать инфраструктуру. .Форма +Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. +In this section one can zoom into this black box using additional deployment diagrams: -Maybe a highest level deployment diagram is already contained in section 3.2. as -technical context with your own infrastructure as ONE black box. In this section one can -zoom into this black box using additional deployment diagrams: +Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. как технический контекст с собственной инфраструктурой как ОДИН черный ящик. +В этом разделе можно увеличить этот черный ящик, используя дополнительные диаграммы развертывания: -* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, -when your infrastructure is more complex. +* UML offers deployment diagrams to express that view. +Use it, probably with nested diagrams, when your infrastructure is more complex. * When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure. +* UML предлагает диаграммы развертывания, чтобы выразить это представление. +Используйте его, возможно, с вложенными диаграммами, когда ваша инфраструктура более сложна. +* Когда заинтересованные стороны (аппаратного обеспечения) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры. .Дальнейшая информация - See https://docs.arc42.org/section-7/[Deployment View] в документации arc42. **** @@ -54,22 +75,30 @@ Describe (usually in a combination of diagrams, tables, and text): * mapping of software artifacts to elements of this infrastructure For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments. + +Опишите (обычно в комбинации диаграмм, таблиц и текста): + +* распределение системы по нескольким местоположениям, средам, компьютерам, процессорам и т. д., а также физическим соединениям между ними +* важные обоснования или мотивы для этой структуры развертывания +* характеристики качества и/или производительности этой инфраструктуры +* сопоставление программных артефактов с элементами этой инфраструктуры + +Для нескольких сред или альтернативных развертываний скопируйте и адаптируйте этот раздел arc42 для всех соответствующих сред. **** _****_ Motivation:: -__ +_<объяснение в текстовом виде>_ Quality and/or Performance Features:: -__ +_<объяснение в текстовом виде>_ Mapping of Building Blocks to Infrastructure:: __ - === Infrastructure Level 2 [role="arc42help"] @@ -88,7 +117,6 @@ __ __ ... - ==== __ __ From 03a07cbba153c5998220b2058f8984cd5d4683ec Mon Sep 17 00:00:00 2001 From: max arshinov Date: Wed, 21 Jun 2023 00:08:16 +0200 Subject: [PATCH 09/23] 7 --- RU/asciidoc/src/07_deployment_view.adoc | 29 +++++-------------------- 1 file changed, 5 insertions(+), 24 deletions(-) diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index fd396407..05bc1f22 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -5,42 +5,23 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** -.Содержание -The deployment view describes: - -1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and - -2. mapping of (software) building blocks to that infrastructure elements. - Представление развертывания описывает: -1. техническая инфраструктура, используемая для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и +1. техническую инфраструктуру, используемуя для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и 2. сопоставление строительных блоков (программного обеспечения) с этими элементами инфраструктуры. -Often systems are executed in different environments, e.g. development environment, test environment, production environment. -In such cases you should document all relevant environments. - -Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips. - -From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. -Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture. - -Часто системы выполняются в разных средах, например. среда разработки, тестовая среда, производственная среда. +Часто системы выполняются в разных средах, например. среда разработки, тестовая среда, продакшн. В таких случаях вы должны задокументировать все соответствующие среды. -Особенно задокументируйте представление развертывания, если ваше программное обеспечение выполняется как распределенная система с более чем одним компьютером, процессором, сервером или контейнером или когда вы проектируете и создаете свои собственные аппаратные процессоры и микросхемы. +Особенно важно задокументировать представление развертывания, если ваше программное обеспечение выполняется в виде распределенной системы с более чем одним компьютером, процессором, сервером или контейнером; или когда вы проектируете и создаете свои собственные аппаратные процессоры и микросхемы. -С точки зрения программного обеспечения достаточно зафиксировать только те элементы инфраструктуры, которые необходимы для демонстрации развертывания ваших стандартных блоков. +С точки зрения программного обеспечения достаточно зафиксировать только те элементы инфраструктуры, которые необходимы для демонстрации развертывания ваших строительных блоков. Архитекторы аппаратного обеспечения могут пойти дальше и описать инфраструктуру с любым уровнем детализации, который им необходим. .Мотивация -Software does not run without hardware. -This underlying infrastructure can and will influence a system and/or some cross-cutting concepts. -Therefore, there is a need to know the infrastructure. - Программное обеспечение не работает без аппаратного обеспечения. -Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные концепции. +Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные (cross-cutting) концепции. Поэтому необходимо знать инфраструктуру. .Форма From 004125c724bfc17a4f41381a59e8efa38eaa7eea Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 13:53:47 +0200 Subject: [PATCH 10/23] 07 --- RU/asciidoc/src/07_deployment_view.adoc | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 05bc1f22..94a0dca3 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -28,16 +28,12 @@ ifndef::imagesdir[:imagesdir: ../images] Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams: -Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. как технический контекст с собственной инфраструктурой как ОДИН черный ящик. -В этом разделе можно увеличить этот черный ящик, используя дополнительные диаграммы развертывания: - -* UML offers deployment diagrams to express that view. -Use it, probably with nested diagrams, when your infrastructure is more complex. -* When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure. +Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанной ОДНИМ черным ящиком. +В этом разделе можно раскрыть этот черный ящик, используя дополнительные диаграммы развертывания: * UML предлагает диаграммы развертывания, чтобы выразить это представление. -Используйте его, возможно, с вложенными диаграммами, когда ваша инфраструктура более сложна. -* Когда заинтересованные стороны (аппаратного обеспечения) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры. +Используйте его, возможно, с вложенными диаграммами, в случае если ваша инфраструктура более сложна. +* Если заинтересованные стороны (связанные с аппаратным обеспечением) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры. .Дальнейшая информация See https://docs.arc42.org/section-7/[Deployment View] в документации arc42. From 16a3a8dc51069b401d19707046e5907a36850a00 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 14:03:09 +0200 Subject: [PATCH 11/23] 8 --- RU/asciidoc/src/07_deployment_view.adoc | 2 +- RU/asciidoc/src/08_concepts.adoc | 61 +++++++++---------- .../src/09_architecture_decisions.adoc | 2 +- RU/asciidoc/src/10_quality_requirements.adoc | 2 +- RU/asciidoc/src/11_technical_risks.adoc | 2 +- RU/asciidoc/src/12_glossary.adoc | 2 +- RU/asciidoc/src/about-arc42.adoc | 2 +- 7 files changed, 36 insertions(+), 37 deletions(-) diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 94a0dca3..7b120fe4 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -36,7 +36,7 @@ In this section one can zoom into this black box using additional deployment dia * Если заинтересованные стороны (связанные с аппаратным обеспечением) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры. .Дальнейшая информация -See https://docs.arc42.org/section-7/[Deployment View] в документации arc42. +Смотри https://docs.arc42.org/section-7/[Deployment View] в документации arc42. **** diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index 72e883ee..cb7e52af 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -1,29 +1,29 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-concepts]] -== Cross-cutting Concepts +== Сквозные концепции [role="arc42help"] **** .Содержание -This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. -Such concepts are often related to multiple building blocks. -They can include many different topics, such as +В этом разделе описываются главные правила и идеи решений, которые применимы к нескольким частям (= сквозные) вашей системы. +Такие концепции часто связаны с несколькими строительными блоками. +Они могут включать множество различных тем, таких как -* models, especially domain models -* architecture or design patterns -* rules for using specific technology -* principal, often technical decisions of an overarching (= cross-cutting) nature -* implementation rules +* модели, особенно модели предметной области +* архитектура или шаблоны дизайна +* правила использования конкретных технологий +* принципиальные, часто технические решения всеобъемлющего (= сквозного) характера +* правила реализации .Мотивация -Concepts form the basis for _conceptual integrity_ (consistency, homogeneity) of the architecture. -Thus, they are an important contribution to achieve inner qualities of your system. -Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety. +Концепции составляют основу _концептуальной целостности_ (непротиворечивости, однородности) архитектуры. +Таким образом, они являются важным вкладом в достижение внутренних качеств вашей системы. +Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительноси. .Форма The form can be varied: @@ -33,41 +33,40 @@ The form can be varied: * sample implementations, especially for technical concepts * reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) -.Structure -A potential (but not mandatory) structure for this section could be: + .Структура +Потенциальная (но не обязательная) структура этого раздела может быть следующей: -* Domain concepts -* User Experience concepts (UX) -* Safety and security concepts -* Architecture and design patterns -* "Under-the-hood" -* development concepts -* operational concepts +* Концепции домена +* Концепции взаимодействия с пользователем (UX) +* Концепции безопасности и защиты +* Архитектура и шаблоны проектирования +* "Под капотом" +* концепции развития +* операционные концепции -Note: it might be difficult to assign individual concepts to one specific topic -on this list. +Примечание: может быть сложно отнести отдельные концепции к одной конкретной теме в этом списке. -image::08-Crosscutting-Concepts-Structure-EN.png["Possible topics for crosscutting concepts"] +image::08-Crosscutting-Concepts-Structure-EN.png["Возможные темы для сквозных концепций"] .Дальнейшая информация -See https://docs.arc42.org/section-8/[Concepts] в документации arc42. +Смотри https://docs.arc42.org/section-8/[Концепции] в документации arc42. **** -=== __ +=== _<Концепция 1>_ -__ +_<объяснение>_ -=== __ +=== _<Концепция 2>_ -__ +_<объяснение>_ ... -=== __ +=== _<Концепция n>_ -__ +_<объяснение>_ diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc index e6b7b27d..5206a12d 100644 --- a/RU/asciidoc/src/09_architecture_decisions.adoc +++ b/RU/asciidoc/src/09_architecture_decisions.adoc @@ -29,7 +29,7 @@ Various options: .Дальнейшая информация -See https://docs.arc42.org/section-9/[Architecture Decisions] в документации arc42. +Смотри https://docs.arc42.org/section-9/[Architecture Decisions] в документации arc42. There you will find links and examples about ADR. **** diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc index 4df0da48..23dc016c 100644 --- a/RU/asciidoc/src/10_quality_requirements.adoc +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -21,7 +21,7 @@ concrete and measurable. .Дальнейшая информация -See https://docs.arc42.org/section-10/[Quality Requirements] в документации arc42. +Смотри https://docs.arc42.org/section-10/[Quality Requirements] в документации arc42. **** diff --git a/RU/asciidoc/src/11_technical_risks.adoc b/RU/asciidoc/src/11_technical_risks.adoc index 3b0a2f43..f7478c52 100644 --- a/RU/asciidoc/src/11_technical_risks.adoc +++ b/RU/asciidoc/src/11_technical_risks.adoc @@ -20,6 +20,6 @@ List of risks and/or technical debts, probably including suggested measures to m .Дальнейшая информация -See https://docs.arc42.org/section-11/[Risks and Technical Debt] в документации arc42. +Смотри https://docs.arc42.org/section-11/[Risks and Technical Debt] в документации arc42. **** diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc index 91df1ecd..dd0db21d 100644 --- a/RU/asciidoc/src/12_glossary.adoc +++ b/RU/asciidoc/src/12_glossary.adoc @@ -26,7 +26,7 @@ Potentially more columns in case you need translations. .Дальнейшая информация -See https://docs.arc42.org/section-12/[Glossary] в документации arc42. +Смотри https://docs.arc42.org/section-12/[Glossary] в документации arc42. **** diff --git a/RU/asciidoc/src/about-arc42.adoc b/RU/asciidoc/src/about-arc42.adoc index a9d3ae47..700c9bc6 100644 --- a/RU/asciidoc/src/about-arc42.adoc +++ b/RU/asciidoc/src/about-arc42.adoc @@ -11,5 +11,5 @@ arc42, the template for documentation of software and system architecture. Template Version {revnumber}. {revremark}, {revdate} Created, maintained and (C) by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. -See https://arc42.org. +Смотри https://arc42.org. From 43df68f03c2fd13134237c2e10918120cc48ac54 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 14:30:20 +0200 Subject: [PATCH 12/23] 9 --- .../src/09_architecture_decisions.adoc | 28 +++++++++---------- 1 file changed, 13 insertions(+), 15 deletions(-) diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc index 5206a12d..6beaec4b 100644 --- a/RU/asciidoc/src/09_architecture_decisions.adoc +++ b/RU/asciidoc/src/09_architecture_decisions.adoc @@ -1,35 +1,33 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-design-decisions]] -== Architecture Decisions +== Архитектурные решения [role="arc42help"] **** .Содержание -Important, expensive, large scale or risky architecture decisions including rationales. -With "decisions" we mean selecting one alternative based on given criteria. +Важные, дорогие, крупномасштабные или рискованные архитектурные решения, включая их обоснование. +Под «решениями» мы подразумеваем выбор одной альтернативы на основе заданных критериев. -Please use your judgement to decide whether an architectural decision should be documented -here in this central section or whether you better document it locally -(e.g. within the white box template of one building block). +Решите сами, следует ли документировать архитектурное решение в этом центральном разделе, или лучше документировать это локально (например, в шаблоне белого ящика одного стандартного блока). -Avoid redundancy. -Refer to section 4, where you already captured the most important decisions of your architecture. +Избегайте избыточности. +Обратитесь к разделу 4, где вы уже зафиксировали наиболее важные решения вашей архитектуры. .Мотивация -Stakeholders of your system should be able to comprehend and retrace your decisions. +Заинтересованные лица вашей системы должны иметь возможность понять и проследить ваши решения. .Форма -Various options: +Различные варианты: -* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision -* List or table, ordered by importance and consequences or: -* more detailed in form of separate sections per decision +* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) для каждого важного решения +* Список или таблица, упорядоченные по важности и последствиям или: +* подробнее в виде отдельных разделов по решению .Дальнейшая информация -Смотри https://docs.arc42.org/section-9/[Architecture Decisions] в документации arc42. -There you will find links and examples about ADR. +Смотри https://docs.arc42.org/section-9/[Архитектурные решения] в документации arc42. +Там вы найдете ссылки и примеры по ADR. **** From fb0bf9edc49ae6b5c29e5affb566b982ff9a703f Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 14:37:34 +0200 Subject: [PATCH 13/23] 10 --- RU/asciidoc/src/10_quality_requirements.adoc | 51 +++++++++----------- 1 file changed, 24 insertions(+), 27 deletions(-) diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc index 23dc016c..63b304be 100644 --- a/RU/asciidoc/src/10_quality_requirements.adoc +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -1,27 +1,25 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-quality-scenarios]] -== Quality Requirements +== Требования к качеству [role="arc42help"] **** .Содержание -This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals) +Этот раздел содержит все требования к качеству в виде дерева качества со сценариями. Наиболее важные из них уже были описаны в разделе 1.2. (цели качества) -Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved. +Здесь вы также можете зафиксировать требования к качеству с меньшим приоритетом, +не создающие высоких рисков будучи не полностью достигнутыми. .Мотивация -Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important to them, -concrete and measurable. - +Поскольку требования к качеству будут иметь большое влияние на архитектурные +решения, вы должны знать что действительно важно для каждой из заинтересованных сторон (конкретно и измеримо). .Дальнейшая информация -Смотри https://docs.arc42.org/section-10/[Quality Requirements] в документации arc42. +Смотри https://docs.arc42.org/section-10/[Требования к качеству] в документации arc42. **** @@ -30,19 +28,18 @@ concrete and measurable. [role="arc42help"] **** .Содержание -The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs. +Дерево качества (как определено в ATAM — Architecture Tradeoff Analysis Method) со сценариями качества/оценки в виде листьев. .Мотивация -The tree structure with priorities provides an overview for a sometimes large number of quality requirements. +Древовидная структура с приоритетами обеспечивает обзор большого количества требований к качеству. .Форма -The quality tree is a high-level overview of the quality goals and requirements: - -* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root -* a mind map with quality categories as main branches +Дерево качества представляет собой высокоуровневый обзор целей и требований в области качества: -In any case the tree should include links to the scenarios of the following section. +* древовидное уточнение термина «качество». Используйте «качество» или «полезность» в качестве корня +* майндмпеп с категориями качества в качестве основных ветвей +В любом случае дерево должно включать ссылки на сценарии следующего раздела. **** @@ -51,23 +48,23 @@ In any case the tree should include links to the scenarios of the following sect [role="arc42help"] **** .Содержание -Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios. +Конкретизация (иногда расплывчатых или неявных) требований к качеству с использованием сценариев (качества). -These scenarios describe what should happen when a stimulus arrives at the system. +Эти сценарии описывают, что должно произойти, когда в систему поступает стимул. -For architects, two kinds of scenarios are important: +Для архитекторов важны два вида сценариев: -* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second. -* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change. +* Сценарии использования (также называемые сценариями приложений или сценариями вариантов использования) описывают реакцию системы во время выполнения на определенный стимул. Сюда также входят сценарии, описывающие эффективность или производительность системы. Пример: Система реагирует на запрос пользователя в течение одной секунды. +* Сценарии изменений описывают модификацию системы или ее ближайшего окружения. Пример: Реализована дополнительная функциональность или изменены требования к атрибуту качества. .Мотивация -Scenarios make quality requirements concrete and allow to -more easily measure or decide whether they are fulfilled. +Сценарии конкретизируют требования к качеству и позволяют +легче измерить или решить, выполнены ли они. -Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) -more precisely down to a level of scenarios that can be discussed and evaluated. +Особенно, когда вы хотите оценить свою архитектуру, используя такие методы, как +ATAM вам необходимо описать ваши цели в области качества (из раздела 1.2) +точнее до уровня сценариев, которые можно обсуждать и оценивать. .Форма -Tabular or free form text. +Табличный или произвольный текст. **** From 1046ffeaef4dbad654b4274c9b959c3eab62f684 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 14:44:00 +0200 Subject: [PATCH 14/23] 11, 12, about --- RU/asciidoc/arc42-template.adoc | 2 +- RU/asciidoc/src/11_technical_risks.adoc | 12 +++++------ RU/asciidoc/src/12_glossary.adoc | 27 ++++++++++++------------- RU/asciidoc/src/about-arc42.adoc | 8 ++++---- 4 files changed, 24 insertions(+), 25 deletions(-) diff --git a/RU/asciidoc/arc42-template.adoc b/RU/asciidoc/arc42-template.adoc index 97e31fca..b81171c2 100644 --- a/RU/asciidoc/arc42-template.adoc +++ b/RU/asciidoc/arc42-template.adoc @@ -9,7 +9,7 @@ include::src/config.adoc[] = image:arc42-logo.png[arc42] Шаблон :revnumber: 8.2 RU :revdate: Январь 2023 -:revremark: (based upon AsciiDoc version) +:revremark: (основана на версии AsciiDoc) // toc-title definition MUST follow document title without blank line! :toc-title: Оглавление diff --git a/RU/asciidoc/src/11_technical_risks.adoc b/RU/asciidoc/src/11_technical_risks.adoc index f7478c52..e2a4cef4 100644 --- a/RU/asciidoc/src/11_technical_risks.adoc +++ b/RU/asciidoc/src/11_technical_risks.adoc @@ -1,25 +1,25 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-technical-risks]] -== Risks and Technical Debts +== Риски и технический долг [role="arc42help"] **** .Содержание -A list of identified technical risks or technical debts, ordered by priority +Список выявленных технических рисков или технических долгов, упорядоченный по приоритету .Мотивация -“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) +«Управление рисками — это управление проектами для взрослых» (Тим Листер, Atlantic Systems Guild). -This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning. +Это должно быть вашим девизом для систематического обнаружения и оценки рисков и технических задолженностей в архитектуре, которые потребуются управляющим заинтересованным сторонам (например, руководителям проектов, владельцам продуктов) в рамках общего анализа рисков и планирования измерений. .Форма -List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts. +Список рисков и/или технических долгов, возможно, включая предлагаемые меры по минимизации, смягчению или предотвращению рисков или сокращению технических долгов. .Дальнейшая информация -Смотри https://docs.arc42.org/section-11/[Risks and Technical Debt] в документации arc42. +Смотри https://docs.arc42.org/section-11/[Риски и технический долг] в документации arc42. **** diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc index dd0db21d..eca3e4f7 100644 --- a/RU/asciidoc/src/12_glossary.adoc +++ b/RU/asciidoc/src/12_glossary.adoc @@ -6,37 +6,36 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** .Содержание -The most important domain and technical terms that your stakeholders use when discussing the system. +Наиболее важные доменные и технические термины, которые ваши заинтересованные стороны используют при обсуждении системы. -You can also see the glossary as source for translations if you work in multi-language teams. +Вы также можете использовать глоссарий в качестве источника переводов, если вы работаете в многоязычной команде. .Мотивация -You should clearly define your terms, so that all stakeholders - -* have an identical understanding of these terms -* do not use synonyms and homonyms +Вы должны четко определить свои условия, чтобы все заинтересованные стороны +* имели одинаковое понимание этих терминов +* не использовали синонимы и омонимы .Форма -A table with columns and . +Таблица со столбцами и . -Potentially more columns in case you need translations. +Потенциально больше столбцов на случай, если вам понадобятся переводы. .Дальнейшая информация -Смотри https://docs.arc42.org/section-12/[Glossary] в документации arc42. +Смотри https://docs.arc42.org/section-12/[Глоссарий] в документации arc42. **** [cols="e,2e" options="header"] |=== -|Term |Definition +|Термин |Определение -| -| +|<Термин-1> +|<определение-1> -| -| +|<Термин-2> +|<определение-2> |=== diff --git a/RU/asciidoc/src/about-arc42.adoc b/RU/asciidoc/src/about-arc42.adoc index 700c9bc6..0381f76c 100644 --- a/RU/asciidoc/src/about-arc42.adoc +++ b/RU/asciidoc/src/about-arc42.adoc @@ -3,13 +3,13 @@ :keywords: software-architecture, documentation, template, arc42 :numbered!: -**About arc42** +**Об arc42** [role="lead"] -arc42, the template for documentation of software and system architecture. +arc42, шаблон для документации программного обеспечения и системной архитектуры. -Template Version {revnumber}. {revremark}, {revdate} +Версия шаблона {revnumber}. {revremark}, {revdate} -Created, maintained and (C) by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. +Создано и поддерживается (C) доктором Петером Хрушкой, доктором Гернотом Старке и другими участниками. Смотри https://arc42.org. From c42fe0e76e9e7a9d289fd9e7fd876b56110a331f Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 14:47:22 +0200 Subject: [PATCH 15/23] typos --- RU/asciidoc/src/01_introduction_and_goals.adoc | 4 ++-- RU/asciidoc/src/07_deployment_view.adoc | 2 +- RU/asciidoc/src/08_concepts.adoc | 4 ++-- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/RU/asciidoc/src/01_introduction_and_goals.adoc b/RU/asciidoc/src/01_introduction_and_goals.adoc index 5977b0e7..9c1dbd59 100644 --- a/RU/asciidoc/src/01_introduction_and_goals.adoc +++ b/RU/asciidoc/src/01_introduction_and_goals.adoc @@ -47,12 +47,12 @@ ifndef::imagesdir[:imagesdir: ../images] .Содержание Три (максимум пять) главных целей в области качества для архитектуры, выполнение которых имеет первостепенное значение для основных заинтересованных сторон. Здесь действительно имеются в виду цели качества для архитектуры. Не путайте их с целями проекта. -Они не обязательно совпдают. +Они не обязательно совпадают. Рассмотрите этот обзор потенциальных тем (на основе стандарта ISO 25010): image::01_2_iso-25010-topics-EN.drawio.png["Категории требований по качеству"] -.Мотвация +.Мотивация Вы должны знать цели в области качества наиболее важных заинтересованных сторон, поскольку они будут влиять на фундаментальные архитектурные решения. Убедитесь, что вы очень конкретно говорите об этих качествах, избегайте модных словечек. Если вы как архитектор не знаете, как будет оцениваться качество вашей работы... diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 7b120fe4..7e5c7de3 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -7,7 +7,7 @@ ifndef::imagesdir[:imagesdir: ../images] **** Представление развертывания описывает: -1. техническую инфраструктуру, используемуя для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и +1. техническую инфраструктуру, используемую для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и 2. сопоставление строительных блоков (программного обеспечения) с этими элементами инфраструктуры. diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index cb7e52af..bd2d58ed 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -23,7 +23,7 @@ ifndef::imagesdir[:imagesdir: ../images] Концепции составляют основу _концептуальной целостности_ (непротиворечивости, однородности) архитектуры. Таким образом, они являются важным вкладом в достижение внутренних качеств вашей системы. -Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительноси. +Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительности. .Форма The form can be varied: @@ -33,7 +33,7 @@ The form can be varied: * sample implementations, especially for technical concepts * reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) - .Структура +.Структура Потенциальная (но не обязательная) структура этого раздела может быть следующей: * Концепции домена From 4d9154e5f35eb6e001ba0df192d1fbea9e6f539d Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 15:02:31 +0200 Subject: [PATCH 16/23] titles 6,7 --- RU/asciidoc/src/06_runtime_view.adoc | 2 +- RU/asciidoc/src/07_deployment_view.adoc | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc index 0ccb81f3..d445aed7 100644 --- a/RU/asciidoc/src/06_runtime_view.adoc +++ b/RU/asciidoc/src/06_runtime_view.adoc @@ -1,7 +1,7 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-runtime-view]] -== Runtime View +== Представление времени выполнения [role="arc42help"] **** diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 7e5c7de3..ebacc805 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -1,7 +1,7 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-deployment-view]] -== Deployment View +== Представления развертывания [role="arc42help"] **** From 09ac3d419955809a20a1c5186b9a4393b270df06 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 15:21:41 +0200 Subject: [PATCH 17/23] Some more translations --- RU/asciidoc/src/05_building_block_view.adoc | 6 +++--- RU/asciidoc/src/07_deployment_view.adoc | 16 ++++++++-------- RU/asciidoc/src/08_concepts.adoc | 6 ++++-- RU/asciidoc/src/10_quality_requirements.adoc | 4 ++-- RU/asciidoc/src/12_glossary.adoc | 4 ++-- 5 files changed, 19 insertions(+), 17 deletions(-) diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index f74d80f1..ea968478 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -31,8 +31,8 @@ box descriptions of all contained building blocks. *Уровень 1* представляет собой описание всей системы в виде «белого ящика» вместе с описаниями всех содержащихся строительных блоков в виде «черных ящиков». -*Level 2* zooms into some building blocks of level 1. -Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks. +*Уровень 2* zooms into some building blocks of уровень 1. +Thus it contains the white box description of selected building blocks of уровень 1, together with black box descriptions of their internal building blocks. *Уровень 2* раскрывает детали некоторых строительных блоков уровня 1. Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием их внутренних строительных блоков как «черных ящиков». @@ -189,7 +189,7 @@ _<шаблон белого ящика>_ -=== Level 3 +=== Уровень 3 [role="arc42help"] **** diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index ebacc805..5e2ef02a 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -21,11 +21,11 @@ ifndef::imagesdir[:imagesdir: ../images] .Мотивация Программное обеспечение не работает без аппаратного обеспечения. -Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные (cross-cutting) концепции. +Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные (сквозные) концепции. Поэтому необходимо знать инфраструктуру. .Форма -Maybe a highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. +Maybe a highest уровень deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section one can zoom into this black box using additional deployment diagrams: Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанной ОДНИМ черным ящиком. @@ -40,7 +40,7 @@ In this section one can zoom into this black box using additional deployment dia **** -=== Infrastructure Level 1 +=== Инфраструктурный уровень 1 [role="arc42help"] **** @@ -76,24 +76,24 @@ _<объяснение в текстовом виде>_ Mapping of Building Blocks to Infrastructure:: __ -=== Infrastructure Level 2 +=== Инфраструктурный уровень 2 [role="arc42help"] **** -Here you can include the internal structure of (some) infrastructure elements from level 1. +Here you can include the internal structure of (some) Инфраструктурный элементs from level 1. Please copy the structure from level 1 for each selected element. **** -==== __ +==== _<Инфраструктурный элемент 1>_ __ -==== __ +==== _<Инфраструктурный элемент 2>_ __ ... -==== __ +==== _<Инфраструктурный элемент n>_ __ diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index bd2d58ed..2fbbb3b1 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -28,10 +28,12 @@ ifndef::imagesdir[:imagesdir: ../images] .Форма The form can be varied: -* concept papers with any kind of structure -* cross-cutting model excerpts or scenarios using notations of the architecture views * sample implementations, especially for technical concepts * reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) +* концептуальные документы любой структуры +* сквозные фрагменты моделей или сценарии с использованием обозначений архитектурных представлений +* примеры реализации, особенно для технических концепций +* ссылка на типичное использование стандартных фреймворков (например, использование Hibernate для объектно-реляционного сопоставления) .Структура Потенциальная (но не обязательная) структура этого раздела может быть следующей: diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc index 63b304be..81a6c0d3 100644 --- a/RU/asciidoc/src/10_quality_requirements.adoc +++ b/RU/asciidoc/src/10_quality_requirements.adoc @@ -23,7 +23,7 @@ ifndef::imagesdir[:imagesdir: ../images] **** -=== Quality Tree +=== Дерево качества [role="arc42help"] **** @@ -43,7 +43,7 @@ ifndef::imagesdir[:imagesdir: ../images] **** -=== Quality Scenarios +=== Сценарии качества [role="arc42help"] **** diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc index eca3e4f7..8eb47d4c 100644 --- a/RU/asciidoc/src/12_glossary.adoc +++ b/RU/asciidoc/src/12_glossary.adoc @@ -1,7 +1,7 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-glossary]] -== Glossary +== Глоссарий [role="arc42help"] **** @@ -18,7 +18,7 @@ ifndef::imagesdir[:imagesdir: ../images] .Форма -Таблица со столбцами и . +Таблица со столбцами <Термин> и <Определение>. Потенциально больше столбцов на случай, если вам понадобятся переводы. From 75448b0e9dddd86ccf8dc3c4cf2f2059bdc1951f Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 11 Jul 2023 15:49:14 +0200 Subject: [PATCH 18/23] Context --- RU/asciidoc/src/03_context_and_scope.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc index 104e31cb..bc365d0b 100644 --- a/RU/asciidoc/src/03_context_and_scope.adoc +++ b/RU/asciidoc/src/03_context_and_scope.adoc @@ -1,7 +1,7 @@ ifndef::imagesdir[:imagesdir: ../images] [[section-context-and-scope]] -== Context and Scope +== Контекст и рамки [role="arc42help"] @@ -39,7 +39,7 @@ Various options: **** -=== Business Context +=== Бизнес контекст [role="arc42help"] **** From 9d0cbdfdbf339c7f92dd85949f459b8254e7504f Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 18 Jul 2023 19:32:37 +0200 Subject: [PATCH 19/23] 1-3 --- .../src/01_introduction_and_goals.adoc | 5 ++- RU/asciidoc/src/03_context_and_scope.adoc | 40 +++---------------- RU/asciidoc/src/05_building_block_view.adoc | 2 +- RU/asciidoc/src/07_deployment_view.adoc | 21 +++++----- 4 files changed, 21 insertions(+), 47 deletions(-) diff --git a/RU/asciidoc/src/01_introduction_and_goals.adoc b/RU/asciidoc/src/01_introduction_and_goals.adoc index 9c1dbd59..384512d6 100644 --- a/RU/asciidoc/src/01_introduction_and_goals.adoc +++ b/RU/asciidoc/src/01_introduction_and_goals.adoc @@ -24,7 +24,7 @@ ifndef::imagesdir[:imagesdir: ../images] (с номером версии и информацией, где ее найти). .Мотивация -С точки зрения конечных пользователей система создается или модифицируется чтобы +С точки зрения конечных пользователей система создается или модифицируется, чтобы улучшить поддержку деловой активности и/или улучшить качество. .Форма @@ -47,9 +47,10 @@ ifndef::imagesdir[:imagesdir: ../images] .Содержание Три (максимум пять) главных целей в области качества для архитектуры, выполнение которых имеет первостепенное значение для основных заинтересованных сторон. Здесь действительно имеются в виду цели качества для архитектуры. Не путайте их с целями проекта. -Они не обязательно совпадают. +Они необязательно совпадают. Рассмотрите этот обзор потенциальных тем (на основе стандарта ISO 25010): + image::01_2_iso-25010-topics-EN.drawio.png["Категории требований по качеству"] .Мотивация diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc index bc365d0b..86cd487a 100644 --- a/RU/asciidoc/src/03_context_and_scope.adoc +++ b/RU/asciidoc/src/03_context_and_scope.adoc @@ -8,25 +8,14 @@ ifndef::imagesdir[:imagesdir: ../images] **** .Содержание -Context and scope - as the name suggests - delimits your system (i.e. your scope) from all its communication partners -(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces. - -Контекст и область действия — как следует из названия — разграничивают вашу систему (то есть область действия) от всех ее коммуникационных партнеров. -(соседние системы и пользователи, т.е. контекст вашей системы). Таким образом, он определяет внешние интерфейсы. - -If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware). +Контекст и область действия — как следует из названия — разграничивают вашу систему (ее рамки) от всех партнеров с которыми она коммуницирует (соседние системы и пользователи, т.е. контекст вашей системы). Таким образом, он определяет внешние интерфейсы. При необходимости различайте бизнес-контекст (специфические для предметной области входы и выходы) и технический контекст (каналы, протоколы, аппаратное обеспечение). .Мотивация -The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them. +Интерфейсы домена и технические интерфейсы для коммуникационных партнеров являются одними из наиболее важных аспектов вашей системы. Убедитесь, что вы их полностью понимаете. .Форма -Various options: - -* Context diagrams -* Lists of communication partners and their interfaces. - Различные варианты: * Контекстные диаграммы @@ -44,27 +33,17 @@ Various options: [role="arc42help"] **** .Содержание -Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces. -Optionally you can add domain specific formats or communication protocols. - Спецификация *всех* коммуникационных партнеров (пользователи, ИТ-системы, ...) с пояснениями входных и выходных данных или интерфейсов, специфичных для предметной области. При желании вы можете добавить специфичные для домена форматы или протоколы связи. .Мотивация -All stakeholders should understand which data are exchanged with the environment of the system. - -Все заинтересованные стороны должны понимать, какими данными происходит обмен со средой системы. +Все заинтересованные стороны должны понимать, какими данными система обменивается со средой. .Форма -All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners. - -Alternatively (or additionally) you can use a table. -The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs. - Все виды диаграмм, изображающих систему в виде черного ящика и определяющих интерфейсы домена для коммуникационных партнеров. В качестве альтернативы (или дополнительно) можно использовать таблицу. -Заголовок таблицы — это имя вашей системы, три столбца содержат имя партнера по связи, входы и выходы. +Заголовок таблицы — это имя вашей системы, три столбца содержат имя партнера, с которым происходит коммуникация, входы и выходы. **** @@ -77,20 +56,13 @@ The title of the table is the name of your system, the three columns contain the [role="arc42help"] **** .Содержание -Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel. - Технические интерфейсы (каналы и среды передачи), связывающие вашу систему с окружающей средой. Кроме того, сопоставление ввода/вывода, специфичного для предметной области, с каналами, то есть объяснение, какой ввод/вывод использует какой канал. .Мотивация -Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces. - -Многие заинтересованные стороны принимают архитектурные решения на основе технических интерфейсов между системой и ее контекстом. Особенно разработчики инфраструктуры или оборудования решают эти технические интерфейсы. +Многие заинтересованные стороны принимают архитектурные решения на основе технических интерфейсов между системой и ее контекстом. Зачастую разработчики инфраструктуры или оборудования выбирают эти технические интерфейсы. .Форма -E.g. UML deployment diagram describing channels to neighboring systems, -together with a mapping table showing the relationships between channels and input/output. - -Например. Диаграмма развертывания UML, описывающая каналы к соседним системам, +Например, диаграмма развертывания UML, описывающая каналы к соседним системам, вместе с таблицей сопоставления, показывающей взаимосвязь между каналами и вводом/выводом. **** diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index ea968478..4d170081 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -77,7 +77,7 @@ _<текстовое объяснение>_ Содержащиеся строительные блоки:: -_<Описание содержащегося стандартного блока (черные ящики)>_ +_<Описание строительных блоков (черные ящики)>_ Важные интерфейсы:: _<Описание важных интерфейсов>_ diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index 5e2ef02a..ad2f6432 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -63,37 +63,38 @@ For multiple environments or alternative deployments please copy and adapt this Для нескольких сред или альтернативных развертываний скопируйте и адаптируйте этот раздел arc42 для всех соответствующих сред. **** -_****_ +_**<Обзорная диаграмма>**_ -Motivation:: +Мотивация:: _<объяснение в текстовом виде>_ -Quality and/or Performance Features:: +Характеристики качества и/или производительности:: _<объяснение в текстовом виде>_ -Mapping of Building Blocks to Infrastructure:: -__ +Сопоставление строительных блоков с инфраструктурой:: +_<описание сопоставления>_ === Инфраструктурный уровень 2 [role="arc42help"] **** -Here you can include the internal structure of (some) Инфраструктурный элементs from level 1. +Сюда можно включить внутреннюю структуру (некоторых) Инфраструктурных элементов уровня 1. -Please copy the structure from level 1 for each selected element. +Пожалуйста, скопируйте структуру уровня 1 для каждого выбранного элемента. **** ==== _<Инфраструктурный элемент 1>_ -__ +_<диаграмма + объяснение>_ ==== _<Инфраструктурный элемент 2>_ -__ +_<диаграмма + объяснение>_ ... + ==== _<Инфраструктурный элемент n>_ -__ +_<диаграмма + объяснение>_ From 34553a9815c2b40d6fecd001c9fd5bffaa827769 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 18 Jul 2023 19:46:19 +0200 Subject: [PATCH 20/23] 5-8 --- RU/asciidoc/src/05_building_block_view.adoc | 10 +--------- RU/asciidoc/src/06_runtime_view.adoc | 2 +- RU/asciidoc/src/07_deployment_view.adoc | 15 ++------------- RU/asciidoc/src/08_concepts.adoc | 4 +--- 4 files changed, 5 insertions(+), 26 deletions(-) diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index 4d170081..2b6ffeda 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -8,9 +8,7 @@ ifndef::imagesdir[:imagesdir: ../images] [role="arc42help"] **** .Содержание -The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, ...) as well as their dependencies (relationships, associations, ...) - -Представление строительных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, платформы, слои, разделы, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...) +Представление строительных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, фреймворки, слои, партиции, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...) Это представление является обязательным для любой архитектурной документации. По аналогии с домом это _план этажа_. @@ -26,14 +24,8 @@ The building block view shows the static decomposition of the system into buildi image::05_building_blocks-EN.png["Иерархия строительных блоков"] -*Уровень 1* is the white box description of the overall system together with black -box descriptions of all contained building blocks. - *Уровень 1* представляет собой описание всей системы в виде «белого ящика» вместе с описаниями всех содержащихся строительных блоков в виде «черных ящиков». -*Уровень 2* zooms into some building blocks of уровень 1. -Thus it contains the white box description of selected building blocks of уровень 1, together with black box descriptions of their internal building blocks. - *Уровень 2* раскрывает детали некоторых строительных блоков уровня 1. Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием их внутренних строительных блоков как «черных ящиков». diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc index d445aed7..5839fff4 100644 --- a/RU/asciidoc/src/06_runtime_view.adoc +++ b/RU/asciidoc/src/06_runtime_view.adoc @@ -32,7 +32,7 @@ ifndef::imagesdir[:imagesdir: ../images] * ... .Дальнейшая информация -Смотри https://docs.arc42.org/section-6/[Runtime View] в документации arc42. +Смотри https://docs.arc42.org/section-6/[Представление времени выполнения] в документации arc42. **** diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc index ad2f6432..5310c5ea 100644 --- a/RU/asciidoc/src/07_deployment_view.adoc +++ b/RU/asciidoc/src/07_deployment_view.adoc @@ -25,10 +25,7 @@ ifndef::imagesdir[:imagesdir: ../images] Поэтому необходимо знать инфраструктуру. .Форма -Maybe a highest уровень deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. -In this section one can zoom into this black box using additional deployment diagrams: - -Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанной ОДНИМ черным ящиком. +Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанного ОДНИМ черным ящиком. В этом разделе можно раскрыть этот черный ящик, используя дополнительные диаграммы развертывания: * UML предлагает диаграммы развертывания, чтобы выразить это представление. @@ -36,7 +33,7 @@ In this section one can zoom into this black box using additional deployment dia * Если заинтересованные стороны (связанные с аппаратным обеспечением) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры. .Дальнейшая информация -Смотри https://docs.arc42.org/section-7/[Deployment View] в документации arc42. +Смотри https://docs.arc42.org/section-7/[Представление развертывания] в документации arc42. **** @@ -44,14 +41,6 @@ In this section one can zoom into this black box using additional deployment dia [role="arc42help"] **** -Describe (usually in a combination of diagrams, tables, and text): - -* distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them -* important justifications or motivations for this deployment structure -* quality and/or performance features of this infrastructure -* mapping of software artifacts to elements of this infrastructure - -For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments. Опишите (обычно в комбинации диаграмм, таблиц и текста): diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc index 2fbbb3b1..4e17581d 100644 --- a/RU/asciidoc/src/08_concepts.adoc +++ b/RU/asciidoc/src/08_concepts.adoc @@ -26,10 +26,8 @@ ifndef::imagesdir[:imagesdir: ../images] Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительности. .Форма -The form can be varied: +Форма может быть разнообразной: -* sample implementations, especially for technical concepts -* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping) * концептуальные документы любой структуры * сквозные фрагменты моделей или сценарии с использованием обозначений архитектурных представлений * примеры реализации, особенно для технических концепций From cbe518e61fc66c0f89a92b668b5009ba90912b7b Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 18 Jul 2023 19:48:00 +0200 Subject: [PATCH 21/23] 9 --- RU/asciidoc/src/09_architecture_decisions.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc index 6beaec4b..6786d1df 100644 --- a/RU/asciidoc/src/09_architecture_decisions.adoc +++ b/RU/asciidoc/src/09_architecture_decisions.adoc @@ -21,7 +21,7 @@ ifndef::imagesdir[:imagesdir: ../images] .Форма Различные варианты: -* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) для каждого важного решения +* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Документирование архитектурных решений]) для каждого важного решения * Список или таблица, упорядоченные по важности и последствиям или: * подробнее в виде отдельных разделов по решению From 52ae31c7e3bb3e88f0ce26fe74a9c27f3371d897 Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 18 Jul 2023 19:49:51 +0200 Subject: [PATCH 22/23] config RU --- RU/asciidoc/src/config.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RU/asciidoc/src/config.adoc b/RU/asciidoc/src/config.adoc index 334d5291..369d72ba 100644 --- a/RU/asciidoc/src/config.adoc +++ b/RU/asciidoc/src/config.adoc @@ -1,4 +1,4 @@ -// asciidoc settings for EN (English) +// asciidoc settings for RU (Russian) // ================================== :toc-title: table of contents From a8fad2f1f384db6bc926dbe6fc9b647ef8ce396f Mon Sep 17 00:00:00 2001 From: max arshinov Date: Tue, 18 Jul 2023 19:54:41 +0200 Subject: [PATCH 23/23] 5 --- RU/asciidoc/src/05_building_block_view.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc index 2b6ffeda..41bea062 100644 --- a/RU/asciidoc/src/05_building_block_view.adoc +++ b/RU/asciidoc/src/05_building_block_view.adoc @@ -195,7 +195,7 @@ _<шаблон белого ящика>_ [role="arc42help"] **** -Specifies the internal structure of _строительный блок x.1_. +Описывает внутреннюю структуру _строительного блока x.1_. ****