«Un giorno nella vita di uno scoiattolo» o dalla modellazione dei processi alla progettazione di un sistema automatizzato per la registrazione dei beni materiali «Scoiattolo-1.0» (Parte 2)
Riepilogo della puntata precedente
In abbiamo utilizzato un'area tematica «fiabesca», ispirati da esempi di studio delle diagrammi UML basati su trame di fiabe (cfr., per esempio, [1]). Prima dell'inizio della modellazione, abbiamo concordato sull'uso di alcuni elementi del diagramma di Attività e abbiamo iniziato a formare un accordo sulla modellazione. Tenendo conto di questi accordi, nella prima fase abbiamo descritto il processo sotto forma di diagrammi di Attività, e nella seconda fase abbiamo identificato i passaggi del processo per i quali è necessaria (e possibile) l'automazione.
Ricordo che intendiamo automatizzare l'attività di registrazione dei beni materiali, che si verifica in questi processi.
…
Un'isola si trova in mare, (E1, E2)
Una città sull'isola esiste (E3, E1)
Con chiese d'oro, (E4)
Con torri e giardini; (E5, E6)
Un abete cresce davanti al palazzo, (E7, E8)
E sotto di esso una casa di cristallo; (E9)
Là vive uno scoiattolo domestico, (A1)
Che fantastica creatura! (A1)
Lo scoiattolo canta canzoni, (P1, A1)
E morde noci, (P2)
Ma non noci comuni, (C1)
Tutte con gusci d'oro, (C2)
Con un cuore di puro smeraldo; (C3)
I servitori vigilano sullo scoiattolo, (P3, A2)
Le fanno da servitori vari (P4)
E un funzionario rigoroso è assegnato (A3)
Il conteggio delle noci è preciso; (P5, C1)
L'esercito le presta onore; (P6, A4)
Dai gusci si battono monete, (P7, C2, C4)
E girano nel mondo; (P8)
Le ragazze spruzzano smeraldi (P9, A5, C3)
Nelle cantine, e sotto il pavimento; (E10, E11)
…
(A.S. Pushkin «La fiaba del re Saltano, del suo glorioso e potente figlio, il guerriero principe Guidone Saltanovič e della bella principessa Cigno», )
In questo esempio utilizzo l'ambiente Enterprise Architect dell'azienda australiana [2], e nel contesto delle lezioni applico [3].
Ricordo che esistono vari tipi di processi, è possibile informarsi, ad esempio, [4] e [5].
Per maggiori dettagli sugli approcci utilizzati nella modellazione e nella progettazione, consultare [6, 7].
La specifica completa di UML si trova in [8].
Ora siamo pronti a passare alle fasi successive e a cominciare la progettazione delle funzioni del sistema e della sua organizzazione interna. La numerazione delle illustrazioni proseguirà.
Fase 3. Ogni passo da automatizzare deve essere associato a una o più funzioni del sistema
Il sistema automatizzato in fase di sviluppo (AS) è destinato a mantenere un rigoroso controllo delle noci, ricordi? Per ogni passaggio selezionato (cfr. Figura 3, Figura 4 ), che intendiamo automatizzare, scriveremo un requisito funzionale, utilizzando un costrutto simile a «Il sistema deve implementare la possibilità di…» e svilupperemo un diagramma Use-case. Ora, di fatto, stiamo completando il nostro accordo di modellazione con nuove regole. Spiegherò quali elementi utilizzeremo.
Tra il «Ruolo dell'utente» e la «Funzione» utilizzeremo un collegamento di «Associazione» (Figura 5), il che significa che per l'utente con quel ruolo è possibile eseguire quella funzione.
Figura 5. Utilizzo della relazione di tipo «Associazione»
Dal «Funzione» al «Requisito» stabiliremo la relazione «Implementazione» (Figura 6) per mostrare che questo requisito sarà realizzato da queste funzioni; la relazione può essere anche «molti-a-molti», ovvero una funzione può partecipare alla realizzazione di più requisiti, mentre per realizzare un requisito possono essere necessarie più di una funzione.
Figura 6. Utilizzo della relazione di tipo «Implementazione»
Se una funzione richiede per la sua esecuzione che venga eseguita un'altra funzione, e questo è obbligatorio, utilizzeremo la relazione «Dipendenza» con lo stereotipo «Include» — inclusione (Figura 7). Se invece l'esecuzione di una funzione aggiuntiva è richiesta a determinate condizioni, utilizzeremo la relazione «Dipendenza» con lo stereotipo «Extend» — estensione. È molto facile da ricordare: «Include» — SEMPRE, e «Extend» – A VOLTE.
Figura 7. Utilizzo della relazione di tipo «Dipendenza (inclusione)»
In definitiva, il nostro diagramma apparirà così (Figura 8).
Figura 8. Diagramma Use-case (modello funzionale del sistema)
Inoltre, il diagramma Use-case è utilizzato per modellare i ruoli degli utenti (Figura 9).
Figura 9. Diagramma Use-case (ruoli degli utenti del sistema)
Fase 4. Descriviamo l'organizzazione interna del sistema automatizzato mediante un diagramma delle classi
Utilizzando le informazioni sugli artefatti di ingresso e uscita del nostro processo (vedi diagrammi Activity — Figura 2, Figura 3, Figura 4), svilupperemo un diagramma delle classi. Utilizzeremo elementi modellanti «Classe» e diversi tipi di relazioni tra di essi.
Per mostrare la relazione «parte-tutto» utilizzeremo la relazione di tipo «Aggregazione» (Figura 10): la noce è il tutto, mentre il guscio e il nocciolo sono le parti.
Figura 10. Relazione «parte-tutto»
In definitiva, il frammento del nostro diagramma apparirà così (Figura 11). I colori indicano le classi che abbiamo evidenziato direttamente nella descrizione testuale del processo.
Figura 11. Diagramma delle classi
Il diagramma delle classi è stato utilizzato anche per modellare altri artefatti, non solo quelli che saranno pertinenti al modello concettuale del processo automatizzato di contabilità delle risorse materiali, ma anche per quanto riguarda l'ambiente di esecuzione – il contesto (Figura 12) e i processi "adiacenti" (Figura 13), che possono influenzare il processo automatizzato, ma che al momento non sono al centro della nostra attenzione (supponiamo che il sistema si svilupperà e queste informazioni risulteranno utili).
Figura 12. Diagramma delle classi (contesto)
La relazione di ereditarietà mostra la generalizzazione di diverse strutture, le "classi figlie" sotto la "classe padre" generalizzante "Struttura".
Figura 13. Diagramma delle classi (informazioni aggiuntive sugli artefatti)
"La reazione alla situazione" dipende dai "Dati di controllo visivo". Per molte relazioni di dipendenza viene utilizzato lo stereotipo "trace" per mostrare la tracciatura delle classi non esplicitamente indicate nella descrizione del processo, ma necessarie per la sua automazione, verso le classi, su cui ci sono indicazioni precise nella nostra descrizione.
Fase 5. Analizziamo le annotazioni sulla pista 'Regole di business'
Sono state indicate come regole (vedi Figura 2 ):
- la necessità di suddividere uno dei passaggi in 2 parti, dove la seconda parte inizia ad essere eseguita solo in determinate condizioni;
- l'assegnazione della contabilità delle noci a un determinato funzionario;
- una tecnica tecnica (colore bianco degli elementi), che indica che l'elemento non è stato esplicitamente menzionato nella descrizione del processo.
Va notato che tutte queste regole sono state già utilizzate nello sviluppo dei diagrammi.
Osservazioni conclusive
Dunque, abbiamo attraversato 5 fasi e costruito 3 tipi di diagrammi. Aggiungerò un breve commento sull'organizzazione dei nostri modelli nell'ambiente di modellazione. Esistono molti framework che aiutano a strutturare i modelli sviluppati, ma questo non è l'oggetto di questo articolo, pertanto ci limiteremo al seguente semplice insieme di pacchetti per gestire il nostro progetto in modo ordinato: Processo aziendale, Modello funzionale, Artefatti, Partecipanti e Contesto (Figura 14).
Figura 14. Struttura dei pacchetti del progetto
In questo modo, abbiamo sviluppato modelli concordati che descrivono il sistema di contabilizzazione delle risorse materiali da diverse angolazioni: il modello di processo aziendale automatizzabile, il modello funzionale e il modello di organizzazione interna del sistema a livello concettuale.
Elenco delle fonti
- Sito "UML2.ru". Forum della Comunità degli Analisti. Sezione generale. Esempi. Esempi di favole presentate come diagrammi UML. [Risorsa elettronica] Modalità di accesso: Internet:
- Sito Sparx Systems. [Risorsa elettronica] Modalità di accesso: Internet:
- Sito Modelio. [Risorsa elettronica] Modalità di accesso: Internet:
- Grande Dizionario Enciclopedico. Processo (interpretazione). [Risorsa elettronica] Modalità di accesso: Internet:
- Sito «Organizzazione della gestione efficace». Blog. Categoria «Gestione dei processi aziendali». Definizione di processo aziendale. [Risorsa elettronica] Modalità di accesso: Internet:
- Certificato n. 18249 di registrazione e deposito di un'opera del risultato dell'attività intellettuale. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manoscritto di un sussidio didattico dal titolo «Modellazione dell'area tematica utilizzando Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellazione dei processi aziendali. — Mosca: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- Specifica del Linguaggio di Modellazione Unificato (OMG UML). Versione 2.5.1. [Risorsa elettronica] Modalità di accesso: Internet:
Fonte: habr.com
