Please enable JavaScript.
Coggle requires JavaScript to display documents.
ESAME INGEGNERIA DEL SOFTWARE - Coggle Diagram
ESAME INGEGNERIA DEL SOFTWARE
1)NOZIONI DI BASE
INGEGNERIA DEL SOFTWARE (permette ddi sviluppare software di qualità)
coinvolge
IMPLEMENTAZIONE
VERIFICA E VALIDAZIONE
PROGETTAZIONE
MANUTENZIONE
ANALISI DEI REQUISITI
PROCESSO DI SVILUPPO DEL SOFTWARE
obiettivi
QUALITÀ
CONTROLLABILITÀ
PRODUTTIVITÀ
ATTIVITÀ FONDAMENTALI DEL PROCESSO
Progettare la struttura del sistema
Implementare il sistema
Specificare cosa deve fare il sistema
Verificare che il sistema soddisfi le aspettative
MODELLI DI PROCESSO
A CASCATA
INCREMENTALE
EVOLUTIVO/PROTOTIPAZIONE
SPIRALE
MODELLAZIONE E ASTRAZIONE (il processo per creare rappresentazioni semplificate del sistema)
serve a:
Comunicare tra stakeholder (Qualsiasi individuo, gruppo o organizzazione che ha un interesse nel progetto software, influenzandolo o essendone influenzato, direttamente o indirettamente)
Analizzare e verificare le proprietà del sistema
Gestire la complessità
MODELLI STATICI VS DINAMICI
Statici: descrivono la struttura del sistema (es. classi, oggetti)
Dinamici: descrivono il comportamento nel tempo (es. diagrammi di sequenza)
LINGUAGGI DI MODELLAZIONE (UML) - Linguaggio standard per la modellazione OO (object-oriented)
Diagrammi strutturali (classi, oggetti, componenti, deployment)
Diagrammi comportamentali (casi d’uso, sequenza, attività, stati)
OBIETTIVO MODELLAZIONE OO: Trasformare i requisiti in un modello orientato agli oggetti.
VANTAGGI PROGRAMMAZIONE OO
Scalabilità
Coerenza con la realtà del dominio
Manutenibilità
Riutilizzo del codice
DIAGRAMMI PRINCIPALI UML
Diagramma delle classi: rappresenta classi e relazioni (ereditarietà, associazioni, ecc.)
Diagramma di sequenza: flusso temporale dei messaggi tra oggetti
Diagramma dei casi d’uso: relazioni attori-sistema
Diagramma degli stati: stati e transizioni di un oggetto
3)ANALISI
SCOPO: cosa deve fare, non come
CREAZIONE DEL MODELLO DI ANALISI
separazione fra:
dominio del problema (business)
dominio della soluzione (progettazione)
PRODOTTI PRINCIPALI
classi di analisi (astraggono concetti del dominio)
devono avere:
3-5 responsabilità
attributi ed operazioni di alto livello
nome chiaro
realizzazioni dei casi d'uso (mostrano collaborazione tra oggetti per soddisfare i casi d'uso)
CLASSI E OGGETTI
OGGETTO (entità con identità, stato e comportamento)
incapsulamento (nasconde dati dietro operazioni)
CLASSE (insieme di oggetti con attributi/metodi comuni)
ISTANZA
CLASSIFICATORE
DIAGRAMMI DELLE CLASSI (UML)
NOME (CamelUpperCase)
ATTRIBUTI (LuwerCamelCase, tipo, molteplicità)
OPERAZIONI (funzioni con segnatura, direzione, return)
VISIBILITÀ (opzionale)
AMBITO (istanza vs. classe)
TECNICHE DI INDIVIDUAZIONE DELLE CLASSI
ANALISI NOME/VERBO
ANALISI CRC (classi, responsabilità, collaboratori)
ALTRE FONTI (oggetti reali, moduli, interfacce, pattern archetipo es. CRM, Money, Order)
RELAZIONI TRA CLASSI
ASSOCIAZIONI (1-1, 1-N, N-M, riflessive, navigabili)
AGGREGAZIONE/COMPOSIZIONE
EREDITARIETÀ
CLASSI ASSOCIAZIONE (con attributi propri)
NAVIGABILITÀ
MOLTEPLICITÀ
ASSOCIAZIONE RIFLESSIVA
6)PATTERN: Soluzioni riutilizzabili a problemi comuni nella progettazione software. i destinatari sono Sviluppatori esperti (architetti) e meno esperti.
OBIETTIVI:
Evitare duplicazione del codice
Separare le responsabilità per ridurre l'accoppiamento
Promuovere riusabilità, flessibilità e manutenibilità.
CLASSIFICAZIONE DEI PATTERN:
LIVELLI DI ASTRAZIONE:
Design Pattern: Risolvono problemi di progettazione OO (es: Singleton, Factory), operano a livello intermedio
Pattern di Implementazione (Idiomi): Specifici per una tecnologia/piattaforma (es: gestione memoria in C++)
Pattern Architetturali: Organizzano la struttura del sistema (es: MVC, Layered Architecture) e Operano a livello macro
PATTEN ARCHITETTUALI:
DAO (Data Access Object):
Scopo: Disaccoppiare logica di business dall'accesso ai dati.
Componenti: BusinessObject, DataAccessObject, TransferObject.
Repository: Centralizza i dati in un database condiviso.
Esempio: IDE con strumenti che condividono dati tramite repository.
Layered Architecture:
Struttura: Strati sovrapposti (es: UI, Business Logic, Database).
Vantaggi: Sostituibilità degli strati, sviluppo incrementale. Svantaggi: Performance per elaborazione a cascata.
Client-Server:Ruoli: Client richiede servizi, Server li fornisce.
Esempio: Libreria multimediale con server separati per video, immagini, catalogo
Model-View-Controller (MVC): Separazione chiara, multipli view per un model (es. Orologio con view digitale e analogica)
Componenti:
Model: Gestisce dati e logica.
View: Visualizza i dati.
Controller: Gestisce input utente.
Pipe-and-Filter: Flusso: Dati elaborati in sequenza da "filtri" (es: elaborazione batch di fatture).
Vantaggi: Modularità, riuso trasformazion
DESIGN PATTERN (GoF):
Pattern Creazionali:
Abstract Factory: Crea famiglie di oggetti correlati.
Builder: Costruisce oggetti complessi passo-passo.
Factory Method: Delega creazione alle sottoclassi.
Prototype: Clona oggetti esistenti.
Singleton: Garantisce un'unica istanza globale.
Pattern Strutturali:
Adapter: Adatta interfacce incompatibili (es: XML-to-JSON).
Bridge: Separa astrazione da implementazione (es: GUI multi-OS).
Composite: Gerarchie ad albero di oggetti (es: ordini con prodotti/scatole).
Decorator: Aggiunge funzionalità dinamiche (es: notifiche via email/SMS).
Facade: Semplifica interfaccia per sottosistemi complessi.
Flyweight: Condivide stato per ridurre memoria (es: particelle in un gioco).
Proxy: Controlla accesso a oggetti (es: lazy loading).
Pattern Comportamentali:
Chain of Responsibility: Catena di gestori per una richiesta (es: middleware di autenticazione).
Command: Incapsula richieste in oggetti (es: undo/redo in editor).
Iterator: Attraversa collezioni senza esporre struttura.
Observer: Notifica cambiamenti a sottoscrittori (es: notifiche in tempo reale).
Strategy: Famiglia di algoritmi intercambiabili (es: routing in mappe).
Visitor: Separa algoritmi dalle strutture dati (es: esportazione XML di grafi).
8)SOFTWARE COME PRODOTTO
Project Management
Gestione delle persone: Separazione tra manager di progetto e manager del personale per evitare conflitti.
Lavoro di squadra:
Riutilizzo del software:
Necessità di un'architettura coerente e ben definita.
Importanza di identificare componenti riutilizzabili.
Leadership (che può essere suddivisa tra più persone): Differenza tra leadership (visione strategica) e management (gestione operativa)
Stima dei tempi: Le stime possono essere influenzate da pressioni esterne
Controllo della qualità:
Utilizzo di sistemi di gestione della qualità (QMS) come ISO 9001.
Approcci come Total Quality Management (TQM) enfatizzano l'impegno delle persone.
Responsabilità del manager:
Analisi e controllo dei rischi.
Comunicazione con il cliente e team.
Pianificazione delle risorse e dei tempi.
Misurazione dei progressi e controllo qualità.
Utilizzo di componenti e strumenti appropriati.
Rispetto degli standard e miglioramento continuo.
Caratteristiche del software:
Preminenza del design, malleabilità, manutenzione correttiva e adattativa.
Qualità interna (struttura) ed esterna (funzionalità).
Rapporti tra committente e sviluppatore: Autoconsumo, sviluppo interno, sviluppo su commessa, software shrink-wrapped.
Mese-uomo:
Unità di misura dello sforzo di lavoro, con limiti alla scalabilità lineare.
Pianificazione delle risorse:
Modelli matematici per ottimizzare il numero di programmatori e minimizzare i tempi di rilascio.
Costo del software: Costi diretti (personale, risorse) e indiretti (mancato profitto, complessità).
Modelli di stima come COCOMO2.
Metriche del software:
Metriche dimensionali (LOC, SLOC) e funzionali (Function Point, Object Point).
Diagrammi di Gantt:
Strumento per pianificare e visualizzare task, tempi e risorse.
Configuration Management:
Gestione delle versioni e degli artefatti software
Function Point Analysis (FPA): Misura le funzionalità del software dal punto di vista dell'utente, indipendentemente dalla tecnologia.
Standardizzata dall'IFPUG.
componenti:
Funzioni dati: Internal Logic File (ILF) e External Interface File (EIF).
Funzioni transazionali: External Input (EI), External Output (EO), External Inquiry (EQ).
Processo di conteggio:
Identificare il tipo di conteggio (sviluppo, manutenzione, applicazione).
Definire l'ambito e i confini applicativi.
Contare gli Unadjusted Function Point (UFP).
Calcolare il Value Adjustment Factor (VAF) basato su 14 General System Characteristics (GSC).
Ottenere i Function Point finali con la formula: FP=UFP×VAF
Esempi e casi di studio: Applicazioni come gestione del personale, project management e web application.
Mapping tra FP e concetti OOP/web.
Conversione in linee di codice:
Tabella di conversione tra FP e KSLOC per vari linguaggi (es: C, Java, Cobol).
2)GESTIONE DEI REQUISITI
INGEGNERIA DEI REQUISITI (Disciplina per raccogliere, definire e organizzare ciò che il sistema deve fare)
Coinvolge stakeholder diversi
PROCESSO DI NEGOZIAZIONE
OBIETTIVO: creare una specifica di alto livello del sistema
FLUSSO DI LAVORO DEI REQUISITI (UP): Svolto principalmente nelle fasi di Avvio ed Elaborazione
Modellato con attività e risorse, collegate da frecce che indicano la sequenza tipica
ATTIVITÀ PRINCIPALI
Individuare attori e casi d’uso
Descrivere casi d’uso
Descrivere casi d’uso
MODELLO DEI REQUISITI (SRS)
contiene:
REQUISITI FUNZIONALI (cosa fa il sistema)
azioni/servizi (es. validare PIN)
REQUISITI NON FUNZIONALI (vincoli su come deve funzionare)
vincoli tecnici, prestazioni, sicurezza, tecnologia (es. usare C++)
MODELLO DEI CASI D'USO
ESTENSZIONE DEL FLUSSO DI LAVORO STANDARD
INDIVIDUARE REQUISITI FUNZIONALI E NON FUNZIONALI
ASSEGNARE PRIORITÀ
ESTRARRE I CASI D'USO DAI REQUISITI
DEFINIZIONE DEI REQUISITI (Specifica di COSA deve fare il sistema)
TASSONOMIA: classificazione dei requisiti in categorie gestibili
TECICHE DI RACCOLTA DEI REQUISITI
INTERVISTE
QUESTIONARI
WORKSHOP
MAPPE MENTALI
FILTRI COGNITIVI SECONDO CHOMSKY
RIMOZIONE (si omette informazione)
DISTORSIONE (si modifica la realtà percepita)
GENERALIZZAZIONE (si crea una regola universale)
COMPONENTI
ATTORI (esterni al sistema, rappresentano ruoli)
PRIMARI (iniziano il caso d’uso)
SECONDARI (continuano)
SPACIALI (es. tempo)
CASI D'USO (ciò che un attore chiede al sistema)
descrizione:
ATTORI COINVOLTI
PRECONDIZIONEI/POSTCONDIZIONI
BREVE DESCRIZIONE
SEQUANZA PRINCIPALE DEGLI EVENTI
IDENTIFICATORE NUMERICO
SEQUENZE ALTERNATIVE
NOME
RELAZIONI ()
<<include>>: frammento incluso da altri (non istanziabile da solo)
<<extend>>: aggiunge comportamento opzionale (il base è autosufficiente)
Segmenti inseribili: multipli e numerati se necessario
SUBJECT (confine del sistema - rettangolo)
ERRORI COMUNI
CONFUSIONE FRA COSA E COME
SEQUENZE TROPPO LUNGHE
SCOMPOSIZIONE FUNZIONALE
4)PROGETTAZIONE (Attività di modellazione che trasforma i requisiti in una soluzione implementabile)
MODELLI
Modello di Analisi: Logico, focalizzato sul "cosa" (requisiti)
Modello di Progettazione: Fisico, focalizzato sul "come" (implementazione)
APPROCCIO UP (UNIFIED PROCESS): organizzazione per obiettivi/manufatti, non per competenze
FLUSSO DI LAVORO PER LA PROGETTAZIONE
Progettazione di Classi (Ingegnere dei Componenti): Trasforma classi di analisi in classi implementabili e Completa attributi, metodi, relazioni
Progettazione di Casi d’Uso (Ingegnere dei Casi d’Uso): Realizza casi d’uso con classi di progettazione e diagrammi di interazione
Progettazione dell’Architettura (Architetto): Definisce l'architettura di sistema (sottosistemi, interfacce) e Produce manufatti schematici (bozze di classi, interfacce)
manufatti: Sottosistemi, classi di progettazione, interfacce, diagrammi di deployment
CLASSI DI PROGETTAZIONE: Classi con specifiche complete per l'implementazione (es. ContoBancario con attributi e metodi dettagliati).
EREDITARIETÀ E INTERFACCE
EREDITARIETÀ: Usata per riuso codice
PROBLEMI: Alta interdipendenza, fragilità (modifiche alla superclasse impattano sottoclassi)
INTERFACCE: Riducono accoppiamento, favoriscono estensibilità
COMPONENTI E SOTTOINSIEMI
COMPONENTI: Moduli autonomi con interfacce ben definite
SOTTOINSIEMI: Unità di decomposizione gerarchica e Comunicano tramite interfacce per ridurre interdipendenze
DIAGRAMMI DI PROGETTAZIONE
Diagrammi di Temporizzazione: Vincoli temporali in sistemi real-time
Macchine a Stati: Modellano cicli di vita
TIPO DI COMPORTAMENTO: Azioni/attività negli stati
TIPO DI PROTOCOLLO: Definisce condizioni per chiamate
Diagrammi di Sequenza: Mostrano interazioni tra oggetti per realizzare casi d’uso
5)IMPLEMENZAZIONE: Trasformazione del modello di progettazione in codice eseguibile
OBIETTIVI
Produrre il modello di implementazione, allocando classi di progettazione a componenti fisici
Generare codice eseguibile e gestire il deployment
MODELLO DI IMPLEMENTAZIONE
RELAZIONE CON LA PROGETTAZIONE: Vista specializzata del modello di progettazione, focalizzata su aspetti fisici
METAMODELLO
COMPONENTI: Entità logiche raggruppate (es. classi Java)
MANUFATTI: Rappresentazioni fisiche (es. file .jar, script)
NODI: Hardware/ambiente di esecuzione (es. server, PC)
DIAGRAMMI PER L'IMPLEMENTAZIONE:
DIAGRAMMA DI DEPLOJMENT: Mappare software su hardware
FORME
DESCRITTORE: Nodi generici e relazioni (es. <<periferica>>, <<ambiente esecuzione>>)
ISTANZA: Dettagli specifici (es. server_WindowsPC con ConverterApp.ear)
ELEMENTI
MANUFATTI: Stereotipi: <<file>>, <<eseguibile>>, <<libreria>>, <<script>>
NODI: Stereotipi: <<periferica>> (hardware), <<ambiente esecuzione>> (software, es. Apache).
DIAGRAMMA DEI COMPONENTI: mostra componenti software e le loro dipendenze (es. LibreriaSistema.jar da jdom.jar)
DEPLOYMENT
Progettazione: Definizione nodi e connessioni (bozza
Implementazione: Assegnazione manufatti a nodi (dettaglio)
MANUFATTI E COMPONENTI (File sorgente, eseguibili, librerie, script, documenti)
RELAZIONE CON I COMPONENTI: <<manifesta>>: Un manufatto realizza un componente (es. Libro.class → Libro)
7)CICLO DI VITA DI UN PROGETTO: Insieme di attività e azioni per realizzare un progetto software
Modelli Tradizionali di Ciclo di Vita
Modello Iterativo:
Sviluppo incrementale per sottoinsiemi di requisiti.
Prototipi parziali o prodotti funzionanti rilasciati iterativamente.
Termina con l'implementazione di tutti i requisiti (3-8 iterazioni tipiche).
Modello a Spirale (Bohem, 1988):
Analisi (obiettivi e vincoli con il committente).
Progetto (valutazione alternative e rischi).
Sviluppo (codifica e test).
Collaudo (verifica e pianificazione successiva).
vantaggi:Riusabilità del codice, Eliminazione progressiva degli errori, Integrazione sviluppo/manutenzione
svantaggi: Complessità e necessità di personalizzazione
Modello a Cascata
Studio di fattibilità.
Raccolta e analisi dei requisiti (funzionali, non funzionali, tecnologici).
Progettazione (documentazione rigorosa, UML).
Codifica e test modulari.
Integrazione e test di sistema.
Manutenzione (70% dei costi totali).
Critiche:
Scarsa flessibilità.
Difficoltà nella gestione dei cambiamenti.
Variante: Cascata con backtrack (possibilità di tornare alla fase precedente).
METODOLOGIE AGILI:
Extreme Programming (XP): Sviluppo incrementale, test prima della codifica (test upfront), pair programming.
Metafora condivisa, pianificazione flessibile ("planning game").
Scrum:
Filosofia Agile (Manifesto, 2001): Rilasci frequenti, feedback continuo, coinvolgimento attivo del committente
Kanban:
Visualizzare il flusso di lavoro (Kanban board).
Limitare il Work in Progress (WIP).
Misurare e gestire il flusso (lead time, cycle time).
Politiche di processo esplicite.
Miglioramento continuo (Kaizen).
DEVOPS: Integrazione tra sviluppo (Dev) e operations (Ops) per continuous delivery e gli obiettivi sono Automazione, collaborazione, qualità e velocità
pratiche chiave:
Continuous Integration (CI): Merge frequente nel repository centrale + test automatici.
Continuous Delivery (CD): Deployment automatizzato in ambienti di test/produzione.
Infrastructure as Code (IaC): Gestione infrastruttura via codice (es. AWS API).
Microservizi: Architettura modulare per scalabilità e fault isolation.
Monitoraggio Continuo: Strumenti come Nagios, Prometheus.
tipologie di team:
Dev & Ops Collaboration: Modello ideale (es.: Facebook).
SRE Team: Google (Site Reliability Engineering).
Container-Driven: Docker/Kubernetes per isolamento.
10)INGEGNERIA DEL SOFTWARE AVANZATA
Component-Based Software Engineering (CBSE):
Riutilizzo di componenti indipendenti e modulari.
Comunicazione tramite interfacce (fornite/usate).
Principi chiave: modularità, coesione, incapsulamento, sostituibilità, riusabilità.
Applicazioni: SOA, EDA, Web Services.
Modelli: Enterprise JavaBeans, .NET.
Legato al concetto di calcolo distribuito.
Distributed Computing: Sistemi con componenti su diversi nodi con comunicazione via messaggi. (si utilizza in: SOA, giochi online, sistemi bancari, sistemi embedded)
caratteristiche:
Concorrenza
Assenza di clock globale
Fault tolerance
architetture:
Client-server
Three-tier / N-tier
Peer-to-peer
Database-centrica
Service-Oriented Architecture (SOA):
Componenti → Servizi, con basso accoppiamento.
Proprietà di un servizio:
Autonomia
Astrazione
Riutilizzabilità
Scoperta
Composizione
ruoli:
Provider
Broker
Consumer
stili: Orchestrazione e Coreografia
tecnologie correlate: API, UDDI, Web Services
Real-Time Computing
Requisito: rispettare le deadline
tipi:
Hard real-time: mancato rispetto → fallimento (es. pacemaker)
Firm real-time: tolleranza minima
Soft real-time: degrado della qualità (es. videogiochi)
Applicazioni: sistemi embedded, stampanti, videogiochi
Strumenti: RTOS, reti real-time, linguaggi sincroni
Cloud Computing:
Servizi: IaaS, PaaS, SaaS, Serverless
Tipi di cloud:
Pubblico
Privato
Ibrido
Vantaggi:
Scalabilità
Affidabilità
Sicurezza
Velocità di provisioning
Tecnologie: Kubernetes, container, DevOps
Microservice Architecture:
Ogni microservizio: è indipendente e autonomo, Ha accoppiamento lasco ed è focalizzato su uno specifico business task
vantaggi: scalabilità, flessibilità, manutentibilità
svantaggi: Complessità e costo
patern di composizione:
Aggregator
Proxy
Chained
Branch
Shared Resource
principi:
Alta coesione
Automazione
“Two Pizza Rule”
9)SOFTWARE COME PROCESSO
PROCESSO SOFTWARE: Insieme strutturato di attività necessarie per sviluppare un sistema software
INCLUDE
Specifica
Sviluppo
Validazione
Evoluzione
MODELLI DI PROCESSO:
Waterfall (a cascata): sequenza lineare di fasi.
Incrementale: rilascio incrementale di funzionalità.
Integrazione continua: continua integrazione e test.
Prototipazione: sviluppo di prototipi per comprendere meglio i requisiti.
Agile (es. Scrum, XP): iterazioni brevi e collaborazione continua.
ATTIVITÀ FONDAMENTALI DEL PROCESSO:
Specifica dei requisiti: definizione delle funzionalità.
Sviluppo del software: progettazione e codifica.
Validazione: verifica e test.
Evoluzione: manutenzione e aggiornamenti post-rilascio.
ATTORI DEL PROCESSO SOFTWARE:
Clienti: definiscono esigenze e vincoli.
Sviluppatori: progettano e realizzano il software.
Manager di progetto: pianificazione e controllo.
Tester: verificano la correttezza del prodotto.
STRUMENTI E ARTEFATTI: Documenti di specifica, diagrammi, codice sorgente, test case, report di bug, piani di progetto
VALUTAZIONE DEI PROCESSI:
Metrica e qualità: misurazioni su costi, tempo, difetti.
Miglioramento dei processi: modelli come CMMI o ISO/IEC 12207.