Articles

Affichage des articles du 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
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 q

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 nouveau
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 classe s 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 classe s 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.
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 classe s 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 (conditio
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 classe s de l’interface IHM = maquette ( les classe les dialogues ) et celles qui décrivent la cinématique de l’application ( les classe s contrôles ) et de les associer à nos classe s métier trouvées auparavant. Par exemple pour le développement d’un site Web, les classe s 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 classe s contrôles font la transition entre les dialogues et les classe s métiers : Elles n’auront pas d’attributs, mais seulement des opérations qui montre les comportements du système informatique. Les classe s métier garderont seulement leurs attributs. A noter que les associations sont unidirectionnelles. Par exemple

Nouveautés UML 2.0

1.1. Nouveautés introduites par UML 2.0 Cette section présente les nouveautés UML2.0 en ce qui concerne le diagramme de classes et le diagramme d'architecture. Le diagramme d'architecture,aussi appelé diagramme structure composite, est un tout nouveau diagramme introduit par le standard UML2.0. Cette section regroupe les deux diagrammes car certains concepts peuvent être utilisés dans les deux diagrammes. Les notions abordées dans cet article sur les nouveautés UML2.0 sont principalement les ports, les interfaces, les connecteurs, les parts. Avant de présenter les nouveaux concepts de ces deux diagrammes (classe, architecture), voyons quelques rappels. 1.1.1. Diagramme de classes Un diagramme de classes donne une vue statique du système/logiciel. Il décrit les types et les objets du système/logiciel. Typiquement il met en relation des classes mais aussi des interfaces, des types de données, des types énumérés... Une classe Une classe représente une entit

Autres éléments

1.1.1. Composition La composition, également appelée agrégation composite, décrit une contenance structurelle entre instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une instance de la partie appartient toujours à au plus une instance de l’élément composite. Graphiquement, on ajoute un losange plein (_) du côté de l’agrégat. Dépendance Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible implique une modification de la source. La dépendance est souvent stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle Interfaces Les classes permettent de définir en même temps un objet et son interface. Le classeur, que nous décrivons dans cette section, ne permet de définir que des éléments d’interface. Il peut s’agir de l’interface complète d’un objet,
Image
1.1. Diagramme de classe d’analyse 1.1.1. Diagrammes de classe Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation. Alors que le diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation. Il est important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs cas d’utilisation. Les cas d’utilisation ne réalisent donc pas une partition1 des classes du diagramme de classes. Un diagramme de classes n’est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d’un cas d’utilisation particulier. Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramm
Image
1.1. Diagrammes de séquence et messages Cette section présente les nouveautés UML2.0 en ce qui concerne le diagramme de séquence (appelé sequence diagram ou interaction diagram en anglais) Les diagrammes de séquence sont comme on peut s’en rendre compte couramment utilisés par nombre d'acteurs d'un projet, même quelque fois à leur insu, sans savoir qu'ils utilisent là un des diagrammes UML. En effet, le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette représentation intuitive est également un excellent vecteur de communication dans une équipe d'ingénierie pour discuter cette solution.Les diagrammes de séquence peuvent également servir à la problématique de test. Les traces d'exécution d'un test peuvent en effet être représentées sous

Un exemple complet

Image
1.1. Exemple complet Cette section présente un exemple complet d’un diagramme de séquence Un message réflexif ne représente pas l'envoi d'un message, il représente une activité interne à l'objet (qui peut être détaillée dans un diagramme d'activités ) ou une abstraction d'une autre interaction (qu'on peut détailler dans un autre diagramme de séquence).
Image
1. Présentation des différents diagrammes d’analyse 1.1. Introduction aux diagrammes de séquence Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Contrairement au diagramme de collaboration , on n'y décrit pas le contexte ou l' état des objets, la représentation se concentre sur l'expression des interactions. Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation . L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe. La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la sémantique du diagramme. Les diagrammes de séquences et les diagrammes d'état-transitions sont les vues dynamiques les plus importantes d'UML 1.1. Types de messages Comme vous pouvez le voir dan

L'analyse par rapport à l'ensemble de la démarche

1 . Situer la phase d’analyse dans l’ensemble de la démarche La phase d’analyse intervient en amont de la préparation du cahier de charge fonctionnel, l’objectif de ce dernier étant de relater les besoins exactes des utilisateurs. Pour ce faire des entretiens sont menés et un groupe de travail est constitué. Le cahier de charge fonctionnel devient alors la conclusion des travaux d’analyse de la valeur et d’analyse fonctionnelle qui symbolisent la démarche d’expression du besoin. La démarche adoptée fait généralement l’objet des points suivants. Orienter l'étude Rechercher l'informationLa recherche de l'information doit être canalisée et formalisée. C'est un processus constant tout au long du projet qui doit être mené rigoureusement dès le début du projet afin d'appréhender plus précisément les caractéristiques essentielles du besoin. Un excellent moyen de chercher l'information la plus pertinente et de la vérifier en même temps est de constituer