Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

2Tup

No description
by

AHMED AHMED

on 3 July 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 2Tup

Abbad Badr
Ennaciri Abdelali
Ahmed Alahyane
Zadoussi Hassan
Hambi El mostafa

2012 - 2013
Encadré par:
M . Marzak

PROCESSUS DE DÉVELOPPEMENT LOGICIEL


Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant.

L’objet d’un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles.
Quand intervient la conception préliminaire

La conception préliminaire est avant tout affaire d’organisation ; elle s’appuie
sur les points de vue de spécification fonctionnelle et structurelle de l’analyse,
mais également sur les frameworks de la conception technique. Elle se
termine lorsque la conception est organisée suivant :
• son déploiement cible,
• son modèle d’exploitation,
• son modèle logique.
PROCESSUS UNIFIÉ

Processus Unifié (UP pour Unified Process) est un processus de développement itératif et incrémental.

Il s'agit d'une démarche s'appuyant sur la modélisation UML pour la description de l'architecture du logiciel (fonctionnelle, logicielle et physique) et la mise au point de cas d'utilisation permettant de décrire les besoins et exigences des utilisateurs.

il répond aux caractéristiques suivant :
La Méthode 2tup

2TUP (2 tracks unified process) est un processus de développement logiciel qui implémente le Processus Unifié.

Processus créé par
Valtech

« 2 Track » signifie littéralement que le processus suit deux chemins: « fonctionnels » et « d’architecture technique ».

Pourquoi 2tup ?
La méthode 2tup
Étude préliminaire
Capture des besoins fonctionnels
Capture des besoins techniques
Phase d'analyse
Conception générique
Conception préliminaire
Conception détaillée
Développement du modèle de déploiement

Le déploiement d’une solution client/serveur se construit sur la définition des postes de travail.

Le poste de travail
représente un ou plusieurs acteurs pouvant être localisés sur une machine
Développement du modèle d’exploitation

le modèle d’exploitation va définir les applications installées sur les postes de travail, les composants métier déployés sur les serveurs et les instances de bases de données implantées sur les serveurs également.
DÉFINITION DES APPLICATIONS(Suite
)

L’exemple ci-après illustre la réalisation des cas d’utilisation par des applications, à partir d’un extrait du modèle de spécification fonctionnelle.

Nous avons attribué un nom à chaque application de SIVEx. L’application ConVEx servira aux exemples de conception préliminaire et détaillée. Elle correspond aux fonctions de planification et de contrôle des missions
Énumération des interfaces utilisateur(Suite
)

Il est fort judicieux d’accompagner le développement 2TUP de la définition des IHM
À l’étape de capture des besoins fonctionnels, ceux d’IHM peuvent se transformer en maquettes pour chaque cas d’utilisation
À l’étape d’analyse, au niveau de l’analyse de l’application plus particulièrement, les messages produits ou reçus par les acteurs peuvent être attachés aux vues déjà définies
À l’étape de conception préliminaire, les vues de la maquette sont formalisées et réparties sur les différentes applications du modèle d’exploitation
Développement du modèle logique

Le modèle logique est précisément celui de la représentation des classes organisées en catégories.
ORGANISATION DU MODÈLE LOGIQUE(Suite
)

Le découpage présenté ici correspond à la façon dont les concepteurs
envisagent d’organiser leur conception.
Définir l’interface des catégories

Dans un modèle, l’interface d’une catégorie se présente donc sous la forme
des classes et des interfaces utilisables de l’extérieur de la catégorie
Nous allons illustrer comment apparaissent les interfaces des catégories de conception.
LE DESIGN PATTERN « FAÇADE »
Une façade a pour fonction de produire une classe qui constitue le seul point d’entrée aux services offerts par la catégorie. L’objectif de cette classe est de mieux contrôler les échanges d’une catégorie avec le reste du système et de faciliter le bon usage d’une catégorie.
Organiser la configuration logicielle

A priori, chaque catégorie se transforme en un sous-système de configuration logicielle. Il faut cependant prendre en compte les parties à extraire pour bénéficier de la réutilisation de code. Par exemple, le sous-système de présentation des commandes doit isoler spécifiquement un sous-système regroupant les classes nécessaires à la construction de la fenêtre de recherche et de sélection de commandes.
Quand intervient le développement du modèle dynamique ?

Le développement du modèle dynamique constitue la troisième activité de l’étape d’analyse. Elle se situe sur la branche gauche du cycle en Y. Il s’agit d’une activité itérative, fortement couplée avec l’activité de modélisation statique.
Formaliser les scénarios

En analyse, un scénario représente un ensemble ordonné de messages
échangés par des objets. On parle ici d’objet au sens large : instance de classe d’analyse ou instance d’acteur
Prenons le scénario « Création d’une mission de traction validée »
•le répartiteur donne un nom d’identification et établit la nature de la mission qu’il veut créer. Comme c’est une mission de traction, il doit indiquer une agence principale de destination ;
• le répartiteur affecte les commandes à la nouvelle mission. Le système évalue au fur et à mesure des affectations le tonnage estimé de la mission ;
• le répartiteur affecte un véhicule et un chauffeur à la mission, en fonction du tonnage évalué ;
• le répartiteur valide la mission ; il doit alors préciser l’heure de départ prévue. Le système produit pour sa part une feuille de route.
EXCEPTIONS DANS LE SCÉNARIO(suite)
Construire les diagrammes d’états

DIAGRAMME D’ÉTATS DE LA CLASSE MISSION
Valider les diagrammes d’états avec le diagrammes d’interactions

Nous avons insisté précédemment sur la complémentarité entre :
• les diagrammes d’interaction (séquence ),
• et les diagrammes d’états.
Confronter les modèles statique et dynamique

ILLUSTRATION DES CORRESPONDANCES ENTRE MODÈLES STATIQUE ET DYNAMIQUE SUR LA CLASSE MISSION


Un deuxième exemple va nous permettre d’observer d’autres correspondances
COMPLÉTEZ LES DIAGRAMMES DE CLASSES AVEC LES ATTRIBUTS ET OPÉRATIONS IDENTIFIÉES GRÂCE À L’ANALYSE DYNAMIQUE !(Suite)

Il ne faut pas oublier de mettre à jour les diagrammes de classes, afin de profiter de l’analyse réalisée avec les différents diagrammes dynamiques
Quand intervient la conception générique?

La conception générique consiste à développer la solution qui répond aux spécifications techniques que nous vous avons présentées au chapitre 5.

Cette conception est qualifiée de générique car elle est entièrement indépendante des aspects fonctionnels spécifiés en branche gauche.

La conception générique reste donc une activité de la branche droite.
Quand intervient la conception générique?

La conception générique consiste à développer la solution qui répond aux spécifications techniques

L’architecte technique détermine et structure les besoins techniques suivant les couches du modèle de spécification logicielle

la conception générique permet de formaliser, sous la forme de
classes techniques réutilisables, les règles de conception pour l’ensemble d’un système à développer.
Modèle logique

Les classes, les interfaces et les frameworks techniques représentent les briques de construction d’un modèle logique de conception générique.

Le modèle logique est organisé par packages de classes qui représentent les frameworks développés pour résoudre les problèmes purement techniques

Le modèle logique est donc organisé suivant les dépendances qui s’établissent entre frameworks techniques.
Le modèle d’exploitation
Le modèle d’exploitation montre l’organisation des composants correspondant aux différents frameworks techniques
Il propose une vision statique de l’organisation des éléments physiques logiciels du système
=> élaboration le diagramme de composant (exécutables, librairies, fichier) correspondant aux frameworks techniques
Génération de code

Un générateur de code doit nous permettre d’accéder à toutes les informations du modèle UML et de produire des fichiers qui restituent cette information sous le format de votre choix.

La conception générique consiste à développer le squelette technique d’un projet
=> Implémenter le framework technique
Développement d’un prototype

le prototype valide et prépare les trois niveaux de tests requis à la recette technique du système :

• il inclut le test unitaire des composants techniques
• il prépare les tests d’intégration dans le cadre de la préparation au développement du système complet ;
• il répond aux spécifications techniques

Le prototype valide et termine éventuellement l’étape de conception générique.
Capture des besoins fonctionnels
-La capture des besoins fonctionnels est la
première étape de la branche gauche du cycle enY.
-Elle formalise et détaille ce qui a été ébauché au cours
de l’étude préliminaire.
-Elle décrit les différentes façons qu’auront les
acteurs d’utiliser le futur système.
La capture des besoins fonctionnels est la première étape de la branche gauche du cycle en Y.
Elle formalise et détaille ce qui a été ébauché au cours de l’étude préliminaire.
Elle décrit les différentes façons qu’auront les acteurs d’utiliser le futur système.
-Un cas d’utilisation n’est pas une transaction, ni
une fonction.
-Distinguer l’acteur principal des acteurs
secondaires.
-Nommer les cas d’utilisation avec un verbe à
l’infinitif suivi d’un complément.
-Etablir une première description succincte de
chaque cas d’utilisation candidat.
-Détailler les rôles (principal ou secondaire) et le
sens des associations.
-Ne réinventer pas la décomposition fonctionnelle.
-Limiter à 20 le nombre de vos cas d’utilisation.
-Utiliser le style de description adapté.
-Ne mélanger pas l’IHM et le fonctionnel.
-Compléter les descriptions textuelles avec des
diagrammes dynamiques simples.
-Les relations <<INCLUDE>> entre cas d’utilisation.
-Inclusion: pas de décomposition fonctionnelle.
-Les relations << EXTEND >> entre cas d’utilisation.
-Les relations de généralisation entre cas d’utilisation.
-Vous pouvez aussi généraliser les acteurs.
QU’EST-CE QU’UN PACKAGE?
Un package UML représente un espace de nommage qui peut contenir :
-des éléments d’un modèle.
-des diagrammes qui représentent les éléments du modèle,
-d’autres packages
Identification par responsabilité
-Une responsabilité est une sorte de contrat,
ou d’obligation, pour une classe.
-les attributs, les opérations, et les associations
représentent les propriétés élémentaires qui
contribueront à remplir les responsabilités de la
classe.
Traçabilité
Il faut assurer la traçabilité des cas d’utilisation avec l’expression des besoins.
Se servir des cas d’utilisation pour définir les itérations :
Développement du modèle statique
-constitue la deuxième activité de l’étape d’analyse après
le découpage en catégories.
-Les diagrammes des classes participantes établis et
réorganisés lors du découpage en catégories , vont
être détaillés , complétés, et optimisés.
Affiner les classes
Pour affiner les classes il faut éliminer les :
-classes redondantes.
-classes vagues.
-classes à la place d’attribut.
-classes à la place d’un rôle.
-classes représentant des acteurs.
-classes de conception.
-classes représentant des groupes d’objets.
Affiner les associations
Eliminer les associations incorrectes ou Inutiles :
-associations non structurelles : ce sont les liens
structurels qui se caractérisent par une certaine
durée et une certaine dynamique.
-associations redondantes : elles peuvent être retrouvées
par navigation grâce aux associations existantes.
-Il faut utiliser aussi l’agrégation et la composition.
Ajout des attributs
Eliminer les attributs redondants :
Ajout des attributs
Distinguer les attributs dérivés :
Ajout des attributs
Distinguer les attributs de classe :
Ajout des opérations
Pour ne pas surcharger les diagrammes de
classes il est inutile d’écrire certaines opérations
implicites comme :
-Constructeur et destructeur.
-Getters et setters.
Etude Préliminaire

L’étude préliminaire (ou pré-étude) est la toute première étape de notre processus de développement.

Elle consiste à effectuer un premier repérage des besoins fonctionnels et opérationnels, en utilisant principalement le texte, ou des diagrammes très simples.
Situation de l’étude préliminaire dans 2TUP
Les acteurs candidats sont systématiquement :
• les utilisateurs humains directs : identifiez
tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance,
etc. ;
• les autres systèmes connexes qui interagissent
aussi directement avec les système.
Identification des acteurs
Un message représente la spécification d’une
communication unidirectionnelle entre objets
qui transporte de l’information avec l’intention
de déclencher une activité chez le récepteur.
Identifier les messages
Modéliser le contexte
Tous les messages (système acteurs) identifiés peuvent être représentés de façon synthétique sur un diagramme, que l’on peut qualifier de diagramme de contexte dynamique.
• le système étudié est représenté par un participant central ;
• ce participant central est entouré par d’autres participants
symbolisant les différents acteurs ;
• des liens relient le système à chacun des acteurs ;
• sur chaque lien sont montrés les messages en entrée et en
sortie du système, sans numérotation.
Exemple de diagramme de contexte
Découpage en catégories
C’est la première activité de l’étape d’analyseObjectifs:
Organiser les équipes d’analystes, puisqu’elles vont pouvoir travailler sur des ensembles cohérents et faiblement couplés assure l’évolutivité et la facilité de maintenance, et favoriser la réutilisation, en séparant notamment les parties applicatives des parties métiers.
Exemple de découpage en catégorie
Importance de découplage en catégorie
Diagramme de classe préliminaire(ex)
Dépendance entre catégories
CONCLUSION
Plan
Le modèle de configuration logicielle

Organiser et préciser la configuration en indiquant les dépendances entre composants


Identifier les sous-ensembles(sous-système) pouvant se fabriquer et s’utiliser indépendamment les uns des autres
Introduction
Full transcript