jeudi 10 avril 2008

En conception

Une image bien faite , vaut mieux qu'un long discours

--
Alain Lompo
Excelta - Conseils et services informatiques
MCT
MCSD For Microsoft .Net
MVP Windows Systems Server / Biztalk Server
Certifié ITIL et Microsoft Biztalk Server

lundi 31 mars 2008

Ce document a pour objectif de décrire l’architecture technique de la solution proposée dans le cadre du projet de professionnalisation « Plate forme .Net ». Il s’agit d’une solution de gestion de la planification basé sur le modèle de fonctionnement d’une EFPP
1.1.1. Objectif d’une conception d’application distribuée

Lorsqu’on conçoit une application distribuée, il faudra faire des choix particuliers concernant son architecture logique et physique ainsi que les technologies et infrastructures utilisées pour implémenter ses fonctionnalités. Afin de prendre ces décisions de façon effective, il faut avoir une compréhension claire des processus métiers que l’application réalisera (ses spécifications fonctionnelles), ainsi que le niveau d’échelonnabilité, de disponibilité, la sécurisation, la maintenabilité exigée (les spécifications non fonctionnelles et les spécifications opérationnelles).
Notre objectif au travers ce document est donc :
Concevoir une application qui solutionne la problématique métier adressée : la gestion de la planification au sein des EFPP
Prendre en compte les considérations de sécurité nécessaires pour implémenter les mécanismes adéquats d’authentification, la logique d’autorisation ainsi que la communication sécurisée.
D’effectuer la conception nécessaire pour l’obtention d’un haut niveau de performance ainsi qu’un modèle de développement et de déploiement optimisé
Concevoir une architecture de solution échelonnable de façon à ce que la solution puisse supporter un grand nombre d’activités et d’utiliser avec un usage minimaliste des ressources.
Concevoir une architecture d’une solution concevable, gérable et mesure de façon à pouvoir gérer les problèmes éventuels qui surviendraient lors de l’utilisation de l’application
Concevoir une architecture de solution maintenable dans laquelle chaque unité fonctionnelle ait un emplacement prédictible ainsi qu’une conception qui prend en compte divers types d’applications, et des spécifications métier et techniques changeantes



1.1.2. Services et intégration de service

L’approche service s’est rapidement impose par le fait qu’elle propose au processus métier de s’affranchir aisément des frontières physiques des entreprises dans lesquelles ils sont consommés.
Du point de vue du consommateur du service, ce dernier est semblable à un composant traditionnel, excepté le fait qu’ils encapsulent leurs propres données et que d’un point de vue stricte ils ne font pas partie de notre application.
Du fait que les applications et les services qui les consomment sont généralement définis, développés, maintenus et mis à jours de façon indépendante les uns des autres, il est donc important que le couplage entre les deux soit aussi faible que possible.

Il est recommandé d’implémenter la communication entre services en utilisant la technique basée sur les messages afin d’assurer un haut niveau de robustesse et d’échelonabilité. Vous pouvez mettre en place une communication par message de façon très explicite (par exemple en écrivant du code pour MSMQ), ou vous pouvez utiliser des composants d’infrastructure qui gèrent la communication implicitement pour vous (par exemple les proxys générés par Visual Studio .Net).
Le principe d’utilisation d’un service est le suivant : un service expose une interface qui définit le contrat d’utilisation des méthodes que le service met à votre disposition, c’est – à – dire que chaque méthode du service définit son mode d’appel, ses paramètres ainsi que sa valeur de retour : on parle de signature de la méthode.

1.1.3. Composants et tiers dans les applications et services

Les composants sont utilisés pour décomposer chaque couche en éléments cohérents et logiques. On admet généralement un empilement des couches dans le sens Présentation à Données en passant par la couche des services.

Le schémas présenté sur la page suivante illustre l’architecture multitiere adoptée pour cette solution.

Diagrammes de conception

1. Les diagrammes de conception
Pour améliorer encore notre diagramme de classes et le préparer à la production du code, nous cesserons de considérer le système comme une boîte fermée et décrirons plus précisément les interactions survenant entre les différentes classes identifiées précédemment - soit les dialogues, les contrôles et les entités.
Nous isolerons un cas d'utilisation particulier pour illustrer certains aspects complexes de l'application. Prenons le cas d'un utilisateur qui effectue une recherche intermédiaire par auteur. Un premier diagramme de séquences illustre ce cas d'utilisation :








Nous ajoutons maintenant au diagramme de séquences les instances de classe d'objet intervenant dans le système. Continuons à identifier les messages pour l'obtention de la fiche détaillée d'un document choisi dans la page de résultats.

Ce diagramme nous permet maintenant d'identifier quelques nouveaux messages. Ceux-ci nous permettront d'attribuer aux bonnes classes les bonnes opérations.
Typer les attributs
Retournons à notre diagramme de classes et ajoutons des types aux attributs, ainsi qu'aux paramètres et aux retours des opérations.
En considérant pour illustration le langage ActionScript 2.0, le typage s'effectue ainsi :
// pour un attribut
propriété:Type
// pour une opération, avec un argument et un renvoi
operation(parametre:Type):TypeRenvoi
Lorsqu'aucun renvoi n'existe pour une opération, on indiquera le type Void. Ce sera généralement le cas.
Préciser la visibilité
Un concept fondamental de l'orienté objet est l'encapsulation - le fait de garder des informations cachées à l'intérieur de l'objet.
On pourra aussi indiquer à cette étape quels attributs ou méthodes sont privées ou publiques en faisant précéder l'attribut ou la méthode du signe + (pour public) ou - (pour privé).
Règle générale, tous les attributs devraient être privés, à moins d'avoir une excellente raison - ce qui est rarement le cas. On privilégiera plutôt l'utilisation des accesseurs (getter / setter) servant à fournir ou à modifier les valeurs d'attributs.



Diagramme de classe de conception
1.1.1. Conception objet et passage au code - diagrammes d’interaction et classe
Création de diagrammes d’interactionCréation de diagrammes de classe
Dernière étape avant l’écriture du code. On affine et on applique les trois derniers diagrammes au langage utilisé ainsi que la notation des attributs et des opérations.
En utilisant le langage orienté objet PHP par exemple, certaines pages deviennent à la fois dialogues et contrôles comme par exemple la page panier.php qui accède directement à l’entité panier
1.1.1. Modélisation préliminaire objet interaction du système technique ULM : diagrammes d’interaction (séquence et ou collaboration) et diagrammes de classes

Création de diagrammes d’interaction (séquence ou collaboration) Création de diagrammes de classe
Dans les diagrammes de séquences système on confrontait l’acteur au système dans sa globalité. Dans cette étape on va détailler le système décrit par nos classes participantes et compléter le diagramme de séquence système. Chaque classe devient un objet du système symbolisé comme pour les diagrammes de classes participantes.On détaille les séquences du Scénario au sein du système, d’objet à objet.Un objet pourra s’envoyer un message à lui-même comme le cas pour la vérification de syntaxe effectué par l’objet recherche avancé.Un objet pourra crée un autre objet comme le cas pour le catalogue qui crée un objet résultat.

Le diagramme de collaboration est la même description écrite d’une manière différente. Chaque séquence est annotée avec son chiffre d’apparition dans le Scénario puisque ce diagramme n’exprime pas le temps.
A cette étape on crée des diagrammes de classes de conception préliminaires ou l’on rajoute en fonction des précédents diagrammes de séquences essentiellement des attributs ou des opérations. Par exemple verifierSyntaxeRecherche (phrase) à la classe dialogue RechercheAvancée.
De plus on peut déjà ajouter le type de chaque attribut de classe par exemple : chercherLivre : string
1.1.1. Modélisation de la navigation - technique UML : diagrammes d’activités
Création de diagrammes d’activités
En fonction de l’interface (maquette) et des diagrammes de classes participantes (et d’autres) on modélise un diagramme d’activité. Un diagramme d’activité est un diagramme dynamique qui a un début, une ou des fins et une ou des fins anormales. Chaque activité est reliée à une autre ou a une condition (symbolisé par un losange). Pour le WEB on va ajouter des conventions :La page :la frame a l’intérieur d’une page L’exception : erreur ou comportement inattendu du système

Pour la réalisation de ce diagramme on commence par l’acteur (ex l’internaute) qui arrive sur une page donnée (ex : Page d’accueil). Ensuite on détaille le parcourt de page en page :
De la page d’accueil l’internaute choisi le frame recherche rapide (présente sur la page d’accueil) ou va vers la page de recherche avancée. L’une ou l’autre recherche est une action « recherche » qui va (condition), soit se concrétiser par un résultat écrit sur un frame, soit échouer (pas de livre correspondant) et va proposer un retour à la page d’accueil. Il faudra penser à réaliser ce type de schémas sur un tableau.
On peut donner résumer ensuite un modèle global pour un ensemble de cas d’utilisations sans donner compte des fins anormales ou des conditions.
1.1.1. Classes participantes - technique UML pour les diagrammes de classe
Création de diagrammes de classe participante
Dans cette partie le but est de trouver les classes de l’interface IHM = maquette ( les classe les dialogues ) et celles qui décrivent la cinématique de l’application ( les classes contrôles ) et de les associer à nos classes métier trouvées auparavant. Par exemple pour le développement d’un site Web, les classes dialogues font la liaison entre l’utilisateur et le site WEB : elles vont recevoir en plus des attributs (qui représentent les champs de saisie) des opérations (qui représentent les actions d’utilisateur).
Les classes contrôles font la transition entre les dialogues et les classes métiers : Elles n’auront pas d’attributs, mais seulement des opérations qui montre les comportements du système informatique.
Les classes métier garderont seulement leurs attributs.
A noter que les associations sont unidirectionnelles.
Par exemple pour la recherche d’ouvrage. On va ajouter les classes dialogues ; écran de recherche rapide et recherche avancée et résultat de recherche. Leur associer une classe contrôle (contrôle recherche) pour les lier a nos classes métier (catalogue)

Nouveautés UML 2.0

1.1. Nouveautés introduites par UML 2.0
Cette section présente les nouveautés UML2.0 en ce qui concerne le diagramme de classes et le diagramme d'architecture. Le diagramme d'architecture,aussi appelé diagramme structure composite, est un tout nouveau diagramme introduit par le standard UML2.0.
Cette section regroupe les deux diagrammes car certains concepts peuvent être utilisés dans les deux diagrammes. Les notions abordées dans cet article sur les nouveautés UML2.0 sont principalement les ports, les interfaces, les connecteurs, les parts.

Avant de présenter les nouveaux concepts de ces deux diagrammes (classe, architecture), voyons quelques rappels.
1.1.1. Diagramme de classes
Un diagramme de classes donne une vue statique du système/logiciel. Il décrit les types et les objets du système/logiciel. Typiquement il met en relation des classes mais aussi des interfaces, des types de données, des types énumérés...
Une classe
Une classe représente une entité, un groupe d'objets, qui partagent des
propriétés (attributs), un comportement (méthodes), une structure et des interfaces communes. Une classe est instanciée pour créer un objet en particulier. Exemple classique : La classe Homme est instanciée en Adam. La classe Femme est instanciée en Eve.

Signaux

Un signal est un type de message pouvant être échangé entre deux objets. Il se distingue du concept d'opération : en effet, le signal est asynchrone. Un signal peut transporter des données : ces données sont spécifiées au moyen des paramètres du signal.Le signal dispose donc de deux caractéristiques : son nom, ses attributs (ou paramètres).

Déclaration

Le signal est déclaré de la même manière qu'une opération, une classe, une interface. Sa déclaration se fait dans un diagramme de classe au moyen d'un symbole Classe stéréotypé "signal". Selon les outils, il pourra également être déclaré textuellement.Les signaux peuvent être regroupés (non obligatoire) dans des Interfaces. Dans ce cas, leur nom est préfixé par le nom de l'interface (dans la représentation sous forme de classe). Cette construction permet d'une part d'augmenter la lisibilité des diagrammes et d'autre part de spécifier les interfaces des classes.Déclaration du signal ordre :

Déclaration du signal estOK qui transporte une donnée booléenne :

Exemple de possibilité de déclaration textuelle :

Signaux faisant partie de l'interface IDemander:




Utilisation

Les signaux sont utilisés pour représenter les événements asynchrones. L'objet expéditeur n'est alors pas bloqué dans son flot d'exécution sur un retour du destinataire. Au contraire, l'objet expéditeur continue son activité.

Les signaux sont utilisés dans :

- les diagrammes de séquences : pour représenter les interactions dynamiques entre objets,
- les diagrammes de classes : pour les déclarations et au travers des interfaces et des ports,
- les diagrammes d'architecture : pour représenter les interconnexions entre les instances de classe,
- les diagrammes d'états : pour représenter les déclencheurs de transitions.


Port

Un port permet de spécifier les points d'intéractions d'un objet : soit entre l'objet et son environnement, soit entre l'objet et sa décomposition interne. Les ports sont reliés au moyen de connecteurs sur lesquels transitent les messages permettant de déclencher le comportement des objets.Un port indique les interfaces proposées par l'objet (realized) ainsi que les interfaces requises (required). De manière simplifiée, on peut dire que les interfaces "realized" sont des ENTREES (in) alors que les interfaces "required" sont des SORTIES.
Les ports sont typiquement indiqués sur les classes actives.

Déclaration

Un port est déclaré sur une classe, en général, sur une classe active.
Il porte un nom. Il existe deux types de ports : les ports dits "protocole" et les ports dits "comportementaux".- Un port comportemental (Behaviour port) est directement associé à la machine à étatq de la classe active qui porte ce port. Tous les messages envoyés sur ce port sont consommés par la machine à étatq de la classe.

Notation d'un port comportemental :

- Un port protocole (Protocol port) sert à décrire la connectique interne et externe de la classe.

Notation d'un port protocole :


2.2. Utilisation

Les ports apparaissent essentiellement dans les diagrammes de classes et d'architecture. Un port peut être placé sur : - une classe - un part - sur le pourtour (frame) d'un diagramme d'état d'une classe active - sur le pourtour (frame) d'un diagramme d'architecture

Port protocole

Dans le schéma ci-dessous, le port client est typiquement un port protocole. En effet, il traduit le point d'entrée dans le système automateBillet pour les interfaces Client et comment ce point d'entrée se distribue sur les composants de l'automateBillet. Il n'a aucune signification comportementale (d'autant plus que la classe active AutomateBillet ne contient pas de diagramme d'état).

Premier niveau d'architecture : Notez que les ports n'ont pas forcément besoin d'être reliés par des connecteurs. Dès l'instant où deux ports se complètent, "s'emboîtent", l'outil considère qu'ils sont connectés.





Décomposition de la classe active AutomateBillet : Notez l'utilisation conjointe des notations avec/sans connecteurs.


Port comportemental

Dans le schéma ci-dessous, le port DAB de la classe active Client est un port comportemental. Il traduit le point d'entrée de la classe, mais surtout indique que les interactions font vivre la machine à états qui décrit le comportement typique d'un client de distributeur automatique. La classe Client contient la description d'une machine à états.

Utilisation d'un port comportemental :

Hierarchie du modèle : machine à états


Parts (ou Partie ?)

Un Part (appelons-le ainsi en attendant une traduction adéquate) désigne une ou plusieurs instances qui compose(nt) une classe.

Déclaration

Un part est une instanciation d'une classe. Le terme de "déclaration" ne s'applique donc pas vraiment à un part.Un part est représenté dans un diagramme d'architecture (nouveau diagramme proposé par UML2.0). Ce diagramme est également appelé diagramme structure composite.
Un part représente une ou plusieurs instances d'une classe grâce à des contraintes de multiplicité. Les multiplicités sont importantes à préciser d'abord dans un but descriptif mais également pour avoir une simulation réaliste lorsque l'outil propose la fonctionnalité de simulation du modèle. Un part est considéré comme un attribut de la classe active qui le contient.Ci-dessous l'exemple d'un part sans multiplicité. Dans ce cas, l'objet est construit dès que le part est construit.

Ci-dessous l'exemple d'un part avec multiplicité. La multiplicité s'exprime ainsi [ cardinalité_minimale..cardinalité_maximale ] / cardinalité_initiale. La cardinalité initiale représente le nombre d'instances créées automatiquement lors de la création de la classe contenant le part.

Exemple de Part - DAB est une instance de la classe active AutomateBillet :

Ci-dessous l'exemple d'une classe active contenant des parts :


Utilisation

Les parts sont représentés dans les diagrammes d'architecture. Ils décrivent comment est stucturée une classe ainsi que les connexions entre les parts composants. Ils peuvent porter des ports reliés par des connecteurs.


Connecteur

Les connecteurs sont identifiés comme un nouveau concept. Mais cela peut facilement s'apparenter aux associations.
Ils indiquent un lien, une communication entre deux parts (au contraire des associations qui relient des classes).

Déclaration

Les connecteurs relient des parts : ils sont donc rattachés à la notion de diagramme d'architecture. Les connecteurs font transiter les messages, par exemple les signaux. Les connecteurs portent des noms.


Exemple

Dans le diagramme ci-dessus illustrant l'utilisation des parts, on identifie aff2ver et cai2ver comme connecteurs.

Autres éléments

1.1.1. Composition

La composition, également appelée agrégation composite, décrit une contenance structurelle entre
instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants. Une
instance de la partie appartient toujours à au plus une instance de l’élément composite. Graphiquement, on ajoute un losange plein (_) du côté de l’agrégat.
Dépendance





Une dépendance est une relation unidirectionnelle exprimant une dépendance sémantique entre les
éléments du modèle. Elle est représentée par un trait discontinu orienté. Elle indique que la modification de la cible implique une modification de la source. La dépendance est souvent
stéréotypée pour mieux expliciter le lien sémantique entre les éléments du modèle

Interfaces
Les classes permettent de définir en même temps un objet et son interface. Le classeur, que nous décrivons dans cette section, ne permet de définir que des éléments d’interface. Il peut s’agir de l’interface complète d’un objet, ou simplement d’une partie d’interface qui sera commune à plusieurs objets.
Le rôle de ce classeur, stéréotypé « interface », est de regrouper un ensemble de propriétés et d’opérations assurant un service cohérent.
Une interface est représentée comme une classe excepté l’absence du mot-clef abstract (car l’interface et toutes ses méthodes sont, par définition, abstraites) et l’ajout du stéréotype « interface ».

Une interface doit être réalisée par au moins une classe. Graphiquement, cela est représenté par un
trait discontinu terminé par une flèche triangulaire et le stéréotype « realize ». Une classe (classe cliente de l’interface) peut dépendre d’une interface (interface requise).

On représente cela par une relation de dépendance et le stéréotype « use ».


















Élaboration d’un diagramme de classes
Il y a au moins trois points de vue qui guident la modélisation (Steve Cook et John Daniels) :
– Le point de vue spécification met l’accent sur les interfaces des classes plutôt que sur leurs contenus.
– Le point de vue conceptuel capture les concepts du domaine et les liens qui les lient. Il s’intéresse
peu ou prou à la manière éventuelle d’implémenter ces concepts et relations et aux langages
d’implémentation.
– Le point de vue implémentation, le plus courant, détaille le contenu et l’implémentation de chaque
classe.
En fonction du point de vue adopté, vous obtiendrez des modèles différents. Une démarche couramment utilisée pour bâtir un diagramme de classes consiste à :
Trouver les classes du domaine étudié. Cette étape empirique se fait généralement en collaboration avec un expert du domaine. Les classes correspondent généralement à des concepts ou des substantifs du domaine.
Trouver les associations entre classes. Les associations correspondent souvent à des verbes, ou des constructions verbales, mettant en relation plusieurs classes, comme « est composé de », « pilote », « travaille pour ». Attention, méfiez vous de certains attributs qui sont en réalité des relations entre classes.
Trouver les attributs des classes. Les attributs correspondent souvent à des substantifs, ou des groupes nominaux, tels que « la masse d’une voiture » ou « le montant d’une transaction ». Les adjectifs et les valeurs correspondent souvent à des valeurs d’attributs. Vous pouvez ajouter des attributs à toutes les étapes du cycle de vie d’un projet (implémentation comprise). N’espérez pas trouver tous les attributs dès la construction du diagramme de classes.
Organiser et simplifier le modèle en éliminant les classes redondantes et en utilisant l’héritage.
Vérifier les chemins d’accès aux classes.
Itérer et raffiner le modèle. Un modèle est rarement correct dès sa première construction. La modélisation objet est un processus non pas linéaire mais itératif.

Diagramme d’objets (object diagram)

Présentation
Un diagramme d’objets représente des objets (i.e. instances de classes) et leurs liens (i.e. instances de relations) pour donner une vue de l’état du système à un instant donné. Un diagramme d’objets permet, selon les situations, d’illustrer le modèle de classes (en montrant un exemple qui explique le modèle), de préciser certains aspects du système (en mettant en évidence des détails imperceptibles dans le diagramme de classes), d’exprimer une exception (en modélisant des cas particuliers, des connaissances non généralisables . . .), ou de prendre une image (snapshot) d’un système à un moment donné. Le diagramme de classes modélise les règles et le diagramme d’objets modélise des faits.




Par exemple, le diagramme de classes de la précédente montre qu’une entreprise emploie au moins
deux personnes et qu’une personne travaille dans au plus deux entreprises. Le diagramme d’objets
modélise lui une entreprise particulière (OSKAD) qui emploie trois personnes.
Un diagramme d’objets ne montre pas l’évolution du système dans le temps. Pour représenter une
interaction, il faut utiliser un diagramme de communication ou de séquence.

Représentation

Graphiquement, un objet se représente comme une classe. Cependant, le compartiment des opérations n’est pas utile. De plus, le nom de la classe dont l’objet est une instance est précédé d’un « : » et est souligné. Pour différencier les objets d’une même classe, leur identifiant peut être ajouté devant le nom de la classe.
Enfin les attributs reçoivent des valeurs. Quand certaines valeurs d’attribut d’un objet ne sont pas renseignées, on dit que l’objet est partiellement défini.

Dans un diagrammes d’objets, les relations du diagramme de classes deviennent des liens.



Graphiquement,
un lien se représente comme






La relation de dépendance d’instanciation (stéréotypée « instanceof ») décrit la relation entre un
classeur et ses instances. Elle relie, en particulier, les liens aux associations et les objets aux classes.


1.1. Diagramme de classe d’analyse

1.1.1. Diagrammes de classe

Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation. Alors que le diagramme de cas d’utilisation montre un système du point de vue des acteurs, le diagramme de classes en montre la structure interne. Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation. Il est important de noter qu’un même objet peut très bien intervenir dans la réalisation de plusieurs cas d’utilisation.

Les cas d’utilisation ne réalisent donc pas une partition1 des classes du diagramme de classes. Un diagramme de classes n’est donc pas adapté (sauf cas particulier) pour détailler, décomposer, ou illustrer la réalisation d’un cas d’utilisation particulier.

Il s’agit d’une vue statique car on ne tient pas compte du facteur temporel dans le comportement du système. Le diagramme de classes modélise les concepts du domaine d’application ainsi que les concepts internes créés de toutes pièces dans le cadre de l’implémentation d’une application. Chaque langage de Programmation Orienté Objets donne un moyen spécifique d’implémenter le paradigme objet (pointeurs ou pas, héritage multiple ou pas, etc.), mais le diagramme de classes permet de modéliser les classes du système et leurs relations indépendamment d’un langage de programmation particulier.

Les principaux éléments de cette vue statique sont les classes et leurs relations : association, généralisation et plusieurs types de dépendances, telles que la réalisation et l’utilisation.




1.1.2. Les classes
Notions de classe et d’instance de classe


Une instance est une concrétisation d’un concept abstrait. Par exemple :
– la Ferrari Enzo qui se trouve dans votre garage est une instance du concept abstrait Automobile ;
– l’amitié qui lie Jean et Marie est une instance du concept abstrait Amitié ;
Une classe est un concept abstrait représentant des éléments variés comme :
– des éléments concrets (ex : des avions),
– des éléments abstraits ( ex : des commandes),
– des composants d’une application (ex : les boutons des boîtes de dialogue),
– des structures informatiques (ex : des tables de hachage),
– des éléments comportementaux (ex : des tâches), etc.

Tout système orienté objet est organisé autour des classes.
Une classe est la description formelle d’un ensemble d’objets ayant une sémantique et des propriétés communes.

Un objet est une instance d’une classe. C’est une entité discrète dotée d’une identité, d’un état et d’un comportement que l’on peut invoquer. Les objets sont des éléments individuels d’un système en cours
d’exécution.

Par exemple, si l’on considère que Homme (au sens être humain) est un concept abstrait, on peut dire que la personne Marie-Cécile est une instance de Homme. Si Homme était une classe, Marie-Cécile en
serait une instance : un objet.

Notions de propriétés
Une classe définit un jeu d’objets dotés de propriétés. Les propriétés d’un objet permettent de spécifier son état et son comportement. Dans les sections 1.3.2 et 1.3.4, nous avons dit que les propriétés d’un objet
étaient soit des attributs, soit des opérations. Ce n’est pas exact dans un diagramme de classe car les terminaisons d’associations font également partie des propriétés d’un objet au même titre que les attributs et les opérations.

État d’un objet : Ce sont les attributs et les terminaisons d’associations (cf. section 3.3.2) qui décrivent l’état d’un objet. On utilise les attributs pour des valeurs de données pures, dépourvues d’identité, telles que les nombres et les chaînes de caractères. On utilise les associations pour connecter les classes du diagramme de classe. Dans ce cas, la terminaison de l’association (du côté de la classe cible) est une propriété de la classe de base.

Les propriétés décrites par les attributs prennent des valeurs lorsque la classe est instanciée. L’instance d’une association est appelée un lien.

Comportement d’un objet : Les opérations décrivent les éléments individuels d’un comportement que l’on peut invoquer. Ce sont des fonctions qui peuvent prendre des valeurs en entrée et modifier les attributs ou produire des résultats.

Une opération est la spécification (i.e. déclaration) d’une méthode. L’implémentation (i.e. définition) d’une méthode est également appelée méthode. Il y a donc une ambiguïté sur le terme méthode.

Les attributs, les terminaisons d’association et les méthodes constituent donc les propriétés d’une classe (et de ses instances).

Représentation graphique
Une classe est un classeur 2. Elle est représentée par un rectangle divisé en trois à cinq compartiments







Représentation UML d’une classe


Le premier indique le nom de la classe , le deuxième ses attributs et le troisième ses opérations. Un compartiment des responsabilités peut être ajouté pour énumérer l’ensemble de tâches devant être assurées par la classe mais pour lesquelles on ne dispose pas encore assez d’informations. Un compartiment des exceptions peut également être ajouté pour énumérer les situations exceptionnelles devant être gérées par la classe.


Encapsulation, visibilité, interface





Nous avons déjà abordé cette problématique section 1.3.4. L’encapsulation est un mécanisme consistant à rassembler les données et les méthodes au sein d’une structure en cachant l’implémentation de l’objet, c’est-à-dire en empêchant l’accès aux données par un autre moyen que les services proposés. Ces services accessibles (offerts) aux utilisateurs de l’objet définissent ce que l’on appel l’interface de l’objet
(sa vue externe).

L’encapsulation permet donc de garantir l’intégrité des données contenues dans l’objet.

L’encapsulation permet de définir des niveaux de visibilité des éléments d’un conteneur. La visibilité déclare la possibilité pour un élément de modélisation de référencer un élément qui se trouve dans un
espace de noms différents de celui de l’élément qui établit la référence.

Elle fait partie de la relation entre un élément et le conteneur qui l’héberge, ce dernier pouvant être un paquetage, une classe ou un autre
espace de noms. Il existe quatre visibilités prédéfinies.

public ou + : tout élément qui peut voir le conteneur peut également voir l’élément indiqué.

protected ou # : seul un élément situé dans le conteneur ou un de ses descendants peut voir l’élément indiqué.

private ou - : seul un élément situé dans le conteneur peut voir l’élément.

package ou _ ou rien : seul un élément déclaré dans le même paquetage peut voir l’élément.

Par ailleur, UML 2.0 donne la possibilité d’utiliser n’importe quel langage de programmation pour la spécification de la visibilité.

Dans une classe, le marqueur de visibilité se situe au niveau de ses propriétés (attributs, terminaisons d’association et opération). Il permet d’indiquer si une autre classe peut accéder à ses propriétés.

Dans un paquetage, le marqueur de visibilité se situe sur des éléments contenus directement dans le paquetage, comme les classes, les paquetages imbriqués, etc. Il indique si un autre paquetage susceptible d’accéder au premier paquetage peut voir les éléments.

Dans la pratique, lorsque des attributs doivent être accessibles de l’extérieur, il est préférable que cet accès ne soit pas direct mais se fasse par l’intermédiaire de méthodes


Nom d’une classe

Le nom de la classe doit évoquer le concept décrit par la classe. Il commence par une majuscule. On peut ajouter des informations subsidiaires comme le nom de l’auteur de la modélisation, la date, etc.

Pour indiquer qu’une classe est abstraite, il faut ajouter le mot-clef abstract.
La syntaxe de base de la déclaration d’un nom d’une classe est la suivante :
[ ::...:: ]
[ { [abstract], [], [], ... } ]

Les attributs

Les attributs définissent des informations qu’une classe ou un objet doivent connaître. Ils représentent les données encapsulées dans les objets de cette classe.

Chacune de ces informations est définie par un nom, un type de données, une visibilité et peut être initialisé. Le nom de l’attribut doit être unique dans la classe. La syntaxe de la déclaration d’un attribut est la suivante :

[/] :
[ ’[’ ’]’ [ ’{’ ’}’ ] ] [ = ]

Le type de l’attribut () peut être un nom de classe, un nom d’interface ou un type de donné prédéfini. La multiplicité () d’un attribut précise le nombre de valeurs que l’attribut peut contenir. Lorsqu’un multiplicité supérieure à 1 est précisée, il est possible d’ajouter une contrainte () pour préciser si les valeurs sont ordonnées ({ordered}) ou pas ({list}).

Attributs de classe

Par défaut, chaque instance d’une classe possède sa propre copie des attributs de la classe. Les valeurs des attributs peuvent donc différer d’un objet à un autre.

Cependant, il est parfois nécessaire de définir un attribut de classe (static en Java ou en C++) qui garde une valeur unique et partagée par toutes les instances de la classe. Les instances ont accès à cet attribut mais n’en possèdent pas une copie.

Un attribut de classe n’est donc pas une propriété d’une instance mais une propriété de la classe et l’accès à cet attribut ne nécessite pas l’existence d’une instance.

Graphiquement, un attribut de classe est souligné.

Attributs dérivés

Les attributs dérivés peuvent être calculés à partir d’autres attributs et de formules de calcul. Lors de la conception, un attribut dérivé peut être utilisé comme marqueur jusqu’à ce que vous puissiez déterminer les règles à lui appliquer.

Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur nom.
Les méthodes


Dans une classe, une opération (même nom et même types de paramètres) doit être unique. Quand le nom d’une opération apparaît plusieurs fois avec des paramètres différents, on dit que l’opération est
surchargée. En revanche, il est impossible que deux opérations ne se distinguent que par leur valeur retournée.

La déclaration d’un opération contient les types des paramètres et le type de la valeur de retour, sa syntaxe est la suivante :

( [ [, [, ...] ] ] ) :
[] [ { } ]

La syntaxe de définition d’un paramètre () est la suivante :
[] : [’[’’]’] [=]

La direction peut prendre l’une des valeurs suivante :

in : Paramètre d’entrée passé par valeur. Les modifications du paramètre ne sont pas disponibles pour l’appelant. C’est le comportement par défaut.

out : Paramètre de sortie uniquement. Il n’y a pas de valeur d’entrée et la valeur finale est disponible pour l’appelant.

inout : Paramètre d’entrée/sortie. La valeur finale est disponible pour l’appelant.

Le type du paramètre () peut être un nom de classe, un nom d’interface ou un type de donné prédéfini.

Les propriétés () correspondent à des contraintes ou à des informations complémentaires comme les exceptions, les préconditions, les postconditions ou encore l’indication qu’une méthode
est abstraite (mot-clef abstract), etc.



Méthode de classe

Comme pour les attributs de classe, il est possible de déclarer des méthodes de classe. Une méthode de classe ne peut manipuler que des attributs de classe et ses propres paramètres.

Cette méthode n’a pas accès aux attributs de la classe (i.e. des instances de la classe). L’accès à une méthode de classe ne nécessite
pas l’existence d’une instance de cette classe.


Graphiquement, une méthode de classe est soulignée.

Méthodes et classes abstraites

Une méthode est dite abstraite lorsqu’on connaît son entête mais pas la manière dont elle peut être réalisée (i.e. on connaît sa déclaration mais pas sa définition).

Une classe est dite abstraite lorsqu’elle définit au moins une méthode abstraite ou lorsqu’une classe parent (cf. section 3.3.1) contient une méthode abstraite non encore réalisée.

On ne peut instancier une classe abstraite : elle est vouée à se spécialiser. Une classe abstraite peut très bien contenir des méthodes concrètes.

Une classe abstraite pure ne comporte que des méthodes abstraites. En programmation orientée objet, une telle classe est appelée une interface.

Classe active

Une classe est passive par défaut, elle sauvegarde les données et offre des services aux autres. Une classe active initie et contrôle le flux d’activités.

Graphiquement, une classe active est représentée comme une classe standard dont les lignes verticales du cadre, sur les côtés droit et gauche, sont doublées.
Relations entre classes

Généralisation et Héritage











La généralisation décrit une relation entre une classe générale (classe de base ou classe parent) et une classe spécialisée (sous-classe).

La classe spécialisée est intégralement cohérente avec la classe de
base, mais comporte des informations supplémentaires (attributs, opérations, associations). Un objet de la classe spécialisée peut être utilisé partout où un objet de la classe de base est autorisé.

Dans le langage UML, ainsi que dans la plupart des langages objet, cette relation de généralisation se traduit par le concept d’héritage. On parle également de relation d’héritage.

Ainsi, l’héritage permet
la classification des objets
Le symbole utilisé pour la relation d’héritage ou de généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général

Les propriétés principales de l’héritage sont :
– La classe enfant possède toutes les propriétés des ses classes parents, mais elle ne peut accéder aux propriétés privées de celle-ci.


– Une classe enfant peut redéfinir (même signature) une ou plusieurs méthodes de la classe parent. Sauf indication contraire, un objet utilise les opérations les plus spécialisées dans la hiérarchie des
classes.

– Toutes les associations de la classe parent s’appliquent aux classes dérivées.

– Une instance d’une classe peut être utilisée partout où une instance de sa classe parent est attendue.

Par exemple, en se basant sur le diagramme de la figure 3.3, toute opération acceptant un objet d’une classe Animal doit accepter un objet de la classe Chat.

– Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple. Le langage C++ est un des langages objet permettant son implémentation effective, le langage java ne le permet pas.
En UML, la relation d’héritage n’est pas propre aux classes. Elle s’applique à d’autres éléments du langage comme les paquetages, les acteurs ou les cas d’utilisation


Association

Une association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui décrit les connexions structurelle entre leurs instances.

Terminaison d’association vs. Attribut

Un attribut est une association dégénérée dans laquelle une terminaison d’association3 est détenue par un classeur (généralement une classe). Le classeur détenant cette terminaison d’association devrait théoriquement se trouver à l’autre terminaison, non modélisée, de l’association. Un attribut n’est donc rien d’autre qu’une terminaison d’un cas particulier d’association.

Les terminaisons d’associations et les attributs sont donc deux éléments conceptuellement très proches que l’on regroupe sous le terme de propriété structurelle.
Une propriété structurelle peut être paramétrée par les éléments suivant :
nom : Comme un attribut, une terminaison d’association peut être nommée. Le nom est situé à proximité de la terminaison, mais contrairement à un attribut, ce nom est facultatif. Le nom d’une terminaison d’association est appelée nom du rôle. Une association peut donc posséder autant de noms de rôle que de terminaisons (deux pour une association binaire et n pour une association n-aire).

visibilité : Comme un attribut, une terminaison d’association possède une visibilité (cf. section 3.2.4). La visibilité est mentionnée à proximité de la terminaison, et plus précisément, le cas échéant, devant
le nom de la terminaison.

Multiplicité : Comme un attribut, une terminaison d’association peut posséder une multiplicité. Elle est mentionnée à proximité de la terminaison. Il n’est pas impératif de la préciser, mais, contrairement
à un attribut dont la multiplicité par défaut est 1, la multiplicité par défaut d’une terminaison
d’association est non spécifiée. L’interprétation de la multiplicité pour une terminaison d’association
est moins évidente que pour un attribut.
navigabilité : Pour un attribut, la navigabilité est implicite, navigable, et toujours depuis la classe vers
l’attribut. Pour une terminaison d’association, la navigabilité peut être précisée

Association binaire





Une association binaire est matérialisée par un trait plein entre les classes associées.
Elle peut être ornée d’un nom, avec éventuellement une précision du sens de lecture (I ou J).
Quand les deux extrémités de l’association pointent vers la même classe, l’association est dite réflexive.
Association n-aire








Une association n-aire lie plus de deux classes. La ligne pointillée d’une classe-association peut
être reliée au losange par une ligne discontinue pour représenter une association n-aire dotée d’attributs, d’opérations ou d’associations.
On représente une association n-aire par un grand losange avec un chemin partant vers chaque classe participante. Le nom de l’association, le cas échéant, apparaît à proximité du losange.
Multiplicité ou cardinalité
La multiplicité associée à une terminaison d’association, d’agrégation ou de composition déclare
le nombre d’objets susceptibles d’occuper la position définie par la terminaison d’association. Voici
quelques exemples de multiplicité :

– exactement un : 1 ou 1..1
– plusieurs : _ ou 0.._ – au moins un : 1.._ – de un à six : 1..6

Dans une association binaire, la multiplicité sur la terminaison cible contraint le nombre
d’objets de la classe cible pouvant être associés à un seul objet donné de la classe source (la classe de l’autre terminaison de l’association).
Dans une association n-aire, la multiplicité apparaissant sur le lien de chaque classe s’applique sur
une instance de chacune des classes, à l’exclusion de la classe-association et de la classe considérée. Par exemple, si on prend une association ternaire entre les classes (A, B, C), la multiplicité de la terminaison C indique le nombre d’objets C qui peuvent apparaître dans l’association (définie section 3.3.6) avec une paire particulière d’objets A et B.
Remarque
Il faut noter que, pour les habitués du modèle entité/relation, les multiplicités sont en UML « à
l’envers » (par référence à Merise) pour les associations binaires et « à l’endroit » pour les n-aires avec
n > 2.
Navigabilité
La navigabilité indique s’il est possible de traverser une association. On représente graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche la navigabilité par une croix du côté de la terminaison non navigable. Par défaut, une association est navigable dans les deux sens.

Par exemple, sur la suivante, la terminaison du côté de la classe Commande n’est pas navigable :
cela signifie que les instances de la classe Produit ne stockent pas de liste d’objets du type Commande.








Inversement, la terminaison du côté de la classe Produit est navigable : chaque objet commande contient une liste de produits.






Lorsque l’on représente la navigabilité uniquement sur l’une des extrémités d’une association, il
faut remarquer que, implicitement, les trois associations représentées sur la précédente ont la même
signification : l’association ne peut être traversée que dans un sens.








Nous avons dit précédemment que :
« Un attribut est une association dégénérée dans laquelle une terminaison d’association est détenue par un classeur (généralement une classe). Le classeur détenant cette terminaison d’association devrait théoriquement se trouver à l’autre terminaison, non modélisée, de l’association. Un attribut n’est donc rien d’autre qu’une terminaison d’un cas particulier d’association. »

La figure précédente illustre parfaitement cette situation. Attention toutefois, si vous avez une classe Point dans votre diagramme de classe, il est extrêmement maladroit de représenter des classes (comme la classe Polygone) avec un ou plusieurs attributs de type Point. Il faut, dans ce cas, matérialiser cette propriété de la classe en question par une ou plusieurs associations avec la classe Point.





1.1. Diagrammes de séquence et messages
Cette section présente les nouveautés UML2.0 en ce qui concerne le diagramme de séquence (appelé sequence diagram ou interaction diagram en anglais)
Les diagrammes de séquence sont comme on peut s’en rendre compte couramment utilisés par nombre d'acteurs d'un projet, même quelque fois à leur insu, sans savoir qu'ils utilisent là un des diagrammes UML. En effet, le diagramme de séquence est une représentation intuitive lorsque l'on souhaite concrétiser des interactions entre deux entités (deux sous-systèmes ou deux classes d'un futur logiciel). Ils permettent à l'architecte/designer de créer au fur et à mesure sa solution. Cette représentation intuitive est également un excellent vecteur de communication dans une équipe d'ingénierie pour discuter cette solution.Les diagrammes de séquence peuvent également servir à la problématique de test.

Les traces d'exécution d'un test peuvent en effet être représentées sous cette forme et servir de comparaison avec les diagrammes de séquence réalisés lors des phases d'ingénierie.
Les diagrammes de séquence tels que définis en UML1.x souffraient cependant d'un gros inconvénient. La quantité de diagrammes à réaliser pouvait atteindre un nombre conséquent dès lors que l'on souhaitait décrire avec un peu de détail les différentes branches comportementales d'une fonctionnalité.

Le plus coûteux étant de remettre à jour ces diagrammes lors d'un changement au niveau des exigences ou bien du design. Nous allons voir qu’UML2.0 souhaite donner plus de puissance de représentation à ces diagrammes grâce à de nouvelles constructions qui peuvent servir à réduire la quantité de diagramme à réaliser.

Nous avons vu plus haut qu’un diagramme de séquence permet de décrire les interactions entre différentes entités et/ou acteurs : par exemple des objets dans un modèle d'un logiciel, des sous-systèmes dans un modèle d'un système complet.
- Le temps est représenté comme s'écoulant du haut vers le bas le long des "lignes de vie" (lifeline) des entités.- Des flèches représentent les messages qui transitent d'une entité vers l'autre. Le nom des message apparaît sur chaque flèche. Si l'extrémité de la flèche est pleine, le message est synchrone. Si l'extrémité de la flèche est creuse, le message est asynchone.



1.1. « Boite noire »
Un composant possède une « vue externe » (ou vue de type Black Box) qui reflète ses propriétés et ses opérations visibles. Cette vue montre l’ensemble des interfaces requises et fournies, nécessaires au fonctionnement du composant. De plus, le comportement d’un composant peut être spécifié sous la forme d’une machine à état associée à une interface ou au composant lui-même, servant à définir de façon précise les différents états possibles du composant et les conditions à remplir pour déclencher des réactions ou des changements d’états au sein de ce même composant.
1.2. « Boite blanche »
Un composant possède aussi une « vue interne » regroupant l’ensemble de ses propriétés privées et de ses fonctions réalisant ses interfaces. Cette vue montre comment le comportement externe est implémenté

Un exemple complet

1.1. Exemple complet
Cette section présente un exemple complet d’un diagramme de séquence


Un message réflexif ne représente pas l'envoi d'un message, il représente une activité interne à l'objet (qui peut être détaillée dans un diagramme d'activités) ou une abstraction d'une autre interaction (qu'on peut détailler dans un autre diagramme de séquence).

1. Présentation des différents diagrammes d’analyse
1.1. Introduction aux diagrammes de séquence
Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages.
Contrairement au diagramme de collaboration, on n'y décrit pas le contexte ou l'état des objets, la représentation se concentre sur l'expression des interactions.
Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation.
L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.
La disposition des objets sur l'axe horizontal n'a pas de conséquence pour la sémantique du diagramme.
Les diagrammes de séquences et les diagrammes d'état-transitions sont les vues dynamiques les plus importantes d'UML



















1.1. Types de messages

Comme vous pouvez le voir dans l'exemple ci-dessus, UML propose un certain nombre de stéréotypes graphiques pour décrire la nature du message (ces stéréotypes graphiques s'appliquent également aux messages des diagrammes de collaborations) :
message simpleMessage dont on ne spécifie aucune caractéristique d'envoi ou de réception particulière.
message minuté (timeout)Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans une contrainte), en attendant la prise en compte du message par le récepteur. L'expéditeur est libéré si la prise en compte n'a pas eu lieu pendant le délai spécifié.
message synchroneBloque l'expéditeur jusqu'à prise en compte du message par le destinataire. Le flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le récepteur actif) à la prise en compte du message.
message asynchroneN'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris en compte par le récepteur à tout moment ou ignoré (jamais traité).
message dérobantN'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération chez le récepteur que s'il s'est préalablement mis en attente de ce message

1.2. Activation d’objets
Sur un diagramme de séquence, il est aussi possible de représenter de manière explicite les différentes périodes d'activité d'un objet au moyen d'une bande rectangulaire superposée à la ligne de vie de l'objet.On peut aussi représenter des messages récursifs, en dédoublant la bande d'activation de l'objet concerné.Pour représenter de manière graphique une exécution conditionnelle d'un message, on peut documenter un diagramme de séquence avec du pseudo-code et représenter des bandes d'activation conditionnelles




1.1. Remarques
Ne confondez la période d'activation d'un objet avec sa création ou sa destruction. Un objet peut être actif plusieurs fois au cours de son existence (voir exemple ci-dessus).
Le pseudo-code peut aussi être utilisé pour indiquer des itérations (avec incrémentation d'un paramètre d'un message par exemple).
Le retour des messages asynchrones devrait toujours être matérialisé, lorsqu'il existe.
Notez qu'il est fortement recommandé de synchroniser vos messages, comme sur l'exemple qui suit...
L'exemple qui suit présente aussi une alternative intéressante pour la représentation des branchements conditionnels. Cette notation est moins lourde que celle utilisée dans l'exemple ci-dessus.
Préférez aussi l'utilisation de contraintes à celle de pseudo-code, comme dans l'exemple qui suit

L'analyse par rapport à l'ensemble de la démarche

1. Situer la phase d’analyse dans l’ensemble de la démarche
La phase d’analyse intervient en amont de la préparation du cahier de charge fonctionnel, l’objectif de ce dernier étant de relater les besoins exactes des utilisateurs.

Pour ce faire des entretiens sont menés et un groupe de travail est constitué. Le cahier de charge fonctionnel devient alors la conclusion des travaux d’analyse de la valeur et d’analyse fonctionnelle qui symbolisent la démarche d’expression du besoin. La démarche adoptée fait généralement l’objet des points suivants.


Orienter l'étude
Rechercher l'informationLa recherche de l'information doit être canalisée et formalisée. C'est un processus constant tout au long du projet qui doit être mené rigoureusement dès le début du projet afin d'appréhender plus précisément les caractéristiques essentielles du besoin.
Un excellent moyen de chercher l'information la plus pertinente et de la vérifier en même temps est de constituer un groupe de travail.
Traduire le besoin en fonctionsLe passage du besoin en fonction s'effectue au travers de l'analyse fonctionnelle qui recense, caractérise, ordonne, hiérarchise et valorise les fonctions.
Formaliser les travaux
Contrôler le CdCF (Cahier de charge fonctionnel) Besoin
Valider le CdCF BesoinIl s'agit de s'assurer que le passage du besoin exprimé au besoin fonctionnel est conforme aux objectifs visés. C'est un travail qui peut s'avérer fastidieux et risqué si le volume d'information est important. L'objectif est donc ici de rendre efficace la validation en réduisant son domaine d'action et tout en conservant sa représentativité.






1.1. L’analyse de la valeur

L'analyse de la valeur permet de traquer les coûts superflus liés à chacune des fonctions d'un produit ou d'un service. Comme elle aboutit souvent à opérer des compromis, elle gagne à être utilisée de pair avec le design, afin de sauvegarder les éléments attractifs du produit ou des services.L'analyse de la valeur a pour objectif d'abaisser le coût de production total en recherchant les économies réalisables sur chacun des postes de dépense sans réduire la qualité ni les performances techniques du produit ou du service. Cette méthode a été inventée dans les années 50 aux Etats-Unis. Elle a d'abord été utilisée dans l'industrie de la Défense. Ses modalités d'application peuvent varier selon les intervenants.Elle consiste à analyser les différentes fonctions d'un produit. Le but est de vérifier, pour chacune, si elle correspond à un réel besoin, quel est son coût et comment il peut être réduit. L'analyse peut également porter sur la valeur ajoutée à chacune des étapes de la fabrication.L'analyse de la valeur s'adapte aussi bien à la conception d'un nouveau produit qu'à un produit existant. Elle nécessite de bien identifier les différentes fonctions. Celles-ci se décomposent notamment en fonction d'usage ou de service et en fonction d‘estime.Les principales fonctions d‘un tournevis sont de visser et de dévisser. Mais il peut aussi remplir d'autres fonctions: être agréable à utiliser, à manipuler ou à regarder, donner une impression de robustesse et/ou de légèreté, s'intégrer dans une gamme, donner une image valorisante de l'entreprise. Ces fonctions figurent en principe dans le cahier des charges, le document servant de base de travail pour la conception d‘un produit.Certains designers recourent à l'analyse de la valeur pour conforter leur démarche créative. Mais cette méthode ne remplacera jamais l'intuition et le bon sens. Et elle gagnera toujours à être utilisée en liaison avec le design. Celui-ci est le garant de la personnalité et de la qualité perçue du produit. Surtout, le design offre une meilleure visibilité dans la gestion des économies et le tri des fonctions. Des fonctions apparemment accessoires, qui risqueraient donc d'être sacrifiées par le biais de l'analyse de la valeur, peuvent en réalité constituer des critères de choix déterminants pour le consommateur. A l'inverse, des fonctions jugées importantes par l'industriel peuvent ne pas être primordiales aux yeux du consommateur




1.2. L’analyse fonctionnelle

1.2.1. Présentation
D'après la norme AFNOR NF X 50-151, l'analyse fonctionnelle est une démarche qui consiste à rechercher, ordonner, caractériser, hiérarchiser et / ou valoriser les fonctions du produit attendu par l'utilisateur.

L'analyse fonctionnelle révèle les fonctions associées au besoin réel, ce qui permet de limiter les évolutions ultérieures du besoin exprimé aux seules évolutions du besoin réel.

L'analyse fonctionnelle laisse ouvert le choix des solutions. On permet ainsi une meilleure adéquation entre les concepts de solution qui apparaîtront et le besoin exprimé.

L'analyse fonctionnelle encourage la créativité en ne limitant pas les recherches aux seules solutions existantes. A partir d'un groupe de travail, l'analyse fonctionnelle organise les échanges entre acteurs d'un projet et limite les contentieux ultérieurs.

Pour mener à bien l'analyse fonctionnelle, il convient de : - Bien choisir le groupe de travail qui doit être composé de 4 à 8 participants permanents,
- choisir un rapporteur de séance, - établir le calendrier des réunions, - organiser la communication à l'intérieur du groupe de travail : comptes-rendus de réunion, diffusion du résultat.

L'analyse fonctionnelle s'applique à la création ou à l'amélioration d'un produit, elle est dans ce cas l'étape fondamentale de l'analyse de la valeur.



Appliquée au seul besoin, elle est la base de l'établissement du Cahier des Charges Fonctionnel Besoin.

Les exigences et attentes - que font spontanément connaître les clients, utilisateurs et autres acteurs - ne constituent, le plus souvent, que la partie émergée de l’iceberg représentatif de l’ensemble du besoin à satisfaire, la partie immergée comprenant tout ce qui est habituellement exigé (normes, règlements,...) d’une fourniture du type correspondant.
Ainsi, l’Analyse Fonctionnelle du Besoin considère le rôle joué par la fourniture à l’égard des éléments qui l’entourent, le traduit par les fonctions de service et les contraintes, dont les critères permettent d’apprécier si elles sont bien remplies ou respectées. Telles sont les bases du Cahier des Charges Fonctionnel (CdCF)

L’entreprise, qui a établi ces bases pour chacune des principales familles de fournitures (qu’elle vend, se procure ou utilise dans le cadre de son métier) est en position de mieux faire préciser, par les différentes parties prenantes, ce qu’elles attendent, ainsi que les latitudes et compensations qu’elles admettent (flexibilité).

Pour parvenir au CdCF particulier à une fourniture, il a fallu: - acquérir les informations sur le marché et la concurrence (Marketing) ;
- rassembler les informations sur le savoir-faire et les ressources mobilisables (Information orientée Fonction)
La démarche d'expression fonctionnelle du besoin est itérative et prend en compte les choix de principes de solution et d'architecture fonctionnelle (Analyse Fonctionnelle Technique) pour arriver à la spécification de la fourniture