«Un giorno nella vita di uno scoiattolo» o dalla modellazione dei processi alla progettazione di un sistema automatizzato per la contabilizzazione dei beni materiali «Scoiattolo-1.0» (Parte 1)
Cosa c'entra lo «scoiattolo»?
Facciamo un po' di chiarezza su cosa c'entra lo «scoiattolo». Navigando in Rete sono incappata in divertenti progetti per studiare UML basati su aree tematiche tratte da favole (ad esempio, [1]), ho deciso di preparare un esempio simile per i miei studenti, affinché potessero iniziare a studiare tre tipi di diagrammi: Diagramma di attività, Diagramma dei casi d'uso e Diagramma delle classi. Non traduco deliberatamente in russo i nomi dei diagrammi, per evitare discussioni sulle «difficoltà di traduzione». Spiegherò un po' più tardi a cosa servono. In questo esempio utilizzo l'ambiente Enterprise Architect dell'azienda australiana [2] – un buon strumento a un prezzo ragionevole. E nel contesto delle lezioni utilizzo [3], un buon strumento gratuito di progettazione orientata agli oggetti, che supporta gli standard UML2.0 e BPMN, senza eccessivi fronzoli in termini di capacità grafiche, ma adeguato per imparare le basi del linguaggio.
Intendiamo automatizzare l'attività di contabilizzazione 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 favola del re Saltan, del suo glorioso e potente eroe principe Guidone Saltanovich e della bella principessa Cigno", — 10 anni dall'idea alla pubblicazione, tra l'altro!)
Un po' sui codici che sono scritti a destra delle righe. “A” (da “Attore”) significa che nella riga è contenuta un'informazione su un partecipante al processo. “C” (da “Classe”) – informazione sugli oggetti delle classi che vengono elaborati durante l'esecuzione dei processi. “E” (da “Ambiente”) – informazione sugli oggetti delle classi che caratterizzano l'ambiente di esecuzione dei processi. “P” (da “Processo”) – informazione sui processi stessi.
A proposito, la definizione esatta di processo rivendica anche di essere motivo di dibattiti metodologici, almeno a causa del fatto che i processi possono essere diversi: aziendali, produttivi, tecnologici e così via. (si può consultare, ad esempio, [4] e [5]). Per evitare polemiche, concordiamo che il processo ci interessa dal punto di vista della sua ripetibilità nel tempo e della necessità di automazione, ossia il trasferimento dell'esecuzione di alcune operazioni del processo a un sistema automatizzato.
Note sull'uso del diagramma di Attività
Iniziamo a modellare il nostro processo e utilizziamo per questo il diagramma di Attività. Per prima cosa spiegherò come i codici menzionati sopra verranno utilizzati nel modello. È più facile spiegare con un esempio grafico, e nel contempo analizzeremo alcuni (quasi tutti gli elementi necessari) del diagramma di Attività.
Analizziamo il seguente frammento:
…
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)
…
Abbiamo due passaggi del processo P1 e P2, il partecipante A1 e oggetti di tre classi diverse: un oggetto della classe C1 entra nel passaggio, mentre gli oggetti delle classi C2 e C3 vengono prodotti in uscita come risultato dell'operazione di questo passaggio P2 del nostro processo. Per il diagramma utilizzeremo i seguenti elementi di modellazione.
Il frammento del nostro processo può essere rappresentato circa così (Figura 1).
Figura 1. Frammento del diagramma di Attività
Per organizzare lo spazio e strutturare il diagramma di Attività, adotteremo un approccio non del tutto standard, dal punto di vista dell'uso classico della notazione UML. Ma ci sono alcune ragioni per questo. Prima di tutto, semplicemente prima di iniziare la modellazione, prepareremo il cosiddetto accordo sulla modellazione, in cui registreremo tutte le peculiarità dell'uso della notazione. In secondo luogo, questo approccio è stato applicato con successo più volte nella fase di modellazione aziendale in progetti reali di creazione di sistemi software, i risultati sono stati registrati dal nostro piccolo gruppo di autori nel corrispondente oggetto di diritto d'autore [6], e sono stati anche utilizzati in un manuale [7]. Per il diagramma delle Attività, definiremo che il campo del diagramma è strutturato attraverso ‘corsie di nuoto’ – Swim lanes. Il nome della corsia corrisponderà al tipo di elementi del diagramma che saranno collocati in quella corsia.
«Artefatti di ingresso e uscita»: in questa corsia saranno posizionati gli elementi Objects – oggetti utilizzati o risultati dell'esecuzione di un certo passo del processo.
«Passi del processo»: qui collocheremo gli elementi Activity – azioni dei partecipanti al processo.
«Partecipanti»: corsia per gli elementi che designano i ruoli degli esecutori delle azioni nel nostro processo, per cui utilizzeremo lo stesso elemento di modellazione Object – oggetto, ma aggiungeremo il suo stereotipo «Actor».
La corsia successiva si chiama «Regole aziendali» e in questa corsia collocheremo in forma testuale le regole per l'esecuzione dei passi del processo, utilizzando per questo l'elemento di modellazione Note – nota.
Qui ci fermeremo, anche se potremmo ulteriormente utilizzare la corsia «Strumenti» per raccogliere informazioni sul livello di automazione del processo. Potrebbe anche tornare utile la corsia «Posizioni e dipartimenti dei partecipanti», che può essere utilizzata per collegare i ruoli con le posizioni e i dipartimenti dei partecipanti al processo.
Tutto ciò che ho appena descritto è un frammento dell'accordo di modellazione, questa parte dell'accordo si riferisce alle regole di organizzazione di un diagramma e, di conseguenza, alle regole per la sua scrittura e lettura.
«Ricetta»
Ora consideriamo un'opzione di modellazione del sistema in base alla diagramma delle Attività. Questa è solo una delle opzioni; sottolineo che non è certamente l'unica. Il diagramma di Activity ci interesserà dal punto di vista del suo ruolo nel passaggio dalla modellazione del processo alla progettazione di un sistema automatizzato. A tale scopo ci atteniamo alle raccomandazioni metodologiche - una sorta di ricetta, composta da soli cinque fasi e che prevede lo sviluppo di tre tipi di diagrammi. L'applicazione di questa ricetta aiuterà a ottenere una descrizione formalizzata del processo che desideriamo automatizzare e a raccogliere dati per la progettazione del sistema. E per gli studenti all'inizio dello studio dell'UML, è una sorta di salvagente che non permette di affogare nella varietà di mezzi espressivi e tecniche disponibili nell'UML e nei moderni strumenti di modellazione.
Ecco, di fatto, la ricetta stessa, e dopo seguono i diagrammi costruiti per il nostro ambito 'favolistico'.
Fase 1. Descriviamo il processo in forma di diagramma di Activity. Per un processo che ha più di 10 passi, ha senso applicare il principio della decomposizione dei passi del processo, per migliorarne la leggibilità del diagramma.
Fase 2. Identifichiamo ciò che può essere automatizzato (i passi possono essere, ad esempio, evidenziati nel diagramma).
Fase 3. Ogni passo da automatizzare deve essere associato a una o più funzioni del sistema (la relazione può essere molti a molti), disegniamo il diagramma dei Caso d'uso. Queste sono le funzioni del nostro sistema.
Fase 4. Descriviamo l'organizzazione interna del sistema automatizzato mediante un diagramma delle classi – Class. La pista 'Oggetti in ingresso e in uscita (documenti)' nel diagramma di Activity è la base per costruire il modello ad oggetti e il modello entità-relazione.
Fase 5. Analizziamo le annotazioni sulla pista 'Regole di business', esse forniscono vari tipi di vincoli e condizioni, che si trasformano progressivamente in requisiti non funzionali.
L'insieme risultante di diagrammi (Activity, Use-case, Class) ci fornisce una descrizione formalizzata in una notazione sufficientemente rigorosa, cioè ha una lettura univoca. Ora possiamo sviluppare un capitolato tecnico, chiarire la specifica dei requisiti, ecc.
Iniziamo a modellare.
Fase 1. Descriviamo il processo in forma di diagramma di Activity
Ricordo che il campo del diagramma è stato strutturato utilizzando percorsi "fluttuanti", su ogni percorso si trovano elementi dello stesso tipo (Figura 2). Oltre agli elementi sopra descritti, utilizzeremo elementi aggiuntivi, descriviamoli.
La Decisione (Decision) sulla diagramma indica un punto di diramazione del nostro processo, mentre la fusione dei flussi (Merge) rappresenta il punto di ripristino. Nelle parentesi quadre sui transiti sono indicate le condizioni di passaggio.
Tra due sincronizzatori (Fork) mostreremo i rami paralleli del processo.
Il nostro processo può avere solo un inizio - un punto di ingresso (Initial). Tuttavia, ci possono essere più conclusioni (Final), ma non per il nostro diagramma specifico.
Ci sono molti flussi; con un numero elevato di elementi e collegamenti, possiamo prima evidenziare le fasi del processo e poi decomporre queste fasi. Ma vorrei mostrare il nostro processo "fiabesco" in modo chiaro su un solo diagramma, e ovviamente bisogna cercare di evitare che i flussi "si incollino", in modo da poter seguire con precisione cosa è collegato a cosa.
Figura 2. Diagramma dell'Attività - visione generale del processo
Poiché in alcune righe poetiche alcuni dettagli del processo sono stati omessi, è stato necessario ripristinarli; sono mostrati con elementi su sfondo bianco. Questi dettagli includono il passaggio "Trasferimento/ricezione per stoccaggio e lavorazione" e diversi artefatti di ingresso e uscita. È importante notare che questo passaggio non rivela completamente il processo, poiché sarebbe necessario distinguere separatamente il passaggio di trasferimento e il passaggio di ricezione, e per i gusci aggiungere un passaggio separato, e inoltre ipotizzare che tutte queste risorse materiali debbano essere temporaneamente immagazzinate, ecc.
Notiamo anche che resta ancora senza risposta la questione dell'origine delle noci: da dove provengono e come arrivano allo scoiattolo? E questa domanda (è evidenziata in rosso nel commento - elemento Note) richiede un'elaborazione separata! Così lavora l'analista: raccogliendo informazioni a piccole dosi, formulando ipotesi e ottenendo "ok" o "non-ok" dagli esperti del settore - persone molto importanti e semplicemente insostituibili nella fase di modellazione aziendale durante la creazione di sistemi.
Si osservi anche che il passaggio del processo P5 è composto da due parti.
E ogni parte la decomposta e la esamineremo più in dettaglio (Figura 3, Figura 4), poiché l'attività svolta nell'ambito di questi passaggi sarà automatizzata.
Figura 3. Diagramma di Attività – dettaglio (parte1)
Figura 4. Diagramma di Attività – dettaglio (parte2)
Fase 2. Identifichiamo ciò che può essere automatizzato
I passaggi da automatizzare nei diagrammi sono evidenziati a colori (vedi Figura 3, Figura 4).
Tutti vengono eseguiti da un partecipante al processo – Diacono incaricato:
- Inserisce le informazioni sul peso della noce nel registro;
- Inserisce le informazioni sul trasferimento della noce nel registro;
- Fissa il fatto della trasformazione della noce in gusci e nocciolo;
- Inserisce le informazioni sul nocciolo della noce nel registro;
- Inserisce le informazioni sui gusci della noce nel registro.
Analisi del lavoro svolto. E ora?
Quindi, abbiamo svolto un grande lavoro preparativo: abbiamo raccolto informazioni sul processo che intendiamo automatizzare; abbiamo iniziato a formare un accordo sulla modellazione (per ora solo in merito all'uso del diagramma di Attività); abbiamo effettuato la modellazione del processo e persino una decomposizione di alcuni dei suoi passaggi; abbiamo evidenziato i passaggi del processo che automatizzeremo. Ora siamo pronti a passare alle fasi successive e a iniziare la progettazione delle funzioni del sistema e della sua organizzazione interna.
Come è risaputo, la teoria senza pratica è nulla. È necessario provare assolutamente la "modellazione" con le proprie mani, è utile anche per comprendere l'approccio proposto. Ad esempio, si può lavorare nell'ambiente di modellazione [3]. Abbiamo decomposto solo parte dei passaggi del diagramma generale del processo (vedi Figura 2). Come compito pratico può essere proposto di ripetere tutti i diagrammi nell'ambiente Modelio e di effettuare la decomposizione del passaggio "Trasferimento/ricezione per stoccaggio e lavorazione".
Il lavoro in ambienti di modellazione specifici non è ancora considerato, ma questo potrebbe diventare oggetto di articoli e rassegne autonome.
Nella seconda parte dell'articolo analizzeremo le tecniche di modellazione e progettazione necessarie nelle fasi 3-5, utilizzeremo i diagrammi UML Use-case e Class. Continuerà.
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.
Fonte: habr.com
