Plan du cours

L’analyse système

La conception

L’architecture logicielle

L’analyse système

Reformulation des besoins

Modélisation objet

L’analyse système

Reformulation des besoins

Reformulation des besoins

La reformulation des besoins consiste à itérer sur sept activités principales : Production d’un glossaire système Identification des acteurs et des cas

d'utilisation Analyse d’un cas d'utilisation Structuration du modèle des cas d'utilisation Description des besoins non fonctionnels Maquettage de l’interface utilisateur Vérification du modèle des besoins

Production d’un glossaire système Cette activité consiste à déterminer le vocabulaire

système pour les termes spécifiques ou sujets à une mauvaise interprétation.

Chaque entrée du glossaire comporte un nom de terme, sa définition (un texte) et un type.

Le type est le nom du concept sous lequel est classifié le terme si c’est le cas. Cette rubrique est donc optionnelle.

Identification des acteurs et des cas d'utilisation

ActionAction ObjectifObjectif

Identifier les acteurs

Identifier les acteurs en interaction avec le système. Ces Identifier les acteurs en interaction avec le système. Ces acteurs peuvent représenter des systèmes fournisseurs de acteurs peuvent représenter des systèmes fournisseurs de services, ou des systèmes utilisateurs de servicesservices, ou des systèmes utilisateurs de services

Définir le contexte du système

Représenter le système dans son environnement (interactions Représenter le système dans son environnement (interactions avec les acteurs selon des points de vue statique, dynamique avec les acteurs selon des points de vue statique, dynamique et fonctionnel), afin de définir sans ambiguïté les frontières du et fonctionnel), afin de définir sans ambiguïté les frontières du systèmesystème

Identifier les cas d'utilisation du Système

Identifier les fonctionnalités confiées au système, sous forme Identifier les fonctionnalités confiées au système, sous forme de cas d'utilisation. Ces fonctionnalités peuvent utiliser des de cas d'utilisation. Ces fonctionnalités peuvent utiliser des services existants ou prévus. Elles peuvent aussi représenter services existants ou prévus. Elles peuvent aussi représenter ce que le système doit offrir ultérieurement, sous forme d'un ce que le système doit offrir ultérieurement, sous forme d'un ou de plusieurs servicesou de plusieurs services

Décrire textuellement les acteurs

Décrire, sous forme de texte, chaque acteur en interaction Décrire, sous forme de texte, chaque acteur en interaction avec le systèmeavec le système

Analyse d’un cas d'utilisation

ActionAction ObjectifObjectif

Décriretextuellement un cas d'utilisation

Décrire précisément un cas d'utilisation, en langage naturel, Décrire précisément un cas d'utilisation, en langage naturel,

selon un modèle structuré comportant des clauses et en selon un modèle structuré comportant des clauses et en

apportant des informations sur son comportement dynamique. apportant des informations sur son comportement dynamique.

Décrire textuellement un scénario

Décrire de façon détaillée en langage naturel, et selon un Décrire de façon détaillée en langage naturel, et selon un

modèle structuré comportant des clauses, le déroulement d’un modèle structuré comportant des clauses, le déroulement d’un

scénario représentatif du cas d'utilisation concernéscénario représentatif du cas d'utilisation concerné

Décrire la dynamique d'un cas d'utilisation

Modéliser l'enchaînement des tâches et des flots d’événements Modéliser l'enchaînement des tâches et des flots d’événements

et d’informations mis en oeuvre lors de l'exécution d’un cas et d’informations mis en oeuvre lors de l'exécution d’un cas

d'utilisationd'utilisation

Identifier les règles de gestion

Identifier et définir précisément les règles de gestion qui Identifier et définir précisément les règles de gestion qui

doivent être satisfaites lors du déroulement du cas d'utilisation. doivent être satisfaites lors du déroulement du cas d'utilisation.

Une règle de gestion est une propriété (portant dans ce cas sur Une règle de gestion est une propriété (portant dans ce cas sur

le déclenchement des tâches du cas d'utilisation) qui relève du le déclenchement des tâches du cas d'utilisation) qui relève du

métier et qui doit toujours être vérifiéemétier et qui doit toujours être vérifiée

Analyse d’un cas d'utilisation: Description textuelle d'un cas d'utilisation

ClauseClause DescriptionDescription

IdentifiantIdentifiant Contient un nom qui identifie de manière non ambiguë le cas d'utilisation dans le Contient un nom qui identifie de manière non ambiguë le cas d'utilisation dans le modèle d’analysemodèle d’analyse

RésuméRésumé est une description succincte en quelques lignes qui résume l'objectif du cas est une description succincte en quelques lignes qui résume l'objectif du cas

d'utilisationd'utilisation

ActeursActeurs contient une énumération des identifiants des acteurs qui interagissent avec le contient une énumération des identifiants des acteurs qui interagissent avec le

systèmesystème

Contexte de Contexte de déclenchementdéclenchement

décrit l’événement déclencheur du cas d’utilisation, qui peut être un stimulus émis décrit l’événement déclencheur du cas d’utilisation, qui peut être un stimulus émis

par un acteur, un événement conditionnel ou un événement temporelpar un acteur, un événement conditionnel ou un événement temporel

Pré conditionsPré conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement pour pouvoir déclencher le cas manipulées par le système et son environnement pour pouvoir déclencher le cas d'utilisationd'utilisation

DescriptionDescription doit indiquer, dans le texte qui la constitue, le séquencement des tâches du cas doit indiquer, dans le texte qui la constitue, le séquencement des tâches du cas d'utilisation, les services utilisés, les entités manipulées, sous forme de concepts et d'utilisation, les services utilisés, les entités manipulées, sous forme de concepts et d’informations, et les conditions de déclenchement des exceptionsd’informations, et les conditions de déclenchement des exceptions

Post conditionsPost conditions contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement à la fin de l'exécution du cas manipulées par le système et son environnement à la fin de l'exécution du cas d'utilisationd'utilisation

ExceptionsExceptions est un texte qui décrit, pour chaque exception citée dans la clause Description, le est un texte qui décrit, pour chaque exception citée dans la clause Description, le traitement (local, ou délégué à un autre cas d'utilisation) de cette exceptiontraitement (local, ou délégué à un autre cas d'utilisation) de cette exception

Contraintes non Contraintes non fonctionnellesfonctionnelles

est un texte décrivant les contraintes non fonctionnelles spécifiques au cas d'utilisationest un texte décrivant les contraintes non fonctionnelles spécifiques au cas d'utilisation

Analyse d’un cas d'utilisation: Description textuelle d'un scénario

ClauseClause DescriptionDescription

IdentifiantIdentifiant Contient un nom qui identifie de manière non ambiguë le scénario dans Contient un nom qui identifie de manière non ambiguë le scénario dans le modèle d’analysele modèle d’analyse

RésuméRésumé est une description succincte en quelques lignes qui résume l'objectif du est une description succincte en quelques lignes qui résume l'objectif du scénario scénario

ActeursActeurs contient une énumération des identifiants des acteurs qui interagissent contient une énumération des identifiants des acteurs qui interagissent avec le système dans le cadre du scénarioavec le système dans le cadre du scénario

Contexte de Contexte de déclenchementdéclenchement

décrit l’événement déclencheur du scénario, qui peut être un stimulus décrit l’événement déclencheur du scénario, qui peut être un stimulus émis par un acteur, un événement conditionnel ou un événement émis par un acteur, un événement conditionnel ou un événement temporeltemporel

Pré conditionsPré conditions contient un texte qui exprime des propriétés qui doivent être satisfaites contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement pour par les entités manipulées par le système et son environnement pour pouvoir déclencher le scénariopouvoir déclencher le scénario

DescriptionDescription doit indiquer, dans le texte qui la constitue, le séquencement des tâches doit indiquer, dans le texte qui la constitue, le séquencement des tâches du scénario, les services utilisés, les entités manipulées, sous forme de du scénario, les services utilisés, les entités manipulées, sous forme de concepts et d’informationsconcepts et d’informations

Post conditionsPost conditions contient un texte qui exprime des propriétés qui doivent être satisfaites contient un texte qui exprime des propriétés qui doivent être satisfaites par les entités manipulées par le système et son environnement à la fin par les entités manipulées par le système et son environnement à la fin de l'exécution du scénariode l'exécution du scénario

Analyse d’un cas d'utilisation: Représentation dynamique La représentation dynamique d’un cas d'utilisation exprime de manière plus

formelle le contenu de sa description (clause Description).

En effet, la description textuelle d’un cas d'utilisation fait apparaître le cas nominal, les scénarios d’alternatives et les cas d’exception du comportement du cas d'utilisation.

Si le nombre de scénarios est important ou le cas d'utilisation complexe à décrire, il est donc intéressant de compléter cette description textuelle par une modélisation de la cinématique des tâches qui composent le cas d'utilisation.

Par rapport à la description textuelle du cas d'utilisation et au modèle de cas d'utilisation, la représentation dynamique comporte les informations suivantes, formalisées : L'ordre de séquencement des tâches (qui peuvent correspondre à des appels de

services) qui composent le cas d'utilisation ainsi que les parallélisations possibles ; Des indications sur les entités produites et/ou utilisées et sur leur état ; Les acteurs interagissant avec le système ; Les événements reçus et produits par le cas d'utilisation.

En UML, la représentation de ces informations est possible à l’aide du diagramme d’activités.

Structuration du modèle des cas d'utilisation

ActionAction ObjectifObjectif

Identifier des fonctionnalités Identifier des fonctionnalités

partagées entre cas d'utilisationpartagées entre cas d'utilisation

Distinguer, en identifiant de nouveaux cas Distinguer, en identifiant de nouveaux cas d'utilisation, les comportements communs à d'utilisation, les comportements communs à plusieurs cas d'utilisation, et donc réutilisablesplusieurs cas d'utilisation, et donc réutilisables

Identifier des fonctionnalitésIdentifier des fonctionnalités

optionnelles pour un cas d'utilisationoptionnelles pour un cas d'utilisation

Distinguer, en identifiant de nouveaux cas Distinguer, en identifiant de nouveaux cas

d'utilisation, les comportements optionnels d'utilisation, les comportements optionnels

pour un cas d'utilisationpour un cas d'utilisation

Identifier des cas d'utilisationIdentifier des cas d'utilisation

génériquesgénériques

Identification de cas d'utilisation généralisant Identification de cas d'utilisation généralisant

d'autres cas d'utilisationd'autres cas d'utilisation

Structurer le modèle des acteursStructurer le modèle des acteurs Faire apparaître d’éventuelles généralisationsFaire apparaître d’éventuelles généralisations

d’acteursd’acteurs

Définir les catégories de casDéfinir les catégories de cas

d'utilisation et leurs dépendancesd'utilisation et leurs dépendances

Partitionner le modèle de cas d'utilisation en Partitionner le modèle de cas d'utilisation en

les regroupant en catégories, et en identifiant les regroupant en catégories, et en identifiant

les dépendances entre ces catégoriesles dépendances entre ces catégories

Description des besoins non fonctionnels

Cette activité produit une description textuelle des besoins non fonctionnels, qu’ils soient spécifiques à un cas d'utilisation ou non

Les besoins non fonctionnels décrivent des caractéristiques du système ou de son environnement :

Facilité d’utilisation, Fiabilité, Performances, Contraintes de développement et de mise en production, Contraintes d’interfaçage avec des systèmes physiques ou

informatiques externes, Contraintes de conception (fonctionnement multi-utilisateurs,

volumétrie des données, fréquence de déroulement des séquences d’interactions utilisateur/système, etc.),

Contraintes d’implémentation (standards, langages, politique d’intégrité de base de données, limite de ressources, environnement d’exécution, lignes directrices, etc.)

Maquettage de l’interface utilisateur

Cette activité produit les maquettes d’interface utilisateur, sous forme papier ou exécutable.

Ce maquettage est itératif jusqu'à la stabilisation des exigences de la MOA et des utilisateurs.

Vérification du modèle des besoins

Cette activité vérifie le modèle des besoins à chaque incrément de la reformulation des besoins.

Elle ne comporte pas d'actions particulières. Elle utilise tous les produits du travail qui sont le résultat de la reformulation des besoins, mais ne les modifie pas et n'en crée pas de nouveaux (la correction éventuelle d'un produit du travail est du ressort de l'activité qui l'a produit)

Vérification du modèle des besoins (suite)Les règles suivantes doivent être vérifiées lors de cette activité : Chaque acteur identifié doit être réellement externe au système. Tous les acteurs identifiés doivent être facilement compréhensibles des différents

intervenants du projet. Il doit exister au moins un diagramme de contexte pour représenter l’environnement du

système. Tous les acteurs identifiés doivent apparaître sur au moins un diagramme de contexte. Si différents types de diagrammes de contexte sont utilisés pour représenter le système

dans son environnement, ils doivent être cohérents. Chaque acteur doit être émetteur ou récepteur d’événements ou d’informations par

rapport au système. Tous les acteurs identifiés doivent communiquer avec au moins un cas d'utilisation. Le modèle de description textuelle de cas d'utilisation doit être respecté. Les clauses

obligatoires doivent être renseignées. Le vocabulaire employé dans les descriptions textuelles des cas d’utilisation et des

scénarios doit être simple, précis et compréhensible des correspondants Maîtrise d’Ouvrage et des utilisateurs qui les liront et les valideront.

Le déclenchement et la terminaison de chaque cas d'utilisation doivent être précisés. Pour chaque scénario réalisé pour une condition, le scénario correspondant à la négation

de la condition doit être décrit. Toutes les relations entre cas d'utilisation doivent être justifiées. Les fonctionnalités communes à plusieurs cas d'utilisation doivent être factorisées. Les fonctionnalités optionnelles d’un cas d'utilisation doivent être dissociées.

Analyse système

Modélisation objet

Modélisation objet

La macro-activité Modélisation objet du système consiste à itérer sur cinq activités principales:

Description d’un cas d'utilisation Structuration du modèle du système Description d’une classe Description d’une association Vérification du modèle du système

Description d’un cas d'utilisation

ActionAction ObjectifObjectif

Identifier les entités participant à un cas d'utilisation

Identifier les entités participant au déroulement du Identifier les entités participant au déroulement du cas d'utilisation, leurs associations et attributs cas d'utilisation, leurs associations et attributs concernés. Certaines de ces entités peuvent concernés. Certaines de ces entités peuvent correspondent à des concepts spécialisés déjà correspondent à des concepts spécialisés déjà identifiésidentifiés

Modéliser les scénarios d'un cas d'utilisation

Préciser au moyen de diagrammes d'interaction la Préciser au moyen de diagrammes d'interaction la description textuelle des scénarios représentatifs, description textuelle des scénarios représentatifs, en faisant ainsi apparaître les interactions entre en faisant ainsi apparaître les interactions entre objets (acteurs, entités, cas d'utilisation inclus) objets (acteurs, entités, cas d'utilisation inclus) participant au cas d'utilisation. Une interaction participant au cas d'utilisation. Une interaction peut correspondre à un appel de service émis vers peut correspondre à un appel de service émis vers un système externeun système externe

Structuration du modèle du système

ActionAction ObjectifObjectif

Définir les catégories d’entités et leurs dépendances

Partitionner le modèle objet des entités en Partitionner le modèle objet des entités en regroupant les entités en catégories, et regroupant les entités en catégories, et représenter leurs Dépendancesreprésenter leurs Dépendances

Définir les dépendances entrecatégories de cas d'utilisation et d’entités

Définir les dépendances des catégories de casDéfinir les dépendances des catégories de cas

d'utilisation vis à vis des catégories d’entitésd'utilisation vis à vis des catégories d’entités

Construire des vues Cas d'utilisation, Entité ou Acteur

Réaliser des vues partielles du modèle objet, Réaliser des vues partielles du modèle objet, centrées soit sur les classes de type Cas centrées soit sur les classes de type Cas Utilisation, soit sur les classes de type Entité, soit Utilisation, soit sur les classes de type Entité, soit sur les classes de type Acteur, afin de pouvoir sur les classes de type Acteur, afin de pouvoir faire des analyses d’impact en mettant en relief faire des analyses d’impact en mettant en relief un élément du modèleun élément du modèle

Description d’une classeActionAction ObjectifObjectif

Définir l’entité et ses responsabilités

Décrire le concept représenté par l’entité, et lesDécrire le concept représenté par l’entité, et les

responsabilités de l’entité (ce qu'elle sait faire ouresponsabilités de l’entité (ce qu'elle sait faire ou

interpréter) afin de mieux cerner son rôle dans le interpréter) afin de mieux cerner son rôle dans le systèmesystème

Décrire les attributs de l’entité Décrire précisément chaque attribut au niveau Décrire précisément chaque attribut au niveau analyse de l’entité: son rôle, son type, etc.analyse de l’entité: son rôle, son type, etc.

Décrire le cycle de vie de l’entité

Lorsque l’entité a un cycle de vie significatif, Lorsque l’entité a un cycle de vie significatif, décrire les principaux états de l’entité et les décrire les principaux états de l’entité et les transitions possibles entre ces étatstransitions possibles entre ces états

Identifier les règles de gestion Identifier les règles de gestion qui s'appliquent àIdentifier les règles de gestion qui s'appliquent à

l'entité, et donner à ces règles de gestion une l'entité, et donner à ces règles de gestion une définition précise. Une règle de gestion est une définition précise. Une règle de gestion est une propriété (portant dans ce cas sur l'entité, ses propriété (portant dans ce cas sur l'entité, ses attributs, ses états) qui relève du métier et qui attributs, ses états) qui relève du métier et qui doit toujours être vérifiéedoit toujours être vérifiée

Description d’une association

Cette activité enrichit le modèle statique du système.

Cette activité ne se décompose pas en actions particulières

Vérification du modèle du systèmeLes règles suivantes doivent être vérifiées lors de cette activité : « Jouer » les scénarios sur le modèle statique afin de vérifier que toutes les

entités, les relations et tous les attributs nécessaires à un scénario sont présents dans le modèle statique.

Vérifier que chaque événement possède un objet émetteur et un objet récepteur qui peuvent être le même objet.

Vérifier que tous les attributs d'une entité sont référencés au moins une fois dans le modèle dynamique (référencés par des conditions gardées, manipulés dans des actions ou activités,….)

Vérifier que le partitionnement du modèle objet du système en catégories d’entités est cohérent, à savoir : Pas de dépendance circulaire entre catégories, Pas d’entité isolée dans une catégorie, Les entités liées par une composition doivent appartenir à la même catégorie.

Vérifier que les dépendances entre catégories de cas d’utilisation et d’entités sont cohérentes : une catégorie de cas d’utilisation peut dépendre d’une ou plusieurs catégories d’entités, mais une catégorie d'entités ne peut pas dépendre d'une catégorie de cas d'utilisation.

Vérifier que les interactions entre scénarios de cas d’utilisation dans la vue dynamique sont cohérentes avec les relations entre cas d’utilisation exprimées dans le modèle de cas d’utilisation.

Vérification du modèle du système (suite) Vérifier la cohérence entre les responsabilités des entités décrites

au niveau de chaque entité et leur mise en oeuvre effective dans les diagrammes de la vue dynamique.

Vérifier que les diagrammes d’interactions sont lisibles. Vérifier que toutes les associations du modèle statique sont

utilisées dans le sous ensemble du modèle dynamique concernant l’une des entités participant à l’association.

Vérifier que toutes les relations de composition entre entités sont justifiées, c-à-d pour les classes les représentant : La classe composant est réellement une «partie» de la classe

composée. Le cycle de vie de la classe composant doit être lié à celui de la classe

composée. Vérifier que toute entité est justifiée, c-à-d qu’elle n’est pas :

Redondante : elle exprime le même concept qu’une autre entité, Floue : sa sémantique n’est pas clairement définie, Abusive : elle correspond en fait à un attribut, Au mauvais niveau : classe relevant d’un choix de conception.

Vérification du modèle du système (suite) Vérifier que tout attribut est justifié, c’est-à-dire qu’il

ne représente pas un concept mais bien une propriété que l’on peut valoriser.

Vérifier que toute entité ayant un comportement dynamique significatif dans le fonctionnement du système présente une description de son cycle de vie.

Vérifier que tous les événements concernant une entité apparaissent dans le diagramme montrant son cycle de vie.

Vérifier que chaque diagramme représentant le cycle de vie d’une entité est un automate déterministe.

Vérifier que le cycle de vie d’une entité soit lisible. Vérifier que chaque élément du modèle statique du

système est commenté.

Exemple: consulter une commande

Utilisateur

(from Acteurs)

Rechercher des commandes

Consulter des commandes

<<include>>

Consulter le detail d'une commande

<<extend>>

Consulter la synthèse d'une commande

(from UC Commun Commande)

Exemple: consulter une commande Titre

Consulter commande Description

Cette fonctionnalité permet à l'acteur ayant droit de consulter les commandes en cours ou archivés.

ActeursL'utilisateur

Pré conditionsL'acteur s'est authentifié sur le système. Il a choisit un contrat et un catalogue.

Post conditionsLes commandes sont consultées

DéclencheursL'acteur peut accéder à la consultation de commandes à partir du menu principal de la page d'accueil

Exemple: consulter une commande Description du traitement nominal

1. L'acteur sélectionne un client2. l'acteur recherche une commande à partir d'un critère <<include>> Rechercher des commandes.3. Le système affiche les commandes en cours et les commandes archivées associées au critère de recherche.4. L'acteur peut sélectionner une commande pour consulter les détails.5. Le système affiche les détails de la commande sélectionnée <<extend>> Consulter le détail d'une commande.

Complément d'exigences fonctionnellesfaut-il limiter la consultation uniquement aux services auxquels l'utilisateur à le droit ?La liste des commandes en cours est composée des éléments suivants :- la date de création de la commande (date d'enregistrement),- le numéro de la commande, lien vers la consultation détaillée d'une commande ,- le code et le libellé du service,- le statut de la commande (relatif au processus),- l'état de la commande (relatif au processus).

La liste des commandes archivée est composée des éléments suivants :- la date de création de la commande (date d'enregistrement),- le numéro de la commande, lien vers la consultation détaillée d'une commande ,- le code et le libellé du service.

Exemple: consulter une commande Description des exceptions

Sans objet.

Description des traitements alternatifsSans Objet

Contraintes IHMLes commandes sont affichées par des tranches de 20. Les commandes en cours sont affichées avant les commandes archivées.

Contraintes non fonctionnellesaccès en moins de 5 s au service.

Conception

Techniques d’analyse et conception

Les patterns Un pattern est une bonne pratique face à un problème

courant. Il est souvent traduit dans la littérature française par «modèle», «motif», «solution abstraite» ou «patron»

Un pattern est une capitalisation du savoir-faire et de l’expérience pour résoudre des problèmes récurrents intervenants dans les différents niveaux du processus: analyse (analysis pattern), architecture (architectural pattern) conception (design pattern) programmation (idiomes ou idiomatiques en français)

C’est un moyen de partager la connaissance de la résolution d’un type de problème sous une forme « conceptuelle », mais ce n’est pas une solution implémentée.

Pourquoi les patterns Tout d’abord, pour ne pas réinventer, mais aussi pour :

se concentrer sur de bons designs objets, apprendre en suivant de bons exemples, écrire du code facilement compréhensible par les autres

programmeurs.

Utiliser les DP apporte des avantages … Un vocabulaire commun, Une capitalisation de l’expérience Un niveau d’abstraction plus élevé qui permet d’élaborer des

constructions logicielles de meilleure qualité Une réduction de la complexité Un guide/catalogue de solutions,

… mais n’est pas sans inconvénients car cela nécessite Un effort de synthèse : reconnaître, abstraire… Un apprentissage à effectuer, une expérience.

Techniques de conception L’activité de conception

La spécification et l’analyse des besoins ont permis de définir quel système construire.

L’activité de conception, s’intéresse à la façon de construire le système.

Elle vise à construire une solution qui conforme aux besoins du système

Techniques de conception La conception orienté objet

En conception, un système est vu comme une communauté d’objets qui collaborent entre eux.

Ce mode de réflexion permet:

d’identifier les objets qui contribuent à la réalisation d’un événement système.

de définir les actions pour qu’ils s’acquittent de leurs responsabilités.

Techniques de conception Les responsabilités sont affectées aux classes et sont de

deux types:

Les responsabilités de Faire comme:

Créer un objet ou faire un calcul. Déclencher une action sur un objet. Contrôler les activités d’un objet.

Les responsabilités de Savoir comme:

Connaître les données encapsulées. Connaître les objets connexes. Connaître les éléments à dériver ou à calculer

Techniques de conception Les classes de Jacobson

les classes de conception identifiées peuvent être classifiées selon trois catégories, correspondant aux trois classes d’analyse de Jacobson :

Les classes « boundary » jouent le rôle d’intermédiaires entres les acteurs externes au système et

le coeur du système. Il s’agit des classes de présentations, d’interfaces avec d’autres systèmes ou pilotes de périphériques. Généralement on retrouve au moins une classe « boundary » par paire (acteur, cas d’utilisation).

Les classes « entity » constituent l’abstraction du cas d’utilisation et correspondent plus ou

moins aux entités identifiées dans la phase d’analyse système. Elles se traduisent souvent par des composants persistants.

Les classes « control » permettent de découpler les deux types de classes précédentes. Elles

contiennent la logique applicative, la coordination, l’enchaînement de tâches dans les systèmes.

Techniques de conceptionQuelques règles sont à respecter pour la mise en place de ces classes

d’analyse :

Les acteurs ne peuvent interagir qu’avec les boundary

Les boundary peuvent interagir avec les control ou exceptionnellement avec d’autres boundary, mais jamais directement avec les entity

Les control peuvent interagir avec les boundary, les entity ou d’autres control

Les entity ne peuvent interagir qu’entre elles. (les control peuvent manipuler des entity, mais pas l’inverse)

Ces classes apparaîtront pendant la phase où on passe des diagrammes d’analyse système aux premiers diagrammes de conception (éclatement des diagrammes de séquence ou de collaboration).

Architecture

L’architecture logicielle et technique

ArchitectureL’architecture c’est « l’art de concevoir et de construire

un bâtiment selon un esthétisme et des règles techniques déterminées. »

Cette définition peut s’appliquer à la fabrication du logiciel.

A l’instar d’un bâtiment, un logiciel est:

structuré par un plan, illustré par une maquette, réalisé par des procédés et des outils adaptés.

ArchitectureL’architecture d’un système peut être vue selon deux

angles principaux.

La vue logique qui concerne l’organisation conceptuelle ou la structure du système.

La vue de déploiement qui concerne l’organisation physique du système:

Machines, OS, Réseaux, etc …

ArchitectureLa vue logique ou l’architecture logicielle décrit:

L’organisation générale d’un système. Les éléments qui le structurent et leurs interfaces. Les propriétés et les collaborations des éléments qui

le composent.

Elle contribue à une meilleure qualité du Logiciel en terme de:

maintenance, évolutivité, réutilisation, performance, etc.

Architecture L’architecture par couches

On l’applique aux applications munies d’une interface graphique et manipulant des données.

Elle a pour but de séparer les différentes logiques d’une application:

La présentation. La logique applicative. Le domaine métier. L’accès aux des données.

Architecture (déploiement) La vue par niveau ou Tiers donne la vision physique

d’un système.

Elle distribue les couches logiques d’un système sur ses éléments physiques.

Plusieurs de ces modèles ont vu le jour:

Le modèle 1 Tiers. Le modèle 2 Tiers ou Client/Serveur ou Thick client. Le modèle 3 Tiers aussi appelé N-Tiers ou Thin client.

Architecture 1/3 Les applications tournaient sur

des systèmes en temps partagé. Caractéristiques:

Gros systèmes mêlant interfaces, règles métiers et données

Terminaux passifs Avantages

Administration performance sécurité

Inconvénients Mode caractère peu convivial Ouverture vers d’autres

systèmes

Terminaux passifsTerminaux passifs Gros systèmeGros système

Architecture 2/3 L'architecture à deux niveaux (2-

tiers) caractérise les systèmes clients/serveurs.

Caractéristiques: Un SGBD et une application

Avantages Permet de répartir la puissance

machine sur les clients Mise en oeuvre du modèle de bases

de données relationnelles Intégration inter-systèmes au

niveau des données possibles Inconvénients

Déploiement Maintenance, gestion des versions Les règles métiers réparties sur les

deux composantes

clientsclients SGBDRSGBDR

Architecture 3/3Caractéristiques:

Les 3 niveaux: Le client: le demandeur de ressources Le serveur d'application (appelé aussi middleware) chargé de fournir la ressource mais faisant appel à un autre serveur Le serveur secondaire (généralement un serveur de base de données, fichiers XML, annuaire LDAP, ...), fournissant un service au premier serveur

Des normes de communication entre les niveaux

clientsclients Serveur Serveur d’applicationd’application RessourcesRessources

Architecture N/3 La requête d'un client peut-

être re-routée vers un autre serveur

Différents serveurs peuvent accéder à une même base de données ou à un même serveur de données.

Les différents serveurs peuvent être directement en communication (pour se synchroniser, se répartir les requêtes des clients, prendre la place d'un autre serveur défaillant, etc.).