Kitten a assumé des responsabilités en continu, ce qui a été un coup dur pour son cœur. C'était la première fois de sa carrière. Si vous êtes intéressé par la situation du chaton, vous pouvez en apprendre davantage sur les « événements idempotents » et les « événements de rupture de cache ».
Ce jour-là, le chef d'équipe est venu dans une salle de conférence avec le chaton.
Tant d'accidents se sont produits en si peu de temps. Je comprends que ce n'est pas facile pour vous, après tout, vous venez de reprendre ce projet. Il y a peut-être des problèmes avec le projet lui-même. Maintenant, la responsabilité vous incombe, j'espère que vous ne vous découragerez pas...", a poursuivi le chef d'équipe.
Le chaton regarda le poussin et hocha la tête, se sentant soulagé. J'ai pensé : « Il semble que le chef d'équipe ne critiquera pas ma performance. »
Cependant, des problèmes sont survenus et il peut y avoir d'autres problèmes avec le système, notamment des aspects commerciaux, de code ou de conception. Veuillez prendre le temps d’organiser et de préparer une analyse des documents de votre projet. Nous sommes impatients de vous voir partager l’état actuel du système avec vous lors de notre prochaine réunion mensuelle.
Le petit chat hocha la tête à plusieurs reprises, pensant dans son esprit : "Cela devrait être considéré comme attraper un modèle déguisé, c'est tout. Mais comment dois-je rédiger un tel document ?"
À ce moment-là, le chaton a recommencé à se sentir mal à l'aise.
Quand on reprend un nouveau système, comment se familiariser avec celui-ci ? En fait, Laomao a demandé à tout le monde à la fin du dernier article « Incident de pénétration du cache ». Je me demande si vous avez encore des impressions ?
Parlons maintenant du processus de familiarisation du vieux chat avec un nouveau système. J'espère que ces expériences vous seront utiles et vous êtes invités à partager vos propres méthodes. Les principales étapes sont les suivantes :
Connaissance du projet
Après avoir reçu un nouveau système commercial, nous devons d'abord savoir au moins ce que fait le système actuel, nous devons donc parfois prendre le temps de trouver le chef de produit concerné pour comprendre l'entreprise. À ce stade, le chef de produit peut discuter avec vous. sur la situation actuelle. Certains statuts et antécédents commerciaux, mais peuvent également vous lancer directement une version V0-Vn du plan des exigences du produit et vous informer qu'il n'est pas disponible. Si c'est ce dernier cas, n'oubliez pas de vous retenir et de ne pas frapper le visage du produit avec le moniteur, car votre coopération n'a pas encore commencé... Je plaisante, passons aux choses sérieuses.
Commençons par comprendre ce qu'est un diagramme de cas d'utilisation.
Une brève analyse du diagramme de cas d'utilisation
Un cas d'utilisation est une unité fonctionnelle du système et peut être décrit comme une interaction entre l'exécuteur et le sujet. Un acteur est le rôle idéalisé d'un utilisateur externe, d'un processus ou d'un autre système qui interagit avec un système, un sous-système ou une classe.
Objectif : Capable de répertorier les cas d'utilisation et les exécuteurs dans le système, et d'afficher quel exécuteur participe à l'exécution de quel cas d'utilisation.
Pour le « point commercial de commande et de paiement » que Mao Mao a rencontré auparavant, dessinons un diagramme de cas d'utilisation pour l'illustrer. Comme indiqué ci-dessous :
Cas d'utilisation
L'image ci-dessus est en fait un simple diagramme de cas d'utilisation. Ce que nous devons comprendre, c'est la signification des différentes lignes.
De cette façon, nous pouvons avoir une compréhension claire de la situation actuelle de l'entreprise.
Après avoir trié les points de fonction du système et les formulaires commerciaux actuels, nous pouvons intervenir et examiner le modèle de système existant, c'est-à-dire les tables de la base de données DB. De cette façon, nous pouvons savoir comment le système actuellement conçu fait abstraction de l’entreprise. Ensuite, en regardant les tableaux associés, nous pouvons dessiner lentement le diagramme ER.
Qu'est-ce que le diagramme ER
Le diagramme E-R est le nom complet du diagramme Entity-Relation. Il fournit une méthode pour représenter les types d'entités, les attributs et les relations, et est utilisé pour décrire le modèle conceptuel du monde réel.
Grâce à sa définition, nous savons en fait qu'il y a trois points importants dans le diagramme ER, à savoir la classe d'entité, les attributs et les connexions. Lorsque nous organisons la table DB, elle correspond en fait à notre table, aux champs de la table et à la relation entre les tables et les tables correspondantes.
Regardons un exemple. Dessinons la logique de produit sous-jacente d'un système général de centre commercial.
Exemple ER
Expliquez la signification de chaque image :
Dans l'image ci-dessus, nous pouvons en fait voir plus clairement qu'il existe trois concepts d'entités importants dans le système actuel, à savoir les matières premières, les pools de matières premières et les étagères. Sur la photo, nous pouvons également voir grossièrement la relation entre eux.
Après avoir trié le diagramme ER, il sera probablement clair comment le diagramme métier du cas d'utilisation mentionné ci-dessus est résumé dans le système existant.
Après avoir parlé de cela, regardons les choses du point de vue de Dieu. Nous avons donné un squelette au système actuel, puis nous devons laisser son cœur se mettre à battre, son sang affluer, et laisser le système tout entier recevoir une âme. Ensuite, nous enchaînerons les modèles tout au long du processus.
Regardons directement l'exemple. En fait, Laomao pense que trier l'organigramme peut être relativement simple, mais la difficulté est de savoir comment contrôler les liens dans l'ensemble du processus. Si vous réfléchissez plus attentivement lorsque vous dessinez, vous pouvez enregistrer chaque étape de l'inventaire. Dans ce cas, l’accent sera moins mis sur les affaires. Si le dessin est épais, la relation correspondante entre les modèles risque de ne pas être bien contrôlée. Par conséquent, Laomao estime que cet endroit est un test de la capacité de généralisation et de compréhension commerciale du programmeur.
Organigramme
Dans l'image ci-dessus, Laomao a simplement dessiné un organigramme. Bien sûr, il peut y avoir des erreurs dans l'organigramme. Ne le prenez pas trop au sérieux. C'est juste pour illustrer une telle chose. processus métier à l’intérieur. Dans le processus ci-dessus, nous voyons le contenu graphique suivant :
La représentation du processus ci-dessus est en fait relativement simple et nous n'avons pas besoin de nous soucier des limites du système. Dessinez simplement.
Mais nos systèmes de développement actuels sont souvent basés sur des microservices, nous devrons donc peut-être considérer le processus d'interaction entre les différents systèmes à l'heure actuelle. A partir de là, nous pouvons introduire le concept de couloirs de nage. Voir ci-dessous.
Processus de couloir de nage
Dans la figure ci-dessus, nous pouvons voir l'interaction entre différentes applications système. Chaque couloir représente l'un des systèmes de microservices. Il s'agit d'une image réelle dessinée par Laomao dans sa familiarité quotidienne avec l'entreprise. Je voudrais souligner une fois de plus que ce que vous devriez regarder, ce sont quelques idées du dessin et ne pas trop vous impliquer dans l'entreprise.
Entrons un peu plus en détail. Par exemple, lorsque nous discutons du flux de statut des commandes, afin de mieux contrôler, nous utiliserons des diagrammes de flux de statut pour le trier.
Transfert de statut
Ce qui précède explique principalement le flux de l'ensemble de l'état dans le processus. Bien sûr, souvent, lorsque les bits d'état sont relativement simples, nous n'avons pas besoin de les dessiner. Peut-être envisagerons-nous de dessiner la machine à états lorsque les états sont plus nombreux. complexe et diversifié.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!