Modèle de conception approprié pour un analyseur de journal des événements?

Question

Travailler sur un projet qui analyse un journal des événements, puis met à jour un modèle en fonction des propriétés de ces événements. J'ai été assez paresseux pour "y arriver". et plus préoccupés par l'optimisation initiale, le code Lean et les modèles de conception appropriés. Principalement une expérience d'auto-apprentissage. Je m'intéresse aux modèles que les concepteurs plus expérimentés jugent pertinents, ou au type d'architecture d'objet pseudocodé qui serait la meilleure, la plus facile à maintenir, etc.

.

Il peut y avoir 500 000 événements dans un seul journal, et il existe environ 60 types d'événements, qui partagent tous environ 7 propriétés de base, puis ont de 0 à 15 propriétés supplémentaires en fonction du type d'événement. Le type d'événement est la deuxième propriété du fichier journal de chaque ligne.

J'ai donc essayé un analyseur impératif vraiment moche qui parcourt le journal ligne par ligne, puis traite les événements ligne par ligne. Ensuite, j’ai essayé une spécification lexicale qui utilise un " nextEvent " motif, qui est appelé dans une boucle et traité. Ensuite, j'ai essayé un vieil article "Analyser". méthode qui ne retourne jamais et déclenche simplement des événements pour les rappels d'écouteur enregistrés. J'ai essayé à la fois un rappel unique quel que soit le type d'événement et une méthode de rappel spécifique à chaque type d'événement.

J'ai essayé un "événement" de base classe avec une union de toutes les propriétés possibles. J'ai essayé d'éviter le "nouvel événement". call (car il peut y avoir un très grand nombre d’événements et que les objets d’événement sont généralement de courte durée) et avoir les méthodes de rappel par type avec des arguments de propriété primitifs. J'ai essayé de créer une sous-classe pour chacun des 60 types d'événements avec un parent d'événements abstrait avec les 7 propriétés de base communes.

J'ai récemment essayé d'aller plus loin et d'utiliser un modèle de commande pour définir le code de gestion des événements par type d'événement. Je ne suis pas sûr d’apprécier cela et son approche vraiment semblable à celle des rappels par type, mais le code est contenu dans une fonction d’exécution des sous-classes de types par rapport aux méthodes de rappel par type.

Le problème est qu’une grande partie de la logique de mise à jour du modèle est partagée, et qu’elle est en grande partie spécifique à la sous-classe, et je commence tout juste à être troublée par tout. J'espère que quelqu'un pourra au moins m'indiquer une direction à prendre en compte!

Answer 1

Eh bien ... pour une chose plutôt que pour une seule classe d'événements avec une union de toutes les propriétés, ou 61 classes d'événements (1 base, 60 sous-titres), dans un scénario comportant autant de variations, je serais tenté de avoir une seule classe d'événements qui utilise un sac de propriétés (dictionnaire, hashtable, w / e qui flotte dans votre bateau) pour stocker les informations sur les événements. Le type d'événement est juste une valeur de propriété supplémentaire qui est mise dans le sac. La raison principale pour laquelle je me pencherais de cette façon est simplement parce que je n’aimerais pas conserver 60 classes dérivées de quoi que ce soit.

La grande question est de savoir ce que vous devez faire avec les événements lors de leur traitement. Les formatez-vous dans un rapport, les organisez-vous dans une table de base de données, réveillez-vous les personnes si certains événements se produisent ... quoi?

S'agit-il d'un analyseur après coup ou d'un gestionnaire d'événements en temps réel? Je veux dire, surveillez-vous le journal au fur et à mesure que les événements arrivent ou analysez-vous simplement les fichiers du journal le lendemain?

Answer 2

Prenons une usine d’objets Stratégie Flyweight, une par classe d’événement.

Pour chaque ligne de données d'événement, recherchez la stratégie d'analyse appropriée à partir de la fabrique flyweight, puis transmettez-la à la stratégie d'analyse. Chacun des 60 objets de stratégie peut appartenir à la même classe, mais être configuré avec une combinaison différente d’objets d’analyse de champs. C'est un peu difficile d'être plus précis sans plus de détails.

Answer 3

Peut-être Objets d'adaptateur hachés trouvez une bonne explication sur le Web - ils semblent faire défaut.)

Answer 4

Juste du haut:

J'aime la suggestion faite dans la réponse acceptée de ne créer qu’une classe avec une carte de propriétés. Je pense aussi que le behvavior peut être assemblé de cette façon:

class Event
{
    // maps property name to property value
    private Map<String, String> properties;

    // maps property name to model updater
    private Map<String, ModelUpdater> updaters; 

    public void update(Model modelToUpdate)
    {
        foreach(String key in this.properties.keys)
        {
            ModelUpdater updater = this.updaters[key];
            String propertyValue = this.properties[key];

            updaters.updateModelUsingValue(model, propertyValue);
        }
    }

}

La classe ModelUpdater n'est pas illustrée. Il met à jour votre modèle en fonction d'une propriété. J'ai rattrapé la boucle; cela peut être ou ne pas être ce que votre algorithme est réellement. Je ferais probablement de ModelUpdater plus d'une interface. Chaque implémenteur serait par propriété et mettrait à jour le modèle.

Ensuite, ma "boucle principale". serait:

Model someModel;

foreach(line in logFile)
{
    Event e = EventFactory.createFrom(line);
    e.update(someModel);
}

EventFactory construit les événements à partir du fichier. Il remplit les deux cartes en fonction des propriétés de l'événement. Cela implique qu’il existe un moyen de faire correspondre une propriété à son programme de mise à jour de modèle associé.

Je n'ai pas de noms de motifs fantaisistes pour vous. Si vous avez des règles complexes telles que si un événement a les propriétés A, B et C, ignorez le programme de mise à jour du modèle pour B, cette approche doit alors être étendue d'une manière ou d'une autre. Très probablement, vous devrez peut-être injecter des règles dans EventFactory d'une manière ou d'une autre à l'aide du modèle d'objet de règle. Voilà, il y a un nom de motif pour vous!

Answer 5

Je ne suis pas sûr de bien comprendre le problème. Je suppose qu'il existe une «logique de mise à jour de modèle» complexe. Ne distribuez pas cela dans 60 classes, conservez-le au même endroit, déplacez-le des classes d'événements (modèle Mediator, en quelque sorte).

Votre médiateur fonctionnera avec les classes d’événement (je ne vois pas comment vous pourriez utiliser le poids-lourd ici), les événements peuvent s’analyser eux-mêmes.

Si les règles de mise à jour sont très compliquées, vous ne pouvez pas vraiment résoudre le problème avec un langage de programmation à usage général. Pensez à utiliser un moteur basé sur des règles ou quelque chose du genre.