Mapowanie między modelem widoku architektonicznego 4 + 1 a UML

Jestem trochę zdezorientowany, w jaki sposób model widoku architektonicznego 4 + 1 mapuje się na UML.

Wikipedia podaje następujące mapowanie:

• Widok logiczny: schemat klasy, schemat komunikacji, schemat sekwencji.
• Widok rozwoju: schemat komponentów, schemat pakietów
• Widok procesu: Diagram aktywności
• Widok fizyczny: schemat rozmieszczenia
• Scenariusze: schemat przypadków użycia

Papierowa rola konstrukcji diagramu sekwencji UML w koncepcji cyklu życia obiektu daje następujące mapowanie:

• Widok logiczny (schemat klasy (CD), schemat obiektów (OD), schemat sekwencji (SD), schemat współpracy (COD), schemat wykresu stanu (SCD), schemat aktywności (AD))
• Widok programowania (schemat pakietu, schemat komponentu),
• Widok procesu (schemat przypadków użycia, CD, OD, SD, COD, SCD, AD),
• Widok fizyczny (schemat wdrażania) oraz
• Widok przypadku użycia (schemat przypadku użycia, OD, SD, COD, SCD, AD), który łączy cztery wymienione powyżej.

Strona internetowa UML 4 + 1 Wyświetl materiały przedstawia następujące mapowanie:

Wreszcie, biała księga Zastosowanie architektury widoku 4 + 1 z UML 2 daje jeszcze jedno mapowanie:

• Logiczne diagramy klas widoków, diagramy obiektów, wykresy stanów i struktury złożone
• Diagramy sekwencji widoków procesu , diagramy komunikacji, diagramy aktywności, diagramy czasowe, diagramy przeglądu interakcji
• Diagramy komponentów widoku rozwoju
• Schemat rozmieszczenia widoku fizycznego
• Widok przypadku użycia schemat użycia przypadku, diagramy aktywności

Jestem pewien, że dalsze wyszukiwanie ujawni również inne mapowania.

Podczas gdy różni ludzie zwykle mają różne perspektywy, nie rozumiem, dlaczego tak jest w tym przypadku. W szczególności każdy diagram UML opisuje system z określonego aspektu. Na przykład dlaczego „schemat sekwencji” jest uważany za opisujący „logiczny widok” systemu przez jednego autora, podczas gdy inny autor uważa go za opisujący „widok procesu”?

Czy możesz mi pomóc wyjaśnić zamieszanie?

Chociaż generalnie zgadzam się z odpowiedzią Barta van Ingen Schenau , myślę, że kilka punktów wymaga dodatkowych wyjaśnień.

Zaletą modelu widokowego 4 + 1 jest to, że mapuje interesariuszy do rodzaju potrzebnych informacji, bez konieczności stosowania określonych notacji modelowania. Nacisk kładziony jest na zapewnienie, aby wszystkie grupy miały informacje pozwalające zrozumieć system i kontynuować wykonywanie swojej pracy.

Model widokowy architektury oprogramowania 4 + 1 został opisany w artykule Philippe Kruchten w artykule Plany architektoniczne - model widokowy architektury oprogramowania 4 + 1, który został pierwotnie opublikowany w IEEE Software (listopad 1995 r.). Ta publikacja nie zawiera konkretnych odniesień do UML. W rzeczywistości w pracy wykorzystano notację Boocha dla widoku logicznego, rozszerzenia notacji Booch dla widoku procesu i widoku rozwoju, wzywa się do zastosowania „kilku form” opracowania widoku fizycznego oraz nowej notacji dla scenariuszy.

Zamiast próbować mapować każdy z widoków na poszczególne typy diagramów, zastanów się, kim są docelowi odbiorcy każdego widoku i jakich informacji potrzebują. Wiedząc o tym, spójrz na różne typy modeli i które z nich zawierają wymagane informacje.

Widok logiczny ma na celu rozwiać obawy użytkownika końcowego związane z zapewnieniem, że wszystkie pożądane funkcje zostaną przechwycone przez system. W systemie obiektowym często dzieje się tak na poziomie klasy. W złożonych systemach może być potrzebny widok pakietu i rozpakowanie pakietów na diagramy wielu klas. W innych paradygmatach możesz być zainteresowany reprezentowaniem modułów i ich funkcji. Wynikiem końcowym powinno być mapowanie wymaganej funkcjonalności na komponenty, które ją zapewniają.

Widok procesu jest przeznaczony dla osób projektujących cały system, a następnie integrujących podsystemy lub system w system systemów. Ten widok pokazuje zadania i procesy, które ma system, interfejsy do świata zewnętrznego i / lub między komponentami w systemie, wysyłane i odbierane komunikaty oraz sposób, w jaki są obsługiwane wydajność, dostępność, odporność na awarie i integralność.

Widok programowania jest przeznaczony głównie dla programistów, którzy będą budować moduły i podsystemy. Powinien pokazywać zależności i relacje między modułami, sposób ich organizacji, ponownego wykorzystania i przenośności.

Widok fizyczny jest przeznaczony przede wszystkim dla projektantów systemów i administratorów, którzy muszą zrozumieć fizyczne lokalizacje oprogramowania, fizyczne połączenia między węzłami, wdrożenie i instalację oraz skalowalność.

Wreszcie scenariusze pomagają uchwycić wymagania, aby wszyscy interesariusze zrozumieli, w jaki sposób system ma być używany.

Gdy zrozumiesz, co ma zapewniać każdy widok, możesz wybrać, jakich notacji modelowania użyć i na jakim poziomie szczegółowości jest wymagany. Ostatni akapit Barta jest szczególnie prawdziwy - możesz pokazać różne poziomy szczegółowości w swoich modelach UML, skupiając się na konkretnych elementach projektu lub łącząc różne typy diagramów w zestaw. Ponadto możesz rozważyć wyjście poza UML do innych notacji modelowania, aby lepiej opisać architekturę systemu - SysML , modelowanie encji-relacji lub IDEF .

Powodem, dla którego nie można znaleźć mapowania jeden na jeden między widokami modelu architektonicznego 4 + 1 i różnymi diagramami UML, jest to, że takie mapowanie nie istnieje.

Wszyscy autorzy próbują powiedzieć swoimi „mapowaniami”, że dla każdego widoku istnieje inny zestaw diagramów UML, które mogą być przydatne do przekazania informacji, które chcesz przekazać w tym widoku.

Ponadto niektóre diagramy UML mogą być używane na różne sposoby, podkreślając różne elementy na diagramie, co czyni je przydatnymi w wielu widokach. Ale nawet jeśli jeden typ diagramu UML może być użyty w wielu widokach, narysujesz inny diagram (lub zestaw diagramów) dla każdego widoku.

Chociaż zgadzam się z podejściem odpowiedzi Thomasa Owensa, aby zaspokoić potrzeby użytkowników końcowych, jedną rzeczą, o której nie wspomina się, jest to, że pierwotna definicja „architektury modelu widoku 4 + 1” autorstwa Kruchten nie czyni żadnej specyficzne odniesienia do UML są dlatego, że artykuł został napisany w 1995 roku (jak stwierdza odpowiedź), ale UML nie został tak naprawdę przyjęty jako standard do 1997 roku .

Ciągłe stosowanie notacji Booch w tym artykule sugeruje, że odpowiednie może być powiązanie każdego z widoków modeli z konkretnym diagramem UML, ponieważ Grady Booch był jedną z osób zaangażowanych w rozwój UML.

Z tego powodu tak wielu różnych autorów uważa różne diagramy UML za odpowiednie do każdego widoku, ponieważ wiele diagramów UML można rozważyć w pewnej ilości „abstrakcji” Notacji Booch, na której opiera się oryginalna definicja modelu 4 + 1 reprezentować każdy widok.

Mam nadzieję, że to wyjaśni trochę więcej dla każdego, kto się tym zajmie.

Czy nadal używasz magnetowidu kupionego w 1995 r.? 4 + 1 miało zastosowanie wtedy, gdy oprogramowanie było w powijakach. Ale nawet wtedy nikt nigdy nie używał więcej niż 2 lub 3 „widoków”. W ciągu ostatnich 20 lat zmieniła się inżynieria oprogramowania. Obecnie zakres / kontekst oraz koncepcyjne i logiczne oraz fizyczne i ... są zróżnicowane. Wiele rozwiązań COTS musi być zintegrowanych i tak dalej. Dzisiaj mówimy o mapach krajobrazowych, realizacji usług i dziesiątkach innych widoków i punktów widzenia. Najlepszym sposobem, aby na to spojrzeć, są proste ramy taksonomii, takie jak Zachman: 6 widoków i 6 punktów widzenia. Niech to będzie twój punkt wyjścia. 6 widoków to: kontekstowe koncepcyjne lub logiczne biznesowe lub systemowe fizyczne lub technologiczne dostawy lub artefakty funkcjonujące w przedsiębiorstwie

6 punktów widzenia to: dane lub Jaka funkcja lub Jak sieć lub Gdzie ludzie lub Kto czas lub Kiedy motywacja lub Dlaczego

Spójrzmy na przykład. Jeśli interesują nas tylko dane, zaczniemy od widoku zakresu i powiemy „Nasz zakres to CRM”. W widoku koncepcyjnym punktu widzenia danych wymyślimy jakiś model semantyczny dla CRM. Model będzie koncepcyjnymi koncepcjami informacji biznesowych, a nie obiektami danych. Następnie w widoku logicznym stworzymy logiczny model danych z naszego koncepcyjnego modelu CRM. Możemy użyć metodologii ER do stworzenia logicznego modelu danych. Następnie, w widoku fizycznym, stworzymy fizyczny model danych. W tym miejscu zdefiniujemy konkretne typy danych dla wybranej przez nas platformy db, indeksów itp. Wreszcie w widoku dostawy będziemy mieli nasz skrypt DDL, natomiast w działającym widoku przedsiębiorstwa będziemy mieć plik binarny wdrożony na pewnym serwerze bazy danych i odwzorowane na wewnętrzne struktury danych dostawcy DBM. Powtarzamy to dla każdego punktu widzenia lub kolumny. Ponadto, jeśli istnieje więcej niż jeden interesariusz, stworzymy więcej niż jeden model dla każdej kombinacji punktu widzenia / widoku. Teraz, gdy masz już taką taksonomię, możesz zdefiniować własne punkty widzenia i poglądy i dopasować je do tej taksonomii. Na przykład w przypadku inicjatyw na poziomie przedsiębiorstwa ważne są następujące punkty widzenia: współpraca aktorów zachowanie aplikacji współpraca aplikacji struktura aplikacji wykorzystanie aplikacji funkcja biznesowa proces biznesowy implementacja współpracy biznesowej proces wdrażania i wdrażania struktura informacji wykorzystanie infrastruktury infrastruktura przegląd mapy przegląd warstwowa realizacja usług organizacyjnych itp Teraz, gdy masz już taką taksonomię, możesz zdefiniować własne punkty widzenia i poglądy i dopasować je do tej taksonomii. Na przykład w przypadku inicjatyw na poziomie przedsiębiorstwa ważne są następujące punkty widzenia: współpraca aktorów zachowanie aplikacji współpraca aplikacji struktura aplikacji wykorzystanie aplikacji funkcja biznesowa proces biznesowy implementacja współpracy biznesowej proces wdrażania i wdrażania struktura informacji wykorzystanie infrastruktury infrastruktura przegląd mapy przegląd warstwowa realizacja usług organizacyjnych itp Teraz, gdy masz już taką taksonomię, możesz zdefiniować własne punkty widzenia i poglądy i dopasować je do tej taksonomii. Na przykład w przypadku inicjatyw na poziomie przedsiębiorstwa ważne są następujące punkty widzenia: współpraca aktorów zachowanie aplikacji współpraca aplikacji struktura aplikacji wykorzystanie aplikacji funkcja biznesowa proces biznesowy implementacja współpracy biznesowej proces wdrażania i wdrażania struktura informacji wykorzystanie infrastruktury infrastruktura przegląd mapy przegląd warstwowa realizacja usług organizacyjnych itp

4 + 1 Krutchen nie byłby w stanie zaspokoić wszystkich tych potrzeb