È possibile sviluppare un modello in un singolo file e quindi dividerlo in più file, denominati partizioni del modello. Si consiglia di considerare la suddivisione in partizioni di un modello quando la dimensione o la struttura di compressione del modello diventa ingestibile.
Si consiglia di suddividere in partizioni un modello solo in circostanze estreme, perché tale suddivisione in partizioni potrebbe ostacolare lo sviluppo e la collaborazione del team se non si esegue correttamente. Prima di considerare la suddivisione in partizioni di un modello, verificare di disporre di una struttura efficace per il modello e di assegnare la proprietà reale di tale modello, in modo da ridurre al minimo le partizioni e le unioni importanti.
Una struttura efficace di un modello si affida in gran parte alla scomposizione. I seguenti principi di scomposizione sono gli stessi che regolano lo sviluppo orientato agli oggetti, la progettazione basata su componenti e le architetture orientate al servizio:
Se il modello scomposto contiene ancora un numero elevato di dipendenze, è possibile scegliere due opzioni:
Dopo avere stabilito una struttura efficace, è possibile assegnare la proprietà dei componenti strutturali a singoli o a team ridotti. Quando una sola persona o un team ridotto nelle vicinanze lavora su un pacchetto logico o in una filiale di un modello, si riducono al minimo le unioni importanti con tale modello, indipendentemente dal fatto che si memorizzi il modello in un singolo file di modellamento o in più file.
Non è possibile evitare unioni importanti suddividendo in partizioni i modelli in più file di modellamento, perché le interdipendenze strutturali sono logiche e non fisiche. Se si suddivide un modello in partizioni in più file di modellamento, le rappresentazioni delle interdipendenze di elementi diventano riferimenti a più file anziché riferimenti interni ai file.
I conflitti di unione che si verificano a causa di riferimenti a più file interrotti sono difficili da risolvere. Tali riferimenti rappresentano potenziali punti di interruzione, perché si espongono i file nel sistema file host. Di conseguenza, se si spostano, si ridenominano o si modificano i file all'esterno dell'ambiente Eclipse, non è possibile tenere traccia dei riferimenti a più file.
Si consiglia di considerare la suddivisione in partizioni di un modello in più file nelle seguenti situazioni:
Alcuni criteri di gestione configurazione consentono lo sviluppo parallelo, in cui più membri di un team lavorano su un modello contemporaneamente. Durante lo sviluppo parallelo, le modifiche non coordinate potrebbero influire sul file e sul modello logico o sulla sottoserie del modello rappresentata dal file. Prima di poter salvare il file del modello nel sistema di gestione configurazione, è necessario unire le eventuali modifiche. Un'unione significativa si verifica quando le modifiche non presentano conflitti e lo strumento di unione modelli unisce automaticamente le modifiche. Un'unione significativa si verifica quando più utenti consegnano modifiche contrastanti e un utente deve determinare quali modifiche accettare.
Si consiglia di suddividere un modello in partizioni solo se il relativo livello di astrazione si stabilizza. In tal caso, la suddivisione in partizioni è meno incline a cambiare. È inoltre consigliabile identificare i componenti comuni e stabilizzarli prima, perché le modifiche ai componenti comuni potrebbero creare conflitti che si ripercuoterebbero su tutte le altre partizioni.
Le versioni precedenti di un modello spesso illustrano i sottosistemi di livello superiore di un sistema. Non è consigliabile separare il modello finché non si definiscono i probabili sottosistemi di livello superiore permanenti nelle iterazioni future. Quando i sottosistemi di livello superiore sono pronti e stabili, è possibile separarli per consentire lo sviluppo parallelo e per migliorare la velocità con cui si apre il modello. Quando il contenuto di un singolo sistema si stabilizza, è possibile dividere il sottosistema.
Per evitare il danneggiamento dei dati quando si gestiscono partizioni di un modello, è consigliabile lavorare sempre in uno spazio di lavoro sincronizzato che contenga tutte le partizioni allo stesso livello di revisione.
Esempio
Nel seguente esempio viene mostrato il risultato della gestione di partizioni di un modello in uno spazio non sincronizzato.
In un sistema di gestione configurazione, un modello ha due partizioni, modello X e modello Y. Entrambi i modelli dispongono della versione 20. Il modello X contiene un pacchetto, denominato P1. Il modello Y è vuoto.
Due utenti sono coinvolti nel seguente flusso di lavoro:
Se l'utente B seleziona la versione esistente nello spazio di lavoro (modello X, versione 20), è possibile che debba ripetere l'operazione di verifica.
Tuttavia, se l'utente B salva le modifiche con la versione di modello più recente (modello X, versione 21), sovrascrive le modifiche apportate dall'utente A.