Projektowanie oprogramowania a architektura oprogramowania [zamknięte]

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.

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.

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.

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.

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;

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 :

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ę

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

Moje przypomnienie:

• Możemy zmienić Projekt bez pytania kogoś
• Jeśli zmienimy architekturę, musimy ją przekazać komuś (zespołowi, klientowi, interesariuszowi, ...)

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 )

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

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.

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?

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.

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ć :)

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ż ...

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.)

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

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.

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.

... 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.

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.

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.

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!

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.

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.

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

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

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.

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

Zobacz także: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

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”.

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!