Jak planujesz architekturę aplikacji przed napisaniem kodu? [Zamknięte]

Jedyną rzeczą, z którą się zmagam, jest planowanie architektury aplikacji przed napisaniem jakiegokolwiek kodu.

Nie mam na myśli zbierania wymagań w celu zawężenia tego, co aplikacja musi zrobić, ale raczej skuteczne myślenie o dobrym sposobie rozplanowania ogólnej klasy, struktur danych i przepływu oraz iterowanie tych myśli, aby mieć wiarygodny plan należy pamiętać o działaniu jeszcze przed otwarciem IDE. W tej chwili łatwo jest po prostu otworzyć IDE, stworzyć pusty projekt, zacząć pisać bity i boby i pozwolić, aby projekt „wyrósł” stamtąd.

Rozumiem, że UML to jeden ze sposobów, ale nie mam z nim doświadczenia, więc wydaje się to trochę niejasne.

Jak Ci zaplanować architekturę aplikacji przed pisania kodu? Jeśli UML jest właściwą drogą, czy możesz polecić zwięzłe i praktyczne wprowadzenie dla programistów niewielkich aplikacji?

Doceniam twój wkład.

Naprawdę uważam, że pierwsze pisanie na papierze lub tablicy jest naprawdę kluczowe. Następnie przejdź do UML, jeśli chcesz, ale nic nie przebije elastyczności, jaką daje na początku tylko rysowanie odręczne.

Rozważam następujące kwestie:

1. co system ma zrobić, czyli jaki jest problem, który system próbuje rozwiązać
2. kim jest klient i jakie są jego życzenia
3. z czym system ma się zintegrować
4. czy są jakieś starsze aspekty, które należy wziąć pod uwagę
5. jakie są interakcje użytkownika
6. itp...

Potem zaczynam patrzeć na system jak na czarną skrzynkę i:

1. jakie są interakcje, które muszą się wydarzyć z tą czarną skrzynką
2. jakie zachowania muszą się zdarzyć wewnątrz czarnej skrzynki, tj. co musi się stać z tymi interakcjami, aby czarna skrzynka wykazała pożądane zachowanie na wyższym poziomie, np. odbieranie i przetwarzanie wiadomości przychodzących z systemu rezerwacji, aktualizacja bazy danych itp. .

Wtedy to zacznie przedstawiać system, który składa się z różnych wewnętrznych czarnych skrzynek, z których każdą można dalej podzielić w ten sam sposób.

UML bardzo dobrze reprezentuje takie zachowanie. Większość systemów można opisać za pomocą dwóch z wielu składników UML, a mianowicie:

• diagramy klas i
• diagramy sekwencji.

Diagramy aktywności mogą być również potrzebne, jeśli istnieje jakikolwiek paralelizm w zachowaniu, które należy opisać.

Dobrym źródłem do nauki języka UML jest doskonała książka Martina Fowlera „UML Distilled” ( link do Amazon - oczyszczony dla skryptu kiddie link nazis there (-:). Ta książka daje szybkie spojrzenie na podstawowe części każdego z elementów UML.

O. To, co opisałem, jest w dużym stopniu podejściem Ivara Jacobsona. Jacobson jest jednym z Trzech Amigos z OO. W rzeczywistości UML został pierwotnie opracowany przez pozostałe dwie osoby, które tworzą Three Amigos, Grady Booch i Jim Rumbaugh

Zdecydowanie powinieneś rzucić okiem na kompletny kod Steve'a McConnell'a - a zwłaszcza jego rozdział z prezentami na temat „Projektowanie w budownictwie”

Możesz go pobrać z jego strony internetowej:

http://cc2e.com/File.ashx?cid=336

Jeśli tworzysz dla .NET, Microsoft właśnie opublikował (jako darmowy e-book!) Podręcznik architektury aplikacji 2.0b1 . Dostarcza mnóstwo naprawdę dobrych informacji na temat planowania architektury przed napisaniem kodu.

Gdybyś był zdesperowany, spodziewam się, że możesz użyć dużych fragmentów tego dla architektur innych niż .NET.

Przedtem powiem, że zajmuję się głównie tworzeniem stron internetowych, w których większość architektury jest już ustalona z wyprzedzeniem (WebForms, teraz MVC), a większość moich projektów to stosunkowo małe, jednoosobowe prace, które trwają mniej niż rok. Wiem również, że będę mieć ORM i DAL do obsługi, odpowiednio, mojego obiektu biznesowego i interakcji z danymi. Niedawno przerzuciłem się na używanie LINQ w tym celu, więc znaczna część „projektu” staje się projektowaniem i mapowaniem bazy danych za pośrednictwem projektanta DBML.

Zwykle pracuję w trybie TDD (programowanie sterowane testami). Nie spędzam dużo czasu z góry, pracując nad detalami architektonicznymi lub projektowymi. Zbieram ogólną interakcję użytkownika z aplikacją za pomocą historii. Korzystam z historii, aby opracować projekt interakcji i odkryć główne elementy aplikacji. Podczas tego procesu wykonuję dużo białych tablic z klientami - czasami rejestruję szczegóły za pomocą aparatu cyfrowego, jeśli wydają się one wystarczająco ważne, aby zachować je w formie diagramu. Głównie moje historie są przechwytywane w formie historii na wiki. Ostatecznie historie są organizowane w wydania i iteracje.

W tym czasie zwykle mam już całkiem niezłe wyobrażenie o architekturze. Jeśli jest to skomplikowane lub występują nietypowe fragmenty - rzeczy różniące się od moich normalnych praktyk - lub pracuję z kimś innym (nietypowe), sporządzę diagram (ponownie na tablicy). To samo dotyczy skomplikowanych interakcji - mogę zaprojektować układ strony i przepływ na tablicy, zachowując go (lub przechwytując za pomocą kamery), dopóki nie skończę z tą sekcją. Kiedy już będę miał ogólne pojęcie o tym, dokąd zmierzam i co należy zrobić najpierw, zacznę pisać testy do pierwszych artykułów. Zwykle wygląda to tak: „OK, aby to zrobić, potrzebuję tych zajęć. Zacznę od tego, a on musi to zrobić”. Potem wesoło zaczynam TDD, a architektura / projekt rośnie od potrzeb aplikacji.

Od czasu do czasu mam ochotę napisać kilka fragmentów kodu od nowa lub pomyśleć „to naprawdę śmierdzi” i zreformować swój projekt, aby usunąć powielanie lub zastąpić śmierdzące fragmenty czymś bardziej eleganckim. Przede wszystkim martwię się o obniżenie funkcjonalności przy jednoczesnym przestrzeganiu dobrych zasad projektowania. Uważam, że używanie znanych wzorców i zwracanie uwagi na dobre zasady w miarę upływu czasu działa całkiem nieźle.

http://dn.codegear.com/article/31863

Używam UML i uważam, że ten przewodnik jest bardzo przydatny i łatwy do odczytania. Daj mi znać, jeśli potrzebujesz czegoś innego.

UML to notacja. To sposób na nagranie projektu, ale nie (moim zdaniem) na wykonanie projektu. Jeśli chcesz coś zapisać, poleciłbym jednak UML, ale nie dlatego, że jest „najlepszy”, ale dlatego, że jest to standard, który inni prawdopodobnie już potrafią czytać i bije wymyślanie własnego „standardu”.

Myślę, że najlepszym wprowadzeniem do UML jest nadal UML Distilled , autorstwa Martina Fowlera, ponieważ jest zwięzły, zawiera praktyczne wskazówki, gdzie go używać, i jasno pokazuje, że nie musisz kupować całej historii UML / RUP, aby bądź pożyteczny

Projektowanie jest trudne, nie da się go tak naprawdę ująć w jednej odpowiedzi StackOverflow. Niestety, moje umiejętności projektowe ewoluowały przez lata, więc nie mam jednego źródła, do którego mógłbym Cię skierować.

Jednak jednym z modeli, które uznałem za użyteczne, jest analiza solidności (wygoogluj to, ale jest tu wprowadzenie ). Jeśli masz swoje przypadki użycia dotyczące tego, co system powinien robić, model domeny opisujący, jakie rzeczy są z nim związane, to analiza niezawodności jest użytecznym narzędziem do łączenia tych dwóch elementów i określania, jakie muszą być kluczowe elementy systemu .

Ale najlepszą radą jest szerokie czytanie, intensywne myślenie i praktyka. To nie jest umiejętność, której można się nauczyć, naprawdę musisz to zrobić.

Nie jestem wystarczająco sprytny, żeby planować z wyprzedzeniem więcej niż trochę. Kiedy planuję z wyprzedzeniem, moje plany zawsze wychodzą źle, ale teraz spędziłem n dni na złych planach. Mój limit to około 15 minut na tablicy.

Zasadniczo robię tak mało pracy, jak mogę, aby dowiedzieć się, czy zmierzam we właściwym kierunku.

Patrzę na mój projekt pod kątem krytycznych pytań: kiedy A przechodzi z B do C, czy będzie wystarczająco szybki dla D? Jeśli nie, potrzebujemy innego projektu. Na każde z tych pytań można odpowiedzieć skokiem. Jeśli kolce wyglądają dobrze, to mamy projekt i czas go rozwinąć.

Koduję tak, aby jak najszybciej uzyskać prawdziwą wartość dla klienta, aby klient mógł mi powiedzieć, dokąd mam się udać.

Ponieważ zawsze coś mylę, polegam na refaktoryzacji, która pomaga mi to naprawić. Refaktoryzacja jest ryzykowna, więc muszę na bieżąco pisać testy jednostkowe. Pisanie testów jednostkowych po fakcie jest trudne ze względu na sprzężenie, więc najpierw piszę testy. Pozostawanie zdyscyplinowanym w tych sprawach jest trudne, a inny mózg widzi rzeczy inaczej, więc lubię mieć kumpla, który koduje ze mną. Mój kumpel programujący ma nos, więc regularnie biorę prysznic.

Nazwijmy to „Programowaniem ekstremalnym”.

„Białe tablice, szkice i samoprzylepne notatki to doskonałe narzędzia projektowe. Skomplikowane narzędzia do modelowania mają tendencję do bardziej rozpraszania niż oświetlenia”. Z Practices of an Agile Developer autorstwa Venkata Subramaniama i Andy'ego Hunta .

Nie jestem przekonany, że cokolwiek możebyć zaplanowane z wyprzedzeniem przed wdrożeniem. Mam 10 lat doświadczenia, ale to tylko w 4 firmach (w tym 2 lokalizacje w jednej firmie, które były prawie biegunowymi przeciwieństwami) i prawie całe moje doświadczenie dotyczyło oglądania kolosalnego klastra ****** ** występują. Zaczynam myśleć, że takie rzeczy jak refaktoryzacja to naprawdę najlepszy sposób robienia rzeczy, ale jednocześnie zdaję sobie sprawę, że moje doświadczenie jest ograniczone i mogę po prostu reagować na to, co widziałem. To, co naprawdę chciałbym wiedzieć, to jak zdobyć najlepsze doświadczenie, aby móc dojść do właściwych wniosków, ale wydaje się, że nie ma drogi na skróty i wymaga to po prostu dużo czasu, gdy ludzie robią coś źle :(. naprawdę chciałbym spróbować pracy w firmie, w której ludzie robią wszystko dobrze (o czym świadczą udane wdrożenia produktów),

Muszę się różnić: UML może być używany do architektury aplikacji, ale jest częściej używany do architektury technicznej (frameworki, diagramy klas lub sekwencji, ...), ponieważ to właśnie tam te diagramy można najłatwiej utrzymać w synchronizacji z rozwojem .

Architektura aplikacji ma miejsce, gdy bierzesz pewne specyfikacje funkcjonalne (które opisują naturę i przepływy operacji bez dokonywania jakichkolwiek założeń dotyczących przyszłej implementacji) i przekształcasz je w specyfikacje techniczne.

Te specyfikacje przedstawiają aplikacje potrzebne do realizacji niektórych potrzeb biznesowych i funkcjonalnych.

Jeśli więc potrzebujesz przetworzyć kilka dużych portfeli finansowych (specyfikacja funkcjonalna), możesz określić, że musisz podzielić tę dużą specyfikację na:

• dyspozytor do przypisywania tych ciężkich obliczeń do różnych serwerów
• program uruchamiający, aby upewnić się, że wszystkie serwery obliczeniowe są uruchomione i działają przed rozpoczęciem przetwarzania tych portfeli.
• GUI, aby móc pokazać, co się dzieje.
• „wspólny” komponent do opracowywania określonych algorytmów portfela, niezależnie od pozostałej części architektury aplikacji, w celu ułatwienia testowania jednostkowego, ale także niektóre testy funkcjonalne i regresyjne.

Więc w zasadzie myślenie o architekturze aplikacji to decydowanie, jaką "grupę plików" potrzebujesz do stworzenia w spójny sposób (nie możesz w tej samej grupie plików stworzyć programu uruchamiającego, GUI, dyspozytora, ...: one nie będą w stanie ewoluować w tym samym tempie)

Gdy architektura aplikacji jest dobrze zdefiniowana, każdy z jej komponentów jest zwykle dobrym kandydatem na komponent konfiguracyjny , czyli grupę plików, które mogą być wersjonowane jako całość w VCS (system kontroli wersji), co oznacza, że wszystkie jej pliki będą etykietowane razem za każdym razem, gdy trzeba nagrać migawkę tej aplikacji (ponownie, byłoby trudno oznaczyć cały system, każda z jego aplikacji nie może być jednocześnie w stabilnym stanie)

Od jakiegoś czasu zajmuję się architekturą. Używam BPML, aby najpierw udoskonalić proces biznesowy, a następnie używam UML do przechwytywania różnych szczegółów! Trzeci krok to generalnie ERD! Zanim skończysz z BPML i UML, Twój ERD będzie dość stabilny! Żaden plan nie jest doskonały i żadna abstrakcja nie będzie w 100%. Planuj refaktoryzację, celem jest maksymalne zminimalizowanie refaktoryzacji!

Staram się podzielić swoje myślenie na dwa obszary: przedstawienie rzeczy, którymi próbuję manipulować, i tego, co zamierzam z nimi zrobić.

Kiedy próbuję modelować rzeczy, którymi próbuję manipulować, wymyślam serię oddzielnych definicji przedmiotów - witryna e-commerce będzie miała SKU, produkt, klienta i tak dalej. Będę też miał kilka niematerialnych rzeczy, nad którymi pracuję - zamówienie lub kategorię. Kiedy będę miał wszystkie „rzeczowniki” w systemie, utworzę model domeny, który pokazuje, jak te obiekty są ze sobą powiązane - zamówienie ma klienta i wiele jednostek SKU, wiele jednostek jest zgrupowanych w produkt, i tak na.

Te modele domen można przedstawić jako modele domen UML, diagramy klas i SQL ERD.

Kiedy już ustalę rzeczowniki systemu, przechodzę do czasowników - na przykład operacji, przez które przechodzi każdy z tych elementów, aby zatwierdzić zamówienie. Zwykle całkiem dobrze odwzorowują one przypadki użycia z moich wymagań funkcjonalnych - najłatwiejszym sposobem wyrażenia tych, które znalazłem, są diagramy sekwencji UML, aktywności lub współpracy lub diagramy torów.

Ważne jest, aby myśleć o tym jako o procesie iteracyjnym; Zrobię mały róg domeny, a potem popracuję nad działaniami, a potem wrócę. Najlepiej byłoby, gdyby miał czas na napisanie kodu, aby wypróbować różne rzeczy na bieżąco - nigdy nie chcesz, aby projekt wyprzedzał aplikację. Ten proces jest zwykle okropny, jeśli myślisz, że tworzysz pełną i ostateczną architekturę wszystkiego; tak naprawdę wszystko, co próbujesz zrobić, to ustalić podstawowe fundamenty, którymi zespół będzie się dzielił w miarę rozwoju. W większości tworzysz wspólne słownictwo, które członkowie zespołu mogą używać przy opisywaniu systemu, a nie ustanawiasz prawo określające, jak należy to zrobić.

Mam problem z pełnym przemyśleniem systemu przed jego zakodowaniem. Po prostu zbyt łatwo jest rzucić okiem na niektóre elementy, o których dopiero później zdajesz sobie sprawę, że są znacznie bardziej skomplikowane, niż myślałeś, że są.

Jednym z rozwiązań jest po prostu bardzo się postarać. Pisz UML wszędzie. Przejdź przez wszystkie zajęcia. Pomyśl, jak będzie współdziałać z innymi klasami. To jest trudne.

Na początku lubię robić ogólny przegląd. Nie lubię UML, ale lubię rysować diagramy, które dają punkt widzenia. Wtedy zaczynam to wdrażać. Nawet gdy tylko piszę strukturę klasy za pomocą pustych metod, często widzę rzeczy, które wcześniej przegapiłem, więc wtedy aktualizuję swój projekt. Podczas programowania zdaję sobie sprawę, że muszę zrobić coś inaczej, więc zaktualizuję swój projekt. To proces iteracyjny . Koncepcja „najpierw zaprojektuj wszystko, a potem wszystko zaimplementuj” jest znana jako model kaskadowy i myślę, że inni pokazali, że to zły sposób tworzenia oprogramowania.

Wypróbuj Archimate.