From 0428c7c715062efb6c6cae3ffeab6861f64c221a Mon Sep 17 00:00:00 2001 From: HSCnoKenju <26322756+HSCnoKenju@users.noreply.github.com> Date: Fri, 25 Feb 2022 16:35:40 +0100 Subject: [PATCH 1/4] correzioni sintattiche --- .../html/_sources/CostruireSoftware.rst.txt | 44 +++++++++---------- .../html/_sources/Introduzione.rst.txt | 30 ++++++------- .../html/_sources/RaspberrySoftware.rst.txt | 14 +++--- 3 files changed, 44 insertions(+), 44 deletions(-) diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt index a4560310..9793b7a7 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt +++ b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt @@ -36,7 +36,7 @@ Costruire software ====================================== -Il software puo essere definito come: +Il software può essere definito come: - l'insieme di *frasi espresse in un qualche linguaggio formale* al fine di istruire un elaboratore o una rete di elaboratori, @@ -102,10 +102,10 @@ Sotto la spinta di stringenti vincoli di *time to market* (**TTM**) molte aziend Le :blue:`fasi di analisi e progetto` anche se accuratamente svolte, non sempre sono adeguatamente documentate, e *quasi mai corralete in modo sistematico con il codice prodotto*. -Il processo di costruzione del sofware è quindi :blue:`influenzato da una potente forza`, +Il processo di costruzione del software è quindi :blue:`influenzato da una potente forza`, legata alla natura stessa del software: la spinta a impostare la costruzione in modo **bottom-up**, a partire da una specifica tecnologia costituita da un linguaggio di programmazione, -o da un framework applicativo o da una piattafforma operativa. +o da un framework applicativo o da una piattaforma operativa. .. _bottomUp: @@ -117,7 +117,7 @@ La principale conseguenza negativa di questa forza è molto spesso la mancata va in fase di analisi del problema e l'assenza di una esplicita descrizione di progetto che permetta di anticipare la valutazione dei rischi e le potenziali difficoltà connesse allo sviluppo. In molti casi adeguate fasi di analisi e di progettazione hanno luogo, anche in modo sistematico; -ma ciò putroppo quasi sempre accade **solo nella mente dei programmatori**; +ma ciò purtroppo quasi sempre accade **solo nella mente dei programmatori**; nel codice finale non vi è più traccia alcuna di queste fasi, se non qualche debole segnale legato a sporadici commenti. Tuttavia, anche se il codice fosse accuratamente documentato, sia in relazione all'analisi, sia in relazione @@ -328,7 +328,7 @@ in ciascuna delle dimensioni citate. Tuttavia, il motivo principale di una relativa (e solo apparente) stagnazione nello sviluppo di nuovi linguaggi, può essere ricondotto all'idea che un linguaggio -non deve essere necessariamente accompagnato da una sintassi concreta ma può essere suffciente +non deve essere necessariamente accompagnato da una sintassi concreta ma può essere sufficiente definire una **sintassi astratta** utilizzando un :blue:`meta-linguaggio` come ad esempio ``MOF`` (si veda `Meta Object Facility`_) unitamente alla semantica del linguaggio e a un framework di supporto. @@ -352,7 +352,7 @@ sia in fase di analisi sia in fase di progetto, cercare di dare risposta ad alcu - l'elemento è :blue:`atomico o composto`? Nel caso sia composto quali sono le parti che lo formano? - l'elemento è dotato di :blue:`stato modificabile`? In caso affermativo, quali sono le operazioni di modifica dello stato? - quali sono le :blue:`proprietà dell'elemento`, cioè quali attributi lo caratterizzano? -- da quali altri elementti dipende e secondo quale :blue:`tipo di dipendenza`? +- da quali altri elementi dipende e secondo quale :blue:`tipo di dipendenza`? Si noti che un elemento composto implica la *definizione ricorsiva della struttura di ogni parte* e la definizione di operazioni denominate **selettori**. @@ -376,7 +376,7 @@ ad uno specifico destinatario. Il ricevente attende solo quando il buffer è vuo Nel caso di stream, non vi sono vincoli di tempo per la ricezione. In una interazione **sincrona**, la comunicazione avviene senza l'uso di alcun buffer. -L'emittente e il desinatario scambiano informazione unificando concettualmente le proprie attività. +L'emittente e il destinatario scambiano informazione unificando concettualmente le proprie attività. Nel caso di stream, il destinatario si aspetta di ricevere i dati con un ritardo (delay) che non supera un massimo prefissato. @@ -405,7 +405,7 @@ Terminologia di riferimento Nel seguito, faremo riferimento alla seguente terminologia: -- **Messaggio** (:blue:`message`): termne generico per denotare informazione da trasmettere in rete. +- **Messaggio** (:blue:`message`): termine generico per denotare informazione da trasmettere in rete. - **Dispaccio** (:blue:`dispatch`): messaggio inviato in modo asincrono a N (N>=1) specifici destinatari, noti alla emittente, con l'aspettativa che questi lo ricevano e lo elaborino; l'emittente non si aspetta alcuna informazione di ritorno. @@ -417,7 +417,7 @@ Nel seguito, faremo riferimento alla seguente terminologia: rappresenta la richiesta di esecuzione di una attività, con aspettativa da parte del mittente che questa attività si concluda con una risposta pertinente alla richiesta. - **Risposta** (:blue:`reply, response`): messaggio inviato da un destinatario al mittente di una richiesta. - il contenuto del messaggio rappresenta informazione pertinente alla richiesta. + Il contenuto del messaggio rappresenta informazione pertinente alla richiesta. - **Evento** (:blue:`event`): messaggio emessa (più o meno consapevolmente) in modo asincrono da una sorgente senza alcuna particolare nozione di destinatario e senza alcuna aspettativa da parte dell'emittente. - **Segnale** (:blue:`signal`): messaggio inviato in modo asincrono a N (N>=1) destinatari, noti o meno all'emittente, @@ -473,7 +473,7 @@ il cui funzionamento può essere formalmente descritto da una 5-tuple (``States, - **States**: insieme di possibili stati in cui l'automa si può trovare. - **Inputs**: insieme delle informazioni di ingresso, denotabili attraverso un *input alphabet*; nel nostro caso - possiamo pensare che ogni simbolo dell'alfabeto denoti un messggio. + possiamo pensare che ogni simbolo dell'alfabeto denoti un messaggio. - **Outputs**: insieme della informazioni di uscita, denotabili attraverso un *output alphabet*; nel nostro caso possiamo pensare che ogni simbolo dell'alfabeto denoti una **azione**. - **InitialState**: lo stato iniziale (unico) in cui l'automa si trova quando viene creato. @@ -497,7 +497,7 @@ stato ``SCUR``: #. esegue una sequenza (che **deve terminare**) di azioni; #. al termine della sequenza di azioni controlla che vi sia almeno un input (messaggio) capace di attivare una delle transizioni verso un ulteriore stato (``SNEXT``); -#. attiva una delle transizioni possibili pasando dallo stato ``SCUR`` allo stato ``SNEXT`` (che potrebbe anche coincidere +#. attiva una delle transizioni possibili passando dallo stato ``SCUR`` allo stato ``SNEXT`` (che potrebbe anche coincidere con ``SCUR``); #. se non vi sono transizioni attivabili, rimane nello stato ``SCUR`` da cui potrà sbloccarsi solo in conseguenza di un ulteriore input. @@ -508,7 +508,7 @@ Abstraction GAP ++++++++++++++++++++++++++++++++++++++++++++++ -Va sottolieata, a questo punto, la distanza tra le mosse elementari di base e quelle necessarie per affrontare +Va sottolineata, a questo punto, la distanza tra le mosse elementari di base e quelle necessarie per affrontare in modo adeguato un problema applicativo, una distanza cui faremo riferimento col termine :blue:`abstraction gap`. .. image:: ./_static/img/Intro/TopDownBottomUp.PNG @@ -521,7 +521,7 @@ in modo adeguato un problema applicativo, una distanza cui faremo riferimento co Indicazioni sul processo di produzione ----------------------------------------------- -Il riferimento ormai universalemente accettato è quello di un processo di sviluppo agile, +Il riferimento ormai universalmente accettato è quello di un processo di sviluppo agile, che pone al centro il concetto di :blue:`modello del dominio` applicativo. .. image:: ./_static/img/Intro/agileEMDE.PNG @@ -555,7 +555,7 @@ Sappiamo però che, in molti casi, si segue un approccio `bottomUp`_ e quindi po strategie migliori per invertire il processo e le motivazioni per fare questa inversione. Supponendo che le nostre attività di laboratorio siano non troppo dissimili a quanto avviene concretamente nel -mondo del lavoro, faremo riferimento a `SCRUM`_ che oggi costitusice un diffuso framework per lo sviluppo e il +mondo del lavoro, faremo riferimento a `SCRUM`_ che oggi costituisce un diffuso framework per lo sviluppo e il mantenimento di prodotti complessi (non solo software). @@ -607,7 +607,7 @@ Per focalizzare l'attenzione sulla nostra metodologia di costruzione, cercheremo Il template +++++++++++++++++++++++ -Il documento `template2022`_ costituisce lo strumento che useremo per rendere esplcite le conoscenze, le decisioni +Il documento `template2022`_ costituisce lo strumento che useremo per rendere esplicite le conoscenze, le decisioni e i modelli introdotte nelle fasi di analisi e di progetto. Questo documento intende costituire un punto di riferimento @@ -629,7 +629,7 @@ L'analisi dei requisiti mira a: Occorre fare una analisi del testo che precisi in modo non ambiguo il significato dei termini usati e le informazioni non esplicitamente espresse. La costruzione di un :blue:`dizionario` in linguaggio naturale è utile ma non risolutiva, -in quanto esprime informazione ancora affetta da ambiguità se non da incoeranza e inconsistenza. +in quanto esprime informazione ancora affetta da ambiguità se non da incoerenza e inconsistenza. Dunque, le informazioni date in linguaggio naturale servono solo in una fase preliminare dei lavori. @@ -683,7 +683,7 @@ L'analisi del problema serve per capire quali sono le maggiori problematiche da affrontare, le tecnologie da usare e le risorse (umane e temporali) necessarie. Inoltre gettano le basi per impostare il primo sprint di sviluppo e quindi per costruire un primo 'prototipo' funzionante del sistema da estendere poi in modo -incrementale con gli sprint succesivi dopo una opportuna sprint-review con +incrementale con gli sprint successivi dopo una opportuna sprint-review con il committente @@ -692,8 +692,8 @@ il committente L'architettura logica &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& -Il risultato della analsi può essere sintetizzato nella definizione di una -:red:`architettura logica` (che specializza/esetende quella scaturita dai requisiti ) +Il risultato della analisi può essere sintetizzato nella definizione di una +:red:`architettura logica` (che specializza/estende quella scaturita dai requisiti ) che definisce la NATURA (oggetti, processi, servizi, attori, database, etc.) dei MACRO-COMPONENTI del sistema e della loro interazione, NON COME SOLUZIONE DI PROGETTO, ma come VINCOLI IMPLICATI dal problema. @@ -725,7 +725,7 @@ PIANI di testing (unit, integration, functional, acceptance) espressi in MODO NON discorsivo (formale), comprensibile a una macchina. Noi seguiremo questa idea con lo sviluppo (si veda :ref:`FASE2`) di -un meta-modello custom che permette la definizione di modelli eseguibili di sistemi distributi. +un meta-modello custom che permette la definizione di modelli eseguibili di sistemi distribuiti. ++++++++++++++++++++++++++++++++ @@ -748,8 +748,8 @@ Il *test continuo* è parte dell'approccio `DevOps`_, in cui sviluppo e operazio per l'intero ciclo di vita del prodotto. L'obiettivo è quello di accelerare la fornitura del software, bilanciando al tempo stesso i costi, la qualità e i rischi. -Noi porremo particolare attenzione al fatto che la definizione di test (autmatizzabili) può essere vista come -la formalizzazione delle `User Stories`_ e che l'uso dei modelli (esguibili) può permettere +Noi porremo particolare attenzione al fatto che la definizione di test (automatizzabili) può essere vista come +la formalizzazione delle `User Stories`_ e che l'uso dei modelli (eseguibili) può permettere di anticipare questa formalizzazione fin dalle fasi di analisi. diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/Introduzione.rst.txt b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/Introduzione.rst.txt index 4ae4d39f..7b2d19ff 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/Introduzione.rst.txt +++ b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/Introduzione.rst.txt @@ -54,7 +54,7 @@ Al termine del corso lo studente: attraverso la definizione di modelli eseguibili dell':blue:`analisi dei requisiti e dell'analisi del problema`; - è in grado di :blue:`valutare in modo critico` le continua evoluzione delle tecnologie informatiche, sia a livello computazionale, sia livello di sviluppo-software, acquisendo :blue:`conoscenze teorico-operative` - su linguaggi, metododologie e strumenti quali *Kotlin, Gradle, SCRUM, SpringBoot, Devops, Docker*; + su linguaggi, metodologie e strumenti quali *Kotlin, Gradle, SCRUM, SpringBoot, Devops, Docker*; - è in grado di comprendere il ruolo dei diversi :blue:`stili di architetture software` (layers, client-server, pipeline, microkernel, service-based, event-driven, space-based, microservices) e di come :blue:`scegliere lo stile architetturale più opportuno` per i diversi sotto-sistemi individuati; @@ -110,7 +110,7 @@ FASE2 - Introduzione al linguaggio Kotlin. - Dalle coroutine Kotlin agli attori Kotlin. - Da attori message-driven ad attori message-based che operano come automi a stati finiti. -- Definizione di una infrastruttura per attori come supporto alla costruzione di software distribuiti ed eterogeni. +- Definizione di una infrastruttura per attori come supporto alla costruzione di software distribuiti ed eterogenei. ++++++++++++++++++++++++++++++++ @@ -197,7 +197,7 @@ Dal `Sito Web del corso` leggiamo: Dettagli sul colloquio orale ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -- 48 h prima del colloqio, il codice del sistema finale deve essere stato pubblicato sul sito del gruppo, +- 48 h prima del colloquio, il codice del sistema finale deve essere stato pubblicato sul sito del gruppo, dandone relativa informazione via mail al docente. - Il giorno del colloquio, ogni gruppo deve avere effettuato gli opportuni preparativi per la/le demo, @@ -205,7 +205,7 @@ Dettagli sul colloquio orale L'ordine di presentazione dei gruppi verrà opportunamente stabilito dal docente. -#. Presentazione (collettiva di gruppo) di una demo 'live' del sistema fonale di durata 10-15(max) minuti. +#. Presentazione (collettiva di gruppo) di una demo 'live' del sistema finale di durata 10-15(max) minuti. La demo deve mostrare la esecuzione di almeno un Test(Plan) automatizzato ritenuto significativo. Per applicazioni che NON usano robot reali NON sono ammessi video, che potrebbero essere invece utili per mostrare il funzionamento di robot reali @@ -230,25 +230,25 @@ Riportiamo qui un elenco di possibili domande finali durante i colloqui orali: Quale rappresentazione (linguaggio naturale, diagrammi UML, modelli, figure, parti di codice, ...) propone per l'esposizione del progetto? - Che forma assume il deliverable di progetto e come è stato prodotto? - Vi sono connessioni cone la fase di analisi del problema? E con la fase di analisi dei requisiti? + Vi sono connessioni con la fase di analisi del problema? E con la fase di analisi dei requisiti? - Come ci può convincere che l'applicazione 'copre' tutti i requisiti dati senza doverla eseguire caso per caso? - Può mostrare la struttura della architettura finale del sistema? In quale forma ritiene sia più opportuno presentare l'architettura (o in generale una architettura software) per poterne discutere in modo pragmaticamente utile (cioè non solo in modo vago e discorsivo)? -- L'architettura finale è' stata preceduta dalla definizione di una archittura logica scaturita +- L'architettura finale è' stata preceduta dalla definizione di una architettura logica scaturita come deliverable della fase di analisi del problema? - Quali sono i punti salienti che sono stati posti in luce nella fase di analisi del problema? - E' stato evidenziato qualche punto particolamente critico? + E' stato evidenziato qualche punto particolarmente critico? - E' possibile, secondo lei, definire un modello eseguibile del sistema già al termine della fase di analisi dei requisiti? Se sì, quali vantaggi se ne potrebbero trarre? Se no, perchè non lo ritiene possibile? -- Immagino che come linguaggio di codifica si sia usato principlamente Java e/o Kotlin, +- Immagino che come linguaggio di codifica si sia usato principalmente Java e/o Kotlin, insieme a qualche parte scritta in C, C++, Python, JavaScript, etc). Nella fase di analisi del problema, è stato evidenziato qualche macroscopico gap rispetto queste tecnologie? Se sì' come si è pensato di colmare questo 'abstracton gap'? -- Fino a che punto è utile introdurre diagrammmi UML e per quali scopi? +- Fino a che punto è utile introdurre diagrammi UML e per quali scopi? Quali sono le motivazioni che possono indurre una software-house a definire linguaggi - (o metamodelli) Doamin-specific? + (o metamodelli) Domain-specific? - In ambiente industriale non è possibile pensare che sia possibile utilizzare il metamodello QActor. Ma di certo è diffuso l'uso delle librerie. Secondo lei sarebbe possibile affrontare lo sviluppo di applicazioni distribuite usando solo la libreria it.unibo.qakactor-2.5.jar e quelle ad essa necessarie? @@ -266,9 +266,9 @@ Riportiamo qui un elenco di possibili domande finali durante i colloqui orali: - In quanti Sprint Scrum-like si è svolto lo sviluppo del software? - Durante la fase di sviluppo, è stato necessario rivedere qualche parte della analisi del problema? In altre parole, sono state trovate situazioni che l'analista non aveva previsto o aveva affrontato - in modo incompleto? Se sì, ha qualche esempio? E come si è procduto in questo caso? -- E' possibilie sapere, per ciascun componente del team, di quali aspetti del sistema si è - specificatmante occupato? Quando sono state definite e da chi queste ripartizioni dello sviluppo? + in modo incompleto? Se sì, ha qualche esempio? E come si è proceduto in questo caso? +- E' possibile sapere, per ciascun componente del team, di quali aspetti del sistema si è + specificatamente occupato? Quando sono state definite e da chi queste ripartizioni dello sviluppo? - In quale fase dello sviluppo sono stati impostati programmi per il testing? Quali tipi di test (unit, integration, functional,...) sono stati pensati e quali effettivamente realizzati? - L'architettura finale del sistema mostra qualche pattern architetturale riconoscibile @@ -289,5 +289,5 @@ Riportiamo qui un elenco di possibili domande finali durante i colloqui orali: - Per un eventuale supporto Web, quale framework è stato utilizzato? Spring o Node/Express? Quali sono le motivazioni della scelta? - Il sistema finale coinvolge anche un RasperryPi? Se si, quale parte del sistema è stato deployed sul Rasp e in quale modo? -- E' stato tentato un deplyoment della applicazione (o di parti di essa) utilizzando docker? - E docker-compose? Se sì quali sono i criteri/motivazioni per la ripartizione di parti applicative su docker? \ No newline at end of file +- E' stato tentato un deployment della applicazione (o di parti di essa) utilizzando docker? + E docker-compose? Se sì quali sono i criteri/motivazioni per la ripartizione di parti applicative su docker? diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/RaspberrySoftware.rst.txt b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/RaspberrySoftware.rst.txt index 91eff0d9..f4602e60 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/RaspberrySoftware.rst.txt +++ b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/RaspberrySoftware.rst.txt @@ -48,7 +48,7 @@ A questo punto inserisci la scheda SD sul Raspberry, alimentalo con ``5VDC 700mA`` e poi (Si veda anche `Raspberry Pi Wi-Fi & Bluetooth Setup `_): -#. Leggi (opzionalmente collega il Rasperry con un cavo Ethernet) l'indirizzo IP del Raspberry sul Modem-HUB di casa. +#. Leggi (opzionalmente collega il Raspberry con un cavo Ethernet) l'indirizzo IP del Raspberry sul Modem-HUB di casa. #. Connetti il Raspberry via ``ssh`` usando ``Putty``. @@ -213,7 +213,7 @@ Shellinabox `Shellinabox `_ utilizza la tecnologia ``AJAX`` per fornire l'aspetto di una shell nativa tramite un browser web. Il demone ``shellinaboxd`` implementa un server web che ascolta sulla porta specificata -(il defualt è ``4200``). +(il default è ``4200``). Il server web pubblica uno o più servizi che verranno visualizzati in un emulatore ``VT100`` implementato come applicazione web ``AJAX``. @@ -267,7 +267,7 @@ invece di essere installati globalmente (cioè come parte di un Python a livello .. From https://www.mynetbrick.com/index.php/varie/30-python-virtualenv %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Installezione di virtualenv +Installazione di virtualenv %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Fase 1: aggiungiamo un opzione di configurazione al file hidden denominato `.bashrc` aggiungendo il comando @@ -291,7 +291,7 @@ In coppia con ``virtualenv``, è consigliabile l'installazione del modulo ``virt che contiene una sere di utilities per facilitare la gestione degli ambienti virtuali. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Installezione di virtualenvwrapper +Installazione di virtualenvwrapper %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% .. code:: @@ -328,7 +328,7 @@ Ricarichiamo le risorse del profilo: Creazione di un virtual environment %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -Posizionamoci in una drectory di lavoro e +Posizioniamoci in una directory di lavoro e creiamo un ambiente per Python 3 denominato **myenv**. .. code:: @@ -344,7 +344,7 @@ Per uscire dal virtualenv: ``deactivate``. -Per visualizzare gli ambienti virtuali creati, occoorre avere installato `virtualenvwrapper``: +Per visualizzare gli ambienti virtuali creati, occorre avere installato `virtualenvwrapper``: .. code:: @@ -481,7 +481,7 @@ ngrok #. Acquisire authtoken (xxx) #. ngrok authtoken xxx (salvato in /home/pi/.ngrok2/ngrok.yml) #. ngrok http 8081 -#. usare il forqarding proposto (http://1eaa-95-249-218-184.ngrok.io) +#. usare il forwarding proposto (http://1eaa-95-249-218-184.ngrok.io) ---------------------------------- wiringpi on Bullseye From d7393ea095c2ffb80fdc2865775d237184b5b7fe Mon Sep 17 00:00:00 2001 From: HSCnoKenju <26322756+HSCnoKenju@users.noreply.github.com> Date: Fri, 25 Feb 2022 16:38:38 +0100 Subject: [PATCH 2/4] fix TYPO for image url --- .../userDocs/Dispense/html/CostruireSoftware.html | 2 +- .../userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/CostruireSoftware.html b/it.unibo.issLabStart/userDocs/Dispense/html/CostruireSoftware.html index 7c58c540..8202e15a 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/CostruireSoftware.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/CostruireSoftware.html @@ -399,7 +399,7 @@

Indicazioni sul processo di produzione_images/topDown.png -_images/TopDownHowWhat.png +_images/TopDownHowWhat.PNG diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt index 9793b7a7..e5f0a802 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt +++ b/it.unibo.issLabStart/userDocs/Dispense/html/_sources/CostruireSoftware.rst.txt @@ -549,7 +549,7 @@ e non un assunto a-priori. * - Design first - TopDown process * - .. image:: ./_static/img/Intro/topDown.png - - .. image:: ./_static/img/Intro/TopDownHowWhat.png + - .. image:: ./_static/img/Intro/TopDownHowWhat.PNG Sappiamo però che, in molti casi, si segue un approccio `bottomUp`_ e quindi porremo molta attenzione nel capire le strategie migliori per invertire il processo e le motivazioni per fare questa inversione. From 0bf7510d4e2ee7e1a5946811fc199ee7d196a862 Mon Sep 17 00:00:00 2001 From: HSCnoKenju <26322756+HSCnoKenju@users.noreply.github.com> Date: Fri, 25 Feb 2022 16:44:27 +0100 Subject: [PATCH 3/4] fix broken link on NatMolBook, every button "Home" --- .../userDocs/Dispense/html/NatMolBook/Analisi.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Design.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Interazione.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Linguaggi.html | 2 +- .../userDocs/Dispense/html/NatMolBook/LinguaggioUML.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Pattern.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Percorso.html | 2 +- .../Dispense/html/NatMolBook/ProcessiProduzioneSoftware.html | 4 ++-- .../userDocs/Dispense/html/NatMolBook/Progettazione.html | 2 +- .../userDocs/Dispense/html/NatMolBook/SistemiSoftware.html | 2 +- .../userDocs/Dispense/html/NatMolBook/SoftwareFactory.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Tecnologie.html | 2 +- .../userDocs/Dispense/html/NatMolBook/Testing.html | 2 +- .../userDocs/Dispense/html/NatMolBook/bookEntry.html | 2 +- 14 files changed, 15 insertions(+), 15 deletions(-) diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Analisi.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Analisi.html index 547e466b..98846543 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Analisi.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Analisi.html @@ -36,7 +36,7 @@

Analisi del problema

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Design.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Design.html index ad916b18..8213c270 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Design.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Design.html @@ -39,7 +39,7 @@

Progettazione

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Interazione.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Interazione.html index 02beaa6a..2f4aaf5e 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Interazione.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Interazione.html @@ -34,7 +34,7 @@

Interazione

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Linguaggi.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Linguaggi.html index fc7a1e2c..4077368f 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Linguaggi.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Linguaggi.html @@ -39,7 +39,7 @@

Linguaggi e paradigmi computazionali

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/LinguaggioUML.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/LinguaggioUML.html index 1b2c8a6a..2e1db622 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/LinguaggioUML.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/LinguaggioUML.html @@ -39,7 +39,7 @@

Basics

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Pattern.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Pattern.html index 13a92cf6..712b1ec0 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Pattern.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Pattern.html @@ -31,7 +31,7 @@

Design pattern

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Percorso.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Percorso.html index c806d350..14c1dd6d 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Percorso.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/Percorso.html @@ -44,7 +44,7 @@

Un percorso di riferimento

diff --git a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/ProcessiProduzioneSoftware.html b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/ProcessiProduzioneSoftware.html index 843732e9..61f07b2e 100644 --- a/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/ProcessiProduzioneSoftware.html +++ b/it.unibo.issLabStart/userDocs/Dispense/html/NatMolBook/ProcessiProduzioneSoftware.html @@ -21,7 +21,7 @@

Processi di produzione del software