ale zastanawiałem się nad (konceptualnymi) zaletami oddzielania wyniku od statusu (chociaż wydaje mi się, że można argumentować, że błąd i anulowane są również po prostu innymi stanami niż stan ukończony).
Ogromną zaletą jest opisywanie postępów i identyfikowanie punktów awarii (w rozsądnych granicach), jak w twoim przypadku. Myślę, że zamieszanie wynika z pojęć „status” i „stan” - musimy je zakwalifikować. Na przykład „Status zadania”, nawet to nie jest bardzo precyzyjne, więc możemy chcieć użyć „Statusu wykonania zadania”, jednak jest to błędne, ponieważ masz już krok wykonania. Możemy używać nazwy „Status przetwarzania zadania”, a wartości: „inicjowane - sprawdzanie poprawności - wykonywanie - zakończone” mają sens. Rzeczywiście moglibyśmy dodać „Anulowane” do listy. „Błąd” nie odpowiada jednak na takie pytanie: Jaki jest status przetwarzania zadania bardzo dobrze. Wygląda na to, że „Błąd” to status podrzędny Zakończony . Więc co robimy? Mogliśmy zmiana nazwy Zakończony byćUkończono OK, a następnie możemy dodać do listy opcję Ukończono z błędem . Zatem ostateczna lista wartości statusu przetwarzania zadania to:
Zapoczątkowany,
Zatwierdzony,
Wykonywanie,
Anulowany,
Zakończono OK,
Ukończono z błędem
Edycja: teraz powyższa lista wciąż wymaga trochę pracy. Pierwsze 4 pozycje nie zawierają słowa „OK”. Jeśli więc lepiej jest dopasować stan „Ukończono OK”. Drugą rzeczą jest to, że pierwsze 4 pozycje nie mają „z błędem” - co to znaczy? Co się stanie, gdy „wykonywanie” zakończy się nienormalnie - czy wymaga to nowego stanu „wykonanie z błędem”? W tym momencie może być wymagane więcej danych wejściowych i analiz.
