démarche & méthode mustapha el feddi mustapha.elfeddi@sofrecom.com
Post on 03-Apr-2015
115 Views
Preview:
TRANSCRIPT
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.).
top related