Jakie są zalety oddzielenia „wyniku” od „statusu”

Załóżmy, że masz zautomatyzowane procesy, które zasadniczo przechodzą przez następujące stany; zaplanowane - zainicjowane - sprawdzanie poprawności - wykonywanie - zakończone

Ponadto procesy te mogą przedwcześnie zakończyć się z powodu błędu lub wyraźnego anulowania użytkownika.

Moim pierwszym impulsem jest po prostu dodanie błędu i anulowanie do listy możliwych wartości statusu, ale zastanawiałem się nad (koncepcyjnymi) zaletami oddzielania wyniku od statusu (chociaż wydaje mi się, że można argumentować, że błąd i anulowane są również po prostu inne stany niż stan ukończony ).

Stan przypisywany do procesów powinien odzwierciedlać to, co twój program (lub użytkownicy, jeśli tylko wizualizujesz stany), zrobią z tymi informacjami. Czy masz zatem obowiązek oceny / pokazywania stanu swoich procesów, o ile są one uruchomione i nie wykazują błędów? Następnie oddziel wynik od statusu . Jeśli potrzebujesz statusu po zakończeniu procesu, nie rozdzielaj go.

Nie powinieneś modelować niczego tylko ze względu na modelowanie. Lepiej sprawdź swoje wymagania. A jeśli nie masz pewności, czego możesz później potrzebować, wybierz najmniejsze i najprostsze rozwiązanie dla wymagań, które znasz na pewno. Jeśli tylko zgadujesz, w 90% wszystkich przypadków zgadniesz źle, więc i tak będziesz musiał zmienić swój model później.

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.