UML représentation pour le C/C++ pointeurs de fonction

Quelle serait la meilleure représentation d'un C/C++ pointeur de fonction (pf) dans un UML structurels diagramme?

Je suis en train de réfléchir à l'aide d'un élément de l'interface, peut-être, même si "dégénérée", avec la contrainte d'avoir plus qu'une seule opération déclarée.

J'ai trouvé une certaine proposition dans ce document: C et UML Synchronisation Guide de l'Utilisateur, Section 5.7.4. Mais cela semble assez lourd et pas très utile dans la pratique. Même si le droit d'un niveau très bas de vue sémantique. Voici un schéma présentant leur concept en bref:
UML représentation pour le C/C++ pointeurs de fonction

À mon humble avis en C et C++ pointeurs de fonction sont utilisés en tant que tels une vision étroite d'une interface qui ne fournit qu'une seule fonction et de signature. En C fp serait également utilisé pour implémenter plusieurs interfaces complexes de la déclaration d'une structure contenant un ensemble de pointeurs de fonction.

Je pense que je peux même gérer pour obtenir mon outil UML particulier (Enterprise Architect) à l'avant de générer le code est correct, et la synchronisation avec les changements de code, sans préjudice.

Mes questions sont:

  1. Serait déclaration de la fp dans le cadre des éléments de l'interface UML fournissent une bonne vue sémantique?
  2. Ce genre de stéréotype doit être utilisé pour la fp déclaration? Au moins j'ai besoin de fournir une définition de type dans le code ce serait donc mes tripes choix.(j'ai trouvé ce stéréotype est la propriété exclusive de Enterprise Architect) et j'ai besoin de préciser stéréotype pour obtenir la génération de code adapté. En fait, j'ai choisi le stéréotype nom de "délégué", est ce que cela a des conséquences ou de la sémantique des collisions?
  3. Comme pour C++, serait imbrication d'un "délégué" sterotyped interface dans une classe d'élément suffisant pour exprimer une fonction membre de classe pointeur correctement?

Voici un exemple de diagramme de mes pensées pour le langage C de la représentation:
UML représentation pour le C/C++ pointeurs de fonction

C'est le code C qui devraient être générés à partir du modèle ci-dessus:

struct Interface1;

typedef int (*CallbackFunc)(struct Interface1*);

typedef struct Interface1
{
    typedef void (*func1Ptr)(struct Interface1*, int, char*);
    typedef int (*func2Ptr)(struct Interface1*, char*);
    typedef int (*func3Ptr)(struct Interface1*, CallbackFunc);

    func1Ptr func1;
    func2Ptr func2;
    func3Ptr func3;

    void* instance;
};

/* The following extern declarations are only dummies to satisfy code
 * reverse engineering, and never should be called.
 */
extern void func1(struct Interface1* self, int p1, char* p2) = 0;
extern int func2(struct Interface1* self, char*) = 0;
extern int func3(struct Interface1* self, CallbackFunc p1) = 0;

EDIT:

Tout le problème se résume quelle serait la meilleure façon avec les UML outil à portée de main et son code spécifique à l'ingénierie. Ainsi, j'ai ajouté de l'entreprise-architecte de la balise.

  • Une primitive de type de données si votre question est sérieuse, je l'ai mentionné ce (suivre le document lié).
  • J'ai été très grave, mais en effet rhétorique et de ne pas se moquer de vous ou de quelqu'un d'autre. Je crois tout simplement que, parfois, nous devons revenir à l'essentiel.
  • Au moins, j'étais confus lire l'allemand ici. Mais de toute façon, je ne vois que l'utilisation d'un uml:Type de données serait ressembler à ma proposition, malheureusement je ne peux pas imbriquer les Types de données à l'intérieur des classes avec mon outil UML (qui est probablement à droite) et aurait besoin de plus de typedefs, ce qui rend le diagramme de moins claire de son intention.
  • Je dois corriger moi-même: Un pointeur de fonction n'est pas un <<primitive>> mais <<type>>.
  • Je pense que cette approche est erronée dans le début. Pourquoi auriez-vous besoin de modèle de pointeur de fonction des objets?
  • Principalement pour obtenir une granularité fine de contrôle sur la génération de code de l'outil UML, la curiosité est un autre aspect.

InformationsquelleAutor | 2012-12-01