Lo stile di livello applicato, ma l'intuizione è diversa

Naviga le tue risposte
0

Attualmente sto sviluppando un'architettura per un sistema del tipo seguente:

Ci sono un paio di applicazioni esistenti (front-end) con cui è possibile definire profili UML catturando alcuni aspetti specifici del dominio. Poiché gli strumenti sono proprietari, i modelli prodotti non sono scambiabili di default. D'altra parte ci sono un paio di strumenti che possono analizzare i modelli frontend prodotti (back end). Questi hanno anche i loro meccanismi (che sono diversi dai frontend) per rappresentare gli aspetti del dominio.

Dato che questo produrrebbe trasformazioni di modelli m * n con m frontend e n backend, ho scelto di introdurre un modello di scambio che raccolga tutte le informazioni rilevanti dai front-end e tuttavia consenta al back-end di disporre di informazioni sufficienti per l'analisi. Questo approccio produce solo trasformazioni m + n.

La mia vista a volo d'uccello sull'architettura:

Lecosevannocosì:

Latrasformazioneèpossibiletrailmodellodifrontend<->modellodiscambioemodellodiscambio<->ilmodellodibackend.Leattivitàdianalisisonoattivatenelfrontendesonodelegatealback-end,dovevengonoeseguite.

Aprimavista,misembravaunostileastrati,mapiùcipensavo,l'intuizionedelproblemanonèquelladirenderediversilivelliintercambiabili,incuiglistratiraggiungonolaseparazionedellepreoccupazioniesiconcentranosullaportabilità.

Sitrattapiuttostodiintrodurreunostratointermedio,chedisaccoppiaglialtridueesirivolgeprincipalmenteall'estensione.Unaltropuntoèchel'astrazionepiùaltanonsitrovasullostratopiùaltomasullostratointermedio,cioèilformatodiscambiodeveessereilnucleodell'architetturaacuièpossibilecollegarefrontendebackend.Nondovrebbeesserenecessariosaperenulladeifrontendodeibackendallegati.Ciòsignificaanchecheillivellodiback-enddevesaperecometrasformareilformatodiscambionellapropriarappresentazionedelmodello,cheèunutilizzoascendentenonconsentitonellostileastrati.

Questosiriducealledomande:

  1. Conosciqualchestilearchitettonicosimileaquellochehodescrittoenesegueanchel'intuizione?
  2. Perchéquestononèunbuonesempioperlostileapiùlivelli(apartel'usocrescente)?
  3. Poichél'applicazioneèprincipalmenteguidatadalmodello,esistonoalcunimodelli/stiliarchitettonicispecificipersistemidiquestotipo?

Grazieperl'aiutoinanticipo!

EDIT:Inrealtàmipreoccupodeglistrati,perchélavisionegrossolanadiquestaarchitetturaèincorporatainunprogettoesistenteevienecomunicatalìcome"strati". Ma dal punto di vista architettonico, non si adatta allo stile. Il problema sta tra la documentazione e la comunicazione dell'architettura. Se la maggior parte degli stakeholder parla di un'architettura a più livelli e io introduco la vista a strati in essa, sebbene non sia applicata correttamente, non confonderebbe tutti gli stakeholder, che hanno la giusta comprensione di un'architettura a più livelli?

L'obiettivo è di documentare le viste dello stile che è realmente applicato per avere una base corretta per comunicare l'architettura.

    
posta McMannus 19.09.2013 - 12:46
fonte

1 risposta

1

Il Frontend-Exchange-Backend presentato nella domanda può essere facilmente identificato come approccio a tre strati molto comune, di solito visto nei sistemi distribuiti (vedi, ad esempio middleware , forse inteso in senso leggermente più ampio).

Il linguaggio comune tra le parti interessate è più importante della purezza dell'attuazione. Ad esempio, molti sistemi MVC basati sul Web sono lontani dall'ideale e anche lontano dall'essere MVC in primo luogo . Il significato dei livelli nel tuo caso può essere spiegato in una sezione Panoramica della documentazione.

Più importante è che l'architettura software rende il sistema meno complesso aggiungendo un livello di astrazione tra frontend e backend eterogenei.

Al macrolevel, l'architettura a strati che descrivi sembra essere ok. Personalmente avrei preferito l'architettura basata su componenti nel tuo caso, ma immagino che i due non si escludano a vicenda, dato che i componenti possono essere facilmente pensati come disposti in livelli.

Su un microlivello, dai un'occhiata a schemi strutturali come Adattatore , Proxy e Facciata . Non che quelli dovrebbero essere usati direttamente (dipende da ciò che si sta costruendo, modelli di elaborazione dei dati, ecc.). I pattern dipendono anche da una mancata corrispondenza di impedenza tra frontend e backend. Ad esempio, diverse modalità di funzionamento possono rendere più difficile il collegamento delle parti (ad esempio, se un frontend utilizza la tecnologia "push", un'altra tecnologia "pull" e, per esempio, la terza utilizza la modalità batch per eseguire attività / dati di scarico una volta al giorno - Ho incontrato questo caso in una delle applicazioni).

Dalla tua domanda non è del tutto chiaro se la tua applicazione costruisce software usando i modelli UML o è il risultato finale della trasformazione di UML in codice (o è addirittura un interprete di runtime per UML?). In ogni caso, l'incollaggio è necessario e l'architettura risultante potrebbe essere abbastanza simile in entrambi i casi.

Il modello-driveness è, IMHO, ortogonale alla stratificazione dell'architettura. Tuttavia, non ho molta familiarità con Architettura guidata dal modello , se questo è ciò che intendi. E a questo proposito parti pronte della soluzione vincolano la scelta dell'architettura. Se ho capito bene la domanda, hai diversi DSL (ognuno dei frontend utilizza UML diversi).

Tutto sommato, è molto difficile consigliare un'astrazione architettonica adeguata da una panoramica già molto astratta. Il consiglio è comunque quello di dimenticare la purezza e preoccuparsi di più per la praticità.

    
risposta data 19.09.2013 - 16:42
fonte

Leggi altre domande sui tag

Struttura corretta di un progetto esistente nell'architettura MVC Quando si pronuncia "near ID" / "lontano ID" quando si utilizza RTMFP in ActionScript 3?