From All4Dev

Contents 1 Processus 2TUP 2 Processus incrémental 3 Processus pilotés par les exigenes les utilisateurs 4 Modélisation 5 Diagrammes UML 5.1 Diagrammes des cas d'utilisation (statique) 5.2 Diagrammes de classes (statique) 5.3 Diagrammes d'objets (statique) 5.4 Diagrammes de composants (statique) 5.5 Diagrammes de dépoiement (statique) 5.6 Diagrammes d'états (dynamique) 5.7 Diagrammes d'activité (dynamique) 5.8 Diagrammes de collaboration et de séquence (dynamiques) 6 Processus itératif 7 Les points de vue de modélisation 7.1 Spécifications fonctionnelle 7.2 Structurel 7.3 Matériel 7.4 Déploiement 7.5 Exploitation 7.6 Spécification logicielle 7.7 Point de vue logique 7.8 Configuration logicielle 7.9 Remarques 8 Un processus centré sur l'architecture 8.1 Définition 8.2 Axe de solutions génériques 8.3 Avantages d'un processus centré sur l'architecture 9 Processus orienté Composants 10 Conclusion

Processus 2TUP

L'idée est de séparer les contraintes fonctionnelles des contraintes techniques, sous la forme de deux branches.

La branche fonctionnelle comporte:

• capture des besoins fonctionnelles,
• analyse fonctionnel du système à produire en terme métier, indépendament de la techno.

La branche architecture technique:

• capture des besoins techniques:
  • recencement des contraintes,
  • dimensionnement.
• conception générique:
  • définition des composants
  • prototype

Ces deux branches se réunissent dans les phases:

• Conception préliminaire
• Conception détaillée
• Codage et test
• Recette

Image:Y dev process.png

Processus incrémental

1. validation fonctionnelle: validation du principe du système
2. validation technique: focalisation sur architecture: prototype
3. réalisation des fonctions les plus propriétaire
4. finition

Processus pilotés par les exigenes les utilisateurs

• branche fonctionnelle
  • cas d'utilisation sur les plus value métiers des fonctions du système
  • classes d'analyse avec les concepts des utilisateurs
• branche technique
  • cas d'utilisation techniques pour spécifier l'architecture
  • décomposition en couches logicielles
  • conception des classes

Modélisation

Le modèle évolue en fonction de l'étape on l'on est:

• capture des besoins: le système est considéré comme une boîte noire
• analyse: on représente le système vu de l'intérieur
• conception: on modélise en utilisant:
  • outils
  • langage
  • plateforme de développement

Diagrammes UML

Diagrammes des cas d'utilisation (statique)

• représente la structure des fonctionnalités nécessaires aux utilisateurs du système
• utilisés dans
  • capture des besoins fonctionnels
  • capture des besoins techniques

Diagrammes de classes (statique)

• branche fonctionnelle: développe la structure des entités connues des utilisateurs
• conception: représente
  • la structure d'un code OO
  • module du langage de dev

Diagrammes d'objets (statique)

• illustre la structure des classes
• en analyse, vérifie l'adéquation d'un diagramme des classes aux différents cas possible

Diagrammes de composants (statique)

• représentation des concepts pour installation et maintenance du système,
  • détermination de la structure des composants:
    • librairies dynamiques
    • instances de base de données
    • applications
    • progiciels
    • objet distribués
    • exécutables
• représentation des concepts de configuration logicielle
  • agencement des composants
    • fichiers sources
    • packages
    • librairies

Diagrammes de dépoiement (statique)

• structure du réseau informatique
• installation des composant informatique

Diagrammes d'états (dynamique)

• représentent le cycle de vie des objet d'une classe
• utilisés en analyse, dans le développement du modèle dynamique
• utilisés en conception, dans la phase conception détaillée (aka étude détaillée)

Diagrammes d'activité (dynamique)

• régles d'enchainement des activités du système
  • consolidation des spécification d'un cas d'utilisation (phase capture des besoins fonctionnels)
  • conception d'une méthode (phase conception détaillée - aka étude détaillée)

Diagrammes de collaboration et de séquence (dynamiques)

• diagrammes d'interraction
• représentent les échanges de messages entre objets, pour une fonction donnée du système
• les diagrammes de collaboration
  • modèlisent le contexte du système (en étude préliminaire)
  • aide la conceptin des méthode (en conception détaillée)
• les diagrammes de séquence développent en analyse les scénarios d'utilisation (en phase du développpement du modèle dynamique)

Processus itératif

Avancement par étapes successives, de plus en plus détaillée, en se basant sur l'étape précédente. Le volume d'information grossit à chaque étape.

• Capture des besoins fonctionnels:
  • niveau du contexte: définition de la frontière fonctionnelle entre le système, considéré comme boîte noire, et son environnement
  • niveau des cas d'utilisation: définition des activité de chaque utilisateur par rapport au système toujours considéré comme boîte noire

• Pour l'analyse:
  • Modèle d'analyse du domaine: définition de la structure et du comportement des objets connus dans le "métier" des utilisateurs, qui définissent le système;
  • Modèle d'analyse de l'application: on ajoute des objets nécessaires pour répondre aux besoins.

• Pour la capture des besoins techniques, le modèle d'analyse:
  • établit les couches logicielles
  • spécifie les activités techniques attendues

• Pour la conception générique, le modèle de conception générique:
  • définit les composants qui répondent aux exigences opérationnelles du système

• Pour la conception préliminaire, le modèle de conception système:
  • organise le système en composants
  • ce modèle fait le lien entre les couches logicielles, produites pendant la capture des besoins techniques, et les classes décrites pendant l'analyse.

• Pour la conception des classes
  • utilisation du modèle de conception des composants

Utilisation éventuelle au préalable d'un modèle métier.

Les points de vue de modélisation

Image:Model.png

Spécifications fonctionnelle

• besoins fonctionnels exprimés par les utilisateurs
• éléments:
  • cas d'utilisation organisé en packages
  • acteurs
  • activités
  • interractions entre objets
  • contraintes dynamiques

Structurel

• besoins élaborés en classes
• éléments:
  • catégories
  • classes
  • associations
  • généralisations
  • attributs
  • contraintes structurelles

Matériel

• structure physique des machines et réseau
• prévoir le dimensionnement des processeurs et des bandes passantes
• concerne les ingénieurs système et réseau
• éléments:
  • noeuds
  • connexion

Déploiement

• concerne l'ingénieur d'exploitation chargé d'installer le système
• éléments
  • postes de travail
  • serveurs
  • connexions
  • composants qui permettent d'étudier les échanges internes/externes

Exploitation

• organisation des composants
• concerne
  • les ingénieurs d'exploitation (trouver une panne)
  • les concepteurs (recherche de dépendance logicielle)
• éléments:
  • composants
  • interfaces
  • dépendances entre composants

Spécification logicielle

• répartition par couches des exigences techniques
• dissocier par nature de responsabilités
• éléments:
  • cas d'utilisation technique
  • exploitants
  • activité
  • interactions entre objets
  • contraintes dynamique
• utilisation de couches réparties en responsabilités:
  • de présentation
  • gestion des applications
  • gestion du métier
  • d'accès aux données
  • stockage des données

Point de vue logique

• organisation du modèle de solution
• élaboré en classes
• éléments:
  • classes regroupées en catégories
  • interfaces
  • associations
  • généralisations
  • réalisations
  • attributs
  • états
  • opérations
  • méthodes
• vision prêt à coder
• documente le code produit

Configuration logicielle

• retrace la construction des composants
• mesure l'impact d'un changement
• établi les configurations et les compatibilités entre les

versions des composants

• éléments
  • sous-système
  • composants de construction
  • dépendance de fabrication

Remarques

• La spécification fonctionnelle réalise le point de vues des utilisateurs. Elle conditionne les points de vue structurelle et logique, le déploiement de la conception système:
  • les cas d'utilisation permettent de trouver les classes de la vue structurelle du modèle d'analyse
  • les scénarios élaborés par cas d'utilisation permettent de trouver les opérations des interfaces de la vue logique du modèle de conception système
  • les cas d'utilisation identifie les fonctions qu'il faut répartir sur le déploiement du modèle de conception système.
• La spécification logicielle se place du point de vue des exploitants:
  • les cas d'utilisation techniques permettent de trouver les classesde la vue logique du modèle de conception technique
  • les cas d'utilisation techniques identifient les fonctions d'exploitation qu'il faut répartir surt le déploiement du modèle de conception/
• La vue matérielle: support du déploiement
• La vue structurelle: projette ses classes dans la vue logique au niveau de la conception système
• La vue d'exploitation: définit ses composants à partir
  • des interfaces de la vue logique du modèle de conception technique
  • des composants de déploiement
• La vue de configuration dépend des classes du modèle logique

TODO: faire tableau

Un processus centré sur l'architecture

Définition

Architecture: Ensemble des décisions d'organisation du système logiciel qui défend les intérêts de son propriétaire final. Les intérêts s'expriment en termes de:

• d'exigences fonctionnelles;
• d'exigences techniques;
• d'exigences économiques.

Axe de solutions génériques

Architecture client/serveur en tiers

• capacité de montée en charge
• 2-tiers: nombre limité d'utilisateur
• 3-tiers/n-tiers: évolution du nombre d'utilisateurs par introduction d'un middleware

Architecture en couche

• distributions des responsabilités
• exemple à 5 couches
  • présentation
  • application
  • métier
  • accès aux données
  • stockage
• évolution et maintenance technique aisée

Architecture en niveaux

• déploiement des fonctions sur les postes de travail
• trois niveaux pour l'entreprise
  • central
  • départemental
  • local
• contrôle de l'imbrication des fonctions du sytème
• évolution et maintenance fonctionnelle aisée

Architecture en composant

• opportunités de ré-utilisation
• nécessite une définition stricte de la décomposition modulaire

Avantages d'un processus centré sur l'architecture

L'architecture implique des décisions d'organisation qui se répercutent sur la structure du modèle. Les différents points de vue de modèlisation deviennent des outils de contrôle de l'architecte logiciel.

TODO: tableau

• impose le respect des décisions d'architecture à chaque étape
• condition à l'intégrité d'un projet complexe car
  • structure et...
  • ...rends cohérent les points de vue
• facilite la répartition du travail
• la documentation apportée par les modèles facilite les textes, l'intégration, aide à identifier les sources d'erreurs.

Processus orienté Composants

• respect des règles d'architecture
• structuration du modèle à toutes les étapes

tendent naturellement à

• regrouper les concepts à forte cohérence
• identifier les couplages entre parties

L'expression des couplages implique:

• spécification des règles d'interface,
• opportunités de réutiliser les regroupements de concepts à d'autres concepts de développement.

Les regroupements de concepts définissent des packages de composants dans le modèle.

Capture des besoins Les cas d'utilisation sont regroupés en package pour organiser le modèle de spécification fonctionnel. Ces packages :

• représentent les besoins d'un métier;
• structurent la répartition en applications du système

Pendant l'analyse Les classes sont regroupés en catégories pour organiser:

• modèle d'analyse métier
• modèle d'analyse de l'application

Les catégories métier

• représentent la description détaillée des concepts de l'entreprise
• constituent des références réutilisables

Les catégories d'analyse

• structurent les catégories de conception
• structurent la répartition en composant métier

Capture des besoins techniques

• Les cas d'utilisation sont regroupés en couches logicielles...
• ...pour organiser le modèle de spécification technique.
• Les couches logicielles structurent la création d'un framework technique.

Pendant conception technique

• Les classes sont regroupés en framework...
• ...qui organisent les classes répondant à des fonctions techniques spécifiques.

Les frameworks:

• fournissent des services directement utilisable par la conception
• constituent éventuellement des composants du modèle d'exploitation

Les frameworks abstraits structurent les classes de conception détaillée et participent au modèle de configuration logicielle.

Pendant conception détaillée Les classes sont organisée en catégories. Les catégories de conception

• constituent éventuellement des composants du modèle d'exploitation
• structurent le sous-système de configuration logicielle

Les composants d'exploitation Éléments déployer pour installer le système:

• instances de base de données
• applications à disposition des utilisateurs
• librairies dynamiques
• objets distribués
• java beans

TODO: rajouter schéma

Conclusion

Les Processus Unifiés (UP):

• itératif
• incrémental
• centré sur l'architecture
• conduit par exigences utilisateurs
• piloté par les risques
• orienté composants

TODO: rajouter schéma

Le processus 2TUP insiste en plus sur la non corrélation entre les aspects fonctionnels et les aspects techniques.

---

UML en action

---