Discussion :

[vince2121]

Bonjour à tous,

J'attaque la réalisation d'un système de surveillance dans le domaine de la fabrication mécanique, avec différents capteurs (vibrations, puissance, ...), qui doit permettre de détecter en temps réel différents phénomènes et avertir l'utilisateur. Il y a donc une partie hardware (capteurs, cartes d'acquisition) et une partie logiciel avec acquisition, traitement des signaux, corrélation entre les différentes informations, affichage et/ou émission de signal en sortie, interface graphique, etc ...

Le système étant assez conséquent, avant d'attaquer directement le code, il faudrait que je fasse "des plans". Comme en mécanique, on fait des plans avant de construire une machine sinon on risque de galèrer et de ne jamais arriver au bout.

Je ne suis pas informaticien, mais j'ai l'habitude de faire des petites applications avec Matlab (depuis plusieurs années) que j'utilise pour ce projet. Je suis plutôt à l'aise avec le code pour des petites applications, mais je n'ai jamais utilisé la programmation orientée objet par exemple et je n'ai jamais eu à faire "des plans" pour mes applications, mais là j'attaque un gros morceau .

Ca fait quelques semaines que je regarde les différentes méthodes de conception logicielle (UML, Merise, SADT, ...), et je dois dire que je m'y perd un peu et je ne sais pas vraiment par quel bout prendre le problème, d'où ce message sur le forum.

D'après vous, quelle serait la meilleure manière de s'y prendre pour un débutant ? Faut-il attaquer directement par une modélisation UML dans les règles ? Commencer par une analyse descendante type SADT (c'est ce qui me parait le mieux pour au moins dégrossir la chose) ? Autre chose ? ...

Merci d'avance pour vos réponses, et excusez moi si le message n'est pas au bon endroit.

Vincent

[fsmrel]

Bonjour Vincent,


Dans ce genre d’exercice, il y a fondamentalement le QUOI, puis toute la sauce, le charbon (les opérations) pour faire marcher la machine.

Avant de construire une maison (et de l’équiper de sorte qu’on puisse y vivre), on en fait les plans, on la conçoit. Pour vous il devrait en aller de même, en l’occurrence bâtir un diagramme de classes ou un MCD (modèle conceptuel des données) merisien.

Dans cette optique, il faudrait que vous mettiez à plat les « objets » tant matériels que logiciels, en fournir la liste, les attributs (caractéristiques) et établissiez les associations entre ces objets.

Que vous utilisiez un diagramme de classes UML, ou un MCD merisien, peu importe. Si vous vous décidez d’utiliser UML alors que vous avez produit un MCD, la traduction de celui-ci en diagramme de classes est mécanique, donc peu importe. L’essentiel est de produire un modèle de données pas forcément complet, mais capable d’évoluer : ne loupez surtout pas le cœur !

[vince2121]

Bonjour fsmrel,

merci pour votre réponse. Effectivement, avant d'attaquer le code, je veux absolument être capable de faire des diagrammes des différentes interactions entre les différents objets et surtout que les diagrammes soient évolutifs, comme vous le mentionnez.

La difficulté supplémentaire étant que mon système doit être capable de détecter différents phénomènes à partir de différents capteurs physiques. Il y a donc plusieurs "croisements" entre les infos données par les capteurs et les phénomènes à détecter. Ça va même plus loin, car en fonction des phénomènes à détecter, le traitement du signal peut être différent pour un même capteur (je ne sais pas si je suis très clair (?)).

Du coup, je suis parti sur une première approche qui consiste à morceler le système général, càd à considérer chaque phénomène à détecter comme un sous-système à part entière, et ensuite les assembler pour créer le système complet.

Finalement, pour chaque sous-système, je fais un diagramme des cas d'utilisation, un SADT et un diagramme d'activité. Dans un premiers temps çà me permet d'avoir différents points de vue. Et puis je vais avoir à faire des d'essais sur machine pour la mise au point des différents traitements, donc tout çà va évoluer. Le tout étant d'être rigoureux et de ne pas se perdre dans les méandres :-)

[fsmrel]

Bonjour Vincent,

Ça va même plus loin, car en fonction des phénomènes à détecter, le traitement du signal peut être différent pour un même capteur (je ne sais pas si je suis très clair (?))

Raison de plus pour concevoir un diagramme de classes en béton, en sorte que nous puissions « capter » l'univers du traitement des signaux...

[guillaume.finance]

Bonjour,

UML étant souvent trop connoté "Logiciel", SysML me semble plus adapté à ton projet car celui-ci permet de faire coexister des blocs Hardware & Software.
SysML présente également l'avantage d'être moins étendu en terme de diagrammes qu'UML, tout en étant complet : recueil d'exigences, diagrammes statiques, diagrammes dynamiques.
Avec un outil de modélisation, tu peux non seulement établir tes modèles en amont (par ex tes diagrammes de blocs BDD & IBD), mais maintenir une cohérence dans tes modèles.

J'avais rédigé un article en 2010 dont les notions sont encore valides pour la plupart (de nouvelles versions SysML sont sorties depuis) : Modélisation SysML.
Pour plus de détails et d'exemples, il existe également des livres SysML. A noter que Pascal ROQUES, connu pour ses ouvrages UML & SysML, fera un retour d'expérience la semaine prochaine à Paris
-> cf. EAUG Paris 2015

Bonne journée,
Guillaume