Cycles dans les logiciels d'arbres généalogiques

Question

Je suis le développeur d'un logiciel d'arbre généalogique (écrit en C++ et Qt). Je n'ai eu aucun problème jusqu'à ce que l'un de mes clients m'envoie un rapport de bogue. Le problème est que le client a deux enfants avec leur propre fille, et, par conséquent, il ne peut pas utiliser mon logiciel à cause d'erreurs.

Ces erreurs sont le résultat de mes diverses assertions et invariants concernant le graphe familial en cours de traitement (par exemple, après avoir parcouru un cycle, le programme déclare que X ne peut pas être à la fois le père et le grand-père de Y).

Comment puis-je résoudre ces erreurs sans supprimer toutes les assertions de données ?

Answer 1

Il semble que vous (et/ou votre entreprise) ayez une incompréhension fondamentale de ce qu'est censé être un arbre généalogique.

Permettez-moi de préciser que je travaille également pour une société dont l'un des produits est un arbre généalogique et que nous avons été confrontés à des problèmes similaires.

Le problème, dans notre cas, et je suppose dans le vôtre aussi, vient du fait que GEDCOM Un format qui a une opinion très tranchée sur ce que devrait être une famille. Cependant, ce format contient de graves idées fausses sur ce à quoi ressemble réellement un arbre généalogique.

La GEDCOM présente de nombreux problèmes, comme l'incompatibilité avec les relations entre personnes du même sexe, l'inceste, etc... Ce qui, dans la vie réelle, arrive plus souvent qu'on ne l'imagine (surtout quand on remonte dans le temps jusqu'aux années 1700-1800).

Nous avons calqué notre arbre généalogique sur ce qui se passe dans le monde réel : Les événements (par exemple, les naissances, les mariages, les fiançailles, les unions, les décès, les adoptions, etc.) ). Nous n'imposons aucune restriction à ces événements, à l'exception de ceux qui sont logiquement impossibles (par exemple, on ne peut pas être son propre parent, les relations nécessitent deux individus, etc.

L'absence de validations nous donne une solution plus "réelle", plus simple et plus flexible.

En ce qui concerne ce cas spécifique, je suggérerais de supprimer les affirmations car elles ne sont pas universelles.

Pour les problèmes d'affichage (qui se présenteront), je suggérerais de dessiner le même nœud autant de fois que nécessaire, en faisant allusion à la duplication en éclairant toutes les copies lors de la sélection de l'une d'entre elles.

Answer 2

Détendez vos affirmations.

Pas en modifiant les règles, qui sont très probablement très utiles à 99,9 % de vos clients pour détecter les erreurs de saisie de leurs données.

Au lieu de cela, changez le message d'erreur "impossible d'ajouter une relation" en un avertissement avec un "ajouter quand même".

Answer 3

Voici le problème des arbres généalogiques : ce ne sont pas des arbres. Ce sont des graphes acycliques dirigés ou DAG. Si je comprends bien les principes de la biologie de la reproduction humaine, il n'y a pas de cycles.

Pour autant que je sache, même les chrétiens acceptent les mariages (et donc les enfants) entre cousins, ce qui transformera l'arbre généalogique en un DAG familial.

La morale de l'histoire est la suivante : choisissez les bonnes structures de données.

Answer 4

Je suppose que vous avez une valeur qui identifie de manière unique une personne sur laquelle vous pouvez baser vos contrôles.

C'est une question délicate. En supposant que vous voulez garder la structure d'un arbre, je suggère ceci :

Supposez ceci : A a des enfants avec sa propre fille.

A s'ajoute au programme en tant que A et comme B . Une fois dans le rôle de père, appelons-le petit ami.

Ajouter un is_same_for_out() qui indique à la partie de votre programme qui génère la sortie que tous les liens allant à B en interne devrait aller à A sur la présentation des données.

Cela représente un travail supplémentaire pour l'utilisateur, mais je pense que l'informatique serait relativement facile à mettre en œuvre et à maintenir.

En partant de là, vous pourriez travailler sur la synchronisation des codes. A y B pour éviter les incohérences.

Cette solution n'est sûrement pas parfaite, mais elle constitue une première approche.

Answer 5

Vous devez vous concentrer sur ce qui fait vraiment la valeur de votre logiciel . Le temps passé à le faire fonctionner pour UN consommateur vaut-il le prix de la licence ? Probablement pas.

Je vous conseille de vous excuser auprès de ce client, de lui dire que sa situation est hors de portée de votre logiciel et de le rembourser.