david gauchard 4 years ago
parent
commit
181d03c553
1 changed files with 4 additions and 4 deletions
  1. 4
    4
      doc/sujets/tex/conception/conception_robot.tex

+ 4
- 4
doc/sujets/tex/conception/conception_robot.tex View File

@@ -212,7 +212,7 @@ La dernière fonctionnalité qui sera traitée dans cette conception introduit d
212 212
 %%%%%%%%%%%%%%%%%%%%%%%%%
213 213
 
214 214
 \subsection{Identification des threads}
215
-Après avoir identifier les fonctions de l'application, le concepteur doit préciser quand l'exécution des fonctions se produit. La première étape consiste à considérer chaque fonction comme un thread. Deux questions se posent alors :
215
+Après avoir identifié les fonctions de l'application, le concepteur doit préciser quand l'exécution des fonctions se produit. La première étape consiste à considérer chaque fonction comme un thread. Deux questions se posent alors :
216 216
 \begin{itemize}
217 217
 	\item Quel est le type du thread ? Un thread apériodique (noté par un A dans un rond) est un thread dont l'exécution est contrôlé par des événements alors qu'un thread périodique (noté par la valeur de la période dans un rond) aura une exécution qui revient périodiquement.
218 218
 	\item Quel est la priorité du thread ? Une règle simple pour les threads périodiques est d'attribuer les priorités par ordre décroissant des périodes, c'est-à-dire qu'un thread sera d'autant plus prioritaire que sa période sera petite.  Pour les threads apériodiques, le niveau de priorité va dépendre de la criticité des fonctions.\\
@@ -229,7 +229,7 @@ Après avoir identifier les fonctions de l'application, le concepteur doit préc
229 229
 
230 230
 Une seconde étape consiste à avoir un regard critique sur sa conception, par exemple en se demandant s'il est possible de réunir des threads ensembles. Ici, le thread {\tt Etablissement de la communication avec le moniteur} ne peut être appelé qu'après {\tt démarrer serveur}, il est donc possible de les réunir en un seul thread.
231 231
 
232
-C'est aussi le moment de se demande si toutes les fonctionnalités sont couvertes. Pour cela on reprend chaque fonctionnalité et on vérifie qu'elles sont bien traitées. Ici tout semble correct, bien qu'un doute subsiste pour la gestion des déplacements du robot...
232
+C'est aussi le moment de se demander si toutes les fonctionnalités sont couvertes. Pour cela on reprend chaque fonctionnalité et on vérifie qu'elles sont bien traitées. Ici tout semble correct, bien qu'un doute subsiste pour la gestion des déplacements du robot...
233 233
 
234 234
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
235 235
 \subsection{Formalisation}
@@ -328,7 +328,7 @@ Elle ne se veut pas exhaustive, mais simplement présenter les éléments néces
328 328
 
329 329
 Le diagramme d'activité est un diagramme comportemental d'UML, permettant de représenter le déclenchement d'événements en fonction des états du système et de modéliser des comportements parallélisables (multi-threads ou multi-processus).
330 330
 
331
-Les diagrammes d'activités permettent de spécifier des traitements a priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java. Il serait utilisé ici dans ce but.
331
+Les diagrammes d'activité permettent de spécifier des traitements à priori séquentiels et offrent une vision très proche de celle des langages de programmation impératifs comme C++ ou Java. Il serait utilisé ici dans ce but.
332 332
 
333 333
 \subsection{N{\oe}uds d'activité}
334 334
 
@@ -442,7 +442,7 @@ Chaque composant appartient à une {\bf catégorie}. Ces catégories sont préd
442 442
 
443 443
 Chaque composant comprend deux parties. La première, \textbf{le type}, correspond à son interface fonctionnelle, c'est-à-dire ce qui est visible pour les autres composants. La seconde, \textbf{l'implémentation}, décrit son contenu : sous-composants, propriétés, connexions, etc.
444 444
 
445
-Chaque implémentation est associée à un type. ¿ chaque type est associé aucune, une ou plusieurs implémentations. La figure~\ref{fig:type_implementation} donne un exemple de deux types de composants dont le premier est associé à deux implémentations de composants (component implementations).  Textuellement, le type est introduit par le mot décrivant le type du composant, alors que l'implémentation est décrite par le type suivi du mot {\em implementation}.
445
+Chaque implémentation est associée à un type. À chaque type est associé aucune, une ou plusieurs implémentations. La figure~\ref{fig:type_implementation} donne un exemple de deux types de composants dont le premier est associé à deux implémentations de composants (component implementations).  Textuellement, le type est introduit par le mot décrivant le type du composant, alors que l'implémentation est décrite par le type suivi du mot {\em implementation}.
446 446
 
447 447
 
448 448
 \begin{figure}[htbp]

Loading…
Cancel
Save