«Un giorno nella vita di uno scoiattolo» o da modellazione dei processi alla progettazione di un sistema automatizzato di contabilità delle risorse materiali «Scoiattolo-1.0» (Parte 1)
Cosa c'entra lo «scoiattolo»?
Spiego subito cosa c'entra lo «scoiattolo». Navigando in rete ho trovato progetti divertenti per studiare UML, ispirati a temi tratti da favole (ad esempio, [1]), ho deciso di preparare un esempio simile anche per i miei studenti, per studiare inizialmente tre tipi di diagrammi: Diagramma delle Attività, Diagramma dei Casi d'Uso e Diagramma delle Classi. Ho intenzionalmente mantenuto i nomi dei diagrammi in inglese, per evitare discussioni sulle «difficoltà di traduzione». Spiegherò un po' più avanti cosa serve a cosa. In questo esempio utilizzo l'ambiente Enterprise Architect dell'azienda australiana [2] – uno strumento valido a un prezzo ragionevole. E nel contesto delle lezioni utilizzo [3], un buon strumento gratuito per la progettazione orientata agli oggetti, che supporta gli standard UML2.0 e BPMN, senza eccessivi fronzoli nelle capacità grafiche, ma del tutto sufficiente per studiare le basi del linguaggio.
Vogliamo automatizzare l'attività di contabilità delle risorse materiali, che si svolge in questi processi.
…
Un'isola si trova in mare, (E1, E2)
Una città si erge sull'isola (E3, E1)
Con chiese d'oro, (E4)
Con dimore e giardini; (E5, E6)
Un abete cresce davanti al palazzo, (E7, E8)
E sotto di essa una casa di cristallo; (E9)
Lì vive uno scoiattolo domestico, (A1)
E che burlone! (A1)
Lo scoiattolo canta canzoni, (P1, A1)
E continua a sgranocchiare noci, (P2)
Ma le noci non sono semplici, (C1)
Tutte le bucce sono d'oro, (C2)
I semi sono di puro smeraldo; (C3)
I servi vegliano sullo scoiattolo, (P3, A2)
Fanno da servitori in vari modi (P4)
E un ufficiale è assegnato (A3)
A mettere in conto le noci; (P5, C1)
Rendono onore allo scoiattolo; (P6, A4)
Dalla buccia si ricava moneta, (P7, C2, C4)
E si lascia circolare nel mondo; (P8)
Le ragazze spargono smeraldi (P9, A5, C3)
Nei magazzini e sotto il riparo; (E10, E11)
…
(A.S. Pushkin "La fiaba del re Saltan, del suo figlio glorioso e potente eroe principe Gvidone Saltanovich e della bella principessa cigno", — 10 anni dal progetto alla pubblicazione, tra l'altro!)
Un po' sui codici che sono scritti a destra delle righe. “A” (da “Attore”) indica che nella riga è contenuta 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 pretende anche di diventare motivo di controversie metodologiche, almeno a causa del fatto che i processi variano: aziendali, produttivi, tecnologici e così via (è possibile approfondire, ad esempio, [4] e [5]). Per evitare polemiche, concordiamo sul fatto che il processo ci interessa in relazione alla sua ripetibilità nel tempo e alla necessità di automazione, ovvero di trasferire l'esecuzione di alcune operazioni del processo a un sistema automatizzato.
Note sull'uso del diagramma delle Attività
Iniziamo a modellare il nostro processo e useremo a tal fine il diagramma delle Attività. Per cominciare, spiegherò come i codici sopra menzionati verranno utilizzati nel modello. È più facile spiegare con un esempio grafico, e nel contempo esamineremo alcuni (quasi tutti quelli di cui abbiamo bisogno) elementi del diagramma delle Attività.
Analizziamo il seguente frammento:
…
Lo scoiattolo canta canzoni, (P1, A1)
E continua a sgranocchiare noci, (P2)
Ma le noci non sono semplici, (C1)
Tutte le bucce sono d'oro, (C2)
I semi sono di puro smeraldo; (C3)
…
Abbiamo due fasi del processo P1 e P2, il partecipante A1 e gli oggetti di tre classi diverse: un oggetto della classe C1 entra nella fase, gli oggetti delle classi C2 e C3 escono, come risultato dell'attività di questa fase P2 del nostro processo. Per il diagramma utilizziamo i seguenti elementi di modellazione.
Il frammento del nostro processo può essere rappresentato più o meno così (Figura 1).
Figura 1. Frammento del diagramma delle Attività
Per organizzare lo spazio e strutturare il diagramma delle Attività, adotteremo un approccio non del tutto standard, rispetto all'uso classico della notazione UML. Ma ci sono diverse ragioni per questo. In primo luogo, semplicemente prima di iniziare la modellazione, redigeremo ciò che si chiama accordo sulla modellazione, nel quale registreremo tutte le peculiarità dell'uso della notazione. In secondo luogo, questo approccio è stato ripetutamente applicato con successo nella fase di modellazione aziendale in progetti reali di creazione di sistemi software, i risultati sono stati registrati dal nostro piccolo gruppo autorevole nell'oggetto corrispondente di diritto d'autore [6], e sono stati utilizzati anche in un manuale [7]. Per il diagramma delle Attività, definiamo che il campo del diagramma viene strutturato utilizzando “corsie” – Swim lanes. Il nome della corsia corrisponderà al tipo di elementi del diagramma che verranno posizionati su quella corsia.
«Artefatti in entrata e in uscita»: su questa corsia saranno collocati elementi Oggetti – oggetti utilizzati o risultati dall'esecuzione di un certo passo del processo.
«Passi del processo»: qui posizioneremo elementi Attività – azioni dei partecipanti al processo.
«Partecipanti»: una pista per gli elementi che rappresenteranno i ruoli degli attori nel nostro processo; per questo utilizzeremo lo stesso elemento modellante Object – oggetto, ma aggiungeremo lo stereotipo «Actor».
La pista successiva si chiama «Regole di business» e su questa pista inseriremo in forma di testo le regole per l'esecuzione dei passi del processo, utilizzando per questo l'elemento modellante Note – nota.
Ci fermeremo qui, anche se si potrebbe ulteriormente utilizzare la pista «Strumenti» per raccogliere informazioni sul livello di automazione del processo. Potrebbe anche tornare utile la pista «Posizioni e reparti dei partecipanti», che può essere utilizzata per collegare i ruoli con le posizioni e i reparti dei partecipanti al processo.
Tutto ciò che ho appena descritto è un frammento dell'accordo di modellazione, questa parte dell'accordo riguarda le regole per l'organizzazione di un diagramma e, di conseguenza, le regole della sua scrittura e lettura.
«Ricetta»
Ora consideriamo un'opzione di modellazione del sistema a partire dal diagramma di Activity. Questo è soltanto un'opzione; 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. Per questo seguiremo delle 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 che iniziano a studiare UML, è una sorta di giubbotto di salvataggio, che non permetterà di affondare nella varietà di strumenti e tecniche che esistono in UML e nei moderni strumenti di modellazione.
Ecco, in sostanza, la ricetta, e oltre seguono i diagrammi costruiti per la nostra area tematica «favolosa».
Fase 1. Descriviamo il processo sotto forma di diagramma di Activity. Per un processo che prevede più di 10 passi, ha senso applicare il principio di decomposizione dei passi del processo, per migliorare la leggibilità del diagramma.
Fase 2. Identifichiamo ciò che può essere automatizzato (i passi possono essere per esempio evidenziati nel diagramma).
Fase 3. Allo step da automatizzare deve corrispondere una o più funzioni del sistema (la relazione può essere molti-a-molti), tracciamo un diagramma Use-case. Queste sono le funzioni del nostro sistema.
Fase 4. Descriveremo l'organizzazione interna dell'AS con un diagramma delle classi – Class. La pista nuotante «Oggetti in entrata 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 note sul percorso «Regole business», forniscono vari vincoli e condizioni, trasformandosi gradualmente in requisiti non funzionali.
La collezione di diagrammi ottenuta (Activity, Use-case, Class) ci fornisce una descrizione formalizzata in una notazione sufficientemente rigorosa, cioè ha un'interpretazione univoca. Ora possiamo sviluppare un capitolato tecnico, chiarire le specifiche dei requisiti, ecc.
Iniziamo a modellare.
Fase 1. Descriviamo il processo sotto forma di diagramma di Activity
Ricordo che abbiamo strutturato il campo del diagramma utilizzando le «piste» nuotanti; su ciascuna pista si trovano elementi dello stesso tipo (Figura 2). Oltre agli elementi descritti sopra, utilizzeremo ulteriori elementi; descriviamoli.
La Decisione (Decision) indica nel diagramma un punto di diramazione del nostro processo, mentre la fusione dei flussi (Merge) è il punto di riunione. Nelle parentesi quadre sui passaggi sono indicate le condizioni di transizione.
Tra due sincronizzatori (Fork) mostreremo i rami paralleli del processo.
Il nostro processo può avere solo un inizio – un punto di ingresso (Initial). Ma le conclusioni (Final) possono essere anche più di una, sebbene non per il nostro specifico diagramma.
Ci sono molte frecce; con un grande numero di elementi e relazioni, si può iniziare a evidenziare inizialmente le fasi del processo, e poi decomporre queste fasi. Tuttavia, mi piacerebbe mostrare il nostro processo «favoloso» completamente su un unico diagramma; bisogna, ovviamente, cercare di evitare che le frecce «si incollino», in modo da poter seguire con precisione quali sono collegati.
Figura 2. Diagramma di Activity – vista complessiva del processo
Poiché in alcune strofe poetiche alcuni dettagli del processo sono stati omessi, è stato necessario ripristinarli, mostrati come elementi con uno sfondo bianco. Questi dettagli includono il passo 'Trasferimento/ricezione per stoccaggio e lavorazione' e diversi artefatti in ingresso e in uscita. Vale la pena notare che questo passo non svela completamente il processo, poiché sarebbe necessario distinguere separatamente il passo di trasferimento e il passo di ricezione, e ancora aggiungere un passo separato per i gusci, oltre a immaginare che inizialmente tutte queste risorse materiali debbano essere stoccate temporaneamente, e così via.
Notiamo inoltre che rimane ancora senza risposta la questione dell'origine delle noci – da dove provengono e come arrivano allo scoiattolo? Questa domanda (evidenziata in rosso nel commento – elemento Note) richiede un'ulteriore analisi! È così che lavora un analista – raccogliendo informazioni pezzo per pezzo, formulando ipotesi e ottenendo un 'ok' o 'non-ok' da esperti del settore – persone molto importanti e semplicemente indispensabili nella fase di modellazione aziendale nella creazione di sistemi.
Prestiamo attenzione anche al fatto che il passo del processo P5 è composto da due parti.
E ogni parte viene decomposta e esaminata più nel dettaglio (Figura 3, Figura 4), poiché l'attività svolta all'interno di questi specifici passi sarà automatizzata.
Figura 3. Diagramma Activity – dettaglio (parte 1)
Figura 4. Diagramma Activity – dettaglio (parte 2)
Fase 2. Identifichiamo ciò che può essere automatizzato
I passi soggetti ad automazione nei diagrammi sono evidenziati a colori (vedi Figura 3, Figura 4).
Tutti questi compiti sono eseguiti da un singolo partecipante al processo – Diacono ordinario:
- Inserisce le informazioni sul peso della noce nel registro;
- Inserisce le informazioni sul trasferimento della noce nel registro;
- Registra il fatto che la noce è stata trasformata in gusci e nucleo;
- Inserisce le informazioni sul nucleo della noce nel registro;
- Inserisce le informazioni sui gusci della noce nel registro.
Analisi del lavoro svolto. E adesso?
Quindi, abbiamo svolto un grande lavoro preparatorio: abbiamo raccolto informazioni sul processo che intendiamo automatizzare; abbiamo iniziato a formare un accordo sulla modellazione (fino ad ora solo per quanto riguarda l'uso del diagramma Activity); abbiamo modellato il processo e persino effettuato la decomposizione di alcuni dei suoi passi; abbiamo identificato i passi del processo che automatizzeremo. Ora siamo pronti per passare alle fasi successive e iniziare a progettare le funzioni del sistema e la sua organizzazione interna.
Come è noto, la teoria senza la pratica è nulla. È fondamentale provare a 'modellare' con le proprie mani, è utile per comprendere l'approccio proposto. Ad esempio, è possibile lavorare nell'ambiente di modellazione [3]. Abbiamo decomposto solo una parte dei passi del diagramma generale del processo (vedi Figura 2). Come esercizio pratico può essere proposto di ripetere tutti i diagrammi nell'ambiente Modelio e di effettuare la decomposizione del passo 'Trasferimento/ricezione per stoccaggio e lavorazione'. [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 eseguire la decomposizione del passaggio «Trasferimento/ricezione per stoccaggio e lavorazione».
Il lavoro in specifici ambienti di modellazione non viene al momento considerato, ma potrebbe diventare oggetto di articoli e recensioni autonomi.
Nella seconda parte dell'articolo esamineremo le tecniche di modellazione e progettazione necessarie nei passaggi 3-5, useremo i diagrammi UML Use-case e Class. Continuazione segue.
Elenco delle fonti
- Sito «UML2.ru». Forum della Comunità degli Analisti. Sezione Generale. Esempi. Esempi di fiabe presentate sotto forma di 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 Enciclopedia Illustrata. Processo (interpretazione). [Risorsa elettronica] Modalità di accesso: Internet:
- Sito «Organizzazione di una gestione efficace». Blog. Sezione «Gestione dei processi aziendali». Definizione di processo aziendale. [Risorsa elettronica] Modalità di accesso: Internet:
- Certificato n. 18249 di registrazione e deposito del risultato dell'attività intellettuale. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manoscritto del materiale didattico intitolato «Modellazione della materia con Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modellazione dei processi aziendali. — M.: KURS, NII INFRA-M, EBS Znanium.com. — 2017.
Fonte: habr.com
