Debug / Narrative
Jak czytać Diagnostic Story
Historia diagnostyczna porządkuje dowody wokół wybranego zdarzenia. Nie gwarantuje znalezienia jednej przyczyny każdego zachowania systemu.
Co zawiera historia?
| Część | Co odczytać? |
|---|---|
| Zdarzenie i zadanie | Wybrany event, rozpoznany symbol i źródło |
| Timeline | Ograniczone otoczenie zdarzeń danego zadania |
| Causal chain | Powiązania złożone na podstawie dostępnych danych i reguł Collectora |
| Concurrent events | Zdarzenia, dla których zegary wektorowe dają dowód współbieżności |
| Communications | Rozpoznane komunikacje, zadania i powiązanie ze źródłem |
| Evidence | Jawne informacje o sposobie złożenia historii i brakujących danych |
| Build i bundle | Tożsamości przechwycone przy wykonaniu, jeżeli zostały dostarczone |
Kolejność a dowód
Zegar Lamporta pomaga porządkować zdarzenia, lecz sam porządek nie wystarcza do dowiedzenia przyczynowości albo braku wyścigu. Dowód współbieżności wymaga odpowiednich zegarów wektorowych. Pusta lista concurrent events może wynikać z braku tych danych.
Od ramki do historii
Zatrzymana ramka może zostać powiązana ze zdarzeniem przez stabilny symbol, źródło i tożsamość budowania. Gdy dowody nie pasują, poprawnym wynikiem jest brak dopasowania. Podobna nazwa zadania nie wystarcza.
Gdzie pojawia się Mentor?
Mentor dostarcza kontekst statycznej analizy projektu. Ustalenia związane ze stabilnymi symbolami mogą towarzyszyć Story. Nie stają się przez to przyczyną zdarzenia wykonania.
Test integracji Studio uruchomił prawdziwy Collector, wysłał przygotowane zdarzenia i sprawdził wybór oraz odczyt historii. To dowód integracji, a nie rejestracja kompletnego systemu z fizycznym urządzeniem.