Plan du cours
This presentation is the property of its rightful owner.
Sponsored Links
1 / 66

Plan du cours PowerPoint PPT Presentation


  • 186 Views
  • Uploaded on
  • Presentation posted in: General

Plan du cours. Processus Unifié (Unified Process) Le cycle en Y Techniques d’analyse et de conception. Processus Unifié. Unified Process. Définition. UP est un processus de type adaptatif, il est Itératif et incrémental Guidé par les besoins (exigences) des utilisateurs

Download Presentation

Plan du cours

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Plan du cours

Plan du cours

  • Processus Unifié (Unified Process)

  • Le cycle en Y

  • Techniques d’analyse et de conception


Processus unifi

Processus Unifié

Unified Process


D finition

Définition

  • UP est un processus de type adaptatif, il est

    • Itératif et incrémental

    • Guidé par les besoins (exigences) des utilisateurs

    • Centré sur l’architecture

    • Piloté par les risques

  • On le représente selon l’axe statique et dynamique des processus de développement.


Phases et it rations

Phases et itérations

UP comporte les quatre phases suivantes:

  • Pré étude: définition du cadre du projet

  • Élaboration: établissement d’un plan de projet et d’une architecture solide

  • Construction: développement du système

  • Transition: livraison du système aux utilisateurs finaux

    Il existe un certain nombre d’itérations à l’intérieur de chaque phase.

    Une itération représente un cycle de développement logiciel complet (analyse des besoins  version exécutable)


Cycle de vie

Cycle de vie

Itér

n

Itér

n+1

Itér

n+2

Itér

m

Itér

m+1

Itér 1

Itér 2


Phases

Phases

  • Pré étude : On définit le cadre du système et on délimite la portée du projet. Ce cadre comprend:

    • Les critères de réussite

    • La mise en évidence des risques

    • Les estimations des ressources nécessaires

    • Un plan de phase qui contient un planning des principaux jalons

    • Un prototype exécutable validant le concept

  • Élaboration: consiste à

    • Analyser le domaine du problème

    • Établir une architecture solide

    • Développer le plan du projet

    • Éliminer les éléments à risques pour le projet


Phases1

Phases

  • Construction: On développe un produit complet et prêt à transiter vers les utilisateurs, de manière itérative et incrémentale

  • Transition: au cours de cette phase on déploie le logiciel pour les utilisateurs, on réajuste le système en corrigeant les éventuels bugs ou on achève certains fonctionnalités qui avaient été remises à plus tard


Workflows et processus

Workflows et processus


Workflows et artefacts

Workflows et artefacts


Up est it ratif et incr mental

UP est Itératif et incrémental

  • Le développement d’un logiciel nécessite qu’on le découpe en plusieurs petits projets.

  • Chaque projet représente une itération qui donne lieu à un incrément.

    Une itération désigne la succession des activités de développement

    un incrément correspond aux stades de développement du produit


Up est pilot par les uses cases

UP est piloté par les uses cases

Pour servir les attentes des utilisateurs, On centre le processus de développement sur leurs besoins.

On fait apparaître ces besoins à l’aide de la technique des cas d’utilisation :

  • en capturant les besoins fonctionnels d’un système

  • en orientant le travail de chaque itération

    vont guider le processus à travers l’utilisation des différents modèles UML qui représentent le système.


Processus unifi mod le en y

Cahier des charges

Analysés par

Modèle du domaine

Conçus par

Modèle de conception

Réalisés par

Modèle d’implémentation

Modèle d’architecture

Structurés par

Testés par

Modèle de tests

Diagramme des Uses Case

Modèle de déploiement

Déployés par


Up est centr sur l architecture

UP est centré sur l’architecture

  • l’architecture doit prévoir la réalisation de tous les uses case et doit évoluer avec eux.

  • Elle le fait en tenant compte de facteurs tels que:

    • La plateforme d’exécution

      • Matériel, système, BD, réseau,etc.

    • Les composants réutilisables

      • Librairies, caisse à outils, composants du commerce, etc.

    • Les considérations de déploiement et les besoins non fonctionnels

      • La performance, la fiabilité, la robustesse, etc.


Up est pilot par les risques

UP est piloté par les risques

Un risque est un événement redouté dont l’occurrence est plus ou moins prévisible.

Le pilotage par les risques c’est:

  • Analyser les risques potentiels au plus tôt

  • Hiérarchiser les risques

  • Associer un ensemble de uses case à chaque risque

  • Déclencher les itérations selon la criticité des uses cases qu’elles regroupent

    UP propose une gestion des risques. Ce qui constitue une avancée significative.


Les adaptations de up

Les adaptations de UP

UP est un processus générique de développement. Il doit être adaptée au contexte du projet, de l’équipe et de l’organisation concernée.

Il existe donc des adaptations d’UP dont les plus connues sont:

  • Le Rational Unified Process (RUP)

  • L’eXtreme Programming (XP)

  • Le Two Tracks Unified Process (2TUP)


Cycle en y

Cycle en Y

Two Track Unified Process


D finition1

Contraintes

techniques

Contraintes

fonctionnelles

Définition

  • 2TUP est un processus UP apportant une réponse aux contraintes de changement continuel des SI: fonctionnel et technique

  • 2 Track: processus suivant deux chemins

    • Fonctionnel

    • Architecture Technique

SI


Exemples

Exemples

  • Une entreprise modifie son catalogue de produit en imposant de nouvelles règles de tarification  évolution fonctionnelle.

  • Cette même entreprise décide de rendre accessible son catalogue via le WEB  évolution technique.

  • Cette entreprise décide finalement de fusionner son catalogue avec une autre entreprise du même secteur évolution fonctionnelles et techniques.


Cycle en y1

Cycle en Y

La réalisation du système consiste à fusionner les résultats des deux évolutions fonctionnelle et technique: ce qui conduit à un processus de développement en forme de Y


Cycle en y2

Conception préliminaire

Conception détaillée

Contraintes

techniques

Contraintes

fonctionnelles

Codage et tests

Recette

Cycle en Y

Branche

fonctionnelle

Branche

technique

Y

Capture des besoins

fonctionnels

Capture des besoins

techniques

Analyse

Conception générique

prototype


Cycle en y3

Cycle en Y

La branche gauche (fonctionnelle) du Y

  • Capture des besoins fonctionnels

    • Produit un modèle des besoins focalisée sur le métier des utilisateurs

    • Qualifie au plus tôt le risque de produire un système inadapté

    • Permet à la maîtrise d’œuvre de consolider les spécifications et de vérifier la cohérence

  • L’analyse

    • Précise ce que l’on va réaliser en termes métier

    • Le résultat de l’analyse ne dépend d’aucune technologie particulière


Cycle en y4

Cycle en Y

La branche droite (architecture technique) du Y

  • Capture des besoins techniques

    • Recense toutes les contraintes et les choix dimensionnant la conception

    • Identifie les outils et les matériels ainsi que les contraintes d’intégration avec l’existant

  • La conception générique

    • Définit les composants nécessaires à l’élaboration de l’architecture technique

    • Construit le squelette du système et élimine les risques au niveau technique

    • A pour objectif d’uniformiser et de réutiliser les mêmes mécanismes pour la plupart des systèmes

    • Est indépendante des aspects fonctionnels


Cycle en y5

Cycle en Y

La branche du milieu

  • La conception préliminaire

    • Intègre le modèle d’analyse dans l’architecture technique

    • Trace la cartographie des composants du système à développer

  • La conception détaillée

    • Étudie comment réaliser chaque composant

  • Codage

    • Produit les composants et teste au fur et à mesure les unités de code réalisées

  • Recette

    • Valide les fonctions du système développé


Cycle en y6

Cycle en Y

  • Les branches du «Y» produisent des modèles réutilisables

    • La branche gauche capitalise la connaissance du métier de l’entreprise: les fonctions du système d’information sont indépendantes des solutions techniques utilisées.

    • La branche droite capitalise le savoir faire technique: les techniques utilisées peuvent être réalisées indépendamment du besoin fonctionnel


Processus unifi mod le en y

La connaissance d’un langage de modélisation comme UML

La mise en œuvre d’un processus de développement adaptatif comme UP

Ne disent pas ce que doit faire le système ni comment le modéliser !

Nous avons besoin de techniques pour le spécifier, l’analyser et le concevoir.

La modélisation du système


Mod lisation

Modélisation

Techniques de spécification des besoins


Les cas d utilisation

Les cas d’utilisation

  • Les cas d’utilisation sont une collection de scénarios de réussite et/ou d’échec.

  • Ils décrivent la façon dont un acteur utilise un système pour atteindre un but.

  • Ils sont de type boîte noire et décrivent un système en terme de comportement.

  • Ce qu’il fera et non comment il le fera!


Processus unifi mod le en y

Un scénario est un chemin particulier pris lors de l’exécution d’un use case

Nominal - c’est le scénario typique de succès

Alternatif – il correspond aux traitements alternatifs possibles

D’échec – il recensent les échecs dans le déroulement d’une étape de scénario

Les scénarios


Identification des uses cases

Identification des uses cases

  • Comment identifier les uses cases ?

    • Les Processus Métier Élémentaires servent à atteindre le but d’un utilisateur du système.

    • Ils sont de niveau Objectif utilisateur et sont analogues aux cas d’utilisation d’un système.

    • Recenser les PME, permet de découvrir l’ensemble des cas d’utilisation d’un système


Description des uses cases

Description des uses cases

  • Seule la forme textuelle permet de décrire les cas d’utilisation. UML n’en propose aucune.

  • Selon le niveau de précision, la rédaction d’un cas d’utilisation peut prendre deux formes:

    • Résumée

    • détaillée

  • Quelle que soit la forme utilisée, on doit toujours se concentrer sur

    • les intentions de l’utilisateur

    • les responsabilités du système


Use case r sum

Use case: Résumé

  • Le format résumé décrit brièvement, le comportement du cas d’utilisation.

  • Il ne mentionne que l’activité et les échecs les plus significatifs.

  • On les élabore en étendant la liste des objectifs par acteur.


Use case d taill e

Use case: Détaillée

  • Dans sa version étoffée:

    • Titre

    • Description

    • Acteurs

    • Portée

    • Niveau

    • Parties prenantes et intérêts

    • Pré conditions et déclencheurs

    • Scénario nominal

    • Scénarios alternatifs

    • Scénarios d’erreur

    • Post conditions (garantie de succès et d’échec)

    • Variantes de données et de technologies

    • ContraintesIHM

    • Contraintes non fonctionnelles

    • Questions en suspens


Mod le des cas d utilisation

Modèle des cas d’utilisation

  • UML représente les cas d’utilisation par le diagramme de cas d’utilisation.

  • On y montre les acteurs en relation avec les cas d’utilisation.

  • Ce qui donne une vision spatiale et dynamique du système


Exemple consulter une commande

Exemple: consulter une commande


Exemple consulter une commande1

Exemple: consulter une commande

  • Titre

    Consulter commande

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

  • Acteurs

    L'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 commande2

Exemple: consulter une commande

  • Description du traitement nominal1. 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 commande3

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.


Mod lisation1

Modélisation

Techniques d’analyse et conception


Les patterns

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

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 d analyse

Techniques d’analyse

  • Objectifs

    Analyser les besoins, c’est rechercher les objets du domaine, leurs propriétés et leurs relations.

    Le diagramme de classe issu de cette activité représente:

    • les classes conceptuelles ou les objets du domaine.

    • les attributs de ces classes.

    • les associations entre ces classes.


Techniques d analyse1

Techniques d’analyse

  • Mode opératoire

    Pour chaque cas d’utilisation, on déroule les étapes des scénarios que l’on analyse:

    • Pour identifier les classes du domaine.

    • Pour rechercher les attributs de ces classes.

    • Pour recherches les associations entre ces classes.

    • Pour typer ces associations.


Techniques d analyse2

Techniques d’analyse

  • Identification des classes

    Pour identifier les classes conceptuelles, plusieurs techniques existent:

    • l’analyse linguistique.

    • les listes de catégories.

    • les classes de spécifications.

    • les types de données non primitifs.

    • les patterns d’analyse


Techniques d analyse3

Techniques d’analyse

  • Les attributs

    Un attribut est la valeur d’une donnée logique d’un objet.

    Une commande par exemple à un type, une description et une date qui doivent être connus.

    La classe conceptuelle Commande doit donc avoir des attributs type, description et date


Techniques d analyse4

Techniques d’analyse

  • Les associations

    Une association est une relation significative entre des classes

    On distingue plusieurs sortes d’associations :

    • Les associations multiples

    • La généralisation/spécialisation

    • Les classes d’association

    • L’agrégation

    • L’association qualifiée

    • L’association réflexive


Mod lisation2

Modélisation

Réalisation des cas d’utilisation


R alisation des cas d utilisation

Réalisation des cas d’utilisation

  • Les opérations système

    Les opérations système gèrent les événements entrants

Consulter commande

:Système

:Utilisateur

Ces événements système entrants invoquent des opérations système.

L’événement système consulterCommande invoque une opération système appelée consulterCommande() et ainsi de suite.

consulterCommande()


R alisation des cas d utilisation1

Réalisation des cas d’utilisation

Pour chaque cas d’utilisation, on liste toutes les événements système que l’on modélise.

  • en analysant les opérations système

  • en identifiant les classes conceptuelles qui collaborent pour les réaliser

  • en affectant des responsabilités à chacune de ces classes

  • en matérialisant les choix d’affectation des responsabilités dans un diagramme d’interaction


R alisation des cas d utilisation2

Réalisation des cas d’utilisation

  • Les diagrammes d’interactions

    Quelque soit les problèmes de conception, on doit implémenter des méthodes pour les résoudre.

    Pour réaliser ce travail, les diagrammes d’interaction sont indispensables.

    Ils servent à représenter les actions réalisées par les objets en fonction de leurs responsabilités.

    Ces diagrammes sont de deux types:

    • les diagrammes de séquence.

    • les diagrammes de collaboration


R alisation des cas d utilisation3

Réalisation des cas d’utilisation

  • Analyse:

    Une ligne article doit être créée et associée à une spécification produit et à la vente en cours.

    La quantité de la ligne article doit être renseignée.

  • Responsabilité:

    • qui doit créer la ligne article ?

    • qui connaît la spécification d’article à associer à la ligne article ?

    • qui doit transmettre la quantité à la ligne article ?


Techniques de conception

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 conception1

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 conception2

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 conception3

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 conception4

Techniques de conception

Quelques 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

Architecture

L’architecture logicielle et technique


Architecture1

Architecture

L’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.


Architecture2

Architecture

L’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 …


Architecture3

Architecture

La 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.


Architecture4

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

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

Terminaux passifs

Gros système

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


Architecture 2 3

clients

SGBDR

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


Architecture 3 3

Serveur

d’application

clients

Ressources

Architecture 3/3

  • Caracté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


Architecture n 3

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.).


  • Login