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?
źródło
The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level
. Czy nie uważasz, że jeśli chcemy coś zrobić dla użytkowników końcowych, musimy przynajmniej się z nimi porozumieć i mówić jednym językiem. Spróbuj pokazać diagram klas swoim użytkownikom i zobaczmy, co powiedzą.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.
źródło
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.
źródło
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
źródło