Passionné de nouvelles technologies...
l'analyse, la modélisation du monde réel et
la mise en place de nouvelles architectures logicielles
représentent mes principales activités...
L'émergence et la popularité grandissante des technologies objet (méthodes, architectures et langages) influence fortement
l'agencement des systèmes informatisés,
la gestion et l'organisation de notre production logicielle.
La mise en place d'un nouveau système doit être progressive, faisant migrer les systèmes actuels
vers de nouvelles architectures (CORBA, ActiveX COM/DCOM, JavaBeans RMI) et
en utilisant de nouvelles méthodes (UML), procédures et démarches.
Dans la nature, les systèmes complexes qui fonctionnent sont toujours des évolutions de systèmes plus simples.
Les architectures et
la gestion de la production de ces nouveaux systèmes
doivent mettre en avant le respect des
concepts immanents objet afin de garantir l'obtention des
facteurs qualité exigés.
Les exigences qualité des nouveaux systèmes se formalisent chaque jour d'avantage définissant
des principes d'obtention de la qualité et mettant en place des outils de plus en plus rigoureux sur la mesure de la qualité de notre production (Normes qualité ISO 9000).
 |
Les organisations autrefois hiérarchisées se transforment de plus en plus en un réseau coopératif :
- Les responsabilités, les services, les moyens se répartissent, se distribuent et se délèguent.
- Les gros systèmes se désagrègent en moyen, mini et micro systèmes.
- Les canaux de communication se multiplient.
- Les protocoles de communication se standardisent.
- Les systèmes, les architectures et les organisations deviennent fluides : modulaires ; transformables ; évolutifs ...
|
|
Le paradigme objet
Identification des objets
DÉLÉGATION COMPOSITION CLASSIFICATION MODÉLISATION
|
Cycle de développement unitaire et itératif des systèmes objet
[V0 ...], [V1 ANALYSE CONCEPTION CODAGE TEST RECETTE], [V2]
|
Architecture à objets distribués
CLIENT <> MESSAGE <> SERVEUR
AGENT <> Évènement <> SYSTÈME
|
Concept objet immanent
Intégrité MODULARITÉ GéNéRICITé
Extensibilité OPTIMISE Réutilisable
NORMALISÉ
|
Propriétés ACIDe des objets
Atomique Cohérent Intègre Durable
|
Granularité des services d'objets distribuables
Unité d'Acteur Unité de Temps Unité de Lieu
|
Facteurs de qualité des systèmes objet
Lisibilité Vérifiabilité Validité Confidentialité Rapidité Fiabilité Robustesse Ergonomie Facilité Efficacité Compatibilité
|
Les facteurs qualités
Les facteurs qualités (Lisibilité, Vérifiabilité, Validité, Confidentialité, Rapidité, Fiabilité, Robustesse, Ergonomie, Facilité, Efficacité, Compatibilité) passent par la simplification des Méthodes, Processus et Démarches. Plus un système se veut complexe plus ses principes de base doivent être simples.
Les systèmes objet
système ::= objet + messages émis et/ou réceptionnés par l'objet
objet ::= objet + [objet]
message ::= objet transitant entre au moins deux objets
L'agrégation des objets se fait par affinité.
L'affinité entre objets représente la faculté - de réceptionner les objets émis par d'autres objets - de phagocyter d'autres objets.
Les zones de faible affinité délimitent naturellement les sous-systèmes objet.
La dynamique d'un système objet peut être décrit par une succession d'émission et de réception de
messages par des objets. (Voir Cas d'utilisation et
Scénarios, Diagrammes de collaboration ou Diagrammes de séquence de la modélisation objet avec
UML).
La décomposition fonctionnelle d'un système d'information (SI)
Le SI est présenté sur plusieurs niveau d'abstraction, d'une vision globale vers une vision plus détaillée.
Un premier niveau très globale présente le SI comme une boîte noire abstraite rendant un ensemble de services par interaction avec des acteurs externes au travers de messages ou flux d'informations entrants ou sortants. Chaque interaction entre un acteur et un système ou événement est matérialisé par un message. Ce niveau d'abstraction qui présente le SI dans le contexte le plus global ou vue externe est appelé Diagramme de contexte de niveau 0.
Chaque événement matérialisé par un message ou demande de service est pris en charge par un processus de traitement. Ces processus sont décomposés jusqu'à un niveau ACIDe ou non décomposable sans risquer de compromettre l'intégrité du SI. Les processus de plus bas niveau sont appelé Tâche (unité d'Acteur, unité de Lieu, unité de Temps : hALTe).
La décomposition des processus en sous-processus jusqu'aux tâches représente le métier.
La distribution et la répartition des tâches repose sur un modèle d'organisation. Ce modèle d'organisation permet de déterminer l'unité de lieu, l'unité d'Acteur et l'unité de temps de chaque tâche. Ce modèle d'organisation assemble les unités de lieu, de temps et d'acteur en cellule organisationnelle de plus haut niveau jusqu'à regrouper l'ensemble du métier.
Il est important de découpler le métier de l'organisation afin d'augmenter la maintenabilité, l'évolutivité et l'extensibilité du SI.
Métier et organisation ont des préoccupations distinctes mais ils sont interdépendants. Les acteurs de l'organisation opérationnelle déclenchent des services disponibles sur les différents objets métier du SI.
- L'affinage du métier consiste à minimiser et optimiser les tâches.
- L'affinage de l'organisation consiste à synchroniser les flux d'informations entre les tâches (diminution du temps, des lieux et des acteurs).
Cette segmentation de l'espace des besoins selon le point de vue des différents acteurs est purement fonctionnelle et il convient de prendre garde à ne pas embrayer vers une décomposition fonctionnelle plutôt que vers une décomposition objet.
UML réalise les cas d'utilisation au moyen de collaborations entre objets issus du Domaine d'application.
(Voir Modélisation objet avec UML de Pierre-Alain MULLER aux éditions Eyrolles ISBN 2-212-08966-W)
Une modélisation objet du SI décrit des services métiers d'objets métier.
La décomposition fonctionnelle ou objet offre une vision globale et une vision détaillée. Cette décomposition permet une réutilisation maximale de chaque composant, une approche ascendante et descendante, une abstraction de la complexité...
Les scénarios
Pour chaque service rendu par un objet on décrit un ensemble de scénarios.
Un scénario représente une succession ordonnée de messages délégués aux différents objets référencés par les attributs internes de l'objet.
La portée d'un scénario est la même que la portée d'un objet. C'est à dire que ne sont décrits dans un scénario que des services d'adressant au service interne de l'objet et à ces objets référencés par les propriétés de l'objet. Un scénario fait abstraction de l'architecture interne de ses objets référencés.
On décrit ces scénarios au travers d'un langage de spécification des objets
Un scénario est donc un paragraphe formé d'une succession cohérente de phrases.
Par combinaison de scénarios il est possible de descendre dans le détail de chaque phrase. On peut ainsi choisir le niveau de détail nécessaire à la compréhension d'un scénario. On peut avoir une vision globale ou détaillée des mécanismes d'un objet.
Chaque objet est responsable de la synchronisation de la prise en compte des demandes de services qui lui sont adressées. L'objet serveur ignore les caractéristiques de l'objet client pour rendre service. Il y a découplage entre le client et le serveur.
C'est au travers de scénarios concrets que sont identifiés les objets.
Les messages
Un message est la représentation d'une Demande de service d'un objet à un autre objet.
Un message est représenté par une phrase : un objet, un verbe et aucun, un ou plusieurs compléments ordonnés.
Où :
- l'objet identifie le destinataire du message,
- le verbe identifie un des services de l'objet destinataire,
- le ou les compléments identifient des paramètres nécessaires à l'obtention du service. Ces paramètres peuvent être des valeurs basiques typées ou des objets complexes. La condition d'acceptation d'une demande de service ou message passe par la vérification de la compatibilité des valeurs de paramètre. Cette pré compilation valide la crédibilité du message.
Un message peut concerner une population d'objets. Dans ce cas, l'objet destinataire est l'objet population d'objets qui recense tous les objets appartenant à cette population. L'objet population à pour responsabilité de propager le message vers l'ensemble ses objets.
Un message est dit synchrone si le processus à l'origine de l'envoi du message se met en attente d'un message en réponse pour continuer à s'exécuter.
Un message est dit asynchrone si le processus continue à s'exécuter après l'envoi du message.
Les propriétés d'un message sont les suivantes :
- l'identifiant de l'objet à l'origine de l'émission du message,
- l'identifiant du processus de l'objet à l'origine de l'émission du message,
- la date GMT d'émission,
- la date d'obsolescence ou de relance du message,
- l'identifiant de l'objet destinataire (objet),
- l'identifiant du processus destinataire (verbe),
- l'identifiants des objets paramètres (compléments),
- la nature synchrone ou asynchrone du message.
L'identification des objets
Chaque objet identifié lors de la décomposition du système doit avoir une identité unique.
Cette identité prend en compte la traçabilité des évolutions de l'objet et son état d'exploitabilité.
L'identité d'un objet est constitués des éléments suivants :
- un identifiant unique d'objet (immatriculation),
- un numéro d'archivage (numéro de révision),
- une indication du prononcé de recette (état d'exploitabilité).
Le numéro d'archivage précise
- si la nouvelle évolution n'est qu'une correction d'anomalies ou une amélioration de la qualité de l'objet ne modifiant pas l'interface et le comportement de l'objet,
- si la nouvelle évolution concerne qu'une augmentation de l'interface de l'objet, ne modifiant pas l'interface et le comportement de l'objet (Les deux d'objets sont compatibles.),
- si la nouvelle évolution remet en cause l'interface ou le comportement des services de l'objet.
Chaque objet doit être référencé dans au moins un annuaire d'une
bibliothèque d'objets.
Chaque objet fait référence à un identifiant de l'objet à l'origine de sa création (modèle, classe ou type).
Les services de l'objet doivent être identifiées avant sa création. Par comparaison des services des objets, il est possible déterminer s'il s'agit d'un nouvel objet, d'une évolution ou une réutilisation d'un objet existant.
L'architecture de services et Gestion de production logicielle
Ma vision de la gestion de production
logicielle et des architectures de services
est conforme au paradigme objet.
Les technologies objet
Les technologies objet apparaissent progressivement dans l'industrie du logiciel :
CV : LUCK Paul-Alexandre
EMail : paulalexandre.luck@free.fr
