Entitet-kontroll-gräns
Entity -control-boundary ( ECB ), eller entity-boundary-control ( EBC ), eller boundary-control-entity ( BCE ) är ett arkitektoniskt mönster som används i use-case - driven objektorienterad mjukvarudesign som strukturerar klasserna som utgör en programvara i enlighet med deras ansvar i realiseringen av användningsfall.
Ursprung och evolution
Entity-control-boundary-metoden har sitt ursprung i Ivar Jacobsons use-case driven object-oriented software engineering (OOSE) metod publicerad 1992 , . Det kallades ursprungligen Entity-Interface-Control (EIC) men mycket snabbt ersatte termen " gränssnitt " " gränssnitt " för att undvika potentiell förväxling med objektorienterad programmeringsspråksterminologi .
Den vidareutvecklas i Unified Process , som främjar användningen av ECB i analys- och designaktiviteter med stöd av UML-stereotyper . Agil modellering och ICONIX-processen utvecklades ovanpå ECB:s arkitekturmönster med robusthetsdiagram.
Princip
ECB-mönstret organiserar klassernas ansvar enligt deras roll i realiseringen av användningsfall:
- en enhet representerar långlivad information som är relevant för intressenterna (dvs. mestadels härledd från domänobjekt, vanligtvis persistent);
- en gräns kapslar in interaktion med externa aktörer (användare eller externa system);
- en kontroll säkerställer den bearbetning som krävs för exekvering av ett användningsfall och dess affärslogik, och koordinerar, sekvenser styr andra objekt som är involverade i användningsfallet.
Motsvarande klasser grupperas sedan i tjänstepaket, som är en odelbar uppsättning relaterade klasser som kan användas som mjukvaruleveransenheter.
ECB-klasser identifieras först när användningsfall analyseras:
- varje användningsfall representeras som en kontrollklass;
- varje olika relation mellan ett användningsfall och en aktör representeras som en gränsklass;
- entiteter härleds från berättelsen om användningsfall.
Klasserna förfinas sedan och omstruktureras eller omorganiseras efter behov för designen, till exempel:
- Factoring ut vanliga beteenden i olika användningsfallskontroller
- Identifiera en central gränsklass för varje typ av mänsklig aktör och för varje externt system som skulle ge ett konsekvent gränssnitt till omvärlden.
ECB-mönstret antar att klassernas ansvar också återspeglas i relationerna och interaktionerna mellan de olika kategorierna av klasser för att säkerställa robustheten i designen.
Robusthetsdiagram
Robusthetsdiagram gör det möjligt att visuellt representera relationen mellan enheter, kontroller, gränser och aktörer. Den använder grafiska stereotyper som introducerades i Jacobsons tidiga arbete:
| Representation | Relation med | ||||
|---|---|---|---|---|---|
| Roll | Symbol | Skådespelare | Gräns | Kontrollera | Entitet |
| Skådespelare |
|
Ja | Ja | Nej | Nej |
| Gräns |
|
Ja | Del/hel | Ja | Nej |
| Kontrollera |
|
Nej | Ja | Ja | Ja |
| Entitet |
|
Nej | Nej | Ja | Ja |
Följande robusthetsbegränsningar gäller:
- Skådespelare kanske bara känner till och kommunicerar med gränser
- Gränser får endast kommunicera med aktörer och kontroller.
- Kontroller kan känna till och kommunicera med gränser och enheter, och vid behov andra kontroller
- Entiteter kanske bara känner till andra enheter men kan också kommunicera med kontroller;
I princip bör enheter inte känna till gränser och kontroller. I praktiken tillåter dock vissa varianter enheter, gränser och kontroller att prenumerera som observatör till en enhet.
På samma sätt gäller begränsningen att en gränsklass inte känner till andra gränsklasser endast på den högsta nivån, och inte mellan klasser som samarbetar för att implementera samma gräns.
Relation till andra arkitektoniska mönster
Det finns en viss likhet mellan ECB och modell–vy–kontrollant (MVC): enheter tillhör modellen och synpunkter tillhör gränser. Emellertid skiljer sig ECB-kontrollens roll mycket från MVC-kontrollanten, eftersom den även kapslar in affärslogik för användningsfall medan MVC-kontrollanten bearbetar användarinmatning som skulle vara gränsens ansvar i ECB. ECB:s kontroll ökar separationen av problem i arkitekturen genom att kapsla in affärslogik som inte är direkt relaterad till en enhet.
ECB kan användas tillsammans med den hexagonala arkitekturen , närhelst gränserna bildar det yttre adapterskiktet.
ECB är kompatibel med den rena arkitekturen som förenar ECB:s principer med andra arkitektoniska designparadigm. Ren arkitektur placerar entiteter i kärnan och omger dem med en användbar ring (dvs. ECB-kontroll) och en ring med gateways och presentatörer (dvs. ECB-gränser). Ren arkitektur kräver dock ett enkelriktat beroende från utsidan till insidan, vilket kräver att ECB:s kontroller delas upp i användningsfallslogik och objektkoordinering.