From d87fb50a7eb9c463be33df1fa655cdd836e806cc Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 12 Jul 2024 19:29:16 +0200 Subject: [PATCH 1/5] #464 fixed some translation issues in headings and typos normal text --- docs/01-basics/LZ-01-02.adoc | 6 +++--- docs/01-basics/LZ-01-03.adoc | 2 +- docs/01-basics/LZ-01-04.adoc | 2 +- docs/01-basics/LZ-01-05.adoc | 2 +- docs/05-evaluation/LZ-05-02.adoc | 8 ++++---- 5 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/01-basics/LZ-01-02.adoc b/docs/01-basics/LZ-01-02.adoc index 2d381935..1ac0bd13 100644 --- a/docs/01-basics/LZ-01-02.adoc +++ b/docs/01-basics/LZ-01-02.adoc @@ -1,15 +1,15 @@ // tag::DE[] [[LZ-01-02]] -==== LZ 01-02: Nutzen und Ziele von Softwarearchitektur verstehen und erläutern (R1) +==== LZ 01-02: Ziele und Nutzen von Softwarearchitektur verstehen und erläutern (R1) -Softwarearchitekt:innen können folgenden Nutzen und wesentlichen Ziele von Softwarearchitektur begründen: +Softwarearchitekt:innen können die folgenden wesentlichen Ziele und Vorteile der Softwarearchitektur begründen: * Entwurf, Implementierung, Pflege und Betrieb von Systemen zu unterstützen * funktionale Anforderungen zu erreichen bzw. deren Erfüllbarkeit sicherzustellen * Anforderungen wie Zuverlässigkeit, Wartbarkeit, Änderbarkeit, Sicherheit, Energieeffizienz zu erreichen * Verständnis für Strukturen und Konzepte des Systems zu vermitteln, bezogen auf sämtliche relevanten Stakeholder -* systematisch Komplexität zu reduzieren +* Komplexität systematisch reduzieren * architekturrelevante Richtlinien für Implementierung und Betrieb zu spezifizieren // end::DE[] diff --git a/docs/01-basics/LZ-01-03.adoc b/docs/01-basics/LZ-01-03.adoc index 49a8a982..63ec9657 100644 --- a/docs/01-basics/LZ-01-03.adoc +++ b/docs/01-basics/LZ-01-03.adoc @@ -22,7 +22,7 @@ Sie sollen selbstständig die Notwendigkeit von Iterationen bei allen Aufgaben e // tag::EN[] [[LG-01-03]] -==== LG 01-03 [ehemaliges LG 1-4]: Understand Software Architects' Tasks and Responsibilities (R1) +==== LG 01-03 [ehemaliges LG 1-4]: Understand the Tasks and Responsibilities of Software Architects (R1) Software architects are responsible for meeting requirements and creating the architecture design of a solution. Depending on the actual approach or process model used, they must align this responsibility with the overall responsibilities of project management and/or other roles. diff --git a/docs/01-basics/LZ-01-04.adoc b/docs/01-basics/LZ-01-04.adoc index a517d228..3876f0c7 100644 --- a/docs/01-basics/LZ-01-04.adoc +++ b/docs/01-basics/LZ-01-04.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-01-04]] -==== LZ 01-04 [ehemaliges LZ 1-09]: Zuständigkeit von Softwarearchitekt:innen in organisatorischen Kontext einordnen (R3) +==== LZ 01-04 [ehemaliges LZ 1-09]: Verantwortlichkeiten von Softwarearchitekt:innen im größeren architektonischen Kontext (R3) Der Fokus des iSAQB CPSA-Foundation Level liegt auf Strukturen und Konzepten einzelner Softwaresysteme. diff --git a/docs/01-basics/LZ-01-05.adoc b/docs/01-basics/LZ-01-05.adoc index 32d693e6..0c8165b0 100644 --- a/docs/01-basics/LZ-01-05.adoc +++ b/docs/01-basics/LZ-01-05.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-01-05]] -==== LZ 01-05 [ehemaliges LZ 01-05]: Rolle von Softwarearchitekt:innen in Beziehung zu anderen Stakeholdern setzen (R1) +==== LZ 01-05 [ehemaliges LZ 01-05]: Rolle von Softwarearchitekt:innen mit anderen Stakeholdern in Beziehung setzen (R1) Softwarearchitekt:innen können ihre Rolle erklären. Sie sollten ihren Beitrag zur Systementwicklung in Verbindung mit anderen Stakeholdern und Organisationseinheiten kontextspezifisch ausgestalten, insbesondere zu: diff --git a/docs/05-evaluation/LZ-05-02.adoc b/docs/05-evaluation/LZ-05-02.adoc index 651b99df..7c3557a6 100644 --- a/docs/05-evaluation/LZ-05-02.adoc +++ b/docs/05-evaluation/LZ-05-02.adoc @@ -1,15 +1,15 @@ // tag::DE[] [[LZ-05-02]] -==== LZ 05-02 [ehemaliges LZ 4-02]: Qualitäten eines Softwaresystems analysieren (R1, R3) +==== LZ 05-02 [ehemaliges LZ 04-02]: Qualitäten eines Softwaresystems analysieren (R1, R3) Softwarearchitekt:innen -* verstehen dass für eine einzelne Qualität eines Softwaresystems +* verstehen, dass für eine einzelne Qualität eines Softwaresystems verschiedene Analysemethoden zur Verfügung stehen können, wie z.{nbsp}B.: ** Analyse der Ergebnisse von Akzeptanztests (R1) ** quantitative Messung von Laufzeitverhalten (R1) -** qualitative Auswertung durch Interviews, Umfragen, Penetrationstests etc. (R1) +** qualitative Auswertung durch Interviews, Umfragen, Penetrationstests etc. (R1) ** Szenarien (R1) ** Architektur-Metriken für Kopplung wie der Grad eingehender und ausgehender Abhängigkeiten (R1) @@ -20,7 +20,7 @@ Softwarearchitekt:innen ** Architekturdokumentation (R1) ** Architektur- und Entwurfsmodelle (R1) ** Quelltext (R1) -** Quelltext-bezogene Metriken wie z.B: Lines-of-Code, (zyklomatische) +** Quelltext-bezogene Metriken wie z.{nbsp}B: Lines-of-Code, (zyklomatische) Komplexität (R1) ** Testfälle und ihre Testresultate (R1) ** Fehler und ihre Position im Quelltext, besonders Fehlercluster (R1) From adc752a33027e7104d4c727cb1ff00c457495d66 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 12 Jul 2024 19:57:09 +0200 Subject: [PATCH 2/5] #464 fixed some translation issues in headings and typos in normal text, added missing parts in one translation --- docs/00-preamble/03-prerequisites.adoc | 2 +- docs/02-requirements/LZ-02-01.adoc | 16 ++++++++-------- docs/02-requirements/LZ-02-02.adoc | 17 ++++++++--------- docs/02-requirements/LZ-02-03.adoc | 4 ++-- docs/02-requirements/LZ-02-04.adoc | 5 +++-- docs/03-design/LZ-03-08.adoc | 8 ++++---- docs/03-design/LZ-03-10.adoc | 2 +- docs/04-documentation/LZ-04-02.adoc | 4 ++-- docs/04-documentation/LZ-04-06.adoc | 2 +- docs/04-documentation/LZ-04-08.adoc | 2 +- 10 files changed, 31 insertions(+), 31 deletions(-) diff --git a/docs/00-preamble/03-prerequisites.adoc b/docs/00-preamble/03-prerequisites.adoc index 8210cdf1..07af7d98 100644 --- a/docs/00-preamble/03-prerequisites.adoc +++ b/docs/00-preamble/03-prerequisites.adoc @@ -19,7 +19,7 @@ Teilnehmende sollten die im Nachfolgenden genannten Kenntnisse und/oder Erfahrun ** Modellierung und Abstraktion ** Algorithmen und Datenstrukturen (etwa Listen, Bäume, HashTable, Dictionary/Map) ** UML (Klassen-, Paket-, Komponenten- und Sequenzdiagramme) und deren Bezug zum Quellcode -** Vorgehen beim Testen von Software (z.B. Unit- und Akzeptanztests) + ** Vorgehen beim Testen von Software (z.{nbsp}B. Unit- und Akzeptanztests) Hilfreich für das Verständnis einiger Konzepte sind darüber hinaus: diff --git a/docs/02-requirements/LZ-02-01.adoc b/docs/02-requirements/LZ-02-01.adoc index 13d3f4f2..7d5dc675 100644 --- a/docs/02-requirements/LZ-02-01.adoc +++ b/docs/02-requirements/LZ-02-01.adoc @@ -13,29 +13,29 @@ Entwicklungsprozess identifizieren. (R2) |Interessengruppe |Anliegen der Interessengruppe | Produktmanagement -| z. B. benötigte Zeit für die Umsetzung der Anforderungen +| z.{nbsp}B. benötigte Zeit für die Umsetzung der Anforderungen | Projektmanager -| z. B. benötigte Zeit und Budget für die Umsetzung, verbundene Risiken des +| z.{nbsp}B. benötigte Zeit und Budget für die Umsetzung, verbundene Risiken des gewählten architekturellen Ansatzes | Requirements Ingenieure -| z. B. Erfüllung der Anforderungen +| z.{nbsp}B. Erfüllung der Anforderungen | Entwickler -| z. B. zu implementierende Komponenten und Schnittstellen, Protokolle, +| z.{nbsp}B. zu implementierende Komponenten und Schnittstellen, Protokolle, technologische Einschränkungen | Qualitätssicherung und Tester -| z. B. isoliertes Testen von Komponenten +| z.{nbsp}B. isoliertes Testen von Komponenten | Betrieb -| z. B. Infrastrukturanforderungen im Zusammenhang mit dem Betrieb des Systems +| z.{nbsp}B. Infrastrukturanforderungen im Zusammenhang mit dem Betrieb des Systems |=== Softwarearchitekten können potenzielle Konflikte zwischen kurz- und -langfristigen Zielen erklären, um mögliche Konflikte (z.B., Geschäfts- und +langfristigen Zielen erklären, um mögliche Konflikte (z.{nbsp}B., Geschäfts- und Projektziele vs. Architektur- und Wartbarkeitsziele) zu lösen. (R1) Architekten verstehen, dass nicht alle Anliegen der Stakeholder in @@ -44,7 +44,7 @@ werden müssen. (R3) Architekten können die Anliegen der Stakeholder nutzen, um fehlende oder widersprüchliche Anforderungen zu entdecken und/oder Anforderungen und -Einschränkungen an der Architektur zu validieren, z.B. in Stakeholder-Interviews. (R3) +Einschränkungen an der Architektur zu validieren, z.{nbsp}B. in Stakeholder-Interviews. (R3) // end::DE[] // tag::EN[] diff --git a/docs/02-requirements/LZ-02-02.adoc b/docs/02-requirements/LZ-02-02.adoc index e1ff9eca..c6470342 100644 --- a/docs/02-requirements/LZ-02-02.adoc +++ b/docs/02-requirements/LZ-02-02.adoc @@ -3,10 +3,9 @@ [[LZ-02-02]] ==== LZ 02-02 [ehemaliges LZ 2-3]: Anforderungen und Randbedingungen klären und berücksichtigen können (R1-R3) -TODO: translations must be checked - -Softwarearchitekt:innen können Anforderungen (inklusive Randbedingungen als Einschränkungen der Entwurfsfreiheit) klären und berücksichtigen. -Sie verstehen, dass ihre Entscheidungen zu weiteren Anforderungen (inklusive Randbedingungen) an das zu entwerfende System, seine Architektur oder den Entwicklungsprozess führen können. +Softwarearchitekt:innen sind in der Lage, Anforderungen und Randbedingungen zu klären und zu berücksichtigen, die sich +auf die zu entwerfende Architektur oder den Entwurfs- und Entwicklungsprozess auswirken. +Sie wissen, dass ihre Entscheidungen zu zusätzlichen Anforderungen führen können. Sie erkennen und berücksichtigen den Einfluss von: @@ -24,7 +23,7 @@ Sie erkennen und berücksichtigen den Einfluss von: ** Organisationsstruktur von Entwicklungsteams und Auftraggebenden (R1), insbesondere das Gesetz von Conway (R2) ** Unternehmens- und Teamkultur (R3) ** Partnerschaften und Kooperationen (R2) -** Normen, Richtlinien und Prozessmodelle (z.B. Genehmigungs- und Freigabeprozesse) (R2) +** Normen, Richtlinien und Prozessmodelle (z.{nbsp}B. Genehmigungs- und Freigabeprozesse) (R2) ** Verfügbarkeit von Ressourcen wie Budget, Zeit und Personal (R1) ** Verfügbarkeit, Qualifikation und Engagement von Mitarbeitenden (R1) @@ -36,8 +35,8 @@ Sie erkennen und berücksichtigen den Einfluss von: * Trends wie (R3) ** Markttrends -** Technologietrends (z.B. Blockchain, Microservices) -** Methodik-Trends (z.B. agil) +** Technologietrends (z.{nbsp}B. Blockchain, Microservices) +** Methodik-Trends (z.{nbsp}B. Agilität) ** (potenzielle) Auswirkungen weiterer Stakeholderinteressen und vorgegebener oder extern festgelegter Designentscheidungen // end::DE[] @@ -77,8 +76,8 @@ They should recognize and account for the impact of: * trends such as (R3) ** market trends -** technology trends -** methodology trends +** technology trends (Blockchain, Microservices) +** methodology trends (Agile) Software architects are able to describe how those factors can influence design decisions and can elaborate on the consequences of changing diff --git a/docs/02-requirements/LZ-02-03.adoc b/docs/02-requirements/LZ-02-03.adoc index c4844bc6..da1cbcb6 100644 --- a/docs/02-requirements/LZ-02-03.adoc +++ b/docs/02-requirements/LZ-02-03.adoc @@ -7,10 +7,10 @@ Softwarearchitekt:innen können erklären: * dass der Begriff "Qualität" in verschiedenen Kontexten unterschiedlich benutzt wird - im Kontext von Qualitätsmanagement im - Sinne von "Güte" und im Sinne einer spezifischen Eigenschaften + Sinne von "Güte" und im Sinne spezifischer Eigenschaften (eines Softwaresystems) in anderen (und in diesem Abschnitt) * dass es unterschiedliche Taxonomien gibt, die Qualitäten von - Softwaresystemen kategorisieren (wie z.{nbsp}B. <>, + Softwaresystemen kategorisieren (wie z.{nbsp}B. <>, <> oder <>) * dass manche Kategorisierungen zwischen Funktionalität und Qualität unterscheiden * dass Softwarearchitekt:innen die Qualitäten eines Softwaresystems diff --git a/docs/02-requirements/LZ-02-04.adoc b/docs/02-requirements/LZ-02-04.adoc index d10be570..d79e2201 100644 --- a/docs/02-requirements/LZ-02-04.adoc +++ b/docs/02-requirements/LZ-02-04.adoc @@ -1,14 +1,15 @@ // tag::DE[] [[LZ-02-04]] -==== LZ 02-04 [ehemaliges LZ 04-03]: Requirements and Software Architecture (R1-R3) +==== LZ 02-04 [ehemaliges LZ 04-03]: Anforderungen und Softwarearchitektur (R1-R3) + Softwarearchitekt:innen: * verstehen, dass eine Anforderung für eine gegebene Qualität eine Analysemethode spezifizieren sollte (siehe <>) (R1) * verstehen, dass manche Kategorisierungen zwischen "Qualitätsanforderungen" und funktionalen Anforderungen - unterscheiden, wie zum Beispiel IREB <> R1) + unterscheiden, wie zum Beispiel IREB <> (R1) * verstehen, dass eine einzelne Anforderung sich auf mehrere Qualitäten beziehen kann (R1) * wissen, dass die Verwendung einer Metrik als Ziel diese invalidieren diff --git a/docs/03-design/LZ-03-08.adoc b/docs/03-design/LZ-03-08.adoc index 0dc57e9c..80a966d1 100644 --- a/docs/03-design/LZ-03-08.adoc +++ b/docs/03-design/LZ-03-08.adoc @@ -33,7 +33,7 @@ Softwarearchitekt:innen können einige der folgendene Muster erklären, ihre Rel * CQRS (Command-Query-Responsibility-Segregation): Trennung von Lese- und Schreibvorgängen in Informationssystemen. Erfordert Einblicke in konkrete Datenbank-/Persistenztechnologie, um die unterschiedlichen Eigenschaften und Anforderungen von "Lese-" und "Schreib"-Operationen zu verstehen. * Event-Sourcing: Behandlung von Datenoperationen durch eine Abfolge von Ereignissen (Events), von denen jedes in einem Append-only Speicher aufgezeichnet wird. * Interpreter: repräsentieren Domänenobjekt oder DSL als Syntax, bieten eine Funktion, die eine semantische Interpretation des Domänenobjekts getrennt vom Domänenobjekt selbst implementiert. -* Integrations- oder Messaging-Patterns (z.B. aus <>) +* Integrations- oder Messaging-Patterns (z.{nbsp}B. aus <>) * Die MVC- (Model View Controller), MVVM- (Model View ViewModel), MVU- (Model View Update), PAC- (Presentation Abstraction Control) Musterfamilie, die die externe Repräsentation (Ansicht) von Daten von Operationen Diensten und deren Koordination trennt. * Schnittstellenmuster wie Adapter, Fassade, Proxy. Solche Muster helfen bei der Integration von Subsystemen und/oder bei der Vereinfachung von Abhängigkeiten. Architekt:innen sollten wissen, dass diese Muster unabhängig von (Objekt-)Technologie verwendet werden können. ** Adapter: Entkopplung von Konsument und Provider - wenn die Schnittstelle des Providers nicht genau mit der des Konsumenten übereinstimmt. @@ -43,14 +43,14 @@ Softwarearchitekt:innen können einige der folgendene Muster erklären, ihre Rel registriert sich bei einem Objekt (dem Subjekt), damit das Subjekt den Observer bei Änderungen benachrichtigt. * Plug-In: erweitert das Verhalten einer Komponente. -* Ports&Adapters (syn. Onion-Architecture, Hexagonale Architektur, Clean-Architecture): konzentrieren die Domänenlogik im Zentrum des Systems, und besitzen lediglich an den Rändern Verbindungen zur Außenwelt (Datenbank, UI). Abhängigkeiten von außen nach innen (Outside-In), niemals von innen nach außen (Inside-Out). <> <> +* Ports & Adapters (Synonyme: Onion-Architecture, Hexagonale Architektur, Clean-Architecture): konzentrieren die Domänenlogik im Zentrum des Systems, und besitzen lediglich an den Rändern Verbindungen zur Außenwelt (Datenbank, UI). Abhängigkeiten von außen nach innen (Outside-In), niemals von innen nach außen (Inside-Out). <> <> * Remote Procedure Call: eine Funktion oder einen Algorithmus in einem anderen Adressraum ausführen lassen. * SOA (Service-orientierte Architektur): Ein Ansatz zur Bereitstellung abstrakter Dienste statt konkreter Implementierungen für die Benutzer des Systems, um die Wiederverwendung von Diensten über Abteilungen und zwischen Unternehmen zu fördern. * Template und Strategy: spezifische Algorithmen durch Kapselung flexibel machen. * Visitor (Besucher): Traversierung von Datenstrukturen von spezifischer Verarbeitung trennen. -Softwarearchitekt:innen kennen wesentliche Quellen für Architekturmuster, beispielsweise die POSA-Literatur (z.B. <>) und PoEAA (<>) (für Informationssysteme) (R3) +Softwarearchitekt:innen kennen wesentliche Quellen für Architekturmuster, beispielsweise die POSA-Literatur (z.{nbsp}B. <>) und PoEAA (<>) (für Informationssysteme) (R3) // end::DE[] @@ -95,7 +95,7 @@ Software architects can explain several of the following patterns, explain their * _observer_: An interested object (observer) registers with another object (the subject) so that the subject notifies the observer upon changes. * _plug-in_: extend the behaviour of a component -* _ports & adapters_ (syn. Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): concentrate domain logic in the center of the system, have connections to the outside world (database, UI) at the edges, dependencies only outside-in, never inside-out <> <> +* _ports & adapters_ (synonyms: Onion-Architecture, Hexagonal-Architecture, Clean-Architecture): concentrate domain logic in the center of the system, have connections to the outside world (database, UI) at the edges, dependencies only outside-in, never inside-out <> <> * _remote procedure call_: make a function or algorithm execute in a different address space * _SOA_ (Service-Oriented Architecture): an approach to provide abstract services rather than concrete implementations to users of the system to promote reuse of services across departments and between companies * _template and strategy_: make specific algorithms flexible by encapsulating them diff --git a/docs/03-design/LZ-03-10.adoc b/docs/03-design/LZ-03-10.adoc index 3b571559..d852d52e 100644 --- a/docs/03-design/LZ-03-10.adoc +++ b/docs/03-design/LZ-03-10.adoc @@ -9,7 +9,7 @@ Softwarearchitekt:innen: * können grundlegende Konzepte des Deployments von Software benennen und erklären, beispielsweise: ** Automatisierung von Deployments ** Wiederholbare Builds -** Konsistente Umgebungen (z.B. durch Nutzung von unveränderlicher (_immutable_) Infrastruktur) +** Konsistente Umgebungen (z.{nbsp}B. durch Nutzung von unveränderlicher (_immutable_) Infrastruktur) ** Alles liegt unter Versionskontrolle ** Releases sind einfach zurückzunehmen diff --git a/docs/04-documentation/LZ-04-02.adoc b/docs/04-documentation/LZ-04-02.adoc index faec23a8..d13175cc 100644 --- a/docs/04-documentation/LZ-04-02.adoc +++ b/docs/04-documentation/LZ-04-02.adoc @@ -6,7 +6,7 @@ Softwarearchitekt:innen nutzen Dokumentation zur Unterstützung bei Entwurf, Imp Softwarearchitekt:innen (R1): -* können Architekturen entsprechend der Anliegen der Stakeholder dokumentieren und kommunizieren und dadurch unterschiedliche Zielgruppen adressieren, z. B. Management, Entwicklungsteams, QS, andere Softwarearchitekt:innen sowie möglicherweise zusätzliche Stakeholder +* können Architekturen entsprechend der Anliegen der Stakeholder dokumentieren und kommunizieren und dadurch unterschiedliche Zielgruppen adressieren, z.{nbsp}B. Management, Entwicklungsteams, QS, andere Softwarearchitekt:innen sowie möglicherweise zusätzliche Stakeholder * können die Beiträge unterschiedlicher Autorengruppen stilistisch und inhaltlich konsolidieren und harmonisieren * können Maßnahmen entwickeln und umsetzen, die mündliche und schriftliche Kommunikation in Einklang miteinander halten und miteinander angemessen ausbalancieren * kennen den Nutzen von Template-basierter Dokumentation @@ -17,7 +17,7 @@ Sie können beispielsweise die folgenden Merkmale von Dokumentation je nach Situ * Umfang und Detaillierungsgrad der benötigten Dokumentation * das Dokumentationsformat * die Zugänglichkeit der Dokumentation -* Formalitäten der Dokumentation (z.B. Diagramme, die einem Metamodell entsprechen, oder einfache Zeichnungen) +* Formalitäten der Dokumentation (z.{nbsp}B. Diagramme, die einem Metamodell entsprechen, oder einfache Zeichnungen) * formale Überprüfungen und Freigabeprozesse für die Dokumentation diff --git a/docs/04-documentation/LZ-04-06.adoc b/docs/04-documentation/LZ-04-06.adoc index 696621dd..1ad7d127 100644 --- a/docs/04-documentation/LZ-04-06.adoc +++ b/docs/04-documentation/LZ-04-06.adoc @@ -4,7 +4,7 @@ ==== LZ 04-06 [ehemaliges LZ 3-05]: Kontextabgrenzung von Systemen erläutern und anwenden (R1) Softwarearchitekt:innen können: -* Kontext von Systemen z.B. in Form von Kontextdiagrammen mit Erläuterungen darstellen +* Kontext von Systemen z.{nbsp}B. in Form von Kontextdiagrammen mit Erläuterungen darstellen * externe Schnittstellen von Systemen in der Kontextabgrenzung darstellen * fachlichen und technischen Kontext differenzieren. diff --git a/docs/04-documentation/LZ-04-08.adoc b/docs/04-documentation/LZ-04-08.adoc index 3c2f032a..d5877b51 100644 --- a/docs/04-documentation/LZ-04-08.adoc +++ b/docs/04-documentation/LZ-04-08.adoc @@ -6,7 +6,7 @@ Softwarearchitekt:innen können typische Querschnittsthemen (synonym _Querschnittskonzepte_, _Aspekte_) adäquat dokumentieren und kommunizieren, -z. B. Persistenz, Ablaufsteuerung, UI, Verteilung/Integration, Protokollierung. +z.{nbsp}B. Persistenz, Ablaufsteuerung, UI, Verteilung/Integration, Protokollierung. // end::DE[] From 53de140c0ca2a788e53f12a32187f515afa327f0 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Fri, 12 Jul 2024 20:25:36 +0200 Subject: [PATCH 3/5] #464 fixed some translation issues in headings and typos in normal text --- docs/03-design/LZ-03-08.adoc | 1 - docs/06-examples/LZ-06-01.adoc | 2 +- docs/06-examples/LZ-06-02.adoc | 4 +++- 3 files changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/03-design/LZ-03-08.adoc b/docs/03-design/LZ-03-08.adoc index 80a966d1..fc84c51d 100644 --- a/docs/03-design/LZ-03-08.adoc +++ b/docs/03-design/LZ-03-08.adoc @@ -58,7 +58,6 @@ Softwarearchitekt:innen kennen wesentliche Quellen für Architekturmuster, beisp [[LG-03-08]] ==== LG 03-08 [previously LG 2-05]: Describe, Explain and Appropriately Apply Important Patterns (R1, R3) - Software architects know: * various architectural patterns and can apply them when appropriate diff --git a/docs/06-examples/LZ-06-01.adoc b/docs/06-examples/LZ-06-01.adoc index 99a01ac6..e8e837d2 100644 --- a/docs/06-examples/LZ-06-01.adoc +++ b/docs/06-examples/LZ-06-01.adoc @@ -1,6 +1,6 @@ // tag::DE[] [[LZ-06-01]] -==== LZ 06-01: Bezug von Anforderungen und Randbedingungen zu Lösung erfassen (R3) +==== LZ 06-01: Bezug von Anforderungen und Randbedingungen zur Lösung erfassen (R3) Softwarearchitekt:innen haben an mindestens einem Beispiel den Bezug von Anforderungen und Randbedingungen zu Lösungsentscheidungen erkannt und nachvollzogen. // end::DE[] diff --git a/docs/06-examples/LZ-06-02.adoc b/docs/06-examples/LZ-06-02.adoc index f64f44ad..4449c58f 100644 --- a/docs/06-examples/LZ-06-02.adoc +++ b/docs/06-examples/LZ-06-02.adoc @@ -1,13 +1,15 @@ // tag::DE[] [[LZ-06-02]] ==== LZ 06-02: Technische Umsetzung einer Lösung nachvollziehen (R3) + Softwarearchitekt:innen können anhand mindestens eines Beispiels die technische Umsetzung (Implementierung, technische Konzepte, eingesetzte Produkte, Lösungsstrategien) einer Lösung nachvollziehen. // end::DE[] // tag::EN[] [[LG-06-02]] -==== LG 06-02: Know the Rationale of a Solution's Technical Implementation (R3) +==== LG 06-02: Understand the technical implementation of a solution (R3) + Software architects understand the technical realization (implementation, technical concepts, products used, architectural decisions, solution strategies) of at least one solution. // end::EN[] From 340be06a9ee88be9176aabca240b08df62f25419 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Mon, 15 Jul 2024 19:44:54 +0200 Subject: [PATCH 4/5] #464 further titles adjusted: using a verb within LG titles --- docs/01-basics/LZ-01-04.adoc | 4 ++-- docs/02-requirements/LZ-02-01.adoc | 4 ++-- docs/02-requirements/LZ-02-04.adoc | 4 ++-- docs/02-requirements/LZ-02-05.adoc | 2 +- docs/03-design/LZ-03-03.adoc | 1 + docs/03-design/LZ-03-04.adoc | 9 +++++---- docs/03-design/LZ-03-09.adoc | 2 +- docs/03-design/LZ-03-11.adoc | 4 ++-- docs/04-documentation/LZ-04-04.adoc | 6 +++--- docs/05-evaluation/LZ-05-01.adoc | 4 ++-- docs/05-evaluation/LZ-05-02.adoc | 2 +- docs/05-evaluation/LZ-05-03.adoc | 4 ++-- 12 files changed, 24 insertions(+), 22 deletions(-) diff --git a/docs/01-basics/LZ-01-04.adoc b/docs/01-basics/LZ-01-04.adoc index 3876f0c7..95e22d99 100644 --- a/docs/01-basics/LZ-01-04.adoc +++ b/docs/01-basics/LZ-01-04.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-01-04]] -==== LZ 01-04 [ehemaliges LZ 1-09]: Verantwortlichkeiten von Softwarearchitekt:innen im größeren architektonischen Kontext (R3) +==== LZ 01-04 [ehemaliges LZ 1-09]: Verantwortlichkeiten von Softwarearchitekt:innen in organisatorischen Kontext einordnen (R3) Der Fokus des iSAQB CPSA-Foundation Level liegt auf Strukturen und Konzepten einzelner Softwaresysteme. @@ -21,7 +21,7 @@ Diese Architekturdomänen sind nicht inhaltlicher Fokus vom CPSA-F. // tag::EN[] [[LG-01-04]] -==== LG 01-04 [previously LG 1-09]: Responsibilities of Software Architects within the Greater Architectural Context (R3) +==== LG 01-04 [previously LG 1-09]: Classify Responsibilities of Software Architects within the Greater Architectural Context (R3) The focus of the iSAQB CPSA Foundation Level is on structures and concepts of individual software systems. diff --git a/docs/02-requirements/LZ-02-01.adoc b/docs/02-requirements/LZ-02-01.adoc index 7d5dc675..1609f508 100644 --- a/docs/02-requirements/LZ-02-01.adoc +++ b/docs/02-requirements/LZ-02-01.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-02-01]] -==== LZ 02-01: Stakeholder-Anliegen +==== LZ 02-01: Stakeholder-Anliegen verstehen Architekten können Stakeholder und deren Anliegen sowie deren Auswirkungen auf die Softwarearchitektur oder den Entwurfs- und @@ -49,7 +49,7 @@ Einschränkungen an der Architektur zu validieren, z.{nbsp}B. in Stakeholder-Int // tag::EN[] [[LG-02-01]] -==== LG 02-01: Stakeholder Concerns (R1 - R3) +==== LG 02-01: Unterstand Stakeholder Concerns (R1 - R3) Architects can identify stakeholders and their concerns, as well as their impact on the software architecture or the design and development process. (R2) diff --git a/docs/02-requirements/LZ-02-04.adoc b/docs/02-requirements/LZ-02-04.adoc index d79e2201..cbcd7e30 100644 --- a/docs/02-requirements/LZ-02-04.adoc +++ b/docs/02-requirements/LZ-02-04.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-02-04]] -==== LZ 02-04 [ehemaliges LZ 04-03]: Anforderungen und Softwarearchitektur (R1-R3) +==== LZ 02-04 [ehemaliges LZ 04-03]: Bedeutung von Anforderungen für die Softwarearchitektur verstehen (R1-R3) Softwarearchitekt:innen: @@ -23,7 +23,7 @@ Softwarearchitekt:innen: // tag::EN[] [[LG-02-04]] -==== LG 02-04 [previously LG 04-03]: Requirements and Software Architecture (R1-R3) +==== LG 02-04 [previously LG 04-03]: Understand the Importance of Requirements for Software Architecture (R1-R3) Software architects: diff --git a/docs/02-requirements/LZ-02-05.adoc b/docs/02-requirements/LZ-02-05.adoc index 3f942088..a4696af4 100644 --- a/docs/02-requirements/LZ-02-05.adoc +++ b/docs/02-requirements/LZ-02-05.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-02-05]] -==== LZ 02-05 [ehemaliges LZ 1-08]: Bevorzuge explizite Aussagen vor impliziten Annahmen (R1) +==== LZ 02-05 [ehemaliges LZ 1-08]: Explizite Aussagen vor impliziten Annahmen bevorzugen (R1) Softwarearchitekt:innen: diff --git a/docs/03-design/LZ-03-03.adoc b/docs/03-design/LZ-03-03.adoc index d7bfb83e..1bf5d7a3 100644 --- a/docs/03-design/LZ-03-03.adoc +++ b/docs/03-design/LZ-03-03.adoc @@ -2,6 +2,7 @@ // tag::DE[] [[LZ-03-03]] ==== LZ 03-03 [ehemaliges LZ 2-01]: Vorgehen und Heuristiken zur Architekturentwicklung auswählen und anwenden können (R1,R3) + Softwarearchitekt:innen können grundlegende Vorgehensweisen der Architekturentwicklung benennen, erklären und anwenden, beispielsweise: * Top-down- und Bottom-up-Vorgehen beim Entwurf (R1) diff --git a/docs/03-design/LZ-03-04.adoc b/docs/03-design/LZ-03-04.adoc index 62e094dc..6ea1f798 100644 --- a/docs/03-design/LZ-03-04.adoc +++ b/docs/03-design/LZ-03-04.adoc @@ -63,6 +63,7 @@ Softwarearchitekt:innen kennen weitere Prinzipien (etwa CUPID, siehe <> * high cohesion (R1) * SOLID principles (R1-R3), which have, to a certain extent, relevance at the architectural level -** S: Single responsibility principle (R1) and its relation to SoC +** S: Single responsibility principle (R1) and its relation to SoC ** O: Open/closed principle (R1) -** L: Liskov substitution principle (R3) as a way to achieve consistency and conceptual integrity in OO design -** I: Interface segregation principle (R2) +** L: Liskov substitution principle (R3) as a way to achieve consistency and conceptual integrity in OO design +** I: Interface segregation principle (R2) //, including its relation to <> -** D: Dependency inversion principle (R1) by means of interfaces or similar abstractions +** D: Dependency inversion principle (R1) by means of interfaces or similar abstractions **Conceptual integrity** (R2) diff --git a/docs/03-design/LZ-03-09.adoc b/docs/03-design/LZ-03-09.adoc index 953a398d..b85f30cc 100644 --- a/docs/03-design/LZ-03-09.adoc +++ b/docs/03-design/LZ-03-09.adoc @@ -16,7 +16,7 @@ Softwarearchitekt:innen wissen, dass solche Querschnittskonzepte systemübergrei // tag::EN[] [[LG-03-09]] -==== LG 03-09 [previously LG 2-04]: Design and Implement Cross-Cutting Concerns (R1) +==== LG 03-09 [previously LG 2-04]: Identify, Design and Implement Cross-Cutting Concerns (R1) Software architects are able to: diff --git a/docs/03-design/LZ-03-11.adoc b/docs/03-design/LZ-03-11.adoc index 0ea55601..fa322c34 100644 --- a/docs/03-design/LZ-03-11.adoc +++ b/docs/03-design/LZ-03-11.adoc @@ -1,7 +1,7 @@ // tag::DE[] [[LZ-03-11]] -==== LZ 03-11 [ehemaliges LZ 1-11]: Herausforderungen verteilter Systeme (R3) +==== LZ 03-11 [ehemaliges LZ 1-11]: Herausforderungen verteilter Systeme kennen (R3) Softwarearchitekt:innen können: @@ -19,7 +19,7 @@ Softwarearchitekt:innen wissen: // tag::EN[] [[LG-03-11]] -==== LG 03-11 [previously LG 1-11]: Challenges of Distributed Systems (R3) +==== LG 03-11 [previously LG 1-11]: Know the Challenges of Distributed Systems (R3) Software architects are able to: diff --git a/docs/04-documentation/LZ-04-04.adoc b/docs/04-documentation/LZ-04-04.adoc index 1c918bb7..596bcfb1 100644 --- a/docs/04-documentation/LZ-04-04.adoc +++ b/docs/04-documentation/LZ-04-04.adoc @@ -1,15 +1,15 @@ // tag::DE[] [[LZ-04-04]] ==== LZ 04-04 [new]: Fehler: Lernziel nicht gefunden (R3) -Softwarearchitekt:innen können unerwartete Situationen geschickt bewältigen. +Softwarearchitekt:innen können unerwartete Situationen geschickt bewältigen. // end::DE[] // tag::EN[] [[LG-04-04]] -==== LG 04-04 [new]: Learning Goal not Found (R3) -Software architects are able to gracefully deal with unexpected situations. +==== LG 04-04 [new]: Error: Learning Goal not Found (R3) +Software architects are able to gracefully deal with unexpected situations. // end::EN[] diff --git a/docs/05-evaluation/LZ-05-01.adoc b/docs/05-evaluation/LZ-05-01.adoc index 5b506443..b8b05914 100644 --- a/docs/05-evaluation/LZ-05-01.adoc +++ b/docs/05-evaluation/LZ-05-01.adoc @@ -1,6 +1,6 @@ // tag::DE[] [[LZ-05-01]] -==== LZ 05-01: Gründe für Architekturanalyse (R1) +==== LZ 05-01: Gründe für Architekturanalyse kennen (R1) Softwarearchitekt:innen verstehen, dass es verschiedene mögliche Gründe gibt, um eine Architekturanalyse durchzuführen, zum Beispiel: @@ -17,7 +17,7 @@ Gründe gibt, um eine Architekturanalyse durchzuführen, zum Beispiel: // tag::EN[] [[LG-05-01]] -==== LG 05-01: Reasons for Architecture Analysis (R1) +==== LG 05-01: Know the Reasons for Architecture Analysis (R1) Software architects understand that there are different possible reasons for performing architecture analysis, for example: diff --git a/docs/05-evaluation/LZ-05-02.adoc b/docs/05-evaluation/LZ-05-02.adoc index 7c3557a6..f6c1cc35 100644 --- a/docs/05-evaluation/LZ-05-02.adoc +++ b/docs/05-evaluation/LZ-05-02.adoc @@ -34,7 +34,7 @@ Softwarearchitekt:innen // tag::EN[] [[LG-05-02]] -==== LG 05-02 [previously LG 4-02]: Analysis of Software System Qualities (R1, R3) +==== LG 05-02 [previously LG 4-02]: Analyze the Qualities of a Software System (R1, R3) Software architects diff --git a/docs/05-evaluation/LZ-05-03.adoc b/docs/05-evaluation/LZ-05-03.adoc index 3e8a4f4d..146d179d 100644 --- a/docs/05-evaluation/LZ-05-03.adoc +++ b/docs/05-evaluation/LZ-05-03.adoc @@ -1,6 +1,6 @@ // tag::DE[] [[LZ-05-03]] -==== LZ 05-03: Qualitätsszenarien, Qualitätsbäume (R2, R3) +==== LZ 05-03: Qualitätsszenarien formulieren und Qualitätsbäume beschreiben können (R2, R3) Softwarearchitekt:innen @@ -13,7 +13,7 @@ Softwarearchitekt:innen // tag::EN[] [[LG-05-03]] -==== LZ 05-03: Quality Scenarios, Quality Trees (R2, R3) +==== LZ 05-03: Formulate Quality Scenarios and Describe Quality Trees (R2, R3) Software architects From 0c3d7eb72fa662bd602db7b84e4e749c2e919b34 Mon Sep 17 00:00:00 2001 From: Falk Sippach Date: Tue, 16 Jul 2024 10:55:55 +0200 Subject: [PATCH 5/5] #464 further titles adjusted: using a verb within LG titles --- docs/01-basics/LZ-01-02.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/01-basics/LZ-01-02.adoc b/docs/01-basics/LZ-01-02.adoc index 1ac0bd13..6bebfc96 100644 --- a/docs/01-basics/LZ-01-02.adoc +++ b/docs/01-basics/LZ-01-02.adoc @@ -3,13 +3,13 @@ [[LZ-01-02]] ==== LZ 01-02: Ziele und Nutzen von Softwarearchitektur verstehen und erläutern (R1) -Softwarearchitekt:innen können die folgenden wesentlichen Ziele und Vorteile der Softwarearchitektur begründen: +Softwarearchitekt:innen können die folgenden wesentlichen Ziele und Nutzen der Softwarearchitektur begründen: * Entwurf, Implementierung, Pflege und Betrieb von Systemen zu unterstützen * funktionale Anforderungen zu erreichen bzw. deren Erfüllbarkeit sicherzustellen * Anforderungen wie Zuverlässigkeit, Wartbarkeit, Änderbarkeit, Sicherheit, Energieeffizienz zu erreichen * Verständnis für Strukturen und Konzepte des Systems zu vermitteln, bezogen auf sämtliche relevanten Stakeholder -* Komplexität systematisch reduzieren +* Komplexität systematisch zu reduzieren * architekturrelevante Richtlinien für Implementierung und Betrieb zu spezifizieren // end::DE[]