“Un giorno nella vita di uno scoiattolo” o dalla modellazione dei processi alla progettazione di un sistema di contabilità patrimoniale automatizzato “Belka-1.0” (Parte 2)
Riassunto dell'episodio precedente
В Abbiamo utilizzato un dominio “fiabesco”, ispirato da esempi di apprendimento di diagrammi UML basati su trame fiabesche (vedi, ad esempio, [1]). Prima dell'inizio della modellazione, abbiamo concordato l'utilizzo di alcuni elementi del diagramma di attività e abbiamo iniziato a stipulare un accordo di 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 le fasi del processo per le quali è richiesta (e possibile) l'automazione.
Permettetemi di ricordarvi che automatizzeremo l'attività di contabilità dei beni materiali, che nasce in questi processi.
...
Un'isola si trova sul mare, (E1, E2)
C'è grandine sull'isola (E3, E1)
Con chiese dalle cupole dorate, (E4)
Con torri e giardini; (E5, E6)
Davanti al palazzo cresce un abete rosso (E7, E8)
E sotto c'è una casa di cristallo; (E9)
Lì vive uno scoiattolo addomesticato, (A1)
Sì, che avventura! (A1)
Lo scoiattolo canta canzoni, (P1, A1)
Sì, continua a sgranocchiare noci, (P2)
Ma le noci non sono semplici, (C1)
Tutte le conchiglie sono dorate, (C2)
Il nucleo è puro smeraldo; (C3)
I servitori sorvegliano lo scoiattolo, (P3, A2)
La servono come servi vari (P4)
E fu assegnato un impiegato (A3)
La novità è un resoconto rigoroso delle noci; (P5, C1)
L'esercito la saluta; (P6, A4)
Dalle conchiglie viene versata una moneta (P7, C2, C4)
Lasciali andare in giro per il mondo; (P8)
Ragazze versano smeraldi (P9, A5, C3)
Nei magazzini e al coperto; (E10, E11)
...
(A.S. Pushkin “La storia dello zar Saltan, del suo glorioso e potente eroe, il principe Guidon Saltanovich e della bellissima principessa Swan”, )
In questo esempio sto utilizzando il framework Enterprise Architect di un'azienda australiana [2] e durante le sessioni di allenamento che utilizzo [3].
Lascia che ti ricordi che esistono diversi processi, puoi conoscere, ad esempio, [4] i [5].
Per maggiori dettagli sugli approcci applicati alla modellazione e alla progettazione, vedere [6, 7].
Per la specifica UML completa, vedere [8].
Siamo ora pronti per passare ai passi successivi e iniziare a progettare la funzionalità e l'organizzazione interna del sistema. La numerazione dei disegni continuerà.
Fase 3. Il passaggio automatizzato deve essere associato ad una o più funzioni del sistema
Il sistema automatizzato (AS) in fase di sviluppo è progettato per mantenere registri rigorosi delle noci, ricordate? Per ogni passaggio evidenziato (vedere Figura 3, Figura 4 ), che automatizzeremo, scriveremo un requisito funzionale utilizzando approssimativamente la seguente costruzione: "Il sistema deve implementare l'abilità..." e sviluppare un diagramma del caso d'uso. Ora stiamo effettivamente aggiungendo nuove regole al nostro accordo di modello. Lasciami spiegare quali elementi utilizzeremo.
Utilizzeremo la connessione “Associazione” tra il “Ruolo Utente” e la “Funzione” (Figura 5), questo significa che un utente con questo ruolo può svolgere questa funzione.
Figura 5. Utilizzo di una relazione di tipo Associazione
Da “Funzione” a “Requisito” tracceremo la connessione “Implementazione” (Figura 6) per mostrare che questo requisito sarà implementato da queste funzioni; la relazione può essere “molti-a-molti”, ovvero Una funzione può essere coinvolta nell’implementazione di diversi requisiti e può essere necessaria più di una funzione per implementare un requisito.
Figura 6. Utilizzo della relazione di tipo “Implementazione”.
Se una funzione richiede per la sua esecuzione che venga eseguita qualche altra funzione, e necessariamente, utilizzeremo la connessione “Dipendenza” con lo stereotipo “Includi” (Figura 7). Se in determinate condizioni è richiesta l'esecuzione di una funzione aggiuntiva, utilizzeremo la connessione "Dipendenza" con lo stereotipo "Estendi". Tutto è molto facile da ricordare: "Includi" è SEMPRE e "Estendi" è A VOLTE.
Figura 7. Utilizzo della relazione “Dipendenza (inclusione)”.
Di conseguenza, il nostro diagramma sarà simile a questo (Figura 8).
Figura 8. Diagramma dei casi d'uso (modello funzionale di AC)
Inoltre, viene utilizzato un diagramma dei casi d'uso per modellare i ruoli utente (Figura 9).
Figura 9. Diagramma dei casi d'uso (ruoli degli utenti AS)
Fase 4. Descriviamo l'organizzazione interna dell'AS utilizzando un diagramma di classe
Utilizzando le informazioni sugli artefatti di input e output del nostro processo (vedi Diagrammi di attività - Figura 2, Figura 3, Figura 4), svilupperemo un diagramma di classi. Utilizzeremo gli elementi di modellazione “Classe” e vari tipi di connessioni tra di loro.
Per mostrare la relazione “intero-parte”, utilizzeremo una relazione di tipo “Aggregazione” (Figura 10): la noce è l'intero, mentre i gusci e il gheriglio sono le parti.
Figura 10. Relazione intero-parte
Di conseguenza, un frammento del nostro diagramma sarà simile a questo (Figura 11). Le classi che abbiamo evidenziato direttamente nella descrizione testuale del processo sono contrassegnate a colori.
Figura 11. Diagramma delle classi
Il diagramma delle classi è stato utilizzato anche per modellare altri artefatti - non solo quelli che saranno correlati al modello concettuale del processo automatizzato di contabilità delle risorse materiali, ma anche relativi all'ambiente di esecuzione - l'ambiente (Figura 12) e "vicino" processi (Figura 13) che possono influenzare il processo automatizzato, ma non sono ancora al centro della nostra attenzione (supponiamo che il sistema si svilupperà e queste informazioni saranno utili).
Figura 12. Diagramma delle classi (ambiente)
La relazione di ereditarietà mostra la generalizzazione di vari edifici, classi “figlie”, sotto la classe “genitore” generalizzante “Edificio”.
Figura 13. Diagramma delle classi (informazioni aggiuntive sugli artefatti)
La “reazione alla situazione” dipende dai “dati di controllo visivo”. Per diverse relazioni di dipendenza, lo stereotipo "traccia" viene utilizzato per mostrare la tracciabilità di classi non esplicitamente identificate nella descrizione del processo, ma necessarie per automatizzarlo, verso classi le cui istanze sono esplicitamente indicate nella nostra descrizione.
Fase 5. Analizziamo le note sul percorso “Business Rules”.
Le regole sono state specificate (vedi Figura 2 ):
- la necessità di dividere uno dei passaggi in 2 parti, la seconda parte inizia ad essere eseguita solo a determinate condizioni;
- nomina di un determinato funzionario per effettuare la contabilità delle noci;
- una tecnica (colore bianco degli elementi) che indica che l'elemento non è stato esplicitamente specificato nella descrizione del processo.
Va notato che abbiamo già utilizzato tutte queste regole durante lo sviluppo dei diagrammi.
Osservazioni finali
Quindi, abbiamo attraversato 5 fasi e creato 3 tipi di diagrammi. Aggiungerò un piccolo commento sull'organizzazione dei nostri modelli nell'ambiente di modellazione. Esistono numerosi framework che aiutano a strutturare i modelli in via di sviluppo, ma questo non è l'oggetto di questo articolo, quindi ci limiteremo al seguente semplice insieme di pacchetti per la gestione ordinata del nostro progetto: Business Process, Modello Funzionale , Artefatti, Partecipanti e Ambiente (Figura 14).
Figura 14. Struttura del pacchetto di progetti
Pertanto, abbiamo sviluppato modelli coerenti che descrivono il sistema contabile materiale da vari aspetti: un modello di un processo aziendale automatizzato, un modello funzionale e un modello dell'organizzazione interna del sistema a livello concettuale.
Elenco delle fonti
- Sito web "UML2.ru". Forum della comunità di analisti. Sezione generale. Esempi. Esempi di fiabe formattate come diagrammi UML. [Risorsa elettronica] Modalità di accesso: Internet:
- Sito web dei sistemi Sparx. [Risorsa elettronica] Modalità di accesso: Internet:
- Sito web Modelio. [Risorsa elettronica] Modalità di accesso: Internet:
- Grande dizionario enciclopedico. Processo (interpretazione). [Risorsa elettronica] Modalità di accesso: Internet:
- Sito web "Organizzazione della gestione efficace". Blog. Categoria "Gestione dei processi aziendali". Definizione di un processo aziendale. [Risorsa elettronica] Modalità di accesso: Internet:
- Certificato n. 18249 sulla registrazione e deposito di un'opera di attività intellettuale. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manoscritto di un sussidio didattico dal titolo “Modellare un'area disciplinare utilizzando Enterprise Architect” // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellazione dei processi aziendali. — M.: CORSO, SIC INFRA-M, EBS Znanium.com. — 2017.
- Specifiche OMG Unified Modeling Language (OMG UML). Versione 2.5.1. [Risorsa elettronica] Modalità di accesso: Internet:
Fonte: habr.com