Projektowanie oprogramowania a architektura oprogramowania [zamknięte]

342

Czy ktoś mógłby wyjaśnić różnicę między projektowaniem oprogramowania a architekturą oprogramowania?

Dokładniej; jeśli powiesz komuś, by przedstawił ci „projekt” - czego byś się spodziewał? To samo dotyczy „architektury”.

Moje obecne rozumienie to:

  • Projekt: schemat UML / schemat blokowy / proste szkielety (dla interfejsu użytkownika) dla określonego modułu / części systemu
  • Architektura: schemat komponentów (pokazujący, w jaki sposób różne moduły systemu komunikują się ze sobą i innymi systemami), jakiego języka należy używać, wzorców ...

Popraw mnie, jeśli się mylę. Odsyłam Wikipedia ma artykuły na http://en.wikipedia.org/wiki/Software_design i http://en.wikipedia.org/wiki/Software_architecture , ale nie jestem pewien, czy dobrze je zrozumiałem.

Mads Mobæk
źródło
Czy którekolwiek z poniższych pytań było pomocne? ;)
Patrick Karcher
Pamiętaj, że do pewnego stopnia rozróżnienie (które z pewnością jest rzeczywiste) często wynika z pretensjonalności. Żaden architekt nie może być jakimkolwiek dobrem bez przyzwoitego zrozumienia projektu i konstrukcji, a żaden projektant nie może być żadnym dobrem bez rozsądnego zrozumienia architektury.
Hot Licks
Kiedyś widziałem architekturę opisaną jako „projekt dostosowany do celu”. To trochę banalne, ale zawiera samorodek prawdy, ponieważ dobra architektura musi ostatecznie skupiać się na celu, a nie na implementacji.
Hot Licks

Odpowiedzi:

329

Masz rację tak. Architektura systemu jest jego „szkieletem”. To najwyższy poziom abstrakcji systemu. Jaki rodzaj przechowywania danych jest obecny, w jaki sposób moduły współdziałają ze sobą, jakie są systemy odzyskiwania. Podobnie jak wzorce projektowe, istnieją wzorce architektoniczne: MVC, trójwarstwowe projektowanie warstwowe itp.

Projektowanie oprogramowania polega na projektowaniu poszczególnych modułów / komponentów. Jakie są obowiązki, funkcje modułu x? Klasy Y? Co może zrobić, a co nie? Jakie wzorce projektowe można zastosować?

Krótko mówiąc, architektura oprogramowania dotyczy bardziej projektowania całego systemu, podczas gdy projektowanie oprogramowania kładzie nacisk na poziom modułu / komponentu / klasy.

Razzie
źródło
116
Ponadto architektura zazwyczaj zajmuje się tym, co (jest zrobione) i gdzie (to jest zrobione), ale nigdy nie jest to możliwe. Na tym polega podstawowa różnica - projekt uzupełnia to, o czym architektura nie mówi (i nie powinna) mówić.
Asaf R
2
Cześć @ AsafR! to sprawiło, że pomyślałem o architekturze jako analizie, ponieważ analiza zajmuje się tym, co (jest zrobione), a projektem - jak. tak myślisz?
Chriss,
2
W dzisiejszych czasach ludzie wykonują wszystkie zadania związane z projektowaniem, wdrażaniem, utrzymywaniem serwerów zaplecza (prawdopodobnie w chmurze) i projektowaniem front-endowym (internetowym lub mobilnym). Myślę, że nazywają się deweloperami pełnego stosu. Dobrze?
Maziyar
1
Architektura to zarys systemu, struktura, plan całości. Projektowanie to tylko czynność tworzenia planu. Możesz zaprojektować architekturę, możesz zaprojektować moduł, możesz nawet zaprojektować metodę.
Evan Hu,
2
To dlatego, że MVC jest projektem architektonicznym. MVC nie podaje żadnych szczegółów w sobie. „Widok” może być witryną internetową, formularzami win, aplikacją konsolową. Model może być prawie wszystkim, nie określa niczego, skąd pochodzi (warstwa bazy danych lub cokolwiek innego).
Razzie
80

W niektórych opisach SDLC (Software Development Life Cycle) są one wymienne, ale konsekwencją jest to, że są odrębne. Są to jednocześnie: różne (1) etapy , (2) obszary odpowiedzialności i (3) poziomy decyzyjne .

  • Architektura to większy obraz: wybór ram, języków, zakresu, celów i metodologii wysokiego poziomu ( Rational , wodospad , zwinny itp.).
  • Projekt to mniejszy obraz: plan organizacji kodu; jak będą wyglądały umowy między różnymi częściami systemu; bieżące wdrażanie metodologii i celów projektu. Specyfikacja jest zapisywana na tym etapie.

Te dwa etapy wydają się łączyć ze sobą z różnych powodów.

  1. Mniejsze projekty często nie mają wystarczającego zakresu, aby rozdzielić planowanie na etapy.
  2. Projekt może być częścią większego projektu, a zatem części obu etapów są już ustalone. (Istnieją już bazy danych, konwencje, standardy, protokoły, ramy, kod wielokrotnego użytku itp.)
  3. Nowsze sposoby myślenia o SDLC (patrz metodologie Agile ) nieco zmieniają to tradycyjne podejście. Projektowanie (architektura w mniejszym stopniu) odbywa się celowo w całym SDLC . Często jest więcej iteracji, w których cały proces odbywa się w kółko.
  4. Tworzenie oprogramowania jest i tak skomplikowane i trudne do zaplanowania, ale klienci / menedżerowie / handlowcy zwykle utrudniają zmianę celów i wymagań w połowie strumienia. Projekty, a nawet decyzje architektoniczne muszą zostać później uwzględnione w projekcie, niezależnie od tego, czy jest to plan, czy nie.

Nawet jeśli etapy lub obszary odpowiedzialności łączą się ze sobą i zdarzają się wszędzie, zawsze dobrze jest wiedzieć, jaki jest poziom podejmowania decyzji. (Moglibyśmy to kontynuować wiecznie. Staram się zachować to streszczenie). Kończę: Nawet jeśli wydaje się, że twój projekt nie ma formalnej architektury ani etapu projektowego / AOR / dokumentacji, dzieje się tak, czy ktoś jest świadomie robiąc to czy nie. Jeśli nikt nie zdecyduje się na architekturę, zdarza się, że domyślnie jest ona słaba. To samo dotyczy projektu. Pojęcia te są prawie ważniejsze, jeśli nie są reprezentowane żadne formalne etapy.

Patrick Karcher
źródło
Dobra odpowiedź. Podoba mi się nacisk na to, jak jedno może wydawać się częścią drugiego. Czwarta kwestia rodzi interesujące pytanie: czy projektowanie w konkretnej dziedzinie problemowej jest mniej aktualne, gdy nie ma jeszcze architektury, w której mógłby istnieć? Doświadczenie sugeruje, że tak, ale teoretycznie chciałbym myśleć, że projekt, który mieści się w odpowiednim zakresie (tj. Dla konkretnego komponentu), powinien być równie ważny, niezależnie od tego, w jaki sposób zostanie ostatecznie wykorzystany.
Tom W
55

Architektura jest strategiczna, a Projektowanie taktyczne.

Architektura obejmuje frameworki, narzędzia, paradygmaty programowania, standardy inżynierii oprogramowania oparte na komponentach, zasady wysokiego poziomu.

Podczas gdy projektowanie jest działaniem związanym z lokalnymi ograniczeniami, takimi jak wzorce projektowe, idiomy programistyczne i refaktoryzacje.

Chris Kannon
źródło
Chciałbym, aby mniej odniesień do „designu” i „architektury” w definicji „designu” zagłosowało w tej sprawie ...
Peter Hansen
1
Uzgodnione ... być może: Architektura obejmuje ramy, narzędzia, paradygmaty programowania, standardy inżynierii oprogramowania oparte na komponentach, zasady wysokiego poziomu. Podczas gdy projektowanie jest działaniem związanym z lokalnymi ograniczeniami, takimi jak wzorce projektowe, idiomy programistyczne i refaktoryzacje.
Chris Kannon
38

Znalazłem to, gdy sam szukałem prostej różnicy między architekturą a designem;
Co sądzisz o tym sposobie patrzenia na nich:

  • architektura jest tym, co budujemy;
  • projekt to „jak” budujemy;
George S.
źródło
4
To, co budujemy, to wymagania klienta. To, jak go zbudujemy, zależy zarówno od architektury, jak i projektu. Więc nie, to jest całkowicie błędne.
Marek
1
@Marek Nie rozumiem, co jest z tym nie tak. Architektura jest tym, co budować, czego chce klient, jak powinien on ogólnie wyglądać, z jakich komponentów powinien być wykonany itp. Projekt polega na tym, jak te rzeczy są faktycznie wykonane: rzeczywiste implementacje komponentów, algorytmów itp.
RecursiveExceptionException
21
  1. Architektura oznacza strukturę koncepcyjną i logiczną organizację komputera lub systemu komputerowego.

    Projekt oznacza plan lub rysunek stworzony w celu ukazania wyglądu i funkcji lub działania systemu lub obiektu przed jego wykonaniem.

  2. Jeśli „komponujesz” komponent, definiujesz jego zachowanie w większym systemie.

    Jeśli „projektujesz” ten sam komponent, określasz, jak zachowuje się on wewnętrznie.

Cała architektura to design, ale NIE cały design to architektura.

Whatczęść jest Projektowanie, Howjest konkretna realizacja i przecięcie Whati Howjest architektura.

Obraz dla odróżnienia architektury i designu :

Projektowanie a architektura

Istnieją również decyzje projektowe, które nie mają znaczenia architektonicznego, tj. Nie należą do gałęzi architektury. Na przykład wewnętrzne decyzje projektowe niektórych komponentów, takie jak wybór algorytmu, wybór struktury danych itp.

Każda decyzja projektowa, która nie jest widoczna poza granicami komponentu, jest wewnętrznym projektem komponentu i nie ma charakteru architektonicznego. Takie decyzje projektowe pozostawiłby architekt systemu według uznania projektanta modułu lub zespołu wdrażającego, o ile ich projekt nie złamie ograniczeń architektonicznych narzuconych przez architekturę na poziomie systemu.

Link, który daje dobrą analogię

TryinHard
źródło
Nie podoba mi się ta odpowiedź. Architektura jest najwyższym poziomem abstrakcji, dlatego nie powinieneś zawracać sobie głowy tym, jak to się robi. Zgadzam się, że projekt i architektura są w jakiś sposób powiązane - Projektowanie jest działaniem, które tworzy część architektury systemu, ale nie powiedziałbym, że „Co i jak” to architektura, ponieważ jest bardzo myląca ...
Martin Čuka,
15

Powiedziałbym, że masz rację, własnymi słowami;

Architektura to alokacja wymagań systemowych na elementy systemu. Cztery stwierdzenia dotyczące architektury:

  1. Może wprowadzać niefunkcjonalne wymagania, takie jak język lub wzorce.
  2. Definiuje interakcję między komponentami, interfejsami, synchronizacją itp.
  3. Nie wprowadza nowej funkcjonalności,
  4. Przydziela (zaprojektowane) funkcje, które system ma wykonywać, do elementów.

Architektura jest niezbędnym krokiem inżynieryjnym, gdy złożoność systemu jest podzielona.

Przykład: Pomyśl o swoim domu, nie potrzebujesz architekta do swojej kuchni (zaangażowany jest tylko jeden element), ale cały budynek wymaga pewnych definicji interakcji, takich jak drzwi i dach .

Projekt jest informacyjnym przedstawieniem (proponowanej) implementacji funkcji. Jego celem jest uzyskiwanie informacji zwrotnych i omawianie z zainteresowanymi stronami. Może to być dobra praktyka, ale nie jest niezbędnym krokiem inżynieryjnym .

Byłoby miło zobaczyć projekt kuchni przed jej zainstalowaniem, ale nie jest to konieczne dla wymagań gotowania :

Jeśli o tym pomyślę, możesz powiedzieć:

  • architektura jest dla publiczności / inżynierów na bardziej szczegółowym poziomie abstrakcji
  • projekt przeznaczony jest do publicznego użytku na mniej szczegółowym poziomie abstrakcji
user662182
źródło
+1 dla architektury to alokacja wymagań systemowych na elementy systemu. Wirtualny -1 do użycia słowa „a” na końcowej liście. Uważam, że twoja (poprawna) początkowa definicja jest antytezą abstrakcji.
Chris Walton
Nie jestem pewien co do punktów 1 i 3. Nic nie powinno wprowadzać większej funkcjonalności niż jest to wymagane do spełnienia wymagań interesariuszy. Ograniczenia są raczej problemem metodologicznym. Inne punkty są pomocne. Analogia kuchenna nie jest świetna; nie potrzebujesz architekta, ale projektowanie kuchni jest dość wyspecjalizowaną dziedziną, w której coś jest projektowane przy użyciu nieco modułowych komponentów. Nie mogę się zgodzić z tym, że projekt nie jest niezbędnym krokiem inżynieryjnym. Nie jestem pewien, co oznaczają ostatnie dwa punkty.
Mike G
Gdzie mieści się wdrożenie? Czy wdrożenie nie jest projektem?
jwilleke,
14

Moje przypomnienie:

  • Możemy zmienić Projekt bez pytania kogoś
  • Jeśli zmienimy architekturę, musimy ją przekazać komuś (zespołowi, klientowi, interesariuszowi, ...)
Peter Gfader
źródło
6

Myślę, że powinniśmy zastosować następującą regułę, aby określić, kiedy mówimy o projektowaniu a architekturze: Jeśli elementy utworzonego obrazu oprogramowania można zamapować jeden na jeden na konstrukcji składni języka programowania, to jest to projekt, jeśli nie architektura.

Na przykład, jeśli widzisz diagram klasowy lub diagram sekwencyjny, możesz odwzorować klasę i ich relacje na język programowania obiektowego przy użyciu konstrukcji składniowej klasy. To jest wyraźnie Design. Ponadto może to doprowadzić do wniosku, że ta dyskusja ma związek z językiem programowania, którego użyjesz do wdrożenia systemu oprogramowania. Jeśli używasz Javy, zastosowanie ma poprzedni przykład, ponieważ Java jest językiem programowania obiektowego. Jeśli wymyślisz diagram, który pokazuje pakiety i ich zależności, to również Design. Możesz odwzorować element (w tym przypadku pakiet) na konstrukcję składni Java.

Załóżmy teraz, że twoja aplikacja Java jest podzielona na moduły, a każdy moduł jest zestawem pakietów (reprezentowanych jako jednostka wdrażania pliku jar), a otrzymasz diagram zawierający moduły i ich zależności, a więc Architektura. W Javie nie ma sposobu (przynajmniej do Java 7) na zmapowanie modułu (zestawu pakietów) na konstrukcję składniową. Możesz również zauważyć, że ten diagram przedstawia krok wyższy w poziomie abstrakcji twojego modelu oprogramowania. Każdy diagram powyżej (gruboziarnisty niż) diagram pakietu przedstawia widok architektoniczny podczas programowania w języku programowania Java. Z drugiej strony, jeśli rozwijasz się w Modula-2, wówczas schemat modułu reprezentuje Projekt.

(Fragment z http://www.copypasteisforword.com/notes/software-architecture-vs-software-design )

Enrique Molinari
źródło
Bardzo to lubię. Dobry wkład. Nie jestem pewien, czy jest to tak jednoznaczne, ale przy takim pytaniu jest tak ostateczne, jak się da. Chciałbym zagłosować, ale nie mam dzisiaj głosów :(.
Mike G
5

Osobiście podoba mi się ten:

„Projektant jest zaniepokojony tym, co dzieje się, gdy użytkownik naciska przycisk, a architekt obawia się, co się stanie, gdy dziesięć tysięcy użytkowników naciśnie przycisk”.

SCEA for Java ™ EE Study Guide autorstwa Mark Cade i Humphrey Sheil

Tavi
źródło
Nawet jeśli przeczytałem tę książkę więcej niż dwa razy, po przeczytaniu wszystkich powyższych komentarzy ta definicja nie ma dla mnie sensu. Oto dlaczego: część dla projektantów brzmi dobrze, ponieważ zadbasz o każdy szczegół, aby upewnić się, że przycisk robi to, co powinien. Ale część architekta nie jest niczym innym o interakcji modułów ani dużym obrazem, ale o wydajności i podobnych rzeczach, czy myślisz, że źle zrozumiałem coś z tej definicji?
Rene Enriquez,
5

Zgadzam się z wieloma wyjaśnieniami; zasadniczo uznajemy różnicę między projektem architektonicznym a szczegółowym projektowaniem systemów oprogramowania.

Podczas gdy celem projektanta jest być tak precyzyjne i konkretne w specyfikacjach, jakie będzie konieczne dla rozwoju; architekt zasadniczo dąży do określenia struktury i globalnego zachowania systemu w takim stopniu, w jakim jest to konieczne do rozpoczęcia szczegółowego projektu.

Dobry architekt zapobiegnie hiper-specyfikacjom - architektury nie można nadmiernie sprecyzować, ale wystarczy, że decyzje (architektoniczne) zostały ustanowione tylko dla aspektów, z którymi wiąże się najbardziej kosztowne ryzyko, i skutecznie zapewniają ramy („wspólność”), w których można opracować szczegółowy projekt, tj. zmienność dla lokalnej funkcjonalności.

Rzeczywiście proces architektury lub cykl życia podąża za tym tematem - odpowiedni poziom abstrakcji, aby zarysować strukturę dla (architektonicznie) istotnych wymagań biznesowych i pozostawić więcej szczegółów na etapie projektowania, aby uzyskać bardziej konkretne rezultaty.

Ajay Shendye
źródło
5

Architektura to design, ale nie każdy design jest architektoniczny. Dlatego, mówiąc ściśle, bardziej sensowne byłoby rozróżnienie między projektem architektonicznym a projektem niearchitektonicznym . A jaka jest różnica To zależy! Każdy architekt oprogramowania może mieć inną odpowiedź (ymmv!). Rozwijamy naszą heurystykę, aby znaleźć odpowiedź, na przykład: „diagramy klasowe są architekturą, a diagramy sekwencji projektowe”. Więcej informacji w książce DSA .

Często mówi się, że architektura jest na wyższym poziomie abstrakcji niż projekt, lub architektura jest logiczna, a projektowanie jest fizyczne. Ale to pojęcie, choć powszechnie akceptowane, jest w praktyce bezużyteczne. Gdzie wyznaczasz granicę między wysoką a niską abstrakcją, między logicznym a fizycznym? To zależy!

Tak więc moja propozycja to:

  • utwórz pojedynczy dokument projektowy.
  • nazwij ten dokument projektowy tak, jak chcesz, a najlepiej, do którego czytelnicy są bardziej przyzwyczajeni. Przykłady: „architektura oprogramowania”, „specyfikacja oprogramowania”.
  • podziel ten dokument na widoki i pamiętaj, że możesz utworzyć widok jako udoskonalenie innego widoku.
  • umożliwiać nawigację w widokach dokumentu poprzez dodawanie odsyłaczy lub hiperłączy
  • wtedy będziesz mieć widoki na wyższym poziomie pokazujące szeroki, ale płytki przegląd projektu, oraz widoki bliższe wdrożenia pokazujące wąskie, ale głębsze szczegóły projektu.
  • możesz rzucić okiem na przykład dokumentu architektury z wieloma widokami ( tutaj ).

Powiedziawszy to wszystko ... bardziej trafnym pytaniem, które musimy zadać, jest: ile projektowania wystarczy? To znaczy, kiedy powinienem przestać opisywać projekt (na schematach lub prozie) i przejść do kodowania?

Paulo Merson
źródło
1
Chociaż zgadzam się z pierwotną definicją, miło byłoby dodać jej źródło: „Paul Clements, Dokumentowanie architektury oprogramowania: widoki i nie tylko”. Na twoje ostatnie pytanie: nigdy nie przestajesz projektować. Właśnie to Clements próbuje wskazać w przywoływanej książce. Każdy deweloper pracuje nad systemem zaprojektuje jakąś część, ale większość z tych projektów nie będą istotne dla architektury. Dlatego jeśli chcesz porozmawiać o architekturze oprogramowania lub udokumentować ją, przestajesz, gdy tylko omawiasz części, które nie są już istotne.
Thomas Eizinger
1
@ThomasEizinger. Dodałem link do naszej książki. Dobry pomysł. Twój komentarz pomaga również odpowiednio przypisać. Jeśli chodzi o ostatnie pytanie, chciałem odnieść się do prac związanych z dokumentacją projektową. Zredagowałem akapit. Dzięki!
Paulo Merson
3

Tak, to mi pasuje. Projekt jest tym, co zamierzasz zrobić, a architektura to sposób, w jaki elementy projektu zostaną połączone. Może być niezależny od języka, ale normalnie określa technologie, które mają być używane, tj. LAMP v Windows, Web Service v RPC.

MrTelly
źródło
3

Architektura oprogramowania programu lub systemu komputerowego jest strukturą lub strukturami systemu, które zawierają komponenty oprogramowania, widoczne z zewnątrz właściwości tych komponentów oraz relacje między nimi.

(z Wikipedii, http://en.wikipedia.org/wiki/Software_architecture )

Projektowanie oprogramowania to proces rozwiązywania problemów i planowania rozwiązania programowego. Po określeniu celu i specyfikacji oprogramowania programiści zaprojektują lub zatrudnią projektantów do opracowania planu rozwiązania. Obejmuje on problemy z implementacją komponentów i algorytmu niskiego poziomu, a także widok architektoniczny.

(z Wikipedii, http://en.wikipedia.org/wiki/Software_design )

Nie mógłbym tego lepiej powiedzieć :)

Larry Watanabe
źródło
3

Patrzę na architekturę tak jak Patrick Karcher - duży obraz. Na przykład możesz dostarczyć architekturę do budynku, wyświetlić jego podparcie konstrukcyjne, okna, wejścia i wyjścia, odprowadzanie wody itp. Ale nie „zaprojektowałeś” układu podłogi, położenia kabiny itp.

Podczas projektowania budynku nie zaprojektowałeś układu każdego biura. Myślę, że to samo dotyczy oprogramowania.

Możesz zobaczyć projektowanie układu jako „architekturę układu”, chociaż ...

mr-sk
źródło
3

Dobre pytanie ... Chociaż linia między nimi nie jest jasną, ostrą linią, imho, jeśli używasz obu terminów, Architektura obejmuje bardziej techniczne lub strukturalne decyzje dotyczące tego, jak zbudować lub zbudować coś, szczególnie te, które będą trudne ( lub trudniej) zmienić po wdrożeniu, podczas gdy Projekt obejmuje decyzje, które albo można później łatwo zmienić (takie jak nazwy metod, struktura organizacyjna pliku <->, wzorce projektowe, czy użyć singletona czy klasy statycznej do rozwiązania określonego problemu itp.) i / lub wpływające na wygląd lub aspekty estetyczne systemu lub aplikacji (Interfejs człowieka, łatwość użycia, wygląd i działanie itp.)

Charles Bretana
źródło
3

Architektura oprogramowania „dotyczy problemów ... wykraczających poza algorytmy i struktury danych obliczeniowych.

Architektura nie dotyczy w szczególności… szczegółów implementacji (np. Algorytmów i struktur danych). Projektowanie architektoniczne obejmuje bogatszy zbiór abstrakcji niż zwykle zapewnia OOD ”(projektowanie obiektowe).

Projekt dotyczy modularyzacji i szczegółowych interfejsów elementów projektu, ich algorytmów i procedur oraz typów danych potrzebnych do obsługi architektury i spełnienia wymagań.

„Architektura” jest często używana jako zwykły synonim „projektu” (czasami poprzedzony przymiotnikiem „wysoki poziom”). I wiele osób używa terminu „wzorce architektoniczne” jako synonim „wzorców projektowych”.

Sprawdź ten link.

Definiowanie terminów Architektura, projekt i wdrożenie

Tebo
źródło
3

Architektura:
Prace konstrukcyjne na wyższych poziomach abstrakcji, które spełniają technicznie istotne wymagania w systemie. Architektura stanowi podstawę do dalszego projektowania.

Design:
Sztuka wypełniania tego, czego nie robi architektura poprzez iteracyjny proces na każdej warstwie abstrakcji.

Joshua Ramirez
źródło
3

Ten artykuł bardzo mi się podobał, ponieważ oddziela architekturę od projektu:

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

Nazywa się to hipotezą Intensywność / Lokalność. Oświadczenia o naturze oprogramowania, które są nielokalne i intensywne, mają charakter architektoniczny. Stwierdzenia lokalne i intensywne są projektowe.

LindsayBradford
źródło
Tak, dokładnie. To ten sam zestaw pomysłów (od tych samych autorów), który sugeruję powyżej. Myślę, że są to pomocne pomysły w tej dziedzinie.
Eoin,
3

... dawno temu, w odległym miejscu, filozofowie martwili się o różnicę między jednym a wieloma. Architektura dotyczy relacji, która wymaga wielu. Architektura ma komponenty. Projekt dotyczy treści, która wymaga tej. Projekt ma właściwości, cechy, cechy. Zwykle uważamy, że projektowanie mieści się w architekturze. Myślenie dualistyczne daje wielu jako pierwotne. Ale architektura również mieści się w zakresie projektowania. To wszystko, jak wybieramy widok tego, co przed nami - jednego lub wielu.

buzzcoda
źródło
Podoba mi się ta odpowiedź tylko z powodu tego zdania: „Ale architektura jest również w designie”. Powiedziałbym, że „architektura może być w ramach projektu”. - to zależy od Ciebie. Nie są rozdzielone.
Miroslav Trninic,
3

Całkiem subiektywnie, ale moje zdanie:

Architektura Ogólny projekt systemu, w tym interakcje z innymi systemami, wymagania sprzętowe, ogólny projekt komponentów i przepływ danych.

Projektowanie Organizacja i przepływ komponentu w całym systemie. Obejmuje to również interfejs API komponentu do interakcji z innymi komponentami.

Jesse Vogt
źródło
2

Architekturę oprogramowania najlepiej stosować na poziomie systemu, gdy trzeba projektować biznes i funkcje identyfikowane przez wyższe poziomy architektury w aplikacjach.

Na przykład twoja działalność dotyczy „zysków i strat” dla traderów, a twoje główne funkcje obejmowały „ocenę portfela” i „obliczanie ryzyka”.

Ale kiedy architekt oprogramowania szczegółowo omówi swoje rozwiązanie, zda sobie sprawę, że:

„ocena portfela” nie może być tylko jedną aplikacją. Trzeba to udoskonalić w zarządzalnych projektach, takich jak:

  • GUI
  • Wyrzutnia
  • Dyspozytor
  • ...

(ponieważ operacje są tak ogromne, że trzeba je rozdzielić na kilka komputerów, a jednocześnie cały czas są monitorowane za pomocą wspólnego GUI)

projekt oprogramowania zbada różne aplikacje, ich relacje techniczne i ich wewnętrzne podzespoły.
Opracuje specyfikacje potrzebne do pracy na ostatniej warstwie architektury („architekturze technicznej”) (pod względem ram technicznych lub komponentów przekrojowych), a zespoły projektowe (bardziej zorientowane na implementację funkcji biznesowych ) rozpoczną ich odpowiednie projekty.

VonC
źródło
2

jeśli ktoś zbuduje statek, wówczas jego „elementami architektonicznymi” będą silnik, kadłub, obwody elektryczne itp. Dla niego konstrukcja silnika będzie „pracą projektową”.

Jeśli następnie przekaże konstrukcję silnika innemu zespołowi, stworzą „architekturę silnika” ...

Tak więc - zależy to od poziomu abstrakcji lub szczegółów. Architektura jednej osoby może być projektem innej!

Gernot Starke
źródło
2

Architektura to „decyzje projektowe, które trudno zmienić”.

Po pracy z TDD, co praktycznie oznacza, że ​​cały projekt ciągle się zmienia, często miałem problem z tym pytaniem. Powyższa definicja została wyodrębniona z wzorców architektury aplikacji korporacyjnych autorstwa Martina Fowlera

Oznacza to, że architektura zależy od języka, frameworka i domeny twojego systemu. Jeśli możesz po prostu wyodrębnić interfejs z klasy Java w 5 minut, nie jest to już decyzja architektoniczna.

ekeren
źródło
1

Wersja Cliff Notes:

Projekt: Wdrożenie rozwiązania na podstawie specyfikacji pożądanego produktu.

Architektura: Podstawa / narzędzia / infrastruktura / komponenty, które wspierają Twój projekt.

To dość szerokie pytanie, które wywoła wiele odpowiedzi.

Ta01
źródło
1

Architektura to wynikowa kolekcja wzorców projektowych do budowy systemu.

Wydaje mi się, że Design łączy w sobie kreatywność?

Mark Redman
źródło
muszę się nie zgodzić. wydaje się, że ty (tak jak ja i większość innych odpowiedzi) stawiasz architekturę na „dużym obrazie”, podczas gdy projektowanie bardziej dotyczy metod i rozwiązywania problemów. Ale jeśli twoja architektura jest tym, co „wynika” z wzorców projektowych, to nie tak naprawdę ją zaprojektowałeś, po prostu pozwalasz jej rosnąć!
Javier
... chyba że nie pozwolisz mu rosnąć, to znaczy :-) Potrzeba trochę wiedzy i doświadczenia, aby mieć kreatywność w użyciu dostępnych technik w celu stworzenia eleganckiej architektury. ... to oczywiście zbyt subiektywne, aby wymyślić coś ostatecznego ... ale tak, masz rację, biorąc pod uwagę, że istnieją pewne złe systemy bez ogólnych projektów systemów (architektur)
Mark Redman,
1

Projektowanie oprogramowania ma dłuższą historię, a termin architektura oprogramowania ma zaledwie 20 lat. Dlatego teraz przechodzi przez to coraz większe bóle.

Naukowcy postrzegają architekturę jako część szerszej dziedziny projektowania oprogramowania. Mimo że rośnie uznanie, że Arch jest polem we własnym zakresie.

Praktycy postrzegają Archa jako decyzje strategiczne na wysokim szczeblu, które są strategiczne i których cofnięcie może być kosztowne w projekcie.

Dokładna linia między Arch i designem zależy od domeny oprogramowania. Na przykład w dziedzinie aplikacji internetowych architektura warstwowa zyskuje obecnie największą popularność (Biz Logic Layer, Data Access Layer itp.) Części niższego poziomu tego Arch są uważane za projektowanie (diagramy klas, podpisy metod itp.) ) Zostałoby to zdefiniowane inaczej w domenach systemów wbudowanych, systemów operacyjnych, kompilatorów itp.

LeWoody
źródło
1

Architektura to projektowanie na wysokim poziomie, abstrakcyjne i logiczne, podczas gdy projektowanie oprogramowania to projektowanie na niskim poziomie, szczegółowe i fizyczne.

imran
źródło
1

Podoba mi się definicja i wyjaśnienie Roya Thomasa Fieldinga dotyczące tego, czym jest architektura oprogramowania w jego pracy: Style architektoniczne i projektowanie architektur oprogramowania sieciowego

Architektura oprogramowania jest abstrakcją elementów wykonawczych systemu oprogramowania podczas pewnej fazy jego działania. System może składać się z wielu poziomów abstrakcji i wielu faz działania, każdy z własną architekturą oprogramowania.

Podkreśla „elementy czasu wykonywania” i „poziomy abstrakcji”.

Jacky
źródło
elementy wykonawcze odnosiły się również do komponentów lub modułów aplikacji, a każdy moduł lub komponent zawiera własny poziom abstrakcji. Poprawny?
Ankit Rana
1

Nie ma ostatecznej odpowiedzi na to pytanie, ponieważ „architektura oprogramowania” i „projektowanie oprogramowania” mają dość wiele definicji i nie ma też definicji kanonicznej.

Dobrym sposobem myślenia o tym jest stwierdzenie Len Bassa, Paula Clementsa i Ricka Kazmana, że ​​„cała architektura to design, ale nie każdy design to architektura” [Software Architecture in Practice]. Nie jestem pewien, czy całkowicie się z tym zgadzam (ponieważ architektura może obejmować inne działania), ale oddaje to, że architektura jest działaniem projektowym, które zajmuje się krytycznym podzbiorem projektu.

Moja nieco niepoprawna definicja (znaleziona na stronie z definicjami SEI ) jest taka, że ​​jest to zestaw decyzji, które, jeśli zostaną źle podjęte, spowodują anulowanie twojego projektu.

Przydatną próbę rozdzielenia architektury, projektowania i implementacji jako koncepcji dokonali Amnon Eden i Rick Kazman kilka lat temu w artykule badawczym zatytułowanym „Architektura, projektowanie, wdrażanie”, który można znaleźć tutaj: http: //www.sei.cmu .edu / library / asset / ICSE03-1.pdf . Ich język jest dość abstrakcyjny, ale w uproszczeniu mówią, że architektura to projekt, który może być stosowany w wielu kontekstach i ma być stosowany w całym systemie, projekt to (err) projekt, który może być stosowany w wielu kontekstach, ale jest stosowany w określonej części systemu i wdrożenie jest specyficzna dla danego kontekstu i zastosowana w tym kontekście.

Tak więc decyzja architektoniczna może być decyzją o integracji systemu za pomocą komunikatów, a nie RPC (więc jest to ogólna zasada, którą można zastosować w wielu miejscach i ma ona dotyczyć całego systemu), decyzją projektową może być użycie wzorca / struktura wątków slave w module obsługi żądań wejściowych w systemie (ogólna zasada, która może być używana w dowolnym miejscu, ale w tym przypadku jest używana tylko w jednym module) i na koniec decyzja o wdrożeniu może polegać na przeniesieniu odpowiedzialności za bezpieczeństwo z routera żądania do modułu obsługi żądań w module menedżera żądań (decyzja istotna tylko w tym kontekście, zastosowana w tym kontekście).

Mam nadzieję, że to pomoże!

Eoin
źródło