Potrebbe essere praticamente difficile limitarsi a UML 1 solo per il seguente motivo: Quasi tutti gli strumenti disponibili per i diagrammi di disegno implementano UML 2 da molto tempo. Pertanto, ogni volta che si disegna un costrutto, è necessario verificare manualmente se fosse già disponibile in UML 1.
Il passaggio da 1 a 2 è stato in gran parte motivato dall'hype di ingegneria del software denominato MDA (Model Driven Architettura) circa 10,15 anni fa. Si trattava di generare software direttamente dal modello. Per supportare questo, tutti gli elementi del modello sono stati definiti attraverso una semantica formale. Inoltre, alcuni tipi di modelli e diagrammi sono stati migliorati. I diagrammi di sequenza sono stati arricchiti per controllare le strutture per esprimere i flussi di controllo. I diagrammi dei componenti e della distribuzione sono stati migliorati.
Ora, oltre a suggerire che non ha molto senso tornare a UML 1, ho letto dalla tua domanda che è necessario impostare le priorità. Ciò ha senso, poiché la definizione di UML (1 e 2) è piuttosto lunga e non si vuole studiarne tutti i dettagli. Quindi, ecco alcuni suggerimenti:
Con tecnologia object oriented ovunque intorno, classe modellazione è la nozione centrale. Dovresti quindi avere familiarità con classi, associazioni, aggregazioni, composizione, ereditarietà, attributi, operazioni e relativi parametri e risultati, visibilità di metodi e attributi, classi e metodi astratti e interfacce.
Gli oggetti di una classe cambiano i loro stati mediante l'applicazione delle loro operazioni. Un modello centrale, e talvolta sottovalutato, di conseguenza è la modellazione di stato . Qui, UML offre due tipi di diagrammi e diagrammi parzialmente ridondanti: modelli di stato e di attività. Dovresti prendere confidenza con almeno uno di questi - passare all'altra dovrebbe quindi non essere troppo difficile.
La maggior parte degli utenti di UML è piuttosto affezionata allo di utilizzo del modello. Non lo sono, in quanto questi casi d'uso tendono a non avere alcun significato (se si limitano a nominare casi d'uso e attori) o struttura (se si inizia a documentare dati e funzionalità del sistema con i propri casi d'uso). Ma il resto del mondo ti accetterà solo come esperto di UML se li conosci, quindi non sarai in grado di evitarli. Prima di usarli a lungo, pensa a come raggiungere il principio DRY (non ripeterti) quando descrivi un sistema tramite casi d'uso.
un'occhiata http://www.differencebetween.info/difference-between-uml-1-and-uml-2 – deadman
@deadman, grazie uomo. Lo controllerò. – Vinvinvinvin
Penso che per l'applicazione pratica la differenza tra questi due sia piuttosto marginale, è possibile creare un modello molto cattivo (o buono) in entrambi. Probabilmente dovresti concentrarti solo su parti di UML rilevanti per il tuo lavoro (come i diagrammi di classe per la progettazione del database, il caso d'uso e BPM per l'analisi dei processi aziendali ecc.) –