Teraz używam NetBeans jako mojego preferowanego IDE i ma on wtyczkę do modelowania UML. Na schemacie klasy, są znane jako elementy modelu Boundary Class, Control Classoraz Entity Class. Jednak nie mogę znaleźć dobrej ich definicji, ale znalazłem tę witrynę na diagramach klas UML.
Co to są klasy graniczne, klasy kontrolne i klasy jednostek na diagramach klas UML?
Odpowiedzi:
Często używany z / jako część OOAD i modelowania biznesowego. Definicja Neila jest poprawna, ale jest w zasadzie identyczna z definicją MVC, ale tylko abstrakcyjna dla biznesu. „Dobre podsumowanie” jest dobrze zrobione, więc nie będę go tutaj kopiować, ponieważ nie jest to moja praca, bardziej szczegółowa, ale zgodna z wypunktowaniem Neila.
Dobre podsumowanie - Conceito: Entity-Control-Boundary Pattern
3
Ale MVC jest tylko dla warstwy widoku.
—
Alex78191
Odpowiedź powinna zawierać informację, a nie tylko link do niej. Niestety łącze nie działa.
—
Johan,
@ ted-johnson Czy jest szansa na zaktualizowany link? Dzięki!
—
Narshe
Zaktualizowany link do podobnej witryny, która zawierała treść.
—
Ted Johnson,
Diagramy odporności są zapisywane po przypadkach użycia, a przed diagramami klas. Pomagają zidentyfikować role poszczególnych etapów przypadków użycia. Możesz ich użyć, aby upewnić się, że przypadki użycia są wystarczająco solidne, aby reprezentować wymagania użytkowania dla budowanego systemu.
Obejmują:
- Aktorzy
- Przypadków użycia
- Podmioty
- Granic
- Sterownica
Podczas gdy wzorzec Model-View-Controller jest używany w interfejsach użytkownika, w systemach używany jest wzorzec Entity-Control-Boundary Pattern (ECB). Poniższe aspekty EBC można porównać do abstrakcyjnej wersji MVC, jeśli jest to pomocne:
Jednostki (model)
Obiekty reprezentujące dane systemowe, często z modelu domeny.
Granice (widok / współpracownik usługi)
Obiekty, które łączą się z aktorami systemu (np. Użytkownikiem lub usługą zewnętrzną ). Okna, ekrany i menu to przykłady granic, które występują między użytkownikami.
Kontrole (kontroler)
Obiekty, które pośredniczą między granicami i jednostkami. Służą one jako spoiwo między elementami granicznymi a elementami encji, wdrażając logikę wymaganą do zarządzania różnymi elementami i ich interakcjami. Ważne jest, aby zrozumieć, że możesz zdecydować się na zaimplementowanie kontrolerów w swoim projekcie jako coś innego niż obiekty - wiele kontrolerów jest na tyle prostych, że można je zaimplementować na przykład jako metodę jednostki lub klasy granicznej.
Do komunikacji mają zastosowanie cztery zasady:
- Aktorzy mogą rozmawiać tylko z obiektami granicznymi.
- Obiekty graniczne mogą rozmawiać tylko z kontrolerami i aktorami.
- Obiekty encji mogą komunikować się tylko z kontrolerami.
- Kontrolery mogą rozmawiać z obiektami granic i obiektami jednostek oraz z innymi kontrolerami, ale nie z aktorami
Komunikacja dozwolona:
Entity Boundary Control
Entity X X
Boundary X
Control X X X
Sądząc po komentarzach, ta odpowiedź nie pomaga ludziom docenić różnicy między „Entity Boundary Control” a MVC. Jedną z nich jest to, że granica nie jest widokiem; jest to element systemu, który zarządza komunikacją z elementami spoza projektowanego obszaru, niezależnie od tego, jaki to obszar. Na przykład fasada PayPal REST API wewnątrz systemu może być elementem granicznym. Ponadto Twoje podsystemy mogą mieć własne granice. Porównaj to z widokiem, który jest zawsze widokiem z dowolnej perspektywy i jest zawsze skierowany do użytkownika.
—
DavidS
Ta odpowiedź zawiera tak naprawdę to samo: „Granica: Obiekty, które łączą się z aktorami systemu (np. Użytkownik lub usługa zewnętrzna )”. W każdym razie chodzi mi o to, że są one różne: EBC nie jest „uproszczeniem” MVC.
—
DavidS
Są to stereotypy klasowe używane w analizie.
klasy graniczne to te na granicy systemu - klasy, z którymi Ty lub inne systemy współdziałają
klasy jednostek to typowe jednostki biznesowe, takie jak „osoba” i „konto bankowe”
klasy kontrolne implementują logikę biznesową lub inną
Wzorzec Boundary Control Entity ma dwie wersje:
- stary strukturalny, opisany jako 127 (byt jako elementy modelu danych, sterowanie jako funkcje, granica jako interfejs aplikacji)
- nowy wzorzec obiektowy
Jako wzorzec obiektowy:
- Boundary to interfejs dla " inny świat ”
- Sterowanie w dowolnej logice wewnętrznej (jak usługa we wzorcu DDD)
- Podmiot jest trwałym serwisem dla obiektów (jak repozytorium we wzorcu DDD).
Wszystkie klasy mają operacje (zobacz anty-wzorzec modelu domeny anemicznej Fowlera).
Wszystkie z nich są komponentem Model we wzorcu MVC. Zasady:
- Tylko Boundary świadczy usługi dla „innego świata”
- Boundary może dzwonić tylko do Controll
- Control może dzwonić do każdego
- Podmiot nie może do nikogo dzwonić (!), Można go tylko wywołać.
J z
W rzeczywistości Diagramy Solidności (lub Diagramy analizy, jak się je czasem nazywa) są po prostu wyspecjalizowanymi diagramami klas. Są częścią UML i są od początku (patrz książka Jacobsona, The Unified Software Development Process - część serii książek „Three Amigos”). Wspomniana książka zawiera dobrą definicję tych trzech klas na str. 183-185.