Jak podejść do problemów projektowych, takich jak "zaprojektuj automat"

Question

Chciałem wiedzieć, jakie kroki należy wykonać, aby podejść do problemów, takich jak zaprojektowanie automatu sprzedającego i opracować szereg dokumentów projektowych (takich jak przypadek użycia, sekwencja schemat, diagram klasowy). Czy istnieje źródło/link, który mogę przeczytać tam, gdzie mówi o tym, jak przejść krok po kroku.

Dzięki.

Answer 1

Nie jestem pewien, czy istnieje jakikolwiek powszechnie akceptowany zestaw kroków, ale najłatwiej jest po prostu zepsuć każdy krok tak daleko, jak to możliwe.

1. Zacznij główne działania (wprowadzenie pieniędzy, naciskając wybór, otrzymując napój)
2. dalej rozkładających każde działanie w mniejszych działań i reakcji, aż stanie się niemal trywialna. Aby wpłacić pieniądze, musisz wiedzieć, ile zostało wpłacone, suma, jaka została wpłacona, kwota do wyświetlenia itp.
3. Pomyśl o wszelkich scenariuszach, w których Twoje działania nie byłyby ważne (naciskasz wybór, a maszyna jest pusta) i jak sobie z tym poradzisz. (zwróć pieniądze, poproś o inny wybór, itp.)
4. Przypisuj działania i odpowiedzi do aktorów i do systemu. Kto wkłada pieniądze, kto śledzi bieżącą sumę?

Następnie możesz oprzeć swoje diagramy sekwencji i diagram klas od tego, co wymyśliłeś.

Answer 2

Cóż, automat jest w zasadzie state machine.

Chciałbym zdecydować, jakie będą ważne dane wejściowe (monety i banknoty?) I jakie będą wyniki.

Jakie są prawdopodobne wyniki od użytkownika podchodzącego do maszyny. Jakie problemy mogą wystąpić? (za dużo pieniędzy, za mało pieniędzy) Jak będą obsługiwane? (zmiana wydawania, zwrot pieniędzy)

Wreszcie, napisz, co jest potrzebne, aby poradzić sobie z przypadkami użycia. Twoje rzeczowniki to prawdopodobnie klasy. Twoje czasowniki są prawdopodobnie metodami należącymi do tych klas.

Answer 3

Ogólnie, pomyśl o jakie obiekty są zaangażowane w automacie:

• VendingMachine - ewentualnie klasa abstrakcyjna
• DrinkMachine, SnackMachine i zajęcia rozciągające VendingMachine
• VendingProduct - klasa abstrakcyjna?
• Drink inne klasy rozciągające VendingProduct
• Coke innych klas rozciągające Drink
• & c, & C.

Ale jestem pewien, że możesz to łatwo zrozumieć. Nakrętki i śruby maszyny będą miały pewną klasę użytkową, z metodami akceptowania rachunków i monet, obliczania zmian itp.

Dalsze czytanie:

• Here jest dobry artykuł na rozpoczynający się projekt OOP, Allen Holub.
• Here to początek projektu automatów do kawy z wykorzystaniem OOP.

Answer 4

początek definiując "maszynę sprzedawca":

Maszyna sprzedawca jest maszyną, która .....

presto! są twoje wymagania.

Answer 5

te myśli mogą pomóc:

Z punktu widzenia interfejsu zdefiniowanie wejść, wyjść, oczekiwane warunki, warunki błędach.

Zdecyduj, jak dobrze musi wyglądać.

Jak długo musi działać (żywotność).

Jak często musi być uzupełnianie zapasów?

Answer 6

Zakładam, że już widziałeś this link.

Nie myśl najpierw o kodzie (klasy, & c.). Pomyśl o przypadkach użycia i wymaganiach funkcjonalnych. Jaką funkcjonalność ma zapewniać automat vendingowy? W jaki sposób użytkownicy mają z nim współdziałać? A co z opiekunami? Staraj się nie mylić szczegółów implementacji z wysokimi wymaganiami, robiąc to.

Następnie, w zależności od rodzaju projektu dla klasy , pomyśl o wymaganiach niefunkcjonalnych. Jaki jest najważniejszy atrybut: szybkość, niezawodność, łatwość konserwacji, zdolność adaptacji do nowych sytuacji, bezpieczeństwo ...? Istnieją inne możliwości. Nie są to odpowiedzi binarne, tak/nie, myślcie więcej w kategoriach zakresów i minimalnych standardów w stosunku do optymalnych celów. Uwaga: "optymalny" zależy od punktu widzenia danego interesariusza. Łatwość użycia i bezpieczeństwo często są w konflikcie, więc musisz dowiedzieć się, co jest ważniejsze.

Następnie możesz wrócić do swoich przypadków użycia i sprawdzić, w jaki sposób wpływają na Twoje niefunkcjonalne wymagania. To tutaj odbywa się negocjacja z klientem, który w tym przypadku jest prawdopodobnie tobą. Czy musisz poświęcić funkcje, aby osiągnąć inny cel? Dla każdej cechy, jakie jest ryzyko w stosunku do nagrody? Łatwe do wdrożenia funkcje zapewniające wysoką wartość są świetne. Trudne do wdrożenia (z powodu ograniczeń) funkcje, które dodają jedynie niewielką wartość, powinny być wyraźnie priorytetowo traktowane jako ostatnie. Pozostałe dwie kombinacje wymagają starannego namysłu.

Następnie można rozpocząć projektowanie urządzenia.

Istnieje wiele różnych schematów, które można wykorzystać do wizualizacji problemu lub wyjaśnienia proponowanego rozwiązania innym.

Answer 7

Istnieje nie tylko jeden właściwy sposób zaprojektowania całego oprogramowania od podstaw!

Prawdopodobnie istnieje kilkadziesiąt różnych podejść, od bardzo niewielkiego projektu z góry, takiego jak w Evolutionary Design do Big Up Front Design, który został napisany w August 2005 on JoelOnSoftware. Prawdopodobnie istnieje więcej niż kilka metod, które mają swoje miejsce, więc zależy to od metodologii, z której chcesz korzystać, ponieważ niektóre z nich mogą wymagać większego projektu z góry, jak w przypadku Waterfall, w porównaniu z czymś bardziej zwinnym, gdzie wymagania mogą się zmieniać regularnie, a to nie działa. T powoduje wiele problemów, a przynajmniej taka jest teoria.

Answer 8

podejść do takich problemów

1. Określenie wymagań, funkcjonalność USECASE

2. rozbić tych wymogów do zadań banalnych i podstawowych

3. Zidentyfikuj Challanges i problemów, które użytkownik może napotkać, a od systemu perspektywa. wszystkie nieprawidłowe scnearios. wymagania takie jak wydajność, bezpieczeństwo, niezawodność.
4. Zidentyfikuj rozwiązanie wszystkich wyzwań i problemów wymienionych wcześniej:
5. zaznacz wszystkie rzeczowniki jako klasy i czasowniki oraz czynność jako metodę. określ także publiczne interfejsy dla klasy na podstawie tego, w jaki sposób klasy będą współdziałać ze sobą iz zewnętrznymi aktorami, na podstawie scenariusza i opisu problemu, spróbuj zastosować dowolny wzór projektu, jeśli je znasz. (Tylko pokazać swoją znajomość wzorców projektowych add on)
6. zaprezentować swój projekt za pomocą diagramów przypadków użycia klasy diagramów itp

i na pewno zadać wiele pytań, aby wyczyścić wymagania

Answer 9

W przypadku niektórych problemów (np. Automatów sprzedających) można je rozwiązać za pomocą projektowania obiektowego za pomocą narzędzia State Machine.

Początkowy status jest bezczynny i przechodzi do pisania, jeśli zaczynasz wpisywać, pozwala to wyczyścić, anulować i przesłać przy wpisywaniu pozycji wiersza i kolumny, następnie dba o płatność po przesłaniu wiersza pozycji i numeru kolumny, wreszcie wyskoczy przedmiot, jeśli zostanie opłacony, inaczej zapłacisz ponownie.

Dla klas w automacie do sprzedaży powinny znajdować się przyciski do wskazania numeru wiersza (A, B, C) i kolumny (1, 2, 3), niektórych przycisków do wyczyszczenia, anulowania lub przesłania liczb wierszy i kolumn, niektóre automaty do przyjmowania płatności (gotówka, moneta, karta kredytowa/debetowa), niektóre automaty do przechowywania przedmiotów (napoje, przekąski itp.).

Patrz blog