I.1.6 Diagramme de classe
Le diagramme de classes est le point central dans un
développement orienté objet. En analyse, il a pour objectif de
décrire la structure des entités manipulées par les
utilisateurs. En conception, le diagramme de classes représente la
structure d'un code orienté. [Roques06]
· Une classe : Représente la
description abstraite d'un ensemble d'objets possédant les mêmes
caractéristiques. On peut parler également de type.
[Roques06]
· Un objet: Est une entité aux
frontières bien définies, possédant une identité et
encapsulant un état et un comportement. Un objet est une instance (ou
occurrence) d'une classe. [Roques06]
· Un attribut : Représente un type
d'information contenu dans une classe. [Roques06]
· Une opération: Représente
un élément de comportement (un service) contenu dans une classe.
[Roques06]
· Une association: Représente une
relation sémantique durable entre deux
classes.[Roques06]
· Une superclasse : Est une classe plus
générale reliée à une ou plusieurs autres classes
plus spécialisées (sous-classes) par une
relation de généralisation. Les
sous-classes« Héritent » des propriétés de leur
superclasse et peuvent comporter des propriétés
spécifiques supplémentaires. [Roques06]
I.I.7 Diagramme de déploiement
Ce diagramme décrit l'architecture technique d'un
système avec une vue centrée sur la répartition des
composants dans la configuration d'exploitation. [JD08]
I.2 Le Processus Unifié I.2.1 Définition
d'UP
Pour définir le processus unifié, nous allons
simplement définir les deux termes qui le composent :
· Processus : Suite continue
d'opérations constituant la manière de fabriquer. En d'autres
termes, c'est une succession de tâches dans le but d'accomplir un
travail, un projet.
· Unifié : Participe
passé du verbe unifié, être amené à
l'unité, se fondre en un tout. En fait, les méthodes d'analyse et
de conception orientées objet, étaient variées
jusqu'à ce que Rambaugh, Jacobson et Booch eut l'idée de les
unifier.
I.2.2 Les principes d'UP
Le processus unifié s'appuie sur les principes suivants
:
> Piloté par les cas d'utilisation :
Comme nous avons déjà vu, un cas d'utilisation
représente une fonctionnalité qui satisfait un besoin d'un
utilisateur.
Le processus suit une voie spécifique, en
procédant par une série d'enchaînement d'activités,
dérivées d'un cas d'utilisation. Un cas d'utilisation est
analysé, conçu, implémenté et enfin
testé.
> Centré sur l'architecture :
L'architecture logicielle représente les aspects statiques et
dynamiques du système. L'architecture émerge des besoins de
l'entreprise, tels qu'ils sont exprimés par les utilisateurs et
reflétés par les cas d'utilisation. L'architecture propose une
vue d'ensemble de la conception faisant ressortir les caractéristiques
essentielles en laissant de côté les détails secondaires.
Il faut noter que tout produit est à la fois forme et fonction. L'une ou
l'autre isolément ne saurait suffire. Les cas d'utilisation et
l'architecture doivent s'équilibrer pour créer un produit
réussi.
> Itératif et incrémental :
Vu que les projets à réaliser sont de plus en plus
complexes et grands, l'idée est de découper le travail en mini
projets. Chacun d'entre eux représente une itération qui donne
lieu à un incrément. Les itérations désignent des
étapes de l'enchaînement d'activités, tandis que les
incréments correspondent à des stades de développement du
produit. [JBR99]
| 
