From 701444771318570454f87cf76474cc792ae836af Mon Sep 17 00:00:00 2001 From: Ulrich Becker Date: Sat, 12 Oct 2024 18:04:36 +0200 Subject: [PATCH] Chapter 3 Fix translations, wording, redundant relevance levels --- docs/03-design/01-design-duration-terms.adoc | 2 +- docs/03-design/LG-03-02.adoc | 10 ++++---- docs/03-design/LG-03-04.adoc | 4 ++-- docs/03-design/LG-03-05.adoc | 2 +- docs/03-design/LG-03-07.adoc | 2 +- docs/03-design/LG-03-09.adoc | 24 ++++++++++---------- docs/03-design/LG-03-10.adoc | 6 ++--- 7 files changed, 25 insertions(+), 25 deletions(-) diff --git a/docs/03-design/01-design-duration-terms.adoc b/docs/03-design/01-design-duration-terms.adoc index 38a4619..e837937 100644 --- a/docs/03-design/01-design-duration-terms.adoc +++ b/docs/03-design/01-design-duration-terms.adoc @@ -26,7 +26,7 @@ Architekturmuster; Entwurfsmuster; Mustersprachen; Entwurfsprinzipien; -Abhängigkeit; +Abhängigkeiten; Kopplung; Kohäsion; Top-down- und Bottom-up-Vorgehen; diff --git a/docs/03-design/LG-03-02.adoc b/docs/03-design/LG-03-02.adoc index 8de61ff..fd16ba2 100644 --- a/docs/03-design/LG-03-02.adoc +++ b/docs/03-design/LG-03-02.adoc @@ -11,7 +11,7 @@ Softwarearchitekt:innen können: * Begriffe {glossary_url}blockbox[Blackbox] und {glossary_url}whitebox[Whitebox] erklären und zielgerichtet anwenden * schrittweise Verfeinerung und Spezifikation von Bausteinen durchführen * Architektursichten entwerfen, insbesondere Baustein-, Laufzeit- und Verteilungssicht (siehe <>) -* die aus diesen Entscheidungen resultierenden Konsequenzen auf den Quellcode erklären +* die aus Entscheidungen resultierenden Konsequenzen auf den Quellcode erklären * domänenspezifische und technische Bestandteile in Architekturen trennen und diese Trennung begründen * Risiken von Architekturentscheidungen identifizieren. @@ -24,12 +24,12 @@ Softwarearchitekt:innen können: Software architects are able to: * design and appropriately communicate and document software architectures based upon known functional and quality requirements for software systems that are neither safety- nor business-critical -* make structure-relevant decisions regarding system decomposition and building-block structure and deliberately design dependencies between building blocks (see <>) -* recognize and justify interdependencies and trade-offs of {glossary_url}architecture decisions[architecture decisions] +* make structural decisions regarding system decomposition and building-block structure, thereby defining dependencies between building blocks (see <>) +* recognize and justify interdependencies and trade-offs between {glossary_url}architecture decisions[architecture decisions] * explain the terms {glossary_url}blockbox[black box] and {glossary_url}whitebox[white box] and apply them purposefully -* apply stepwise refinement and specify building blocks +* apply stepwise refinement and specification of building blocks * design architecture views, especially building-block view, runtime view and deployment view (see <>) -* explain the consequences of these decisions on the corresponding source code +* explain the consequences of decisions on the corresponding source code * separate technical and domain-related elements of architectures and justify these decisions * identify risks related to architecture decisions. diff --git a/docs/03-design/LG-03-04.adoc b/docs/03-design/LG-03-04.adoc index 5b3bfcb..fc17976 100644 --- a/docs/03-design/LG-03-04.adoc +++ b/docs/03-design/LG-03-04.adoc @@ -53,13 +53,13 @@ Softwarearchitekt:innen sind in der Lage: ==== LG 03-04 [previously LG 2-06]: Explain and Use Design Principles (R1-R3) Software architects are able to explain what design principles are. -They can outline their general objectives and applications with regard to software architecture. (R2) +They can outline their general objectives and their application with regard to software architecture. (R2) Software architects are able to: * explain the design principles listed below and can illustrate them with examples * explain how those principles are to be applied -* explain how the requirements determine which principles should be applied +* explain how requirements determine which principles should be applied * explain the impact of design principles on the implementation * analyze source code and architecture designs to evaluate whether these design principles have been applied or should be applied diff --git a/docs/03-design/LG-03-05.adoc b/docs/03-design/LG-03-05.adoc index e19f267..a854de9 100644 --- a/docs/03-design/LG-03-05.adoc +++ b/docs/03-design/LG-03-05.adoc @@ -18,7 +18,7 @@ Sie [[LG-03-05]] ==== LG 03-05 [previously LG 1-06]: Correlation between Feedback Loops and Risks (R1, R2) -Software architects understand the necessity of iterations, especially when decision-making is affected by uncertainties. They +Software architects understand the necessity of iterations, especially when decisions are made in the face of uncertainties. They * are able to explain the influence of iterative approaches on architectural decisions (with regard to risks and predictability). (R1) * can work and make decisions incrementally and iteratively. (R1) diff --git a/docs/03-design/LG-03-07.adoc b/docs/03-design/LG-03-07.adoc index 250aaff..f0b1784 100644 --- a/docs/03-design/LG-03-07.adoc +++ b/docs/03-design/LG-03-07.adoc @@ -39,7 +39,7 @@ They know: ** implementations can be exchanged if required. * different approaches for implementing interfaces (R3): ** resource oriented approach (REST, Representational State Transfer) -** service oriented approach (see WS-*/SOAP-based web services. +** service oriented approach (see WS-*/SOAP-based web services). See also <>. diff --git a/docs/03-design/LG-03-09.adoc b/docs/03-design/LG-03-09.adoc index 7029941..8b75e4a 100644 --- a/docs/03-design/LG-03-09.adoc +++ b/docs/03-design/LG-03-09.adoc @@ -5,23 +5,23 @@ Softwarearchitekt:innen kennen den Unterschied zwischen Architektur- und Entwurfsmustern. Sie können mehrere der folgenden Entwurfsmuster erklären, ihre Relevanz für -konkrete Systeme erklären und Beispiele nennen. (R3) +konkrete Systeme erklären und Beispiele nennen. * {glossary_url}combinator[Combinator] -* {glossary_url}interpreter[Interpreter] -* {glossary_url}observer[Observer] -* {glossary_url}remote-procedure-call[Remote procedure call] * Schnittstellenmuster wie {glossary_url}adapter[Adapter], {glossary_url}facade[Facade], und {glossary_url}proxy[Proxy]. Architekt:innen sollten wissen, dass diese Muster unabhängig von bestimmten Programmiersprachen oder Frameworks verwendet werden können. -* {glossary_url}template-method[Template Method] und {glossary_url}Strategy[strategy] +* {glossary_url}interpreter[Interpreter] +* {glossary_url}observer[Observer] +* {glossary_url}remote-procedure-call[Remote procedure call] +* {glossary_url}template-method[Template Method] und {glossary_url}Strategy[Strategy] * {glossary_url}visitor[Visitor] Softwarearchitekt:innen kennen wesentliche Quellen für Entwurfsmuster, wie z.B. -<> und <> (R3). +<> und <>. -Sie wissen (R3): +Sie wissen: * dass Muster ein Weg sind, bestimmte Qualitäten für gegebene Probleme und Anforderungen innerhalb gegebener Kontexte zu erreichen. * dass es verschiedene Kategorien von Mustern gibt. @@ -32,11 +32,11 @@ Sie wissen (R3): // tag::EN[] [[LG-03-09]] -==== LG 03-09 [previously LG 2-05]: Describe, Explain and Apply Important Design Patterns (R3) +==== LG 03-09 [previously LG 2-05]: Describe, Explain, and Appropriately Apply Important Design Patterns (R3) Software architects know the difference between architectural and design patterns. They can explain several of the following design patterns, explain their relevance for -concrete systems, and provide examples. (R3) +concrete systems, and provide examples. * {glossary_url}combinator[Combinator] * Interfacing patterns like {glossary_url}adapter[Adapter], {glossary_url}facade[Facade], @@ -46,13 +46,13 @@ concrete systems, and provide examples. (R3) * {glossary_url}interpreter[Interpreter] * {glossary_url}observer[Observer] * {glossary_url}remote-procedure-call[Remote procedure call] -* {glossary_url}template-method[Template Method] and {glossary_url}Strategy[strategy] +* {glossary_url}template-method[Template Method] and {glossary_url}Strategy[Strategy] * {glossary_url}visitor[Visitor] Software architects know essential sources for design patterns, such as -<> and <>. (R3) +<> and <>. -They know (R3): +They know: * that patterns are a way of achieving certain qualities for given problems and requirements within given contexts. * that there are different categories of patterns. diff --git a/docs/03-design/LG-03-10.adoc b/docs/03-design/LG-03-10.adoc index 9321786..3cbe17d 100644 --- a/docs/03-design/LG-03-10.adoc +++ b/docs/03-design/LG-03-10.adoc @@ -21,12 +21,12 @@ Siehe auch <>. Software architects are able to: -* explain the significance of such {glossary_url}cross-cutting-concern[cross-cutting concerns] -* identify such cross-cutting concerns +* explain the significance of {glossary_url}cross-cutting-concern[cross-cutting concerns] +* identify cross-cutting concerns * design cross-cutting concepts, for example persistence, communication, GUI, error handling, concurrency, energy efficiency * identify and assess potential interdependencies. -Software architects know that such cross-cutting concerns may be re-used across systems. +Software architects know that such cross-cutting concepts may be re-used across systems. See also <>.