diff --git a/00 - Introduzione.md b/00 - Introduzione.md index 70ea209..ef3b79c 100644 --- a/00 - Introduzione.md +++ b/00 - Introduzione.md @@ -15,13 +15,28 @@ Il corso viene tenuto dal prof. Riccardo Sisto in collaborazione con l'assistent L'obiettivo principale del corso è quello di concludere la consocenza degli argomenti trattati nei corsi di *Distributed programming I* e di *Object oriented programming*. +In particolare nel primo corso ci si era posti come obiettivi: + +1. `network programming` ossia programmare i socket. +2. `web application` ossia siti web. + +In questo corso invece andremmo verso la parte di web-application ma ci si foccalizzerà su B2B interazione. + In particolare ci si focalizzerà su tre concetti chiave: -1. conoscere le principali tecniche di sviluppo di software distribuito, cioè **applicazioni B2B** (Business to Business) +1. conoscere le principali tecniche di sviluppo di software distribuito, cioè **applicazioni B2B** (Business to Business) ossia `machine to machine iteration` in contraposizione (del primo corso) con con l'iterazione tra utente e machine. In altre parole nel primo corso si aveva una iterazione tra l'utente e le macchine mentre qui si vuole avere come unici attori due o più macchine. + + E per fare ciò si andrà ad utilizzare XML programming e web service programing. 2. imparare a programmare utilizzando **XML** e a sviluppare **servizi Web**. Tutto questo tenendo conto degli aspetti della *robustezza*, *sicurezza*, *portabilità* ed *interoperabilità* delle applicazioni che impareremo a sviluppare. + + +XML è un metodo per rapresentare i dati sul web. Si potrebbe dire che è simile a XDR. XML serve per rappresentare qualsiasi dati e ed è "cariental oriented". + +Web-service sono i programmi che interagiscono tra di loro nel web e andremmo ad usare il java per fare ciò. + ### Cosa ci sarà di nuovo rispetto al corso di DP1? Sostanzialmente, ci concentreremo sullo sviluppo di **applciazioni Web** nelle interazioni B2B, ma parleremo anche di micro servizi nell'**Internet delle cose** (ovvero: **IoT**). Faremo anche alcune cose che riguradano l'accesso programmato ai servizi di **cloud computing***. @@ -76,6 +91,20 @@ In questo corso studieremo l'**IoT**? No. Studieremo in modo ragionevolmente app +Un primo modo per connettere i dispositivi tra di loro è passare per un "service" o meglio dire un server che fornisca a loro un servizio. ![01](immagini/lezione-00/01.png) + + + + + +Oppure fare in modo che si parlino a vicenda senza l'intervento di un umano o di un altro computer. + + ![02](immagini/lezione-00/02.png) + +Un altra tecnologia per IoT è IPV6. Quindi ai giorni nostri molte applicazioni hanno la compatibilità con ipv6 o meglio dire si cerca la compatibilità con IpV6 come fa apple. + + + #### Che cos'è il cloud computing? > #### Cloud computing @@ -88,12 +117,26 @@ In questo corso studieremo il **cloud computing**? No. Studieremo i meccanismi i +Come esempio di cloud computing non si deve solo pensare ad una nuvola che da potenza di calcolo ma anche per mettere i dati con Icloud. Quindi nella nuvola si può anche virtualizare le cose e poi si accede tramite intenert. + +Nella nuvola si hanno dei server che devono parlare tra di loro per svolgere dei servizi. + + ![03](immagini/lezione-00/03.png)Più specificatamente le tecniche che studieremmo in questo corso sono alla base per tutti questi ambienti. + +Nel primo corso avemamo studiato la parte che c'è tra l'omino e la macchina (web-server) tra lasciando ciò che accadeva dietro le quinte. + +Qui andremmo a vedere l'iterazione tra i vari server che stanno dietro alle quinte come si può vedere con le freccie rosse nel disegno sotto. In questo modo ogni server da un contributo diverso ed in più. ![04](immagini/lezione-00/04.png) + + + + + ## Prerequisiti del corso Quattro grandi argomenti sono necessari per affrontare con serenità questo corso: - [ ] come funziona un **sistema operativo** e le basi per interagire con esso -- [ ] le reti telematiche, in particolare è richiesta la conoscenza dei protocolli **TCP/IP** e **HTTP**. Si userà molto il paradigma *restful*, ovvero: GET, UPDATE, DELETE, ... . +- [ ] le reti telematiche, in particolare è richiesta la conoscenza dei protocolli **TCP/IP** e **HTTP** (sapere molto bene http). Si userà molto il paradigma *restful*, ovvero: GET, UPDATE, DELETE, ... . - [ ] ciò che abbiamo imparato in **DP1**. - [ ] infine bisognerà saper usare ragionavolmente bene il linguaggio **Java**. @@ -103,22 +146,20 @@ Quattro grandi argomenti sono necessari per affrontare con serenità questo cors I principali argomenti inclusi in questo corso sono: -1. il linguaggio **XML** e i relativi strumenti Java per utilizzarlo: +1. il linguaggio **XML** e i relativi strumenti Java per utilizzarlo o meglio dire frameworks: 1. `JAXP` 2. `JAXB` - 2. conosceremo l'architettura delle applicazioni distribuite nel senso di applicazioni sviluppate secondo i seguenti paradigmi: 1. object-oriented 2. component-oriented - 3. service-oriented - + 3. service-oriented (soprattutto) 3. i *Web services* (quelli visti poco fa, **non** le Web applications) e il relativo strumenti per svilupparli, ovvero `JAX-RS` - 4. altre cose, come *ant* per il supporto automatizzato dello sviluppo, le *annotazioni Java* e così via... - + +Negli anni passati si vedeva anche sop web-services e rest-full, quest'anno ci concentriamo di più su rest-full perché il trend generale lo usa maggiormente. ## Esercizi e laboratori @@ -133,11 +174,21 @@ Lo svolgimento dei laboratori si tiene sempre di lunedì ma è diviso in due squ I laboratori inizieranno già il **10 ottobre 2016**. +Una parte dei laboratori ci sarà la Serena mentre l'altra parte ci sarà Sisto. + ## Materiale di supporto -Tutto il materiale utile può essere trovato nella [pagina del corso](https://pad.polito.it:8080/enginframe/dp2/dp2.xml?_uri=//dp2/material). Il corso è anche videoregistrato. +Tutto il materiale utile può essere trovato nella [pagina del corso](https://pad.polito.it:8080/enginframe/dp2/dp2.xml?_uri=//dp2/material). Il corso è anche videoregistrato (sulla nostra pagina personale). + +Dentro al campus si deve usare un link: +https://pad.polito.it:8080 + +Fuori dal campus: +https://pad.polito.it + + @@ -147,22 +198,38 @@ L'esame consiste in tre punti: 1. valutazione degli **assignments** 2. prova scritta ai LABINF (possibile esonero se gli assignments sono stati svolti brillantemente) -3. facoltativo un orale finale +3. facoltativo un orale finale che potrebbe essere chiesto dallo studento (se il voto non è quello che vorebbe avere) o dal professore se ci sono dei dubbi. ##### Gli assignments -Ciascun assignment verrà proposto ad ogni laboratorio e dovranno essere consegnati entro una data prestabilita, se qualche assignments verrà consegnato oltre tale data, l'assignment non verrà considerato nella valutazione. +Ciascun assignment verrà proposto ad ogni laboratorio e dovranno essere consegnati entro una data prestabilita che è relativa all'appello d'esame in cui si vuole passare, se qualche assignments verrà consegnato oltre tale data, l'assignment non verrà considerato nella valutazione. Inoltre, ogni assignment deve essere svolto individualmente. Se il docente scopre che qualcuno ha copiato o hanno lavorato insieme, verranno **entrambi** segnalati alla commissione disciplinare. Bisogna quindi stare molto attenti anche a far si che la propria soluzione rimanga al sicuro e che nessuno ce la copi. +La data di consegna di solito sono due giorni lavorativi prima dell'esame in cui si vuole sostenere. + +Si consegnano gli assegnaments come quando di faceva DP1 con il sito. + +Quando si consegnato i laboratori ci sono dei test che vengono fatti in automatico dal sistema e il laboratorio deve passare i mandatory test. Se non gli passa allora si deve ri-caricare il laboratorio con le opportune modifiche. Ci sarà anche la possibilità di provare i nostri laboratori in locale, tuttavia è buona norma mandare i laboratori non all'ultima ora ma ben prima in modo da verificare e corregere eventuali errori se non passa i tests. + ##### Ammissione al test finale Si può essere ammessi solo se ogni assignment superi almeno i test di base. Si noti che si possono consegnare gli assignment (anche tutti assieme) solo entro due giorni **lavorativi** prima dell'inizio della prova scritta ai LABINF. Quindi, se l'esame è di lunedì, bisogna consegnare gli assignment entro mercoledì! Poiché sabato e domenica non sono due giorni lavorativi. +Possiamo anche essere esonerati se i laboratori sono molto buoni e molto diverrsi l'uno dall'altro. + +Inoltre per sapere se non dobbiamo andare all'esame finale lo sapremmo solo 1 giorno prima rispetto all'esame stesso. Perché per valutarli deve aspettare che tutti abbiano consegnato e visto che la scadenza è per l'appunto due giorni lavoratori va da se che lo sapremmo solo dopo. Quindi è meglio prepararsi e poi la più non si va perché si ha avuto una buona sorpresa. + + + +Un altro modo per non sostenere l'esame è di fare una tesi o una "tesina" (progetto speciale) tutto relativo al corso. I numeri di progetti sono limitati quindi ci sarà una selezione se ci sono tanti studenti che richiedono una. + +In alcuni casi si può fare un progetto (tesi o tesina) assieme ma solo perché mettendo a ssieme il tutto si ottiene una gorssa cosa quindi è come se ci fossero molte tesi o tesine. + ##### Il professore controllerà i tuoi assignments! @@ -173,7 +240,11 @@ Fare molta attenzione ai propri elaborati, perchè il docente, con il supporto d ##### La prova scritta ai LABINF -La prova finale è facoltativa. Dipende da come sono stati fatti gli assignments. Se sono di buona qualità non ci sarà bisogno di fare la prova finale. Tale prova consiste nello svolgimento di un nuovo assignment più una domanda aperta, il tutto da svolgersi nell'arco di due ore oppure due ore e mezza. Questa prova verrà considerata superata se l'elaborato scritto supererà i test obbligatori. Faremo una simulazione di questa prova verso la fine del corso: è **importante** esserci! +La prova finale è facoltativa. Dipende da come sono stati fatti gli assignments. Se sono di buona qualità non ci sarà bisogno di fare la prova finale e molto diversi dai nostri compagni. Tale prova consiste nello svolgimento di un nuovo assignment più una domanda aperta (relativa ai nostri laboratori su come abbiamo svolto gli assignmen), il tutto da svolgersi nell'arco di due ore oppure due ore e mezza. Questa prova verrà considerata superata se l'elaborato scritto supererà i test obbligatori. Faremo una simulazione di questa prova verso la fine del corso: è **importante** esserci! + + + +Per passare la prova scritta si deve passare i test obbligatori se no non si passa la prova. In alcuni casi se non si passa l'esame ma l'errore è cosi piccolo allora il professore potrebbe fare passare l'esame. @@ -181,10 +252,16 @@ La prova finale è facoltativa. Dipende da come sono stati fatti gli assignments I punti assegnati verranno calcolati nel seguente modo: -- gli assignment verranno valutati con un punteggio minimo di 16 e un massimo di 20 punti, +- gli assignment verranno valutati con un punteggio minimo di 16 (solo se si passa i test obbligatori) e un massimo di 20 punti (se si passa anche i test non obbligatori quindi extra-test), - la prova scritta ha un range da 0 a 6 punti, - la domanda aperta vale da 0 a 4 punti. + + +Il professore ci darà un voto finale se ci piace bene se no in casi speciali si può richiedere un orale. + +Durante l'orale può chiedere delle cose e andranno ad influire sulla notazione finale sia in positivo sia in negativo. + Per avere la lode è necessario fare l'orale. diff --git a/01 - A brief recall of UML NOTATION.md b/01 - A brief recall of UML NOTATION.md index b0020d2..194232d 100644 --- a/01 - A brief recall of UML NOTATION.md +++ b/01 - A brief recall of UML NOTATION.md @@ -10,6 +10,7 @@ 4. Sequence Diagrams +Questa parte è solo un richiamo per avere la stessa "base"/linguaggio/idea del professore sul UML onde evitare pastici di comprensione in futuro. ## Richiami su UML @@ -37,6 +38,18 @@ Uno degli assunti fondamentali del paradigma a oggetti è che il concetto di cla L'elemento di modello principale dei diagrammi delle classi è la classe. Una classe rappresenta una categoria di entità (istanze), nel caso particolare dette oggetti; il nome della classe indica la categoria di entità descritta dalla classe. Ogni classe è corredata da un insieme di attributi (che descrivono le caratteristiche o lo stato degli oggetti della classe) e operazioni (che descrivono il comportamento della classe). Il simbolo grafico che rappresenta le classi UML è un rettangolo suddiviso in tre scomparti, rispettivamente dedicati al nome della classe, agli attributi e alle operazioni. +Si possono rappresenatare le classi in vario modo: + +1. Una classe senza altri dettagli. +2. Oppure con attributi e metodi. +3. Oppure dando ancora più dettagli come public, protect ecc... Con anche dei "static metodi". +4. Ci possono anche essere metodi astratti. +5. Se un metodo ha un eccezione si può usare una "throws relazione" in cui si punta alla classe a cui è collegata l'eccezione. + +Si può avere una classe senza altri dettagli. ![08](immagini/lezione-01/08.png) + + + ##### Relazione @@ -63,7 +76,7 @@ Due classi possono essere legate da una relazione di generalizzazione, che indic -##### Esempio di diagramma +##### Esempio di diagramma 1 Esempio di *Class Diagram*: @@ -79,6 +92,31 @@ La relazione indica anche una **cardinalità** (i numeri posti vicino alle Class +##### Esempio di diagramma 2 + +1. L'ereditarietà: + + In questo caso si ha l'ereditarietà: In questo caso `FileEntry` e `DirectoryEntry` ereditano da `DirectoryComponent` che è una classe astratta. Quindi `disaplay` è astratta sotto `DirectoryComponent`ma è non-astratta in `FileEntry`e `DirectoryEntry`. + +2. Aggregation relationship: + + Un altro importante link è "aggregation relationship" e si va a specificare che `DirecotoryEntry` object include `DirectoryComponent` oggetto. In questo modo si può specificare che dentro a `DirectoryEntry`si ha `DirectoryComponent` reference (link). + +3. Navigation relationship: + + Significa che si navigare da un oggetto di una classe ad un oggetto di un altra classe. In particolare in questo caso da `FileEntry object` a `File obejct`. + +4. General relationship: + + In questo caso si può anche mettere un'ettichetta (label) con la loro molteplicità. Ad esempio un `File obejct`ha uno o più `DiskSector object`. E viceversa un `DisckSector object`ha un solo `File object`. + In altre parole un `File object` è mappato su uno o più `DiskSector Objcet`mentre un `DisckSector Objcet`è mappato solo su un `File object`. + +5. "Use" relationship: + + Esso è un generico link. Quando un metodo sta per qualche motivo fuori dalla classe. + +![09](immagini/lezione-01/09.png) + ##### Interfacce Nel modellamento UML, le interfacce sono elementi di modello che definiscono serie di operazioni che altri elementi, ad esempio le classi, o componenti devono implementare. Un elemento del modello di implementazione realizza un'interfaccia sostituendo ogni operazione dichiarata dall'interfaccia. @@ -89,6 +127,19 @@ Le interfacce supportano la non visualizzazione di informazioni e la protezione Le interfacce si identificano nel seguente modo: `<>`. +##### Esempio di interfaccia: + +1. In una interfiaccia classe la parte di attributi deve essere vuota. Ma si hanno dei metodi e i metodi devono essere astratti. +2. Altro modo per rapresentare un interfaccia senza dettagli è usare un cerchietto mettendo solo il nome. + Quindi le due interfaccie (1 e 2) sono uguali a parte per i metodi che in uno ci sono mentre nell'altro non ci sono. +3. Questo link è simile all'ereditarietà ma rappresenta una classe che implementa un'interfaccia. Quindi `Bibliography`implementa `BigSearch`. Come per il cerchietto in cui `BigSearch`è attacato alla classe che implementa quella interfaccia. Quindi `Bibliography`implementa `BigSearch`. +4. In particolare si può vedere come ci siano due cerchietti che sono due interfaccie (`BigSearch`e `Update`) che vengono implementati da `Bibliography`. +5. Si può anche fare in modo che è possibile specificare che qualche classi usano le interfaccie. O alcune classi chiamano i metodi delle interfaccie. Ad esempio `SearchRobot class`usa l'interfaccia `BigSearch interface` e quindi `SearchRobot class` può chiamare le operazioni di `searchByTitle()`o altre di quella interfaccia. + + + +![10](immagini/lezione-01/10.png) + ## Package Diagrams @@ -97,6 +148,18 @@ Un package nell'Unified Modeling Language è usato *"per raggruppare elementi e Praticamente *tutti gli elementi UML possono essere raggruppati in package*. Così classi, oggetti, use case, componenti, nodi, istanze di nodi, ecc. possono essere tutti organizzati come package, consentendo così una maneggevole organizzazione delle miriadi di elementi che un modello UML comporta. + + +##### Esempio di package: + +Dentro al package `Widgets`si ha `Window class`e cosi via. + + ![11](immagini/lezione-01/11.png) + + + + + ##### Utilizzo Quando si organizzano modelli funzionali (use case, workflow, ecc.) si usano i package per modellare la struttura modulare del sistema da applicare nel mondo reale. Quando si organizza il codice sorgente, si usano i package per rappresentare i differenti strati di un codice sorgente. @@ -137,12 +200,30 @@ Il diagramma descrive nella parte superiore i diversi modi in cui possono essere Nella parte inferiore è riportato un esempio di istanze di due classi diverse, la classe Progetto e quella Utente, e la relazione che esiste tra l'istanza Wikipedia e l'istanziazione di tre determinati utenti. +Si rammenti che i nomi nelle classi nel object diagram è sempre sottolineato in modo da riccordare che non è una rappresentazione delle classi ma degli oggetti. + +Ad esempio da `d1` si può andare a `d2`ma non viceversa. + +1)Rappresenta un oggetto e non una classe. `d1`è il nome dell'ogetto. + +2) `DirectoryEntry`è il tipo della classe che appartiene a `d2`. + +3)`FileEntry`è la classe dell'ogetto ma non si specifica il nome. Ergo si ha l'oggetto `FileEntry`senza il nome. + +4) E' un oggetto remoto. + + + +![12](immagini/lezione-01/12.png) + ## Sequence Diagrams Un **Sequence Diagram** (in italiano: Diagramma di sequenza) è un diagramma previsto dall'UML utilizzato per descrivere uno scenario. +Il diagramma si legge dall'alto verso il basso e da sinistra verso destra insomma come quando si legge. + Uno scenario è una determinata sequenza di azioni in cui tutte le scelte sono state già effettuate; in pratica nel diagramma non compaiono scelte, né flussi alternativi. Normalmente da ogni Activity Diagram sono derivati uno o più Sequence Diagram; se per esempio l'Activity Diagram descrive due flussi di azioni alternativi, se ne potrebbero ricavare due scenari, e quindi due Sequence Diagram alternativi. @@ -164,7 +245,23 @@ Un esempio di sequence diagram: -## State diagram +In questo diagramma l'omino è semplicemente qualche d'uno che svolge un attività e non deve essere per forza un essere umano. I nomi dentro i rettangoli che sono sottlienati sono degli oggetti. + +Le liene verticali rappresentano la vita dell'oggetto. In particolare si può vedere come `x:Remote`vive più a lungo di tutti gli altri. + +Al punto 1 si vede che quel rettangolo rappresenta l'attività svolta dall'oggetto `Local`. + +Inoltre si vede come `getRemoteRef()`venga chiamato come metodo e poi viene ritornato una `x`come valore di ritorno. + +Nel punto 2 si vede come la chiamata al metodo è su se stesso. Quindi si chiama un metodo dell'ogetto stesso per ritornare all'oggetto stesso un valore di ritorno. + +Nel punto 3 si vede come un oggetto venga distrutto. + + + + + +## State diagram (Non è stato fatto) Lo State Chart Diagram o Diagramma degli stati è un diagramma previsto dall'UML per descrivere il comportamento di entità o di classi in termini di stato (macchina a stati). Il diagramma mostra gli stati che sono assunti dall'entità o dalla classe in risposta ad eventi esterni. diff --git a/02 - XML.md b/02 - XML.md index dfc1ad7..32143d2 100644 --- a/02 - XML.md +++ b/02 - XML.md @@ -15,7 +15,7 @@ Ci sono degli standard che definiscono dei linguaggi che possono essere utilizza Le due principali caratteristiche di ciascuno di questi standard sono: 1. essere un linguaggio in grado di definire **tipi di dati astratti**, -2. **rappresentare i dati in modo neutrale** cioè, come detto, indipendenti dai sistemi con i quali stanno interagendo. +2. **rappresentare i dati in modo neutrale** cioè, come detto, indipendenti dai sistemi con i quali stanno interagendo. Lo scambio di dati può avvenire, per esempio, tra un server basato su Java Spring e un client basato su JavaScript e i dati sono codificati tramite **JSON**. Tra le due piattaforme ci sarà un minimo di elaborazione per la *codifica/decodifica* di tali dati. @@ -25,18 +25,28 @@ Di questi standard citiamo: - **XDR** - Sviluppato nella metà del 1980 da Sun Microsystems e pubblicato per la prima volta nel 1987. È diventato uno standard IEFT nel 1995. -- **COBRA CDR** - Common Data Representation (CDR) viene utilizzato per rappresentare dati strutturati o primitivi che vengono passati come argomenti o come valori di ritorno durante le invocazioni remote negli oggetti distribuiti CORBA (Common Object Request Broker Architecture). +- **COBRA CDR** - Common Data Representation (CDR) viene utilizzato per rappresentare dati strutturati o primitivi che vengono passati come argomenti o come valori di ritorno durante le invocazioni remote negli oggetti distribuiti CORBA (Common Object Request Broker Architecture). Ora non è cosi tanto popolare. Permette la comunicazione tra client e server che sonos tati scritti in linguaggi differenti tra loro. Per esempio, può tradurre in little-endian in big-endian e viceversa. - **XML** - È un metalinguaggio per la definizione di linguaggi di markup, ovvero un linguaggio marcatore basato su un meccanismo sintattico che consente di definire e controllare il significato degli elementi contenuti in un documento o in un testo. -- **JSON** - Acronimo di JavaScript Object Notation, è un formato adatto all'interscambio di dati fra applicazioni client-server. +- **JSON** - Acronimo di JavaScript Object Notation, è un formato adatto all'interscambio di dati fra applicazioni client-server. Molto popolare ai giorni nostri. È basato sul linguaggio JavaScript Standard ECMA-262 3a edizione dicembre 1999, ma ne è indipendente. Viene usato in AJAX come alternativa a XML/XSLT. In particolare **XML** e **JSON** sono quelli che attualmente stanno avendo larga diffusione e grande popolarità. +I seguenti standard sono in binary rappresentazione: +`ASN.1`, `XDR`, `CORBA CDR` + +Mentre `XML` e `JSON` sono carattere oriented. + +XML è molto più complicato rispetto a JSON. + +Alcune volte quando si inviano i dati, non si ricevono i dati veri e propri ma prima si riceve un qualche cosa simile ad un dizionario che ci fa capire come decodificare i dati che ci arriveranno. Questo avviene ad esempio in XDR. Sta di fatto che il ricevente non sa che tipo di dato che arriverà. Quindi non sarebbe in grado di decodificare i dati senza avere prima il modo di farlo. +Mentre in XML si ha un altro sistema perché si può far in modo che dentro all'informazione c'è anche l'informazione del tipo di dato, quindi chi riceve non ha bisogno di altro, ma deve solo decodificarla. Questo accade anche per JSON. + ## XML (eXtensible Markup Language) @@ -97,8 +107,12 @@ Ecco un esempio tipico di file XML, visualizzabile all'interno di un browser qua Le principali caratteristiche del linguaggio XML possono essere riassunte nei tre seguenti punti: -1. la rappresentazione dei dati è sia *leggibile da un essere umano* sia *leggibile dalla macchina*, il che però, non lo rende ottimale per l'occupazione di memoria e larghezza di banda. +1. la rappresentazione dei dati è sia *leggibile da un essere umano* sia *leggibile dalla macchina*, il che però, non lo rende ottimale per l'occupazione di memoria e larghezza di banda. Questo è detto come "character-oriented". Essendo che è "character-oriented" ha bisogno di più banda e più memoria per poter trasmettere i dati. + + Ai giorni nostri si preferice il "character-oriented" perché è più semplice da leggere rispetto al binario e perché c'è molta potenza nei calcolatori e quindi non si deve risparmiare perché di potenza ne abbiamo cosi da avere anche dei meccanismi facili da debbuggare. + 2. I dati assumono la forma di *documenti formali*, che ricordano molto i documenti HTML. + 3. I dati includono la definizione dei tipi di se stessi, il che è utile, poichè il ricevente non ha bisogno di sapere in anticipo che tipo di dati sta per ricevere. @@ -171,6 +185,13 @@ Il DTD si può dichiarare all'interno di uno stesso documento XML (dichiarazione +Analisi documento: + +`` +è il reference del DTD e si ha la versione e si mette anche il link. Lo si mette all'inizio cosi che il parsing diventa semplice. + + + ### Relazioni tra SGML, HTML e documenti XML La seguente figura mostra i gradi di relazione che sussistono tra gli standard che sono stati descritti: @@ -179,6 +200,8 @@ La seguente figura mostra i gradi di relazione che sussistono tra gli standard c +Come si vede dal diagramma si potrebbero avere dei documenti XML non validi per XHTML e via discorendo. Ad esempio alcuni documenti HTLM sono conformi allo stantard XML e altri no. A causa delle regole che seguono. + ## Un semplice documento XML ```XML @@ -205,6 +228,13 @@ La seguente figura mostra i gradi di relazione che sussistono tra gli standard c +Analisi: + +Si hanno i tags `` simile all HTML ma la differenza è che in questo caso si può usare qualsiasi tags che si vuole, tuttavia deve essere presente nel DTD che è una sorta di dizionario. + +In questo caso dentro a ``si hanno degli elementi: +`
`,`` come se fossimo in una pagina HTLM. E dentro ad ogni tags si hanno altri tags. + ## Schema concettuale di un documento XML Un **documento XML** include due aspetti: diff --git a/immagini/lezione-00/01.png b/immagini/lezione-00/01.png new file mode 100644 index 0000000..dcc24ef Binary files /dev/null and b/immagini/lezione-00/01.png differ diff --git a/immagini/lezione-00/02.png b/immagini/lezione-00/02.png new file mode 100644 index 0000000..73b664e Binary files /dev/null and b/immagini/lezione-00/02.png differ diff --git a/immagini/lezione-00/03.png b/immagini/lezione-00/03.png new file mode 100644 index 0000000..8219c64 Binary files /dev/null and b/immagini/lezione-00/03.png differ diff --git a/immagini/lezione-00/04.png b/immagini/lezione-00/04.png new file mode 100644 index 0000000..6b3fd68 Binary files /dev/null and b/immagini/lezione-00/04.png differ diff --git "a/immagini/lezione-00/Icon\r" "b/immagini/lezione-00/Icon\r" new file mode 100644 index 0000000..e69de29 diff --git a/immagini/lezione-01/04 Backup.png b/immagini/lezione-01/04 Backup.png new file mode 100644 index 0000000..8338fe8 Binary files /dev/null and b/immagini/lezione-01/04 Backup.png differ diff --git a/immagini/lezione-01/04.png b/immagini/lezione-01/04.png index 8338fe8..c446499 100644 Binary files a/immagini/lezione-01/04.png and b/immagini/lezione-01/04.png differ diff --git a/immagini/lezione-01/08.png b/immagini/lezione-01/08.png new file mode 100644 index 0000000..bb2e621 Binary files /dev/null and b/immagini/lezione-01/08.png differ diff --git a/immagini/lezione-01/09.png b/immagini/lezione-01/09.png new file mode 100644 index 0000000..7fc0616 Binary files /dev/null and b/immagini/lezione-01/09.png differ diff --git a/immagini/lezione-01/10.png b/immagini/lezione-01/10.png new file mode 100644 index 0000000..632aa21 Binary files /dev/null and b/immagini/lezione-01/10.png differ diff --git a/immagini/lezione-01/11.png b/immagini/lezione-01/11.png new file mode 100644 index 0000000..9d90d35 Binary files /dev/null and b/immagini/lezione-01/11.png differ diff --git a/immagini/lezione-01/12.png b/immagini/lezione-01/12.png new file mode 100644 index 0000000..a98283e Binary files /dev/null and b/immagini/lezione-01/12.png differ

AltStyle によって変換されたページ (->オリジナル) /