Spécification d'une occurrence dans l'espace et dans le temps ; de manière moins formelle, occurrence de quelque chose à laquelle doit réagir le système.  L'objet de l'artefact Evénement est de répertorier les caractéristiques d'événements, telles que leur fréquence, priorité et exigences de réponse.
Autres relations :  Partie de Modèle de conception
Rôle :  Architecte logiciel 
Caractère facultatif/Occurrence:  L'identification et la caractérisation d'événements s'appliquent essentiellement aux systèmes réactifs (guidé par les événements), à ceux utilisant les accès concurrents et/ou des échanges de messages asynchrones.
Canevas et rapports : 
     
Exemples : 
     
Représentation UML : 

Dans le contexte des diagrammes d'état et d'activité, un événement se réfère à un déclencheur de transition d'état.

Cependant, cet artefact recouvre les "événements" dans leur sens plus général, c'est-à-dire des occurrences auxquelles le système doit répondre, y compris des signaux, appels, changements d'état ou événements temporels.

Voir également Artefact : Signal.

Informations supplémentaires :   
Entrée d'activités :    Sortie d'activités :   

Objet Haut de la page

Un événement permet d'identifier et de recenser des information sur des occurrences externes dont le système est conscient et auxquelles il doit répondre. Ils peuvent aussi servir à capturer des informations sur des événements internes, comme des exceptions.

Bref aperçu Haut de la page

Caractéristiques importantes des événements :

  • interne ou externe - L'événement est-il interne ou externe ?
  • priorité - Cet événement doit-il provoquer la suspension d'autres traitements pour être géré ?
  • fréquence - A quelle fréquence cet événement se produit-il ?
  • répartition de la fréquence - L'événement se produit-il à des intervalles réguliers ou connaît-il des pointes ?
  • exigences de réponse - A quelle vitesse le système doit-il répondre à l'événement (il peut être nécessaire de distinguer entre situation extrême et moyenne).
  • type - S'agit-il d'un appel, d'un événement temporel, d'un signal ou d'une modification (voir Concepts : Evénements et signaux pour leurs definitions) ?

Calendrier Haut de la page

Certains événements, notamment ceux représentant les événements externes et les événements internes significatifs auxquels doit répondre le système, sont identifiés au début de la phase d'élaboration. Ceux requis pour une communication asynchrone avec le système le sont vers la fin de la phase d'élaboration. Tous les événements significatifs sur le plan de l'architecture doivent avoir été totalement identifiés à la fin de la phase d'élaboration.

Responsabilité Haut de la page

L'architecte logiciel est responsable de tous les événements et doit veiller à leur usage approprié.

Personnalisation Haut de la page

Les caractéristiques des événements peuvent être capturées dans une feuille de tableur, une base de données, une base de données de gestion des exigences ou en tant que tableau dans le document d'architecture logicielle.

Elles peuvent même être capturées en tant que classes, stéréotypées en tant qu'<<événement>>, bien que ceci ne représente qu'une méthode pratique pour répertorier des informations de gestion sur les événements, à ne pas confondre avec les données transmises lorsque l'événement se produit. Si un événement de type appel se traduit par une transmission de données, celles-ci doivent être représentées par la signature de l'opération appelée. S'il s'agit d'un signal, ses données peuvent être modélisées explicitement (voir Artefact : Signal).



RUP (Rational Unified Process)   2003.06.15