jeudi 10 avril 2008

En conception

Une image bien faite , vaut mieux qu'un long discours

--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

lundi 31 mars 2008

Ce document a pour objectif de décrire l’architecture technique de la solution proposée dans le cadre du projet de professionnalisation « Plate forme .Net ». Il s’agit d’une solution de gestion de la planification basé sur le modèle de fonctionnement d’une EFPP
1.1.1. Objectif d’une conception d’application distribuée

Lorsqu’on conçoit une application distribuée, il faudra faire des choix particuliers concernant son architecture logique et physique ainsi que les technologies et infrastructures utilisées pour implémenter ses fonctionnalités. Afin de prendre ces décisions de façon effective, il faut avoir une compréhension claire des processus métiers que l’application réalisera (ses spécifications fonctionnelles), ainsi que le niveau d’échelonnabilité, de disponibilité, la sécurisation, la maintenabilité exigée (les spécifications non fonctionnelles et les spécifications opérationnelles).
Notre objectif au travers ce document est donc :
Concevoir une application qui solutionne la problématique métier adressée : la gestion de la planification au sein des EFPP
Prendre en compte les considérations de sécurité nécessaires pour implémenter les mécanismes adéquats d’authentification, la logique d’autorisation ainsi que la communication sécurisée.
D’effectuer la conception nécessaire pour l’obtention d’un haut niveau de performance ainsi qu’un modèle de développement et de déploiement optimisé
Concevoir une architecture de solution échelonnable de façon à ce que la solution puisse supporter un grand nombre d’activités et d’utiliser avec un usage minimaliste des ressources.
Concevoir une architecture d’une solution concevable, gérable et mesure de façon à pouvoir gérer les problèmes éventuels qui surviendraient lors de l’utilisation de l’application
Concevoir une architecture de solution maintenable dans laquelle chaque unité fonctionnelle ait un emplacement prédictible ainsi qu’une conception qui prend en compte divers types d’applications, et des spécifications métier et techniques changeantes



1.1.2. Services et intégration de service

L’approche service s’est rapidement impose par le fait qu’elle propose au processus métier de s’affranchir aisément des frontières physiques des entreprises dans lesquelles ils sont consommés.
Du point de vue du consommateur du service, ce dernier est semblable à un composant traditionnel, excepté le fait qu’ils encapsulent leurs propres données et que d’un point de vue stricte ils ne font pas partie de notre application.
Du fait que les applications et les services qui les consomment sont généralement définis, développés, maintenus et mis à jours de façon indépendante les uns des autres, il est donc important que le couplage entre les deux soit aussi faible que possible.

Il est recommandé d’implémenter la communication entre services en utilisant la technique basée sur les messages afin d’assurer un haut niveau de robustesse et d’échelonabilité. Vous pouvez mettre en place une communication par message de façon très explicite (par exemple en écrivant du code pour MSMQ), ou vous pouvez utiliser des composants d’infrastructure qui gèrent la communication implicitement pour vous (par exemple les proxys générés par Visual Studio .Net).
Le principe d’utilisation d’un service est le suivant : un service expose une interface qui définit le contrat d’utilisation des méthodes que le service met à votre disposition, c’est – à – dire que chaque méthode du service définit son mode d’appel, ses paramètres ainsi que sa valeur de retour : on parle de signature de la méthode.

1.1.3. Composants et tiers dans les applications et services

Les composants sont utilisés pour décomposer chaque couche en éléments cohérents et logiques. On admet généralement un empilement des couches dans le sens Présentation à Données en passant par la couche des services.

Le schémas présenté sur la page suivante illustre l’architecture multitiere adoptée pour cette solution.

Diagrammes de conception

1. Les diagrammes de conception
Pour améliorer encore notre diagramme de classes et le préparer à la production du code, nous cesserons de considérer le système comme une boîte fermée et décrirons plus précisément les interactions survenant entre les différentes classes identifiées précédemment - soit les dialogues, les contrôles et les entités.
Nous isolerons un cas d'utilisation particulier pour illustrer certains aspects complexes de l'application. Prenons le cas d'un utilisateur qui effectue une recherche intermédiaire par auteur. Un premier diagramme de séquences illustre ce cas d'utilisation :








Nous ajoutons maintenant au diagramme de séquences les instances de classe d'objet intervenant dans le système. Continuons à identifier les messages pour l'obtention de la fiche détaillée d'un document choisi dans la page de résultats.

Ce diagramme nous permet maintenant d'identifier quelques nouveaux messages. Ceux-ci nous permettront d'attribuer aux bonnes classes les bonnes opérations.
Typer les attributs
Retournons à notre diagramme de classes et ajoutons des types aux attributs, ainsi qu'aux paramètres et aux retours des opérations.
En considérant pour illustration le langage ActionScript 2.0, le typage s'effectue ainsi :
// pour un attribut
propriété:Type
// pour une opération, avec un argument et un renvoi
operation(parametre:Type):TypeRenvoi
Lorsqu'aucun renvoi n'existe pour une opération, on indiquera le type Void. Ce sera généralement le cas.
Préciser la visibilité
Un concept fondamental de l'orienté objet est l'encapsulation - le fait de garder des informations cachées à l'intérieur de l'objet.
On pourra aussi indiquer à cette étape quels attributs ou méthodes sont privées ou publiques en faisant précéder l'attribut ou la méthode du signe + (pour public) ou - (pour privé).
Règle générale, tous les attributs devraient être privés, à moins d'avoir une excellente raison - ce qui est rarement le cas. On privilégiera plutôt l'utilisation des accesseurs (getter / setter) servant à fournir ou à modifier les valeurs d'attributs.



Diagramme de classe de conception
1.1.1. Conception objet et passage au code - diagrammes d’interaction et classe
Création de diagrammes d’interactionCréation de diagrammes de classe
Dernière étape avant l’écriture du code. On affine et on applique les trois derniers diagrammes au langage utilisé ainsi que la notation des attributs et des opérations.
En utilisant le langage orienté objet PHP par exemple, certaines pages deviennent à la fois dialogues et contrôles comme par exemple la page panier.php qui accède directement à l’entité panier
1.1.1. Modélisation préliminaire objet interaction du système technique ULM : diagrammes d’interaction (séquence et ou collaboration) et diagrammes de classes

Création de diagrammes d’interaction (séquence ou collaboration) Création de diagrammes de classe
Dans les diagrammes de séquences système on confrontait l’acteur au système dans sa globalité. Dans cette étape on va détailler le système décrit par nos classes participantes et compléter le diagramme de séquence système. Chaque classe devient un objet du système symbolisé comme pour les diagrammes de classes participantes.On détaille les séquences du Scénario au sein du système, d’objet à objet.Un objet pourra s’envoyer un message à lui-même comme le cas pour la vérification de syntaxe effectué par l’objet recherche avancé.Un objet pourra crée un autre objet comme le cas pour le catalogue qui crée un objet résultat.

Le diagramme de collaboration est la même description écrite d’une manière différente. Chaque séquence est annotée avec son chiffre d’apparition dans le Scénario puisque ce diagramme n’exprime pas le temps.
A cette étape on crée des diagrammes de classes de conception préliminaires ou l’on rajoute en fonction des précédents diagrammes de séquences essentiellement des attributs ou des opérations. Par exemple verifierSyntaxeRecherche (phrase) à la classe dialogue RechercheAvancée.
De plus on peut déjà ajouter le type de chaque attribut de classe par exemple : chercherLivre : string
1.1.1. Modélisation de la navigation - technique UML : diagrammes d’activités
Création de diagrammes d’activités
En fonction de l’interface (maquette) et des diagrammes de classes participantes (et d’autres) on modélise un diagramme d’activité. Un diagramme d’activité est un diagramme dynamique qui a un début, une ou des fins et une ou des fins anormales. Chaque activité est reliée à une autre ou a une condition (symbolisé par un losange). Pour le WEB on va ajouter des conventions :La page :la frame a l’intérieur d’une page L’exception : erreur ou comportement inattendu du système

Pour la réalisation de ce diagramme on commence par l’acteur (ex l’internaute) qui arrive sur une page donnée (ex : Page d’accueil). Ensuite on détaille le parcourt de page en page :
De la page d’accueil l’internaute choisi le frame recherche rapide (présente sur la page d’accueil) ou va vers la page de recherche avancée. L’une ou l’autre recherche est une action « recherche » qui va (condition), soit se concrétiser par un résultat écrit sur un frame, soit échouer (pas de livre correspondant) et va proposer un retour à la page d’accueil. Il faudra penser à réaliser ce type de schémas sur un tableau.
On peut donner résumer ensuite un modèle global pour un ensemble de cas d’utilisations sans donner compte des fins anormales ou des conditions.
1.1.1. Classes participantes - technique UML pour les diagrammes de classe
Création de diagrammes de classe participante
Dans cette partie le but est de trouver les classes de l’interface IHM = maquette ( les classe les dialogues ) et celles qui décrivent la cinématique de l’application ( les classes contrôles ) et de les associer à nos classes métier trouvées auparavant. Par exemple pour le développement d’un site Web, les classes dialogues font la liaison entre l’utilisateur et le site WEB : elles vont recevoir en plus des attributs (qui représentent les champs de saisie) des opérations (qui représentent les actions d’utilisateur).
Les classes contrôles font la transition entre les dialogues et les classes métiers : Elles n’auront pas d’attributs, mais seulement des opérations qui montre les comportements du système informatique.
Les classes métier garderont seulement leurs attributs.
A noter que les associations sont unidirectionnelles.
Par exemple pour la recherche d’ouvrage. On va ajouter les classes dialogues ; écran de recherche rapide et recherche avancée et résultat de recherche. Leur associer une classe contrôle (contrôle recherche) pour les lier a nos classes métier (catalogue)