|
De la Modélisation Métier vers des Systèmes Informatisés |
|
Telles que proposées par le Processus Unifié de Rational®, il existe des relations entre les disciplines de modélisation métier et de gestion des exigences logicielles, et ceci se confirme dès l'emploi de la technique des cas d'utilisation.
La figure ci-dessous visualise les relations entre les représentations UML de concepts employés d'une part dans le cadre de la modélisation métier et d'autre part lors de la gestion des exigences ainsi que l'analyse de ces dernières.
Les Acteurs Métier (Business Actors) représentent les intervenants qui utilisent les services d'une société ou qui sont identifiés comme nécessaires au bon fonctionnement de ces services et ce, soit en tant que sous-traitants, contrôleurs ou coordinateurs. Ainsi, la première règle suivante peut être énoncée:Les Business Workers sont des candidats d'acteurs de systèmes informatiques.
Un Business Worker est une classification d'un certain type de collaborateur au sein d'une société d'un système informatique dont certains aspects de leurs responsabilités sont sujets à l'automatisation. Pour cette raison, il prévaut que: Les Business Workers sont des candidats d'acteurs de système informatisés.
Lorsqu'un Business Worker représente une système automatisé alors il est recommandé de le qualifier d'Automated Business Worker. Avec les opérations, ou plutôt les fonctions, d'un Business Worker, l'on visualise les responsabilités de Business Worker. Dans le cadre d'une initiative d'automatisation informatique, les Automated Business Workers se voient assigner l'ensemble ou une partie des responsabilités de Human Business Workers. Ainsi, la seconde règle suivante peut être énoncée: Les responsabilités des Automated Business Workers sont des cas d'utilisation candidats de systèmes informatiques.
Les Cas d'Utilisation Métiers (Business Use Cases) expriment les services qu’une organisation propose au doit proposer à ses clients ou à tout autre partie ayant une relations ave l'organisation. Lorsque ces services sont totalement au partiellement, par exemple dans le cadre d'Internet, alors la troisième règle suivante peut être énoncée: Les Cas d'Utilisation Métier sont des candidats pour des Cas d'Utilisation de systèmes informatiques.
Les Règles Métier (Business Rules) permettent au niveau opérationnel de modéliser des décisions relatives à la gouvernance d'une organisation ou des contraintes relatives à la législation à laquelle doit satisfaire cette même organisation. Pensez donc aux lois qui concernent la protection des données privées, la gestion des risques, les règles d'acceptation, les règles de calcul,… Vu que ce qui est d'application à des procédures manuelles s'applique aussi aux procédures automatisées, une quatrième règle peut être énoncée:Les Cas d'Utilisation sont des contextes pour l'application de Règles Métiers (Business Rules).
L'information se représente lors de la modélisation métier au travers d'Entités Métier (Business Entities). Certaines de ces Entités Métiers disposent d'un cycle de vie. Par exemple, combien de temps une offre ou un contrat doivent être gardé ou à quel moment peuvent-ils être supprimés? Une cinquième règle: Les Machines d'Etats (State Machines) offrent une approche pour visualiser le cycle de vie d'Entités Métier (Business Entities)..
Vu que le cycle de vie d'une Entité Métier (Business Entity) est est en fait régit par un ensemble de Règles Métier (Busines Rules), une sixième règle est à retenir: Les Machines d'Etats (State Machines) au niveau de la modélisation métier et de la modélisation de systèmes informatiques doivent être associés aux Règles Métier (Business Rules).
Un bon système informatique est reconnaissable par le fait que le jargon métier se retrouve au niveau de la programmation. Voici une septième règle: Les Entités Métier (Business Entities) sont des candidats pour des Classes d’Analyse (Analysis Classes) de systèmes informatiques.
Les Règles Métier (Business Rules) imposent toujours des contraintes. Même une formule à employer lors d’un calcul particulier est une contrainte. En fait, la formule impose une contrainte aux résultats possibles ou autorisés. Les contraintes peuvent être visualisées et implémentées au travers d’associations entre classes et de cardinalités. Finalement, voici la huitième et dernière règle à retenir : Les Règles Métiers (Business Rules) sont des candidats pour des associations entre classe et des cardinalités.
Si vous désirez apprendre davantage sur la relation entre la modélisation métier et d’autres disciplines du développement logiciel, consultez la description de notre formation sur la Modélisation Métier avec le Processus Unifié. |
