PowerPoint Presentation

Motywy zmian tradycyjnego HTML

• Problem rozdzielenia treści od sposobu

prezentacji:

– Pożądane pełne wykorzystanie CSS – jednak nie jest

ono egzekwowane przez aktualną specyfikację HTML.

• Dopuszcza usterki składniowe:

– Utrudnione przetwarzanie, większa konsumpcja

zasobów na „małych” urządzeniach.

• Stworzony z myślą o tradycyjnych komputerach:

– Zakłada jednolitą interpretację znaczników na różnych

platformach;

– Monolityczna specyfikacja – nie przygotowana na

selektywne implementacje standardu.

• Konieczność osadzania zasobów utworzonych w

innych językach (zob. dalej).

• Utrudniona walidacja formularzy (zob. dalej).

XHTML – założenia

• Składnia XML – m.in. łatwiejsze transformacje oraz prezentacja

w przeglądarkach.

• Zastąpienie poleceń formatujących arkuszami CSS – tutaj już

jako wymóg języka.

• Język podzielono na moduły:

– Mogą być selektywnie implementowane na poszczególnych platformach.
– Możliwość definiowania nowych modułów, specyficznych dla zastosowań.
– Integracja z innymi językami rodziny XML.

• Wsparcie przestrzeni nazwowych:

– Pozwala tworzyć strony złożone z różnych języków rodziny XML.

• Uwzględnia zróżnicowanie:

– Platform (zwłaszcza upowszechnienie urządzeń mobilnych) – różne

możliwości:
1) urządzeń wyjściowych,
2) mocy obliczeniowej.

– Różne prezentacje docelowe (m.in. wydruk, dźwięk…);
– Różni odbiorcy (m.in. udogodnienia dla niepełnosprawnych)
– Różne języki narodowe (znaki, kierunek tekstu…)

Reguły poprawności pochodzące od XML

• Nazwy znaczników i atrybutów – obowiązkowo małe

litery

• Cudzysłowy na wartościach atrybutów
• Poprawne zagnieżdżenie znaczników, deklaracja XML
• Zamiast atrybutów NAME – globalnie unikalne atrybuty

• Zawartość znakowa (np. skrypty) – w deklaracjach

<![CDATA[…]]>

• Tzw. attribute minimization – niedopuszczalna:

• Wymóg określenia przestrzeni nazwowej:

<html

xmlns="http://www.w3.org/1999/xhtml"

xml:lang="pl" >

• Obowiązek wskazania standardowego DTD:

<!DOCTYPE

html

PUBLIC

"-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"

Migracja z HTML do XHTML

• Zdefiniowano 3 dialekty:

–

Strict – wymusza wszystkie reguły;

–

Transitional – mniej restrykcyjny; łatwość przejścia z

HTML;

–

Frameset – służy tworzeniu stron XHTML z ramkami.

• Uwaga na deklarowany typ zawartości (Content

type):

–

text/html

– będzie traktowany jak wariant HTML.

–

application/xml

lub

application/xhtml+xml

– traktowany

jak XML

=> nie wszystkie przeglądarki wspierają;
=> istnieją drobne różnice w przetwarzaniu

(wartości domyśle, wielkość znaków w nazwach

tagów itp.)

• Problemy:

–

ograniczone wsparcie w dzisiejszych przeglądarkach;

–

utrudnione tworzenie dokumentów – niektóre założenia

krytykowane jako nadmiernie idealistyczne;

Dalsza ewolucja – propozycje XHTML 2.0

• Dość radykalne założenia ukierunkowane na:

– Kompletną eliminację poleceń o charakterze

formatującym;

– Minimalizację zestawu podstawowych znaczników;

– Kompozycyjność poleceń;

– Ograniczenie zapotrzebowania na skrypty.

• Ciekawsze zmiany:

– Brak nagłówków

h1-h6

=> zamiast tego

, i

zagnieżdżenia elementów

section

;

– Element

może mieć blokową zawartość (np. listy)

– Brak

=> zast. przez

separator

– Brak

=> elementy

line

(można „zaczepić” CSS!)

– Brak

img

=> zast. przez

object

z atrybutami

data

type

;

– Brak

=> atrybut

href

dozwolony dla większości

znaczników; podobnie często dozwolony – atrybut

src

;

– Nowy rodzaj listy:

(lista nawigacyjna). Zawiera

odnośniki tworząc w ten sposób odpowiednik menu;

XForms – założenia

• Standard formularzy dla XHTML 2.0 (nie będzie

on posiadał tradycyjnych kontrolek);

• Model danych oddzielony od zagadnienia

wyglądu kontrolki;

• Znacząco eliminują konieczność stosowania

skryptów – deklaracyjnie rozwiązana walidacja!

• Całkowicie oparte na XML:

– Definicja formularzy;
– Definicja przetwarzanych w nich danych;
– Postać przekazywanych danych.

• Oddzielenie prezentacji od treści –

wyodrębniono:

– Model (dane i logika);
– Interfejs użytkownika (prezentacja).

XForms – model

• Model stanowi jakby szablon dokumentu

gromadzącego dane (element instance).

• Zawiera też informację o sposobie przekazywania

(element submission):

<html xmlns:xf="

http://www.w3.org/2002/xforms

<head>

<xf:model>

<xf:instance>

</xf:instance>
<xf:submission id="formularz1" action="submit.asp"

method="get"/>

</xf:model>

</head> …

XForms – interfejs użytkownika

• Interfejs użytkownika określa zestaw

kontrolek i ich powiązania z modelem:

…<body>

<xf:

input

ref="

imię

<xf:

label

>First Name</xf:label></xf:input>

<br />
<xf:input ref="

nazwisko

<xf:label>Last Name</xf:label></xf:input>
<br />
<xf:

submit

submission="

formularz1

<xf:label>Submit</xf:label></xf:submit>

</body>

XForms – najważniejsze elementy

• Element label – obowiązkowy (stanowi opis dla

użtkownika).

• Inne elementy:

– secret

– wprowadzanie np. haseł

– textarea

– pole tekstowe

– trigger

– przycisk wyzwalający zdarzenie

– submit

– wysyłanie formularza

– output

– wyświetlenie wprowadzonych danych

– upload

– wysyłanie plików (zawiera

filename

mediatype

)

– range

– podawanie wartości z zakresu (atrybuty

start

end

step

)

– select

select1

– listy wyboru

– zawierają

item

posiadające

label

value

Walidacja danych w formularzu

• Tradycyjna domena skryptów osadzonych na

stronie

• Tutaj – poprzez kontrolę typologiczną opartą o

XML Schema:

<xf:instance>
<osoba xmlns="">
<imię

xsi:type="xsd:string"

<nazwisko

xsi:type="xsd:string"

<dataUr

xsi:type="xsd:date"

<wzrost

xsi:type="xsd:integer"

</osoba>
</xf:instance>

• Możliwa również kontrola dynamiczna (reguły

uzależnione od już wprowadzonych danych)

Akcje i właściwości

• W reakcji na zadane zdarzenia (w interfejsie) –

np. message – okienko komunikatu:

<input ref="nazwisko">
<label>Nazwisko</label>

<message level="ephemeral"

event="DOMFocusIn">Podaj nazwisko</message>

</input>

• Setvalue – ustawienie wartości:

<input ref="zniżka"><label>Zniżka</label>

</input>

• Właściwości (dotyczą modelu) – m.in.:

– calculate

– sposób wyliczenia;

– constraint

– ograniczenie;

– readonly

required

relevant

;

– type

– typ.

Inne ważne technologie „prezentacyjne”

XML

• XML Frames (XFrames) – zastąpi w XHTML

rozwiązania ramek pochodzące z HTML

• XML Events
• SMIL (Synchronized Multimedia Integration

Language ) – budowa interaktywnych
multimedialnych prezentacji

• Voice XML
• SSML (Speech Synthesis Markup Language)
• SVG (Scalable Vector Graphics) – zob. dalej

SVG – motywacja

• Słabości zwykłych obrazów rastrowych:

– Znaczna objętość;
– Ustalona rozdzielczość;
– Bardzo ograniczone przetwarzanie i adaptowalność

(do możliwości prezentacyjnych środowiska);

– Nie są interakcyjne;
– Problem z dodaniem informacji opisowych.

• Grafika wektorowa:

– Dostosowywalna do rozdzielczości;
– Można też osadzać zwykłe pikselowe obrazy;
– Możliwość transformacji i aktywnej interakcji.

SVG – budowa dokumentu

• Zwyczajowo – rozszerzenie pliku i prefiks ns

– svg.

<?xml version="1.0" encoding="ISO-8859-1"

standalone="no"?>

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG

20010904//EN" "http://www.w3.org/TR/2001/REC-

SVG-20010904/DTD/svg10.dtd">

xmlns:xlink=”http://www.w3.org/1999/xlink”

width="450" height="500" viewBox="0 0

450 500">

<-- TUTAJ ZAWARTOŚĆ -->

</svg>

• Język z rodziny XML (zwróćmy też uwagę na

użycie w nim języka XLink).

Przykłady dostępnych konstrukcji

• Figury geometryczne (koło, prostokąt, elipsa,

wieloboki…)

• Krzywe Beziera
• Łuki, domykanie ścieżek
• Linie, multilinie
• Tekst – różne aranżacje (m.in. osadzony na

ścieżce)

• Sposoby wygładzenia kształtów
• Dołączanie grafiki rastrowej
• Różnorodne efekty graficzne oparte na tzw.

filtrach

Manipulacja zawartością

• Zaletą opisu w XML jest separowalność i

adresowalność poszczególnych konstrukcji:

– Grupowanie do późniejszego użycia:

tutaj przygotowane elementy

</svg:g>

– Użycie grupy:

– Transformacje istniejącej zawartości:

<use xlink:href="#nazwaGrupy" transform="scale(-1

1) translate(-20 20) rotate(45)" />

– Wstawianie zasobów z innego dokumentu.
– Manipulacja z języka skryptowego (np. JavaScript).
– Dowiązywanie definicji stylów CSS.

Metadane w językach programowania i

bazach danych

• Oznaczają dane opisujące inne dane, co jest

oczywiście terminem bardzo pojemnym.

• Tradycyjne (tj. nie związane z opisem zasobów

Webu) rozumienie tego terminu wiąże się z

zależnością „jest wystąpieniem” zachodzącą

pomiędzy daną a metadaną.

• Np.

obiekt {oid=321, ”Kowalski”, 2500}

jest wystąpieniem klasy Pracownik

• Skutkuje to obiektywnym rozdziałem pomiędzy

„meta-warstwami”, wyznaczonym przez przebieg

związków „jest wystąpieniem” (instance-of).

• W bazach danych (choć nie tylko) można myśleć o

metadanych jako o danych opisowych

niezależnych od konkretnego stanu [bazy] danych

regularnych.

Wymiana metadanych – założenia

• Ważnym rodzajem metadanych stały się modele

tworzone w języku UML (szczególne model klas jako

podstawowy i najbardziej rozwinięty).

• Istotnym postępem dokonanym przez UML było

rozpowszechnienie standardowej ramy pojęciowej

dla budowy modeli systemów.

• Stworzyło to możliwość, aby modele UML

wytworzone w różnych narzędziach mogły być

swobodnie wymieniane.

• O ile standard UML nie zawiera w pełni formalnej

definicji języka, o tyle specyfikacja jego abstrakcyjnej

składni stwarza podstawy dla sformułowania

opartego na tekście formatu wymiany modeli.

• Należy przy okazji zapytać: czy tylko metadane UML

warto wymieniać?

UML – zawartość specyfikacji

• Semantyka – podana w postaci nieformalnej.

Nie określa w ścisłym sensie semantyki języka.

W tej części zdefiniowano:

– abstrakcyjną składnię UML (podaną w postaci

diagramów metamodelu UML);

– objaśnienia wprowadzonych pojęć – w języku naturalnym;
– ograniczenia poprawnościowe związane z

poszczególnymi pojęciami – podane w języku naturalnym

oraz sformalizowane w deklaratywnym języku OCL

(Object Constraint Language – również część standardu

UML)

• Notacja: objaśnia (nieformalnie) składnię

konkretną, wiążąc ją ze składnią abstrakcyjną.

• Przykładowe profile, czyli rozszerzenia języka dla

konkretnych obszarów zastosowań.

Metamodel UML – przykładowy fragment

Element

ModelElement

Feature

Namespace

GeneralizableElement

ElementOwnership

Parameter

Classifier

BehavioralFeature

Constraint

StructuralFeature

Attribute

Operation

Method

body : ProcedureExpression

defaultValue : Expression
kind : ParameterDirectionKind

constrainedElement {ordered}

name : Name

ownerScope : ScopeKind
visibility : VisibilityKind

visibility : VisibilityKind
isSpecification : Boolean

0..1

namespace

isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean

feature {ordered}

1..*

ownedElement

body : BooleanExpression

constraint

* parameter {ordered}

isQuery : Boolean

concurrency : CallConcurrencyKind
isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean
specification : String

specification

multiplicity : Multiplicity
changeability : ChangeableKind
targetScope : ScopeKind

type

owner

0..1

type

initialValue : Expression

Specyfikacja OMG MOF (Meta Object

Facility)

• Motyw – wspólna rama opisu i przetwarzania modeli w

różnych językach modelowania.

• Można z uproszczeniem przyjąć że stanowi mocno

okrojony UML (ta sama terminologia, pozostawiono

zestaw najbardziej istotnych pojęć).

• Z drugiej strony UML jest zdefiniowany w terminach MOF.

MOF stanowi zatem „wspólny mianownik” dla UML oraz

narzędzi opartych na innych [meta]modelach (np. IDL, CCM,

EJB, CWM). Zdefiniowanie tych metamodeli w terminach

MOF umożliwia ich przechowywanie w jednolitym

repozytorium oraz określanie odwzorowań ich metadanych.

• Jest zbudowany w oparciu o następujące podstawowe

pojęcia:

– Klasy: pozwalają opisać metaobiekty;

– Asocjacje: wyłącznie binarne; pozwalają opisywać

związki pomiędzy metaobiektami;

– Typy proste: reprezentacja innych danych (w tym

wartości prostych);

– Pakiety: służą modularyzacji modeli.

XMI – scenariusz wykorzystania

• A. Jeśli stosujemy własny, niestandardowy

model danych:

– Opisujemy metamodel naszego systemu (tj.

współzależności takich pojęć jak klasy, atrybuty,
asocjacje albo kolumny, tabele, typy proste) w
kategoriach MOF.

– Generujemy z modelu MOF schematy XML Schema.
– Transformujemy nasze modele do postaci plików XML

zgodnych z tymi schematami.

• B. Jeśli dysponujemy modelami w UML:

– Istnieją gotowe schematy dokumentów, dostarczone

przez standard.

– Możemy zatem przejść wprost to zapisania modeli UML

w XML-u.

XMI – zawartość standardu

• Standard określa:

– Reguły generowania schematów dla własnych

opisanych w terminach MOF metamodeli

– Sposób zapisu w XML metadanych zgodnych z tymi

metamodelami (zgodność w znacznym zakresie
kontrolowana przez ww. schematy).

– Konkretne schematy dokumentów dla modeli (czyli –

dla metadanych) UML

• Należy podkreślić, że w obecnej postaci służy

zapisowi modelu a nie diagramów (gdyż nie
determinuje postaci wizualnej wykraczającej
poza formalną treść modelu).

Metadane w postaci XMI – przykład

Osoba

Firma

pracownik

pracodawca

Zatrudnienie

<?xml version='1.0' encoding='ISO-8859-1' ?>
<!DOCTYPE XMI SYSTEM 'UML_1.4_XMI_1.1.dtd'>
<XMI xmi.version='1.2' xmlns:UML='omg.org/UML/1.4'>
  <XMI.header>
  <XMI.metamodel xmi.name='UML' xmi.version='1.4'/>
  </XMI.header>
  <XMI.content>
  <UML:Model xmi.id='S.1' name=‘Zatrudnienia' visibility='public'
  isSpecification='false' isRoot='false' isLeaf='false' isAbstract='false'>
  <UML:Namespace.ownedElement>
  <UML:Class xmi.id='S.2' name=‘Osoba' visibility='public'
isSpecification='false'
  namespace='S.1' isRoot='true' isLeaf='true' isAbstract='false'
isActive='false'/>

  <UML:Association xmi.id='G.1' name=‘Zatrudnienie' visibility='public'
  isSpecification='false' isRoot='false' isLeaf='false'
isAbstract='false'>
  <UML:Association.connection>

  </UML:Association.connection>
  </UML:Association>
  </UML:Namespace.ownedElement>
  </UML:Model>
  </XMI.content>
</XMI>

Sporządzony w oparciu o przykład ze specyfikacji OMG UML 1.5
(http://www.omg.org)

Reprezentacja obiektów w XML -

możliwości

• Zapis obiektów odbywa się w postaci elementów

XML i ich atrybutów.

• Można tworzyć powiązania pomiędzy

elementami reprezentującymi obiekty zarówno
lokalnymi (znajdującymi się w tym samym
dokumencie) jak i nielokalnymi.

• Jest to możliwe dzięki zapewnieniu tożsamości

obiektu (ID lub UUID).

• Obiekty oraz ich definicje mogą być

przedmiotem wersjonowania.

• Zgodność z metamodelem możliwa (w pewnym

zakresie) do wykontrolowania za pomocą
walidacji XML.

XMI – podsumowanie (1)

XML Schema – UML

(określony w standardzie)

XMI

XML Schema

(powstały z metamodelu)

XMI

UML

Własny
metamodel

XMI – podsumowanie (2)

• Co więc to wnosi w porównaniu z

samodzielnym, bezpośrednim tworzeniem
definicji XML Schema?

–

Gotowy język do wymiany modeli UML;

–

Modelowanie obiektowe przy tworzeniu
„słownictwa”, z którego powstaje następnie
schemat dokumentu XMI;

–

Umożliwia wsparcie narzędziowe dla tworzenia
dokumentów XMI:

1. Nadawanie unikalnych identyfikatorów,
2. Kontrola poprawności w narzędziach (pozwala

skontrolować ograniczenia nie uwzględniane w
samym schemacie XML).

MDA – Model Driven Architecture

• MDA jest najbardziej doniosłą nową inicjatywa grupy

OMG (rozwijającej standardy UML i CORBA).

• Intencją jest podniesienie poziomu abstrakcji w

procesie budowy systemów, poprzez oddzielenie logiki

biznesowej od elementów projektowych zależnych od

konkretnej infrastruktury implementacyjnej (tj.

języków programowania czy oprogramowania

pośredniczącego).

• Centralną rolę odgrywa w tej technologii modelowanie

w UML.

• Same postulaty (modelowanie, izolowanie zagadnień

realizacyjnych) nie wykraczają koncepcyjnie poza

uznane zasady inżynierii oprogramowania.

• Jakościową zmianę mogą wprowadzić zasady

modelowania oraz odpowiednie ich wsparcie

narzędziowe.

MDA – założenia architektoniczne

• MDA wyróżnia następujące 4 warstwy projektu

systemu:

– abstrakcyjny model biznesowy;
– model systemu niezależny od platformy (PIM –

platform-independent model)

– model systemu specyficzny dla wybranej platformy

(PSM – platform-specific model)

– implementacja.

• Inicjatywa koncentruje się zwłaszcza na

określeniu przejścia pomiędzy drugą i trzecią z
tych warstw:

– jest najważniejsze dla pomyślnej realizacji projektu;
– stwarza możliwość precyzyjnego opisu odwzorowania

(i częściowej jego automatyzacji).

Document Outline