Ingegneria Del Software

1. Progetto di Ingegneria del Software
Top Manager
Prof. Andrea De Lucia
Project Manager
Antonio Luca D’Avanzo
Fabiano Pecorelli

2. “
”
FABIANO
PECORELLI
Project Manager
Team 1

3. Team 1
Severino Ammirati Angelo Caputo Paolo Di Filippo
Dario Galiani Fabricio Madaio Lino Sarto

4. “
”
ANTONIO LUCA
D’AVANZO
Project Manager
Team 2

5. Team 2
Andrea Buonaguro Ferdinando D’Avino Alfredo Fiorillo
Giovanni Leo Vincenzo Noviello Andrea Sarto Giorgio Vitiello

6. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

7. Problem Domain
GiorgioVitiello

8. DOMANDA/OFFERTA PER UN LAVORO?
8

9. Web Application
9

10. PERCHE SCEGLIERE
CROWDMINE?
1
0

11. 1
1
NOTIFICHE

12. 1
2

13. 1
3
USER FRIENDLY

14. Requirements Analysis
Andrea Buonaguro

15. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

16. Requisiti Principali
16
RF 3.5:
Inserimento annuncio
RF 3.12:
Rispondere ad
un annuncio
RF 4.2:
Ricezione notifica per
annuncio di interesse
RF 5.4:
Lasciare un feedback
RNF 1:
Usabilità

17. Attori
17
Amministratore
Moderatore
Utente
Società
(l’attore fantasma)

18. Scenario
18

19. Use Case
19

20. Entity
20
Annuncio
Utente
Canditatura
Feedback
FeedbackMacro/MicroCategoriaNotifica

21. Requirements Analysis
Lino Sarto

22. Modellazione Dinamica, Path Navigazionali e mockup

23. Modellazione Dinamica
Focus sul
comportamento
del sistema
StateMachine
Activity
Sequence
Identificazione
deglioggetti
Control
Business
Boundary

24. I Diagrammi
Sequence
Activity
StateMachine
• Annuncio
• Feedback
• Utente
• Ban Utente
• Rilascio Feedback
• ValutazioneFeedback
Oltre 100 Sequence

25. Sequence Diagram – Inserimento Annuncio
*params = userId, data, titolo, luogo, listaMicro, retribuzione, tipologia, descrizione

26. Sequence Diagram
Aggiunta micro-categoria nel profilo utente.

27. State Machine Diagram - Annuncio

28. Activity Diagram – Rilascio Feedback

29. Interfacce Utente
Lorem ipsum dolor sit amet, nec
an dictas equidem appellantur, ut
has commune accommodare.
Mea illum, ludus solet idpro.
ScreenMock-ups
Path Navigazionali

30. Path Navigazionali – Profilo Personale

31. Screen mock-ups – Modifica dati anagrafici

32. Screen mock-ups – Inserimento Annuncio

33. Quality Review
State Chart
Diagram
e
Activity
Diagram
Requisiti
funzionali e
non
funzionali
Sequence
Diagram
Object
Model
Introduzione
e sistema
corrente
Casi d’uso
Path
Navigazionli
e
mock-ups

34. Quality Review – Casi d’uso
1 Contenuti generali
1aIl documento rispetta il template?
1b Se nonlo rispetta quante pagine nonlo rispettano?
2 Quante pagine contengono errorigrammaticali (eseguire controllo ortografico)?
3aIl documento contiene un indice generale?
3b Taleindice è coerente?
4aIl titolo dei capitoli è scritto in Arial24grassetto?
4b Quanti titoli nonsono scritti secondo questa convenzione?
5aIl titolo dei paragrafi è scritto in Arial 13grassetto?
5b Quanti titoli nonsono scritti secondo questa convenzione?
6aIl titolo dei sottoparagrafi di livello inferiore è stato scritto in Arial 11grassetto?
6b Quanti titoli non sono scritti secondo questa convenzione?
7aIl testo è scritto in Arial10?
7b Quante pagine contengono testo nonscritto secondo questa convenzione?
8aL'interlinea del testo è sempre 1,15?
8b Quante pagine contengono testo nonscritto secondo questa convenzione?
9aSono stati evitati doppi spazi?
9b Inquantepagine sono presenti doppi spazi?

35. (1) Quality Review – Casi d’uso
2 Contenuti Casi D’Uso
1aI casid’usocopronol’intero insieme dei requisiti funzionali?
1bQuanticasid’uso nonderivanodairequisiti funzionali?
2 Leorigini deicasi d’usosonochiare?
3 I casi d’usosonostatidescritti sottoformadi scenariodi interazione(dialogo) tragli utilizzatorieil sistema?
4 Ladescrizionedei casi d’usoècompletaechiara?
5 I casi d’usorispecchianoil reale funzionamentodelsistema?
6 Il casod’usoè esente daidettagli di implementazionee di design?
7 Sonostateindividuatetutteleinterazionitral’attoree il sistema?
8 Sonoevitatele omonimienegli identificatividei casid’uso?
9 Ogni casod’usohaalmeno unattorecon cui comunica?
10Sonostatiidentificatituttigli attori?
11Ogni attorepartecipain almenoun casod’uso?
12Si èconsideratala possibilitàdi combinaredueattoriche partecipanoagli stessi casid’usoin unounico?

36. System Design
Dario Galiani

37. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

38. Obiettivi di Design
P AMU
Performance AffidabilitàManutenzioneUtente Finale

39. S W
O T
Obiettivi di Design
39
Tempo di risposta
Throughput
Memoria
Robustezza
Disponibilità
Tolleranza aglierrori
Sicurezza
Estendibile
Modificabile
Leggibilità
Usabilità
Performance
Criteri di Manutenzione
Affidabilità
UtenteFinale

40. S W
O T
Obiettivi di Design
Tempodi risposta sotto I 10 secondi su ogni operazione.
Gestione 500 utenti connessi contemporaneamente.
Spaziodi archiviazione capacedi rendere funzionale il Sistema perogni
utente connesso.
PERFORMANCE
Tempodi risposta
Throughput
Memoria

41. O T
S W
Obiettivi di Design
Gestione di input errati, controlli sia lato Client cheServer.
Il sistema èdisponibile on-line ed èsempreaccessibile.
Tollerante agli errori grazieal basso accoppiamento.
Sistema di accesso sicuro.
AFFIDABILITÀ
Robustezza
Disponibilità
Tolleranza aglierrori
Sicurezza

42. W
T
S
O
Obiettivi di Design
Lo sviluppo in moduli consente l’estendibilità.
Il codicesi presenta in modo chiaroe constandard precisi.
ESTENDIBILE
Estendibile
Modificabile
Leggibilità

43. W
O
S
T
Obiettivi di Design
CrowdMine dispone di funzionalità semplici edintuitive perl’utente.
UTENTE FINALE
Usabilità

44. Architettura
WEB CLIENT
WEB SERVER
DATABASE SERVER
CrowdMine si basa su un’architettura a 3 livelli nota come three-tier

45. Architettura

46. Architettura
Presental’interfacciachepermetteall’utentedi comunicarecon il
sistemae dei primi controllisu input.
L’accessoavviene mediantebrowser.
WEBCLIENT– LIVELLO INTERFACCIA

47. Architettura
Elaborale richiesteche arrivanodallivello superioreecomunicacon il
databaseeffettuandologica di business.
WEBSERVER- LIVELLO APPLICAZIONI

48. Architettura
Èil livello dovesi trovail databaseperlagestione ti tuttii dati
persistentigenerati dalsistema.
DATABASESERVER– LIVELLO DEIDATI

49. Mapping Hardware-Software

50. Mapping Hardware-Software
50
Design Time Run Time

51. Pattern
Una dellesfidedi design all’internodel progettoCrowdmineè statal’implementazionedi un sistema
di eventi capacidi scatenarel’arrivodi unanotificadopounaparticolareazione.
Abbiamoquindideciso di utilizzareil Design PatternObserver.
Diagrammadi classeperObserver

52. Pattern
Un esempio applicatoal nostrosistema utilizzandola libreria standarddi PHP che implementail patternObserver

53. System Design
FerdinandoD’Avino

54. 3.e Gestione
Dati Persistenti e
DB

55. Gestione Dati Persistenti
La tecnologia
Perchèun DBMS?
• Sicurezza:Sistema di autorizzazioni
• Integrità:Controllo consistenda deidati
• Supporto: Interfaccia friendly perla gestione

56. Le Entità
• Utente
• Annuncio
• Feedback
• MicroCategoria
• MacroCategoria
• Messaggio
• Commento
• Notifica
• Dispatcher Notifica
• Candidatura
• Interesse
• Competente
• Preferito
• Riferito
• Bloccato

57. Gli Stati
Notifica
• Inserimento
• Risoluzione
• Decisione

58. Gli Stati
Ruolo
• Utente
• Moderatore
• Amministratore

59. Gli Stati
Annunci
• Domanda
• Offerta

60. Gli Stati
Candidatura
INVIOCOLLABORAZIONE
• Non valutata
• Accettata
• Rifiutata
INVIOCANDIDATURA
• Inviata
• Non inviata
• Non valutata

61. Gli Stati
• Revisione
• Attivo
• Segnalato
• Disattivato
• Ricorso
• Eliminato
• Amministratore
• Revisione Modifica

62. L’Entity Diagram di CrowdMine

63. 3.f Class
Diagram

64. Il Class Diagram di CrowdMine

65. Nel dettaglio
MacroMicro

66. Nel dettaglio
Oggetto Notifica

67. Nel dettaglio
Commento e Feedback

68. 3.g Routing e
Controllo degli
Accessi

69. Routing
Il routing nel Sistema CrowdMine è
completamente gestisto dalla pagina index.php.
Si è fatto in modo modificando il file di
configurazione di Apache htacces cheprima
dell’apertua di ogni pagina si passi appunto per
index, cheprovvederà al reindirizzamento
dell’utente nelle pagine.

70. Routing e Controllo degli Accessi
Index.php fa un parsing della URL inserita e fa in
modo di reindirizzarel’utente alla giusta pagina,
proprio in base a quest’ultima.
Questo tipo di gestione ci permette anche di
gestire in modo efficace gli accessi alle pagine
tramite il metodo checkPermission

71. Ruoli
CrowdMinedividel’utenza inruoli diversie
ognuno diquestipuò accederesoloa determinate
parti delSistema
I ruolisono:
• AMMINISTRATORE
• MODERATORE
• UTENTE
• UTENTENON LOGGATO
Ogni ruolo avràaccessoai diversilivellidel
Sistemadiversamenteinbasealla tabellaseguente
ATTORI
OGGETTI
Utente non loggato Utente Moderatore Amministratore
Annuncio visualizza visualizza,
crea,
cancella annuncio
personale,
modifica,
segnala
visualizza,
crea,
cancella annuncio
personale,
modifica,
segnala,
rimuovi con ricorso,
vota al ricorso
visualizza,
crea,
cancella annuncio
personale,
modifica,
segnala,
rimuovi
Utente visualizza crea Account,
cancella Account,
modifica Dati,
segnala,
blocca
crea Account,
cancella Account,
modifica Dati,
segnala,
blocca,
banna con ricorso,
vota al ban con ricorso
crea Account,
cancella Account,
modifica Dati,
segnala,
blocca,
banna con ricorso,
rimuovi
Macrocategoria aggiungi al profilo,
rimuovi dal profilo,
aggiungi ad un annuncio
aggiungi al profilo,
rimuovi dal profilo,
aggiungi ad un
annuncio
aggiungi al profilo,
rimuovi dal profilo,
aggiungi ad un annuncio,
aggiungi al sistema,
rimuovi dal sistema
Microcategoria crea,
aggiungi al profilo,
rimuovi dal profilo
crea,
aggiungi al profilo,
rimuovi dal profilo,
rimuovi dal sistema
crea,
aggiungi al profilo,
rimuovi dal profilo,
rimuovi dal sistema
Feedback visualizza aggiungi,
rimuovi feedback
personale, segnala
aggiungi, segnala,
rimuovi
aggiungi,
rimuovi
Notifica visualizza visualizza visualizza
Commento aggiungi,
segnala,
rimuovi c. personale
aggiungi,
segnala,
rimuovi
aggiungi,
segnala,
rimuovi
Messaggio invia,
visualizza
invia,
visualizza
invia,
visualizza
Candidatura effettua effettua effettua

72. Livelli d’accesso e CheckPermission
Coerentementecon i ruoliprimaelencati,
CrowdMineèdivisosu più livellid’accesso,
ognuno deiqualiraggiungibilesoloda determinati
ruoli.
I livellisono:
• ALL
• UTENTE
• MODERATORE
• AMMINISTRATORE
• BANNEDONLY
• NOT LOGGEDONLY
.

73. Object Design
GiovanniLeo

74. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

75. Object Design Trade-offs
Comprensibilitàvs Tempo
Prestazioni vs Costi Interfacciavs Usabilità
Sicurezzavs Efficienza

76. Tecnologie Utilizzate
Tecnologie client-side
PHP Bootstrap
GitHub
Sql

77. Package Diagram
Architetturadel Sistema
InterfaceLayer
ApplicationLogic Layer
Storage Layer

78. Package Diagram
Package Core

79. Testing
AngeloCaputo

80. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

81. L’importanza del testing
“Il test di un programma può essere usato per
mostrare la presenza di bug, ma mai per
mostrare la loro assenza.”
Edsger Wybe Dijkstra

82. Timeline
Test Plan Test CaseSpecification Test ExecutionReport Test IncidentReport

83. Test Plan

84. Test Plan – le 3 fasi principali
Test di
unità
Test di
integrazione
Test di
sistema

85. Test di Unità

86. Test Plan
Requisito funzionale 3.5

87. Timeline
Test Plan Test CaseSpecification Test ExecutionReport Test IncidentReport

88. Test Case Specification
All’interno di questo documento sono presenti
tutti i Test Case identificati nel Test Plan in
modo dettagliato, identificando:
• Id test case
• Id RF
• Precondizione
• Flusso di eventi
• Oracolo

89. Timeline
Test Plan Test CaseSpecification Test ExecutionReport Test IncidentReport

90. Test Execution Report
In questo documento si tiene traccia
dell’esecuzione dei test specificati nel test
case specification

91. Test Execution Report

92. Timeline
Test Plan Test CaseSpecification Test ExecutionReport Test IncidentReport

93. Test Incident Report
In questo documento sono elencati tutti i bug
riscontrati nella fase di testing di sistema.
In particolare, è identificato il test case con il suo
id, è presente una piccola descrizione del
problema, su come riprodurlo, la priorità e lo stato
della risoluzione

94. Testing
VincenzoNoviello

95. Performance Testing – Stress Testing

96. Performance Testing – Stress Testing
Time Test
Continuerichiestealserver
peruncertoperiododi
tempo.
RAMP Test
Raggiungereunospecifico
numerodiutenti,
progressivamente.
Click Test
Ogni utente clicca5 volte
alsecondo.

97. Performance Testing – Stress Testing
Click Test
Simulando 150 Utenti
ClickTest
Simulando 500 Utenti
Click Test
Simulando100Utenti

98. Performance Testing – Stress Testing
RAMP Test
Simulando500 Utenti
Time Test
Simulando500 Utenti

99. Performance Testing – Stress Testing

100. Performance Testing – Stress Testing

101. Performance Testing – Stress Testing

102. Security and Recovery Testing

103. Security and Recovery Testing
SQL
Injection
Prevedel’ignezionedi
codiceSQL all’internodi
unaform.
XSS
Prevedel’inserimentodi
codicejavaScriptinuna
form.
Privilege
Escalation
Teentativo di ottenere I
privilege più alti del Sistema.
Recovery
Come ilSistema
reagisce aifallimenti.

104. Security and Recovery Testing

105. Security and Recovery Testing

106. Security and Recovery Testing

107. Security and Recovery Testing

108. Timeline
Problem
Domain
Requirements
Analysis
SistemDesign Object Design Testing Demo

109. Live Demo
Paolo Di Filippo
Severino
Ammirati
Alfredo
Fiorillo
Fabricio Madaio
Andrea
Sarto