2009-06-03 47 views
31

Dekompozycja funkcjonalna, do czego jest przydatna i jakie są jej zalety/wady? Gdzie są przykłady sprawdzonych metod użycia?Czym jest funkcjonalna dekompozycja?

+11

Zapytałem, ponieważ nie ma już odpowiedzi na temat SO, i istnieje pewna krytyka FD jako metody projektowania na http://stackoverflow.com/questions/250044/design-pattern-or-code-smell-denormalised -data-as-result-of-functional-decompo/250132 # 250132 –

+23

Gdzie jest napisane, że żadne pytanie nie powinno być zadawane na SO, chyba że ma niskie trafienia w Google? –

Odpowiedz

54

Dekompozycja funkcjonalna jest procesem złożonego procesu i podzielenia go na mniejsze, prostsze części.

Na przykład pomyśl o użyciu bankomatu. Można rozkładać proces w:

  1. chodzić do bankomatu

  2. włożeniu karty bankowe

  3. wprowadzić kod PIN

dobrze ... masz punkt.

Możesz myśleć o programowaniu w ten sam sposób. Pomyśl o oprogramowanie uruchomione że Bankomat:

  1. kod do odczytu karty

  2. weryfikację PIN

  3. tworzenie transferu

z których każdy może być podzielone dalej. Po osiągnięciu najbardziej rozłożonych części podsystemu można pomyśleć o tym, jak rozpocząć kodowanie tych elementów. Następnie komponujesz te małe części w większą całość. Sprawdź ten artykuł w Wikipedii:

Decomposition (programming)

Korzyść z rozkładem funkcjonalnym jest to, że po uruchomieniu kodowania, pracujesz na najprostszych składników można ewentualnie pracuję dla danej aplikacji. W związku z tym tworzenie i testowanie tych komponentów staje się znacznie łatwiejsze (nie wspominając już o tym, że możesz lepiej zaprojektować swój kod i projekt, aby pasował do twoich potrzeb).

Oczywistym minusem jest inwestycja czasowa. Wykonanie dekompozycji funkcjonalnej w złożonym systemie zajmuje więcej niż trywialną ilość czasu PRZED rozpoczęciem kodowania.

Osobiście uważam, że ta ilość czasu jest tego warta.

+0

Chciałbym dodać, że służy nie tylko do rozłożenia procesów na swoje funkcje, ale może również służyć do rozłożenia całego systemu na jego mniejsze funkcje. Przy prawidłowym stosowaniu dekompozycja funkcjonalna może być jednym z najszybszych sposobów określenia zakresu i funkcjonalności systemu, komunikacji i uzyskania porozumienia między różnymi zainteresowanymi stronami. Zwykle ludzie uczą się korzystać z diagramu, podobnego do WBS, ale z mojego doświadczenia wynika, że ​​hierarchiczne listy punktorów komunikują się równie skutecznie i jest o wiele łatwiej i szybciej je szkicować i edytować. –

3

Oto przykład: Twój kompilator języka C.

Najpierw jest preprocesor: obsługuje on #include i #define oraz wszystkie makra. Dajesz mu nazwę pliku i niektóre opcje, i zwraca naprawdę długi ciąg. Nazwijmy tę funkcję preprocess(filename).

Następnie jest analizator leksykalny. Pobiera ciąg i dzieli go na tokeny. Nazywają to lex(string). Analizator składni pobiera tokeny i zamienia je w drzewo, nazywając je parse(tokens). Następnie jest funkcja do konwersji drzewa do DAG bloków, nazywając to dag(tree). Zadzwoń do nadawcy kodu emit(dag), który pobiera DAG z bloków i wypluwa asembler.

Kompilator jest następnie:

emit(dag(parse(lex(preprocess(filename))))); 

Mamy rozkłada się wielki, trudny do zrozumienia funkcji (funkcja compile) pod bandą mniejsze, łatwiejsze do zrozumienia funkcji. Nie musisz robić tego jako potok, możesz napisać swój program jako:

process_data(parse_input(), parse_config()) 

To jest bardziej typowe; kompilatory są dość głębokimi programami, większość programów jest szeroka w porównaniu.

6

To samo jak budowle WorkBreakDown (WBS), mindmapping i odgórnie rozwoju - w zasadzie złamanie dużego problemu na mniejsze, bardziej zrozumiałymi podczęści.

Plusy

  • pozwala na proaktywne podejście do programowania (resiting chęć Code)
  • pomaga zidentyfikować złożone i/lub ryzyka obszary projektu (w przykładzie ATM, bezpieczeństwo jest prawdopodobnie bardziej złożony komponent)
  • pomaga zidentyfikować WSZYSTKIE komponenty projektu - # 1 przyczyną awarii projektu/kodu (przez Capersa Jonesa) są brakujące elementy - rzeczy, o których nie pomyślano aż do końca projektu (gee, nie zdawałem sobie sprawy Musiałem sprawdzić saldo osoby przed wydaniem $)
  • pozwala na oddzielenie części dla lepszego programowania, udostępnianie kodu i podziału pracy

Przeciw - nie istnieją żadne realne CONS w robi rozkładowi, jednak istnieją pewne wspólne błędy

  • nie uszkodzi wystarczająco daleko lub zepsucie się do daleka - każda osoba musi określić szczęśliwy poziom szczegółowości potrzebny do zapewnienia im wglądu do komponentu bez przesady (nie rozpadaj się na linie programistyczne kodu ...)
  • nie przy uwzględnieniu wcześniej istniejących wzorców/modułów kodu (przeróbek)
  • nie zapoznaniu się z klientami w celu zapewnienia zakresu jest poprawna
  • nie stosując podział kiedy faktycznie kodowania (jak projektując dom niż zapominając o planie i po prostu zaczyna paznokci kilka desek razem)
1

dekompozycji funkcjonalnej jest pomocny przed utworzeniem dokumentów wymagań funkcjonalnych. Jeśli potrzebujesz oprogramowania do czegoś, rozkład funkcjonalny odpowiada na pytanie "Jakie funkcje musi zapewniać to oprogramowanie?". Dekompozycja jest potrzebna do zdefiniowania funkcji drobnoziarnistych. "Potrzebuję oprogramowania do pomiaru efektywności energetycznej" jest zbyt ogólne. Właśnie dlatego dzielimy to na mniejsze części, aż do momentu, w którym wyraźnie zrozumiemy wszystkie funkcje, jakie muszą zapewnić systemy. Może to być później wykorzystane jako lista kontrolna dla kompletności systemu.

Dokument wymagań funkcjonalnych (FD) to w zasadzie tekstowe przedstawienie dekompozycji funkcjonalnej. Kodowanie bezpośrednio z FD może być w porządku dla języków proceduralnych, ale nie jest wystarczająco dobre dla rozwiązań obiektowych, ponieważ nie identyfikuje obiektów. Nie nadaje się również do planowania i testowania użyteczności.

Uważam, że powinieneś poświęcić trochę czasu na stworzenie FD, ale nie używać go zbyt często. Skonsultuj się z każdą osobą, która zna proces, który podążasz za swoim systemem, aby znaleźć wszystkie potrzebne funkcje.

Mam duże doświadczenie w projektowaniu, projektowaniu i sprzedaży oprogramowania, a jako pierwszy krok do rozwoju używam rozkładu funkcjonalnego. Używam go jako bazy do umowy, więc klient wie, co dostanie i wiem, co muszę dostarczyć.