Merge pull request #624 from isaqb-org/Chapter_3_Fix_translations_and…

…_wording

Chapter 3 Fix translations, wording, redundant relevance levels

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;

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 <<LG-04-05>>)
-* 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 <<LG-03-06>>)
-* 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 <<LG-03-06>>)
+* 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 <<LG-04-05>>)
-* 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.
 

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
 

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)

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 <<LG-04-06>>.
 

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.
-<<gof,GOF>> und <<buschmanna,POSA>> (R3).
+<<gof,GOF>> und <<buschmanna,POSA>>.
 
-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
-<<gof,GOF>> and <<buschmanna,POSA>>. (R3)
+<<gof,GOF>> and <<buschmanna,POSA>>.
 
-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.

docs/03-design/LG-03-10.adoc

@@ -21,12 +21,12 @@ Siehe auch <<LG-04-07>>.
 
 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 <<LG-04-07>>.