Inception, la suite des Use Case

Maintenant qu’on sait comment manipuler les use case de manière basique, concentrons nous sur une base simple d’interface graphique sur laquelle on pourra s’appuyer pour faire le reste des use case. Et surtout, une base qui puisse nous permettre d’ajouter facilement les fonctionnalité au fur et à mesure du développement.

Avant de me lancer dans le reste de l’article je voudrais préciser que le développement UX (pour User eXperience) c’est une discipline vraiment à part et que je risque fortement de faire des erreur de débutant à ce niveau.
Je vais me concentrer sur ce qui me parait logique et/ou intuitif, il se peut donc que des modifications radicales interviennent dans le futur si je me rend compte que j’ai fait de la merde.

Comme vous pouvez le voir, j’ai essayé de faire très simple. Je me suis inspiré d’interfaces que j’ai déjà pu voir, et en général les app ou les site web traitant des charts se présentent de cette façon.

Ce qui est important à garder à l’esprit, c’est le but simple et succint de cette application :

“Pouvoir faire du Trading en étant soutenu par une IA qu’on peut entraîner à tout moment.”

Listons les éléments :

  1. PRIMARY_MENU : “Fichiers, Editions, Outils, etc.”, menu principal de l’application. On y trouvera des accès aux configurations de l’application, gestion des outils, et certainement plein d’autre choses plus “globale”.
  2. TOP_ACTIONS_AND_TOOLS_MENU_BAR : Menu iconique, permettant d’accéder aux actions et outils qui peuvent agir directement sur la vue “CHARTS_WIDGET_VIEW”. L’intérêt de ce menu est de faciliter l’accès aux outils dont aurait besoin le trader. Par exemple, on pourrait y voir un bouton “INDICATEURS” permettant d’avoir accès à la liste des indicateurs.
    Il pourrait y avoir également des boutons pour configurer et sauvegarder des informations sur l’état de la vue (la plateforme, le marché, la timeframe, etc.).
  3. CHARTS_WIDGET_VIEW : Vue centrale qui affiche les graphiques de marchés selon l’état actuel de l’application.
  4. ACTIONS_WIDGET_VIEW : Vue latérale qui affiche des formulaire de configuration, qui donne accès à des actions selon le ou les outils sélectionnés actuellement.
    Par exemple, on peut ouvrir l’outil “Trade” et avoir un formulaire qui permet de configurer et exécuter une prise de position.
    Ou encore cette vue pourrait afficher par exemple un formulaire de configuration d’un nouveau indicateur à ajouter à la vue centrale.
  5. STATUS_BAR : Doit afficher des messages simple d’informations concernant l’ensemble de l’application.

Pour tout vous dire, vu mon petit background de dev web, au départ je partais sur l’idée d’avoir plusieurs “pages” dans l’application, mais je me suis vite rendu compte que ça ne faciliterait absolument rien et que ce genre de configuration en “page”.
Ici on développe un projet d’application orientée “Desktop” donc on a accès à tout directement, plus besoin de penser l’application en succession de pages mais bien en succession “d’état d’application”. Si je sélectionne l’outil “Tracer une Ligne”, je change “l’état” de mon application, tout comme dans Paint quand vous utilisez l’outil Rectangle plutôt que l’outil Sélection.

Il faut qu’on puisse sélectionner nos outils facilement et exécuter des actions de manière fluide. Par exemple, vous êtes en Live Trading et vous repérez un pattern que vous incluez dans votre stratégie, c’est donc le moment de prendre une image de ce pattern et de l’ajouter aux images pour l’entraînement de votre IA. 

Il paraît beaucoup plus simple et intuitif de cliquer sur un bouton “Pattern Modeler” (par exemple) que de passer sur une autre page dans votre application pour prendre cette image. 

Commençons par le début : Le lancement de l’application et son interface graphique

Quand l’utilisateur lance l’application en cliquant sur son raccourci, il faut qu’on puisse établir les différentes étapes par lesquelles l’application doit passer.

En schéma ça donne quelque chose comme ça :

  1. Lancement de l’application
  2. On Initialise “l’état de l’application”, qu’on nommera “Application State”.
  3. On lance l’UI (User Interface) (qui détient une relation inclusive avec l’action précédente, il faut que le State soit défini avant de lancer l’interface graphique)
  4. On charge les différents Widgets principaux (les Widgets sont des cadres, indépendants les un des autres, qui contiennent des éléments graphique dans une interface graphique).

Lorsque l’application est lancée, on veut avoir une application vierge, on va donc devoir définir ce qui doit s’afficher par défaut dans chaque Widget.

Chacun ira chercher son State (son “état”) dans le State Globale de l’application. Les state seront relativement simple, une simple liste d’autres Widget à contenir ou non.

Exemple avec le Top Menu Actions : Ce menu est destiné à recevoir tous les boutons d’actions pour exécuter des méthodes sur les Widget Actions et Widget Charts. 

Rappelez vous l’exemple avec le bouton de dessin d’une ligne ou d’un rectangle.

Imaginons un bouton nous permettant de gérer des Indicateurs, en cliquant dessus d’abord un formulaire de configuration apparaîtrait dans le Widget Actions une fois rempli et accepté, le fait de cliquer sur “Ajouter Indicateur” dans le formulaire, cela aurait pour effet d’impacter les configurations d’indicateur sur la vue Widget Charts et cela ajouterais l’indicateur de manière visuelle, que ce soit directement sur le chandelier ou dans un cadre ajouté automatiquement dans la vue. 

En interne évidemment il y aurait d’autres exécutions d’algorithmes, par exemple le calcul de l’indicateur, un chargement éventuel de données supplémentaire, etc. 

Tout ce que la vue Widget Charts ferait c’est se mettre à jour quand on sait qu’on a calculé tout ce qu’il faut. Cette mise à jour se ferait simplement en exploitant les données qui se trouvent dans le State de la vue. 

Autre exemple avec la vue Widget Charts :

Par défaut, si l’utilisateur clic sur les charts il ne se passe rien. Si l’utilisateur laisse son clic enfoncé il pourrait étendre une zone de sélection par exemple.

En fait il y a deux évènement successifs, quand on presse le bouton de la souris et quand on le relâche.
On peut parler d’état du bouton de souris, s’il est enfoncé ou non.

Ensuite, en parlant de l’état de la vue widget charts, la vue va contrôler l’état de la souris et vérifier son propre état, l’état de la barre de menu actions et voir quel bouton est sélectionné.

Si l’outil “Dessiner une ligne est sélectionné”, la vue dessinera une ligne. Si l’outil “modeler un pattern” est sélectionné, chaque clic sélectionnera (ou désélectionnera si elle l’est déjà) une bougie par exemple.

Des Widgets indépendants mais une communication via le State Global

Donc comme vous l’aurez compris, les widgets sont indépendant les uns des autres, mais communiquent entre eux via le State Global de l’application et agissent de manière différentes en fonction de l’état de l’application et des autres widgets.

Pourquoi commencer par l’interface graphique ?

Il y a une chose que j’ai toujours trouvé relativement compliqué c’est arriver à séparer ce qu’on voit, ce avec quoi on peut interagir directement (appelé Front End), et ce qu’il se passe en coulisse, ce qu’on ne voit pas (appelé le Back End).

Il y a du backend et du frontend un peu partout, tout dépend à quel niveau on se met.

Ce qui est important c’est de savoir faire communiquer toutes les parties d’une application de manière fluide et permettre à chacune de ces parties d’application d’être indépendantes des autres un maximum pour qu’elles puissent être mise à jour indépendamment des autres.

L’interface graphique est une des grandes parties de l’application qu’on va devoir définir et développer dans un Module ou un Package. 

Module/Package qui devra être chargé et qui devra pouvoir s’intégrer dans une logique de communication interne à l’application.

Ce dernier schéma représente la construction de l’interface graphique. L’acteur primaire c’est notre Application.

Même si on ne l’a pas encore défini, j’ai rajouté l’Application State comme module, mais je crois qu’on peut le voir comme un acteur externe dans notre cas, chose que je ne maîtrise malheureusement pas encore x)

Je ne sais pas encore si je peux utiliser les schémas de cette manière, mais étant donné qu’il n’y a pas de méthodologie précise dans leurs utilisation, je m’autorise une petite utilisation personnelle.

Je me rend compte que l’article commence à être fouilli car beaucoup de choses sont abordées (autant par écrit que dans ma tête) et comme je voudrais garder le côté “Keep it simple”, je pense que je vais m’arrêter ici et approfondir encore dans le prochain article.

J’espère que je ne me répète pas trop et que je ne tourne pas trop en rond. Je cherche encore la/les bonnes manières de faire, celles qui me parlent le plus.

Merci d’avoir lu cet article, hésitez pas à vous inscrire et commenter l’article si ça vous dit !

A bientôt dans un prochain article 😀

Ecrire un commentaire