Introduction to design patterns Introduzione personale 🟩 I design patterns sono simili a dei plug and play, ossia delle soluzioni che hanno funzionato bene in passato e che sono ora riutilizzati. Solitamente dovrebbe essere una abilità implicita, cioè un buon programmatore è in grado di fare senza pensarci, dovrebbe essere automatico. Infatti quando uno fa il design non lo fa esplitamente seguendo un certo modello, ma farlo solitamente risulta utile per guidare il processo. ...
This small note sections tries to fix 5 important concepts in software engineering Sub-system and modules 🟩 We need to differentiate from sub-system, which is a part of a system that tries to achieve some objective, and a module, which is more language specific way of saying imported file, or set of functions or classes. Information hiding 🟩 This is a very important principle present in object oriented programming. Within this philosophy we should be able to access only public methods or data, this allows the construction of abstractions that allow us to think at a higher level. ...
Dato che il software sta diventando sempre più diffuso, diventa sempre più importante andare a definire delle metriche che possano garantirne la qualità, ossia la non frequenza di errori o bug che possono in qualche modo limitarne la qualità. Error, Fault and Failure Secondo la definizione esatta data da IEEE, questi tre termini hanno un significato ben specifico, molto diverso. Error, sono comportamenti non previsti da un comportamento dell’utente, oppure il programmatore capisce male le specifiche. Fault sono i bugs, degli errori nel codice che creano un comportamento non previsto Failure, sono comportamenti non previsti da specifiche, che crea un guasto e non permette il funzionamento Qualità del software Rating and Ranking Il rating è l’assegnazione di un punteggio assoluto di qualità riguardo al prodotto. ...
Socialità dello sviluppo del software (3) 🟨- Si assume che È difficile assegnarsi i compiti, bisogni di utenti, tempi di consegna (+ persone difficile) È facile scrivere software (almeno software classico, e non computazione scientifica) La gente sia brava tecnicamente che socialmente è una cosa rara VS Waterfall (3) 🟨++ Pianificare tutto come viene descritto nel modello del waterfall non è possibile. Per i seguenti motivi Non è chiaro cosa vuole l’utente finale (quindi sarebbe meglio avere feedback continuo). Non si sa già dall’inizio cosa è che interessa all’utente, per questo motivo si consegna il prodotto passo passo per feedback continuo dato che i requisiti cambiano nel tempo. Giustificazione agile alto livello 🟩 Vorremo una metodologia che permetta una iterazione ossia un cambio continuo specifiche in funzione di un utente, vogliamo fare le cose a seconda di quanto vuole l’utente. ...
Introduzione ai modelli lineari Processi di sviluppo Definizione L’insieme strutturato di attività, eventi, documenti e procedure necessari per la costruzione di un sistema software Cosa viene descritto (4) 🟩 Questo è proprio quanto vuole studiare l’ingegneria del software -> metodi di sviluppo, in modo da portare i migliori risultati possibile. Nella formazione classica va a definire 4 concetti (soprattutto utili nel lavoro di gruppo, al fine di comunicare nella maniera più efficace): ...
Introduzione sui requisiti del software Note introduttive In linguaggio naturale (dizionario) 🟥+ Sono tutte le qualità necessarie per uno scopo ben determinato. Secondo il prof. I requisiti sono dei desideri ossia ciò che idealmente vorresti riguardo qualcosa (nel nostro caso il software). Ma credo sia anche una tendenza italiana di fare le cose meglio possibile senza mai soddisfare tutto Functional requirements 🟩 Sono ciò che permetterà di fare il sistema ...
Introduzione (idea principale) In breve: essence card 🟩- Giallo = Prodotto. Metafora staffetta-rugby 🟩 Con altri metodi si fanno produzioni stile staffetta, ossia un membro sta fermo, finché non ha il testimone e poi si uccide correndo… Il metodo più utile ispirato a scrum è rugby, che tutti si muovo insieme collaborando. Un po’ di tutto è fatto durante lo sprint Cicli di base (3) 🟩 Planning: in cui vengono scelti i task da eseguire durante questo sprint, solitamente questo viene preso da un subset dei task descritti dal product owner. Execution: questo è abbastanza chiaro, si sviluppa. Retrospective and review: in cui vengono identificati i problemi che sono stati incontrati durante lo sviluppo, e modi possibili per risolverli. ! 500 Lo sprint (3) 🟩- Una cosa molto importante che aiuterà di gran lunga lo sviluppo è la costanza che Si scelgono ...
NOTA: tolgo dalle note perché non mi sembra importante. Introduction to system design Packages vs diagrams 🟩- Packages fisica implementazione, perché è una cosa utile per lo sviluppo Diagrams logica visualizzazione perché aiuta solamente a comprendere meglio come funziona il sistema in toto. Components What is a component (3) 🟨 È una entità totalmente indipendente che funziona a sé, un esempio è il dll, dynamically loaded libraries presente nei sistemi di windows. Una cosa è che espongono interfacce per interagirci, e questi possono essere utilizzati per creare sistemi complessi. ...
Cosa è UML è un linguaggio di modelling (molto vecchio) ma ancora di continua evoluzione, da un punto di vista storico è nato insieme ai concetti di Object Oriented Programming che ora è molto presente all’interno dell’industria, descritto bene in Classi OOP, anche se in questa occasione sviluppata in maniera molto più intuitiva (grafica). Perché serve 🟩 Per cercare di comunicare quanto necessario riguardo struttura e dinamicità dell’architettura. Struttura di UML Structural Diagram 🟨++ These diagrams focus on representing the static structure of a system. They help depict the components, classes, objects, and their relationships in a system. Some common structural diagrams in UML include: ...