Ingegneria del Software, Anna Rita Fasolino.
- Tempo impiegato per la preparazione: Ho seguito solo poche lezioni del corso, ho impiegato circa tre settimane per prepararlo, ma si può fare anche in meno tempo.
- traccia e/o domande ricevute all'esame: La traccia chiedeva come al solito casi d'uso, system domain model, statechart (al posto dell'activity), class diagram di dettaglio e i due sequence. All'orale mi sono stati chiesti: coesione e accoppiamento nella progettazione del software, pattern architetturale multi-layer e design pattern Composite.
- Libri e appunti utilizzati: Le slide delle lezioni sono più che sufficienti per la preparazione della prova orale.
- Eventuali difficoltà riscontrate e/o osservazioni personali: Come dicevo, ho seguito non più di 5-6 lezioni, quindi non posso giudicare la validità del corso. Nonostante ciò, in molti mi hanno detto che la risoluzione della prova scritta non viene assolutamente chiarita dai prof. Spesso si concentrano su casi d'uso, SDM e activity/statechart; vengono fatti pochissimi esempi di class diagram di dettaglio e sequence diagram di dettaglio, che sono invece fondamentali per il superamento della prima prova. Tuttavia, andando qualche volta a ricevimento (cosa che consiglio a tutti di fare) qualcosa la si capisce.
Di seguito riporto qualche suggerimento per ciascun diagramma e il punteggio massimo per ciascuno:
- Diagramma dei casi d'uso (3 punti):
è un diagramma di alto livello, rappresenta sostanzialmente chi interagisce col sistema e ciò che gli compete. Solitamente è meglio non aggiungere troppi include o extend perché esulano dagli scopi del diagramma stesso. Ad es. tutte le volte che viene chiesta una verifica, meglio non includerla come caso d'uso, ma mantenersi ad un più alto livello di astrazione.
- System Domain Model (7 punti):
è il diagramma più importante, su cui poi si basa la struttura stessa del software. Farlo bene aumenta le possibilità di superare l'esame. Oltre a inserire tutte le classi concettualmente esistenti, si richiede di assegnare tutte le responsabilità (quelle dei casi d'uso, per intenderci) alle classi giuste.
- Activity/Statechart (3 punti):
anche qui si tratta di diagrammi di alto livello, quindi (soprattutto per il primo) rappresentare sempre cosa si deve fare e non come. Lo statechart, quando richiesto dalla traccia, è facile perché sia gli stati che le transizioni sono chiarite bene nei requisiti.
- Class Diagram di Dettaglio (5 punti):
la documentazione fornita per questo tipo di diagramma è decisamente insufficiente. Viene sempre richiesto il pattern multi-layer, in particolare il BCED, quindi bisogna realizzare 4 package (Boundary, Control, Entity, Database). Non tutte le classi individuate nel SDM saranno necessarie per l'implementazione delle due funzionalità in esame. Solitamente il BCED si costruisce insieme ai due sequence.
- Sequence Diagram (2 - 6 punti):
ciò che veramente è importante qui è rispettare sempre l'architettura. Ad esempio, una classe del Control non può chiamarne una del Database senza passare per l'Entity. Solitamente la struttura dei sequence non cambia molto nei vari compiti.
Oltre ai punteggi dei diagrammi, ci sono altri 3-4 punti che tengono conto di: coerenza diagrammi-codice Java, testing. Questo per far capire quanto sia importante la progettazione delle 3 ore di compito rispetto alla stesura del codice (che comunque deve essere funzionante). Per quanto riguarda Java, non c'è bisogno di avere conoscenze approfondite del linguaggio, basta veramente scrivere qualcosa di rudimentale che faccia funzionare il tutto.
L'orale invece è davvero molto tranquillo, sia con lei che con i vari assistenti. Le domande più ricorrenti possono essere sulla manutenzione, sul testing white-box, sui design pattern o sui pattern architetturali. Ho sentito anche qualcuno a cui veniva chiesto in generale il waterfall model. Consiglio di studiare l'orale (le domande non sono mai troppo specifiche), perché può consentire di aumentare il voto anche di 4-5 punti.
Riporto qui una possibile soluzione della traccia di Ottobre 2017.
- Tempo impiegato per la preparazione: Ho seguito solo poche lezioni del corso, ho impiegato circa tre settimane per prepararlo, ma si può fare anche in meno tempo.
- traccia e/o domande ricevute all'esame: La traccia chiedeva come al solito casi d'uso, system domain model, statechart (al posto dell'activity), class diagram di dettaglio e i due sequence. All'orale mi sono stati chiesti: coesione e accoppiamento nella progettazione del software, pattern architetturale multi-layer e design pattern Composite.
- Libri e appunti utilizzati: Le slide delle lezioni sono più che sufficienti per la preparazione della prova orale.
- Eventuali difficoltà riscontrate e/o osservazioni personali: Come dicevo, ho seguito non più di 5-6 lezioni, quindi non posso giudicare la validità del corso. Nonostante ciò, in molti mi hanno detto che la risoluzione della prova scritta non viene assolutamente chiarita dai prof. Spesso si concentrano su casi d'uso, SDM e activity/statechart; vengono fatti pochissimi esempi di class diagram di dettaglio e sequence diagram di dettaglio, che sono invece fondamentali per il superamento della prima prova. Tuttavia, andando qualche volta a ricevimento (cosa che consiglio a tutti di fare) qualcosa la si capisce.
Di seguito riporto qualche suggerimento per ciascun diagramma e il punteggio massimo per ciascuno:
- Diagramma dei casi d'uso (3 punti):
è un diagramma di alto livello, rappresenta sostanzialmente chi interagisce col sistema e ciò che gli compete. Solitamente è meglio non aggiungere troppi include o extend perché esulano dagli scopi del diagramma stesso. Ad es. tutte le volte che viene chiesta una verifica, meglio non includerla come caso d'uso, ma mantenersi ad un più alto livello di astrazione.
- System Domain Model (7 punti):
è il diagramma più importante, su cui poi si basa la struttura stessa del software. Farlo bene aumenta le possibilità di superare l'esame. Oltre a inserire tutte le classi concettualmente esistenti, si richiede di assegnare tutte le responsabilità (quelle dei casi d'uso, per intenderci) alle classi giuste.
- Activity/Statechart (3 punti):
anche qui si tratta di diagrammi di alto livello, quindi (soprattutto per il primo) rappresentare sempre cosa si deve fare e non come. Lo statechart, quando richiesto dalla traccia, è facile perché sia gli stati che le transizioni sono chiarite bene nei requisiti.
- Class Diagram di Dettaglio (5 punti):
la documentazione fornita per questo tipo di diagramma è decisamente insufficiente. Viene sempre richiesto il pattern multi-layer, in particolare il BCED, quindi bisogna realizzare 4 package (Boundary, Control, Entity, Database). Non tutte le classi individuate nel SDM saranno necessarie per l'implementazione delle due funzionalità in esame. Solitamente il BCED si costruisce insieme ai due sequence.
- Sequence Diagram (2 - 6 punti):
ciò che veramente è importante qui è rispettare sempre l'architettura. Ad esempio, una classe del Control non può chiamarne una del Database senza passare per l'Entity. Solitamente la struttura dei sequence non cambia molto nei vari compiti.
Oltre ai punteggi dei diagrammi, ci sono altri 3-4 punti che tengono conto di: coerenza diagrammi-codice Java, testing. Questo per far capire quanto sia importante la progettazione delle 3 ore di compito rispetto alla stesura del codice (che comunque deve essere funzionante). Per quanto riguarda Java, non c'è bisogno di avere conoscenze approfondite del linguaggio, basta veramente scrivere qualcosa di rudimentale che faccia funzionare il tutto.
L'orale invece è davvero molto tranquillo, sia con lei che con i vari assistenti. Le domande più ricorrenti possono essere sulla manutenzione, sul testing white-box, sui design pattern o sui pattern architetturali. Ho sentito anche qualcuno a cui veniva chiesto in generale il waterfall model. Consiglio di studiare l'orale (le domande non sono mai troppo specifiche), perché può consentire di aumentare il voto anche di 4-5 punti.
Riporto qui una possibile soluzione della traccia di Ottobre 2017.
Ultima modifica da un moderatore:
