Teoria Ingegneria del software

ONFIGURATION ANAGEMENT NTEGRATION AND UILDS

1. Cosa si intende per Software configuration managment? Da che cosa

dipendono gli strumenti software a supporto di questa fase?

Il software configuration managment rappresenta un insieme di regole e strumenti in

grado di facilitare la gestione e il controllo di un software. Gli strumenti software

utilizzati a supporto di questa fase dipendono da diversi fattori, tra cui le esigenze

specifiche del progetto, la dimensione del team di sviluppo e la complessità del

software. Un esempio di software configuration management è GitHub

2. Quali sono le funzioni fondamentali che supportano lo storage e la fase di

integrazione e build?

build → insieme di attività associate all’integrazione e alla conversione dei file sorgente

in un insieme di file eseguibili destinati a un ambiente di esecuzione specifico. Le

funzioni fondamentali che supportano lo storage e la fase di integrazione e build

includono diverse attività e strumenti. Alcune funzioni chiave:

sistema di controllo delle versioni

 repository → luogo organizzato per gestione del codice

 strumenti di integrazione continua → automatizzazione del processo di

 integrazione, rilevazione errori + test automatici

gestione delle configurazioni → garantisce coerenza tra gli ambienti di sviluppo,

 test e produzione

sistemi di build → automatizzazione del processo di compilazione del codice

 sorgente, eseguendo test e generando gli artifacts della build (artifacts della

build → risultati intermedi, prodotti finali della build)

repository artifacts

 archiviazione e gestione documenti



S S &M

OFTWARE UPPORT AINTENANCE

1. Perché la fase di supporto del software e manutenzione è importante? Quali

sono le operazioni che vengono svolte in questa fase?

La fase di supporto e manutenzione del software è una fase cruciale che dura anni e

anni. Essa è essenziale in quanto i prodotti software di grandi dimensioni contengono

difetti al momento del rilascio; perciò, è importante che ci sia una buona comprensione

e ampia preparazione per l’assistenza ai clienti. Inoltre, per evitare che il software

diventi vecchio o addirittura non più utilizzato, sono necessarie release, aggiornamenti

e migliorie, nuove funzionalità.

2. È importante stimare il tasso di notifica dei problemi?

È importante stimare il tasso di notifica di problemi collegati alla distribuzione di un

software poichè rappresenta un indice di utilizzo del prodotto rilasciato e per un fattore

di autovalutazione (cosa si poteva fare meglio nel software). Le segnalazioni

dovrebbero avvenire proprio in corrispondenza o fino a qualche mese dopo il rilascio del

software, ciò significa che il cliente sta usando il nostro software (beneficio per la

software-house in termini economici).

3. In che modo può essere strutturato il centro di supporto? Quali sono i ruoli

che svolge?

Ha 3 livelli:

1° livello: Rappresentanti dell’assistenza clienti, ricevono le richieste dei clienti,

 registrano i problemi, forniscono risposte se disponibili, e inviano rapporti al

2°livello se necessario.

2° livello: Analisti del problema tecnico, ingegneri qualificati analizzano e

 risolvono i problemi con correzioni codice.

3° livello: Gruppo di controllo delle modifiche, gestisce il flusso di creazione,

 approvazione, tracciamento e chiusura delle modifiche. Si occupa anche della

pianificazione, consegna, installazione e documentazione delle correzioni.

4. Quali sono i problemi connessi con la distribuzione e l’installazione delle

patch di manutenzione/miglioria del software?

Non tutti i clienti applicheranno (o installeranno) immediatamente le versioni delle

correzioni. Le soluzioni di emergenza ad alta priorità possono essere consegnate al

cliente di cui il sistema potrebbe essere inattivo e la cui attività è sospesa.

D P

ESIGN ATTERN

1. Quali sono i principi di programmazione che motivano la realizzazione e l’uso

di design pattern?

I design pattern sono soluzioni progettuali generali utilizzati per problemi ricorrenti che

si verificano durante lo sviluppo del software. La loro utilità è basata su principi di

programmazione fondamentali quali:

Riutilizzo del codice

 Modularità

 Flessibilità

 Estendibilità

 Separazione delle Responsabilità

 Astrazione e Incapsulamento



2. Tipologie di design pattern

Strategy

Scopo: separa l’algoritmo dalla sua implementazione, consentendo di cambiare

facilmente strategia utilizzata senza dover modificare il codice client che la utilizza.

Componenti:

Context: classe che che interagisce con la strategia, il contesto delega

 l’esecuzione dell’algoritmo alla strategia

Strategy: interfaccia o classe astratta che definisce l’interfaccia comune per tutte

 le strategie concrete. Tutte le strategie concrete devono implementare questa

interfaccia

ConcreteStrategy: queste sono le classi che implementano le diverse strategie



Quando utilizzarlo? Quando si ha una famiglia di algoritmi che possono essere usati in

maniera intercambiabile.

Observer

Scopo: serve per tenere aggiornati gli oggetti quando accade qualcosa che potrebbe

interessarli.

Il soggetto non conosce come si aggiorna lo stato degli observer

Componenti:

Subject: oggetto principale che tiene traccia dello stato e mantiene una lista di

 osservatori

Observers: oggetti interessati ai cambiamenti di stato del soggetto



Quando utilizzarlo?

quando un oggetto deve notificare uno o più altri oggetti quando il suo stato

 cambia

quando si vuole evitare un accoppiamento eccessivo tra soggetto e gli

 osservatori

Decorator Pattern

Scopo: aggiungere responsabilità in più agli oggetti in maniera dinamica. I decoratori

forniscono un’alternativa flessibile e dinamica alle sottoclassi per estendere le proprie

funzionalità e comportamenti.

Componenti:

Component: classe astratta/interfaccia che definisce l’oggetto di base su cui

 verranno aggiunte le decorazioni

ConcreteComponent: implementazione del Component

 Decorator: classe astratta/interfaccia che estende component e contiene un

 riferimento al component di base

ConcreteDecorator: implementazioni del Decorator



Quando utilizzarlo? Quando è necessario aggiungere funzionalità ad oggetti in maniera

dinamica evitando la crescita eccessiva delle sottoclassi

Factory

Scopo: è un design pattern che promuove l’incapsulamento in quanto fornisce

un’interfaccia per creare oggetti in una superclasse, ma delega la scelta del tipo di

oggetto concreto da creare alle sottoclassi.

Componenti:

Product: interfaccia/classe astratta che il Factory method deve creare

 ConcreteProduct: implementazioni del Product. Ogni classe concreta rappresenta

 un tipo specifico di oggetto da creare

Creator: interfaccia/classe astratta che dichiara il metodo di creazione

 (factorymethod) che le sottoclassi devono implementare

ConcreteCreator: classi concrete che implementano il FactoryMethod. Ogni

 sottoclasse di Creator è responsabile di creare una specifica istanza di

ConcreteProduct

Quando utilizzarlo?

quando un sistema deve essere indipendente dall’implementazione specifica dei

 suoi oggetti e client e prodotti devono essere disaccoppiati

quando si desidera consentire alle sottoclassi di una classe di scegliere la classe

 da istanziare

Abstract Factory: (caso particolare del Factory)

Scopo: esso fornisce un’interfaccia per creare famiglie di oggetti correlati o dipendenti

senza specificare le classi concrete

Componenti:

Abstract Factory: interfaccia/classe astratta che dichiara metodi per creare i vari

 tipi di oggetti di una famiglia. Ciascun metodo astratto corrisponde a un tipo di

oggetto da creare

Concrete Factory: implementazioni dell’Abstract Factory, forniscono

 implementazioni specifiche dei metodi per creare oggetti concreti

Abstract Product: interfaccia/classe astratta che dichiara il comportamento

 comune per i prodotti all’interno di una famiglia

Concrete Product: implementazioni dell’Abstract Product, rappresentano i

 prodotti concreti all’interno di una famiglia

Quando utilizzarlo? Quando vuoi fornire una libreria di classi per creare diverse famiglie

di oggetti, questo design è particolarmente utile in scenari in cui il sistema deve essere

facilmente adattabile per supportare diverse piattaforme, ambienti, configurazioni

Singleton Pattern

Scopo: utilizzato per assicurarsi che, dalla classe che è un singleton, ne esista una e

una sola di istanza. (es. di utilizzo: Threads, oggetti usati per login). Possibile problema

di race condition riguardante i thread. Una possibile solutizione è utilizzare il metodo

synchronized.

Command Pattern

Scopo: incapsulare una richiesta come un oggetto, rendendo possibile la

parametrizazione delle richieste e supportare il ripristino delle operazioni

(annullamento o ripetizione)

Componenti:

Command: interfaccia comune per tutti i programmi con un metodo “esegui” che

 rappresenta l’azione da eseguire

ConcreteCommand: implementa il command e incapsula una richiesta specifica

 come oggetto

Invoker: è responsabile di invocare i comandi. Mantiene un riferimento a un

 oggetto Command e innesca l’esecuzione del comando tramite l’”esegui”

Receiver: esegue le operazioni effettive associate a un comando

 Client



Quando utilizzarlo? È particolarmente utile in scenari in cui è necessario supportare

l’annullamento, il ripristino e la gestione asincrona delle operazioni

The Adpter Pattern

Scopo: modificare l’interfaccia di una classe per rispettare l’interfaccia di un’altra classe

Componenti:

Target: interfaccia desiderata (che il client utilizza)

 Client: utilizza il target per accedere alle funzionalità dell’adattatore

 Adaptee: rappresenta l’interfaccia incompatibile

 Adapter: implementa l’interfaccia target e contiene un riferimento all’Adaptee



Quando utilizzarlo? Utilizzato per consentire a due classi o oggetti con interfacce

incompatibili di lavorare insieme

The Facade Pattern

Scopo: serve per fornire un’interfaccia semplificata per una grande porzione

Componenti:

Facade (=facciata): fornisce un’interfaccia semplificata al client

 Subsystem: insieme delle classi che costituiscono il sistema complesso

 Client: colui che interagisce con la facciata



Quando utilizzarlo? fornire un’interfaccia semplificata per un sottosistema complesso

The Templ