Instructions: Entité métier
Les entités métier représentent des "éléments" traités et utilisés par les travailleurs métier lorsqu'ils exécutent un cas d'utilisation métier. Ces instructions sont une description de la modélisation des entités métier.
Relations
Description principale

Explication

Les entités métier représentent des "éléments" traités et utilisés par les travailleurs métier lorsqu'ils exécutent un cas d'utilisation métier. Une entité métier représente souvent quelque chose ayant une valeur pour plusieurs cas d'utilisation métier ou instances de cas d'utilisation ; l'objet entité métier a donc une durée de vie plutôt longue. En général, il est bien que l'entité métier ne contienne aucune information concernant son utilisation et son utilisateur.

Une entité métier représente généralement un document ou une partie essentielle d'un produit. Il s'agit parfois de quelque chose de moins perceptible comme l'importance de connaître un marché ou un client. Dans un restaurant par exemple, le menu et les boissons sont des entités métier ; dans un aéroport, les billets et les cartes d'embarquement sont d'importantes entités métier.

En modélisation métier, on considère généralement les entités métier comme des éléments d'information significatifs (et persistants) ; c'est en effet comme cela que nous les décrivons dans la description d'artefact. Cependant, les "éléments" traités ou utilisés par les travailleurs métier sont généralement des objets physiques : si un travailleur métier est réalisé par un système physique complexe ayant des flux matériels au delà de ses frontières, il peut s'avérer utile que les entités métier représentent les informations analogues pour ces éléments physiques - elles représentent la manière dont le travailleur métier communique ses actions au reste de l'entreprise. Vous pouvez alors traiter les considérations physiques du travailleur métier en dehors du contexte de modélisation métier : vous traitez alors le travailleur métier comme un système à part entière.

Vous devez seulement modéliser en tant qu'entités métier les phénomènes auxquels d'autres classes dans le modèle de domaine métier doivent faire référence. D'autres "éléments" peuvent être modélisés en tant qu'attributs des classes pertinentes ou simplement décrits textuellement dans ces classes.

Attributs

Un attribut d'une classe est un élément d'information concernant un objet de cette classe et conservé avec cet objet. Un attribut comporte un type d'attribut. Chaque attribut et type d'attribut ont, respectivement, un nom.

Un objet dispose normalement de plusieurs éléments d'information qui décrivent certaines de ses caractéristiques. Ces éléments d'information peuvent être décrits implicitement dans la description textuelle de la classe d'objet ou modélisés explicitement en tant qu'attribut de la classe.

Un attribut fait partie d'un type d'attribut. Il a un nom, de préférence un nom qui décrit son rôle par rapport à la classe. Un type d'attribut peut être plus ou moins primitif, en partant d'un numéro simple ou d'une chaîne. Des classes différentes peuvent avoir des attributs ayant des structures identiques. Ces attributs devraient avoir la même description, c'est-à-dire qu'ils devraient avoir le même type d'attribut.

Note : Le but de la modélisation des attributs est de rendre une classe plus compréhensible !

Utilisation d'attributs ou d'entités

Il est parfois difficile de savoir s'il faut décrire un concept en tant qu'attribut d'une classe ou en tant qu'une classe d'entité métier séparée. La règle générale est la suivante : modéliser un phénomène en tant qu'attribut si un objet seulement doit y accéder directement ou si le seul moyen naturel d'y accéder se fait par le biais de l'objet. Sinon, il faut modéliser le concept séparément, dans une classe qui lui est propre.

Diagramme décrit dans le texte d'accompagnement.

Dans le cas d'utilisation de l'enregistrement dans un aéroport, les billets sont des éléments importants. Sur chaque billet, il y a le nom du passager et le vol. Ici, les attributs Nom et Vol sont identifiés. Le dernier est plus complexe car il comprend la compagnie aérienne, la destination, l'heure de départ et l'heure d'arrivée.

Diagramme décrit dans le texte d'accompagnement.

Tous les passagers voyageant sur le même vol ont ce vol en commun. La compagnie aérienne est la même pour plusieurs vols. Il vaut donc mieux modéliser le vol et la compagnie aérienne en tant que classes.

Une fois que vous avez décidé si un concept est suffisamment important pour le cas d'utilisation pour faire l'objet d'une modélisation, ce qui vous oriente vers une modélisation en tant que classe séparée ou simplement en tant qu'une classe d'attribut n'est pas l'importance de ce concept dans le monde réel. Ce qui dicte le type de modélisation, c'est le besoin que l'entreprise a d'y accéder. Cela veut dire que certains concepts sont modélisés différemment pour des entreprises différentes.

Considérez l'exemple suivant : Pour les employés participant au cas d'utilisation d'un planning du trafic aérien d'un aéroport, les vols sont des éléments vitaux. L'heure de départ, la compagnie aérienne et la destination doivent être définies pour chaque vol. Dans ce cas, vous devriez utiliser une classe et lui donner pour attributs l'heure de départ, la compagnie aérienne et la destination.

Diagramme décrit dans le texte d'accompagnement.

Les vols sont un élément essentiel pour les employés participant au cas d'utilisation métier d'un planning de trafic aérien d'un aéroport.

La situation est par contre différente pour les employés d'une agence de voyage. Bien qu'ils aient toujours besoin de l'heure de départ, de la compagnie aérienne et de la destination, ils ont besoin d'éléments supplémentaires. Le plus important pour les agences, c'est de trouver un vol avec une destination particulière, auquel cas il est approprié de créer une classe séparée pour la destination. Il faut bien sûr que les classes Vol et Destination aient conscience de l'existence de l'autre. Une association bidirectionnelle vous permet d'assurer cela.

Diagramme décrit dans le texte d'accompagnement.

L'heure de départ et la destination d'un vol sont de la même importance pour les employés participant au cas d'utilisation d'une agence de voyage.

Théoriquement, vous pouvez tout modéliser en tant que classe. Cependant, une utilisation appropriée d'attributs réduit le nombre de classes qu'il faut maintenir et rend le modèle d'objet plus facile à comprendre.

Opérations

Afin de remplir les responsabilités d'un travailleur métier, la personne agissant en tant que travailleur métier utilise un ou plusieurs outils pour manipuler les entités métier. Vous pouvez définir ces outils de manière générale ou explicite, en vous aidant des opérations et des messages représentant les outils utilisés et les accès créés. Une opération définit l'outil avec lequel une entité métier est manipulée. L'accès est initié par un message. Un outil que l'on peut utiliser pour manipuler un objet entité métier est représenté en tant qu'opération de la classe entité métier, avec un nom et, éventuellement, des paramètres. L'accès d'une unité entité métier est montré en tant que message envoyé à l'objet entité métier.

Par exemple, une opération "associer bagages" sur l'entité métier "billet" impliquerait d'attacher les étiquettes des bagages au billet. Les étiquettes des bagages représenteraient les paramètres.

Chaque opération porte un nom, qui devrait indiquer l'objectif de cette opération et, éventuellement, un certain nombre de paramètres. Les paramètres précisent ce qu'un objet de la classe doit recevoir d'un objet qui demande un support ou un accès, ainsi que ce que l'objet va fournir une fois l'opération exécutée. Par exemple, vous pouvez créer des paramètres qui déterminent le moment où un travailleur métier doit prendre des mesures dans l'opération de travailleur, ou le moment où ce travailleur métier doit accéder à une certaine entité métier en lançant l'une des opérations de cette entité. Les paramètres peuvent aussi représenter des choses plus ou moins tangibles qui sont transmises.

On peut définir les opérations de manière informelle ou de manière un peu plus détaillée selon l'importance ou le niveau de détail requis dans un cas d'utilisation. Une description "un peu plus détaillée" peut décrire une séquence de comportements qui indique quels attributs et quelles relations sont traités pendant son exécution, comment les objets des autres classes sont contactés et comment la séquence se termine.

Caractéristiques d'une bonne entité métier

  • Son nom et sa description sont clairs et compréhensibles.
  • Les relations entre entités métier ne dépendent pas les unes des autres.
  • Chaque relation est utilisée dans l'enchaînement d'activités d'au moins un cas d'utilisation métier.
  • Tous les "éléments" de l'entreprise tels que les produits, les documents, les contrats etc. sont modélisés en tant qu'entités métier.
  • Elle participe à au moins un cas d'utilisation métier.
  • Elle a un propriétaire, c'est-à-dire un travailleur métier ou un acteur métier responsable de l'entité métier.

Evénements métier

Les événements métier peuvent être utilisés afin de notifier les parties intéressées (y compris d'autres entités métier) d'un changement dans l'état de l'entité métier. La création et la destruction d'une entité métier peuvent être significatives. Si vous avez défini une machine d'état, examinez les états de l'entité métier. Chaque transition est un événement métier potentiel. Examinez aussi les attributs et les opérations de l'entité métier. Les opérations importantes qui sont utilisées peu fréquemment peuvent avoir un événement métier qui leur est associé. Les changements apportés aux attributs importants peuvent déclencher un événement. Les patterns de processus métier et les patterns d'entité métier peuvent aussi fournir un aperçu des événements métier utiles. Par exemple, si une entité métier doit être approuvée pour utilisation, un événement métier <quelque chose> Approuvé peut être utile pour notifier à d'autres parties que l'événement métier est prêt à être utilisé. Pour plus d'informations sur la recherche des événements métier, voir Instructions : Evénement métier.