CO7214 / CO4214 / CO7514
Service-Oriented Architectures
Part 2: Modelling XML Data
Prof Reiko Heckel
www.le.ac.uk
CO7214 / CO7514: Service-oriented Architectures
Outline
1. Introduction
2. Modelling XML Data
1. Mapping Class Diagrams to DTDs
2. Attribute to Attribute, hierarchic
3. Attribute to Element, hierarchic
4. Net-like Mapping
Motivation
How to transfer :Bill from Online Shop to Shopping
Agent?
export :Bill
<<service>>
transform and transmit :Bill MyAgent:
ShoppingAgent
import :Bill
:Order :Bill
Technologies (W3C WS)
<<service>>
XML - OO data binding Amazon:
Online Shop
(export/import)
XSLT for transformation
SOAP for transmission
Requirements for Mappings
Schema: use schema (DTD) to
Preserve
allow validation of incoming PIM relevant part
data of PIM.
Justify, where
Validity: exported documents irrelevant data
are removed.
must be valid over schema
(DTD)
PSM
Correctness: schema (DTD)
should allow the same data, as Preserve data
the relevant part of the PIM where possible.
Justify where
Traceability: relations should be Schema constraints are not
documented, non-trivial (DTD) implemented
by DTD.
decisions justified
Definition: Data Mapping and Data Capacity
A data mapping m: M S from model M to schema S
m extends data capacity if no information is lost
M is contained in S (M ⊆ S), apart from mapping from model
to implementation language, e.g. class diagrams to DTD
m reflects data capacity if no information is added
S is contained in M (S ⊆ M), apart from mapping from model
to implementation language, e.g. class diagrams to DTD
m preserves data capacity if it extends and reflects it
M S (M ⊆ S), apart from mapping from model to
implementation language, e.g. class diagrams to DTD
DTDs from Class Diagrams
Select relevant class(es), associations, etc. whose instances shall
be ex- or imported according to functional requirements
parameters and return values of operations to be exchanged
include required attributes, classes, associations following your
understanding of the problem domain
Create XML-specific class diagram, using appropriate styles to
preserve data capacity and satisfy non-functional requirements
hierarchic: use composition to designate tree structure
net-like: define references as directed associations
Derive DTD, preserving (or at least extending) data capacity
mapping UML attribute XML attribute
mapping UML attribute XML element
Test DTD by translating sample object diagrams into XML instances
DTDs from Class Diagrams: Select Classes
placeOrder(sid:String, p:Product): Bill
BankAccount
accNo
0..1 Client
has name
Q: What data needs to be code
1
exchanged for returning a Bill? 1 pays
to
Bill
A: One Bill object with related total
status
BankAccounts, Clients, and Products.
contains
Product
price
descr
DTDs from Class Diagrams: XML-Specific Class
Diagram
Use composition to designate
BankAccount
tree structure accNo
Client
name
maps to XML sub-elements code
1 pays 1
to
Bill
total
status
contains
Product
hierarchic price
structure descr
DTDs from Class Diagrams: XML-Specific Class
Diagram
Define references as directed
BankAccount
associations accNo
Client
name
maps to XML id/idref pairs code
1 pays 1
to
Bill
total
status
contains
Product
net-like price
structure descr
DTDs from Class Diagrams: XML-Specific Class
Diagram
Use composition to designate BankAccount
tree structure accNo Client
code name
maps to XML elements
1
Define references as directed 1 pays
to
associations Bill
maps to XML id/idref pairs total
status
contains
Product
hybrid price
structure descr
Mapping: Class Diagrams DTDs
General Rules
class element
association (n-to-n) element
Plus two (orthogonal) mapping variants
attribute attribute, hierarchic
attribute element, hierarchic
attribute attribute, net-like
attribute element, net-like
o hierarchic or
determined by
o net-like structure DTD-specific model
Questions
How do I know what is the “relevant part of the PIM”
to be preserved?
What are functional and non-functional requirements?
How do operation signatures tell me what data to
include?
Is it always possible to preserve data capacity when
mapping PSM to DTD? If not, explain why!
What is the most and the least demanding of the
three requirements: to be data preserving,
extending or reflecting?
What is the purpose of the reduced class diagram?
Exercise
A 1..* 2 B
a: String b: int
If possible, create from the domain-specific class
diagram above DTD-specific diagrams such that data
capacity is
preserved
extended, but not preserved
reflected but not extended
Assume, for the purpose of this exercise, that all
classes, associations, attributes, … are relevant.
CO7214 / CO7514: Service-oriented Architectures
Outline
1. Introduction
2. Modelling XML Data
Mapping Class Diagrams to DTDs
2. Attribute to Attribute, hierarchic
3. Attribute to Element, hierarchic
4. Net-like Mapping
Attribute Attribute, hierarchic
<!ELEMENT
BankAccount
Bill ( Client
accNo
Client, code name
Product*,
1 pays 1
BankAccount
) to
Bill
> total
<!ATTLIST Bill status
status CDATA #REQUIRED
contains
total CDATA #REQUIRED
> Product
price
descr
Attribute Attribute, hierarchic
BankAccount
<!ELEMENT Client, EMPTY> accNo Client
<!ATTLIST Client code name
name CDATA #REQUIRED
1 pays 1
>
to
Bill
total
status
contains
Product
price
descr
Attribute Attribute, hierarchic
BankAccount
<!ELEMENT Product, EMPTY> Client
accNo
<!ATTLIST Product code name
price CDATA #REQUIRED
1 pays 1
descr CDATA #REQUIRED
> to
Bill
total
status
contains
Product
price
descr
Attribute Attribute, hierarchic
BankAccount
<!ELEMENT BankAccount, EMPTY> Client
accNo
<!ATTLIST BankAccount code name
accNo CDATA #REQUIRED
1 pays 1
code CDATA #REQUIRED
> to
Bill
total
status
contains
Product
price
descr
DTD Summary: Attribute Attribute, hierarchic
<?xml version ="1.0„ encoding = "UTF-8"?>
<!ELEMENT Bill (Client, Product*, BankAccount)>
<!ATTLIST Bill
status CDATA #REQUIRED
total CDATA #REQUIRED>
<!ELEMENT Client EMPTY>
<!ATTLIST Client name CDATA #REQUIRED>
<!ELEMENT Product EMPTY>
<!ATTLIST Product
price CDATA #REQUIRED
descr CDATA #REQUIRED>
<!ELEMENT BankAccount EMPTY>
<!ATTLIST BankAccount
accNo CDATA #REQUIRED
code CDATA #REQUIRED>
Object Diagram XML Instance: Attr. Attr.,
hierarchic
<?xml version="1.0" encoding="UTF-8"?>
:BankAccount :Client
<!DOCTYPE Bill SYSTEM "we-shop-attr.dtd">
accNo = 0815 name
<Bill status="closed" total="150"> code = 1234 = “Max“
<Client name=“Max"/> :Bill
pays
<Product to status =
price="50“ closed
descr = “Winnetou”/> total =
<Product 150
price="100“ contains contains
descr=“H.Potter”/> :Product :Product
<BankAccount accNo="0815" code="1234"/> price = price=50
100 descr =
</Bill> descr = “Winnetou“
“H.Potter“
Mapping: Class Diagrams DTDs
General Rules
class element
association (n-to-n) element
Plus two (orthogonal) mapping variants
attribute attribute, hierarchic
attribute element, hierarchic
attribute attribute, net-like
attribute element, net-like
o hierarchic or
determined by
o net-like structure DTD-specific model
Exercise
Apply the mapping attribute attribute, hierarchic to
the exercise at the end of 2.1. creating
1. DTD specific class diagram
2. DTD and sample XML instance
Try to ensure that data capacity is preserved or at
least extended, and where this is not the case, point
this out and justify why it is not.
CO7214 / CO7514: Service-oriented Architectures
Outline
1. Introduction
2. Modelling XML Data
Mapping Class Diagrams to DTDs
Attribute to Attribute, hierarchic
3. Attribute to Element, hierarchic
4. Net-like Mapping
Attribute Element, hierarchic
BankAccount
Client
accNo
<!ELEMENT name
code
Bill( 1
1 pays
Client,
Product*, to
Bill
BankAccount, total
Bill.total, status
Bill.status
contains
) prefix element types with class
> names to avoid name conflicts Product
<!ELEMENT Bill.total(#PCDATA)> price
<!ELEMENT Bill.status (#PCDATA)> descr
Attribute Element, hierarchic
BankAccount
<!ELEMENT Client
accNo
Client( name
code
Client.name 1
1 pays
)
> to
Bill
<!ELEMENT Client.name(#PCDATA)> total
status
prefix element types with class
names to avoid name conflicts contains
Product
price
descr
Attribute Element, hierarchic
BankAccount
<!ELEMENT Client
accNo
Product( name
code
Product.price, 1
1 pays
Product.descr
) to
Bill
> total
<!ELEMENT Product.price (#PCDATA)> status
<!ELEMENT Product.descr (#PCDATA)>
contains
Product
price
descr
Attribute Element, hierarchic
BankAccount
<!ELEMENT Client
accNo
BankAccount( name
code
BankAccount.accNo, 1
1 pays
BankAccount.code
) to
Bill
> total
<!ELEMENT BankAccount.accNo (#PCDATA)> status
<!ELEMENT BankAccount.code (#PCDATA)>
contains
Product
price
descr
DTD Summary: Attribute Element, hierarchic
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT Bill (Client, Product*, BankAccount, Bill.total,
Bill.status)>
<!ELEMENT Client (Client.name)>
<!ELEMENT Product (Product.price, Product.descr)>
<!ELEMENT BankAccount (BankAccount.accNo,
BankAccount.code)>
<!ELEMENT Bill.total (#PCDATA)>
<!ELEMENT Bill.status (#PCDATA)>
<!ELEMENT Client.name (#PCDATA)>
<!ELEMENT Product.price (#PCDATA)>
<!ELEMENT Product.descr (#PCDATA)>
<!ELEMENT BankAccount.accNo (#PCDATA)>
<!ELEMENT BankAccount.code (#PCDATA)>
Object Diagram XML Instance: Attrib. El.,
hierarchic
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE Bill SYSTEM „we-shop-el.dtd"> :BankAccount :Client
<Bill>
<Client>
accNo = 0815 name
<Client.name>Max</Client.name> code = 1234 = “Max“
</Client>
<Product> :Bill
pays
<Product.price>50</Product.price> to status =
<Product.descr>Winnetou</Product.descr>
closed
</Product>
<Product> total =
<Product.price>100</Product.price> 150
<Product.descr>H. Potter</Product.descr>
contains contains
</Product>
<BankAccount>
<BankAccount.accNo>4711</BankAccount.accNo> :Product :Product
<BankAccount.code>0815</BankAccount.code> price = price=50
</BankAccount> 100 descr =
<Bill.status>closed</Bill.status> descr = “Winnetou“
<Bill.total>150</Bill.total> “H.Potter“
</Bill>
Mapping: Class Diagrams DTDs
General Rules
class element
association (n-to-n) element
Plus two (orthogonal) mapping variants
attribute attribute, hierarchic
attribute element, hierarchic
attribute attribute, net-like
attribute element, net-like
o hierarchic or
determined by
o net-like structure DTD-specific model
Discussion
Attribute Attribute
more compact XML documents
smaller footprint, more efficient processing and
transmission
better readability
Attribute Element
uniform mapping of classes and attributes
DTD remains (relatively) stable even when class
diagram is extended
Questions: Data Capacity
Apply the mapping attribute element, hierarchic to the
exercise at the end of 2.1. extended by the following
attribute cardinality, stating that attribute b has to carry
at least one but possibly many values.
A 1..* 2 B
a: String b: int [1..*]
Create
1. DTD specific class diagram
2. DTD and sample XML instance
Try to ensure that data capacity is preserved or at least
extended, and where this is not the case, point this out
and justify why it is not.
CO7214 / CO7514: Service-oriented Architectures
Outline
1. Introduction
2. Modelling XML Data
Mapping Class Diagrams to DTDs
Attribute to Attribute, hierarchic
Attribute to Element, hierarchic
4. Net-like Mapping
Class Diagram DTD: Attribute Element, Net-like
BankAccount
Client
New Scenario: send all Bills of accNo
name
the week to archive code
1
1 pays
<!ELEMENT root (Bill*, Client*,
to
Product*, BankAccount*)> Bill
total
status
<!ELEMENT Bill (Bill.status, Bill.total)>
contains
<!ATTLIST Bill
pays IDREF #REQUIRED Product
contains IDREFS #IMPLIED price
to IDREF #REQUIRED descr
>
Class Diagram DTD: Attribute Element, net-like
BankAccoun
t Client
<!ELEMENT Client(Client.name)> accNo name
<!ATTLIST Client
code
id ID #IMPLIED 1
1 pays
>
<!ELEMENT Product(Product.price, to
Bill
Product.descr)>
<!ATTLIST Product total
id ID #IMPLIED status
>
<!ELEMENT BankAccount(BankAccount.accNo, contains
BankAccount.code)>
Product
<!ATTLIST BankAccount
id ID #IMPLIED price
> descr
.. plus mapping of UML attributes, Attribute Element, hierarchic
Object Diagram XML Instance: Attrib. El., net-like
<root> a1:BankAccount c1:Client
accNo = 4711 name
<Bill pays="c1" to="a1" contains="p1 p1">
code = 1234 = “Max“
<Bill.status>closed</Bill.status>
<Bill.total>100</Bill.total> :Bill
pays
</Bill> to status =
closed
total =
<Client id="c1"> 100
<Client.name>Max</Client.name> contains contains
</Client>
p1:Product
price = 50
descr = “Winnetou“
Object Diagram XML Instance: Attrib. El., net-like
a1:BankAccount c1:Client
<Product id=“p1"> accNo = 4711 name
<Product.price>50</Product.price> code = 1234 = “Max“
<Product.descr>Winnetou</Product.descr>
</Product> :Bill
pays
to status =
<BankAccount id=“a1"> closed
<BankAccount.code>1234</BankAccount.code> total =
<BankAccount.accNo>4711</BankAccount.accNo>100
</ BankAccount > contains contains
p1:Product
</root>
price = 50
descr = “Winnetou“
Mapping: Class Diagrams DTDs
General Rules
class element
association (n-to-n) element
Plus two (orthogonal) mapping variants
attribute attribute, hierarchic
attribute element, hierarchic
attribute attribute, net-like
attribute element, net-like
o hierarchic or
determined by
o net-like structure DTD-specific model
Discussion
Hierarchic
obvious tree structure
simplifies navigation and processing
better readability
Net-like
relational structure
less redundancy
simplified mapping to relational data model
Exercise and Question
Apply the mapping attribute attribute, hierarchic to
the exercise at the end of 2.1. creating
1. DTD specific class diagram
2. DTD and sample XML instance
Try to ensure that data capacity is preserved or at
least extended, and where this is not the case, point
this out and justify why it is not.
Describe examples where, based on the data model
given or informally stated requirements, hierarchical
or net-like mappings may be more appropriate.
How can you unfold a non-hierarchical structure into
a tree?
CO7214 / CO7514: Service-oriented Architectures
Outline
1. Introduction
2. Modelling XML Data
Mapping Class Diagrams to DTDs
Attribute to Attribute, hierarchic
Attribute to Element, hierarchic
Net-like Mapping
