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.
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 !
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.
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.
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.
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.
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.
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.
-
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.
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.
|