IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Cas d'utilisation Discussion :

création d'un acteur par un cas d'utilisation


Sujet :

Cas d'utilisation

  1. #1
    Membre confirmé
    Inscrit en
    Janvier 2008
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Janvier 2008
    Messages : 58
    Par défaut création d'un acteur par un cas d'utilisation
    Bonjour,

    J'ai une application client/serveur à implémenter. Le principe général consiste à:

    • Un client demande un service s1 au serveur1.
    • Le serveur1 exécute le service s1, et pendant l'exécution il crie un client temporaire pour demander un service s2 au serveur2.


    Je veux faire un diagramme de cas d'utilisation pour ce système, alors j'ai pensé à cela:

    j'ai un acteur externe humain, un cas d'utilisation s1, et un autre cas d'utilisation s2.

    Mon problème est que le cas d'utilisation s2 est utilisé par le client temporaire crié par s1, donc puisse-je rajouter un autre acteur logiciel qui est crié par s1 qui vas utiliser le cas d'utilisation s2.

    Si c'est possible comment modéliser ça.

    Merci

  2. #2
    Membre expérimenté Avatar de ze_corsaire
    Inscrit en
    Décembre 2007
    Messages
    240
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Décembre 2007
    Messages : 240
    Par défaut
    Les UC servent à définir le fonctionnel, le "quoi faire" et toi tu cherches à définir le technique, le "comment faire (ce quoi)".
    Les UC considèrent ton client et tes serveurs comme un tout, le système. Les acteurs (au sens UC) sont alors les intervenants extérieurs du système.
    Les UCs doivent comporter des termes fonctionnels.

    Oublie les UC et pars sur un diagramme de séquence.

    _____

  3. #3
    Membre confirmé
    Inscrit en
    Janvier 2008
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : Janvier 2008
    Messages : 58
    Par défaut
    Bonjour,

    Je m'excuse pour le retard, je vous remercie de votre réponse. Alors vous dites que le système est le tout c'est à dire et les clients et les serveurs.

    J'insiste toujours sur l'utilisation des UC pour décrire mes acteurs. Dans ce cas mon acteur externe est une personne qui utilise les clients, et les clients invoque les services correspondants. c'est à dire j'aurais 4 UCs et un acteur.

    Est-il juste ce que je suis entrain de raconter?

  4. #4
    Membre expérimenté Avatar de ze_corsaire
    Inscrit en
    Décembre 2007
    Messages
    240
    Détails du profil
    Informations personnelles :
    Âge : 47

    Informations forums :
    Inscription : Décembre 2007
    Messages : 240
    Par défaut
    Désolé, je ne pige pas tout. D'où sort ce chiffre 4 ??

    Par ailleurs, on ne sait pas de quoi traite ton système, est-ce un outil de navigation aérienne ? Un outil gérant la production de café ? ... Tant que n'apparaîtra pas une terminologie fonctionnelle dans tes UC, ben tu n'auras pas défini de "bons" UC.

    ______

  5. #5
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    Juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : Juillet 2004
    Messages : 1 883
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par hnouna2007 Voir le message
    Bonjour,

    J'ai une application client/serveur à implémenter. Le principe général consiste à:

    • Un client demande un service s1 au serveur1.
    • Le serveur1 exécute le service s1, et pendant l'exécution il crie un client temporaire pour demander un service s2 au serveur2.


    Je veux faire un diagramme de cas d'utilisation pour ce système, alors j'ai pensé à cela:

    j'ai un acteur externe humain, un cas d'utilisation s1, et un autre cas d'utilisation s2.

    Mon problème est que le cas d'utilisation s2 est utilisé par le client temporaire crié par s1, donc puisse-je rajouter un autre acteur logiciel qui est crié par s1 qui vas utiliser le cas d'utilisation s2.

    Si c'est possible comment modéliser ça.

    Merci
    Oublies tes serveurs.
    Ton acteur humain, il veut quoi au final ?
    Ta réponse sera LE cas d'utilisation unique (visiblement) de ton système.
    Utilises un verbe à l'infinitif pour dire ce qu'attend ton acteur.

  6. #6
    Membre extrêmement actif

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Par défaut
    Citation Envoyé par ze_corsaire Voir le message
    Les UC servent à définir le fonctionnel, le "quoi faire" et toi tu cherches à définir le technique, le "comment faire (ce quoi)".
    Ce n'est pas tout à fait exact, il est possible aussi de définir des cas d'utilisation technique pour la conception technique du SI cela permet de lever un voile sur des "classes" candidates ainsi que l'identification de composant.


    Les UC considèrent ton client et tes serveurs comme un tout, le système.
    J'ai tendance à penser que cela dépend du niveau de granularité que l'on souhaite au moment de l'analyse, il peut aussi y avoir différents niveaux de détails ou de découpage, plusieurs vue de uc pour un même cas


    Les UCs doivent comporter des termes fonctionnels.
    Relis ma première remarque, on peut avoir un cas "optimiser sqlcore" d'en écrire des cas puis d'en extraire des classes candidates pour l'implémentation

  7. #7
    Membre extrêmement actif

    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    Juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : Juin 2003
    Messages : 4 506
    Par défaut
    Citation Envoyé par ze_corsaire Voir le message
    Les UC servent à définir le fonctionnel, le "quoi faire" et toi tu cherches à définir le technique, le "comment faire (ce quoi)".
    Ce n'est pas tout à fait exact, il est possible aussi de définir des cas d'utilisation technique pour la conception technique du SI cela permet de lever un voile sur des "classes" candidates ainsi que l'identification de composant.


    Les UC considèrent ton client et tes serveurs comme un tout, le système.
    J'ai tendance à penser que cela dépend du niveau de granularité que l'on souhaite au moment de l'analyse, il peut aussi y avoir différents niveaux de détails ou de découpage, plusieurs vue de uc pour un même cas


    Les UCs doivent comporter des termes fonctionnels.
    Relis ma première remarque, on peut avoir un cas "optimiser sqlcore" d'en écrire des cas puis d'en extraire des classes candidates pour l'implémentation

Discussions similaires

  1. Réponses: 4
    Dernier message: 11/09/2009, 16h11
  2. Acteurs d'un Cas d'Utilisation
    Par abygae dans le forum Cas d'utilisation
    Réponses: 3
    Dernier message: 24/04/2009, 13h50
  3. [Modélisation] Cas d'utilisation et acteurs
    Par ftrifiro dans le forum Cas d'utilisation
    Réponses: 5
    Dernier message: 30/01/2005, 15h20

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo