Discussion :

[asie86]

Bonjour
Je doit refaire l'interface d'une application qui existe déja, je n'ai l'habitude de concevoir que l'orienté objet avec UML et XP ou UP...
Pouvez vous me donnez les étapes à suivre pour la conception d'une IHM , je ne sais même pas comment démarrer , s'il y a une méthode de conception ou pas, tout ce qu'on a étudier en IHM est l'analyse de la tâche.

Merci d'avance.

[elbj]

Bonjour

Une IHM, ou une série d'IHM, n'est que la face visible de l'application, l'interface qui va permettre de l'utiliser. L'IHM est généralement liée aux processus métier que l'application implémente. C'est dans cette logique qu'il faut penser chaque IHM.

Comme je l'ai dit, une IHM est une interface entre l'utilisateur et l'application. Il y a donc des flux dans les deux sens :
- l'utilisateur saisi des informations dans des formulaires, provoques des actions en cliquant sur des boutons, etc...
- l'application fourni les informations demandées, des messages, etc...

Dans un premier temps il faut donc se poser la question de savoir de quelles IHM on a besoin, quels traitements elles porteront et quelles informations elles fourniront à l'utilisateur : formulaire de saisie de client, liste des marchandises en stock, détail d'une intervention technique, etc...

Ensuite il faut réaliser des modèles d'IHM. Soit avec un "super outil",..., soit avec un papier et un crayon. Chacun de ces modèles doit être expliqué. Quelle est sa place dans les processus métier, quelles informations sont fournies, quels traitements sont effectués, que se passe-t-il si je clique sur le gros bouton rouge, etc...

Petit à petit les IHM se précisent...

Bon courage

[asie86]

Bonjour
Merci pour la réponse, j'ai envi de savoir un peu plus, en modélisant j'utilise quels diagrammes? et quelles sont les étapes que je dois suivre, par exemple en orienté objet on commence l'analyse de besoins avec les cas d'utilisations....Il y'a des gens qui m'ont dit qu'il faut faire:
1.l'analyse de la tache
2.Dérivation des styles d'interaction
3. graphe d'enchainement
est ce que ces etapes sont correctes. merci d'avance.

[elbj]

Bonsoir

Dans le cas présent il s'agit de reprise de l'existant si je ne m'abuse. Donc les étapes suivantes devraient être suivies :
- Etude de l'Existant : qu'est-ce qu'on a pour faire quoi ?
- Expression des Besoins : qu'est-ce qu'on veut pour faire quoi ?
- Analyse Fonctionnelle : uses cases, détail des fonctions demandées, des règles métier, des processus, des contraintes, modèles d'IHM, modèle de données, etc...
- Analyse Détaillée : modélisation poussée prenant en compte le langage, le matériel, algorithmes, etc...
- Codage : implémentation
- Tests : vérification de la conformité du produit avec les besoins
- Déploiement : installation et configuration
- Maintenance : suivi, débuggage, évolutions

Une IHM peut-être modélisée grâce à plusieurs diagrammes. On se trouve là dans l'Analyse Fonctionnelle.

Etant en objet, chaque Interface Graphique est un objet. Un diagramme de classes peut représenter les interfaces graphiques.
Les Attributs de ces classes pourront représenter le type d'objet manipulé. Les Méthodes de ces classes représenteront dans un premier temps ce que l'on peut faire avec l'interface.

Par exemple : une interface d'édition d'un élément d'un carnet d'adresse, objet de type Personne, permettant de Créer, Mettre à Jour et Supprimer, pourra se représenter ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
class FormulaireSaisiePersonne
Attributs :
 - Personne
Méthodes :
 - Créer() : Personne
 - Mettre à Jour (Personne) : bool
 - Supprimer (Personne) : bool

Attention, on se place ici dans le contexte de l'Analyse Fonctionnelle, qui vient après l'Expression des Besoins et avant l'Analyse Détaillée. Cela signifie que l'on doit fournir un travail aisément compréhensible par le client pour qu'il puisse le valider.

L'utilisation d'une Interface Graphique se fait généralement en suivant des Scénarios d'Utilisation. Un tel scénario a sa place dans l'analyse fonctionnelle. Il expliquera comment l'utilisateur va manipuler les fonctionnalités de l'interface pour faire son travail.

Tout ceci n'est qu'une vision personnelle d'une façon de faire parmi beaucoup d'autres. Je vous invite à surfer sur le net pour trouver plus d'informations à ce sujet. J'avoue que ce serait vraiment très long de vous exposer ici tout le métier de Développeur Informatique.

Cordialement

[hed62]

Je propose d'ailleurs le forum Méthodes pour ça

[slim]

pour réaliser une IHM, il existe bien des méthodes et différentes de celles de développement tel que UP, Merise...

Outre l'étude fonctionnelle, il existe une méthode de description de l'IHM utilisant des automates étendus.

J'en ai parlé une fois dans un post. Le voici.

Au fait, il faut lister tous les événements de l'utilisateur. Les conditions permettant ces événements et les actions effectuées par le logiciel.

Exemple :
Evénement : clic sur un bouton
Condition : Il faut que l'utilisateur ait saisi le nom de sa belle mère
Action : Envoi automatique d'un email à la belle mère.

Avec ça, tu obtiens un automate à états. Chaque état représente un état que peut avoir ton interface.
A partir de l'automate, tu obtiens une matrice états événements qui te permet de réaliser tes events handler (le code quoi...).

PS: je l'utilise toujours dans mes projets et ça marche plutôt bien.

bon courage.

[koala01]

Salut, et toutes mes excuses de faire remonter le post...

Je me dis que le principe qui devrait prévaloir (mais pour cela, il faut disposer de l'analyse des besoins et sans doute du début de l'analyse fonctionnelle), c'est de fournir une interface suffisemment riche pour éviter à l'utilisateur de devoir passer au travers de 10 formulaire pour obtenir (un morceau de) l'information qui lui est utile pour continuer à remplir celui sur lequel il bosse, tout en évitant malgré tout les interface "fourre tout" dans lesquelles on ne sait même plus s'orienter en fonction de ce que l'on veut faire...

Je m'explique: j'ai du aller déclarer la perte de ma carte d'identité il y a quelques mois...

Le policier qui s'est occupé de moi a bien du effectuer dix allers/retours parmi 5 formulaires différents, simplement pour disposer d'informations (qui n'étaient meme pas transmises de formulaire à formulaire) finalement toutes simples lui permettant de remplir les blancs dans un document pourtant basique (à part les informations classiques que l'on fournit lors de démarches administratives, et les circonstances de la perte,il n'y avait rien à mettre...).

Et pourtant, outre mon nom et mon prénom, je lui avais même donné mon numéro de registre national, et donc il aurait du pouvoir disposer d'une seule traite de toutes les informations me concernant, et, même si j'avais eu un nom particulièrement usité dans ces contrées (ce qui n'est pas mon cas), le formulaire de recherche aurait quand même pu transmettre ces informations au formulaire de "perte de carte d'identité"...

C'est là que l'on se rend compte qu'un formulaire de recherche, c'est très bien, mais qu'il n'a réellement de sens que s'il est en mesure de transférer l'information (ou les informations) sélectionnées vers le formulaire d'origine, et surtout, qu'il faut prévoir un accès suffisemment "global" à ce formulaire de recherche pour ne pas obliger l'utilisateur à en traverser 10 qui n'ont rien à voir avant de trouver le bon