Strategie di progettazione del software
La progettazione del software è un processo per concettualizzare i requisiti software nell'implementazione del software. La progettazione del software prende le esigenze degli utenti come sfide e cerca di trovare una soluzione ottimale. Durante la concettualizzazione del software, viene elaborato un piano per trovare il miglior design possibile per l'implementazione della soluzione prevista.
Esistono più varianti di progettazione del software. Analizziamoli brevemente:
Design strutturato
Il design strutturato è una concettualizzazione del problema in diversi elementi di soluzione ben organizzati. Fondamentalmente si occupa della progettazione della soluzione. Il vantaggio del design strutturato è che offre una migliore comprensione di come il problema viene risolto. Il design strutturato rende anche più semplice per il progettista concentrarsi sul problema in modo più accurato.
La progettazione strutturata si basa principalmente sulla strategia "divide et impera" in cui un problema viene suddiviso in diversi piccoli problemi e ogni piccolo problema viene risolto individualmente fino a quando l'intero problema non viene risolto.
I piccoli pezzi del problema vengono risolti mediante moduli di soluzione. Il design strutturato sottolinea che questi moduli devono essere ben organizzati per ottenere una soluzione precisa.
Questi moduli sono disposti in gerarchia. Comunicano tra loro. Un buon design strutturato segue sempre alcune regole per la comunicazione tra più moduli, vale a dire:
Cohesion - raggruppamento di tutti gli elementi funzionalmente correlati.
Coupling - comunicazione tra diversi moduli.
Un buon design strutturato ha un'elevata coesione e bassi accordi di accoppiamento.
Design orientato alla funzione
Nella progettazione orientata alla funzione, il sistema è composto da molti sottosistemi più piccoli noti come funzioni. Queste funzioni sono in grado di eseguire attività significative nel sistema. Il sistema è considerato come vista dall'alto di tutte le funzioni.
Il design orientato alla funzione eredita alcune proprietà del design strutturato in cui viene utilizzata la metodologia divide et impera.
Questo meccanismo di progettazione divide l'intero sistema in funzioni più piccole, che fornisce mezzi di astrazione nascondendo le informazioni e il loro funzionamento. Questi moduli funzionali possono condividere le informazioni tra di loro mediante il passaggio di informazioni e utilizzando le informazioni disponibili a livello globale.
Un'altra caratteristica delle funzioni è che quando un programma chiama una funzione, la funzione cambia lo stato del programma, che a volte non è accettabile da altri moduli. Il design orientato alla funzione funziona bene dove lo stato del sistema non ha importanza e il programma / le funzioni lavorano sull'input piuttosto che su uno stato.
Processo di progettazione
- L'intero sistema è visto come il modo in cui i dati fluiscono nel sistema per mezzo del diagramma di flusso dei dati.
- DFD descrive come le funzioni cambiano i dati e lo stato dell'intero sistema.
- L'intero sistema è logicamente suddiviso in unità più piccole note come funzioni sulla base del loro funzionamento nel sistema.
- Ciascuna funzione viene quindi descritta in generale.
Design orientato agli oggetti
La progettazione orientata agli oggetti lavora intorno alle entità e alle loro caratteristiche invece che alle funzioni coinvolte nel sistema software. Questa strategia di progettazione si concentra sulle entità e sulle sue caratteristiche. L'intero concetto di soluzione software ruota attorno alle entità coinvolte.
Vediamo i concetti importanti di Object Oriented Design:
- Objects - Tutte le entità coinvolte nella progettazione della soluzione sono note come oggetti. Ad esempio, persona, banca, azienda e clienti vengono trattati come oggetti. Ogni entità ha alcuni attributi ad essa associati e ha alcuni metodi da eseguire sugli attributi.
Classes - Una classe è una descrizione generalizzata di un oggetto. Un oggetto è un'istanza di una classe. La classe definisce tutti gli attributi che un oggetto può avere e i metodi che definiscono la funzionalità dell'oggetto.
Nella progettazione della soluzione, gli attributi vengono memorizzati come variabili e le funzionalità vengono definite mediante metodi o procedure.
- Encapsulation - In OOD, gli attributi (variabili di dati) e metodi (operazione sui dati) sono raggruppati insieme è chiamato incapsulamento. L'incapsulamento non solo raggruppa le informazioni importanti di un oggetto, ma limita anche l'accesso ai dati e ai metodi dal mondo esterno. Questo si chiama nascondere le informazioni.
- Inheritance - L'OOD consente a classi simili di impilarsi in modo gerarchico in cui le classi inferiori o inferiori possono importare, implementare e riutilizzare variabili e metodi consentiti dalle loro super classi immediate. Questa proprietà di OOD è nota come eredità. Ciò semplifica la definizione di classi specifiche e la creazione di classi generalizzate da quelle specifiche.
- Polymorphism - I linguaggi OOD forniscono un meccanismo in cui è possibile assegnare lo stesso nome ai metodi che eseguono attività simili ma variano negli argomenti. Questo è chiamato polimorfismo, che consente a un'unica interfaccia di eseguire attività per diversi tipi. A seconda di come viene richiamata la funzione, viene eseguita la rispettiva porzione di codice.
Processo di progettazione
Il processo di progettazione del software può essere percepito come una serie di passaggi ben definiti. Sebbene varia in base all'approccio di progettazione (orientato alla funzione o orientato agli oggetti, tuttavia può comportare i seguenti passaggi:
- Un progetto di soluzione viene creato dal requisito o dal sistema utilizzato in precedenza e / o dal diagramma di sequenza del sistema.
- Gli oggetti vengono identificati e raggruppati in classi per conto della somiglianza nelle caratteristiche degli attributi.
- La gerarchia di classe e la relazione tra di loro è definita.
- Il framework dell'applicazione è definito.
Approcci alla progettazione del software
Ecco due approcci generici per la progettazione del software:
Design dall'alto verso il basso
Sappiamo che un sistema è composto da più di un sottosistema e contiene un numero di componenti. Inoltre, questi sottosistemi e componenti possono avere il loro insieme di sottosistemi e componenti e creano una struttura gerarchica nel sistema.
La progettazione top-down prende l'intero sistema software come un'entità e poi lo scompone per ottenere più di un sottosistema o componente in base ad alcune caratteristiche. Ogni sottosistema o componente viene quindi trattato come un sistema e ulteriormente scomposto. Questo processo continua finché non viene raggiunto il livello di sistema più basso nella gerarchia top-down.
La progettazione top-down inizia con un modello di sistema generalizzato e continua a definirne la parte più specifica. Quando tutti i componenti sono composti, l'intero sistema viene all'esistenza.
La progettazione top-down è più adatta quando la soluzione software deve essere progettata da zero e i dettagli specifici sono sconosciuti.
Design dal basso
Il modello di progettazione dal basso verso l'alto inizia con i componenti più specifici e di base. Procede con la composizione di componenti di livello superiore utilizzando componenti di livello base o inferiore. Continua a creare componenti di livello superiore fino a quando il sistema desiderato non si evolve come un singolo componente. Con ogni livello più alto, la quantità di astrazione aumenta.
La strategia bottom-up è più adatta quando è necessario creare un sistema da un sistema esistente, in cui le primitive di base possono essere utilizzate nel sistema più recente.
Entrambi gli approcci top-down e bottom-up non sono pratici individualmente. Viene invece utilizzata una buona combinazione di entrambi.