From b2be9c2262889f246271ce17deff7c7ad11bfe1e Mon Sep 17 00:00:00 2001 From: Ulrich Becker Date: Thu, 28 Oct 2021 14:20:24 +0200 Subject: [PATCH] Fix typos --- docs/01-system-development/02-learning-goals.adoc | 2 +- .../02-software-development/02-learning-goals.adoc | 8 ++++---- docs/04-realtime/02-learning-goals.adoc | 14 +++++++------- docs/05-adaptability/02-learning-goals.adoc | 6 +++--- 4 files changed, 15 insertions(+), 15 deletions(-) diff --git a/docs/01-system-development/02-learning-goals.adoc b/docs/01-system-development/02-learning-goals.adoc index cbb50a2..a0c7537 100644 --- a/docs/01-system-development/02-learning-goals.adoc +++ b/docs/01-system-development/02-learning-goals.adoc @@ -123,7 +123,7 @@ technical systems architecture: * Decide on the communication paradigm (e.g., time triggered vs. event triggered). * Decide on network topologies (e.g., bus vs. star) and network technologies, - both wired (e.g., ethernet, flexray, CAN), and wireless (e.g., Bluetooth, + both wired (e.g., Ethernet, FlexRay, CAN), and wireless (e.g., Bluetooth, WiFi, cellular). Participants understand the challenges of distributed systems regarding latency, diff --git a/docs/02-software-development/02-learning-goals.adoc b/docs/02-software-development/02-learning-goals.adoc index b23a3ba..bbb609b 100644 --- a/docs/02-software-development/02-learning-goals.adoc +++ b/docs/02-software-development/02-learning-goals.adoc @@ -83,10 +83,10 @@ Participants know how models can be used to generate artifacts for the realization, and understand the trade-offs: * Different kinds of models and model elements can be used: structural models - (e.g., UML component models, AADL) and behavioral models (e.g., statecharts, + (e.g., UML component models, AADL) and behavioral models (e.g., state charts, activity diagrams). -* Different kinds artifacts can be generated, e.g. implementation code, test +* Different kinds of artifacts can be generated, e.g. implementation code, test cases, configurations, or analysis models. * Using a model-based approach can have the following benefits: @@ -95,7 +95,7 @@ realization, and understand the trade-offs: ** Increased quality since manual errors can be eliminated. -** Can support adaptibility in a resource-efficient way by resolving variability +** Can support adaptability in a resource-efficient way by resolving variability during code generation. * Using a model-based approach has the following potential costs: @@ -136,7 +136,7 @@ and know the limitations of these techniques: [[LG-2-7]] ==== LG 2-7: Design Paradigms -Participants know design principles and paradigms for embdded software, such as +Participants know design principles and paradigms for embedded software, such as design by contract, the robustness principle, or defensive programming. // end::EN[] diff --git a/docs/04-realtime/02-learning-goals.adoc b/docs/04-realtime/02-learning-goals.adoc index eb05a83..fac5d02 100644 --- a/docs/04-realtime/02-learning-goals.adoc +++ b/docs/04-realtime/02-learning-goals.adoc @@ -50,7 +50,7 @@ systems: * Map logical tasks to jobs. * Decide on technical solutions (e.g., RTOS tasks), and allocate jobs to the - the technical solution elements. + technical solution elements. * Implement the real-time architectural design. @@ -76,8 +76,8 @@ Participants understand that real-time is a cross-cutting concern. ==== LG 4-3: Real-Time Requirements Participants are able to specify and model real-time requirements. They know -different approaches to specifying real-time requirements (e.g., specifiying -real-time requirements in UML, SysML, or AADL) and are able to select a suitable +different approaches to specifying real-time requirements (e.g., specifying +real-time requirements in UML, SysML, or AADL) and can select a suitable approach for a particular system. @@ -138,7 +138,7 @@ RTOS-based event-triggered approach: * Participants can define the RTOS-tasks and their characteristics. * Participants can describe important timing properties of RTOSes and hardware - (i.e. interrupt latency, scheduling latency, dispatch latency) + (e.g., interrupt latency, scheduling latency, dispatch latency) Application-level interrupt handling: @@ -175,7 +175,7 @@ elements which share the same software resources to the same RTOS task). Participants understand how deadlocks occur and how they can be avoided. -Partipants understand priority inversion and know solution approaches (priority +Participants understand priority inversion and know solution approaches (priority ceiling, priority inheritance). @@ -255,8 +255,8 @@ Shared resource analysis: ==== LG 4-9: Tools for Real-Time Architectural Design and Analysis Participants understand that tools for specification, design and analysis of -real-time systems are needed for complex embedded systems with a large number of -external real-time requirements. +real-time systems are needed for complex embedded systems with many external +real-time requirements. Participants know application areas of tools for real-time architectural design and analysis, such as modeling the real-time architectural design, static WCET diff --git a/docs/05-adaptability/02-learning-goals.adoc b/docs/05-adaptability/02-learning-goals.adoc index b1411ea..0fdf6ca 100644 --- a/docs/05-adaptability/02-learning-goals.adoc +++ b/docs/05-adaptability/02-learning-goals.adoc @@ -18,7 +18,7 @@ Participants know possible binding times when variability can be resolved Participants know trade-offs and drawbacks of increased adaptability and variability as well as competing quality goals (e.g., testability, performance, -safety, security and backwards compatibility) and complementing quality goals +safety, security, and backwards compatibility) and complementing quality goals (e.g., maintainability, reusability). Participants know high level approaches to adaptability and variability such as @@ -36,7 +36,7 @@ technical architectures can support adaptability and variability by allowing alternative technical architectures for the same functional architecture. Participants know how to model variation points in requirements, functional -architectures and technical architectures. +architectures, and technical architectures. [[LG-5-3]] ==== LG 5-3: Supporting Adaptability and Variability @@ -67,7 +67,7 @@ Participants understand the trade-offs of using legacy code and how its usage can restrict adaptability and variability. Participants know how to maintain adaptability and deal with new adaptability -requirements, e.g. by refactoring. +requirements (e.g., by refactoring). Participants know approaches how to handle system and software updates, as well as trade-offs of updates.