Projektowanie oprogramowania a Architektura oprogramowania [zamknięty]

W niektórych opisach SDLC (Software Development Life Cycle) są one wymienne, ale są one różne. Są jednocześnie: różne (1) etapy, (2) obszary odpowiedzialności oraz (3) poziomy podejmowania decyzji .

• Architektura jest szerszym obrazem: wybór frameworków, języków, zakresu, celów i metodologii wysokiego poziomu ( Rational, wodospad , agile , itp.).
• Design to mniejszy obraz: plan organizacji kodu; jak będą wyglądały umowy między różnymi częściami systemu; trwająca implementacja metodologii i celów projektu. Specyfikacja jest pisana na tym etapie.

Te dwa etapy będą wydają się zlewać się ze sobą z różnych powodów.

1. mniejsze projekty często nie mają wystarczającego zakresu, aby oddzielić planowanie do tych etapów.
2. projekt może być częścią większego projektu, a zatem części obu etapów są już ustalone. (Istnieją już istniejące bazy danych, konwencje, standardy, protokoły, frameworki, kod wielokrotnego użytku itp.)
3. nowsze sposoby myślenia o SDLC (zobacz Agile metodologie) nieco przearanżować to tradycyjne podejście. Projektowanie (architektura w mniejszym stopniu) odbywa się w całym SDLC celowo . Często są więcej iteracji gdzie cały proces dzieje się w kółko.
4. tworzenie oprogramowania jest skomplikowane i trudne do zaplanowania, ale klienci / menedżerowie/sprzedawcy zwykle utrudniają to, zmieniając cele i wymagania w połowie strumienia. Projekt, a nawet decyzje architektoniczne MUSZĄ być rozpatrywane później w projekcie, niezależnie od tego, czy taki jest plan, czy nie.

Nawet jeśli etapy lub obszary odpowiedzialności zlewają się ze sobą i zdarzają się wszędzie, zawsze jest dobrze wiedzieć, jaki jest poziom podejmowania decyzji. (Możemy to ciągnąć w nieskończoność. Staram się to streścić.) Na koniec: nawet jeśli wydaje się, że twój projekt nie ma formalnego etapu architektonicznego lub projektowego / AOR / dokumentu, dzieje się to niezależnie od tego, czy ktoś świadomie to robi, czy nie. Jeśli nikt nie zdecyduje się na architekturę, wtedy zdarza się domyślna, która jest prawdopodobnie słaba. To samo dotyczy designu. Pojęcia te są prawie ważniejsze , jeśli nie ma formalnych etapów reprezentuję ich.

Architektura jest strategiczna, podczas gdy Design jest taktyczny.

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

Znalazłem to, ponieważ szukałem prostego rozróżnienia między architekturą a samym designem;
Co sądzicie o takim sposobie patrzenia na nie:

• architektura to " to " co budujemy;
• design to " jak " budujemy;

1. Architektura oznacza strukturę pojęciową i logiczną organizację komputera lub systemu komputerowego.

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

2. Jeśli "tworzysz" komponent, definiujesz jego zachowanie w większym systemie.

   Jeśli "projektujesz" ten sam komponent, definiujesz jego zachowanie wewnętrznie.

Cała architektura jest designem, ale nie wszystkie wzornictwo jest architekturą.

What część to projekt, {[1] } to konkretna realizacja, a przecięcie What i {[1] } to Architektura.

Obraz dla odróżnienia Architektury i Wzornictwa :

Istnieją również decyzje projektowe, które nie są istotne architektonicznie, tzn. nie należą do architektonicznej gałęzi projektowania. Na przykład, wewnętrzne decyzje projektowe jakiegoś komponentu, np.-wybór algorytmu, wybór struktury danych itp.

Każda decyzja projektowa, która nie jest widoczna poza jego granicami składowymi, jest wewnętrznym projektem komponentu i nie jest architektoniczna. Są to decyzje projektowe, które architekt systemowy pozostawiłby w gestii projektanta modułu lub zespołu wdrożeniowego, o ile ich projekt nie łamie ograniczeń architektonicznych narzuconych przez poziom systemu Architektura.

Link, który daje dobrą analogię

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

Architektura {[4] } to przydział wymagań systemowych do elementów systemu. Cztery stwierdzenia o architekturze:

1. może wprowadzać niefunkcjonalne wymagania, takie jak język lub wzorce.
2. definiuje interakcję między komponentami, interfejsami, czasem itp.
3. nie wprowadza nowych funkcjonalności,
4. przydziela (zaprojektowane) funkcje, które system ma pełnić do żywioły.

Architektura jest istotnym etapem inżynieryjnym , gdy złożoność systemu jest podzielona.

przykład: pomyśl o swoim domu, nie potrzebujesz architekta do kuchni (dotyczy to tylko jednego elementu), ale cały budynek wymaga pewnych definicji interakcji, takich jak drzwi i dach {22]}.

Design jest informacyjnym przedstawieniem (proponowanej) implementacji funkcji. Ma ona na celu wywołanie sprzężenia zwrotnego i dyskusja z zainteresowanymi stronami. Może to być dobra praktyka, ale nie jest istotnym etapem inżynieryjnym .

byłoby miło zobaczyć projekt kuchni zobaczyć przed kuchnia jest zainstalowany, ale nie jest to niezbędne do wymagania gotowania:

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

• architektura jest dla społeczeństwa/inżynierów na bardziej szczegółowym poziomie abstrakcji
• projekt jest przeznaczony dla publiczności na mniej szczegółowym poziomie abstrakcji

Moje przypomnienie:

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

Myślę, że powinniśmy użyć następującej zasady, aby określić, kiedy mówimy o projektowaniu vs architekturze: jeśli elementy obrazu oprogramowania, które stworzyłeś, mogą być odwzorowane jeden do jednego do konstrukcji składniowej języka programowania, to jest Design, jeśli nie jest architekturą.

Tak więc, na przykład, jeśli widzisz diagram klasy lub diagram sekwencji, jesteś w stanie odwzorować klasę i ich relacje do zorientowanego obiektowo języka programowania przy użyciu konstrukcji składniowej klasy. To jest wyraźnie projekt. Ponadto, może to doprowadzić do tabeli, że ta dyskusja ma związek z językiem programowania, którego użyjesz do wdrożenia systemu oprogramowania. Jeśli używasz Javy, stosuje się poprzedni przykład, ponieważ Java jest zorientowanym obiektowo językiem programowania. Jeśli wymyślisz diagram pokazujący pakiety i ich zależności, będzie to również projekt. Możesz zmapować element (pakiet w tym przypadku) do konstrukcji składniowej Javy.

Załóżmy, że Twoja aplikacja Java jest podzielony na moduły, a każdy moduł jest zbiorem pakietów (reprezentowanym jako jednostka rozmieszczenia plików jar), a Ty otrzymujesz diagram zawierający moduły i ich zależności, czyli architekturę. Nie ma sposobu w Javie (przynajmniej dopiero w Javie 7) na mapowanie modułu (zestawu pakietów) do konstrukcji składniowej. Można również zauważyć, że ten diagram reprezentuje krok wyższy w poziomie abstrakcji modelu oprogramowania. Dowolny schemat powyżej (Gruboziarnisty niż) pakietu diagram, przedstawia widok architektoniczny podczas tworzenia w języku programowania Java. Z drugiej strony, jeśli rozwijasz się w Modula-2, to diagram modułu reprezentuje projekt.

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

Osobiście podoba mi się ten:

" projektant martwi się tym, co się dzieje, gdy użytkownik naciska przycisk, a architekt martwi się tym, co się dzieje, gdy dziesięć tysięcy użytkowników naciska przycisk."

SCEA for Java™ EE Study Guide BY Mark Cade and Humphrey Sheil

Zgadzam się z wieloma wyjaśnieniami; zasadniczo dostrzegamy rozróżnienie między projektem architektonicznym a szczegółowym projektem systemów oprogramowania.

Podczas gdy celem projektanta jest być tak precyzyjny i konkretny w specyfikacji, jak będzie to konieczne do rozwoju; architekt zasadniczo dąży do określenia struktury i globalnego zachowania systemu tak bardzo, jak jest to wymagane do szczegółowego projektu, aby rozpocząć.

Dobry architekt zapobiegnie hiper-specyfikacji-Architektura nie musi być zbyt określone, ale wystarczy, (architektoniczne) decyzje ustanowione tylko dla aspektów, które stanowią najbardziej kosztowne ryzyko do obsługi, i skutecznie zapewnić ramy ("commonality"), w którym szczegółowy projekt może być pracował na TJ zmienność dla lokalnej funkcjonalności.

Rzeczywiście, proces architektury lub cykl życia po prostu podąża za tym tematem-odpowiedni poziom abstrakcji do zarysowania struktury dla (architektonicznie) istotnych wymagań biznesowych i pozostawić więcej szczegółów na etapie projektowania dla bardziej konkretnych rezultatów.

Architektura to projekt, ale nie wszystkie projekty są architektoniczne. dlatego, ściśle mówiąc, byłoby bardziej sensowne, aby spróbować odróżnić projekt architektoniczny i projekt nie-architektoniczny . A jaka jest różnica? To zależy! Każdy architekt oprogramowania może mieć inną odpowiedź (ymmv!). Rozwijamy naszą heurystykę, aby wymyślić odpowiedź, taką jak "diagramy klas to architektura, a diagramy sekwencji to projektowanie". Zobacz DSA book dla więcej.

Powszechnie mówi się, że architektura jest na wyższym poziomie abstrakcji niż projektowanie, lub architektura jest logiczna, a design jest fizyczny. Ale to pojęcie, choć powszechnie przyjęte, jest w praktyce bezużyteczne. Gdzie rysujesz granicę pomiędzy wysoką i niską abstrakcją, pomiędzy logiczną i fizyczną? To zależy!

Więc moja propozycja to:

• Utwórz pojedynczy dokument projektowy.
• nazwij ten dokument projektowy tak, jak chcesz lub, lepiej, tak, jak czytelnicy bardziej przyzwyczajeni. Przykłady: "Architektura Oprogramowania", "Specyfikacja Projektu Oprogramowania".
• podziel ten dokument na widoki i pamiętaj, że możesz utworzyć widok jako udoskonalenie innego widoku.
• aby widoki w dokumencie można było nawigować, dodając odsyłacze lub hiperłącza
• następnie będziesz mieć widoki wyższego poziomu pokazujące szeroki, ale płytki przegląd projektu, oraz widoki bliższe realizacji pokazujące wąskie, ale głębsze szczegóły projektu.
• możesz chcieć aby spojrzeć na przykład dokumentu architektury wielu widoków (tutaj ).

Powiedziawszy to wszystko... bardziej istotne pytanie, które musimy zadać, to: ile wystarczy projekt? to znaczy, kiedy powinienem przestać opisywać projekt (diagramami lub prozą) i przejść do kodowania?

Yep to brzmi dobrze dla mnie. Projekt jest tym, co zamierzasz zrobić, a architektura jest sposobem, w jaki kawałki projektu zostaną połączone ze sobą. Może to być język agnostyczny, ale zwykle określa technologie, które mają być używane, tj. lampa v Windows, Web Service v RPC.

Architektura oprogramowania programu lub systemu komputerowego jest strukturą lub strukturami systemu, które obejmują składniki oprogramowania, widoczne na zewnątrz właściwości tych komponentów i relacje między nimi.

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

Projektowanie oprogramowania jest procesem rozwiązywania problemów i planowania rozwiązania oprogramowania. Po ustaleniu celu i specyfikacji oprogramowania, Programiści zaprojektują lub zatrudnią projektantów do opracowania planu rozwiązania. Obejmuje zagadnienia implementacji komponentów niskiego poziomu i algorytmów, a także widok architektoniczny.

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

Sam bym tego lepiej nie powiedział :)

Widzę architekturę tak, jak Patryk Karcher-z szerszej perspektywy. Na przykład możesz podać architekturę budynku, wyświetlić jego wsparcie konstrukcyjne, okna, wejścia i wyjścia, odprowadzanie wody itp. Ale nie "zaprojektowałeś" układu podłogi, pozycji kabin itp.

Więc kiedy już zaprojektowałeś budynek, nie zaprojektowałeś układu każdego biura. Myślę, że to samo dotyczy oprogramowania.

Można zobaczyć projektowanie układu, jako "architecting the layout"...

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 o tym, jak zbudować lub skonstruować coś, zwłaszcza te decyzje, które będą trudne (lub trudniejsze) do zmiany po wdrożeniu, podczas gdy projektowanie obejmuje te decyzje, które są łatwe do zmiany później (jak nazwy metod, struktura organizacyjna pliku klasy, wzorce projektowe, czy używać pliku). singleton lub klasy statycznej, aby rozwiązać jakiś konkretny problem, itp. ) i/lub te, które wpływają na wygląd lub estetyczne aspekty systemu lub aplikacji (interfejs człowieka, łatwość obsługi, wygląd itp.)

Software architecture is " concerned with issues...poza algorytmami i strukturami danych obliczeń.

W architekturze nie chodzi konkretnie o ... szczegóły implementacji (np. algorytmy i struktury danych.) Projektowanie architektoniczne wiąże się z bogatszym zbiorem abstrakcji niż zazwyczaj zapewnia OOD " (object-oriented design).

Design zajmuje się modularyzacją i szczegółowymi interfejsami elementów projektu, ich algorytmy i procedury oraz typy danych potrzebne do wsparcia architektury i spełnienia wymagań.

"architektura" jest często używany jako zwykły synonim "design" (czasami poprzedzony przymiotnikiem "wysoki poziom"). Wiele osób używa terminu " wzorce architektoniczne "jako synonimu" wzorców projektowych."

Sprawdź ten link.

Definiowanie pojęć Architektura, Projektowanie i realizacja

Architektura:
Prace konstrukcyjne na wyższych poziomach abstrakcji, które realizują istotne technicznie wymagania w systemie. Architektura kładzie podwaliny pod dalszy projekt.

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

Bardzo spodobał mi się ten artykuł za zasadę oddzielania architektury od designu:

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

To się nazywa hipoteza intencji/lokalności. Wypowiedzi na temat natury oprogramowania, które nie są lokalne i intensywne, mają charakter architektoniczny. Wypowiedzi, które są lokalne i intensywne, są projektowane.

...dawno temu w odległym miejscu filozofowie martwili się o rozróżnienie między jednym a wieloma. Architektura jest o relacji, która wymaga wielu. Architektura ma komponenty. Design jest o treści, która wymaga jednego. Projekt ma właściwości, cechy, cechy. Zazwyczaj uważamy, że design mieści się w architekturze. Dualistyczne myślenie daje wielu jako pierwotne. Ale architektura jest również w projektowaniu. To wszystko, jak wybieramy, aby zobaczyć, co jest przed nami-jeden lub wielu.

Dość subiektywne ale moje ujęcie:

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

Design Organizacja i przepływ elementu w całym systemie. Obejmowałoby to również API komponentu do interakcji z innymi komponentami.

Architektura oprogramowania jest najlepiej wykorzystywana na poziomie systemu, gdy trzeba projektować aplikacje biznesowe i funkcje identyfikowane przez wyższe poziomy architektury.

Na przykład Twoja firma dotyczy "zysków i strat" dla handlowców, a twoje główne funkcje obejmowały "ocenę portfela" i "obliczanie ryzyka".

Ale kiedy architekt oprogramowania określi swoje rozwiązanie, zda sobie sprawę, że:

"ocena portfolio" nie może być tylko jedną aplikacją. Informatyka wymaga dopracowania w zarządzaniu projektami takimi jak:

• GUI
• Launcher
• Dispatcher
• ...

(ponieważ operacje są tak ogromne, że muszą być podzielone między kilka komputerów, a jednocześnie monitorowane przez cały czas za pomocą wspólnego interfejsu graficznego)

Projekt oprogramowania zbada różne aplikacje, ich powiązania techniczne i ich wewnętrzne podzespoły.
Opracuje specyfikacje potrzebne do Ostatni warstwa architektury ("Architektura techniczna") do pracy (pod względem RAM technicznych lub elementów przekrojowych), a dla zespołów projektowych (bardziej zorientowanych na realizację funkcji biznesowych ) do rozpoczęcia odpowiednich projektów.

Jeśli ktoś konstruuje statek, to silnik, kadłub, obwody elektryczne itp. będą jego "elementy architektoniczne". Dla niego konstrukcja silnika będzie "pracą projektową".

Jeśli następnie przekaże konstrukcję silnika innemu zespołowi, stworzy "architekturę silnika"...

Więc-to zależy od poziomu abstrakcji lub detalu. Jedna osoba 'architektura może być Another' projekt!

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

Po pracy z TDD, co praktycznie oznacza, że twój projekt zmienia się cały czas, często borykałem się z tym pytaniem. Powyższa definicja jest wyodrębniona z wzorców architektury aplikacji korporacyjnych , autorstwa Martina Fowlera

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

Cliff Notes version:

Design: wdrożenie rozwiązania w oparciu o specyfikację pożądanego produktu.

Architektura: fundament / narzędzia / Infrastruktura / komponenty wspierające Twój projekt.

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

Architektura jest wynikowym zbiorem wzorców projektowych do budowy systemu.

Wydaje mi się, że Design to kreatywność użyta do tego wszystkiego?

Projektowanie oprogramowania ma dłuższą historię, podczas gdy termin Architektura oprogramowania ma zaledwie 20 lat. W związku z tym przechodzi teraz przez rosnące bóle.

Naukowcy postrzegają architekturę jako część większej dziedziny projektowania oprogramowania. Choć coraz bardziej dostrzega się, że Arch jest polem wewnątrz siebie.

Praktycy mają tendencję do postrzegania Arch jako decyzji projektowych wysokiego poziomu, które są strategiczne i mogą być kosztowne w projekcie do cofnięcia.

Dokładna linia pomiędzy Arch i design zależą od domeny oprogramowania. Na przykład w domenie aplikacji webowych największą popularność zyskuje obecnie Architektura warstwowa (warstwa logiczna Biz, Warstwa dostępu do danych itp.) Niższe części tego łuku są uważane za projektowe (diagramy klas, podpisy metod itp.) Byłoby to inaczej definiowane w domenach systemów wbudowanych, systemów operacyjnych, kompilatorów itp.

Architektura to projekt wysokopoziomowy, abstrakcyjny i logiczny, podczas gdy Projektowanie oprogramowania to projekt niskopoziomowy, szczegółowy i fizyczny.

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

Podoba mi się Definicja i Wyjaśnienie Roya Thomasa Fieldinga na temat architektury oprogramowania w jego artykule: style architektoniczne i projektowanie sieciowych Architektur oprogramowania

Architektura oprogramowania jest abstrakcją elementów systemu oprogramowania w pewnym okresie jego działania. System może składać się z wielu poziomów abstrakcji i wielu faz działania, z których każda ma własną architekturę oprogramowania.

On kładzie nacisk na "elementy czasu pracy" i "poziomy abstrakcji".

Nie ma na to ostatecznej odpowiedzi, ponieważ "architektura oprogramowania "i" projektowanie oprogramowania " mają sporo definicji i nie ma kanonicznej definicji dla obu.

Dobrym sposobem myślenia o tym jest stwierdzenie Lena Bassa, Paula Clementsa i Ricka Kazmana, że "cała architektura to design, ale nie wszystko to Architektura" [Architektura oprogramowania w praktyce]. Nie jestem pewien czy do końca się z tym Zgadzam (bo architektura może zawierać inne działania) ale oddaje esencja, że architektura jest czynnością projektową, która zajmuje się krytycznym podzbiorem projektowania.

Moja nieco frapująca definicja (znaleziona na stronie sei definitions ) jest taka, że jest to zbiór decyzji, które, jeśli zostaną podjęte nieprawidłowo, powodują anulowanie twojego projektu.

Użyteczną próbę oddzielenia architektury, designu i implementacji jako koncepcji podjęli Amnon Eden i Rick Kazman kilka lat temu w pracy naukowej zatytułowanej " Architecture, Design, Implementation" które można znaleźć tutaj: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf . ich język jest dość abstrakcyjny, ale w uproszczeniu mówią, że Architektura to projektowanie, które może być używane w wielu kontekstach i ma być stosowane w całym systemie, projektowanie to (err) projektowanie, które może być używane w wielu kontekstach, ale jest stosowane w określonej części systemu, a implementacja to projektowanie specyficzne dla kontekstu i stosowane w tym kontekście.

So an decyzja architektoniczna może być decyzją o integracji systemu za pomocą wiadomości, a nie RPC (więc jest to ogólna zasada, która może być stosowana w wielu miejscach i ma zastosowanie do całego systemu), decyzja projektowa może być użycie struktury wątku master / slave w module obsługi zapytań wejściowych systemu (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 wreszcie, decyzja implementacyjna może być przeniesienie odpowiedzialności za działanie systemu. zabezpieczenie od routera żądań do obsługi żądań w module Menedżera żądań (decyzja istotna tylko dla tego kontekstu, używana w tym kontekście).

Mam nadzieję, że to pomoże!