Avant de se lancer dans le développement d’un récit utilisateur fullstack (développement coté client et côté serveur), il est primordial de planifier et modéliser quelques éléments.

Modéliser le côté client

Il est parfois plus facile de débuter la planification du côté client. En fait, l’équipe de développement doit toujours avoir en tête les utilisateurs de la fonctionnalité à développer. Il est donc logique que le point de départ soit situé près de l’utilisateur : le côté client.

Mise en contexte

  • S’assurer de la valeur ajoutée du récit utilisateur.
  • Analyser les récits utilisateur déjà développés.
  • Identifier à quel endroit la nouvelle fonctionnalité devra s’insérer.
  • Avoir en tête les concepts d’ergonomie des interfaces et d’utilisabilité.

Produire une maquette et identifier les comportements

  • Produire une maquette simple (KISS : Keep It Simple and Stupid).
  • Identifier les comportements des composants de la maquette (bouton, champ de texte, …)
  • Simuler l’utilisation de cette fonctionnalité (sur papier) avec vos collègues. Cela permettra d’analyser leur comportement et leurs réactions face à cette nouveauté.
  • Modifier la maquette au besoin.

Identifier les entrées et sorties

L’objectif de cette étape est d’identifier comment le composant interagit avec le côté serveur : l’API REST.

  • Une fois la maquette produite, on peut associer le comportement des composants de la maquette avec les services de l’API REST.
  • Identifier les données qui devront être injectées du serveur vers le composant.
  • Identifier les données qui seront envoyées vers le serveur.
  • Planifier les cas limites et les exceptions.

Modéliser le côté serveur – API REST

Une fois le développement côté client approuvé par le client, on peut procéder à la modélisation des services de l’API REST. Voici les étapes proposées :

  • Identifier les routes des services REST à développer.
  • Identifier les données d’entré et de sortie pour ces routes.
  • Identifier les verbes à utiliser (GET, POST, PUT, DELETE, …).
  • Identifier les code de statut (200, 201, 403, 410, …).
  • Modéliser les entités à produire.
    • Définir les règles de validation pour les entités.
  • Identifier et modéliser les relations entre les entités.
  • Modéliser un repository qui contient les requêtes SQL à exécuter.
    • Définir les méthodes de la classe repository.
    • Programmer les méthodes.
  • Créer des fixtures afin de remplir la base de données avec des données de test.
  • Écrire les tests pour le repository.
  • Écrire les tests unitaires et fonctionnels.

Intégration : utiliser les services serveur côté client

La dernière étape consiste à intégrer le côté client et le côté serveur. Cette dernière étape donnera vie à l’application et la rendra fonctionnelle.

  • Produire les tests fonctionnels.
  • Présenter le travail à l’utilisateur et au client.
  • Intégrer le travail à l’application en production.
Note

La section suivante présente un exemple de modélisation pour un récit utilisateur fullstack. Idéalement, cette information devrait tenir sur une page pour le côté client et une page pour le côté serveur.

 

Exemple côté client

Récit utilisateur

En tant qu’utilisateur je veux afficher les commentaires pour un film afin de savoir ce que les autres en pensent.

Maquette : Image du film, bouton afficher les commentaires, liste des commentaires.

Comportement : Lorsque l’utilisateur clique sur le bouton « Afficher les commentaires », les commentaires, pour le film en question, sont récupérés et affichés sous le bouton. Un commentaire est composé du nom d’utilisateur, le texte du commentaire ainsi que la date de rédaction. Le commentaire le plus récent est affiché en premier.

Exemple côté serveur

Modélisation REST

  • Route : /api/comments?movie_id=123
  • Méthode : GET
  • Paramètre d’entrée : Identifiant du film
  • Sortie : Liste des commentaires pour le film
  • Exemple de sortie :
    • {comments: [{id:, body:, user:{id:, username: }, created:}, ]}
  • Code de statut : 200

Entité

  • Nom de l’entité : Comment
  • Relation : Un commentaire est associé à un utilisateur
  • Attributs :
    • id : Clé primaire,unique, incrémenté automatiquement
    • body : texte 1024 caractères maximum
    • created : datetime – automatique
    • movie_id : texte 255 caractères
    • user : lien vers l’entité user

Repository

  • Nom du repository : CommentRepository
  • Méthode : getCommentsForMovie($movieId)
  • SQL : SELECT * FROM comment WHERE movie_id = $movieId ORDER BY created DESC

Données de tests

  • 1, « lorem ip », user_id:1, movie_id:3, date:2016-04-28 11:11
  • 2, « lorem dhcp », user_id:1, movie_id:3, date:2016-04-28 11:12
  • 3, « lorem net », user_id:33, movie_id:1, date:2016-04-28 11:13
  • 4, « lorem apt-get », user_id:2, movie_id:2, date:2016-04-28 11:14

Tests

  • Le movie_id spécifié est valide et retourne le bon nombre de résultats.
  • Le movie_id spécifié est valide et retourne aucun résultat.
  • Le movie_id n’est pas spécifié et retourne aucun résultat.
  • Un movie_id invalide est spécifié et retourne aucun résultat.
  • Le movie_id spécifié est invalide et comporte 1024 caractères.

 

Facebook Comments

0 réponses

Laisser un commentaire

Participez-vous à la discussion?
N'hésitez pas à contribuer!

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.