Parnas 'Paper on Modularization and Workflow Engines

Question

Parnas 'Paper on Modularization and Workflow Engines

#1 da (3 voti)

1

In una classe di ingegneria del software, abbiamo avuto l'incarico di leggere il documento seminale di Parnas sulla modularizzazione [0]. In questo articolo vengono discussi due approcci di divisione di un software in moduli:

Approccio tradizionale: viene disegnato un diagramma di flusso per elaborare le singole fasi di elaborazione e il flusso di alto livello del programma. Quindi ogni passaggio di elaborazione viene trasformato in un modulo. Questo approccio non produce ottimi risultati.
Nuovo approccio: ogni decisione progettuale verrà trasformata in un modulo mediante l'occultamento delle informazioni. Questo approccio porta a risultati molto migliori.

La mia interpretazione personale del termine decisione progettuale è che i moduli sono identificati come strutture dati piuttosto che come fasi di elaborazione di un algoritmo . Questo ha senso, perché le strutture dati sono molto più adatte per nascondere le informazioni e quindi elaborare i passaggi di un algoritmo. (Le informazioni all'interno di una struttura dati sono nascoste dietro le funzioni, mentre una funzione nasconde solo passaggi di elaborazione più dettagliati e nessuna informazione, le informazioni vengono effettivamente passate come argomenti.)

Perché il secondo approccio funziona molto meglio del primo approccio? Ecco la mia seconda interpretazione: le singole fasi di elaborazione di un algoritmo non sono sostituibili (e quindi non riutilizzabili), mentre è possibile convertire strutture di dati in altre strutture di dati.

Ed ecco la mia domanda: potrebbe essere questa la ragione per cui lo sviluppo di software che utilizzava motori di workflow (basati su BPMN, ad esempio) non è mai decollato?

La mia esperienza personale è che le attività create in questi flussi di lavoro non sono quasi mai riutilizzate, ma spesso le grandi strutture di dati passano attorno a tutte le attività coinvolte, anche se la maggior parte delle attività utilizza solo uno o due di esse.

La mia domanda è esagerata: potremmo sbarazzarci di tutti quei goffi motori del flusso di lavoro dando ai manager la carta di Parnas da leggere?

[0]: sui criteri da utilizzare nei sistemi in decomposizione in moduli (Parnas 1972)

workflows data-structures algorithms modularization

posta Patrick Bucher 23.06.2018 - 12:03

fonte

1 risposta

Leggi altre domande sui tag workflows data-structures algorithms modularization

Quando si definisce la mappa del testo locale, la chiave della lingua o la chiave di testo, quale dovrebbe essere la prima chiave? Migliorare la mia inelegante funzione di deduplicazione Haskell

score 3 · Accepted Answer

Perché il "nuovo" (nel 1971) si avvicina meglio?

Il secondo approccio, che è quello raccomandato da Parnas, garantirà il principio di separazione delle preoccupazioni .

In altre parole, identificare decisioni di progettazione che sono difficili e suscettibili di modifiche e incapsularle nei moduli risulterà in un'architettura di sistema, che mantiene indipendenti le cose indipendenti. Di conseguenza, la maggior parte delle modifiche rimarranno locali in un modulo, il che faciliterà la manutenzione pur avendo basi di codice più grandi.

Oggigiorno, con la programmazione orientata agli oggetti e i microservizi, applichiamo questo principio anche a diversi livelli.

Ucciderà i motori del flusso di lavoro?

I motori del flusso di lavoro rispondono a esigenze molto diverse e non devono essere considerati l'implementazione del primo approccio.

Il primo approccio si basa sulla scomposizione sequenziale algoritmica di compiti e processi aziendali. Ciò si traduce in moduli che comunicano inflessibilmente tra loro in modo rigido, secondo il flusso di lavoro analizzato.

I motori di workflow, al contrario, implementano in modo modulare le complesse interazioni tra sistemi e attori diversi. Incapsulando queste interazioni, puoi facilmente cambiare l'orchestrazione.

Inoltre, va detto che i flussi di lavoro non sono solo una questione tecnica. Ad esempio, non si sostituiranno gli esseri umani con i moduli quando si automatizza un flusso di lavoro di approvazione, in cui diversi attori umani cooperano attraverso sistemi e applicazioni diversi per prendere una decisione aziendale.