Discussion :

[yazid86]

bonjour , je suis entrain de rédiger mon mémoire pour ma soutenance ,j'ai fais ingénieur réseaux et sécurité informatique , et j'ai un sérieux probléme avec l'UML et ses diagrammes
Mon thème est " la sécurisation des échanges et accès FTP" et je n'ai pas idée sur comment débuter avec ces diagrammes , svp si quelqu’un peut m'aider ou peut me diriger ca me fera un énorme service
merci a tous

[gtkmm]

Bonjour,
En effet c'est quoi exactement ton problème pour que je puisse vous répondre et vous donner des conseils.

tout d'abord les diagrammes UML nous aident à comprendre le système et le faire comprendre aux autres. Il faut que te sache que la première chose à faire c'est d'expliquer l'aspect fonctionnel de ce que tu veux faire via le diagramme de cas d'utilisation, puis, le diagramme de scénario pour but de décrire l'utilisation ou le scénario de ton système et finalement tu peux attaquer le diagramme de classe et/ou diagramme d'états.
Bon courage et bonne chance

[supergeoffrey]

Dans un mémoire, le premier que je mettrais est le diagramme de cas d'utilisation il est pas très dur à faire des bonhommes ou des PC relié à des bulles représentant un scénario par des flèches pour indiquer se qu'ils peuvent faire.

Après je mettrais les diagrammes de séquences, ils sont sensés schématiser la comportement de la machine avec l’interaction de l'utilisateur...

Finir par un diagramme de classe si tu fais du développement, après ils ne sont pas tous important c'est selon l’ampleur de ton projet.

[supergeoffrey]

Le diagramme de contexte plus connu sur le nom d'etat/transition simplement, c'est des rectangles qui représentent tes états et des flèches qui représentent les transition le passage d'un état à un autre. Tu peux aussi avoir un état d'entrer et de sortie (respectivement rond blanc et noir)

[hegros]

attention quand même parce que dans l'approche rup une diagramme de contexte ce n'est pas un diagramme d'états-transition c'est un diagramme de communication sensés montrer les interactions entre les acteurs avec le système au centre et il y a un document textuel attaché pour expliciter les rôles, les messages et les objectifs métiers.

en principe il vient avant les cas d'utilisation puisque c'est une entrée pour les déduire.

pour documenter en principe il faut faire un plan et le suivre. De plus on ne sait pas jusqu'où tu veux documenter avec uml et quelle partie tu veux couvrir avec

sinon effectivement diagramme de contexte, de cas d'utilisation, de séquences boîtes noires et boîtes blanches et j'ajouterais diagramme d'architecture de déploiement ou de composants, diagramme de classes de conception et diagramme de navigation des écrans s'il en existe